John C. Kirk (johnckirk) wrote,
John C. Kirk

Computer security

I see that there's now a UK version of the "PC vs Mac" adverts. These are pretty similar to the original American versions, although there are fewer UK ones so far. Still, I think that they're quite funny, and I actually prefer the UK ones, mainly due to the actors involved; the "I'm a PC" guy is very enthusiastic about his stupid ideas. Sample quote: "Eye of the tiger! Claw of the eagle! Tentacle of the octopus!" (The UK adverts were done by Mitchell and Webb, and there's a good clip from their sketch show here.)

As a counterpoint to the "Viruses" advert, there's a Ctrl+Alt+Del strip which offers an alternate theory, and I think that's also quite funny. (I read that before I'd seen any of the adverts, which may have coloured my opinions a bit.)

More generally, while I found all these things amusing, and I'm sure that there are plenty of valid reasons for choosing a Mac, I wasn't particularly convinced by any of the technical arguments involved, particularly when it comes to security. Basically, I think that a lot of this comes down to the way you configure your system, rather than the choice of system.

Taking one quote from the Apple website: "A Mac offers a built-in firewall, doesn't advertise its existence on the Net, and isn't compromised within an hour of being turned on." The implication here is that a PC would be compromised that quickly (otherwise this isn't an argument in favour of choosing a Mac).

This would seem to be supported by some research: there was a story in USA Today a couple of years ago about some "honeypot" Windows machines that were monitored for attacks. In particular, they tested a machine running Small Business Server 2003 (the same system I use on my server at home), and said: "To hijack the Windows Small Business Server, the attacker finagled his way into a function of the Windows operating system that allows file sharing between computers. He then uploaded a program that gave him full control." This sounds quite worrying, but how was it done? It turns out that the Administrator password for that machine was "password". Nice.

There have often been similar problems with SQL Server: up until relatively recently (SP3 for SQL 2000), you could leave the "sa" (system administrator) password blank if you wanted to, and so lots of people did. However, this sa account could also be used to run extended stored procedures. These are basically normal Windows programs, rather than database queries, and there are situations where this can be useful (although I've never needed to do it). One particular example of this is "xp_cmdshell", which allows you to execute any program that's installed on the machine. This offers an attack vector: if people can connect to the SQL Server installation via the internet, log in as "sa", run "xp_cmdshell", and then use that to run "tftp" (Trivial FTP client, installed on Windows by default), they can download their own malicious code onto the server. In retrospect, I think that this is how my server was compromised a few years ago (back in my more naïve days).

As a side-note, this attack also works via "SQL injection", and that's a problem that can affect any database driven website that hasn't been properly programmed. Even if you don't have extended stored procedures (e.g. on a MySQL setup), SQL injection is still a risk, e.g. if an attacker can make unauthorised changes to your database.

Anyway, if you have a weak (or non-existent) password then this will make it a lot easier for people to do bad things, and this problem isn't specific to Windows. For instance, in Clifford Stoll's book "The Cuckoo's Egg", he talks about widespread use of default passwords on government/military computers (running VMS/UNIX) during the 1980s. On p223 (in my paperback edition), he describes an attacker logging into Air Force Systems Command, Space Division; username "Field" and password "Service" gave access to a completely privileged account.

A related issue is the way that passwords are stored. As a general rule of thumb, a system should never store passwords in "plain text". Instead, it would normally apply some kind of one-way function (aka hashing), and store the resulting values. For instance, if my password was "Apple", this might get hashed to "123", whereas if my password was "apple" then this might get hashed to "456". In other words, a small difference in the original password will correspond to a large difference in the hash. The idea is that it's very easy to get from the password to the hash, but pretty much impossible to go from the hash back to the password. When you log in to your computer, it will work out the hash for the password you typed, and then compare it to the stored hash; it doesn't directly compare the password you typed to the correct password.

This is all well and good, but it's not a good idea to make the global list of password hashes available to everyone, otherwise people can try a dictionary attack: this involves taking a word, getting its hash, and then searching through the list for any occurrences of that hash. (At a simple level, if I find anyone else with the same password hash as me, that means that I can log into their account with my password.) It should be quite difficult to get hold of that list, unless you have full system admin privileges, and at that point you can do a lot of damage anyway. However, back in my undergrad days (using UNIX), this list was freely available to everyone, on a read-only basis. I'm not an expert on that system, but I think the reason was that the login code had to be able to read that file to check the password you entered. Nowadays I believe it's done differently, with some kind of shadow volumes? Anyway, my point is that you can get security problems on lots of systems, and it just depends on how well they've been configured.

The main problem is that lots of people who use computers aren't experts; this applies to homes and also to some businesses (particularly small companies who can't afford to hire dedicated IT staff). As an example of this, I saw something the other day that I found rather worrying - a guy wanted to access his work PC remotely, so he used Remote Desktop Connection (a Windows client application) to connect to Small Business Server across the internet, logged in as "Administrator" on there, then ran the VNC client on the SBS machine to connect to his work PC. He freely admitted that he didn't know much about computers, but the built-in Administrator account on SBS is almost certainly a domain admin account. Also, if you look at myth #2 on this page, it explicitly says that you should only use Remote Desktop to SBS for remote administration, not for running applications. Personally, I wouldn't recommend allowing that kind of remote access to desktop PCs at all, but if you do want to do it then there are better ways (e.g. port forwarding). I also think that it's a bad idea for people to be logged in with local admin privileges, let alone domain admin; that's something I'll elaborate on in a separate post.

Speaking of port forwarding, I recommend that anyone with an ADSL connection should have a decent (ethernet) router to stick in front of it (not just a USB thing). This should be set up to block all traffic by default, and only allow the things that you want. In my case, I allow ports 25/80/443 to go through to my home server (email/web), but everything else is blocked. That means that you can't establish a Remote Desktop connection (even if you know the password), and you can't connect to SQL Server (even if it had a blank password, or if there was a vulnerability like the one that the Slammer worm exploited). If you're not running your own server at home, you should be able to operate completely in "stealth mode". To check on your current visibility, you can go to GRC and use the "ShieldsUp!" tool (it's about half-way down that page, under "Hot Spots"). This approach is platform independent, i.e. it doesn't matter whether you use a Mac/PC/whatever - the router will protect them all. (It's not a complete solution, but it's certainly useful.)

More generally, I think that security is all about risk management: you need to make the appropriate trade-offs between security and useability in your particular environment. Default settings can help with this, but they won't work for everyone. For instance, in SQL 2005 extended stored procedures are disabled by default; that means that you have to explicitly enable them if you want them, which is a bit more work. Similarly, there are issues of backwards compatibility. For instance, Windows has a RestrictAnonymous setting, which is used when it's acting as a server, and it stops unidentified people from getting a list of all the shared folders and user accounts. However, using this setting will stop NT4 and 9x clients from working. So, should it be enabled by default on a new installation of Windows 2003? If you say yes, then that's a problem for the poor sysadmin who has to figure out why things have suddenly broken, and there would probably be people ranting about evil Microsoft forcing them to upgrade other machines. If you say no, it will probably stay disabled even when the client machines don't need it.

The overall solution is for people to know how their machines work, and that applies to any system. I'm currently reading the book "Protect Your Windows Network", which has some very good advice in it.
Tags: adverts, books, computers, security

  • Facebook spam

    2 months ago, I mentioned my new plan to deal with comment spam. That's worked very well: I've only had 1 dodgy comment since then (from a Russian…

  • Screening for gullibility

    I've received a few variations on the following message, claiming to be from PayPal: Dear PayPal Customer, You have added…

  • Comment spam

    Last year I mentioned that I was receiving a steady stream of spam comments, so I turned on CAPTCHA for anonymous users. That helped for a while,…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded