How do apps transmit the login credentials - can they be sniffed by a MITM?

[michael_kent123]

I have wondered for some time how apps (e.g. Facebook, Twitter, or Instagram) on an iPhone on Android device transmit the username and password.

For example, if I am using a laptop and want to login to Facebook then I browse to https://www.facebook.com and enter my username and password which is transmitted to Facebook which checks whether it is accurate or not.

However, if I use the Facebook app, how is the username and password invoked?

If you are a MITM and you intercept client-server communications (e.g. with SSL Strip) then you can get my Facebook username and password. However, if I am using an app (over wireless) to login to Facebook then can you as the MITM grab my login details?

In all cases, we are using a wireless network.

[digip]

Some sites like facebook these days, uses HSTS, so they won't load without SSL on most of them. For those, you can use a captive portal attack to clone and fake the login page to and then sever to end users if you own the network and their connections with a MITM and dns rebinding, but for things like your iPhone apps and such, you'll need to grab the token or process it uses to login with your stored credentials and may not be simple https logins happening since the apps for different sites may use other login methods and protocols with encryption client side. Depending on how well they protect the process, you'd most likely need an app on the device to read the info for you vs trying to pull an external MITM, but a local one from memory attacks to intercepting the data being sent over the pipe may show more what is going on and what you can do to gain access to their authentication mechanisms.

Kos demoed an attack for Android devices that showed how google used a simple URL and token to authenticate devices and access google user accounts, but that may be patched now(don't quote me on that). His example of how this was done is in an episode of Hak5 few seasons back.

[michael_kent123]

Some sites like facebook these days, uses HSTS, so they won't load without SSL on most of them. For those, you can use a captive portal attack to clone and fake the login page to and then sever to end users if you own the network and their connections with a MITM and dns rebinding, but for things like your iPhone apps and such, you'll need to grab the token or process it uses to login with your stored credentials and may not be simple https logins happening since the apps for different sites may use other login methods and protocols with encryption client side. Depending on how well they protect the process, you'd most likely need an app on the device to read the info for you vs trying to pull an external MITM, but a local one from memory attacks to intercepting the data being sent over the pipe may show more what is going on and what you can do to gain access to their authentication mechanisms.

Kos demoed an attack for Android devices that showed how google used a simple URL and token to authenticate devices and access google user accounts, but that may be patched now(don't quote me on that). His example of how this was done is in an episode of Hak5 few seasons back.

Thank you for the answer.

I have a couple of questions. I've read about HSTS (https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security). The article claims that HSTS defeats SSL Strip. I don't understand this because, using the latest version of both IE and FF, I just successfully stripped my HTTPS connections to websites like Facebook and Gmail.

What I still don't understand is how the app validates the user. Is the user's username and password being sent to a server as in the traditional client / server model?

[i8igmac]

I believe the only way for this to work on mobile devices is to manualy add a cert to the device. the hsts is coded into the app or somethink

Each device will have its own install process to add your custom cert... there may already be some fusions for this idk. Some kind of portal

Edited March 22, 2015 by i8igmac

[cooper]

Thank you for the answer.

I have a couple of questions. I've read about HSTS (https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security). The article claims that HSTS defeats SSL Strip. I don't understand this because, using the latest version of both IE and FF, I just successfully stripped my HTTPS connections to websites like Facebook and Gmail.

What I still don't understand is how the app validates the user. Is the user's username and password being sent to a server as in the traditional client / server model?

SSL Strip works because the initial connection made to the remote site is over http. The http request is proxied by ssl strip to the https side of the server and any https and hsts-related communication is stripped from the response ssl strip sends back to the client.

The point about hsts is that once you've made a connection with an hsts using https website, any subsequent connection attempt with that site will only be attempted via https, even when you the user only provided the domain name in the URL (which would normally default to you accessing the http site rather than the https site). Now, if you can MITM the victim BEFORE that initial connection attempt, everything works as expected. But as soon as those hsts headers reach the browser it takes quite a bit of effort to make the browser forget about it (the quickest way is to get the website to return an hsts header with a time of 1, but you need full control over the webserver to achieve this).

How the app works isn't standardised. I wouldn't be at all amazed if some sort of challenge-response type deal is used, where the user only initially provides the credentials to log in, is given a key of sorts (stored on the server, same as username and password hash) and for each subsequent connection attempt the server provides a random which the app puts through a cryptographically secure hash function along with the initially provided key and sends the result back the server which then compares the hash against what it computes for those same values. The key is only transmitted once and everything else is just encrypted data that proves the user is who (s)he says (s)he is.

The main thing to remember about an app is that, basically, anything goes. They can write their own protocol if they wanted to. Chances are whatever they do will involve http(s) since it's such an established standard that routers and firewalls understand and allow pretty much anywhere. But if an app wants to play hardball and implement its own protocol over UDP or whatever, it can (and I wouldn't be amazed if a number of them already do).

[i8igmac]

Quote cooper "the quickest way is to get the website to return an hsts header with a time of 1, but you need full control over the webserver to achieve this"

how often is this packet found? if I pass this data threw a tamper proxy, I could change this value to 1 as you say could defeat this hsts. Then this data could pass threw sslstrip and we are all set?

If I had time to Test this... when would I see this packet, at the beginning of the session?

[digip]

Quote cooper "the quickest way is to get the website to return an hsts header with a time of 1, but you need full control over the webserver to achieve this"

how often is this packet found? if I pass this data threw a tamper proxy, I could change this value to 1 as you say could defeat this hsts. Then this data could pass threw sslstrip and we are all set?

If I had time to Test this... when would I see this packet, at the beginning of the session?

I've tried looking for HSTS headers and never seen them on any sites. You should be able to find them looking for Strict-Transport-Security with a ctrl+f(in wireshark), but I've yet to run across a site that uses it(or at least shows it in the header responses), so not sure how you check for it or if its on by default via the pre-load list.

Facebook from what I know doesn't even use HSTS(but I could be wrong), although sometime a while back they stopped allowing HTTP on their site to login, and should automatically redirect the user if trying to login via HTTP to HTTPS server side. HSTS drawbacks are that it relies on the browser to enforce, and either redirect after the site tells it to move over to https, or has a pre-loaded list of sites it's meant to only access over HTTPS, which again, relies on the browser and version you use. Not every site on the internet will be in the pre-loaded list, so you can imagine this isn't full proof, which is probably why sites like Facebook automatically redirect to https now. I know Twitter has an option to redirect you to https as well, but not sure if enforced all the time now, or only via your cookies, since you used to be able to check a box under your user profile, and tell it to only allow logins and use the site over https which required you to login first to set this.

Edited March 23, 2015 by digip

[cooper]

Quote cooper "the quickest way is to get the website to return an hsts header with a time of 1, but you need full control over the webserver to achieve this"

how often is this packet found? if I pass this data threw a tamper proxy, I could change this value to 1 as you say could defeat this hsts. Then this data could pass threw sslstrip and we are all set?

If I had time to Test this... when would I see this packet, at the beginning of the session?

As Digip says, it's not a packet but an HTTP response header. It has a numerical value which indicates the amount of seconds to continue to access the site using https only. The problem with your method of dealing with this situation is that once the victim has seen that header, you're unable to MITM his connection with the server so you're unable to change this header in any way.

I'm guessing Facebook dropped hsts (assuming the header is now absent and that they ever even employed it - I don't do facebook so I don't know) because it makes *all* traffic to them go as https which is likely to be a too significant drain on their resources.