CSI2008 Gunter Ollmann Man-in-the-browser

12,115 views
11,970 views

Published on

Man-in-the-browser attack vectors

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
12,115
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
107
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

CSI2008 Gunter Ollmann Man-in-the-browser

  1. 1. Man-in-the-Browser Attack Vectors Gunter Ollmann – Chief Security Strategist IBM Internet Security Systems gollmann@us.ibm.com http://blogs.iss.net/ IBM Date/Time: Tuesday (November 18, 2008)   4:00pm - 5:00pm Topic: Web 2.0
  2. 2. <ul><li>Abstract: Man-in-the-middle attacks have evolved—the attacks are more personal, and the attack front line has shifted into the Web browser. Investigate how man-in-the-browser attack vectors evolved, how they function and what the ramifications for Web 2.0 will be if businesses lose trust in and the trust of the Web browser. </li></ul>
  3. 3. Agenda <ul><li>Old News – Man-in-the-middle </li></ul><ul><li>New(er) News – Man-in-the-browser </li></ul><ul><li>How do you make money from it? </li></ul><ul><li>What do protection strategies look like? </li></ul>
  4. 4. Threat Evolution
  5. 5. Threat Evolution – The Old Days <ul><li>Traditional Infrastructure was easier to protect </li></ul><ul><ul><li>Concrete entities that were easy to understand </li></ul></ul><ul><ul><li>Attack surface and vectors were well-defined </li></ul></ul><ul><ul><li>Perimeter defense was king </li></ul></ul>
  6. 6. Threat Evolution – Abstraction <ul><li>Abstraction of computing technology – “Perimeter” and “Infrastructure” changing meaning </li></ul><ul><ul><li>Abstract and less defined entities, complex and evolving, new attack surface and vectors </li></ul></ul><ul><ul><li>Still emerging – not understood </li></ul></ul><ul><ul><li>Shift in the underlying intent, focus, and direction of security threats and risks </li></ul></ul>
  7. 7. Threat Evolution – Parasitic Era <ul><li>The threats of today and tomorrow are acting as parasites </li></ul><ul><ul><li>Stealthily jump infrastructures from one host to another </li></ul></ul><ul><ul><li>Depend upon the health and continued operation of the infrastructure they attack – rather than being destructive, they feed off the host! </li></ul></ul><ul><ul><li>Darwinism in action – infrastructure evolution driving exploit technologies </li></ul></ul>
  8. 8. Man-in-the- Middle – old news?
  9. 9. Intercepting Traffic – Man-in-the-middle Customer PC Web Services Man-in-the-middle A host under the attackers control is inserted as a proxy between the victim’s system and their destination <ul><li>Permits the attacker to: </li></ul><ul><li>View all clear text traffic </li></ul><ul><li>Intercept confidential data </li></ul><ul><li>Terminate SSL/TLS connections </li></ul><ul><li>Modify and inject new content </li></ul><ul><li>Redirection Techniques: </li></ul><ul><li>Altering proxy settings </li></ul><ul><li>DNS modifications </li></ul><ul><li>Network routing changes </li></ul>
  10. 10. Limitations of Man-in-the-middle <ul><li>Active termination of encrypted sessions </li></ul><ul><ul><li>Why am I getting bad certificates messages all the time? </li></ul></ul><ul><li>Single source identification techniques </li></ul><ul><ul><li>Why are these 60 customers all accessing via the same IP? </li></ul></ul><ul><li>Log analysis of connections </li></ul><ul><ul><li>Why is my www.mybank.com traffic going through www.p0wn3d.ru ? </li></ul></ul><ul><li>Probability of detection by the client or server is high… </li></ul>
  11. 12. Injecting in to the Web browser <ul><li>Getting a “man-in-the-browser” agent in to the browser is actually pretty easy </li></ul><ul><li>Web browsers (and their plugins) are soft targets </li></ul><ul><ul><li>637+ million potential victims, and growing </li></ul></ul><ul><li>Four-phase approach </li></ul><ul><ul><li>Exploit Web browser vulnerabilities </li></ul></ul><ul><ul><li>Execute shellcode </li></ul></ul><ul><ul><li>Install small downloader </li></ul></ul><ul><ul><li>Download man-in-the-browser malware </li></ul></ul>Understanding the Web browser Threat http://www.technicalinfo.net/papers/UnderstandingTheWebBrowserThreat.html
  12. 13. Intercepting Traffic – Man-in-the-browser Trojan Application Local Proxy Agent OS Hooking Keyloggers, Screen grabber TCP/IP Stack Interception Packet inspection, pre/post SSL logging System Reconfiguration DNS Settings, Local HOST file, Routing tables, WPAD and Proxy settings Traditional Malware Operates and intercepts data at points through which the Web browser must communicate Man-in-the-browser Malware hooks inside the Web browser
  13. 14. API Hooking Malware Application The Web browser WinInet httpsendrequest(), navigateto() Winsock TCP/IP stack Clean System Internet Malware Proxying Web browser data . Application The Web browser WinInet httpsendrequest(), navigateto() Winsock TCP/IP stack Internet Infected System Manipulate Copy, redirect, script, change, insert, sell.
  14. 15. Man-in-the-browser Malware <ul><li>Man-in-the-browser also sometimes called a “proxy Trojan” </li></ul><ul><li>Operates from “within” the Web browser by hooking key Operating System and Web browser API’s, and proxying HTML data </li></ul><ul><li>Allows the attacker to: </li></ul><ul><ul><li>Not have to worry about encryption (SSL/TLS happens outside the browser) </li></ul></ul><ul><ul><li>Inspect any content sent or received by the browser </li></ul></ul><ul><ul><li>Inject and manipulate any content before rendering within the Web browser </li></ul></ul><ul><ul><li>Dynamically create additional GET/POST/PUT/etc. to any destination </li></ul></ul>
  15. 16. Crime with Man-in-the- Browser
  16. 17. Traditional Banking Malware <ul><li>Focused on stealing login information </li></ul><ul><ul><li>Bank number, UID, password(s), session keys </li></ul></ul><ul><li>Techniques include: </li></ul><ul><ul><li>Keylogging, screen-grabbing, video-recording of mouse movements </li></ul></ul><ul><ul><li>Redirection to counterfeit site (domain/host substitution) </li></ul></ul><ul><ul><li>Replacement and pop-up windows </li></ul></ul><ul><ul><li>Session hijacking (duplicating session cookies) </li></ul></ul><ul><ul><li>Screen overlays (superimposed counterfeit web forms) </li></ul></ul>
  17. 18. MITB – Grabbing Login Credentials <ul><li>Steal login credentials, and ask for more… </li></ul><ul><li>Requests for additional data are easy to socially engineer </li></ul><ul><ul><li>Ask for credit/debit card details, including PIN and CVV </li></ul></ul><ul><ul><li>Additional “security” questions – SSN, mothers maiden name, address, home phone number, mobile/cell phone number </li></ul></ul><ul><ul><li>Type in all numbers of one-time-keypad scratch-card </li></ul></ul><ul><ul><li>“ Change password” for anti-keylogging partial-password systems </li></ul></ul><ul><ul><li>“ Test” or “resynchronize” password/transaction calculators </li></ul></ul><ul><li>SSL/TLS encryption bypassed, “padlock” intact </li></ul>Pre-login First page of login sequence is manipulated Login Multiple fields & pages added to the login sequence Post-login Authenticated user asked additional security questions
  18. 19. MITB – Grabbing Login Credentials Original pre-login fields UID, password & site Modified pre-login fields Now with ATM details and MMN New fields added MITB malware inserted additional fields. Records them, and sends them to the attacker
  19. 20. MITB – Grabbing Login Credentials Modified pre-login fields Now with ATM details and MMN Programmable Interfaces Malware authors developing an extensible platform that can be sold or rented to other criminals Configuration files XML support, dynamic updates
  20. 21. Hiding in Plain Sight
  21. 22. MITB – Focusing on the Money Transfer <ul><li>Change in tactic’s – move from login to the money transfer </li></ul><ul><ul><li>First malware generation captured in early 2007 (South America) </li></ul></ul><ul><li>Change driven by: </li></ul><ul><ul><li>Widespread use of temporal multi-factor keys for authentication </li></ul></ul><ul><ul><li>Backend application heuristics for spotting login patterns </li></ul></ul><ul><ul><li>Inter-bank sharing of login and transfer “physical” location info </li></ul></ul><ul><ul><li>Improved malware techniques… </li></ul></ul><ul><li>Transfers happen after the customer logs in, from their own computer , while they are logged in. </li></ul><ul><li>“ Session Riding” – can be conducted manually (attacker C&C) or scripted </li></ul>
  22. 23. MITB – State-of-the-art Banking Proxy Trojan Attacker makes off with the money and the victim is unaware a transaction has occurred Victim logs in to the bank “securely” and banks “normally” Proxy Trojan starts functioning once the victim logs in Intercepts each transaction Calculates what is supposed to be in the account Modifies the page that appears to the victim Steals some money
  23. 24. Honing in on the Transaction Customer logs in Authenticates successfully and securely Transfers Customer navigates to the fund transfer interface Validation Customer asked to provide a validation key for the transaction – may include a bank-issued “salt” value 2 nd Submission Customer clicks “Submit” to proceed Confirmation Transfer complete Transaction Validation As an anti-keylogger and anti-replay technique, some banking applications require the use of a separate “ validation” code for each transaction Payment Details The customer proceeds with entering transfer details (from, to, value, when, etc.) Submission Customer clicks “Submit” to proceed Submit Submit
  24. 25. Honing in on the Transaction – Malware Injection 2 nd Submission Customer clicks “Submit” to proceed Payment Details Customer enters their transfer payment details Background Malware In the background, the proxy Trojan has created it’s own transfer details Submission Customer clicks “Submit” to proceed Validation Customer asked to provide a validation key for the transaction – maybe including a bank-issued “salt” value Malware Fakes The malware fakes a “validation failure” even though the fake transaction worked. Prompts user to “try again” 2 nd Validation Customer enters another validation code 3 rd Submission Malware submits the original “real” customer transfer information Confirmation 2 nd transation is confirmed back to the customer. In reality, two transfers have been conducted Submit Submit Submit
  25. 26. Preventing Transaction Injection – Banks Response <ul><li>Customer enters transaction data the same way </li></ul><ul><ul><li>From account, To account, Amount, and When </li></ul></ul><ul><li>Customer creates validation token </li></ul><ul><ul><li>Computational hash created using transaction data, password, and temporal data </li></ul></ul><ul><li>Validation token only viable for one specific transaction </li></ul><ul><li>… yet more things the customer must do in order to create a transfer! </li></ul>
  26. 27. Social Engineering past CAP Transfers - Original Transaction Validation Assuming the customer has already logged in, they must successfully navigate multiple pages to complete a funds transfer.  Page (1) Which FROM account? Page (2) How much? Where TO? Page (3) Are details correct? Page (4) CAP instructions and CODE? Page (5) Validation complete!
  27. 28. Social Engineering past CAP Transfers - Injected  Transaction Monitoring The malware continuously monitors the customer as they navigate the pages to conduct a funds transfer HTML Page Insertion An extra page is inserted in to the transfer sequence and requests an additional CAP “ Security Code”. Page (1) Which FROM account? Page (2) How much? Where TO? Page (3) Are details correct? Page (4) CAP instructions and CODE? Page (5) Security CODE? Page (6) Validation complete!
  28. 29. Social Engineering past CAP Transfers - Injected <ul><li>Attackers response – ask the victim </li></ul><ul><ul><li>Social engineer it from them </li></ul></ul>To Account: 9812-3451-23 Amount: $1,500.00 Validation code: 456123 Validation code: 998543 Security Code: 3133731137 Amount: $1,500.00 Validation Code Calculation Customer must type in the “To Account” number and “Amount” in to the code calculator. The calculator also uses PIN, Date and time information to calculate the validation code Page Insertion As part of the process, the attacker inserts a fake page (extra step in “banks” process) in to the Web browser. The fake page asks the victim to use their calculator again – but to use a “Security Code” which is in fact the attackers bank account – and submits the second transaction.
  29. 30. SMS & Out-of-band Validation/Reporting <ul><li>What does “out-of-band” mean when the contact info can be set online? </li></ul><ul><li>Man-in-the-browser allows the attacker to harvest and change any “personal” information </li></ul><ul><ul><li>Cell-phone address for SMS text message alerts </li></ul></ul><ul><ul><li>Home phone number for notification </li></ul></ul><ul><ul><li>Postal Address </li></ul></ul><ul><li>VoIP technologies added to attackers toolkit </li></ul><ul><ul><li>Caller-ID manipulation </li></ul></ul><ul><ul><li>Cloned/recorded banking message alerts </li></ul></ul>
  30. 31. An Entwined Threat
  31. 32. Man-in-the-browser Ramifications <ul><li>How can you trust anything that comes from a Web browser? </li></ul><ul><li>Man-in-the-browser is an entwined threat… </li></ul><ul><ul><li>What does this mean for the “Trojan defense”? </li></ul></ul><ul><li>But really, what about those stats… </li></ul><ul><ul><li>25-30% of all PC’s infected already… </li></ul></ul><ul><ul><li>50-200 million bots… </li></ul></ul><ul><ul><li>637 million poorly patched Web browsers… </li></ul></ul><ul><li>Continuing business with an un-trustworthy customer’s computer? </li></ul>
  32. 33. Future Man-in-the-Browser Threats <ul><li>The ubiquitous Web browser </li></ul><ul><ul><li>Embedded within thick-client software, </li></ul></ul><ul><ul><li>Smartphone distribution. </li></ul></ul><ul><li>Man-in-the-browser agents will get smarter and more sophisticated </li></ul><ul><ul><li>Open-platform attack engines </li></ul></ul><ul><ul><li>Third-party plug-ins to extend functionality </li></ul></ul><ul><li>Bleed over from banking and financial fraud - to classic “spyware” money makers… </li></ul><ul><ul><li>Identity profiling and sales to marketing companies etc. </li></ul></ul>
  33. 34. PROTECTION STRATEGIES
  34. 35. The Elephant in the Room <ul><li>Complexity creates opportunity for social engineering instigated by malware </li></ul>
  35. 36. Physical Client-side Validation <ul><li>Move the authentication and verification processes out of the Web browser </li></ul><ul><ul><li>Asymmetric keys and TLS session keys stored on physical device </li></ul></ul><ul><ul><li>Real-time viewing of the transaction and manual validation </li></ul></ul><ul><li>Downside: Increase in complexity and decrease in accessibility </li></ul>
  36. 37. Protection Improvement Mindset <ul><li>Most important factor for Web apps? – reduce complexity </li></ul><ul><ul><li>Is it likely additional pages or fields would be spotted by a customer? </li></ul></ul><ul><ul><li>Is it clear to the customer what’s expected of them? </li></ul></ul><ul><ul><li>How many pages must customers navigate through or scroll through? </li></ul></ul><ul><ul><li>Are all the steps logical? </li></ul></ul><ul><ul><li>Are important questions and steps presented as text or as graphics? </li></ul></ul><ul><ul><li>How would a customer recognize changes to page content? </li></ul></ul><ul><ul><li>Could the interface be simplified further? </li></ul></ul>
  37. 38. Improving Web application design <ul><li>“ Continuing Business with Malware Infected Customers” http://www.technicalinfo.net/papers/MalwareInfectedCustomers.html </li></ul><ul><li>Categories to work on… </li></ul><ul><ul><li>Application Flow </li></ul></ul><ul><ul><li>Online Changes </li></ul></ul><ul><ul><li>Back-office Verification </li></ul></ul>
  38. 39. Conclusions <ul><li>Man-in-the-browser attack vectors are unaffected by current authentication and validation technologies </li></ul><ul><li>Attacks are big business, and a well organized crime </li></ul><ul><li>Transaction validation needs to assume that the host is compromised </li></ul><ul><li>Assume that customer details can be gained by simply asking them </li></ul><ul><li>Security professionals must spot application complexity, and think in terms of Security Ergonomics </li></ul>
  39. 41. Questions? Gunter Ollmann – Chief Security Strategist IBM Internet Security Systems gollmann@us.ibm.com http://blogs.iss.net/ IBM Date/Time: Tuesday (November 18, 2008)   4:00pm - 5:00pm Topic: Web 2.0

×