Ping-flooding attack: what remains "off-screen" or about the benefits of meticulousness
Actually, I open a topic based on habrahabr.ru/post/157207
The topic is interesting, but some simple but important points remained behind the scenes. It's a pity. Who cares what - please.
If we discard the trivial analysis of icmp, then the most interesting part of the material will be the statement (confirmed by screenshots) that some target (Windows, I suppose) systems respond to icmp-echo requests in which the destination ip corresponds to the ip of the pinged system, but the destination mac is broadcast. True, there is a certain inconsistency between the screenshot and the text, but we will consider it a typo and focus on the picture.
')
The picture is really interesting, especially when you consider that this should not be. Once, in times of pampering with such things through nemesis, I clearly learned that for Win this trick does not work. It was all the more surprising - well, the screenshots author didn’t fake it.
I decided to repeat the experiment. The simplest method without using any utilities to generate arbitrary packages from the Nix console:
arp -s ip ff: ff: ff: ff: ff: ff
ping ip
The ip sought is not responding. We check by tcpdump that the packets of the desired type leave the interface.
Immediately a question arose. Or maybe it's the victim system? In my case, it was Win XP SP3. The author of the topic confirmed that he, too ... It became interesting. Found the system available to me via RDP. I made sure that icmp requests with broadcast dst mac reach it. No answer.
I repeated the experiment on Win 2008 - the result is positive. Some theories began to move in my head (they were voiced in comments to the topic), but everything turned out to be much simpler.
Well, of course it's OH!
Next Generation TCP / IP Stack.
technet.microsoft.com/en-us/network/bb545475.aspx
Indeed, what was not true for XP became a reality for Vista 7,2008
Google helped find the experimenters who were surprised by the “surprise”.
www.packetstan.com/2010/08/windows-lan-addressing-validation-and.html
...
Response to the broadcasting of the Internet.
blog.taddong.com/2010/09/more-wpa2-hole-196-reflections-and.html
Josh mentioned Windows Vista and 7 accept LAN broadcast addresses sent to unicast IP addresses . I confirmed that Windows Vista SP2 under VMware Fusion 3.1.1 (LAN) in fact does not accept it. Windows Vista and 7 accept TCP broadcast traffic. New TCP / IP stack implements can always include hidden gifts!
Windows XP SP3 (WLAN) doesn’t need to be used, broadcast or multicast. So, does this mean XP is " more secure regarding Hole 196" than Vista & 7? ;)
What-what is written here? Will TCP with a broadcasted mac-ohm destination also work? Check it out ... Again we manually set up the arp bundle, telnet to the open port 80 of the server under Win 2008 and yes. Works.
23: 53: 53.179517 00: 0c: 29: 22: 71: 6c> ff: ff: ff: ff: ff: ff , ethertype IPv4 (0x0800), length 74: 10.xx.4.80.35261> 10.xx. 4.20.80: Flags [S], seq 759040421, win 5840, options [mss 1460, sackOK, TS val 2823711033 ecr 0, nop, wscale 7], length 0
23: 53: 53.180123 00: 0c: 29: 81: 23: 05> 00: 0c: 29: 22: 71: 6c, ethertype IPv4 (0x0800), length 74: 10.xx.4.20.80> 10.xx. 4.80.35261: Flags [S.], seq 1483497967, ack 759040422, win 8192, options [mss 1460, nop, wscale 8, sackOK, TS val 64239843 ecr 2823711033], length 0
23: 53: 53.180405 00: 0c: 29: 22: 71: 6c> ff: ff: ff: ff: ff: ff, ethertype IPv4 (0x0800), length 66: 10.xx.4.80.35261> 10.xx. 4.20.80: Flags [.], Ack 1, win 46, options [nop, nop, TS val 2823711033 ecr 64239843], length 0
On the other hand ... Well, it works, so what? The same experiment with the linux system had, by the way, the same result :)
But the white spots became a little less. To whom as, but for me it is not bad. And yes, thanks to the author of the topic that motivated the experiment.
The topic is interesting, but some simple but important points remained behind the scenes. It's a pity. Who cares what - please.
If we discard the trivial analysis of icmp, then the most interesting part of the material will be the statement (confirmed by screenshots) that some target (Windows, I suppose) systems respond to icmp-echo requests in which the destination ip corresponds to the ip of the pinged system, but the destination mac is broadcast. True, there is a certain inconsistency between the screenshot and the text, but we will consider it a typo and focus on the picture.
')
The picture is really interesting, especially when you consider that this should not be. Once, in times of pampering with such things through nemesis, I clearly learned that for Win this trick does not work. It was all the more surprising - well, the screenshots author didn’t fake it.
I decided to repeat the experiment. The simplest method without using any utilities to generate arbitrary packages from the Nix console:
arp -s ip ff: ff: ff: ff: ff: ff
ping ip
The ip sought is not responding. We check by tcpdump that the packets of the desired type leave the interface.
Immediately a question arose. Or maybe it's the victim system? In my case, it was Win XP SP3. The author of the topic confirmed that he, too ... It became interesting. Found the system available to me via RDP. I made sure that icmp requests with broadcast dst mac reach it. No answer.
I repeated the experiment on Win 2008 - the result is positive. Some theories began to move in my head (they were voiced in comments to the topic), but everything turned out to be much simpler.
Well, of course it's OH!
Next Generation TCP / IP Stack.
technet.microsoft.com/en-us/network/bb545475.aspx
Indeed, what was not true for XP became a reality for Vista 7,2008
Google helped find the experimenters who were surprised by the “surprise”.
www.packetstan.com/2010/08/windows-lan-addressing-validation-and.html
...
Response to the broadcasting of the Internet.
blog.taddong.com/2010/09/more-wpa2-hole-196-reflections-and.html
Josh mentioned Windows Vista and 7 accept LAN broadcast addresses sent to unicast IP addresses . I confirmed that Windows Vista SP2 under VMware Fusion 3.1.1 (LAN) in fact does not accept it. Windows Vista and 7 accept TCP broadcast traffic. New TCP / IP stack implements can always include hidden gifts!
Windows XP SP3 (WLAN) doesn’t need to be used, broadcast or multicast. So, does this mean XP is " more secure regarding Hole 196" than Vista & 7? ;)
What-what is written here? Will TCP with a broadcasted mac-ohm destination also work? Check it out ... Again we manually set up the arp bundle, telnet to the open port 80 of the server under Win 2008 and yes. Works.
23: 53: 53.179517 00: 0c: 29: 22: 71: 6c> ff: ff: ff: ff: ff: ff , ethertype IPv4 (0x0800), length 74: 10.xx.4.80.35261> 10.xx. 4.20.80: Flags [S], seq 759040421, win 5840, options [mss 1460, sackOK, TS val 2823711033 ecr 0, nop, wscale 7], length 0
23: 53: 53.180123 00: 0c: 29: 81: 23: 05> 00: 0c: 29: 22: 71: 6c, ethertype IPv4 (0x0800), length 74: 10.xx.4.20.80> 10.xx. 4.80.35261: Flags [S.], seq 1483497967, ack 759040422, win 8192, options [mss 1460, nop, wscale 8, sackOK, TS val 64239843 ecr 2823711033], length 0
23: 53: 53.180405 00: 0c: 29: 22: 71: 6c> ff: ff: ff: ff: ff: ff, ethertype IPv4 (0x0800), length 66: 10.xx.4.80.35261> 10.xx. 4.20.80: Flags [.], Ack 1, win 46, options [nop, nop, TS val 2823711033 ecr 64239843], length 0
On the other hand ... Well, it works, so what? The same experiment with the linux system had, by the way, the same result :)
But the white spots became a little less. To whom as, but for me it is not bad. And yes, thanks to the author of the topic that motivated the experiment.
Source: https://habr.com/ru/post/157799/
All Articles