Top 5 Application Security
White Paper
Security Builder

                       Vulnerabilities and How to
Application Sec...
White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them




                                     ...
White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them




Introduction
Independent software ven...
White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them




                                    A...
White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them



Top 5 Programming Mistakes That Create...
White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them



                                      ...
White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them



Automated Tools Enable Security Scanni...
White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them




     Sample Vulnerability Report from...
White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them




                                     ...
For more information on the Security Builder offering from the Intel® Software Partner Program,
  visit www�intel�com/cd/s...
Upcoming SlideShare
Loading in …5
×

Top 5 Application Security Vulnerabilities and How to Mitigate Them

839 views

Published on

This white paper explains common errors developers make that expose applications to security flaws, and provides recommendations that can minimize potential problems.

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
839
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Top 5 Application Security Vulnerabilities and How to Mitigate Them

  1. 1. Top 5 Application Security White Paper Security Builder Vulnerabilities and How to Application Security Mitigate Them
  2. 2. White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them Table of Contents Introduction � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 3 Embarrassing to Expensive: Costs of Security Mistakes Continue to Rise � � � � � � � � � � � � � � � � � � � � � 3 Common Doorways to Application Security Vulnerabilities � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 4 Top 5 Programming Mistakes That Create Security Risks � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 5 Mistake #1: Input Validation � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 5 Mistake #2: Failure to Constrain Operations Within the Bounds of a Memory Buffer � � � � � � � � � � � � � 6 Mistake #3: External Control of Critical State Data � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 6 Mistake #4: External Control of File Name or Path � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 7 Mistake #5: Use of a Broken or Risky Cryptographic Algorithm � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 7 Automated Tools Enable Security Scanning � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 8 Conclusion � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 9 2
  3. 3. White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them Introduction Independent software vendors (ISVs) face many challenges in bringing a software product to market. Good coding practices can reveal bugs before customers experience them, prevent outsiders from accessing data they shouldn’t, and deliver a high-quality product. Unfortunately, under the pressure of a tight development schedule, it is difficult to stay focused on the fact that malicious intruders are actively searching for the smallest opportunity to breach application security. That oversight can be expensive for both the software company and its customers. Ideally, a secure program is as specific as a legal agreement, clearly stipulating what is and is not allowed. However, computer programs are incredibly complex—and they are usually a combination of code that has been written in-house and code from third-party software development libraries. Rushed development can introduce vulnerabilities into a developer’s own code. Plus, software companies often blindly trust the third-party software development libraries they re-ship, treating the output from these functions as completely harmless and granting that data the same access that the leaders of Troy gave the Trojan Horse. Even after the problems are discovered and published, if the developers do not find out about the exploits and update their libraries, they continue to expose their customers to potential attackers in version after version. This paper is designed to provide an overview of vulnerability sources and the most common software development mistakes that expose an application to hackers. It also recommends a simplified and inexpensive approach to testing and monitoring applications for known security risks. Embarrassing to Expensive: Costs of Security Costs Associated with Software Security Breaches Mistakes Continue to Rise Failure to catch quality problems may lead to security issues that can USD 250 range from embarrassing to expensive for a software company. A customer that loses trust in an application will likely choose competing USD 200 products. Even worse, a business customer using insecure software Cost per Record may lose significant amounts of data or lose customers of their own, resulting in significant legal and public relations issues for the USD 100 software company. The costs associated with a single software security breach can be USD 50 well over a billion dollars, depending on the number of customer records impacted (see Figure 1). According to the Ponemon Institute, costs USD 0 associated with data breach include the cost of setting up call centers 2005 2007 2008 2006 for handling customer calls; expenses for legal, administrative, and Year investigative purposes; reputation management; and other PR costs. Source: The Ponemon Institute, U.S. Cost of a Data Breach Study, 2005-2008 Figure 1. According to the Ponemon Institute, the costs associated with software security breaches have increased over time� 3
  4. 4. White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them Attack Sophistication vs. Intruder Technical Knowledge High Required Attacker “Stealth”/advanced scanning techniques Knowledge Denial-of-service attacks Network management diagnostics Distributed denial-of-service Sniffers (DDOS) attacks WWW attacks Sweepers Automated probes/scans Back doors GUI Burglaries Packet spoofing Hijacking sessions Disabling audits Attack Exploiting known vulnerabilities Sophistication Password cracking Self-replicating code Password guessing Low 2000 1980 1985 1990 1995 Source: Carnegie Mellon University Software Engineering Institute Figure 2. As attack sophistication increases, the amount of knowledge required by the intruder to create a successful attack decreases. Over the last few years, attacks and security breaches have become built on top of certain libraries provided by others; in some cases these more frequent—in part because the knowledge required to perform are components provided by the platform, operating system, or an attack on a system has steadily declined thanks to sophisticated environment they expect to be installed in. Their functions range from tools and toolkits now available to attackers (see Figure 2). The the mundane “print” statements that display on a computer monitor bottom line: Application attacks are both easier than ever to perform to extremely sophisticated third-party tools such as math libraries or and potentially more costly than ever before. Embedding application graphics drivers. ISVs integrate these components and ship them as security practices into the development process has always been parts of their own application important—today, it’s critical. However, these libraries are often seen as complete, stable, robust parts that can be relied on to function exactly as specified and deliver Common Doorways to Application Security trustworthy data under any circumstances. Though the library author Vulnerabilities intends no malice, this is akin to bringing the Trojan Horse into the city What can you do to make sure your application is not exposed to even of Troy. A component may look innocent enough from the outside, but unsophisticated hackers? Start by avoiding the top five frequently unless the ISV chooses to research the contents, error-handling made mistakes outlined in this white paper. There are many more coding capabilities, and behavior under stress, the risks of adopting that mistakes that can expose your application, but most vulnerabilities software are unknown. are derivatives of these five. Unfortunately, this is a common doorway that allows bugs to slip in. It is crucial to watch for these vulnerabilities in every part of your While most software companies tend to stay focused on their own application, which includes both the code that you write and the code intellectual property, the additional step of testing, checking, and that you obtain from outside sources. Most computer programs are monitoring third-party libraries for known exploits is critical. 4
  5. 5. White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them Top 5 Programming Mistakes That Create Security Secure operating systems with strict permissions help mitigate the risk, but writing software that works in concert with those Risks permissions requires a lot of forethought and presents a steep Mistake #1: Input Validation learning curve for a less-experienced software developer. Resist the temptation to require the software to run as a superuser (“root,” The most common mistake—one made in even the most popular “administrator,” etc.) as a solution to tricky permission problems. software—is a procedure or function that assumes it can trust the Even if it is intended as a temporary shortcut, deadline pressure can data input it receives. Tight deadlines and limited resources encourage make the most conscientious developers forget to restore proper a focus on core functionality, not on what might go wrong. But what permissions handling. Also, the potentially destructive power of OS commands makes it especially crucial to check the dependencies happens if the user intentionally inputs something incorrect, knowing and external resources of the application. that the output will be malicious? • Cleartext/plaintext transmission of sensitive information: • Improper encoding or escaping input: In a simple statement like By simply watching data traffic—easy to do and often impossible “_______ went to school today,” we might expect the blank to be to detect—sensitive information can be collected and reproduced filled in with a person’s name, like “Mary.” What happens when the later by another machine posing as the original. Some of the most blank is filled in with “The school was closed. Only the uninformed”? common protocols, such as POP for e-mail login and retrieval, do The new statement now is very different from what we expected not normally encrypt passwords or other sensitive information, and the output to be and has a very different meaning. most software architects consider any data behind some sort of The same tricks can be used in a computer language to change the password-protected gate or network to be secure. meaning of a command that is being executed. This turns “do what I However, no network is completely secure—and even if it were, many mean” into “do what the attacker says.” of the most devastating attacks are launched by people within the To provide protection, all possible sources of input should be security gate, or with some sort of inside information. Also, the infor- checked to make sure nothing in the input becomes executable. mation that was secure when the program was created is no longer • Failure to preserve SQL query structure: Much like the previous secure once an exploit method is published (see Mistake #5). Secure example, commands can be modified to alter the way databases encryption techniques should always be used when transmitting function. For example, a mischievous change to the scope of a SQL sensitive data. statement might cause the database to delete all records instead of just the two or three that are not needed. Do not make it easy Mistake #2: Failure to Constrain Operations Within the Bounds of for an attacker to modify the commands. It may be simpler to use a Memory Buffer the client’s Java* interpreter to issue store commands in the server’s Another common attack technique is to feed more data through a database, but since Java is often plaintext, it is easily modified. buffer than is expected. If that user-entered data is close enough to • Failure to preserve Web site data integrity: Web sites that the executable data, the user can actually change the instructions the accept instructions from other servers in plaintext offer green computer executes. Secure applications record all data (input and out- fields of opportunity for intruders. Plaintext commands should be put) with care and never store more data than is allocated in memory. as benign as possible, and when they can’t be, every command com- ing from the outside needs to be double-checked. Even “trusted” Tools like the Microsoft Data Execution Prevention* feature and networks of servers are vulnerable, as middleman attacks (in which Intel® Execute Disable Bit are designed to help operating systems a third-party machine intercepts and/or modifies the data while it is in transit, mimicking the role of the machines on each end of the distinguish between data that should be stored and data that are source-to-destination transmission) are common tactics. Remem- computer instructions. Be sure that these effective measures are ber, the machine or code that you think you trust might not be what turned on whenever possible—they are often off by default. you think it is. Also, while field lengths are sometimes enforced by the OS or by the • Failure to preserve OS command structure: This attack compiler when the program is created, this safety net does not always resembles SQL command injection, but is far more dangerous. An exist and may not always be trustworthy. It is best to always double- OS attack can cause a machine to run any command in any way. Some commands can cause permanent damage to hardware if used check the size of incoming data. incorrectly, causing millions of dollars in damage if executed across a cluster, or if they affect irreplaceable data. 5
  6. 6. White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them Mistake #5: Use of a Broken or Risky Cryptographic Algorithm Finally, when using an external tool that receives data, never assume that the tool checks the data or that the checks are infallible. The One of the best ways to protect data is to encrypt the information so story of the original Trojan Horse comes to mind: don’t trust it if you that it can’t be easily read (see Mistake #1). Any encryption is usually don’t know what’s inside. “good enough,” since attackers who do not know what they are looking for tend to collect the data that is the easiest to obtain, and Mistake #3: Exposing Critical State Data to External Control most data exchanges are fairly benign. Computers know what to do by comparing numbers, such as the Unfortunately, cryptography is also a yellow flag to attackers who numerical coordinates of the mouse cursor, the memory position of know what they are looking for. To an attacker, cryptography signals certain data, and values within the program. These numbers are the that the data must be more valuable if the developer took the time to basis of conditional statements, e.g. if the bank balance is less than 0, protect it. When someone cracks the code and publishes how they did print an error message; if the user does not have permission, block them; it, a software vendor who continues to use that encryption essentially if a decimal value is too long, round it off and discard the difference. leaves its customers’ keys in the front door, not only advertising that When attackers can change values, it can enable them to manipulate sensitive data is present but providing the means to decode it. Grab a software to their advantage. They could change permission values to public domain tool from just about anywhere, and you can gain access allow anyone to delete a bank account, or flag data as corrupt so that to that encrypted data. the program will copy the correct data into a backup file controlled by the attackers. Secure Coding Resources Even if the vendor’s own software is secure, if data is not sent or These two resources can provide additional information on received to an external dependency through secure means, the out- common programming errors and secure coding practices. side program may be manipulated to do the wrong thing via a middleman attack. Top 25 Most Dangerous Programming Errors Ideally, data should be securely encrypted at all times, but that may A list of the 25 most dangerous (and most common) pro- not be practical. The next best solution is to encrypt data when it is gramming errors, based on the SANS top 20 attack vectors being transmitted, and carefully investigate third-party code compo- and MITRE’s 2009 Common Weakness Enumeration (CWE). nents for potential vulnerabilities. http://cwe.mitre.org/top25 Mistake #4: External Control of File Name or Path Top 10 Secure Coding Practices Software developers usually assume that the component that they Part of the CERT Secure Coding Web Site, this list includes use to manage files performs some level of file name checking. 10 secure coding practices, plus two bonus practices. However, this is often not the case, and a user can enter a complete path name when asked only for a file name (../../private/donttouch/ www.securecoding.cert.org/confluence/display/seccode/ foobar.txt instead of foobar.txt), placing a file somewhere it is not Top+10+Secure+Coding+Practices supposed to be, and possibly overwriting a critical configuration file with new data that exposes the application to attack. If the software has been granted superuser permissions as described in Mistake #1, the entire system could be compromised. Error and overwrite conditions are often hidden in the fine print of the documentation for many file handler procedures, making it difficult for the programmer to discover the problem and protect (or at least warn) the customer. 6
  7. 7. White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them Automated Tools Enable Security Scanning States Department of Homeland Security. Unfortunately, this can be a daunting task, and does not warn you when new It is already challenging to deliver your own software on time and vulnerabilities are discovered after your research is complete. fully functionally tested, let alone tested for security vulnerabilities. Checking for these kinds of issues in the third-party software you For most companies, it is enough to be informed of relevant depend on is often above and beyond the time and means of the vulnerabilities before their exploits are broadly known (see Figure 3). typical quality assurance team, especially since new vulnerabilities Security Builder, a premium service from the Intel® Software Partner are discovered in older software every day. Program, was designed to address that need. Beyond avoiding common mistakes during application development, Available from Intel through a partnership with SpikeSource, Security there are a variety of tools and solutions that provide another level Builder helps determine if the components that your application of security assurance during the test phase. Larger organizations may depends upon have known problems by comparing the list of use high-end security testing solutions that can require a significant components you use with the vulnerability reports in the NVD and investment in training and manpower. However, many organizations other published sources. are not in a position to implement these high-end solutions. In addition to the customized reporting and notification service, Another option is to compare components used in the application Security Builder offers access to a component library that is against published security vulnerabilities as catalogued in the tested and updated on a regular basis, making it easy for software National Vulnerability Database (NVD), maintained by the United developers to quickly update the application with the most secure version of the component. Vulnerability Exploit Cycle Automated scanning/exploit tools developed Novice intruders Widespread use Intruders begin use crude of automated using new types exploit tools scanning/exploit of exploits tools Crude exploit tools distributed Advanced intruders discover vulnerability Source: Carnegie Mellon University Software Engineering Institute Figure 3. The vulnerability exploit cycle peaks with widespread use of automated scanning and exploit tools. 7
  8. 8. White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them Sample Vulnerability Report from Security Builder Overview Analysis of the principal-level components—or top-level components—noted the following critical vulnerabilities: Component CVE Number Summary Published CVSS Severity BlazeDVD CVE-2006-6199 Stack-based buffer overflow in BlazeVideo BlazeDVD Standard and Professional 5.0, and 11/30/2006 7.5 (High) possibly earlier, allows remote attackers to execute arbitrary code via a long file name in a PLF playlist. Analysis of second-level components yielded the following vulnerabilities: CVE Number Summary Published CVSS Severity CVE-2007-3901 Stack-based buffer overflow in BlazeVideo BlazeDVD Standard and Professional 5.0, and possibly earlier, allows 12/11/2007 8.5 (High) remote attackers to execute arbitrary code via a long filename in a PLF playlist. CVE-2005-2128 QUARTZ.DLL in Microsoft Windows Media Player 9 allows remote attackers to write a null byte to arbitrary memory 10/12/2005 5.0 (Medium) via an AVI file with a crafted strn element with a modified length value. CVE-2003-0346 Multiple integer overflows in a Microsoft Windows DirectX MIDI library (QUARTZ.DLL) allow remote attackers to 8/27/2003 7.5 (High) execute arbitrary code via a MIDI (.mid) file with (1) large length for a Text or Copyright string, or (2) a large number of tracks, which leads to a heap-based buffer overflow. When reviewing automated security testing solutions, consider 3 Does the tool send detailed information on the following: the nature and source of code change? 3 Does the tool maintain a detailed registry of all 3 Can it generate a summary report of the underlying components specific to your solution? components and dependencies of the application? 3 Does it monitor your application components 3 Does the tool provide an intuitive management for new published vulnerabilities? console for managing the update process according to your company policies and procedures? 3 Can it track and evaluate thousands of events weekly across multiple databases, code repositories, Usenet It is most effective to use an automated security scanning tool like groups, bug databases, mail lists, and RSS feeds? Security Builder before the height of the exploit cycle to help ensure that your application is protected when most intruders will attempt to 3 Does it issue smart alerts that determine relevance strike (see Figure 4). of code changes, and provide alerts only when critical changes are required to preserve security? 8
  9. 9. White Paper: Top 5 Application Security Vulnerabilities and How to Mitigate Them When to Use Security Builder Automated scanning/expl oit tools developed Novice Widespread use of intruders use automated crude exploit scanning/exploit Security Builder continues to protect against tools tools future exploit cycles of the same vulnerability Crude exploit tools distributed Security Builder Advanced detects exploit intruders discover vulnerability Figure 4. Automated scanning tools like Security Builder provide the most protection when used prior to the peak of the vulnerability exploit cycle� Conclusion 3. Use an automated scanning tool to help identify any known vulnerabilities in your software stack before exposing your As costs associated with security breaches continue to rise, so does customers to them. the risk that unsophisticated intruders with a motive will use a tool to exploit an application’s weak points. There are several checkpoints Security Builder is a convenient service from Intel that not only scans along the way that can help ensure your shipping software is secure: your application for security vulnerabilities, but also catalogues the components in your application and notifies you automatically when 1. Take care during application development to avoid the common new exploits or vulnerabilities are detected and require attention. mistakes that can plague the development process. Use the expert-recommended techniques referenced in this document to A greater awareness of the security risks commonly overlooked during ensure that obvious doorways for attack are closed and locked. application development, combined with a quality assurance process that 2. Do not assume that the common components used in your includes an automated tool for scanning and reporting on known vulner- application are secure. Make sure that you are using the latest abilities, can significantly improve application security and help protect available version, that it has been tested, and any vulnerabilities both you and your customers from expensive omissions and mistakes. have been resolved. 9
  10. 10. For more information on the Security Builder offering from the Intel® Software Partner Program, visit www�intel�com/cd/software/partner/asmo-na/eng/388020�htm or call an Intel representative today at 1-866-320-9853� INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL’S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WAR- RANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked “reserved” or “undefined.” Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or by visiting Intel’s Web site at www.intel.com. Copyright © 2009 Intel Corporation. All rights reserved. Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and other countries. *Other names and brands may be claimed as the property of others. Printed in USA 0309/JTM/TDA/XX/PDF Please Recycle 321559-001US

×