Exploit An exploit (from the same word in the French language, meaning "achievement", or "accomplishment") is a piece of software, a chunk

of data, or sequence of commands that take advantage of a bug, glitch or vulnerability in order to cause unintended or unanticipated behavior to occur on computer software, hardware, or something electronic (usually computerized). This frequently includes such things as violently gaining control of a computer system or allowing privilege escalation or a denial of service attack.

Classification There are several methods of classifying exploits. The most common is by how the exploit contacts the vulnerable software. -A 'remote exploit' works over a network and exploits the security vulnerability without any prior access to the vulnerable system. -A 'local exploit' requires prior access to the vulnerable system and usually increases the privileges of the person running the exploit past those granted by the system administrator. -Exploits against client applications also exist, usually consisting of modified servers that send an exploit if accessed with client application. Exploits against client applications may also require some interaction with the user and thus may be used in combination with social engineering method. Another classification is by the action against vulnerable system: unauthorized data access, arbitrary code execution, denial of service. Many exploits are designed to provide superuser-level access to a computer system. However, it is also possible to use several exploits, first to gain low-level access, then to escalate privileges repeatedly until one reaches root. Normally a single exploit can only take advantage of a specific software vulnerability. Often, when an exploit is published, the vulnerability is fixed through a patch and the exploit becomes obsolete for newer versions of the software. This is the reason why some blackhat hackers do not publish their exploits but keep them private to themselves or other malicious crackers. Such exploits are referred to as 'zero day exploits' and to obtain access to such exploits is the primary desire of unskilled malicious attackers, often nicknamed script kiddies.[citation needed] Types Exploits are commonly categorized and named by these criteria: The type of vulnerability they exploit (See the article on vulnerabilities for a list) Whether they need to be run on the same machine as the program that has the vulnerability (local) or can be run on one machine to attack a program running on another machine (remote). The result of running the exploit (EoP, DoS, Spoofing, etc...)

Vulnerability In computer security, the term vulnerability is applied to a weakness in a system which allows an attacker to violate the integrity of that system. Vulnerabilities may result from weak passwords, software bugs, a computer virus or other malware, a script code injection, or a SQL injection. A vulnerability may exist only in theory, or may have a known instance of an exploit. Constructs in programming languages that are difficult to use properly can be a large source of vulnerabilities. Causes Password Management Flaws The computer user uses weak passwords that could be discovered by brute force. The computer user stores the password on the computer where a program can access it. Users re-use passwords between many programs and websites. Fundamental Operating System Design Flaws The operating system designer chooses to enforce sub optimal policies on user/program management. For example operating systems with policies such as default permit grant every program and every user full access to the entire computer. This operating system flaw allows viruses and malware to execute commands on behalf of the administrator. [1] Software Bugs The programmer leaves an exploitable bug in a software program. The software bug may allow an attacker to misuse an application through (for example) bypassing access control checks or executing commands on the system hosting the application. Also the programmer's failure to check the size of data buffers, which can then be overflowed, causing corruption of the stack or heap areas of memory (including causing the computer to execute code provided by the attacker). Unchecked User Input The program assumes that all user input is safe. Programs that do not check user input can allow unintended direct execution of commands or SQL statements (known as Buffer overflows,SQL injection or other non-validated inputs).

Vulnerability disclosure The method of disclosing vulnerabilities is a topic of debate in the computer security community. Some advocate immediate full disclosure of information about vulnerabilities once they are discovered. Others argue for limiting disclosure to the users placed at greatest risk, and only releasing full details after a delay, if ever. Such delays may allow those notified to fix the problem by developing and applying patches, but may also increase the risk to those not privy to full details. This debate has a long history in security; see full disclosure and security through obscurity. More recently a new form of commercial vulnerability disclosure has taken shape, as some commercial security companies offer money for exclusive disclosures of Zero Day vulnerabilities. Those offers provide a legitimate market for the purchase and sale of vulnerability information from the security community. From the security perspective, a free and public disclosure is only successful if the affected parties get the relevant information prior to potential hackers, if they did not the hackers could take immediate advantage of the reveled exploit. With Security Through Obscurity the same rule applies, but this time rests on the hackers finding the vulnerability themselves, as opposed to being 'told' the information. The disadvantage here is that there is a lower number of people with full knowledge of the vulnerability who can aid in finding similar or related scenarios.

It should be unbiased to enable a fair dissemination of security critical information. Most often a channel is considered trusted when it is a widely accepted source of security information in the industry (e.g CERT, SecurityFocus, Secunia and FrSIRT). Analysis and risk rating ensure the quality of the disclosed information. The analysis must include enough details to allow a concerned user of the software to assess his individual risk or take immediate action to protect his assets. Vulnerability disclosure date The time of disclosure of a vulnerability is defined differently in the security community and industry. It is most commonly referred to as "a kind of public disclosure of security information by a certain party". Usually, vulnerability information is discussed on a mailing list or published on a security web site and results in a security advisory afterwards. The time of disclosure is the first date a security vulnerability is described on a channel where the disclosed information on the vulnerability has to fulfil the following requirement: the information is freely available to the public the vulnerability information is published by a trusted and independent channel/source the vulnerability has undergone analysis by experts such that risk rating information is included upon disclosure

Identifying and removing vulnerabilities Many software tools exist that can aid in the discovery (and sometimes removal) of vulnerabilities in a computer system. Though these tools can provide an auditor with a good overview of possible vulnerabilities present, they can not replace human judgment. Relying solely on scanners will yield false positives and a limited-scope view of the problems present in the system. Vulnerabilities have been found in every major operating system including Windows, Mac OS, various forms of Unix and Linux, OpenVMS, and others. The only way to reduce the chance of a vulnerability being used against a system is through constant vigilance, including careful system maintenance (e.g. applying software patches), best practices in deployment (e.g. the use of firewalls and access controls) and auditing (both during development and throughout the deployment lifecycle). Examples of vulnerabilities Common types of vulnerabilities include: Memory safety violations, such as: o Buffer overflows o Dangling pointers Input validation errors, such as: o Format string bugs o Improperly handling shell metacharacters so they are interpreted o SQL injection o Code injection o E-mail injection o Directory traversal o Cross-site scripting in web applications Race conditions, such as:

o Time-of-check-to-time-of-use bugs o Symlink races Privilege-confusion bugs, such as: o Cross-site request forgery in web applications Privilege escalation User interface failures, such as: o Warning fatigue [2] or user conditioning [3] o Blaming the Victim Prompting a user to make a security decision without giving the user enough information to answer it [4] o Race Conditions [5]

Common Vulnerabilities and Exposures Common Vulnerabilities and Exposures, or CVE, is a dictionary of publicly-known information security vulnerabilities and exposures. This dictionary is maintained by MITRE Corporation, and is funded by the National Cyber Security Division of the United States Department of Homeland Security.[1] CVE Identifiers As per [1], CVE Identifiers (also called "CVE names," "CVE numbers," "CVE-IDs," and "CVEs") are unique, common identifiers for publicly known information security vulnerabilities. CVE identifiers and be either in "entry" or "candidate" status. Entry status indicates that the CVE Identifier has been accepted to the CVE List while candidate status (also called "candidates," "candidate numbers," or "CANs") indicates that the identifier is under review for inclusion in the list. The same source describes the process of creating a CVE Identifier which begins with the discovery of a potential security vulnerability or exposure to this information is then assigned a (unique) CVE candidate number by a CVE Candidate Numbering Authority (CNA), posted on the CVE Web site, and proposed to the Board by the CVE Editor

The MITRE Corporation functions as Editor and Primary CNA. The CVE Editorial Board (created by MITRE) discusses the candidate and votes on whether or not it should become a CVE entry. If the candidate is rejected, the reason for rejection is noted in the Editorial Board Archives posted on the CVE Web site. If the candidate is accepted, its status is updated to "entry" on the CVE List. However, the assignment of a candidate number is not a guarantee that it will become an official CVE entry. It is best to acquire a CAN number early in its investigation. An entry is live once a number is assigned, however until the go-public date is reached, the CAN number's entry will not provide any information. It will instead show a placeholder to indicate the number is taken. The benefit to early CVE candidacy is that all future correspondence can refer to the CAN/CVE number.[2] Common Vulnerability Scoring System (CVSS) is an industry standard for assessing the severity of computer system security vulnerabilities. It attempts to establish a measure of how much concern a vulnerability warrants, compared to other vulnerabilities, so efforts can be prioritized. The score is based on a series of measurements (called metrics) based on expert assessment. Metrics

The CVSS assessment measures three areas of concern: 1. Base Metrics for qualities intrinsic to a vulnerability. 2. Temporal Metrics for characteristics that evolve over the lifetime of vulnerability. 3. Environmental Metrics for characteristics of a vulnerability that depend on a particular implementation or environment. Base Metrics 1. Is the vulnerability exploitable remotely (as opposed to only locally). 2. How complex must an attack be to exploit the vulnerability? 3. Is authentication required to attack? 4. Does the vulnerability expose confidential data? 5. Can attacking the vulnerability damage the integrity of the system? 6. Does it impact availability of the system? Temporal Metrics 1. How complex (or how long will it take) to exploit the vulnerability. 2. How hard (or how long) will it take to remediate the vulnerability. 3. How certain is the vulnerability's existence. Environmental Metrics

1. Potential to cause collateral damage.

2. How many systems (or how much of a system) does the vulnerability impact. 3. Security Requirement(CIA)

Important sites related to vulnerability 1. http://www.frsirt.com/english/ (French Security Incident Response Team) 2. http://www.securityfocus.com/bid 3. http://www.milw0rm.com/ 4. http://secunia.com/ 5. http://osvdb.org/ (Open Source Vulnerability Database) 6. http://secwatch.org/ 7. http://www.owasp.org/index.php/Category:Vulnerability (Open Web Application security Project) 8. http://cve.mitre.org/ (Common Vulnerability and Exposure) 9. http://www.wve.org/ (Wireless Vulnerability & Exploit) 10. http://www.cert.org/ 11. https://samate.nist.gov/index.php/Main_Page (Software Assurance Metrics And Tool Evaluation) 12. http://www.packetstormsecurity.org/ 13. http://www.mitre.org/ 14. http://www.securityfocus.com/vulnerabilities

Vulnerability assessment A vulnerability assessment is the process of identifying, quantifying, and prioritizing (or ranking) the vulnerabilities in a system. Examples of systems for which vulnerability assessments are performed for include, but are not limited to, nuclear power plants, information technology systems, energy supply systems, water supply systems, transportation systems, and communication systems. Vulnerability assessments can be conducted for small businesses to large regional infrastructures. Vulnerability assessment has many things in common with risk assessment. Assessments are typically performed according to the following steps: 1. 2. 3. 4. Cataloging assets and capabilities (resources) in a system. Assigning quantifiable value (or at least rank order) and importance to those resources Identifying the vulnerabilities or potential threats to each resource Mitigating or eliminating the most serious vulnerabilities for the most valuable resources

Open Vulnerability and Assessment Language Open Vulnerability and Assessment Language (OVAL) is an international, information security, community standard to promote open and publicly available security content, and to standardize the transfer of this information across the entire spectrum of security tools and services. OVAL includes a language used to encode system details, and an assortment of content repositories held throughout the community. The language standardizes the three main steps of the assessment process: representing configuration information of systems for testing; analyzing the system for the presence of the specified machine state (vulnerability, configuration, patch state, etc.); and reporting the results of this assessment. The repositories are collections of publicly available and open content that utilize the language. The OVAL community has developed three schemas written in Extensible Markup Language (XML) to serve as the framework and vocabulary of the OVAL Language. These schemas correspond to the three steps of the assessment process: an OVAL System Characteristics schema for representing system information, an OVAL Definition schema for expressing a specific machine state, and an OVAL Results schema for reporting the results of an assessment.

http://oval.mitre.org/ Vendor Security Advisory Cisco http://www.cisco.com/en/US/products/products_security_advisories_listing.html Microsoft http://www.microsoft.com/technet/security/current.aspx