Known Vulnerabilities

Why Study Known Vulnerabilities?

It’s good to make big-picture, generic categorizations, say, of:

But we need specifics, too! Knowledge of real vulnerabilities and exploits that have actually happened, those that have been in the news, and those that have well-known names is an important part of the discipline of software security. We need to understand history to know what people are doing, what they are trying, what is possible, and how the experts have reacted. Examples of specific attacks include:

• SYN flooding, Smurfs, Pings of death, and Teardrops are kinds of DOS attacks
• Session hijacking, Replay, and IP Spoofing are kinds of MitM attacks
• SQL Injection and XSS are kinds of Injection attacks.
• A Drive-by is but one way to install malware.

Knowing the technical details of how these work help you create software that can prevent or defend against these attacks.

Terminology Review

These terms will be important in our discussion:

Weakness

A shortcoming (e.g., poor design, substandard software implementation, sloppy deployment) in a system that could become a vulnerability.

Vulnerability

A characteristic rendering an asset or assets open to exploitation.

Exploit

The attack itself, or the payload used in the attack, resulting in a breach of confidentiality, integrity, or availability.

Interested in a comprehensive glossary? The NICCS has one. NIST has a smaller one.

Weakness vs. Vulnerability

In practice, these terms are not too distinct. In the context of the famous CWE and CVE, they are slightly distinguished.

The CWE and the CVE

People learn from mistakes. So if weaknesses and vulnerabilities could be recorded and cataloged in a central, well-known location, we could all learn so much. Indeed, such catalogs do exist. We have (with descriptions quoted from the sites themselves):

The CWE

The CWE™ “is a community-developed list of software and hardware weakness types. It serves as a common language, a measuring stick for security tools, and as a baseline for weakness identification, mitigation, and prevention efforts.” (See the FAQ)

The CVE

“The mission of the CVE® Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities.”

What are the main differences?

Common Weakness Enumeration

The CWE lists types of weaknesses, and covers both hardware and software. The list is contributed to by a large community. Each weakness gets a CWE number, and can appear in multiple views. Each entry has a pretty detailed description.

The list page is a great place to start

Definitely click on the TOP 25 link. Every year the Top 25 shift a bit; it’s fun to see the changes in this list over time. In the year 2020, the top 25 were (scores included):

One nice thing about the CWE folks: they cross-reference many of their entries with other lists, such as rules from the CERT standards and lists from OWASP. We’re all in this together, right?

We’re going to browse the CWE

Common Vulnerabilities and Exposures

The CVE is a list of publicly disclosed flaws. Each entry is pretty brief. (Interested in a brief overview of the CVE iteslf? RedHat has one).

There are over 100,000 entries here, so you don’t just download the whole list. It’s more useful to just do a search.

We’re going to browse the CVE®

OWASP

The Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software. The OWASP Foundation provides resources, training, events, and more. One of their best known projects is the OWASP Top Ten. This “standard awareness document for developers and web application security” provides for each entry attack vectors, descriptions of the weakness, impacts, how to tell if software is vulnerable, how to prevent it, example attack scenarios, and references.The document is considered by many to be required reading for anyone producing web applications.

OWASP Top Ten

So what are the top 10?

• Injection
• Broken Authentication
• Sensitive Data Exposure
• XML External Entities
• Broken Access Control
• Security Misconfiguration
• XSS
• Insecure Deserialization
• Using Components With Known Vulnerabilities
• Insufficient Logging and Monitoring

We’ll be browsing the Top 10, of course.

This Top 10 List is Famous

But don’t think it’s the greatest thing since sliced bread.

OWASP Proactive Controls

There are a number of other resources from OWASP besides the famous Top 10. You may be interested in this other Top 10 List, the OWASP Top Ten Proactive Controls, which are:

• C1: Define Security Requirements
• C2: Leverage Security Frameworks and Libraries
• C3: Secure Database Access
• C4: Encode and Escape Data
• C5: Validate All Inputs
• C6: Implement Digital Identity
• C7: Enforce Access Controls
• C8: Protect Data Everywhere
• C9: Implement Security Logging and Monitoring
• C10: Handle All Errors and Exceptions

OWASP Cheatsheets

OWASP also has dozens and dozens of cheatsheets from its remarkable OWASP Cheat Sheet Series, each of which provides a wonderful introduction and description and useful details about security issues. Ones should get to know include: Injection Prevention, Authentication, Authorization, Key Management, User Privacy Protection, Input Validation. Actually, they’re all good.

Some Classics

We’ll do a few classics in class. For more, visit the lessons at Hacksplaining.

XSS

Cross-site scripting (XSS) ranks #1 on the CWE. It’s basically an injection attack in which you blindly take user input and render it straight into your HTML page (e.g., Q & A, forums, comments, tweets). If that user input contains JavaScript code, the browser is going to execute it. 😬

This one is somewhat web-specific, so we’ll deal with web servers later in the course when we do web security.

Even Google search had an XSS vulnerability once:

More at: Hacksplaining • Acunetix • Wikipedia • Tom Scott • OWASP • Software Testing

CSRF

In a Cross-Site Request Forgery (CSRF) attack, the attacker tricks the victim into sending data to a server that the victim is authenticated with, but the payload is controlled by the attacker and causes unintended (and bad) things to happen, such as the user changing their password (to something the attacker might know) or to transfer money to the attacker’s account. The attack works if the user is authenticated only via a cookie or token. The attacker crafts a request with the malicious payload and gets the victim to invoke it, generally by visiting an evil site or clicking on a link or image. The malicious request has the same format as a legal form or API request that the user would normally make. There are many protections a server can employ to keep its users safe from these attacks. (Also, users should be careful what they click on.)

More at: Hacksplaining • Acunetix • Wikipedia • from Tom Scott • OWASP

Session Hijacking

If an attack can sniff out or steal a cookie or authentication token, they will be able to impersonate a logged-in user. A session can be hijacked via session fixation, session predicition, XSS, malware installation, or session side jacking.

More at: Wikipedia • OWASP • CWE • Acunetix

SQL Injection

If an application composes SQL statements with string concatenation using user input, someone is going to give it a malicious string. Every programmer is probably familiar with Bobby Tables’s mom:

What did she do? Well, it’s likely that the school’s backend accepted a student name from a form and made a query like this:

"INSERT INTO STUDENTS (NAME) VALUES ('" + name + "');"

Let’s replace the variable with Bobby’s full name:

INSERT INTO STUDENTS (NAME) VALUES ('Robert'); DROP TABLE Students;--');

This is easy to defend against. You could sanitize but that’s not the best approach and is risky. Don’t do that, despite what the comic suggests!!!. Instead, use prepared statements with parameters. Higher-level libraries that allow programmatic access to databases have these best practices in place already and will not be vulnerable.

But don’t JUST rely on prepared statements! Defend in depth! Make sure you also:

• Validate inputs (proper ids, proper usernames, proper domain object syntax, etc.)
• Make sure the database user accessing the database in the webapp has minimal permissions (better not be an admin)
• Encrypt the data in your database
• Keep the database itself behind a firewall

More at: Hacksplaining • OWASP • CWE • Acunetix • Tom Scott

Billion Laughs

This attack can be made against machines that will accept an XML document and parse it without sanitization, because XML allows entity definitions which expand. Any entity expansion big enough qualifies as an XML Bomb. The original “Billion laughs” has a payload which expands into a billion lols:

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

More at: Wikipedia • OWASP • CWE

Stack Smashing

Also known as a stack buffer overflow attack, this occurs when a poorly coded function allocates a buffer (e.g., an array) as a local variable in the run-time stack and allows it to be filled with user input that it does not length-check. The attacker can writing a specially crafted string into this array in such a way that the function “returns” to a block of memory containing malicious machine code set by the attacker.

More at: Wikipedia • Hacksplaining • CWE • The classic 1996 paper by Aleph One

Format String Attack

Source code using any printf-like function that allows user input for the format string and a variable number of arguments is vulnerable to a well-crafted input string that can read and write memory.

Examples and more at: Wikipedia • OWASP • CWE • A comprehensive paper • Another paper • An Introduction

Resource Enumeration

Any time identifiers are generated sequentially with, say, an integer id, and these identifiers are visible, an attacker can figure out user ids, gift card ids, video conferencing ids, shipment ids, etc.

On sites where usernames are not expected to be public, knowledge of a username could aid an attacker. How do you prevent or defend?

• Don’t use sequential ids
• CAPTCHA
• Rate limiting
• Delay time for unsuccessful login (prevents time-based attacks)
• Never say “username already taken”
• Give a generic “wrong credentials" error, don’t say whether the username or password was wrong
• Don’t put a username on a password reset form
• User should enter their email to get a password reset link
• If user tries to sign up with an existing email address, send an email saying that attempt occurred (don’t hint at anything else on the signup page in your app!)
• Don’t expose profile pages to the public
• Error message for non-existent profile should be same as error message for attacker not being logged in

More at: Hacksplaining • Dev.To • DevelopSec

A Short Guide to Some Attacks

No details or links here, but you might find this summary useful.

For more detail, see this article.

Summary