Surely they'd fix it
This one is inspired in part by a particular reddit comment about security breaches and people not competent enough to fix the problem:
While reading this, I thought "this cannot possibly be true - surely they'd fix it."
Then I remembered how, when I was 15, I once managed to "hack" (I use the term loosely, since they had virtually no security - all it required was decrypting a badly encrypted password stored in a public folder) into a corporate cms.
I was happy to have gotten in, especially since it was my first attempt at doing anything like that, but also a bit shocked that I'd gotten access to sensitive materials like user data so easily. So, I sent them an email about it, suggesting how they could fix it.
The next day, I looked in my inbox, and they had responded - saying that they would report me to the FBI. They had used email forwards to discuss the situation, and since they hadn't bothered to remove the quoted text, I immediately saw what had happened: they had an imbecile in charge of IT, and he was incredibly pissed about being shamed in front of his boss.
When I checked back a few weeks later, they had taken drastic measures against my earlier intrusion: a different passphrase -_-
This might feel a bit like reading a story from The Daily WTF, so skip it if you dislike this kind of stories.
While I'm no security expert myself, I like to believe I'm competent enough at things like frontend security of web applications (surely a dangerous belief to have). I've fixed a bunch of exploits on the few projects I've worked on, I know how to recognize the most dangerous and obvious situations (SQL injection, XSS, CSRF, etc.) and what to generally avoid. I'm better than nothing at all, but then I'd also avoid putting myself in charge of a bank's web application. It seems, however, that some people just thrive on that.
The Context
This story takes place about a year ago. H1N1 made lots of people nervous and governments around the world went on buying vaccines for everyone and telling people to wash their hands 10 times a day. During that period, the province of Quebec's health services decided to organize mass vaccinations for the people who wanted to be protected before Christmas holidays. In fact, they strongly recommended it.
Of course, this caused a few problems here and there. Huge lines would form, people would get angry, and old folks would be complaining on national TV about how inhumane it was to have them standing in the cold all that time. This pushed our friends in one of the many levels of public administration to order a website that would allow people to schedule a vaccination time. The site would then give them a little printable receipt that they could bring to confirm their 'booking'. The first version of the application was deployed for 3 cities in my region, and others in the province would follow in the next few weeks.
My boss (former programmer) scheduled a session and came to see a coworker and me the following day to tell us about a discovery he made. He entered the URL to his receipt in my browser, and it came up without any need for authentication. The best of it, as he pointed out, was that the URL had a querystring parameter that was only an integer, under the name id.
The Problem
As many readers might have guessed by now, the numeric index was likely an auto-incremented SQL primary key. By incrementing or decrementing the number, you could access other people's receipts, with all the information they had, including: home address, phone number, full name, date and time scheduled, date of birth, etc. I'm still not quite sure if the simple fact of being on a site operated for healthcare services makes this medical information, but I sure believed any lawyer could quickly spin it that way. Otherwise, it was a fun place for identity thieves. Or maybe an opportunist burglar could rob someone's house while they're away. Who knows.
We decided to call the company who made that site and tell them about the problem so they could fix it without too much panic.
As safe as a bank
They first thought we were a competitor trying to sink them. They still acknowledged the issue, and within a day, a fix had been deployed.
My boss came back to my desk and showed us their new security scheme. Much safer. Well not that much. My coworker and I rapidly spotted a furtive == appended to a series of seemingly random letters and numbers. A quick test proved that all they did was encode the numeric identifier with a Base64 scheme.
For the readers who don't know, Base64 encoding is used mainly to represent all kinds of data with numbers, letters of the alphabet and a few symbols generaly regarded as safe to transport data (like + or =). In no way does it protect the data, it just represents it differently. This did nothing to actually hide information from anyone who knows how it works.
Funnily enough, the following morning, there were articles in the local newspapers about the site. You can see the French article from the newspapers, or read the following rough translation of a part of it:
When asked about the security level the site's users can benefit from, Stéphane Lajoie explains that his system is encrypted using methods similar to those of financial institutions (128 bits). This security element is a requirement from the beginning, as it is always the case when personal information has to be transmitted.
I figure (or rather hope) they were talking of doing everything over HTTPS, but then what is it worth if all the data is freely accessible anyway?
We called the company in charge of the site again, explaining to them that what they did wasn't any safer and that data was still easy to access.
Repercussions
The next morning, my boss received a call from them. They were threatening to press criminal charges against us for hacking and stealing data.
Those were threats to keep us quiet, mostly because our respective families knew about the issue from us, and then passed the word and it threatened to reach the media. It eventually got to the ears of the government official in charge of the project, and the company started fearing for their image. They didn't look like they were going to fix the site much more than they already did, though.
Luckily, we found out that the people in charge of the site's servers were ex co-workers. After a few phone calls, they decided they didn't want any of the bad press the site could give them. They told the site's owners to man up and fix their stuff, otherwise they'd simply take it down themselves.
The next day, the site was still up, you could still access anyone's ticket. However, it no longer contained any personal information. I guess they just didn't know how to fix the system.
In my opinion, there could have been many safer schemes than what they originally did. Just generating unique random keys (let's say UUIDs), asking for a user-submitted password (hopefully salted and hashed) to access the ticket and regularly purging the data would have been one way to get a much safer (but not the safest) system than what they had chosen.
Blowing the whistle
I had decided to keep my mouth shut on the whole thing for a while, except for a few rants here and there on IRC (mostly #erlang on freenode) and jokes at the office. Today I went and visited the site one more time, just to see if it was still up.
It turns out they considered the whole project a success, and even decided to use the page as advertisement for future projects. They sell the concept as innovative, green (don't have to move around!), fast and whatnot. They are now trying to extend their market to every seasonal flu and to other enterprises.
I simply consider it unsafe to let such a corporation write and sell more websites where customer data could be at risk while advertising high levels of security.
The firm in charge is Agricom Communications. The site in question was monvaccin.ca. They are unprofessional, lying about the level of security they offer and a threat when it comes to security and private data.
I don't like getting this public, mostly because my region is technologically challenged (to put it nicely) and it was nice seeing some local business getting their share of the pie. However, I prefer seeing general quality to local prosperity.
As a programmer, I guess the lesson here is to be careful about accepting new challenges when there are real side effects. We all love trying new stuff and pushing our limits. It just sucks when real people are the guinea pigs of our experiments.