This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Man-in-the-browser attack"

From OWASP
Jump to: navigation, search
(Description)
 
(16 intermediate revisions by one other user not shown)
Line 1: Line 1:
 +
{{taggedDocument}}
 
{{Template:Attack}}
 
{{Template:Attack}}
 
<br>
 
<br>
 
[[Category:OWASP ASDR Project]]
 
[[Category:OWASP ASDR Project]]
[[ASDR Table of Contents]]__TOC__
+
 
 +
 
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
  
Line 8: Line 11:
 
The Man-in-the-Browser attack is the same approach as [[Man-in-the-middle attack]], but in this case a [[Trojan Horse]] is used to intercept and manipulate calls between the main application’s executable (ex: the browser) and its security mechanisms or libraries on-the-fly.
 
The Man-in-the-Browser attack is the same approach as [[Man-in-the-middle attack]], but in this case a [[Trojan Horse]] is used to intercept and manipulate calls between the main application’s executable (ex: the browser) and its security mechanisms or libraries on-the-fly.
  
The most seen objective of this attack is to cause financial fraud thru manipulating transactions of Internet Banking system, even when others authentication factors are in use.
+
The most common objective of this attack is to cause financial fraud by manipulating transactions of Internet Banking systems, even when other authentication factors are in use.
  
A previously installed Trojan horse is used to act between the browser and the browser’s security mechanism, sniffing or modifying transactions as they are formed on the browser, but still displaying back the user´s intended transaction.  
+
A previously installed Trojan horse is used to act between the browser and the browser’s security mechanism, sniffing or modifying transactions as they are formed on the browser, but still displaying back the user's intended transaction.  
  
 
Normally, the victim must be smart in order to notice a signal of such attack while he is accessing a web application like an internet banking account, even in presence of SSL channels, because all expected controls and security mechanisms are displayed and work normally.
 
Normally, the victim must be smart in order to notice a signal of such attack while he is accessing a web application like an internet banking account, even in presence of SSL channels, because all expected controls and security mechanisms are displayed and work normally.
  
 
Points of effect:
 
Points of effect:
 
+
* '''Browser Helper Objects''' – dynamically-loaded libraries loaded by Internet Explorer upon startup
Browser Helper Objects – dynamically-loaded libraries loaded by Internet Explorer upon startup
+
* '''Extensions''' – the equivalent to Browser Helper Objects for Firefox Browser
 
+
* '''API-Hooking''' – this is the technique used by Man-in-the-Browser to perform its Man-in-the-Middle between the executable application (EXE) and its libraries (DLL).
Extensions – the equivalent to Browser Helper Objects for Firefox Browser
+
* '''Javascript''' – By using a malicious Ajax worm, as described on [http://myappsecurity.blogspot.com/2007/01/ajax-sniffer-prrof-of-concept.html Ajax Sniffer - Proof of Concept]
 
 
API-Hooking – this is the technique used by Man-in-the-Browser to perform its Man-in-the-Middle between the executable application (EXE) and its libraries (DLL).
 
 
 
Javascript – By using an malicious Ajax worm, as described on [http://myappsecurity.blogspot.com/2007/01/ajax-sniffer-prrof-of-concept.html | Ajax Sniffer - Proof of Concept]
 
  
 
==Risk Factors==
 
==Risk Factors==
 
TBD
 
TBD
 
[[Category:FIXME|need content here]]
 
[[Category:FIXME|need content here]]
 
  
 
==Examples==
 
==Examples==
Line 35: Line 33:
 
In order to perform this attack, an attacker may progress thru the following steps:
 
In order to perform this attack, an attacker may progress thru the following steps:
  
1. The Trojan infects the computer's software, either OS or Application.
+
# The Trojan infects the computer's software, either OS or Application.
 
+
# The Trojan installs an extension into the browser configuration, so that it will be loaded next time the browser starts.
2. The Trojan installs an extension into the browser configuration, so that it will be loaded next time the browser starts.
+
# At some later time, the user restarts the browser.
 
+
# The browser loads the extension.
3. At some later time, the user restarts the browser.
+
# The extension registers a handler for every page-load.
 
+
# Whenever a page is loaded, the URL of the page is searched by the extension against a list of known sites targeted for attack.
4. The browser loads the extension.
+
# The user logs in securely on to for example <nowiki> https://secure.original.site/.</nowiki>
 
+
# When the handler detects a page-load for a specific pattern in its targeted list (for example <nowiki>https://secure.original.site/account/do_transaction</nowiki>) it registers a button event handler.
5. The extension registers a handler for every page-load.
+
# When the submit button is pressed, the extension extracts all data from all form fields through the DOM interface in the browser, and remembers the values.
 
+
# The extension modifies the values through the DOM interface.
6. Whenever a page is loaded, the URL of the page is searched by the extension against a list of known sites targeted for attack.
+
# The extension tells the browser to continue to submit the form to the server.
 
+
# The browser sends the form, including the modified values, to the server.
7. The user logs in securely on to for example <nowiki> https://secure.original.site/.</nowiki>
+
# The server receives the modified values in the form as a normal request. The server cannot differentiate between the original values and the modified values, or detect the changes.
 
+
# The server performs the transaction and generates a receipt.
8. When the handler detects a page-load for a specific pattern in its targeted list (for example <nowiki>https://secure.original.site/account/do_transaction</nowiki>) it registers a button event handler.
+
# The browser receives the receipt for the modified transaction.
 
+
# The extension detects the <nowiki> https://secure.original.site/account/receipt</nowiki> URL, scans the HTML for the receipt fields, and replaces the modified data in the receipt with the original data that it remembered in the HTML.
9. When the submit button is pressed, the extension extracts all data from all form fields through the DOM interface in the browser, and remembers the values.
+
# The browser displays the modified receipt with the original details.
 
+
# The user thinks that the original transaction was received by the server intact and authorized correctly.
10. The extension modifies the values through the DOM interface.
 
 
 
11. The extension tells the browser to continue to submit the form to the server.
 
 
 
12. The browser sends the form including the modified values to the server.
 
 
 
13. The server receives the modified values in the form as a normal request. The server cannot differentiate between the original values and the modified values, or detect the changes.
 
 
 
14. The server performs the transaction and generates a receipt.
 
 
 
15. The browser receives the receipt for the modified transaction.
 
 
 
16. The extension detects the <nowiki> https://secure.original.site/account/receipt</nowiki> URL, scans the HTML for the receipt fields, and replaces the modified data in the receipt with the original data that it remembered in the HTML.
 
 
 
17. The browser displays the modified receipt with the original details
 
 
 
18. The user thinks that the original transaction was received by the server intact and authorized correctly.
 
 
 
  
 
==Related [[Threat Agents]]==
 
==Related [[Threat Agents]]==
 
* TBD
 
* TBD
 
[[Category:FIXME|need links]]
 
[[Category:FIXME|need links]]
 
  
 
==Related [[Attacks]]==
 
==Related [[Attacks]]==
* [[Man-in-the-Middle attack]]
+
* [[Man-in-the-middle attack]]
 
* [[:Category: Client-side attacks]]
 
* [[:Category: Client-side attacks]]
 +
[[Category:FIXME|should we add this category?]]
  
 
==Related [[Vulnerabilities]]==
 
==Related [[Vulnerabilities]]==
Line 91: Line 71:
  
 
==References==
 
==References==
 +
* http://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf - Stefano di Paola and Giorgio Fedon, Subverting Ajax, Dec, 2006.
 +
 +
[[Category:FIXME|link not working
 +
 
* http://www.it-observer.com/pdf/dl/concepts_against_mitb_attacks.pdf- Philipp Gühring - Concepts against Man-in-the-Browser Attacks, May, 2006.
 
* http://www.it-observer.com/pdf/dl/concepts_against_mitb_attacks.pdf- Philipp Gühring - Concepts against Man-in-the-Browser Attacks, May, 2006.
* http://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf - Stefano di Paola and Giorgio Fedon, Subverting Ajax, Dec, 2006.
 
  
 +
 +
]]
  
 
[[Category:Attack]]
 
[[Category:Attack]]
 
[[Category:FIXME|need Attack subcategory]]
 
[[Category:FIXME|need Attack subcategory]]

Latest revision as of 02:35, 6 June 2016

This page has been tagged and needs review. Please help OWASP and document the reason for this, see FixME.
This is an Attack. To view all attacks, please see the Attack Category page.



Last revision (mm/dd/yy): 06/6/2016


Description

The Man-in-the-Browser attack is the same approach as Man-in-the-middle attack, but in this case a Trojan Horse is used to intercept and manipulate calls between the main application’s executable (ex: the browser) and its security mechanisms or libraries on-the-fly.

The most common objective of this attack is to cause financial fraud by manipulating transactions of Internet Banking systems, even when other authentication factors are in use.

A previously installed Trojan horse is used to act between the browser and the browser’s security mechanism, sniffing or modifying transactions as they are formed on the browser, but still displaying back the user's intended transaction.

Normally, the victim must be smart in order to notice a signal of such attack while he is accessing a web application like an internet banking account, even in presence of SSL channels, because all expected controls and security mechanisms are displayed and work normally.

Points of effect:

  • Browser Helper Objects – dynamically-loaded libraries loaded by Internet Explorer upon startup
  • Extensions – the equivalent to Browser Helper Objects for Firefox Browser
  • API-Hooking – this is the technique used by Man-in-the-Browser to perform its Man-in-the-Middle between the executable application (EXE) and its libraries (DLL).
  • Javascript – By using a malicious Ajax worm, as described on Ajax Sniffer - Proof of Concept

Risk Factors

TBD

Examples

Manipulation thru DOM interface

In order to perform this attack, an attacker may progress thru the following steps:

  1. The Trojan infects the computer's software, either OS or Application.
  2. The Trojan installs an extension into the browser configuration, so that it will be loaded next time the browser starts.
  3. At some later time, the user restarts the browser.
  4. The browser loads the extension.
  5. The extension registers a handler for every page-load.
  6. Whenever a page is loaded, the URL of the page is searched by the extension against a list of known sites targeted for attack.
  7. The user logs in securely on to for example https://secure.original.site/.
  8. When the handler detects a page-load for a specific pattern in its targeted list (for example https://secure.original.site/account/do_transaction) it registers a button event handler.
  9. When the submit button is pressed, the extension extracts all data from all form fields through the DOM interface in the browser, and remembers the values.
  10. The extension modifies the values through the DOM interface.
  11. The extension tells the browser to continue to submit the form to the server.
  12. The browser sends the form, including the modified values, to the server.
  13. The server receives the modified values in the form as a normal request. The server cannot differentiate between the original values and the modified values, or detect the changes.
  14. The server performs the transaction and generates a receipt.
  15. The browser receives the receipt for the modified transaction.
  16. The extension detects the https://secure.original.site/account/receipt URL, scans the HTML for the receipt fields, and replaces the modified data in the receipt with the original data that it remembered in the HTML.
  17. The browser displays the modified receipt with the original details.
  18. The user thinks that the original transaction was received by the server intact and authorized correctly.

Related Threat Agents

  • TBD

Related Attacks

Related Vulnerabilities

Related Controls

References