Over the Summer, I noticed a peculiarity on a section of a website that many people frequently visit that contains a lot of personal information about me as well as all its other users. Upon further inspection, it was a weakness in the site's authentication. For the record, I would not be posting this if the site had not already fixed these problems. This lead me to investigate what of my information is made available through these exploits. I was driven to find out because MY information was available and you always assume that if you can exploit it, anybody can.
The offending peculiarity was a cookie that contained a query string that looked like this: "Num=<ID>&HashNum=<seven letter hash>" I specify that it was a seven letter hash because that's how long an ID number for this site is. The ID is not a secret thing, in this system everybody knows their own ID although nobody should know somebody else's ID. It was implied that the HashNum was the hashed result of the Num (the ID) and that it was a security feature in that if somebody messed with the Num, and it was hashed and didn't match the HashNum, then it was a sign of tampering. The hashnum looked familiar, I know it's odd that I noticed this connection, but if you were to look somebody up in the website's directory, the filename of their image is their hash number. For instance, if my cookie's hashnum was ILZXFZF, then the name of my directory image file is ILZXFZF.jpg. This connects a person's name to their HashNum. In theory, if I could find somebody's ID and relate that to their name, I could look them up in the directory and have all three pieces of information: name of the theoretical target, their ID, and the hash of their ID. With these three pieces being related to eachother, I could replace the cookie and be signed in as them without knowing their password. These three were the bare minimum requirements.
I quickly brought up my concerns with a friend who uses the site and also knows a thing or two about security. Efforts began to break the hash, normally an impossibility, but too many factors showed signs of weakness in the hash. Upon collecting multiple HashNums donated from friends of mine, these factors grew more obvious: output size matched the input size and the output was of a fixed character set which oddly matched the hex character set (D=0, E=1, F=2, G=3, H=4, I=5, J=6, K=7, L=8, M=9, U=A, V=B, W=C, X=D, Y=E, Z=F, in ASCII it's a 17 character shift). It is not a one to one character replacement, but the need to crack the hash was done away when another page was discovered.
Upon browsing the site more, I came across a red flag page. This page asked for either your ID, or if the visitor of the site hasn't been issued an ID yet, they could enter their social security number (if you're not seeing that as a BIG red flag, never go into web development). I'd like to note that the organization running this site is an organization you would normally trust with your SSN, this isn't the red flag. Regardless which you enter, if it were a valid number, it would validate the name associated to that ID or SSN. If an invalid number was put in, it just asked for another one. There was no limit to the number of attempts, either correct or incorrect, you could try as many different attempts as you wanted with no consequences, only rewards of associating the input ID or SSN with the name that matches it. Now with the name attached to the ID, just a quick search in the site directory for that name and you have the matching HashNum, thus all the pieces fell together. In theory, a small app could be written to scan through every possible ID (or SSN) and retain pairs of working IDs and their names. A small database could be formed, stored, and later referenced and would probably finish if run over night. Because I was not intending on doing anything malicious, I did not even write an application to do this, nonetheless run it.
With these facts in mind, I figured it was time to actually test the exploit, to see if it was something to worry about or if my research was for not. I asked my friend, who originally helping me with cracking the hash, if he would allow me to use his ID and corresponding HashNum in my cookie to test the exploit. He granted me permission and I also gave him mine to do the same thing with my info, I figured he'd be just as curious as I am to see this in action. Almost simultaneously, we were both set back with how it truly was that simple to sign in as somebody else. All that was required was signing in to the site with your own username and password, and changing the cookie value in question to a new Num and HashNum and every page request from then on was as if you signed in as the user who's information you put in the cookie. Personal financial information and other sensitive info was easily available and in some cases editable. We also postulated that because these authentication cookies are on an HTTP connection, instead of an HTTPS connection (again, if you don't see the red flag, put down the PHP/ASP.Net book and walk away) that a simple packet sniffer could be used to pick up these Num/HashNum pairs for an attack on a random user. Given that users of this site usually reside in a given geographic area, one could sit in a common place with their laptop and harvest person after person of IDs and their hashes.
One other page caught our eye: the page letting you change your password. You did not have to be signed in to view this page. It asked for the student's username (simply their first name, a dot, their lastname: corey.ogburn), their birthday, their ID number, the last four of their SSN, and their new password. The username is an easy guess, the birthday could probably be found on Facebook or by simply asking the person when their birthday is, the ID and the SSN can both be found with the other page I mentioned. Without knowing the old password, and with all of the necessary information being easily available, any user's account password could easily be changed. Since you don't need to be signed in to your account to change your password, anybody who is not a user in the system can enter the system in this way. This password could then be used for a lot of things. Each user is given 100MB on the network for storage, with this password, the malicious user could access the target's storage. Also, this password governs their site email address and other services hosted by the site. Although admins (of which there are many) are obviously a step up from users, they have the same type of ID that lets them exist in the database alongside normal users. The site contains a section where users are governed by admins. If the password page allows a malicious user to change the password of an admin, 100s of users' information is susceptible to being obtained. Not to mention the malicious user would have access to the admin's email and other areas of the site reserved only for admins.
As the bugs were analyzed more and more, it quickly became apparent that any attempt at security was rendered useless. Once access is gained to an admin account, information is handed to the malicious user. There's control to make or break other users, impersonate the admin, and by getting into the admin's email, could possibly break into the admin's personal life. This could lead to a much worse case of identity theft than just gaining access to this system. From beginning to end, a person's life could be permanently affected within 15 minutes.
Knowing these problems existed, I had to do something. The more I realized was wrong, the more I worried about somebody already knowing about these exploits and possibly using them. I began contacting the site's webmaster. My partner and I wrote up a small paper that discussed how the problems were found, what investigative methods were used to find them, what was achievable using these exploits, and recommendations for how to fix the problems through out the site. The paper was not too different from this blog post, maybe a bit more professional. The webmaster seemed rather stoic when we told him, but he appreciated our work and asked if he could keep in touch with us. He had mentioned that the cookie we found was in a rather old section of code and that the problem had probably been around for many years. That didn't make me feel much better, but what did was when I checked back on the site not even a week later the and offending cookie was no where to be found.
Take note how three small, individual bugs can crush the security of the site when working together. These bugs being the cookie, the page validating IDs and SSNs, and the password page. The discovery of all this started with a cookie. Just a small piece of temporary storage. Yet, it was all down hill from there until the system's security was stripped from any and all pages and available to a person with basic javascript knowledge (for editing the cookie) and the right URLs. To wrap this up, a webmaster should design a system first with security in mind, then tweak the usability until you have a user friendly site/system. If you don't find the hole, somebody else will and you don't want to take that risk about whether they'll approach you to fix it, or use it. I offered recommendations to the site, including moving all pages to HTTPS. For now my information is safe, not to mention the approximate 15000 users over the past 7 or 8 years that the bug existed.
Case Study, Computer Security
security, research, example, internet