2

So I've been offered the chance to go to a day long security awareness event hosted by some organization. On their site, I noticed the login box in the corner, but the site was delivered on HTTP. They probably are doing like some other sites and only using https for the actual login. I thought. So I checked the source of the page, found the form being submitted for login, and noticed 'http://...'.

So I decide to do a test. Break out google's developer tools and capture the post. I still don't see any mention of https and I see my fake password in plain text (so they didn't encrypt with javascript before sending).

I'm wanting to bring this to my coworkers' attention, but first I want to be sure that they actually are sending it over http. Is there any other way to verify the connection is going over http (other than setting up a MITM attack on myself, which I'm pretty sure would cause the network admin to express great... displeasure towards me)?

| improve this question | |
  • 1
    You could use Fiddler or Burp to see all requests and responses, including if it is HTTP or HTTPS. To me it seems, by the way you describe it, it's indeed over HTTP. The fact that you see your 'plaintext' password is 'normal', you will see this also when using Fiddler or Burp (since you MiTM yourself) – Jeroen Dec 19 '14 at 20:39
  • As far as seeing the password, I was guessing they could be doing something crazy like having javascript encrypt it with their public key, and they would unecrypt it with their private key after transit. Not something I would do, but a possibility (I think). By seeing it in plain text, it showed they weren't doing anything like that. – Lawtonfogle Dec 19 '14 at 20:43
  • You realize javascript is client side right? In other words, if some sort of 'encryption' (don't you mean obfuscation?) was performed, it was performed client side and therefore reversable. – Jeroen Dec 19 '14 at 20:50
  • I think it could be MITM by stripping out the script that would encrypt the password, which is still a big flaw, but if it was encrypted with a public key and then sent over the network for all to see, it still couldn't be reversed because the MITM would know the public key and the encrypted text, which isn't enough to decrypt. As I said, stripping out the javascript with a MITM would still defeat it. – Lawtonfogle Dec 19 '14 at 20:55
  • The irony here... – KnightOfNi Dec 19 '14 at 22:22
7

What you have done is a pretty thorough test, but you can get ironclad proof this way: Install Wireshark on your own computer, turn on packet capture, and perform the login. If HTTPS, the packets you capture will be marked as such, and will be encrypted. If not, you will be able to see the login credentials en claire in the captured data.

Do note that encrypting client-side with JavaScript does not work. It is vulnerable to replay attacks and MITM attacks because whatever client sends to server effectively is the password, no matter what has been done to it.

| improve this answer | |
  • It sounds like any better test will require me getting approval from security. – Lawtonfogle Dec 29 '14 at 14:18
3

The most sure fire way would be to place a router in line and monitor the packets, but at the end of the day it is really irrelevant. At best, they are rolling their own crypto, which is still horribly bad.

There are any number of ways a non-HTTPS page could be compromised to give up the credentials even if they are doing some form of client side encryption in javascript that you are missing.

| improve this answer | |
  • If the page with the login form is HTTP, an active MITM can control where the form sends its login info to. Any security applied after that point can only help against passive monitoring. Add in the possibility of SSLStrip, and the whole site needs to be HTTPS from square one. – Brilliand Dec 19 '14 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.