4 ms·

No, not the MITM. A simple denial of service - I can terminate your TLS-over-TCP connection at will by sending a FIN or RST packet. More generally speaking, I

No, not the MITM. A simple denial of service - I can terminate your TLS-over-TCP connection at will by sending a FIN or RST packet. More generally speaking, I can alter the state of your secure over-TCP connection with an unauthenticated packet. Compare this to ESP where every packet that can potentially alter the state is first authenticated.

xyzzy123 14y ago
Blind, or with some way to observe the sequence numbers? If it's blind (e.g. window guessing) I'm interested in what your techniques are. If it's not blind and you don't have MITM and you don't share a medium, I'm interested in how you're doing that. Challenge: I have the following TCP connection open (oh man I'm really asking for it, but what the heck :) tcp 0 0 192.168.0.10:52352 216.240.155.220:80 ESTABLISHED 16284/nc If you can terminate it with a FIN or an RST in the next hour, I'll post proclaiming your victory. If either the box or my local link drops, we'll call it a draw.
- tcoppi 14y ago
  There aren't that many combinations you need to brute force in order for it to work. http://www.blackhatlibrary.net/TCP-RST_Injection http://www.blackhatlibrary.net/TCP-RST_Injection has sample code and an explanation of the attack. EDIT: Just downloaded the sample code and it looks like it won't quite work out of the box, but I'm sure someone with more time could through together something with scapy or similar pretty quickly.
  - xyzzy123 14y ago
    Well I did post the source port, which reduces the effort by a factor of tens of thousands... also, the up-thread did say "with a single fake RST or FIN packet"... which is why I mentioned window guessing... Also, crap, I'm an idiot. Let me do that non-natted ;) tcp 0 0 216.240.155.220:4007 60.225.131.226:43972 ESTABLISHED 18694/nc
    - xyzzy123 14y ago
      Write failed: Broken pipe Well done! Also, you didn't packet me off the Internet, which was nice :) Bet you can't do it with one packet though!
      - 18pfsmt 14y ago
        Sorry for the beginner questions, but how did the remote port change from 80 to 4007? Are you NATed on both ends? And, how did you go about getting the IP:port of your local router? Are you using some tool, or do you have root on your office router?
        xyzzy123 14y ago
        Nah not silly questions at all. I changed the remote port from 80 to 4007 because I figured my web server might get DoS'd :) I have a crappy cable modem which is kind of a "research problem" to root, so I did the netstat on the web server end to get the local port.
      - ay 14y ago
        Could it have been your NAT which terminated the connection due to inactivity ? Quite a few stacks have implemented RFC5961, which should make this attack rather challenging. (Though, I totally agree with the fundamental problem).
        xyzzy123 14y ago
        PREFIX: this is going to sound really cynical. Also, I haven't read RFC5961, so thanks :) Yeah, actually it might have been. But I prefer to give HN the benefit of the doubt. Umm I try and be gentle. But let's talk about the fundamental problem, since you appear to understand it. TCP-RST DoS is like the worst denial of service ever, since it has such massive negative amplification. You're spending like something like 30k * (required window guess packets) to interrupt one connection, which requires like say less than 10 packets to re-establish. Unless you're talking about BGP, which shit, we normally use TCP-MD5 for anyway. Even commodity home bullshit throws most of your packets away for free. I take things quite slowly. The normal HN methodology is to go "Incorrect. blah blah blah.". Reality is nuanced and complicated. I try and avoid doing that, because honestly most statements are actually right when you squint at them the right way. Unfortunately, I get the most fake internet points when I say stupid and ultimately unsupportable bullshit while drunk. I still try to avoid doing that :/ But ahhhh here I go anyway. The nuanced version of this is that most people's devices are going to get DoS'd way harder by fake ipsec traffic which forces checksums in CPU than it is by out of sequence packets which get handled in hardware. But why don't we live in this fantasy world where we can all terminate TCP connections with imaginary sniper packets and ipsec solves everything.

xyzzy123 14y ago

Blind, or with some way to observe the sequence numbers? If it's blind (e.g. window guessing) I'm interested in what your techniques are. If it's not blind and you don't have MITM and you don't share a medium, I'm interested in how you're doing that. Challenge: I have the following TCP connection open (oh man I'm really asking for it, but what the heck :) tcp 0 0 192.168.0.10:52352 216.240.155.220:80 ESTABLISHED 16284/nc If you can terminate it with a FIN or an RST in the next hour, I'll post proclaiming your victory. If either the box or my local link drops, we'll call it a draw.

tcoppi 14y ago
There aren't that many combinations you need to brute force in order for it to work. http://www.blackhatlibrary.net/TCP-RST_Injection http://www.blackhatlibrary.net/TCP-RST_Injection has sample code and an explanation of the attack. EDIT: Just downloaded the sample code and it looks like it won't quite work out of the box, but I'm sure someone with more time could through together something with scapy or similar pretty quickly.
- xyzzy123 14y ago
  Well I did post the source port, which reduces the effort by a factor of tens of thousands... also, the up-thread did say "with a single fake RST or FIN packet"... which is why I mentioned window guessing... Also, crap, I'm an idiot. Let me do that non-natted ;) tcp 0 0 216.240.155.220:4007 60.225.131.226:43972 ESTABLISHED 18694/nc
  - xyzzy123 14y ago
    Write failed: Broken pipe Well done! Also, you didn't packet me off the Internet, which was nice :) Bet you can't do it with one packet though!
    - 18pfsmt 14y ago
      Sorry for the beginner questions, but how did the remote port change from 80 to 4007? Are you NATed on both ends? And, how did you go about getting the IP:port of your local router? Are you using some tool, or do you have root on your office router?
      - xyzzy123 14y ago
        Nah not silly questions at all. I changed the remote port from 80 to 4007 because I figured my web server might get DoS'd :) I have a crappy cable modem which is kind of a "research problem" to root, so I did the netstat on the web server end to get the local port.
    - ay 14y ago
      Could it have been your NAT which terminated the connection due to inactivity ? Quite a few stacks have implemented RFC5961, which should make this attack rather challenging. (Though, I totally agree with the fundamental problem).
      - xyzzy123 14y ago
        PREFIX: this is going to sound really cynical. Also, I haven't read RFC5961, so thanks :) Yeah, actually it might have been. But I prefer to give HN the benefit of the doubt. Umm I try and be gentle. But let's talk about the fundamental problem, since you appear to understand it. TCP-RST DoS is like the worst denial of service ever, since it has such massive negative amplification. You're spending like something like 30k * (required window guess packets) to interrupt one connection, which requires like say less than 10 packets to re-establish. Unless you're talking about BGP, which shit, we normally use TCP-MD5 for anyway. Even commodity home bullshit throws most of your packets away for free. I take things quite slowly. The normal HN methodology is to go "Incorrect. blah blah blah.". Reality is nuanced and complicated. I try and avoid doing that, because honestly most statements are actually right when you squint at them the right way. Unfortunately, I get the most fake internet points when I say stupid and ultimately unsupportable bullshit while drunk. I still try to avoid doing that :/ But ahhhh here I go anyway. The nuanced version of this is that most people's devices are going to get DoS'd way harder by fake ipsec traffic which forces checksums in CPU than it is by out of sequence packets which get handled in hardware. But why don't we live in this fantasy world where we can all terminate TCP connections with imaginary sniper packets and ipsec solves everything.