Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Men in the Server Meet the Man in the Browser

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Próximo SlideShare
Man In The Browser
Man In The Browser
Cargando en…3
×

Eche un vistazo a continuación

1 de 46 Anuncio

Más Contenido Relacionado

Anuncio

Similares a Men in the Server Meet the Man in the Browser (20)

Más de Source Conference (20)

Anuncio

Más reciente (20)

Men in the Server Meet the Man in the Browser

  1. 1. Men in the Server Meet the Man in the Browser Amichai Shulman, CTO
  2. 2. Agenda  Quick Introduction  Motivation  Problem Definition  Shape Based Tests  Content Based Tests  Overall Solution Strategy  Summary 2
  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 Presenter Amichai 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 vulnerabilities 8
  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 + Silentbanker 16
  17. 17. MitB Attacks - The Evolution of Proxy Trojans Key Record Inject Manipulate logger HTML HTML and inject data elements transactions 17
  18. 18. MitB Attacks - Proxy Trojans in Action Before After 18
  19. 19. MitB Attacks - Proxy Trojans in Action Before After 19
  20. 20. MitB Attacks - Proxy Trojans in Action Before After 20
  21. 21. MitB Attacks - Proxy Trojans in Action Before After 21
  22. 22. MitB Attacks - Proxy Trojans in Action Before After 22
  23. 23. Proxy Trojan Architecture Web Application Client Machine 23
  24. 24. Proxy Trojan Architecture Drop Server Inject Fake Transaction Extract Data Tamper Page Web Application Client Machine Tamper Request 24
  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 transactions 27
  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 Request 29
  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 tests 30
  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 protocol 31
  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 assumed 34
  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 Digest 35
  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 test 36
  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 footprint 37
  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 time 40
  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 vendors 41
  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 clients 44
  45. 45. Questions - CONFIDENTIAL -
  46. 46. Thank You - CONFIDENTIAL -

Notas del editor

  • 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&amp;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

×