LinLog

Apparently we were "hacked"

pageer@skepticats.com (Peter Geer)

You know that weird jump in auto-incremented IDs we saw in our database at work the other day? Well, we discovered the cause: apparently we were "hacked".

I use the work "hacked" in the loosest sense of the word. The culprit contacted us the next day, making a number of demands and issuing veiled threats. I may get into the details in another post (it's a long story), but the point is that he appeared to have, at best, a script kiddie level understanding of security. He pointed out a number of flaws in the site, but the ID incrementing was the only one that could actually have caused us any real trouble - and he didn't even mention it! We assume that he actually did that by accident and didn't realize the potential implications if we ran out of ID numbers.

The flaw allowed the ID incrementing was actually quite simple. No SQL injection or cross-site scripting. It was a simple case of passing too much data into a function.

Here's how it works. Our site, which runs on PHP and MySQL, is built on a custom MVC framework. It uses a custom Active Record-style ORM, which is where the flaw lies. The ORM performs database updates and inserts by validating the object's fields against the database schema. Basically, it reads the schema from the database, compares that with the data to be updated, and constructs the SQL accordingly. So when you execute the save() method on an object, it will save the values for the fields that appear in the table schema, but ignore any other fields in the object. The ORM also has static update() and insert() methods that take an associative array, mapping the indexes to field names and performing this same validation. So if you have an array of data, only some of which maps to actual columns in the underlying table, you can just pass the whole thing and not have to go through and separate out the fields you need to save.

That last point is where we got in trouble. We have a method that adds items to our media table. It takes an array of data, does some sanitizing and validation, calls the insert() method to add it to the media table, and adds appropriate records to other tables. The problem was that, in the place where this was called most frequently, we were passing in $_POST as the data array. And while this method did sanitize the fields that we wanted to add to the database, it didn't check for extra fields that just happen to be valid fields in the media table. So, to make a long story short, if you were to put an "id" field in the POST and assign it an integer value, our ORM would happily add that field and value to the INSERT statement it sent to the database.

Of course, this was easily fixed. In fact, it wasn't even hard to find. I did a fair amount of work on our ORM at the beginning of the year, so once I made the connection between the "hacker" and the ID number jump, the source of the bug was immediately obvious. It's just one of those things that nobody ever thought to check until it became a problem.

So the moral of the story is: security is all about attention to detail. Following the "rules" is all well and good, but it's not enough. In our case, we were sanitizing data to protect against XSS attacks and using PDO prepared statements to protect against SQL injection attacks, but it wasn't enough. By forgetting to check for unexpected additional input, we left ourselves open to a completely different type of attack. Of course, it's a significantly less serious class of attack - maxing out our auto-incrementing IDs is recoverable, if annoying - but it's still an issue.

With any luck some good will come out of this. I think we've all learned to be a little more mindful of such issues. And perhaps this will act as a cue to management that maybe - just maybe - it would be better to do some actual testing and review of new code before it's released, rather than just pushing things into production and hoping they work.

Sympathy for the devil

pageer@skepticats.com (Peter Geer)

I know there are those in the Linux community who will regard this as equivalent to spitting on the cross while blaspheming the holy spirit, but sometimes I feel sorry for the people at Microsoft. They have a tough job and they are frequently blamed for things that aren't their fault.

What made me think of this was Jeff Atwood's follow-up to his Windows spyware post.

I understand the pressure to be backwards compatible. There's no end of Vista blowback based on minor driver compatibility issues. The "if it doesn't work, it's automatically Microsoft's fault, even if the software or hardware vendor is clearly to blame" mentality is sadly all too common. But given the massive ongoing Windows security epidemic, was defaulting regular users to Administrator accounts-- exactly like Windows XP, Windows 2000, and Windows NT before it-- really the right decision to make?

In many ways, Microsoft is in a perpetual no-win situation. On the security front, for example, they are besieged by the evil forces of malware. However, every time they try to improve the situation, end users scream blood murder. For example, was the weird "quasi-administrator with prompting" a good idea? Probably not, but it's better for the average user than silently allowing the installation of spyware, and yet everyone seems to hate it. But what's the alternative? To make accounts regular users by default? How would the average Windows user would feel about that? I don't know, but I have read a many comments by recent converts to Linux who seem to think that entering a password just to install some software is completely stupid and unreasonable, so I can't imagine it would be universally hailed as a great improvement.

And, of course, there's always the breakage that accompanies any OS upgrade. For example, remember Windows XP Service Pack 2? I seem to recall widespread complaints about things breaking when that was rolled out. And we're seeing the same thing now with Vista. And who do people blame? Is it the ISV who are still coding with Windows 98 in mind? No - they blamed Microsoft.

What really kills me about this situation is when I read Raymond Chen's accounts of the efforts of the Windows App Compatibility team. For example, consider this sample chapter from his book. From the cases he mentions there, it is completely obvious that Microsoft takes backward-compatibility seriously. Very seriously. In fact, you might even say they take it too seriously.

Think of it this way. On Linux you're lucky if you can get source compatibility for an application that's more than 5 years old. Microsoft has binary compatibility with a large range of programs that are 10 or 15 years old. They're working with third-party binaries, diagnosing obscure bugs, and implementing fixes to keep the applications working, even though it's by sheer luck that they ever worked in the first place. As a programmer, it's hard to overstate how impressive this is. And yet all anyone ever focuses on is the problems they didn't fix.

Then there's the political angle. There are lots of people out there who seem to think that Microsoft can do no good. Everything they do is viewed with suspicion. Anyone who works for Microsoft has to contend with accusations that he is either in on the conspiracy or is bowing down to "the man" every time he says something they MS-haters don't like. That's got to be at least a little demoralizing. And while a certain degree of animosity is certainly warranted (as it is with practically any large business), it's not like Microsoft has been running child sweatshops or dumping toxic waste in the local drinking water. It just seems way out of proportion.

So no matter what the people in Redmond do, it seems like there's always somebody pissed off at them. And it's a shame, because they really do do some good work. The .NET world has lots of neat technologies and is a very cool place for developers. Even though OpenOffice may be good enough for many, MS Office is by far the best office suite available. And, last but not least, Windows, despite it's flaws (and they are legion) is a very impressive feat of software engineering. Not to mention that Microsoft employs a number of very bright people.

So, to the Linux community, I say, let's give Microsoft a chance. I'm not asking you to like MS, or to start using any of their products. Let's just be honest and realistic. Most people in the community aren't shy about placing the blame on them, but give credit where credit is due. We rightly object when people blame free software for not being a panacea, what with hardware incompatibilities and the lack of certain software. We should at least hold MS to the same standard and not judge them for failing to satisfy everyone.

Obscurity or nothing?

pageer@skepticats.com (Peter Geer)

Eugenia at OSNews ran an editorial today regarding password storage in the popular Pidgin IM client (formerly known as Gaim). Her complaint was that Pidgin stores the user's passwords as plain text, which is obviously insecure. However, the developers strenuously object to her proposed solution: obfuscation.

Basically the situation is that Pidgen does not have an encryption scheme for IM account passwords. Some people have submitted patches, e.g. to use gnome-keyring, but the developers don't want to tie themselve to any particular keyring implementation. So, in the absence of any real security, some users have suggested adding fake security, such as ROT13 encoding the passwords. Their argument is essentially that such obfuscation is better than nothing. The Pidgin devs, on the other hand, argue that this does nothing but provide a false sense of security, which is actually worse than being insecure.

I think the Pidgin developers have a good point here. For one thing, the use-case for obfuscation seems to be a little shakey. The general idea is that obfuscation would keep your passwords safe from nontechnical users who would have local access to your machine, such as a parent or co-worker. Presumably they would be able to find the accounts file, but not figure out the obfuscated password. The problem with this is that tools and methods to "recover" IM passwords are all over the net. All you have to do is Google it. Obfuscation would only stop people who are too stupid to use a search engine and those who are too unmotivated to use one. And for those types of attackers, proper file permissions and locking your terminal when you get up from the desk would be sufficient anyway.

To me, this sounds like a "shut up" feature, i.e. the kind of feature a developer implements not because it is actually good or useful, but because the customer thinks it is good and useful. "Fine, I'll do it if it'll shut you up!" This doesn't add any real security and it's not clear that it would stop even non-technical users who actually want your password, but it would make users feel better. That's the kind of thing you do in the commercial world for a whiney customer. I don't think it has any place in the open-source world.

Mac and UNIX security

pageer@skepticats.com (Peter Geer)

You often hear Mac and Linux people going on about how their operating system doesn't suffer from viruses and malware. They claim it's because their OS is inherently more secure. The Windows people then retort that the real reason is that hardly anybody uses MacOS or Linux, so the hackers just don't put much effort into it. A huge flamewar then ensues, in which very few of the participants actually know what they're talking about.

I read an InfoWorld blog on this very topic today. While I found it largely unremarkable, I did take issue with one passage.

The difference isn't market share, it's the foundation of the operating systems. Given that most virus authors and hackers are in it for the ego, don't you think that there would be a huge incentive to be the first one to write a widespread OS X, Linux, or FreeBSD virus?

There are two problems with this passage. First, there's the claim that "most virus authors and hackers are in it for the ego." That may have been true 10 years ago, but not anymore. These days, many hackers and malware writers are in it for the money. Some of them are even in bed with organized crime. It's not about learning how systems work anymore. Now it's big business.

In light of this, it's just absurd to dismiss the possibility that market share is not an issue. Just look at the numbers. On desktop PCs, Windows has well over 80% market share - probably more like 90%. So if you're trying to build a big botnet, what are you going to target? Windows is generally less secure by default, has more non-technical users, and if you get just 10% of them, that's more systems than if you got every Mac out there. With numbers like that, targeting anything other than Windows is just a waste of time.

Of course, the underlying operating system may have something to do with why Mac and Linux users have fewer security worries. However, it's certainly not the only reason. The default configuration of each system is another big reason - the out-of-the-box Windows configuration has historically been wide-open, while MacOS X and Linux are fairly secure by default. But if we're going to be honest, we can't ignore market share. It may or may not be the primary reason, but to claim it's not an issue is just wishful thinking.

On e-mail encryption

pageer@skepticats.com (Peter Geer)

You know what pisses me off? Bad arguments. As a philosophy major, I read lots fo bad arguments. As a "philosophy hobbyist," I still do. And nothing makes me madder than those arguments that are so hideously wrong you don't even know where to begin explaining the problem.

I ran into one of those at work today. Because of HIPAA and other such laws, we're looking into encryption products (laptop drives, database, e-mail, etc.), and I was stupid enough to volunteer for the assignment. Of course, it proably doesn't matter, because the whole effort is doomed from the start. There is absolutely zero buy-in from our IT staff on the idea of deploying encryption products. The only person who is even remotely pleased with the idea is the boss, and I'm the only one of the staff who isn't dead-set against it. The network administrator is particularly against the idea, and without his support, it just isn't going to happen.

Anyway, the particular comment that pissed me off was concerning anti-virus filtering in our mail system. Basically, one of our network people was concerned that we might get encrypted viruses, and because they're encrypted, the anti-virus filters wouldn't be able to catch them. As support, this person cited a virus report from earlier this week about a "new" virus that works by enclosing the executable in a password-protected ZIP archive with the password in the message body. This "encryption" stops the virus filter from catching it, but if we just blocked all encrypted files, we wouldn't have to worry about it.

Now, to me, this entire argument sounds like complete bull. Of course, I'm not an expert on e-mail, network security, or encryption, so I could be wrong. If that's the case, somebody please correct me. But the more I think about it, the more I feel like this is one of those arguments that's just barely true enough that you can make it with a straight face, and yet still have it be completely misleading.

First, I certainly never suggested that we allow any old encrypted file through the mail filters. Just because a file is encrypted doesn't automatically make it trustworthy. An attacker could certainly find a freeware symetric encryption utility from FooBaz Questionable Software, LLC, use it to encrypt a virus, and send it to everyone in the world along with the decryption key and instructions on how to get the naked pictures of Pamela Anderson out of the encrypted file. That would just be a variation on the password-protected ZIP file trick.

My choice would be to use a standard public-key system, like PGP or GnuPG. If you stick to allowing just encrypted messages in that format, then the "virus problem" goes away. After all, the whole point of public-key cryptosystems is that the recipient of the encrypted file already has the decryption key before the file is even encrypted. Hell, the recipient is the one who generates both of the keys. To send public-key encrypted mass-mail, you'd have to encrypt the malicious attachment separately for each recipient. And since many recipients won't have a key pair, or the attacker won't the recipient's public key, the target audience is dramatically cut at the outset.

Plus you can have accountability in public-key cryptosystems. After all, that's what digital signatures are for - so you can know who sent a message. If you're really paranoid, you could only accept encrypted attachments from messages signed by someone you trust.

Of course, nothing about public-key cryptography can prevent a someone with your public key from intentionally sending you a virus. And that's where the "just true enough" part comes in. Yes, an encrypted virus sent by a malicious attacker trusted by user won't be detected by the mail filters. Is this a problem? Well, if you have to do business with people you can't trust, then I guess so. But if you don't publish your public keys and don't do business with 13 year old script-kiddies, I don't see it as a big concern. Besides, this is negated by the other anti-encryption argument this person has been pushing: that the data we're dealing with isn't really important enough to bother with.

So let me get this straight: we can't do e-mail encryption because we're swapping unimportant data with untrustworthy people. My question is: then why are we even bothering? We ought to just lock the doors and start browsing the want ads!

Sigh.... I'm done blowing off steam now. Time to start working on my CV.