I’m able to write this now that the issue I found is fixed. The Minnesota Department of Revenue used to put your social security number in plain text within a non-http-only cookie and it wasn’t a session cookie.
While this is bad enough that wasn’t the limit of the issue. You could also guess SSN’s and be returned legal names attached to them; within the cookie. This was kind of scary.
I should put a disclaimer out there about this. I wasn’t doing testing in any official capacity, I was paying my tax bill. I had logged into the site from work and hadn’t finished up the task of paying before closing the tab and putting my laptop into hibernate to go home. Once I got home I opened my laptop again and revisited the site. It auto-logged me in. This scared me since the only login credentials was my social security number.
Being a tester, I went straight to the cookies. I found a govdata cookie that was pipe delineated with my Social Security Number and my full legal name (which I hadn’t yet put into the site). I cleared my cookies immediately. I tried the steps again: Log into the site with my SSN, view govdata cookie. Again my name was shown. So I tried my wife’s SSN. Her full legal name showed up as well.
I stopped there. I didn’t want to type in any other random SSN’s and be returned legal names (power scares me at the right times). I knew how to make a script that would just start from 000-00-0001 and count up until the end and store all that data. I’m assuming that the state is using the social security administration’s API for checking the validity of an SSN. Also, I’m assuming that the same service provides the full legal name attached to that number.
It wouldn’t have been hard. If you entered an invalid SSN you were shown an error. Enter a valid one and you were shown the next step. The poor sap with the example SSN displayed on the page had his number out there for years.
But why am I publishing this now? First off, it’s fixed. I had contacted a number of officials to make sure they knew about this issue and that it should be corrected ASAP (including a tip to take down the site until it was fixed). The MNDoR communications person replied to my email saying that a new system was due to be in place soon and gave me exact dates.
Her response was a bit alarming and totally incorrect, however, it’s likely because she either received a blown-off reply from the development team or didn’t understand the reply from the development team (emphasis is mine)
Thank you for your e-mail. The Department of Revenue is in the process of transitioning the e-file program you are referencing to a new system. On January 16, 2012, all business taxpayers will be transitioned to the new system and on January 29, 2012, individuals making estimated payments will transition to our new system. The new system will never create a cookie.
To which I replied:
Thank you for the prompt reply. That is great news to hear about the move. However your statement about the “new system will never create a cookie” is impossible on a browser. There’s always a cookie involved when handling transactional processes. If the statement should be amended to say that the new system won’t store a cookie with private information in plain text then that is a better solution.
Keep in mind. Cookies aren’t the bad thing, what is stored in cookies can be.
Yes, I should have combined the 2nd and 3rd sentences (realizing that while proofing this post) but she got back to me pretty quickly with a better answer:
Thank you for the follow-up question. To clarify, we do use a cookie that is a temporary session key. It is unique and temporary and is used to guarantee that the user logged in is the same user for that session. It is set to expire at the end of the session and has a time out feature on it as well.
YAY! A session cookie!
I checked on January 29th to see if the new system had gone up, and it hadn’t. I then forgot about this post due to being really busy with my job and checked it today seeing that it was fixed. Now the cookie is a session cookie that is marked as httponly and isn’t storing the ssn hashed within the cookie itself.
While this security issue doesn’t quite hit the OWASP top ten it’s the second time in a few months that I’ve hit an issue that’s only duplicatable within cookie data.
I’m also disappointed that the other people I contacted never got back to me. Minnesota Attorney General’s Office, United States Department of Justice, IRS Security Department, Social Security Administration Security Department. They were all copied on the email I sent to the MNDoR and I never received a response. I did receive canned responses from our two senators though, the canned responses being that they don’t handle state affairs and that I should take it up with the MNDoR and the Attorney General’s Office.
How many of you testers check cookie data obsessively like I do? I use the “Edit This Cookie” Chrome extension to quickly view what cookies are stored for the domain I’m on. I love that extension and suggest it to anyone who wants to know what the website they are on is tracking about them.
Image Credit: Shanta on Flickr
