Men in the Server Meet the Man in the Browser

1,876 views
1,650 views

Published on

SOURCE Barcelona 2011 - Amichai Shulman

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
1,876
On SlideShare
0
From Embeds
0
Number of Embeds
43
Actions
Shares
0
Downloads
64
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • I use “Men” to describe enterprise IT people.
  • Client side software is much more susceptible to “generic” attacks than server side. Less custom code Introduction of HTML 5.0 which takes a lot of plug-in functionality into browser code and new technologies that allow execution of native code in browser context are probably going to invoke a rise in browser code vulnerabilities- While the 10 IIS vulnerabilities are handled by professional IT staff, the 77 IE vulnerabilities are handled by my mother and my kids.
  • 2010 Figures collected from the webServer side vulnerabilities are handled by top IT people (I chose pictures of 2011 CIO of the year).Client side vulnerabilities are handled by my kids and their grandmother.
  • Mention my interview in CNN in November 2010Traditional methods such as AV updates, Search engine “warning signs” and consumer prudence are no longer a viable defense. This is not a technology issue but a human nature / skill issue.Mention the December 2010 press about Macy’s and Nordstrom being targeted. http://www.informationweek.com/news/security/attacks/showArticle.jhtml?articleID=228800040&cid=RSSfeed_IWK_AllExpansion into other domain is reflected also in VDBIRCounting on consumers to avoid detection is like counting on drivers to avoid car crashes (hint hint)
  • All these have an impact on the financial bottom line of organizations.
  • We learned to expect Seat belt, air bags, ABS, ESP, energy absorbing chassis and more
  • Attackers realized that it is easier to install an agent on the victim’s machine than to tap into communications channel in the InternetDiscuss the commonality of Zeus regardless of its age and tenure.
  • Today they defeat two factor authentication and anti-CSRF
  • Tamper the request to invoke a failed login Tamper the incoming page to include additional fields Intercept the outgoing response and send data to malicious server
  • http://www.ffiec.gov/press/pr062811.htmhttp://www.ffiec.gov/pdf/Auth-ITS-Final%206-22-11%20(FFIEC%20Formated).pdf
  • Men in the Server Meet the Man in the Browser

    1. 1. Men in the Server Meet the Man in the BrowserAmichai Shulman, CTO
    2. 2. Agenda Quick Introduction Motivation Problem Definition Shape Based Tests Content Based Tests Overall Solution Strategy Summary2
    3. 3. Introduction
    4. 4. Imperva Overview Our mission. Protect the data that drives business Our market segment. Enterprise Data Security Our global business. • Public Company, Founded in 2002; • Global operations; HQ in Redwood Shores, CA • 350+ employees • Customers in 50+ countries Our customers. 1,300+ direct; Thousands cloud-based • 4 of the top 5 global financial data service firms • 4 of the top 5 global telecommunications firms • 4 of the top 5 global computer hardware companies • 3 of the top 5 US commercial banks • 150+ government agencies and departments
    5. 5. Today’s PresenterAmichai Shulman – CTO Imperva Speaker at Industry Events + RSA, Sybase Techwave, Info Security UK, Black Hat Lecturer on Info Security + Technion - Israel Institute of Technology Former security consultant to banks & financial services firms Leads the Application Defense Center (ADC) + Discovered over 20 commercial application vulnerabilities – Credited by Oracle, MS-SQL, IBM and others Amichai Shulman one of InfoWorld’s “Top 25 CTOs”
    6. 6. Motivation
    7. 7. Client Side Attacks - Scope of Problem (1)Major Attack Vectors Browser code + On decline over past 3 years + Expected to rise over next 2 years Browser plug-ins (Java, Flash, PDF, Me dia Player etc.) OS libraries (graphics rendering)
    8. 8. Client Side Attacks - Scope of Problem (2) 2010 Vulnerability Figures Client side  Server side + 77 IE + Only 36 vulnerabilities vulnerabilites, 106 across IIS, Apache Firefox and Tomcat vulnerabilities, 188 Chrome vulnerabilities + 73 Adobe Flash, 9 Adobe Reader related vulnerabilities + 72 Various ActiveX related vulnerabilities8
    9. 9. Client Side Attacks - Scope of Problem (3)Malware Distribution Methods Drive-By-Download / Malvertizing Phishing, “Spear Phishing” Torrent and P2P Physical
    10. 10. Client Side Attacks - Scope of Problem (4)2009 / 2010 Attack Figures A 2010 report by Kaspersky + ~600M attempts reported to KSN, more than 5 times increase over 2009 Number of Zeus infected computers estimated at 10M Rustock spanned 1M computers 40K new infections a day (with some being cleaned up) Consumers cannot be expected to cope with the technical problem on their own
    11. 11. From Consumer Attack to a Business Problem The threat to consumers is constantly growing + Number of vulnerabilities + Number of attacks + Types of attacks + Sophistication Usage is expanding beyond banking and popular retail applications We are passed the point of no return + Cannot expect average consumers to avoid infection and mitigate attacks alone + We cannot deny service to infected consumers + We cannot let the consumer bear the consequences of a compromise
    12. 12. From Consumer Attack to a Business Problem Potential consequences (of failing to do so): + Reduced on boarding rate + Reduced activity + Increased refunds + Increased insurance rates Consumer facing malware threatens online commerce* Forrester Feb 2011: Malware And Trojans And Bots, Oh My!
    13. 13. From Consumer Attack to a Business Problem Car User Safety  Online User Safety
    14. 14. Problem Definition
    15. 15. Client Side Trouble – Types of Interaction Key loggers + No interaction between malware and application + Offline interaction between attacker and application using stolen credentials Phishing + Some interaction between browser and actual application during attack – Could be used for detection of some Phishing campaigns + Offline interaction between attacker and application using stolen credentials Man in the Browser + Extensive interaction between malware and application during attack + Offline interaction between attacker and application using stolen credentials
    16. 16. Man in the Browser Attacks Attacker code running in context of victim’s browser AKA Proxy Trojan Original motivation + No need to attack infrastructure (DNS, tap into router, etc.) + Defeat SSL Additional benefits + Access to local resources + Access to application session data Prominent Actors + ZeuS, Gozi, URLZone, Sinowal, Limbo and SpyEye + Silentbanker16
    17. 17. MitB Attacks - The Evolution of Proxy Trojans Key Record Inject Manipulate logger HTML HTML and inject data elements transactions17
    18. 18. MitB Attacks - Proxy Trojans in Action Before After18
    19. 19. MitB Attacks - Proxy Trojans in Action Before After19
    20. 20. MitB Attacks - Proxy Trojans in Action Before After20
    21. 21. MitB Attacks - Proxy Trojans in Action Before After21
    22. 22. MitB Attacks - Proxy Trojans in Action Before After22
    23. 23. Proxy Trojan Architecture Web Application Client Machine23
    24. 24. Proxy Trojan Architecture Drop Server Inject Fake Transaction Extract Data Tamper Page Web Application Client Machine Tamper Request24
    25. 25. Shape Based Tests
    26. 26. An Observation Clean  Infected Trojan Likes to Tamper Plain Traffic
    27. 27. Typical Changes by Trojan Encoding related headers + Enforce use of traffic that is easily tampered by the Trojan + Avoid HTTP/1.1 connections, compressed data Client type identification + Ensure identification by drop server and other attacker controlled components Additional parameters + Extra data provided by an unfortunate victim + Could represent client identification for attacker controlled components Parameter order + Expected from fake transactions27
    28. 28. Shape Based Tests The application (or a device protecting the application) inspects the shape of incoming messages for changes typical to Trojans If a Trojan pattern is detect mark the client (IP address / session / request) as “infected”28
    29. 29. Shape Based Tests in Action Drop Server Apply Shape Tests Inject Fake Transaction Extract Data Tamper Page Web Application Client Machine Apply Shape Tests Tamper Request29
    30. 30. Challenges – Tracking Trojan Discrepancies Each Trojan may  Need to keep track of display a different Trojans change  Create a framework Changes may be for shape based rules reflected in specific  Create a framework request types for constructing shape tests30
    31. 31. Challenges – Avoiding False Positives Some real client HTTP/1.1 200 OK . devices do not . . support (or choose Content-Encoding: gzip not to support) Refresh: 2;url=infection_test.html?infected=no HTTP/1.1 or <html> ...........V*//W...Qzi...I...z...J:`.......T$......d.y.%@.^f.R,...( <head> ..y.:.J....9.V......%%...JV.J~.a...!..~@.Dqbkc...%6.... compressed data <script>window.navigate(infection_test.html?inf ected=yes)</script> Engage the browser </head> <body></body> in a challenge </html> response protocol31
    32. 32. Content Based Tests
    33. 33. Content Based Tests Current malware tampers HTML at the network layer (before it is interpreted by browser) + This is due to simplicity and robustness considerations Use client side code to verify integrity of HTML page content in coordination with the server Some solutions try to “provoke” the MitB into making changes. Then compare the HTML content to known Trojan behaviors + This can be avoided by careful configuration of the MitB + Requires constant chase after MitB configuration files – Construct an up-to-date database of “known behaviors”
    34. 34. Client / Server Content Verification Server computes a digest of the delivered HTML page + Random (invisible) elements are injected into the page before computation Server appends a page digest computation function to the HTML page + Computation function code includes a random salt When page is loaded into the browser, the computation function is invoked, computes the digest and sends it to the server for verification If the browser does not send back a digest then infection is assumed34
    35. 35. Content Based Tests in Action Drop Server Compute Digest and Inject Digest Computation Function Inject Fake Transaction Extract Data Tamper Page Web Application Client Machine Compare Digests Tamper Request Compute Digest35
    36. 36. Model Strengths (1) Digest cannot be pre-computed by malware due to the random HTML elements Digest cannot be computed by malware without executing the digest computation function + Requires malware to implement / invoke Javascript engine Computation function can be extended to explicitly reference the randomly injected HTML elements through DOM functions + Requires the malware to implement / fake DOM Malware cannot dismiss test36
    37. 37. Model Strengths (2) Does not depend on specific MitB configuration and the expected changes + Only depends on protected application page + Some configuration options should be available to restrict the parts of the page that are digested – Avoid elements produced by client side code Breaking the tie with attackers + Complexity of the computation process can be increased with small effort + Resulting changes to malware code are complex and painful, increasing its footprint37
    38. 38. Overall Solution Strategy
    39. 39. Look at the Complete Picture Apply shape based tests and content based tests to identify infected client devices Interact with Infected Clients + Provide clear visual warnings + Contact customer offline + Apply business access policies – Example 1: Allow data extraction but deny transaction – Example 2: Limit transaction size + Automatically employ extra validation through side channels – Adaptive authentication + Keep a more comprehensive audit trail for the user / session
    40. 40. MitB is Only Part of the Landscape Identifying account takeover + Server side fraud detection + Device profiling and reputation + Advanced authentication Defeat Phishing Campaigns + Detect and takedown campaigns + Detect victims in real time40
    41. 41. Flexible Deployment Framework Cannot change application code whenever capabilities change or threats morph Be able to protect legacy applications Create consistency across all applications and flexibility in choosing vendors41
    42. 42. Summary
    43. 43. Summary Threat to consumer is constantly growing and is past the point where we can expect most of our consumers to avoid infection Consumer infection has become a business problem While providers should urge consumers to be prudent they MUST learn how to interact with infected Some car safety mechanisms are consumers and create a safe business environment for them regardless of the general threat already regulated. We can expect the same from business IT security
    44. 44. Summary (cont.) Enterprise IT is failing to properly tackle client based attacks within enterprise The growing number of so called “APT” attacks on organizations demonstrate the effect of “compromised insider” Failures stem from the same reason: try to avoid infection rather than learn to interact with infected clients44
    45. 45. Questions- CONFIDENTIAL -
    46. 46. Thank You- CONFIDENTIAL -

    ×