Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to Stop Man in the Browser Attacks


Published on

Fraud is a key--and evolving--challenge facing security teams today. This presentations highlight tactics organizations can deploy to dramatically reduce incidents of fraud, provides a high-level, technical overview of client-side attacks and demonstrates how man-in-the-browser attacks operate, reveals two techniques that can be used by a Web application to detect infected clients, and discusses practical aspects of implementing these two methods and how to use the output of the detection process in the application.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

How to Stop Man in the Browser Attacks

  1. 1. Stopping Fraud –Getting Rid of the Man in Your BrowserRob Rachwald, Director of Security StrategyNoa Bar-Yosef, Sr. Security Strategist
  2. 2. Agenda Motivation Problem Definition Shape Based Tests Content Based Tests Overall Solution Strategy Summary
  3. 3. Today’s PresenterRob Rachwald, Dir. of Security Strategy, Imperva Research + Directs security strategy + Works with the Imperva Application Defense Center Security experience + Fortify Software and Coverity + Helped secure Intel’s supply chain software + Extensive international experience in Japan, China, France, and Australia Thought leadership + Presented at RSA, InfoSec, OWASP, ISACA + Appearances on CNN, SkyNews, BBC, NY Times, and USA Today Graduated from University of California, Berkeley
  4. 4. Today’s PresenterNoa Bar-Yosef, Senior Security Strategist, Imperva Research + Researches trends in the threat landscape Security experience + Previously, held the position of Sr. Security Researcher for Imperva’s Application Defense Center + Credited for multiple commercial applications’ vulnerabilities + Holds a Master’s thesis specializing in Information Security Thought leadership + Writes a bi-weekly column on hacker trends and techniques for SecurityWeek
  5. 5. Motivation
  6. 6. Client Side Attacks - Scope of ProblemMajor Attack Vectors
  7. 7. Client Side Attacks - Scope of ProblemMajor Attack Vectors Exploiting Browser Code Vulnerabilities • Expected to rise with the introduction of HTML5 Exploiting Browser Plug-ins • E.g. Java, Flash, PDF, Media Player Exploiting OS libraries • E.g. Graphics rendering
  8. 8. Client Side Attacks - Scope of Problem2010 Vulnerability Figures Client side Server side• 77 IE vulnerabilities, • Only 36 vulnerabilities 106 Firefox across IIS, Apache vulnerabilities, 188 and Tomcat Chrome vulnerabilities• 73 Adobe Flash, 9 Adobe Reader related vulnerabilities• 72 Various ActiveX related vulnerabilities
  9. 9. Client Side Attacks - Scope of ProblemMalware Distribution Methods Drive-By-Download / Malvertizing Phishing, “Spear Phishing” Torrent and P2P Physical
  10. 10. Client Side Attacks - Scope of Problem2010 Attack Figures A 2010 report by Kaspersky + ~600M attempts reported to KSN, more than 5 times increase over 2009 Microsoft detects 60K-100K Zeus-infected machine per month 2010 1H – Microsoft cleaned 6.5M bot infections Rustock spanned 1M computers 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 We are passed the point •Types of attacks of no return •Sophistication • We 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 Usage is expanding beyond banking and popular retail applications
  12. 12. From Consumer Attack to a Business Problem Potential consequences (of failing to do so): + Reduced onboarding 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 ProblemCar User Safety Online User Safety
  14. 14. Problem Definition
  15. 15. Client Side Trouble – Types of Interaction Key • No interaction between malware and application loggers • Offline interaction between attacker and application using stolen credentials
  16. 16. Client Side Trouble – Types of Interaction • Some interaction between browser and actual application during attack Phishing • Could be used for detection of some Phishing campaigns • Offline interaction between attacker and application using stolen credentials
  17. 17. Client Side Trouble – Types of Interaction Man in • Extensive interaction between malware the and application during attack • Offline interaction between attacker Browser and application using stolen credentials
  18. 18. Man in the Browser Attacks (aka Proxy Trojan) Attacker code runs in context of victim’s browser Original motivation + No need to attack infrastructure (DNS, tap into router, etc.) + Defeats SSL Additional benefits + Access to local resources + Access to application session data Prominent Actors + ZeuS, Gozi, URLZone, Sinowal, Limbo, and SpyEye + Silentbanker
  19. 19. MitB Attacks - Proxy Trojans in Action Before After
  20. 20. MitB Attacks - Proxy Trojans in Action Before After
  21. 21. MitB Attacks - Proxy Trojans in Action Before After
  22. 22. Proxy Trojan Architecture Web Application Client Machine
  23. 23. Proxy Trojan Architecture Drop Server Inject Fake Transaction Extract Data Tamper Page Web Application Client Machine Tamper Request
  24. 24. Shape Based Tests
  25. 25. A Typical Change by a TrojanClean Infected Observation: Trojan likes to tamper with plain traffic
  26. 26. Observing Typical Changes by Trojans Encoding of • Enforces use of traffic that is easily tampered by the TrojanRelated Headers • Avoids HTTP/1.1 connections, and compressed data Client Type • Ensures identification by the drop server and other Identification attacker controlled components Additional • Extra data provided by an unfortunate victim • Could represent client identification for attacker Parameters controlled componentsParameter Order • A consequence of fake transactions
  27. 27. Shape Based Tests Step 1: • The application (or a device protecting the application) inspects the shape of incoming messages for changes typical to Trojans Step 2: • If a Trojan pattern is detected mark the client (IP address / session / request) as “infected”
  28. 28. 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 Request
  29. 29. Challenges – Tracking Trojan Discrepancies• Each Trojan may • Need to keepdisplay a different track of Trojanschange • Create a• Changes may be framework forreflected in shape based rulesspecific request • Create atypes framework for constructing shape tests
  30. 30. Challenges – Avoiding False Positives Challenge: • Some real client devices do not support (or choose not to support) HTTP/1.1 or compressed data Solution: • Engage the browser in a challenge response protocol
  31. 31. Challenges – Avoiding False PositivesHTTP/1.1 200 OK...Content-Encoding: gzipRefresh: 2;url=infection_test.html?infected=no<html>...........V*//W...Qzi...I...z...J:`.......T$......d.y.%@.^f.R,...(..y.:.J....9.V......%%...JV.J~.a...!..~@.Dqbkc...%6....<head><script>window.navigate(infection_test.html?infected=yes)</script></head><body></body></html>
  32. 32. Content Based Tests
  33. 33. Observing Content-Tampering Trojans Observation: • Current malware tampers HTML at the network layer (before it is interpreted by browser) • This is due to simplicity and robustness considerations Solution: • Use client side code to verify integrity of HTML page content in coordination with the server
  34. 34. OK Solution: Altering the Trojan Behavior Naïve Solution • Step 1: “Provoke” the MitB into making changes • Step 2: Compare the HTML content to known Trojan behaviors Challenges • MitB can be configured to avoid this type of manipulation • Solution requires constant chase after MitB configuration files  Requires constructing an up-to-date database of “known behaviors”
  35. 35. Better Solution: Content-Based Tests Step 1: • Server computes a digest of the delivered HTML page Random (invisible) elements are injected into the page before computation Step 2: • Server appends a page digest computation function to the HTML page Computation function code includes a random salt Step 3: • When page is loaded into the browser, the computation function is invoked, computes the digest and sends it to the server for verification Step 4: • If the browser does not send back a digest then infection is assumed
  36. 36. 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 Digest
  37. 37. Content-Based Tests: Strengths1) Digest cannot be pre-computed by malware due to the random HTML elements2) Digest cannot be computed by malware without executing the digest computation function + Requires malware to implement / invoke Javascript engine3) Computation function can be extended to explicitly reference the randomly injected HTML elements through DOM functions + Requires the malware to implement / fake DOM4) Malware cannot dismiss test
  38. 38. Content-Based Tests: Strengths5) 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 code6) 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 footprint
  39. 39. Overall Solution Strategy
  40. 40. Look at the Complete PictureApply shape based … And content-based tests… tests
  41. 41. Interact with Infected ClientsProvide clear visual warningsContact customer offlineApply business access policies • Example 1: Allow data extraction but deny transaction • Example 2: Limit transaction sizeAutomatically employ extra validation through side channels • Adaptive authenticationKeep a more comprehensive audit trail for the user / session
  42. 42. 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 time
  43. 43. Requires a 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 vendors
  44. 44. Summary
  45. 45. 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
  46. 46. Summary 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 clients
  47. 47. Imperva’s Fraud Solution
  48. 48. SecureSphere 9.0 - Fraud Prevention Services SecureSphere integrates with Trusteer to detect users infected with malware like SpyEye, Zeus, Gozi & Silon 1. User accesses Website 2. SecureSphere redirects browser to Trusteer 3. Browser downloads, runs malware check 4. Result reaches WAF for analysis Is this endpoint safe? Pass / Block
  49. 49. Use Case: Man in the Browser – Fraud Malware Challenge + Fraud malware performing activities on behalf of customers, causing money losses & customers dissatisfaction + FFIEC compliance requirements Solution + Detect infected end-devices + Block sensitive areas in the application from infected devices + Report on users connected from infected end-devices49
  50. 50. ThreatRadar Fraud Prevention Stopping MitB SecureSphere provides full event detail to analyze Man in the Browser (MitB) attacks
  51. 51. Centrally Manage Fraud and Web Security Known Attack Sources User Infected with Malware Geolocation SecureSphere Policy Engine User Name Browser and Agent Web Attack Detection Bot Detection  Combining Web fraud with WAF policies enhances accuracy of fraud detection
  52. 52. Webinar Materials Get LinkedIn to Imperva Data Security Direct for… Answers to Post-Webinar Attendee Discussions Questions Webinar Webinar Slides Recording Link
  53. 53. CONFIDENTIAL -