TCP/UDP Injections

[Aiden]

I had an idea while sitting in my networks class and wrote it down to ask some uber smart friends later. The logs are below. I thought I'd share it just because it's an interesting thought, and it might spark some conversation. ;)

<MoralExpl> Hmm
<MoralExpl> Active Connections
<MoralExpl> Proto Local Address Foreign Address State
<MoralExpl> TCP Zell:1063 kencoy.is.UN.hackable.net:6697 ESTABLISHED
<MoralExpl> TCP Zell:1064 66.252.27.202:6669 ESTABLISHED
<MoralExpl> theoretically
<MoralExpl> If you knew the local port someone was ircing or running another application on
<MoralExpl> Could you not spoof a packet to their IP addressed to that port and have it automatically forwarded to the computer
<MoralExpl> with whatever information for the application you wanted to give?
<duper> you're talking about injecting packets in the tcp stream?
<duper> that's going to be extremely difficult because you won't know the next tcp sequence number
<MoralExpl> gotcha
<duper> this is the same principle that tcp sequencing (a.k.a. blind IP spoofing) operates on
<duper> when tcp stacks where still using sequential sequence numbers, this was extremely easy
<duper> nmap -O will tell you what kind of tcp sequencing strength a host has
<MoralExpl> gotcha
<MoralExpl> thanks duper
<MoralExpl> couldnt you flood
<duper> now, there are other things you can do, simply by knowing the src port and dst port for the connection pair
<MoralExpl> please continue.
<duper> MoralExpl: yeah, but the problem is that the tcp window is going to be advancing, so the next sequence number could have been sent already
<MoralExpl> gotcha
<MoralExpl> I was thinking flooding 1-1million
<MoralExpl> or something
<MoralExpl> hoping one hits
<MoralExpl> but seems
<duper> the window is how many sequence numbers the server is going to allow to be ACKed before it stops accepting packets as part of the tcp stream
<MoralExpl> Ah
<duper> this is all in the TCP RFC
<duper> i mean, yeah i suppose it is possible, remember how people were cache poisioning the DNS RR ID's, those were only 16-bit, guessing a 32-bit number is going to be much more difficult
<duper> we're talking 4 billion possible combinations
<duper> now one thing that you can do with knowledge of the src port / dst port is nuke the connection
<duper> i.e. send an icmp port unreach spoofed from the server to the client (or vice versa) with the correct src and dst ports (assuming that your network's egress filtering and their network's ingress filtering permits the packet)
<duper> if you want to see an implementation of this, take a look at Satanic Mechanic's nuke.c
<MoralExpl> ill look at that
<MoralExpl> sounds interesting
<MoralExpl> anyway, I'm off to bed. duper thank you for the response.
<duper> heh, drusepth wasn't even here for the response
<MoralExpl> ill drop him the logs tomorrow
<duper> the other problem with all this
<duper> even if you got the src port / dst port / tcp flags / sequence number / etc. correct
<duper> unless you're sniffing the connection already you're blind, so you don't know what state the application layer protocol is going to be in
<duper> like if i was sending a PRIVMSG to #antilimit
<duper> TCP could decide to split the packet up at PRIV and send the rest "MSG #antilimit :test" in another packet
<duper> and your packet could come in between those
<duper> (the one your injected)
<duper> there's a tool that does this called monkey in the middle by dugsong
<drusepth> udp packets don't have sequence numbers iirc
<duper> when they're in that state
<duper> they don't.
<duper> they have checksums, but it's a stateless protocol so they don't need sequence numbers
<duper> if a packet arrives out of order it doesn't matter
<duper> if it doesn't arrive at all you do your own transport management by sending it again
<duper> now, you can kind of treat UDP as a connection based protocol with BSD sockets by binding it to a particular address and src/port pair
<duper> then using recvfrom() and sendto() instead of recv() or send()
<duper> 20:46 <duper> !whatis recv
<duper> 20:46 <M3t4B0t> recv (2) - receive a message from a socket
<duper> 20:46 <M3t4B0t> recv (3p) - receive a message from a connected
<duper> socket
<duper> recv(2) is the system call and recv(3p) is the libsocket library call
<duper> 20:48 <duper> ) UDPSocket.instance_methods
<duper> 20:48 <M3t4B0t> [:connect, :bind, :send, :recvfrom_nonblock, :addr, :peeraddr,
<duper> :recvfrom, :close_read, :close_write, :shutdown, :setsockopt,
<duper> :getsockopt, :getsockname, :getpeername, :recv, :recv_nonblock,
<duper> etc.
<duper> note that you can use the connect() function on a UDP socket, even though it's a connection-less protocol
<duper> make sense?;)
<drusepth> For the most part :)
<duper> so this is why DNS uses UDP
<duper> because it's not worth performing the three-way TCP handshake and performing transport layer management when not very much data is going to be sent in the first place
<duper> however, during zone transfers DNS _does_ use tcp/53 because an entire SOA zone can be much larger than just a single DNS RR
<duper> somebody is probably going to say zone transfers are often disabled, BUT the smart network administrators are just going to add a firewall rule that drops packets destined to tcp/53 and allow AXFR's to occur between primary and secondary or caching-only nameservers because it's more efficient

[IceDane]

It's a cool idea, but it isn't anything revolutionizing. Like he said, it would be about predicting sequence numbers, but it seems f***ing with UDP streams should be much of a problem.

The UDP header only contains source addr, dest addr, length of the header and the checksum, which is the checksum of the pseudo header. All of that can be easily spoofed.