27

I'm doing some research on the App of my telephone operator. I started Burp Suite on my Mac in proxy mode, then I opened up the App on my iPhone and started to sniff some traffic.

I pressed the "login" button and this happened:

Burp Suite

My username and my password are there, in plaintext. The connection is actually HTTPS, but if it's HTTPS, why can I read my username and password as plaintext parameters in the POST request?

Is this normal?

I also tried to replicate the login process with a curl command, and it works only if I use the -k parameter that skip the SSL certificate validation.

What's going on here?

Improve this question
2
  • 9
    Remove the burp root certificate from your device and try again, if you can still eavesdrop on traffic this means that despite using HTTPS, the app does a very bad job at verifying the SSL certificate and you are thus at risk (an attacker can generate a self-signed cert and the app would accept it just fine).
    – user42178
    Commented Sep 30, 2014 at 10:56
  • 5
    You've basically compromised your own device. Yes, you can see the login credentials, this is what happens when you decrypt SSL traffic. A packet sniff of what went over the wire would show encrypted traffic.
    – Fiasco Labs
    Commented Sep 30, 2014 at 14:51

3 Answers 3

Reset to default
39

Burp Suite in proxy mode is able to decrypt HTTPS traffic of any systems which trust it. It does this by generating an own certificate and use this cert to register itself as a certificate authority on the system it is installed on. When it then proxies a request to a HTTPS webserver, it does the HTTPS handshake itself, decrypts the traffic, issues a certificate for the webserver signed by itself as a certificate authority, uses that certificate to re-encrypt the traffic and send both the forged certificate and the re-encrypted data to the client.

This allows Burp Suite to eavesdrop on HTTPS traffic. A user which uses a normal proxy server or doesn't trust the Burp Suite pseudo-CA would not have their credentials compromised.

Improve this answer
7
  • Burp issues a certificate to the webserver itself? Isn't this dangerous? If attacker creates his own version of e-mail site, and lures user to login using say gmail password, will Burp issue the certificate to this phishing site?
    – Curious
    Commented Sep 30, 2014 at 11:59
  • 1
    @Curious Burp would get the certificate warning in that case when it connects to the fake-gmail.com server on behalf of the client. Depending on how it is configured it could then abort the connection attempt.
    – Philipp
    Commented Sep 30, 2014 at 12:02
  • Can you explain some details on how it works? So imagine I have an iPhone, a Mac with Burp running in proxy mode and a server called X. The iPhone now tries to establish a secure connection with X. The first stage of the handshake is intercepted by Burp that replies with his own certificate, so the iPhone will receive the proxy certificate instead of that of the server. The Burp's certificate is signed by Burp itself. Right? How can Burp force the iPhone to add himself to se CA list? And then? How the communication evolve? Thanks.
    – marcomanzoni
    Commented Sep 30, 2014 at 13:17
  • 6
    Sounds to me like @marcomanzoni isn't very familiar with SSL proxies, and therefore possibly hasn't configured their phone with the BurpSuite CA. Given that, one of two things has probably happened: 1.) User ignored SSL warnings provided by the app. 2.) App ignored untrustworthy SSL certificate and proceeded without presenting warning or error. The former is a common end-user issue. The latter is a security vulnerability in the app.
    – Iszi
    Commented Sep 30, 2014 at 13:34
  • 6
    @marcomanzoni Different apps and OS's handle invalid certificates differently. Most desktop web browsers and Operating Systems are pretty good about warning the user of invalid certificates. Other desktop applications may not be so reliable. Mobile platforms, especially at the app level, are hit or miss. When an app fails to warn a user that a server it is contacting has presented an untrustworthy certificate (i.e.: one not signed by a CA the app or device has been configured to trust), that represents a vulnerability in the app.
    – Iszi
    Commented Sep 30, 2014 at 13:46
1

I am not 100% sure about this, but I think it highlights a severe vulnerability in the application that you are reviewing:

Normally, when an application connects through https, it creates a secure connection and validates that the certificate has been signed by a trusted Certificate Authority, that it is still valid and, on occasion, that it has not been revoked. The certificate also needs to be valid for the domain the HTTP connection is being initiated to.

Burp generates an invalid certificate for intercepting SSL traffic. As you mentioned, curl, and any other application which is secure, will see that the certificate is signed by an untrusted CA and will act accordingly; browsers will display a grave warning, and curl will exit with an error status.

If the application does not act accordingly, and still connects even though the certificate is invalid, an attacker such as yourself can intercept the connection and do diverse things, among which is stealing your password and if the application auto-updates, executing arbitrary code in your computer.

Note that this only applies if you didn't get and ignore any warnings by the application.

Improve this answer
2
  • I did not ignore any warnings by the application. I think that the App never check the Server's certificate. Now another thing: I can perform the same request to the server using curl. This only works if I'm using the -k flag that skips the Certificate Validation. This means that also the App skips the Certificate Validation? My operator is using a self-signed certificate? Thanks.
    – marcomanzoni
    Commented Oct 3, 2014 at 16:05
  • "I think that the App never check the Server's certificate" Yeah, that's a pretty serious vulnerability, then.
    – droope
    Commented Oct 5, 2014 at 21:09
0

It is surely not good, but it is normal for now. It is not good because an adversary hacked into server can modify the server's software in order to save the credentials for him. Or an adversary able to decrypt https, for example using mitm, as you do, can get the passwords. There is a solution present for more than 30 years called authentication protocols, but unfortunately they are not used. Zero-knowlege authentication protocols are present for more than 20 years, but they are still not in wide use. I don't know why do we still use these obsolete passwords.

BTW, the app developer should implement public key pinning, but this have not been done.

Improve this answer

You must log in to answer this question.

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