2

I was wondering if the following scenario was realistically achievable.

We have a Network with a Computer that is used by Bob. He is security conscious person and uses a password manager. His computer is connected to the internet through a router which Bob got from his ISP. The ISP and the manufacturer of the router have not deployed updates for critical vulnerabilities that his router has.
Then there is Trudy who really wants to know Bobs passwords. She gets full access to his router through an exploit. There are a couple websites she is interested in so she manipulates the DNS entries to point to a webserver under her control. As Trudy has a lot of time, it is assumed that the DNS cache of Bob's computer will eventually be updated to contain the manipulated entries.

Bob happens to connect to a website Trudy is interested in. He thinks he is establishing a connection with https://www.safewebsite.com, but in fact he connecting to Trudy's webserver. The webserver downgrades the connection to plain http, just to establish the connection. Then the webserver performs a redirect to the actual URL of itself, e.g. https://safewebsite.evil.com for which Trudy has a valid (simple) SSL Certificate. Assuming Bob does not look too closely he doesn't see the difference in the address bar.

Alternatively Trudy gets Bob to visit her webserver in a way that does't trigger an invalid certificate exception.

What Trudy needs to do, in order to extract Bobs password, is to embed the valid website Bob wanted to visit. This also happens to be less work for Trudy as she doesn't want to code a phishing website, but wants to trick Bob's password manager. When Bob would visit Trudy's malicious website the password manager enters his credentials into the embedded website, because he believes that this is a valid connection. Then a script from Trudy's website grabs the content of the password field and username, sending both to the webserver.

Now Trudy does have a thing she is struggling with, a lot of websites have the x-frame-option set to deny. This foils Trudy's attempt in many cases. She has the idea to let the Router sniff for packets containing the x-frame-option. It would then be modified or removed. So if Bob visits Trudy's malicious website, he requests the embedded real website and the router performs an active MITM. This means the router connects to https://www.safewebsite.com and only hands Bob the http version. Bob would still see the https://safewebsite.evil.com, not indicating a visual change compared to the previous version of the attack. The question is if the router would be able to remove or modify the x-frame-option in a way that doesn't impact Bob's browsing experience.

Hopefully the idea is clear. If you spot something that is unrealistic, please leave a comment. Maybe you have an even simpler idea how to achieve this.

This is a attack scenario against a specific password manager (which will not be named here) that I would like to use in a presentation for a course at university, but only if it is plausible.

Update
Even though I knew and have thought this through several times, the written idea above has a crucial flaw, www.safewebsite.com would need to be loaded as https otherwise the password manager would not fill in the data. I will work on the scenario and post an updated version.

Update 2
It seems that the password manager does have a security issue filling credentials into iframes. The scenario is flawed though and the answers given are correct for the original question. If the new scenario does work, I will first contact the developers and later release more information about the problem.

Improve this question

3 Answers 3

Reset to default
3

Over HTTP a MITM could manipulate any request header.

Over HTTPS a MITM would NOT be able to do that without having a valid certificate or generating a certificate warning in Bob's browser.

www.safewebsite.com could mitigate some parts of this attack by using HSTS which would tell Bob's browser to only visit over SSL after the initial connection. The site could also refuse POST requests over HTTP (but that wouldn't stop Bob's browser from sending them).

Improve this answer
4
  • You misread a Little bit. What the attacker does, is letting the frame request the http www.safewebsite.com, but this request is then redirected to attacker's webserver, that does the request to https safewebsite.com via a Proxy. This request does then remove the X-frame option. The subsuquent post is done to the https site without any MITM at all (by letting the POST be proxied through the attackers webserver encrypted without any decryption), but at that time, its already too late since the details are captured via the frame.
    – sebastian nielsen
    Nov 6, 2015 at 20:25
  • @sebastiannielsen actually not, u2702 read correctly. But that is an interesting idea as well.
    – John
    Nov 6, 2015 at 20:53
  • @sebastiannielsen but thinking about it, this would likely not work, because the client would switch between a http and https connection. This wouldn't work, because the initial handshake is missing. Other than that my idea has a flaw, see the update.
    – John
    Nov 6, 2015 at 21:03
  • No. You misread me. Im talking about this: client (inside frame) --> http --> your server (removes frame lock) --> https --> safewebsite.com (to load the form), when client POST, you simply do client --> https --------(your server passing encrypted data without touching it)----> https --> safewebsite.com
    – sebastian nielsen
    Nov 6, 2015 at 21:06
1

The attack works, provided 3 things are true:

1: The password manager does not check https/http on the login form page. (or that the form is really a HTTP form POSTed over a HTTPS Connection)

2: The password manager does not use the top frame URL (visible url) as authenticating/triggering URL.

3: The password manager does not send the details directly, but fills them in instead. (Some password managers does POST a "copy" of the form directly instead of filling in the details on-screen, even if it visually looks like that - some password manager indicate this by a padlock Icon to the right of the username/password field. The other fields, like captcha or CSRF tokens, are sent to the password manager to include in the POST - this is a security feature to prevent keyloggers or - as you provided a attack example of - frame grabbers that grabs details out of frames)

However, the downgrade attack you talking about would of course trigger a HTTPS warning. Only way to downgrade the attack would be if the client is initially visiting a HTTP resource, you can strip off HTTPS of any links or forms. You could hope the user clicks through any HTTPS warnings, or you could block the HTTPS Connections to the safewebsite so the user might try "HTTP" and see if that fixes the problem.

Improve this answer
4
  • 1) See the update. I knew that but somehow missed that point in the scenario. 2) Yes this actually works and is tested. 3) The password manager really fills the html textboxes.
    – John
    Nov 6, 2015 at 20:58
  • However, you need to understand there might be password managers that only check the host, not the protocol or port. Try out with different password managers :-) Also some forms might load over HTTP, but POST over HTTPS. Thats pretty common.
    – sebastian nielsen
    Nov 6, 2015 at 21:00
  • Yes of course, but this is regarding a specific password manager. In case that there is a valid scenario, I don't want to post the name here. That is why I kept it general with a password manager in the question. Just assume that the password manager fills in the embedded site if it has the same protocol as usual (which is assumed to be https).
    – John
    Nov 6, 2015 at 21:07
  • aah, you wroite "password managers" (in plural) indicating this was some attack targeting some password managers in general.
    – sebastian nielsen
    Nov 6, 2015 at 21:09
0

I doubt that the attack is feasible, not because of the X-Frame-Option stripping, but because of the following:

When Bob would visit Trudy's malicious website the password manager enters his credentials into the embedded website, because he believes that this is a valid connection. Then a script from Trudy's website grabs the content of the password field and username, sending both to the webserver.

By "embed" I assume you mean putting it an <iframe>? Then, how would the script from Trudy's website grab the content of the password field? The same-origin policy would prohibit the script from reading the content of the <iframe>, including the filled-in password field.

Improve this answer

You must log in to answer this question.

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