full-disclosure - SQL Tabular data stream payload in initial SYN?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Wed May  4 20:35:26 2005
From: fd at mchsi.com (Mark)
Subject: SQL Tabular data stream payload in initial SYN?

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..@....r.I.S.S.
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