csi2008 gunter ollmann man-in-the-browser

Man-in-the-Browser Attack Vectors

Gunter Ollmann – Chief Security StrategistIBM Internet Security Systems

[email protected] http://blogs.iss.net/

IBM

Date/Time: Tuesday (November 18, 2008) 4:00pm - 5:00pmTopic: Web 2.0

IBM Internet Security Systems

Man-in-the-Browser Attack Vectors - CSI 2008 Conference - Gunter Ollmann

Agenda

•Old News – Man-in-the-middle

•New(er) News – Man-in-the-browser

•How do you make money from it?

•What do protection strategies look like?



Threat EvolutionThreat Evolution



Threat Evolution – The Old Days

•Traditional Infrastructure was easier to protect Concrete entities

that were easy to understand

Attack surface and vectors were well-defined

Perimeter defensewas king



Threat Evolution – Abstraction

•Abstraction of computing technology – “Perimeter” and “Infrastructure” changing meaning Abstract and less defined entities, complex and evolving,

new attack surface and vectors

Still emerging – not understood

Shift in the underlying intent, focus, and direction of security threats and risks



Threat Evolution – Parasitic Era

•The threats of today and tomorrow are acting as parasites Stealthily jump infrastructures from one host to another

Depend upon the health and continued operation of the infrastructure they attack – rather than being destructive, they feed off the host!

Darwinism in action – infrastructure evolutiondriving exploit technologies



Man-in-the-Man-in-the-MiddleMiddle – old news? – old news?



Customer PCWeb Services

Intercepting Traffic – Man-in-the-middle

Man-in-the-middleA host under the attackers controlis inserted as a proxy between the

victim’s system and their destination

Permits the attacker to:• View all clear text traffic• Intercept confidential data• Terminate SSL/TLS connections• Modify and inject new content

Redirection Techniques:• Altering proxy settings• DNS modifications• Network routing changes



Limitations of Man-in-the-middle

• Active termination of encrypted sessions Why am I getting bad certificates messages all the time?

• Single source identification techniques Why are these 60 customers all accessing via the same IP?

• Log analysis of connections Why is my www.mybank.com traffic going through www.p0wn3d.ru?

• Probability of detection by the client or server is high…



Injecting in to the Web browser

• Getting a “man-in-the-browser” agent in to the browser is actually pretty easy

• Web browsers (and their plugins) are soft targets 637+ million potential victims, and growing

• Four-phase approach Exploit Web browser vulnerabilities

Execute shellcode

Install small downloader

Download man-in-the-browser malware

Understanding the Web browser Threathttp://www.technicalinfo.net/papers/UnderstandingTheWebBrowserThreat.html



Intercepting Traffic – Man-in-the-browser

Trojan Application

Local Proxy Agent

Trojan Application

Local Proxy Agent

OS HookingKeyloggers,

Screen grabber

OS HookingKeyloggers,

Screen grabber

TCP/IP Stack InterceptionPacket inspection, pre/post SSL logging

TCP/IP Stack InterceptionPacket inspection, pre/post SSL logging

System ReconfigurationDNS Settings, Local HOST file, Routing

tables, WPAD and Proxy settings

System ReconfigurationDNS Settings, Local HOST file, Routing

tables, WPAD and Proxy settingsTraditional MalwareOperates and interceptsdata at points through which the Web browser must communicate

Man-in-the-browserMalware hooks inside theWeb browser



API Hooking Malware

ApplicationThe Web browser


WinInethttpsendrequest(), navigateto()


WinsockTCP/IP stackWinsock

TCP/IP stack

Clean System

InternetInternet

MalwareProxying Web browser data .

MalwareProxying Web browser data .





WinsockTCP/IP stackWinsock

TCP/IP stack

InternetInternet

Infected System

ManipulateCopy, redirect,script, change,

insert, sell.

ManipulateCopy, redirect,script, change,

insert, sell.



Man-in-the-browser Malware

• Man-in-the-browser also sometimes called a “proxy Trojan”

• Operates from “within” the Web browser by hooking key Operating System and Web browser API’s, and proxying HTML data

• Allows the attacker to: Not have to worry about encryption

(SSL/TLS happens outside the browser)

Inspect any content sent or received by the browser

Inject and manipulate any content before rendering within the Web browser

Dynamically create additional GET/POST/PUT/etc. to any destination



Crime with Man-in-the-Crime with Man-in-the-BrowserBrowser



Traditional Banking Malware

• Focused on stealing login information Bank number, UID, password(s), session keys

• Techniques include: Keylogging, screen-grabbing, video-recording of mouse movements

Redirection to counterfeit site (domain/host substitution)

Replacement and pop-up windows

Session hijacking (duplicating session cookies)

Screen overlays (superimposed counterfeit web forms)



MITB – Grabbing Login Credentials

• Steal login credentials, and ask for more…

• Requests for additional data are easy to socially engineer Ask for credit/debit card details, including PIN and CVV

Additional “security” questions – SSN, mothers maiden name, address, home phone number, mobile/cell phone number

Type in all numbers of one-time-keypad scratch-card

“Change password” for anti-keylogging partial-password systems

“Test” or “resynchronize” password/transaction calculators

• SSL/TLS encryption bypassed, “padlock” intact

Pre-loginFirst page of login sequence is

manipulated

Pre-loginFirst page of login sequence is

manipulated

LoginMultiple fields & pages added

to the login sequence

LoginMultiple fields & pages added

to the login sequence

Post-loginAuthenticated user asked

additional security questions

Post-loginAuthenticated user asked

additional security questions




Original pre-login fieldsUID, password & site

Modified pre-login fieldsNow with ATM details and MMN

New fields addedMITB malware

inserted additionalfields. Records them,

and sends them tothe attacker




Modified pre-login fieldsNow with ATM details and MMN

Programmable InterfacesMalware authors developing an extensible platform that can be sold or rented to other criminals

Configuration filesXML support, dynamic updates



Hiding in Plain SightHiding in Plain Sight



MITB – Focusing on the Money Transfer

• Change in tactic’s – move from login to the money transfer First malware generation captured in early 2007 (South America)

• Change driven by: Widespread use of temporal multi-factor keys for authentication

Backend application heuristics for spotting login patterns

Inter-bank sharing of login and transfer “physical” location info

Improved malware techniques…

• Transfers happen after the customer logs in, from their own computer, while they are logged in.

• “Session Riding” – can be conducted manually (attacker C&C) or scripted



MITB – State-of-the-art Banking Proxy Trojan

Attacker makes off with the money and the victim is

unaware a transaction has

occurred

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”

Victim logs in to the bank “securely” and banks

“normally”

Proxy Trojan starts functioning once the victim

logs in

Proxy Trojan starts functioning once the victim

logs in

Intercepts each

transaction

Intercepts each

transaction

Calculates what is supposed to be

in the account

Calculates what is supposed to be

in the account

Modifies the page that

appears to the victim

Modifies the page that

appears to the victim

Steals some money

Steals some money



Honing in on the Transaction

Submit

Customer logs in

Authenticates successfully and

securely

Customer logs in

Authenticates successfully and

securely

Transfers

Customer navigates to

the fund transfer interface

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

Validation

Customer asked to provide a validation key for the

transaction – may include a bank-issued “salt” value Submit

2nd Submission

Customer clicks “Submit” to proceed

2nd Submission


Confirmation

Transfer complete

Confirmation

Transfer complete

Transaction ValidationAs an anti-keylogger andanti-replay technique, somebanking applications requirethe use of a separate“validation” code for eachtransaction

Payment Details

The customer proceeds with

entering transfer details (from, to, value, when, etc.)

Payment Details

The customer proceeds with

entering transfer details (from, to, value, when, etc.)

Submission


Submission




Honing in on the Transaction – Malware Injection

2nd Submission


Submit

Submit

Payment Details

Customer enters their transfer

payment details

Submit

Background Malware

In the background, the proxy Trojan has created it’s

own transfer details

Submission


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”

2nd Validation

Customer enters another

validation code

3rd Submission

Malware submits the original “real”

customer transfer information

Confirmation

2nd transation is confirmed back to the customer. In

reality, two transfers have been conducted



Preventing Transaction Injection – Banks Response

• Customer enters transaction data the same way From account, To account, Amount, and When

• Customer creates validation token Computational hash created using transaction data, password, and temporal

data

• Validation token only viable for one specific transaction

• … yet more things the customer must do in order to create a transfer!



Social Engineering past CAP Transfers - Original

Transaction ValidationAssuming the customer has alreadylogged in, they must successfullynavigate multiple pages to completea funds transfer.

Page (1)Which FROMaccount?

Page (2)How much?Where TO?

Page (3)Are detailscorrect?

Page (4)CAP instructionsand CODE?

Page (5)Validationcomplete!



Social Engineering past CAP Transfers - Injected

Page (1)Which FROMaccount?

Page (2)How much?Where TO?

Page (3)Are detailscorrect?

Page (4)CAP instructionsand CODE?

Page (5)SecurityCODE?

Page (6)Validationcomplete!

Transaction Monitoring

The malware continuously monitorsthe customer as they navigate thepages to conduct a funds transfer

HTML Page InsertionAn extra page is inserted in tothe transfer sequence andrequests an additional CAP“Security Code”.



Social Engineering past CAP Transfers - Injected

• Attackers response – ask the victim Social engineer it from them

To Account: 9812-3451-23Amount: $1,500.00

Validation code:456123

Validation code:998543

Security Code: 3133731137Amount: $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.



SMS & Out-of-band Validation/Reporting

• What does “out-of-band” mean when the contact info can be set online?

• Man-in-the-browser allows the attacker to harvest and change any “personal” information Cell-phone address for SMS text message alerts

Home phone number for notification

Postal Address

• VoIP technologies added to attackerstoolkit Caller-ID manipulation

Cloned/recorded banking message alerts



An Entwined ThreatAn Entwined Threat



Man-in-the-browser Ramifications

• How can you trust anything that comes from a Web browser?

• Man-in-the-browser is an entwined threat… What does this mean for the “Trojan defense”?

• But really, what about those stats… 25-30% of all PC’s infected already…

50-200 million bots…

637 million poorly patched Web browsers…

• Continuing business with an un-trustworthy customer’s computer?



Future Man-in-the-Browser Threats

• The ubiquitous Web browser Embedded within thick-client software,

Smartphone distribution.

• Man-in-the-browser agents will get smarter and more sophisticated Open-platform attack engines

Third-party plug-ins to extend functionality

• Bleed over from banking and financial fraud - to classic “spyware” money makers… Identity profiling and sales to marketing companies etc.



PROTECTIONPROTECTIONSTRATEGIESSTRATEGIES



The Elephant in the Room

• Complexity creates opportunity forsocial engineeringinstigated by malware



Physical Client-side Validation

• Move the authentication and verification processes out of the Web browser Asymmetric keys and TLS session keys stored on physical device

Real-time viewing of the transaction and manual validation

• Downside: Increase in complexity and decrease in accessibility



Protection Improvement Mindset

• Most important factor for Web apps? – reduce complexity Is it likely additional pages or fields would be spotted by a customer?

Is it clear to the customer what’s expected of them?

How many pages must customersnavigate through or scroll through?

Are all the steps logical?

Are important questions and stepspresented as text or as graphics?

How would a customer recognizechanges to page content?

Could the interface be simplifiedfurther?



Improving Web application design

• “Continuing Business with Malware Infected Customers”http://www.technicalinfo.net/papers/MalwareInfectedCustomers.html

• Categories to work on… Application Flow

Online Changes

Back-office Verification



Conclusions

• Man-in-the-browser attack vectors are unaffected by current authentication and validation technologies

• Attacks are big business, and a well organized crime

• Transaction validation needs to assumethat the host is compromised

• Assume that customer details canbe gained by simply asking them

• Security professionals must spotapplication complexity, and think interms of Security Ergonomics

Questions?

Gunter Ollmann – Chief Security StrategistIBM Internet Security Systems

[email protected] http://blogs.iss.net/

IBM

Date/Time: Tuesday (November 18, 2008) 4:00pm - 5:00pmTopic: Web 2.0

csi2008 gunter ollmann man-in-the-browser

Technology