All the Perl that's Practical to Extract and Report

MS SQL Server

Matts on 2003-01-25T18:56:56

So now I've discovered why I couldn't access my honeypot box at work last night or this morning. It was being DoS'd by multiple copies of an MS SQL Server worm. Normally my firewall log fills up fairly slowly with some uninteresting ports being hit. Here's just a small snippet of this morning's firewall log: 

Jan 25 05:36:00 gShield (default drop)  UDP 219.101.40.137:3996 -> ms-sql-m(1434)
Jan 25 05:36:12 gShield (default drop)  UDP ip68-5-107-161.oc.oc.cox.net:1030 -> ms-sql-m(1434)
Jan 25 05:37:58 gShield (default drop)  UDP 194.221.4.33:3913 -> ms-sql-m(1434)
Jan 25 05:39:19 gShield (default drop)  UDP orion.blazenet.net:2036 -> ms-sql-m(1434)
Jan 25 05:41:08 gShield (default drop)  UDP 81.23.225.71:1125 -> ms-sql-m(1434)
Jan 25 05:41:25 gShield (default drop)  UDP 128.111.78.166:2753 -> ms-sql-m(1434)
Jan 25 05:43:31 gShield (default drop)  UDP 131.247.211.3:1631 -> ms-sql-m(1434)
Jan 25 05:46:15 gShield (default drop)  UDP prosj2021.stud.hials.no:1382 -> ms-sql-m(1434)
Jan 25 05:48:09 gShield (default drop)  UDP 6387www0.rwc1.aens.net:4494 -> ms-sql-m(1434)
Jan 25 05:48:36 gShield (default drop)  UDP idejeha3.hh.se:4738 -> ms-sql-m(1434)
Jan 25 05:49:02 gShield (default drop)  UDP 62.128.28.47:2917 -> ms-sql-m(1434)
Jan 25 05:49:20 gShield (default drop)  UDP 142.232.102.210:1278 -> ms-sql-m(1434)
Jan 25 05:50:46 gShield (default drop)  UDP orange.aci.net:1955 -> ms-sql-m(1434)
Jan 25 05:50:55 gShield (default drop)  UDP 64.242.38.126:1661 -> ms-sql-m(1434)
Jan 25 05:51:14 gShield (default drop)  UDP dhcp-atl20-oae-aff066.atl.hp.com:1173 -> ms-sql-m(1434)
And it goes on like that. Not a single hit for any other ports for the entire time period.

Why is it that MS vulnerabilities, even for server technologies which they don't seem to have a monopoly in, seem to be exploited ever so more heavily than Unix/Linux or other product vulnerabilities?

slashdot

djberg96 on 2003-01-26T14:35:53

There was a story on slashdot about this. Five of thirteen root nameservers disabled - ouch. I've never heard a good thing about MS SQL Server (and not just because MS makes it). Why do folks use it? I'm genuinely curious.

Re:slashdot

Matts on 2003-01-26T22:58:11

It's actually not a bad database, so long as you understand its locking strategies. It's based off an old branch of Sybase, so it's got good heritage. We use it in an extremely large installation - over 25 replicated SQL servers globally. It all seems to work fairly well, though I try not to get involved.

However where MS SQL Server doesn't work is when you get deadlocks. Its locking strategy is significantly poorer than PostgreSQL or Oracle's (i.e. it doesn't do MVCC - reading commited data while other transactions are in progress) - you can either lock completely, or allow dirty reads (reading uncommited data!). And locking completely often causes lock ups. Same problem in Sybase though (and other locking databases).

Re:slashdot

dws on 2003-01-27T22:25:28

There's also the problem with row locks myseriously escalating into page locks (they may have changed this behavior in SQL Server 2000, but it was definitely a problem in 6.5 and 7).

honeypots

inkdroid on 2003-01-27T15:13:34

Microsoft is king of the hill when it comes to software (even if they don't have a monopoloy in certain areas)...

In case you haven't seen it yet, details about this particular worm can be found at CERT. Just out of curiosity, how long have you been running your honeypot, and have you had any other incidents? Has it been useful to run one?