The document discusses the threat posed by known vulnerabilities in web applications, emphasizing that while zero-day exploits receive significant attention, known vulnerabilities are frequently exploited due to their prevalence and the ease of access to exploit codes. It outlines the anatomy of attacks targeting both specific and multiple victims, revealing the importance of understanding the vulnerability lifecycle and implementing robust security measures. Recommendations include proactive monitoring, third-party code assessments, and virtual patching to mitigate risks from existing vulnerabilities.

1. Hiding in Plain Sight – The Danger of
Known Vulnerabilities
Tal Be’ery, Web Security Research Team Leader
1
© 2013 Imperva, Inc. All rights reserved.
Confidential

2. Agenda
§ 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
2
© 2013 Imperva, Inc. All rights reserved.
Confidential

3. HII Reports
§ 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
3
© 2013 Imperva, Inc. All rights reserved.
Confidential

4. 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
© 2013 Imperva, Inc. All rights reserved.

5. Introduction
5
© 2013 Imperva, Inc. All rights reserved.
Confidential

6. The Known Knowns
§ 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
6
© 2013 Imperva, Inc. All rights reserved.
Confidential

7. Security’s Knowns and Unknowns Defined
§ 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-A9Using_Components_with_Known_Vulnerabilities)
7
© 2013 Imperva, Inc. All rights reserved.
Confidential

8. CVE: Managing Known Vulnerabilities
§ 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)
8
© 2013 Imperva, Inc. All rights reserved.
Confidential

9. “Hollywood Style”: Web Site Hacking
Single Site Attack
Hacking
1. Identify Target
2. Research Vulnerability
3. Exploit
https://depot.gdnet.org/cms/gallery//25-iStock_000004333554Medium.jpg
9
© 2013 Imperva, Inc. All rights reserved.
Confidential

10. Reality Check: Research Does Not Scale!
Multiple Site Attacks
Hacking
1.
2.
3.
Identify Target
Research Vulnerability
Exploit
Hacking
1.
2.
3.
Identify Target
Research Vulnerability
Exploit
Hacking
1.
2.
3.
Identify Target
Research Vulnerability
Exploit
Hacking
1.
2.
3.
Identify Target
Research Vulnerability
Exploit
Hacking
1.
2.
3.
10
© 2013 Imperva, Inc. All rights reserved.
Identify Target
Research Vulnerability
Exploit
Confidential

11. Reality Check: Known Exploits Scale!
Multiple Site Attacks
Hacking
1.
2.
3.
Identify Infrastructure
Find Existing Exploit
Exploit
Hacking
1.
2.
3.
Identify Infrastructure
Find Existing Exploit
Exploit
Hacking
1.
2.
3.
Identify Infrastructure
Find Existing Exploit
Exploit
Hacking
1.
2.
3.
Identify Infrastructure
Find Existing Exploit
Exploit
Hacking
1.
2.
3.
11
© 2013 Imperva, Inc. All rights reserved.
Identify Infrastructure
Find Existing Exploit
Exploit
Confidential

12. Zero-Days Vs. Known Vulnerabilities
§ 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 costeffective method to exploit applications
http://faildesk.net/wp-content/uploads/2012/02/movie-hacking-vs.-real-hacking.gif
12
© 2013 Imperva, Inc. All rights reserved.
Confidential

13. Vulnerability Lifecycle in Reality
13
© 2013 Imperva, Inc. All rights reserved.
Confidential

14. Why is Known Vulnerability Exploitation so
Successful?
§ 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
14
© 2013 Imperva, Inc. All rights reserved.
Confidential

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
15
© 2013 Imperva, Inc. All rights reserved.
Confidential

16. Known Vulnerabilities Disclosure Increases
§ CVE IDs Enumeration syntax was changed to track more
than 10,000 vulnerabilities in a single year, starting on
2014.
16
© 2013 Imperva, Inc. All rights reserved.
Confidential

17. Exploits Are Publicly Available
§ Exploit-DB: http://www.exploit-db.com/
17
© 2013 Imperva, Inc. All rights reserved.
Confidential

18. OWASP Top 10 – 2013 Update
New, A9 - Using Known Vulnerable Components
18
© 2013 Imperva, Inc. All rights reserved.
Confidential

19. The Anatomy of a Known Vulnerability
Web attack
Attacking a Specific Victim
19
© 2013 Imperva, Inc. All rights reserved.
Confidential

20. Attacking a Specific Application: Theory
§ 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
20
© 2013 Imperva, Inc. All rights reserved.
Confidential

21. The Art of Fingerprinting
Identify a fingerprint in victim application
A fingerprint can be
• Image
• URL
• Content
• Object Reference
• Response to a query
• Etc.
21
© 2013 Imperva, Inc. All rights reserved.
Confidential

22. Fingerprinting Example 1: Content Based
The code will usually contain fingerprints of the infrastructure in
use.
22
© 2013 Imperva, Inc. All rights reserved.
Confidential

23. Fingerprinting Example 2: URL Based
An administrator interface may be front facing, allowing detection
and login attempts.
23
© 2013 Imperva, Inc. All rights reserved.
Confidential

24. Test Case: corporatecaronline.com Hack
http://krebsonsecurity.com/2013/11/hackers-take-limo-service-firm-for-a-ride/
24
© 2013 Imperva, Inc. All rights reserved.
Confidential

25. Fingerprinting corporatecaronline.com
§ The application is using CFM files
§ What’s a CFM file?
25
© 2013 Imperva, Inc. All rights reserved.
Confidential

26. Known Vulnerability for ColdFusion
§ CVE-2013-0632
§ Reported on January 2013
§ A “perfect 10” risk score
26
© 2013 Imperva, Inc. All rights reserved.
Confidential

27. Public Exploit for CVE-2013-0632
http://downloads.securityfocus.com/vulnerabilities/exploits/57164.rb
27
© 2013 Imperva, Inc. All rights reserved.
Confidential

28. ColdFusion Attacks in the Wild
§ Data collected on October 2013
§ More than 4,000 attacks
§ Attacking various resources within the CFIDE directory
28
© 2013 Imperva, Inc. All rights reserved.
Confidential

29. The Anatomy of a Known Vulnerability
Web attack
Mass Hacking
29
© 2013 Imperva, Inc. All rights reserved.
Confidential

30. Mass Hacking: Theory
§ 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
30
© 2013 Imperva, Inc. All rights reserved.
Confidential

31. Mass Hacking - Finding a Vulnerability
Find a vulnerability in an infrastructure
Source: www.exploit-db.com
Public vulnerability databases contain thousands of web
related exploits
31
© 2013 Imperva, Inc. All rights reserved.
Confidential

32. Google Dork for the Masses
§ Query: inurl:(wp-config.conf | wp-config.txt) ext:(conf | txt | config)
§ Results: 144,000
32
© 2013 Imperva, Inc. All rights reserved.
Confidential

33. Test Case: JBoss Based Hack
§ An open source application server
http://www.jboss.org/jbossas
33
© 2013 Imperva, Inc. All rights reserved.
Confidential

34. Known Vulnerability for JBoss
§ Presented during the OWASP Bay Area Chapter Meeting
in November 2011
http://www.matasano.com/research/OWASP3011_Luca.pdf
34
© 2013 Imperva, Inc. All rights reserved.
Confidential

35. Exploit for the Known Vulnerability
§ Exploit was publicly published on September 2013
http://www.exploit-db.com/exploits/28713/
35
© 2013 Imperva, Inc. All rights reserved.
Confidential

36. Google Dorking for Vulnerable JBoss
§ In 2011: 7,370 results
§ In 2013: 23,100 results
36
© 2013 Imperva, Inc. All rights reserved.
Confidential

37. Hackers Apply the Attack
§ 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
37
© 2013 Imperva, Inc. All rights reserved.
Confidential

38. Summary & Conclusion
38
© 2013 Imperva, Inc. All rights reserved.
Confidential

39. Vendor’s Patches Are Not Enough (1)
§ 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
39
© 2013 Imperva, Inc. All rights reserved.
Confidential

40. Vendor’s Patches Are Not Enough (2)
§ Patch installation requires testing before deploying
• Patch may be problematic
• Patch may break custom functionality
40
© 2013 Imperva, Inc. All rights reserved.
Confidential

41. Recommendations
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
41
© 2013 Imperva, Inc. All rights reserved.
Confidential

42. Technical Recommendations
§ 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
42
© 2013 Imperva, Inc. All rights reserved.
Confidential

43. Virtual Patching Check List
§ 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
43
© 2013 Imperva, Inc. All rights reserved.
Confidential

44. www.imperva.com
44
© 2013 Imperva, Inc. All rights reserved.
Confidential