hiding in plain sight: the danger of known vulnerabilities

© 2013 Imperva, Inc. All rights reserved.

Hiding in Plain Sight – The Danger of Known Vulnerabilities

Confidential 1

Tal Be’ery, Web Security Research Team Leader


Agenda

Confidential 2

§  Introduction •  Zero-days Vs. Known vulnerabilities

§  The anatomy of a known vulnerability web attack: Attacking a specific victim •  Theory •  Test case analysis: A vulnerable ColdFusion application

§  The anatomy of a known vulnerability web attack: Mass attacks •  Theory •  Test case analysis: Abusing JBOSS

§ Summary & conclusion § Q&A


HII Reports

Confidential 3

§ Hacker Intelligence Initiative (HII) is focused at understanding how attackers are operating in practice •  A different approach from vulnerability research

§ Data set composition •  ~60 real world applications •  Anonymous proxies

§ More than 24 months of data § Powerful analysis system

•  Combines analytic tools with drill down capabilities


Tal Be’ery,Web Research Team Leader

§ Web Security Research Team Leader at Imperva

§ Holds MSc & BSc degree in CS/EE from TAU

§  10+ years of experience in IS domain §  Facebook “white hat” § Speaker at RSA, BlackHat, AusCERT § Columnist for securityweek.com § CISSP

4


Introduction

Confidential 5


The Known Knowns

Confidential 6

§  There are known knowns; these are things we know that we know.

§  There are known unknowns; that is to say, there are things that we now know we don't know.

§ But there are also unknown unknowns – there are things we do not know we don't know.

-- Donald Rumsfeld, U.S. Secretary of Defense, February 2002


Security’s Knowns and Unknowns Defined

Confidential 7

§ Unknown Unkowns: Zero-Days A zero-day attack is an attack that exploits a previously unknown vulnerability in a computer application, meaning that the attack occurs on "day zero" of awareness of the vulnerability (Wikipedia http://en.wikipedia.org/wiki/Zero-day_attack)

§ Known Knowns: Known vulnerabilities Vulnerable components (e.g., framework libraries) can be identified and exploited (OWASP https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities)


CVE: Managing Known Vulnerabilities

Confidential 8

§ Known vulnerabilities are assigned with a CVE (Common Vulnerabilities and Exposures) ID

§  “CVE’s common identifiers make it easier to share data across separate network security databases and tools, and provide a baseline for evaluating the coverage of an organization’s security tools”

(MITRE http://cve.mitre.org/about/index.html)


“Hollywood Style”: Web Site Hacking

Confidential 9

Hacking 1.  Identify Target 2.  Research Vulnerability 3.  Exploit

Single Site Attack

https://depot.gdnet.org/cms/gallery//25-iStock_000004333554Medium.jpg


Reality Check: Research Does Not Scale!

Confidential 10

Hacking

1.  Identify Target 2.  Research Vulnerability 3.  Exploit

Hacking


Hacking


Hacking


Hacking


Multiple Site Attacks


Reality Check: Known Exploits Scale!

Confidential 11

Hacking

1.  Identify Infrastructure 2.  Find Existing Exploit 3.  Exploit

Hacking


Hacking


Hacking


Hacking


Multiple Site Attacks


Zero-Days Vs. Known Vulnerabilities

Confidential 12

§  Zero-Days get all the glory •  Technically interesting •  Give rise to some interesting theoretical

questions: How to defend the “unkown unkowns?”

§ But known vulnerabilities are doing a lot of the damage •  Provide hackers with a very cost-

effective method to exploit applications

http://faildesk.net/wp-content/uploads/2012/02/movie-hacking-vs.-real-hacking.gif


Vulnerability Lifecycle in Reality

Confidential 13


Why is Known Vulnerability Exploitation so Successful?

Confidential 14

§ Applications are based mostly on 3rd party code § Web applications are no different

•  HTTP Server, Application Server, Plugins, Libraries, etc.

§ Code re-use equals vulnerability re-use § Exploits’ code is available for known vulnerabilities

© 2013 Imperva, Inc. All rights reserved. 15

3rd Party Code Provides a Rich Attack Surface

According to Veracode: •  Up to 70% of internally developed code originates outside of the

development team •  28% of assessed applications are identified as created by a 3rd

party

Confidential


Known Vulnerabilities Disclosure Increases

Confidential 16

§ CVE IDs Enumeration syntax was changed to track more than 10,000 vulnerabilities in a single year, starting on 2014.


Exploits Are Publicly Available

Confidential 17

§ Exploit-DB: http://www.exploit-db.com/

© 2013 Imperva, Inc. All rights reserved. 18

OWASP Top 10 – 2013 Update

New, A9 - Using Known Vulnerable Components

Confidential


The Anatomy of a Known Vulnerability Web attack

Confidential 19

Attacking a Specific Victim


Attacking a Specific Application: Theory

Confidential 20

§ Step 1: Fingerprinting of the victim application to discover third party components and infrastructure

§ Step 2: For the discovered components, find known vulnerabilities and exploits that gives the hacker the desired access level

§ Step 3: Apply the exploit to the victim’s application


The Art of Fingerprinting

Confidential 21

Identify a fingerprint in victim application

A fingerprint can be

•  Image

•  URL

•  Content

•  Object Reference

•  Response to a query

•  Etc.


Fingerprinting Example 1: Content Based

Confidential 22

The code will usually contain fingerprints of the infrastructure in use.


Fingerprinting Example 2: URL Based

Confidential 23

An administrator interface may be front facing, allowing detection and login attempts.


Test Case: corporatecaronline.com Hack

Confidential 24

http://krebsonsecurity.com/2013/11/hackers-take-limo-service-firm-for-a-ride/


Fingerprinting corporatecaronline.com

Confidential 25

§  The application is using CFM files

§ What’s a CFM file?


Known Vulnerability for ColdFusion

Confidential 26

§ CVE-2013-0632

§ Reported on January 2013 § A “perfect 10” risk score


Public Exploit for CVE-2013-0632

Confidential 27

http://downloads.securityfocus.com/vulnerabilities/exploits/57164.rb


ColdFusion Attacks in the Wild

Confidential 28

§ Data collected on October 2013 § More than 4,000 attacks § Attacking various resources within the CFIDE directory


The Anatomy of a Known Vulnerability Web attack

Confidential 29

Mass Hacking


Mass Hacking: Theory

Confidential 30

§ Step 1: Find a public exploit in an infrastructure •  Infrastructure is relevant to many application •  Exploit is “powerful”: usually full server takeover

§ Step 2: Create a search query to identify vulnerable applications in the web •  Often named “Google Dorks”

§ Step 3: Apply the exploit to all of the vulnerable applications


Mass Hacking - Finding a Vulnerability

Confidential 31

Source: www.exploit-db.com

Find a vulnerability in an infrastructure

Public vulnerability databases contain thousands of web related exploits


Google Dork for the Masses

Confidential 32

§  Query: inurl:(wp-config.conf | wp-config.txt) ext:(conf | txt | config) §  Results: 144,000


Test Case: JBoss Based Hack

Confidential 33

§ An open source application server

http://www.jboss.org/jbossas


Known Vulnerability for JBoss

Confidential 34

§ Presented during the OWASP Bay Area Chapter Meeting in November 2011

http://www.matasano.com/research/OWASP3011_Luca.pdf


Exploit for the Known Vulnerability

Confidential 35

§ Exploit was publicly published on September 2013

http://www.exploit-db.com/exploits/28713/


Google Dorking for Vulnerable JBoss

Confidential 36

§  In 2011: 7,370 results

§  In 2013: 23,100 results


Hackers Apply the Attack

Confidential 37

§ Many websites report on being hit by the attack resulting with “pwn.jsp” web shell deployed on the server

§ Allows the attacker to execute arbitrary OS commands


Summary & Conclusion

Confidential 38


Vendor’s Patches Are Not Enough (1)

Confidential 39

§ Security does not necessarily know all components § Security does not necessarily know all vulnerabilities for

components •  Not everything is reported as CVE

§ Vendor patches may not be available •  System reached End of Support (EoS) •  Open source product with no SLA


Vendor’s Patches Are Not Enough (2)

Confidential 40

§ Patch installation requires testing before deploying •  Patch may be problematic •  Patch may break custom functionality


When a company builds its security model it usually does not take into account elements that are not in control, which creates the security hole. Companies should: §  Implement policies both on the legal and technical

aspects to control data access and data usage §  Require third party applications to accept your security

policies and put proper controls in place §  Monitor the enforcement of these policies

Recommendations

41 Confidential 41


§  Assume third-party code – coming from partners, vendors, or mergers and acquisitions – contains serious vulnerabilities

§  Pen test before deployment to identify these issues §  Deploy the application behind a WAF to

•  Virtually patch pen test findings •  Mitigate new risks (unknown on the pen test time)

•  Mitigate issues the pen tester missed •  Use cloud WAF for remotely hosted applications

§  Apply vendor patches, when possible §  Virtually patch newly discovered CVEs

Technical Recommendations

42 Confidential 42


§  Virtually patch newly discovered CVEs

§  Requires a robust security update service •  Timely: Attackers are very quick to on board newly

discovered exploit into their hacking code •  Coverage: Cover all relevant vulnerabilities in the relevant

domain •  Accurate: Tested for false positives

•  Secured by default : §  Automatically loaded into the protecting system

§  No need to reboot

Virtual Patching Check List

43 Confidential 43


www.imperva.com

44 Confidential

hiding in plain sight: the danger of known vulnerabilities

Technology