20

Suppose I am connected to a wifi-hotspot hosted by a malicious attacker. Further, suppose that I am accessing a login page of an fictitious email site tmail.com over insecure HTTP connection.

My question is how can the attacker who owns the WiFi-hotspot steal my password by injecting the malicious JavaScript code without leaving any trace? Will URL still remain the tmail.com when I am accessing this or will it change? Where (application layer/network layer) and how (download the web page or modify network layer data) exactly the attacker will make the changes to succeed?

I am asking this question purely for educational purpose. I am just curious and have no intent to harm anyone.

Improve this question
6
  • 1
    I'm not sure enough, but you can a try a "Man In The Browser Attack" by altering java-script files to inject js payload. Check out this presentation from DEFCON : youtube.com/watch?v=0QT4YJn7oVI
    – TMR_OS
    Nov 10, 2014 at 12:13
  • 1
    And generally whenever you're using free wifi, make sure that you first VPN into a trusted network before logging into anything. VPN is essentially the only thing that can block MITM when accessing naked http content.
    – Andrew Hoffman
    Nov 10, 2014 at 14:47
  • 1
    As far as I know when you are under MitM attack and your are using https I think the browser URL will became red instead of (usually) green. Because the certificate.
    – Vitor Canova
    Nov 10, 2014 at 15:09
  • 1
    Even if you were on a secure hotspot, if you are visiting a page with an insecure connection (Http) anybody thats sniffing can read what you are sending to the router, without having to do any manipulation, as its sent in plaintext.
    – n00b
    Nov 10, 2014 at 16:05
  • Just a few days ago I came across this great blog post that should answer a lot of your questions and shows how it could be done, I recommend you read it: troyhunt.com/2013/05/…
    – Javid Pack
    Nov 11, 2014 at 0:48

2 Answers 2

Reset to default
35

The ISP (here, the WiFi hotspot) is what delivers pages to you. It's of course trivial for an ISP to read unsecured traffic:

diagram showing that the ISP reads unsecured credentials over the wire

Let's now consider a case where the credential submission is secured with HTTPS (so the ISP cannot sniff them right off the wire), but the HTTPS log-in page loads an unsecured script, helper.js. The ISP can inject any behavior into that non-HTTPS script before it finally serves the script to the browser. For example, the ISP can inject the instructions, "When this page submits credentials, send a copy of them to evil.example.com." The diagram below shows secured requests and responses in green and insecure requests/responses in other colors:

diagram showing that the ISP modifies the page content to contain a malicious script

When your browser requests helper.js over HTTP, the malicious ISP responds with a resource that has the wrong content. Your browser has no idea what helper.js should look like, and without any integrity validation measure (like HTTPS), the browser has no idea anything is wrong. Your browser assumes it has correctly been served http://tmail.com/helper.js, because that's what it asked for and the ISP sent back a response without any complaint (e.g., the response was an HTTP 200 for /helper.js). The fact that what your browser got is different from what the real server sent is totally irrelevant, because your browser has no way to detect that this difference occurred.

Based on your comments, you seem to think that modifying a resource can only be done by redirecting the browser to another resource. This is incorrect. Consider Bob the browser, Iggy the ISP, and two servers, Alice and Mallory.

First, consider the honest case:

  • Bob wants to know Alice's favorite food.

    • Bob says to Iggy, "Hey, Iggy, please send a GET /favoritefood to alice.com."
    • Iggy asks Alice about her favorite food. Alice tells him, "Pizza, but with no onions, because I hate onions."
    • Iggy comes back to Bob and says "Hey, I have that response for your GET /favoritefood from alice.com! She says she loves pizza, but not onions."

Now let's consider a dishonest case:

  • Bob wants to know Alice's favorite food.

    • Bob says to Iggy, "Hey, Iggy, please send a GET /favoritefood to alice.com."
    • Iggy comes back to Bob and says, "301 Moved Permanently -- ask Mallory about Alice's favorite food instead"
    • Bob then sends Iggy to GET /favoritefood from mallory.com instead. It's a different resource, and Bob knows it's a different resource from the one he originally asked for.

In this case, the browser's address bar would be different from what you originally typed in: mallory.com/favoritefood instead of alice.com/favoritefood.

Now consider this case instead:

  • Bob wants to know Alice's favorite food.

    • Bob says to Iggy, "Hey, Iggy, please send a GET /favoritefood to alice.com."
    • Iggy asks Alice about her favorite food. Alice tells him, "Pizza, but with no onions, because I hate onions."
    • Iggy comes back to Bob and says "Hey, I have that response for your GET /favoritefood from alice.com! She says she loves to eat lots and lots of onions."

There's no other resources involved. http://alice.com/favoritefood is the only resource being fetched here; Iggy simply lied about what the contents of the resource were. There is no way for Bob to detect that Iggy is lying, because there is no integrity-validating system in place.

One final attempt at explanation: suppose the ISP is honest but mistakenly flipped a single bit when delivering the contents of the HTML file. Surely you would not expect such a mistake to cause the web page to load under a different domain. Now suppose that the honest ISP mistakenly flipped two bits instead of just one: again, such a mistake would never cause the domain or resource path to change. Now suppose the ISP flipped two thousand bits by honest mistake (perhaps the ISP has a faulty switch some place, or the WiFi router was hit by cosmic rays): again, no need for the domain to change. Now suppose the change was done maliciously instead of by mistake: again, the change in intent causes no change in what is actually happening. The resource path and origin, as identified in the browser's address bar, remains unchanged, while the ISP is free to change the contents of the resource (honestly or dishonestly) without detection.

Improve this answer
14
  • I understood the case when .js file is seprate from html file. Can the wifi-hotspot attacker modify the java script snippet embedded in the html code ?
    – Curious
    Nov 10, 2014 at 14:37
  • If the HTML page is protected by HTTPS, no. If the HTML page is not protected by HTTPS, yes. If the HTML page is not protected by HTTPS, the ISP can directly change anything about the page and can sniff credentials directly off the wire as in my first diagram. (If the log-in page is unsecured, but sends the credentials through a secure unsniffable channel, it's trivial to change the behavior of the unsecured page to use an insecure channel instead.)
    – apsillers
    Nov 10, 2014 at 14:41
  • i understood the case when the client makes the second request (.js file) and gets a malicious code from the wifi-hotspot. Because the html file is already received and browser request for .js file to which the attacker can respond with malicious evil.js script. But I didn't get how can the code be modified in the first request(.html). In which layer this is done, application?
    – Curious
    Nov 10, 2014 at 14:52
  • 3
    @Curious "Because the html file is already received.." -- we perform the modification on the HTML resource before the HTML resource is received. The ISP can modify any non-HTTPS traffic: HTML, JS, CSS, office documents, binary executable, etc., etc. There's no difference between modifying a JS file and modifying an HTML file. I don't entirely understand why you're treating the cases of a JS file and an HTML file differently. They're all insecure resources being processed by the ISP.
    – apsillers
    Nov 10, 2014 at 14:57
  • @Curious I've edited my based on your comments. I think you believe that a modification requires some kind of HTTP redirect. This is not correct.
    – apsillers
    Nov 10, 2014 at 15:17
3

I assume the login form on tmail.com will be send with https. Otherwise you can read the plain password with a packet inspector.

Your browser loads a webpage from tmail.com. The wifi owner can add a JavaScript into this page. This script will log whatever you type into the login form of the mail provider and store it somewhere.

Will URL still remain the tmail.com when I am accessing this or will it change?

yes, it will all look the same. But the page source code contains addional JavaScript.

Where (application layer/network layer) and how (download the web page or modify network layer data) exactly the attacker will make the changes to succeed?

In the application layer he will change the webpage.

Update

For better understanding you might like to get mitmproxy.org and use the replacement tool:

:~q:</html>:<script>alert('hi')</script></html>

This will add a JavaScript to all html pages passing through.

Improve this answer
12
  • If the changes to the webpage are done in the application layer, then the attacker has to download and make the changes. How exactly this is done? If the attacker downloads and make changes, it will be stored on the local machine, how can the actual web page be changed on fly and forwarded to my machine?
    – Curious
    Nov 10, 2014 at 12:28
  • @Curious it is called "transparent proxy". the idea is, that all traffic to port 80 (or any other port) is filtered thru the program. usual proxy would just cache the result, so that further requests are served faster, but malicious owner of proxy can set it up to modify the pages
    – JimiDini
    Nov 10, 2014 at 12:36
  • 3
    If you connected to a wifi everything you download is "downloaded" by the wifi router and forwarded to you. The WiFi access point can modify this data on the fly as it pass through.
    – PiTheNumber
    Nov 10, 2014 at 12:37
  • How exactly this data is modified? Can you elaborate further?
    – Curious
    Nov 10, 2014 at 14:01
  • 1
    @Curious Injection is done at the network layer, with possibly some changes to the application layer (e.g., modifying the Content-Length header to reflect the length of the modified document).
    – apsillers
    Nov 10, 2014 at 15:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .