22

Today I was exploring a website used for keeping track of student grades and everything related to school. Basically like a school progress tracker for your child which is used by 90% of schools in my country.

I fired up Charles proxy and connected my phone to it and installed Charles's root certificate so I can use https (the site uses it). Anyway, I logged into the site and checked what Charles captured.

It captured a simple ajax call with 4 fields containing all the login credentials. Here's a screenshot:

enter image description here

Everything is even labeled - uporabnik means "user" and geslo means "password" So if I am understanding this correctly (I am really really just a beginner), everyone that manages to capture this can look at it?

Is this only possible with a proxy or can wireshark for example also do this and just capture packets over wifi?

Are my assumptions true and if they are, what should I do about it?

Charles Duffy
  • 477
  • 5
  • 9
  • 8
    But how would anyone capture this without installing the root certificate on your phone first? – Luc May 17 '19 at 13:15
  • 42
    Protip: If you censor an url, do it right. It's pretty easy to deduct what the URL is. –  May 17 '19 at 13:16
  • @Luc Oh, I see what you mean. Im really gonna have to look into how Charles works. Haven't tought about it that way. I guess it is safe then. –  May 17 '19 at 13:16
  • @MechMK1 got it. Was in a hurry, sorry. –  May 17 '19 at 13:17
  • 4
    note that you can view the same info with the browser's built-in developer tools. – dandavis May 17 '19 at 18:10
  • It's also worth noting that the username should not be considered 'sensitive' or even secret. Most places use a fixed rule for generating them, so they're easy to guess even if they aren't used for dozens of other things on the network. The 'code' ('koda') field is probably for 2FA, which if done right should not be sensitive either (it should be a one-use code that never gets reused and can't be used to generate other valid codes). – Austin Hemmelgarn May 18 '19 at 16:18

2 Answers2

48

You seem to fundamentally misunderstand what TLS does.

TLS takes the regular plain HTTP traffic and encrypts it and adds integrity checks. Together with the certificate of the server, this ensures

  • Confidentiality: An attacker who captures the network traffic can not read the content of the communication.
  • Integrity: If an attacker modifies the network traffic, this would result in errors.
  • Authenticity: You can be sure that your communication partner is the server you think you communicate with. (We get to this in a second.)

If you were to look at the underlying HTTP communication, you would see your username and password in plain text, because this is what you have sent to the server.

What does the proxy do now?

If you use a TLS Proxy such as Charles, you essentially communicate with the proxy and the proxy communicates with the web server. So what stops an attacker from just using a TLS proxy? The certificate!

When you installed the TLS Proxy, the proxy generated a new CA-certificate, which you then imported. This means you gave the proxy the authority to create a certificate for any domain. For the purpose of being a proxy, this is fine.

An attacker however would have to make you import their certificate (or steal the private key of yours!) so you would trust certificates by their proxy.

So, is this an issue now?

No, it's not. Everything is working as it's supposed to. At the end of the day, when you send your username and password to a website, it somehow has to actually reach that website.

  • One potential issue might be if the attacker learns you are using an HTTPS proxy on their machine, and uses their own instance of the proxy to craft a certificate your machine will accept. – John Dvorak May 17 '19 at 13:50
  • 4
    @JohnDvorak Certificates are unique per installation. If I use a proxy, that does not make me vulnerable to other people using the same proxy, as their keys will differ from mine. –  May 17 '19 at 13:51
  • 2
    Thank you. I completely understand now. –  May 17 '19 at 13:51
  • 4
    @MechMK1 Well, at least they should be unique per installation. Of course people managed to mess even this simple thing up, so be careful about what certificates you import. https://arstechnica.com/information-technology/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/ – Peter Harmann May 17 '19 at 14:21
  • @PeterHarmann Yes, but I'm wagering the assumption that the design itself is still correct, even if there are implementation-related issues. –  May 17 '19 at 14:29
  • 3
    *when you send your username and password to a website, it somehow has to actually reach that website.* unless you use an authentication scheme like [SQRL](https://www.grc.com/sqrl/sqrl.htm) – Expired Data May 17 '19 at 16:19
  • @ExpiredData There are exceptions to all rules, but K.Vovk was clearly a beginner, so I tried to explain things as beginner-friendly as I can –  May 17 '19 at 21:33
  • Where does Charles' certificate come from? Is it generated when the application is installed, or is it static? If it's a static one that they distribute, having it trusted is a vulnerability, as any attacker could generate a certificate with it. – jpmc26 May 18 '19 at 09:16
  • @jpmc26 Per [their documentation](https://www.charlesproxy.com/documentation/using-charles/ssl-certificates/): "Charles generates its own certificates for sites, which it signs using a Charles Root Certificate, which is uniquely generated for your installation of Charles (as of v3.10)." That (as of v3.10) is slightly concerning (though that version came out many years ago), but it looks like it's saying it generates a certificate on a unique basis for each installation. – Zach Lipton May 18 '19 at 21:59
  • @ZachLipton I'm not sure why it's concerning. As long as it's unique to the install, an attacker can't do anything with it without a lot of access to the machine. If they have that much access to the machine, chances are they have enough control to use another attack vector anyway. – jpmc26 May 18 '19 at 23:05
  • 1
    @jpmc26 Sorry I meant the "as of v3.10" portion is a bit concerning, because it leads me to wonder what previous versions did and whether they used a static root certificate that was shared between installations. 3.10 should be quite old though, so perhaps any such certificate has expired. – Zach Lipton May 18 '19 at 23:15
4

How do you think most web sites handles login? By sending usernames and passwords in POST data and recognizing the logged in user with session cookies afterwards. There's no reason for hashing the credentials client side, and even less to obfuscate the variable names: it would be equally easy to figure out that uporabnik or ugcbuzsq is a variable that carries usernames.

That's why the connection is encrypted using TLS, and that's also why you weren't able to see this information before you installed the Charles proxy's root certificate.

Esa Jokinen
  • 16,100
  • 5
  • 50
  • 55
  • 1
    I see. TLS takes care of security so even if I can see the password, others cannot as that would require deeper access in my phone. Thats why the certificate is there –  May 17 '19 at 13:53
  • 1
    @K.Vovk no, that is not why the certificate is there. The certificate allows you to identify whether you are connecting to the server you think you are. For example, if you access www.google.com, your browser will open an encrypted connection to google, but how do you know it is really google and not just a hacker that's impersonating them? – fabspro May 17 '19 at 15:32
  • 4
    … and that is precisely *why* you had to install Charles's certificate in the first place to make HTTPS work again. Because Charles is nothing but a man-in-the-middle-attacker in this scenario, and if you didn't install its root certificate, you would get a security warning in your browser, and it would not send the data without warning you. – Jörg W Mittag May 17 '19 at 15:43
  • Oooooh, got it. Thank you for your time. –  May 17 '19 at 16:11