‘Crashgate’ reveals unprotected donor database on Coleman’s site

Sometimes I wish they hadn’t even tried with Crashgate in the first place. It’s like the web community is going to have its own “secure ballot” drama.

There is no excuse for these horrible web management practices. If you somehow cause your database, or a copy of it to end up in public web directories, you deserve what you have coming to you, especially after declaring that your site was down under false pretenses. That’s only going to cause people to investigate, and they can’t help what they find posted to public directories when they do.

I can’t imagine his web “guru” will have a job much longer after this. Also, how long until Norm Coleman comes out and says, “I WAS HACKED”. Most people will be likely to believe that, and yet not understand the reasons why this wasn’t a hack.

Thanks for picking up my post Paul! I wish I’d seen your Twitter earlier today.

It’s a fairly common (and insecure) practice to store backups of database files in publicly accessible directories or in this case, not clean up directories after a site is moved or updated.

In the past, I’ve actually sent letters out to companies in the Twin Cities notifying them of basic security problems like this. The letters include screenshots, articles on why it’s a security issue and what steps they can take to fix it. None replied to my letters or returned my phone calls.

Many probably have heard of the problem with sequential numbering of user ID’s that caused major security and privacy issues for some well known Fortune 500 companies.

Here is a great article that summarizes how all the issues on Norm Coleman’s site could have been addressed before “Crashgate”

http://uis.georgetown.edu/web/hosting/securityexamples.html

I’m really starting to think this wasn’t a deliberate effort to deceive, but a technical error combined with other people not understanding the situation and assuming rather than checking that the cause must have been people seeking information the Coleman campaign had been touting, and thinking the traffic involved was enough to crash a site. The technical people had a screw up, but I’m thinking Coleman’s touts had the bigger screw up. They put out their announcement having no idea if it was true.

Which I suppose is still a lie of a sort. It reminds me of that book on bull—-, where the author defined bull— as different from a lie because the liar knows the truth so it can be covered up, while the bull—er doesn’t know or care about the truth, but says what sounds good.

Geezeus, cut Normy some slack. He has canned his staff and they are sucking wind over there.

Probably they fired the uneeded overhead, like the technicians.
But of course they kept the middle management (the guy that clicks the on-off switch on the
server admin screen.) And the budget for blo-and-go.

Eric, I would agree with you, except for the TTL entries; someone could easily have put out a DNS entry of 1.1.1.1 by mistake. However, explicitly setting it up to be renewed every 10 minutes makes things seem a bit more deliberate, especially since that’s not the kind of default value you’d see in a DNS setup tool. In fact, the kind of default you’d see in a DNS setup tool wouldn’t be 1.1.1.1, either – it’d be 0.0.0.0, which is explicitly set aside for unassigned addresses. If that had happened, browsers would have put up an error message distinctly different from “Site not found” – testing that on my Firefox browser results in sending the request to the local host (i.e. my own computer)

The only reason someone would even think of 1.1.1.1 is that it would display an error message on most people’s browsers that is superficially similar to that of a crashed site, and is likely not assigned to anything.

As incompetent as Norm’s office has been, it’s easy to believe that a half-dozen visitors to his site would be enough to crash the system. I’d be amazed if it wasn’t crashed more often than running. Still, this has the reek of a Karl Rove stunt. If anyone is a devout follower of Rove-tactics, it’s Norm.

The database also contains unencrypted credit card numbers, expiration dates and card verification numbers. I don’t know why this hasn’t hit the mainstream media yet. According to Minnesota law, the Coleman campaign should be required to release information of their loss of data to public news sources in addition to notifying the people whose data they lost directly. Since news of this database leak made it well around the internet, anyone could be using these credit card numbers now.

Someone needs to go very public with this information and soon. Peoples’ data is at stake here, and it’s just completely fucking stupid that nothing has happened yet.

[...] with a little more digging, it looks like Coleman’s IT group was just sloppy Posted by Gabriel | Filed in Corruption, Leftist [...]

[...] indicate that people were at accessing the directory that contained this database. How do I know? There’s screenshots that [...]

[...] brought down his campaign website? Anyway, his dumb, unimpressive fake crash stunt left a database full of info on supporters/donors unprotected and free for anyone to download, including information such as unencrypted credit card [...]

[...] indicate that people were at accessing the directory that contained this database. How do I know? There’s screenshots that [...]

Smooth move, VISI.

[...] campaign, which violated basic on-line security procedures. The unprotected Coleman database was discovered in January, and the campaign was notified by the Minnesota Independent, which has done outstanding reporting [...]

[...] that evening, the Independent reported Richards’ findings that an unsecured donor database was stored on the Coleman site. A few hours after that, the page containing that database was [...]

Why are they storing unencrypted credit card numbers?? Their webmaster or DBA has failed Security 101. Even if the database is leaked, the worst that should happen is that *encrypted* CC numbers are leaked, which don’t give away anything unless you know the encryption key (which should not be in that database).

[...] that evening, the Independent reported Richards’ findings that an unsecured donor database was stored on the Coleman site. A few hours after that, the page containing that database was [...]

The question of whether the site was hacked or if any card data was published on the web is no longer the main point. This information discloses that the Coleman campaign retained the verification code numbers that are usually on the back of the card. The mere fact that they retained these code numbers is itself a violation of Minnesota law AND the agreement contracts with the credit card organizations. Forget about the possible hacking, forget about who might have done or not done it. The fact remains that the retention of these code numbers alone puts the Coleman campaign in violation of the law.

“No person or entity conducting business in Minnesota… shall retain the card security code data, the PIN verification code data, or the full contents of any track of magnetic stripe data,” says state statute 325E.64. “A person or entity is in violation of this section if its service provider retains such data subsequent to the authorization of the transaction.”