[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Full-disclosure] SQL Tabular data stream payload in initial SYN?
- To: full-disclosure <full-disclosure@xxxxxxxxxxxxxxxxx>
- Subject: [Full-disclosure] SQL Tabular data stream payload in initial SYN?
- From: Mark <fd@xxxxxxxxx>
- Date: Wed, 04 May 2005 14:35:19 -0500
We captured these packets last evening and I was just wondering if
anyone here had seen anything like this before. I certainly see SYN
connect attempts to TCP 1433 fairly frequently, but usually with a
source port of 6000 and a window size of 16384. And, never with payload
in the initial SYN.
For background, there is no host at the address the SYNs were directed at.
Googling does come up with some Tabular Data Stream exploits but all the
ones I've found require the TCP handshake to complete for the exploit to
work. This seems to be blindly putting some kind of payload in the
initial SYN.
An ethereal decode comes up with the following; but I don't know enough
about TDS (if that is what this even is) to know if this is normal or
not. With that said, the second one doesn't look right to me. By the
time the decoder picks up on this 'stream' the 0x4d4d pattern has
already started.
Tabular Data Stream size=52 pos=54>
Type: TDS7/8 0x12 Packet (0x12) size=1 pos=54 show=0x12 value=12
Status: Last buffer in request or response (1) size=1 pos=55 show=1 value=01
Size: 52 size=2 pos=56 show=52 value=0034
Channel: 0 size=2 pos=58 show=0 value=0000
Packet Number: 0 size=1 pos=60 show=0 value=00
Window: 0 size=1 pos=61 show=0 value=00
Tabular Data Stream size=484 pos=106>
Type: Unknown (0x4d) size=1 pos=106 show=0x4d value=4d
Status: Unknown (77) size=1 pos=107 show=77 value=4d
Size: 19789 size=2 pos=108 show=19789 value=4d4d
Channel: 19789 size=2 pos=110 show=19789 value=4d4d
Packet Number: 77 size=1 pos=112 show=77 value=4d
Window: 77 size=1 pos=113 show=77 value=4d
[Unreassembled Packet: TDS] size=0 pos=14
Here are the raw tcpdump packets. The first packet only appears once.
The second one is repeated five more times with what appears to be the
timing of a normal TCP back off. Even though the first and second
packets both have the same source port and sequence number, the second
is obviously not a retransmission of the first.
19:09:54.729985 83.149.83.7.29922 > no.host.is.here.1433: S [tcp sum ok]
2669005699:2669005699(0) win 65535 (ttl 114, id 24750, len 4
0)
0x0000 4500 0028 60ae 0000 7206 5332 5395 5307 E..(`...r.S2S.S.
0x0010 c0ed 2d66 74e2 0599 9f15 cb83 0000 0000 ..-ft...........
0x0020 5002 ffff 35de 0000 0000 0000 0000 P...5.........
19:09:56.803510 83.149.83.7.29922 > no.host.is.here.1433: S [tcp sum ok]
2669005699:2669006235(536) win 65535 (ttl 114, id 26674, len
576)
0x0000 4500 0240 6832 0000 7206 4996 5395 5307 E..@xxxxxxxxxxxx
0x0010 c0ed 2d66 74e2 0599 9f15 cb83 0000 0000 ..-ft...........
0x0020 5002 ffff 4fbc 0000 1201 0034 0000 0000 P...O......4....
0x0030 0000 1500 0601 001b 0001 0200 1c00 0c03 ................
0x0040 0028 0004 ff08 0002 1000 0000 4d4d 4d4d .(..........MMMM
0x0050 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0060 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0070 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0080 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0090 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x00a0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x00b0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x00c0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x00d0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x00e0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x00f0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0100 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0110 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0120 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0130 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0140 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0150 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0160 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0170 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0180 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0190 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x01a0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x01b0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x01c0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x01d0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x01e0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x01f0 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0200 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0210 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0220 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
0x0230 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d 4d4d MMMMMMMMMMMMMMMM
And then, nothing.
They could be spoofed, but they don't look like damaged packets to me as
the checksum is ok and the payload doesn't appear scrambled.
So, what do you think? Just some stray packets? Or an exploit I'm not
familiar with?
Thanks in advance for any insight you can provide.
Mark
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/