Anatomy of a hack: SBS 2000

A few years ago (August 2002), my home server got hacked. I dealt with it fairly quickly, but it took me a while to really understand what had happened, because I was more naïve about security in those days.

The server was running Microsoft Small Business Server (SBS) 2000. When I installed it, I picked a fairly strong password for the built-in domain Administrator account. However, when I installed SQL Server I left the “sa” password blank: this was the default, and I figured that I could choose a suitable password later. I didn’t have any important data in there, just an inventory of my books/comics, so I wasn’t too worried about anyone breaking into it. This was my first mistake! Nowadays I specify passwords for every account, and new versions of SQL Server (starting with SP3 for SQL 2000) won’t let you have a blank password for the “sa” account.

SBS also asked me to configure the firewall, so I could tick the boxes for anything that needed remote access. When I looked through the list of applications, there were a few cases where I thought “Hmm, I don’t need remote access at the moment, but that might come in useful later” so I ticked the box anyway; this included SQL Server. This was my second mistake! It’s much better to minimise your “attack surface”, so that you only expose the functionality that you have to. (As an analogy, nobody can break into your house via the skylight if you don’t have a skylight.)

Aside from database queries, the “sa” account can also be used to run extended stored procedures. These are basically normal Windows programs, 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 someone 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.

I installed the server in May 2001, while I was using a dial-up connection. However, I then got ADSL installed in November 2001, which made me more of a target: my server had a permanent connection to the internet, rather than hopping on and off. I re-installed the server in June 2002 (after a hard drive failure) and that was when I checked the extra boxes for remote access.

By August 2002, I’d noticed that the internet connection tended to die periodically – I think this is because I was using a USB ADSL modem rather than an ethernet router. On this particular day, I went to reboot the server as usual. I then saw a message from the anti-virus software, saying it had moved two files on the C drive which were infected. They were both called “server.exe” – one was in the root, and one was in the winnt\system32 folder. After the reboot, I noticed a service running – “Serv-U FTP Server”. That’s not something I’d installed, and it was running out of a random folder in the profiles area. Suspiciously, it was created at the same time as the anti-virus software found the infected files. In fact, I had two copies of the folder structure (on different drives), but only one contained files.

I got rid of that service, and tried to delete the folders. However, they had names like AUX and COM1, so Windows Explorer couldn’t delete them because it thought that they were serial ports. Q120716 had the solution, although it requires you to own a copy of the Windows 2000 Resource Kit to get the necessary file – fortunately, I’d already bought a copy of that book/CD.

There were some other issues too – for instance, the Guest account had wound up in the Administrators group. I removed it, and disabled it – I suspect that the attacker got in via SQL Server, then made that change as a backdoor. From my reading, it looks like the FTP service is something that “warez d00dz” use, as a way to hijack a server as a file-dump.

I did my best to repair the obvious damage, then I shut that server down for a few days. I bought a new ethernet router (an Alcatel Speedtouch 510) which has a basic firewall built into it, so I told that to block all ports by default and only allow through the ports which I specifically needed. I didn’t turn the server back on again until I was confident that it wouldn’t get re-infected from the internet.

The only silver lining in all this is that I was protected when the Slammer worm hit in January 2003. This worked in a very similar way: it connected to SQL Server installations across the internet, so you were safe if you’d blocked that port on your firewall (or if you didn’t run SQL Server).

Leave a Reply

Your email address will not be published. Required fields are marked *