web application defense, breaking the kill chain

Web Application Defense using CAPEC data. Jerome Athias of 9

Web Application Defense, Breaking the Kill Chain Advanced Web Defense using CAPEC data, Behavioral Analysis and Strategic Security Controls

Jerome Athias

DRAFT March 2014

Trademarks are property of their respective owners


Introduction Web Applications are subject to a large exposure, and so high risk of attacks (exploitation of vulnerabilities resulting of exposed weaknesses). A proper SDLC is mandatory, including Best Practices of Secure Web Development. https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet https://www.owasp.org/index.php/Secure_Coding_Principles https://www.cert.org/secure-‐coding/ https://www.owasp.org/index.php/Cheat_Sheets https://www.owasp.org/index.php/Security_Code_Review_in_the_SDLC This is part of a Secure Web Applications Strategy. http://www.opensamm.org Reducing the attack surface is a must for Web Application Security. https://www.owasp.org/index.php/Identify_attack_surface https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet http://websec.io/2013/01/28/Core-‐Concepts-‐Attack-‐Surface.html http://www.slideshare.net/OWASP_Ottawa/pierre-‐ernst-‐xml-‐attack-‐surface-‐owasp-‐ottawa http://publications.drdo.gov.in/ojs/index.php/dsj/article/view/1291 The Threat Modeling SDLC’s activity is a highly efficient process. http://en.wikipedia.org/wiki/Threat_model https://www.owasp.org/index.php/Application_Threat_Modeling https://www.owasp.org/images/7/79/AppSecEU09_OWASP_EU_Threat_Modeling.ppt http://imi.nku.edu/security/Powerpoints/Marco_Morana.pdf As part of all Information Security Management System (or in Risk Management), a selection of relevant and applicable Security Requirements has to be performed. e.g. OWASP ASVS https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project Based on the Security Requirements (Confidentiality, Integrity, Availability), appropriate and efficient Security Controls (see the Orange Book) must be used. The Security Controls (safeguards) must be selected correctly (ROI can play a role here), applied, checked and monitored efficiently. Methodologies exist for Secure Code Review and Web Application Security Assessment (Web Vulnerability Assessment, Web Application Penetration Testing). https://www.owasp.org/index.php/OWASP_Testing_Project http://www.isecom.org/research/osstmm.html Common Weaknesses (root cause of breaches) are now well defined. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project http://projects.webappsec.org/Threat-‐Classification https://cwe.mitre.org However, there is not too much available regarding an effective strategic methodology for technical security controls selection.


CAPEC™ A Common Attack Pattern Enumeration and Classification repository, managed by MITRE. http://capec.mitre.org CAPEC is directly mapped to CWE, WASC and OWASP Top 10, making it easy to use.

Attack Execution Flow Inside the various useful information of CAPEC, there is the Attack Execution Flow, described as progressive Attack Step Techniques.

One familiar with Threat Modeling could directly think about of mapping this to an Attack Tree or complement of a Data Flow Diagram. Going further, the dissection of the Attack Execution Flows described in CAPEC offer an opportunity for Intelligence-‐Driven Web Application Defense by Analysis of Adversary Tactics, Techniques and Procedures (TTP) and Intrusion Kill Chains. Reference: Intelligence-‐Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains, Lockheed Martin Corporation http://www.lockheedmartin.com/content/dam/lockheed/data/corporate/documents/LM-‐White-‐Paper-‐Intel-‐Driven-‐Defense.pdf


Kill Chain As part of Cyber defense strategy against Advanced Persistent Threats, an objective could be a Defensible Security Posture. http://nigesecurityguy.wordpress.com/2013/06/04/defensible-‐security-‐posture/ A kill chain defines the progressive steps of an attack. People familiar with forensics and incident response will easily understand the analogy between the Kill Chain and the Attack Execution Flow. In the context of Web Applications, a defensible actions matrix (technical security controls per attack step) could be defined using the CAPEC’s attack scenarios. The goal: breaking the kill chain in its earlier stages, by using appropriate countermeasures slowing down an attack. A top-‐down, or waterfall, approach could be used to perform a security controls selection and use of defensive programming techniques for proactive detection and mitigation of attacks. Following the defense-‐in-‐depth security principle, these mechanisms will help to extend the intrusion detection window. For the implementation, and prioritization, CAPEC offers also information about the Typical Likelihood of Exploit, the CIA Impact (Attack Motivation-‐Consequences). Furthermore, the Effectiveness and Cost of the security controls will be evaluated (tip: see the CWEs corresponding to a CAPEC entry). In terms of Threat Assessment/Analysis or Threat Intelligence, CAPEC is also interesting, for example providing information related to the Attacker Skills or Knowledge Required, which is interesting for the characterization of the Threat Actors and could be valuable for Computer Incident Response Teams. (e.g. using STIX http://stix.mitre.org/)


Strategy For effective detection and mitigation of the attack techniques, particular attention will be paid to the Probing Techniques listed in CAPEC. These can be mapped, for example, to the OWASP Testing Guide methodology for effective prioritization and maximizing the effectiveness of our defense strategy. Some of our defensive programmatic mechanisms will take this into account to perform a contextual and behavioral analysis, making them more intelligent and effective (less prone to false-‐positives), and could lead attackers to sinkholes or honeypots while generating alerts. This will be useful for continuous monitoring and situational awareness. Remark: the various CAPEC Indicators and Warning of Attacks are useful as Indicators of Compromise (IOC) Note: of course, as per the defense-‐in-‐depth principle, all the listed mechanisms must come with a defense of the perimeter, boundaries protected by a layered security such as at the network level.


CAPEC™ Data Usage CAPEC is not easily usable as is. To be more practical, we will perform a transformation of the CAPEC XML feed, by extraction, to a database. As part of the XORCISM project (eXpandable Open Research on Cyber Information Security Management), a tool is available to achieve this step. https://github.com/athiasjerome/XORCISM With CAPEC parsed and imported into an XORCISM database, it becomes more convenient to manipulate the data.

Checklist Using the Attack Steps in the form of a checklist is interesting and valuable. This could be used into a simple spreadsheet, or better using OCIL. Examples:

• For the definition of security requirements • For the development team self-‐assessment

Similarly to OWASP ASVS, the data will be turned into the question “Do you have proper security requirements/controls in place to prevent or mitigate the following attack steps?” Example: Selection of CAPEC Attack Step Techniques Fingerprinting of the operating system In order to create a valid file injection, the attacker

needs to know what the underlying OS is. Spider Using a browser or an automated tool, an attacker

follows all public links on a web site. He records all the entry points (input) that becomes part of generated HTTP header (not only GET/POST/COOKIE, but also Content-‐Type, etc.)

Forceful browsing When the attacker targets the current application or another one (through CSRF vulnerabilities), the user will then be the one who perform the attacks without being aware of it. These attacks are mostly targeting application logic flaws, but it can also be used to create a widespread attack against a particular website on the user's current network (Internet or not).

Attempt well-‐known or guessable resource locations

Using an automated tool, an attacker requests a variety of well-‐known URLs that correspond to administrative, debugging, or other useful internal actions. He records all the positive responses from the server.

Survey the Application to Identify User-‐controllable Inputs

The attacker surveys the target application to identify all user-‐controllable inputs, possibly as a valid and authenticated user

Probe identified potential entry points for XSS vulnerability

The attacker uses the entry points gathered in the "Explore" phase as a target list and injects various


common script payloads to determine if an entry point actually represents vulnerability and to characterize the extent to which the vulnerability can be exploited. He records all the responses from the server that include unmodified versions of his script. The attacker tries also to inject extra-‐parameter to the HTTP request to see if they are reflected back in the web page or in the HTTP response.

Attempt well-‐known or guessable resource locations

Using an automated tool, an attacker requests a variety of well-‐known URLs that correspond to administrative, debugging, or other useful internal actions. He records all the positive responses from the server.

View unauthorized data The attacker discovers and views unprotected sensitive data.

Vary inputs, looking for malicious results. Depending on whether the application being exploited is a remote or local one the attacker crafts the appropriate malicious input, containing OS commands, to be passed to the application

Execute malicious commands The attacker may steal information, install a back door access mechanism, elevate privileges or compromise the system in some other way.

Steal session IDs, credentials, page content, etc. As the attacker succeeds in exploiting the vulnerability, he can choose to steal user's credentials in order to reuse or to analyze them later on.

Determine Application's Log File Format The first step is exploratory meaning the attacker observes the system. The attacker looks for action and data that are likely to be logged. The attacker may be familiar with the log format of the system.

Manipulate Log Files The attacker alters the log contents either directly through manipulation or forging or indirectly through injection of specially crafted input that the target software will write to the logs. This type of attack typically follows another attack and is used to try to cover the traces of the previous attack.

Explore legitimate website and create duplicate An attacker creates a website (optionally at a URL that looks similar to the original URL) that closely resembles the website that he or she is trying to impersonate. That website will typically have a login form for the victim to put in their authentication credentials. There can be different variations on a theme here.

Convince user to enter sensitive information on attacker's site.

An attacker sends an e-‐mail to the victim that has some sort of a call to action to get the user to click on the link included in the e-‐mail (which takes the victim to attacker's website) and log in. The key is to get the victim to believe that the e-‐mail is coming from a legitimate entity with which the victim does business and that the website pointed


to by the URL in the e-‐mail is the legitimate website. A call to action will usually need to sound legitimate and urgent enough to prompt action from the user.

Use stolen credentials to log into legitimate site Once the attacker captures some sensitive information through phishing (login credentials, credit card information, etc.) the attacker can leverage this information. For instance, the attacker can use the victim's login credentials to log into their bank account and transfer money to an account of their choice.


Security Controls Starting from the list of Attack Steps, it becomes easy to think about them and defines security mechanisms at the Web Application level. Examples: Fingerprinting of the operating system Chances are high that this would be performed in the early stages of an attack. https://www.owasp.org/index.php/Fingerprint_Web_Server_%28OTG-‐INFO-‐002%29 Proper Configuration Management, with the use of Hardening Guidelines should prevent information leakage from the Web Application Framework, Web Server and Operating System. ! Firewall ACLs, limiting allowed HTTP methods, IDS/IPS detecting a port scan (nmap) https://benchmarks.cisecurity.org/downloads/benchmarks/ This is a basic and mandatory activity to reduce the attack surface. Spidering Attempt well-‐known or guessable resource locations A brute force enumeration of the web resources (i.e. pages) accessible into the web application is a common preliminary step of not well skilled attackers. Indicators would be:

• User agent of known tools (e.g. DirBuster, w3af, sqlmap) • Number of HTTP requests in a short period of time (eventually coming from the same IP

address) • Requests coming from a suspicious IP address range (IP Geolocation, use of a proxy, IP

reputation/blacklist) Implementing programmatic functions to analyze, detect, log, prevent, alert when these events occur is a relatively easy and inexpensive task. It represents cost effective defensive controls, even if the effectiveness is disputable. Probe identified potential entry points for XSS vulnerability Vary inputs, looking for malicious results. Execute malicious commands Common injection patterns could easily be detected (in the meantime they are blocked by whitelisting or blacklisting) at the application level, logged and reported. The Web Application could include self-‐defense mechanisms (e.g. fail2ban approach). Web Application Firewall rules could be improved, IP reputation database updated, firewall rules enhanced, defects identified, potential unknown vulnerabilities (0day) detected faster, etc. Explore legitimate website and create duplicate This is a common technique that is somehow detectable (for example by financial CERTs) by searching/monitoring the web for duplicated images or content. https://www.tineye.com/ Steal session IDs, credentials, page content, etc. A common outcome of databases leakage is for attackers to disclose the stolen information, for example on pastebin. As part of continuous monitoring and threat intelligence activities, APIs or tools could be used to help detecting such information disclosure. https://github.com/xme/pastemon https://en.mention.com/

web application defense, breaking the kill chain

Documents