Kalimat al-Mutafalsif

So I was feeling kinda down a few days ago, and I turned to the thing that always cheers me up, hacking. Nothing malicious, just seeing what bugs I could turn up. Found a great one dealing with why sites should use HTTPS instead of HTTP traffic by default. Oh, I've taken the liberty of attempting at clearing out all links to my accounts. Don't worry, my account doesn't use that security question any longer. Also, because this post isn't malicious, I'm omitting the name of the site I found this on (and really, it could be any of the major sites out there, they all act a lot the same and I've yet to go check some other major ones) because they deserve anonymity as much as I do.

DISCLAIMER
I do not condone the breaking of any site's ToS, nor do I condone criminal acts. Nothing in this post is meant to be a how-to for idiots who feel the need to hurt others. This post is meant as an example of what not to do as we all can learn from each other's mistakes.

Anyway, I noticed the other day that a certain site does a huge no no. They only use http:// pages, no https://. Sure, they post the username and password to an https domain, but that's it. Many banks do this also, I can't explain why. Maybe they don't want their users to have to type an extra letter? Granted that's a moot point if you just throw a meta redirect from your http://myhomebank.com/index.html to your https:// domain, but I digress.

This is bad. Why is it bad? First off if I do some DNS pharming I can make the user connect to my evildomain.com where I will change the form action for login to an http domain, or better yet my site. While I have never done this, as obviously that'd be illegal and I never do anything illegal, this is not very hard in a campus setting. While not trivial, dorm networks are normally vulnerable to ARP poisoning, and you can get ~1200 eager college freshman each night logging into your system. Again, this is somewhat of a tangent, suffice it to say, users should *always* be trained to look for the nice yellow bar, and the https so they know they're logging into your site.

Why else should you only use https:// for large, profitable, sites? Because if its http://, I can sniff your traffic. Sure, on a switched network I'd have to ARP poison the router to see the whole dorm's traffic, but I could also just subvert the router and install my sniffer there. Or sit in a computer lab that's wired with a hub (we've got at least two I know of) and see what ~40 people are doing at a time.

Of course, by now you realize that no confidential data ever goes over unsecure lines, right? Your web developers all know just how important your terms of service are. Yea, you can sense the sarcasm already, can't ya? So I poked around this site, and found their security question section they keep pestering me to set. Now this is a feature that almost all major sites have: "Set a security question so we can later identify you." Its not a bad idea at all. I may lose my password, and access to the email I registered with, yet you must now treat these security questions as if they're passwords, because they gain access to the account. Turns out this site sends this setting to their normal account editing php page and that's off a non-SSL secured domain. Which means if you've got a sniffer and a hub like me, its quite easy to find. My laptop popped up this doozy.

0000 00 12 17 3c 68 d9 00 0f 1f 16 20 13 08 00 45 00 ... 0010 00 f6 69 cf 40 00 40 06 2e 2b c0 a8 01 37 cc 0f ..i.@.@..+...7..
0020 14 19 d6 47 00 50 8b 52 2d ea 2b 55 1e 9a 50 18 ...G.P.R-.+U..P.
0030 16 d0 db 58 00 00 43 6f 6e 74 65 6e 74 2d 54 79 ...X..Content-Ty
0040 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f pe: application/
0050 78 2d 77 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e x-www-form-urlen
0060 63 6f 64 65 64 0d 0a 43 6f 6e 74 65 6e 74 2d 4c coded..Content-L
0070 65 6e 67 74 68 3a 20 31 33 34 0d 0a 0d 0a 70 6f ength: 134....po
0080 73 74 5f 66 6f 72 6d 5f 69 64 3d 66 66 66 66 66 st_form_id=fffff
0090 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 ffffffffffffffff
00a0 66 66 66 66 66 66 66 66 66 66 66 26 73 65 74 74 fffffffffff&sett
00b0 69 6e 67 73 3d 26 73 61 76 65 5f 73 65 63 71 3d ings=&save_secq=
00c0 31 26 71 75 65 73 74 69 6f 6e 3d 32 26 61 6e 73 1&question=2&ans
00d0 77 65 72 3d 63 75 74 65 2b 67 69 72 6c 26 73 61 wer=cute+girl&sa
00e0 76 65 5f 71 75 65 73 74 69 6f 6e 3d 43 68 61 6e ve_question=Chan
00f0 67 65 2b 53 65 63 75 72 69 74 79 2b 51 75 65 73 ge+Security+Ques
0100 74 69 6f 6e tion

For those that have no clue what's going on in the above, this is an HTTP POST frame that is passing a few variables. Random crap we don't care about, then post_form_id (my guess is some form of checksum to make sure its me), and then some things to save. The one's we're interested in are:

question=2
answer=cute+girl

This means set Question two (which dealt with kissing?) to the answer of "cute girl" (yea, she was pretty cute, geeks know how to pick 'em). I'd like to take this time to point out that that post_form_id is unique to my account. I logged on on two different systems, and got the same one every time. Now, you're saying "But the account isn't passed in the clear! So this means nothing! Noob!!"

Haha, but unfortunately this site passes the account name in the clear. The full packet also included a line consisting of:

login={username}@{domain}.{TLD}...user={usernum}

I've removed the actual hexdump as it gave away way too much information about what site this is.

Please take a minute to note the user name. It is in clear, plain text. If you read the entire disassembled packet, that means the username, and security question are sent in plain text and together. SCARY. Also fun things to notice, you can read my cookies in there. Sure, they're (hopeully) encrypted, but still I'd really like to try a replay attack on here. I'm willing to bet by next week they'll have made sure there's a time stamp encoded somewhere in that junk. That last field is the user you're tracked by on this site. Take that value, and plug it into the profile page of this site, and you're taken to this other person's profile page. So, this is also a great way to meet random people, or friend them if they're sitting next to you for that ultimate stalker feel.

The Attack
Now, we'll perform an attack (on myself). I logged in on my desktop, while running Ethereal from a laptop on the same hub. I then traveresed to the account page, and finally set up my security question (shh.... its a secret). Checked through my ethereal dump, found the two packets I cared about, and stole some values. Among them the target's account name, and security question/answer. Then I opened up an email (from an account completely unrelated to the registered account email), prepared a little message asking to reset my password, and "identifying myself" with the stolen Q&A, hit send, and waited.

Two days later I got a response, they had reset my password. I used a little social engineering in the emails, but any good hacker would be able to do the same. This is completely non-malicious as its my own account and I owned both email accounts involved, and I wanted to change my password anyways. So just obtaining a user's security question can give attackers access to a certain account.

Practicality
Sure, you say, this attack is possible, but how practical is it? I'll give you that this isn't going to compromise the entirety of ANY site (although through a good phishing scam and ARP poisoning someone could get a nice chunk of a campus or office at once) but it is a vulnerability. And now that some social networking sites are tracking credit cards for various reasons, they have a duty to secure their sites as much as possible. Now, these sites are smart and only show the last four of the credit card number, like any business, but I can now use that credit card to order things off the site. Granted, that's just a little stupid attack, but this does give up at least partial credit card data, including expiration data and name and this should NOT be accepted by the public. We must hold financial institutions, and any place that deals with personal information to a higher standard, require HTTPS.

Conclusions
So, this whole incident begs just one question. Why NOT use https://? It requires no additional coding, you're just going over a secure channel. The user doesn't have to type in the s, you can just meta refresh them to that domain. And since you need https to be able to login, you know all your users support it. Its down right stupid, and begging to be hacked to be this large, and not use it. Same goes for any bank that follows the same principles, and brokerages. Heck it seems like every site that would naturally want encryption shrugs it off, and opts instead for plain ol' http://. Please guys, think of your users, and secure your stuff.

I've tried to be really good in this post about removing any information concerning which site it is. Please don't post comments that contain the site in question, as they will be modified and or deleted. I bear no malice towards that site, and I hope they accept this threat as genuine and secure their site ASAP. I will be passing this on to their admins once I post it, with more detailed information, for them to act upon. I'd hope the site will show me leniency, and recognize my intentions are to use this as a warning for all websites in their position.