HSTS - SSLSTRIP & Mobile Apps

[Anton]

After reading a good bit about sslstip, hsts and how hsts prevents sslstrip attacks, I am intrigued to know if mobile apps send and receive data over a secure https hsts connection. And if https with the hsts implementation is exploitable.

So how would I go about seeing if for example, an app like facebook (because the facebook site implements hsts) uses hsts. Which tools would i need and what would i be looking for?

Secondly are there any known hsts exploits in existence?, sorry if these are all nubish questions but I'm friarly knew to this whole area, links/reading material would be appreciated.

As a side question does hsts effect cookie jacking? i.e. if a clients cookie is obtained and used when visiting a site such as facebook are you goign to see that users page or would hsts prevent this.

Another question I have is.... I know we can use tools like DNS spoof to redirect a browsers request for example *.facebook.com to my.evil.web.server.com but can the same with be done with mobile apps? i.e. do they request urls like a browser?


Cheers - Antony,

hsts :)

Edited August 20, 2014 by Anton

[ZaraByte]

From what i understand you gotta buy a real ssl cert for the site you are targeting if you wanna use tools like sslsplit. i might be wrong you might only need to buy a wildcard cert to use it against victims.

[Anton]

Thanks zara, buy a cert? i'm not following. Would be cool if someone documented how it was done and how to combat against it.

- Anotn.

[ZaraByte]

Thanks zara, buy a cert? i'm not following. Would be cool if someone documented how it was done and how to combat against it.

- Anotn.

I might have miss-understood what Whistle Master said but i believe he says if you buy a legit SSL certificate from a place that sells them ex; godaddy ect.. it doesn't show like a ssl warning to the victim. I myself don't make tons of money to waste of stuff to try them out to see if they work or not myself im kinda confused how owning a legit ssl certificate would allow you to break the https but meh im also confused on how you can get a ssl certificate made in a company like facebook's name.

[cooper]

What is needed is for your cert (which you either purchased or created yourself) is accepted as being THE cert for target.com (replace with whatever you deem appropriate). If you can do that, you can MITM the client, serving him your fake cert for the secure connection between him and you. You can decrypt the data (after all, your cert so you have the key), re-encrypt for the connection between you and the real target.com and send back the response you get from the real target.com to the client. All connections are secure, both client and server have no reason to believe they're talking to someone else, all is good.

To MITM an https connection, you need a few things:

- A trusted cert for target.com. The easiest way to do this is to generate a self-signed signing-capable cert (call it the main cert) and to make a captive portal for your AP which requires the user to accept this main cert as a trusted cert. The idea is that since this cert was trusted, anything signed using that cert will now also get trusted. When a user then requests target.com you quickly generate a new cert for target.com, sign it using the main cert and offer it to the client make it a legit secure connection. Getting this main cert in the client's truststore is the difficult part. Having a trusted thirt party (verisign et al) sign your cert makes it more likely the client will be willing to trust your cert. Problem is that your signing-capable cert will be pricy and the trusted third party might not look too kindly on you wanting such a cert to begin with.

- Full control over the DNS servers available. Part of the standard verification process in ssl is to do a DNS lookup of target.com which will yield an IP address AND ALSO a reverse DNS lookup of the IP address which must result in target.com so you must prevent ALL DNS traffic to hosts other than your controlled DNS servers.

Once those 2 are in place, you're good to go for https MITM stuff.

All HSTS does is let the server inform the client that all future communication for the next time period should be HTTPS-only. It prevents SSLStrip by telling the client to only work over https (sslstrip requires plain http and makes it look like https) and to use https immediately rather than the typical method of user entering a domain name and the browser first trying http which should get redirected to https (which can be circumvented by sslstrip).

[ZaraByte]

Captive Portal is what i noticed a lot of people on here recommend i guess the best thing to do and im not sure how you can make a popup or auto install of the certificate but i guess if you can figure that part out you might be able to say on a captive portal something like...

"Welcome Guest! Before you can access the internet you must install our plug in so we can add you to our internet allow list"

or something more creative to maybe get users to install that allowing you to be able to capture credentials that way.

[cooper]

"Hi! Welcome to our *FREE* Open Access hotspot. Because this is an Open Access hotspot, people could be able to listen in on your web sessions. In order to secure your session and thus prevent this issue, please visit our <a href="https://openaccessAP/accept">Secure AUP Acceptance Page</a> and accept the certificate provided to you, which will look something like this: <img src="http://openaccessAP/cert_accept_ios.gif" />. Once you do this, all your web traffic will be secured from prying eyes and you can safely enjoy your FREE Internet"

Going to the accept page will set a cookie in the browser. The idea is that the above page gets shown when the cookie isn't present. When the cookie IS present, redirect all HTTP traffic to HTTPS and do the MITM stuff. Let the AP figure out if the remote site is HTTPS or HTTP (just try them in that order) and go from there.

[Anton]

Ok well that cleared up a few things :) let me see if I got his in simple terms so I know exactly what I need to be learning about and reading up on. Just tell me if i have picked something up wrong or going a stray.

Internet | MiTM | Client

As long as I (MiTM) can give the client a valid cert, then I can view all traffic between myself and them? The part i am trying to understand is how https with hsts actually works. I get that it tells the client that all communication from this point on will be https only, but what you are saying is, all traffic between me and the client is http? so i can sniff it or do i give the client the impression that i am, i.e. facebook with this cert thing? thus allowing me to decrypt the traffic on the other end? as i am facebook? or so they/their browser thinks?

Breakdown:

MiTM: Hello client i'm facebook

Client: ORLY whers my https hsts cert thingy ma bob?

MiTM: Here it is!

So the client/browers/mobile app (A)now thinks its using https? or (B)it actually is using https?

And if (A) I understand how i would be able to sniff it because its actually http and not https?

If (B) I decrypt the https because i have the cert?

Have i got the jist or am I still confused lol? the whole main cert then serving up another cert and using a captive portal thing confused me aswell.

- Anton.

Edited August 21, 2014 by Anton

[i8igmac]

Would some one make a tutorial.

[cooper]

As long as I (MiTM) can give the client a valid cert, then I can view all traffic between myself and them?

Close. As long as you can give the client a valid cert and get the client to TRUST that cert you can use it to encrypt the traffic between you both and since you have the key you can also decrypt it allowing you to see all the gory details.

The part i am trying to understand is how https with hsts actually works. I get that it tells the client that all communication from this point on will be https only, but what you are saying is, all traffic between me and the client is http?

That's not what I'm saying. That's how standard sslstrip works - get your browser to look like it's operating on an https website, when in fact it's not.

What I'm saying is "fuck sslstrip". You don't use it. Instead, you create, on demand, the cert for whatever domain the user wants, sign it with your main cert and serve it to the client. The client trusts your main cert and since it was used to sign the fake domain cert, it should also be trusted. This results in the user not getting prompted or anything, the connection between you and client will be encrypted (using fake domain cert) and since you have the key for that cert you can decrypt the traffic.

That whole hsts works by informing the client that all traffic to that domain should happen using https. That's all. The goal is to protect mobile devices against sslscript, which relies/requires clients that access the http website of a server BEFORE accessing the https website for that same server. If however you can get a valid https connection going between the client and your AP, HSTS will do exactly nothing to protect you.

Breakdown without hsts:

Client - I want to go to www.facebook.com so let's go to http://www.facebook.com

MiTM - HA! I'm running SSLStrip so I now OWN your ass. You talk http to me, I talk https to facebook. You're screwed.

Breakdown WITH hsts, new visitor:

Client - I want to go to www.facebook.com for the very first time, so let's go to http://www.facebook.com

MiTM - HA! I'm running SSLStrip-hsts so I now OWN your ass. You talk http to me, I talk https to facebook. That hsts header in the response from facebook? Wiped that for ya. You're screwed.

Breakdown WITH hsts, repeat visitor:

Client - I want to go to www.facebook.com again and hsts from a previous visit says I should use https, so let's go to https://www.facebook.com

MiTM - Fuck! I'm running sslstrip but the connection is already encrypted so I'm screwed.

Breakdown WITH hsts, repeat visitor, but as described above:

Client - I want to go to www.facebook.com again so let's access this very trustworthy-looking AP.

AP - Hi! Please put my cert in your truststore. It's kosher. Really!

Client - Guess without that cert no internet. Oh well. Added.

AP - Thanks! (giggle) Enjoy your internet. (chuckle)

Client - I want to go to www.facebook.com again and hsts from a previous visit says I should use https, so let's go to https://www.facebook.com

AP - Here's a DNS response that says www.facebook.com is me, and here's the reverse lookup for my IP saying I'm facebook.

Client - Far so good, how about that cert?

AP - Het's a cert for facebook. See? Says so on the cert. And it's signed by a cert in your truststore, so it MUST be valid.

Client - Excellent. Thanks. Now, where can I put my credentials.

AP - I know just the spot...

Edited August 21, 2014 by Cooper

[Anton]

Hahaha!!! BEST. BREAKDOWNS. EVER!

Made me laugh so much reading that. But I now understand exactly how it works, and it makes sense! Now I know exactly what I need to be reading about.

Thanks again, much appreciated!

- Anton.

[singe]

This talk by Leonardo earlier this year has an awesome bypass for HSTS is some instances: https://www.blackhat.com/asia-14/speakers/Leonardo-Nve.html

His code is available at https://github.com/leonardonve

We integrated it into our mana toolkit at https://github.com/sensepost/mana/tree/master/sslstrip-hsts

[Anton]

Thanks for the reply singe, ill take a look at that when I get the chance.

Cheers, - Anton.

[resentic]

Close. As long as you can give the client a valid cert and get the client to TRUST that cert you can use it to encrypt the traffic between you both and since you have the key you can also decrypt it allowing you to see all the gory details.

That's not what I'm saying. That's how standard sslstrip works - get your browser to look like it's operating on an https website, when in fact it's not.

What I'm saying is "fuck sslstrip". You don't use it. Instead, you create, on demand, the cert for whatever domain the user wants, sign it with your main cert and serve it to the client. The client trusts your main cert and since it was used to sign the fake domain cert, it should also be trusted. This results in the user not getting prompted or anything, the connection between you and client will be encrypted (using fake domain cert) and since you have the key for that cert you can decrypt the traffic.

That whole hsts works by informing the client that all traffic to that domain should happen using https. That's all. The goal is to protect mobile devices against sslscript, which relies/requires clients that access the http website of a server BEFORE accessing the https website for that same server. If however you can get a valid https connection going between the client and your AP, HSTS will do exactly nothing to protect you.

Breakdown without hsts:

Client - I want to go to www.facebook.com so let's go to http://www.facebook.com

MiTM - HA! I'm running SSLStrip so I now OWN your ass. You talk http to me, I talk https to facebook. You're screwed.

Breakdown WITH hsts, new visitor:

Client - I want to go to www.facebook.com for the very first time, so let's go to http://www.facebook.com

MiTM - HA! I'm running SSLStrip-hsts so I now OWN your ass. You talk http to me, I talk https to facebook. That hsts header in the response from facebook? Wiped that for ya. You're screwed.

Breakdown WITH hsts, repeat visitor:

Client - I want to go to www.facebook.com again and hsts from a previous visit says I should use https, so let's go to https://www.facebook.com

MiTM - Fuck! I'm running sslstrip but the connection is already encrypted so I'm screwed.

Breakdown WITH hsts, repeat visitor, but as described above:

Client - I want to go to www.facebook.com again so let's access this very trustworthy-looking AP.

AP - Hi! Please put my cert in your truststore. It's kosher. Really!

Client - Guess without that cert no internet. Oh well. Added.

AP - Thanks! (giggle) Enjoy your internet. (chuckle)

Client - I want to go to www.facebook.com again and hsts from a previous visit says I should use https, so let's go to https://www.facebook.com

AP - Here's a DNS response that says www.facebook.com is me, and here's the reverse lookup for my IP saying I'm facebook.

Client - Far so good, how about that cert?

AP - Het's a cert for facebook. See? Says so on the cert. And it's signed by a cert in your truststore, so it MUST be valid.

Client - Excellent. Thanks. Now, where can I put my credentials.

AP - I know just the spot...

So how would one go about creating these certificates? Is it possible?

[cooper]

Just use OpenSSL. It's a fairly straightforward operation once you've created your own (self-signed) master cert to sign it with.

[resentic]

Just use OpenSSL. It's a fairly straightforward operation once you've created your own (self-signed) master cert to sign it with.

Is there any kind of guide to doing this for the use of bypassing hsts?

[bytedeez]

This talk by Leonardo earlier this year has an awesome bypass for HSTS is some instances: https://www.blackhat.com/asia-14/speakers/Leonardo-Nve.html

His code is available at https://github.com/leonardonve

We integrated it into our mana toolkit at https://github.com/sensepost/mana/tree/master/sslstrip-hsts

It would be real kind of you if you could make it into an infusion for us. Or point us in the right direction on how to get it working on openwrt for a command line infusion

[i8igmac]

I don't own a pineapple, can you git clone or wget the package then run it?

[bytedeez]

It's not available for the pineapple yet.

But yes you can git clone.

[cooper]

The Pineapple uses a MIPS processor so unless you have one of those floating around (don't bet on it) you won't be able to do anything with the binaries.

What you can do is grab the source code and try to compile it on your system. You should end up with a binary fit for your system which should be able to do anything that that same program would do on a Pineapple, just much, much faster.

[bytedeez]

You can literally git clone into kali(1.0.8 or higher)

cd mana

Run ./kali-install.sh

Let it install

Then cd back into mana (if not there)

Then excuse the command "run-mana/start-nat-full.sh"

Edited October 1, 2014 by bytedeez

[Urieal]

Ugh, captive portal with credential harvester.

Forget trying to research HSTS; no disrespect intended but HSTS is also worked directly into the browser...

If any of you are legit pen testers, I really hope that you all do a lot more reconnasiance on your targets instead of waiting for 'someone' to release a HSTS SSL STRIP.....

Target using Internet Explorer inhouse? SSLSTRIP

Target using Chrome,Safari,Firefox,ect, Credential Harvester / Social Engineering / Ettercap.

Many people use forums that don't offer https and these same people are likely to use the same passwords for several other areas of internet access.

Everytime I see someone inquire about HSTS / SSLSTRIP I can't help but feel its a skid/teenybopper.

Trying to compromise facebook accounts.

Legit Pen Testing is all about the shell, besides.. if you're doing credential harvesting you're already in red teaming territory?

Why not just keylog?

Just sayin'.

[bytedeez]

That's part of yes.

But it's also about researching and finding vunilbilities within the entire system. Which includes finding flaws in captive portals used to login into company databases.