Lucene search
K

windows.arp.DoS.txt

🗓️ 17 Aug 1999 00:00:00Reported by Packet StormType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 35 Views

ARP flooding in Windows9X/NT forces user to click multiple messageboxes; needs a patch.

Code
`Date: Mon, 12 Apr 1999 13:59:54 +0200  
From: Joel Jacobson <[email protected]>  
To: [email protected]  
Subject: ARP problem in Windows9X/NT  
  
Hello all bugtraqers!  
  
I've found a problem in Windows9X/NT's way of handeling ARP packets.  
  
If you flood a computer at your LAN with the packet below, it's user  
will be forced to click a messagebox's OK button x times, where x is the number  
of packets you flooded with.  
  
I advice Microsoft to develope a patch for this problem, that let you  
choose to ignore all future messages of this type.  
  
There is no way to trace the flooder since the MAC address in the  
packet can be modified to anything. Bad configurated routers will  
not drop this packet. When I tested this problem on my LAN I could  
flood a computer on another C-net at my LAN without problems.  
  
The program NetXRay was used to preform the flood.  
The victims had to reboot their computer, or choose to click _very_  
many OK buttons.  
  
The ARP packet is build up like this:  
  
Ethernet Version II:  
Address: XX-XX-XX-XX-XX-XX --->FF-FF-FF-FF-FF-FF  
Ehternet II Protocol Type: ARP  
Address Resolution Protocol:  
Hardware Type: 1 (Ethernet)  
Protocol Type: 800  
Hardware Address: Length: 6  
Protocol Address: Length: 4  
Operations: ARP Request  
Source Hardware Address: XX-XX-XX-XX-XX-XX  
IP Source Address: <victim computer's IP>  
Destination Hardware Address: XX-XX-XX-XX-XX-XX  
IP Destination Address: <victim computer's IP>  
  
And in HEX the packet look like this:  
ff ff ff ff ff ff 00 00 00 00 00 00 08 06 08 00 06 04 00 01 00 00 00  
00 00 00 XX XX XX XX 00 00 00 00 00 00 XX XX XX XX  
(XX is what matters here)  
  
Hope a patch for this problem will be developed fast, cause this is a  
big problem for my school and probably also to others.  
  
I'm not a C programmer, and don't know how to write an exploit for  
this problem. So, if anyone else can develope an exploit, feel free to do so.  
  
Joel Jacobson.  
  
----------------------------------------------------------------------------------  
  
Date: Tue, 13 Apr 1999 11:44:12 +0200  
From: Joel Jacobson <[email protected]>  
To: [email protected]  
Subject: Answer to some questions I got about the ARP "bug"  
  
Hi.  
  
In the message I sent to BugTraq, XX XX XX XX is the victim's IP  
Address, in HEX.  
  
Example:  
If you want to flood IP 192.168.0.1 at your network you would enter  
this hex value: C0 A8 00 01  
  
(I tought this was obvious)  
  
Regards, Joel.  
  
----------------------------------------------------------------------------------  
  
Date: Tue, 13 Apr 1999 11:55:01 +0200  
From: Joel Jacobson <[email protected]>  
To: [email protected]  
Subject: Re: ARP problem in Windows9X/NT  
Parts/Attachments:  
1 Shown 20 lines Text (charset: ISO-8859-1)  
2 OK 202 bytes Application  
----------------------------------------  
  
[ The following text is in the "ISO-8859-1" character set. ]  
[ Your display is set for the "US-ASCII" character set. ]  
[ Some characters may be displayed incorrectly. ]  
  
Hello Gandalf,  
  
måndag, 12 april 1999, you wrote:  
  
gpc> Perhaps I am doing it wrong, but sending out arp requests like this only  
gpc> generates a single messagebox. If you send one or a million requests in  
gpc> the time it takes to click ok, no new messageboxes will appear.  
  
gpc> This is on NT4 sp4.  
Okey. Well, I tested this on a friend that run NT, don't know if he  
has sp4 installed or not. But still, the problems exist in Windows98,  
and if Microsoft has developed a fix for NT, why can't they release  
one for Windows98 too?  
  
gpc> The packet I am sending out seems a tad different from the one listed,  
gpc> the hex dump above seems to be missing the hardware address type.  
I've attached an example.  
This packet will attack the computer 192.168.0.1 on your network.  
  
Best regards,  
Joel mailto:[email protected]  
[ Part 2, Application/OCTET-STREAM (Name: "example.cap") 270bytes. ]  
[ Not Shown. Use the "V" command to view or save this part. ]  
  
----------------------------------------------------------------------------------  
  
Date: Tue, 13 Apr 1999 13:21:46 -0700  
From: [email protected]  
To: [email protected]  
Subject: Re: ARP problem in Windows9X/NT  
  
[[email protected] wrote]  
|  
| Unfortunetly i don't have a 98 to test on, or an non sp4 NT machines. For  
  
I do. It works against Windows 98.  
  
| BTW, this is all from linux 2.2.5.  
  
I've tried it from OpenBSD 2.4, FreeBSD 3.1 and Linux 2.2.x.  
  
--  
I live a world of paradox... My willingness to destroy is your chance for  
improvement, my hate is your faith -- my failure is your victory, a victory  
that won't last.  
  
----------------------------------------------------------------------------------  
  
Date: Tue, 13 Apr 1999 15:49:22 -0400  
From: Alan DeKok <[email protected]>  
To: [email protected]  
Subject: Re: ARP problem in Windows9X/NT  
  
[email protected] wrote:  
> Didn't test your code. Rolled my from the same libnet example, and it  
> does work against NT and 95/98.  
  
I tested yours against a number of machines at work. Summary:  
  
NT4 sp3 displays one requestor. While it's on-screen, any  
additional ARP packets are ignored. Clicking 'OK', and then sending  
more packets results in another requestor.  
  
95/98 displays one requestor per packet.  
  
Alan DeKok.  
  
----------------------------------------------------------------------------------  
  
Date: Tue, 13 Apr 1999 11:07:53 -0400  
From: [email protected]  
To: [email protected]  
Subject: Re: ARP problem in Windows9X/NT  
  
On Tue, 13 Apr 1999 [email protected] wrote:  
> [kay wrote]  
> | I started writing that proggie with plain syscalls, but it would only run  
> | on Linux, so I modified one of the examples in Route's Libnet 0.9 to do  
> | the stuff. I haven't tested it yes since I don't have LAN at home...  
>  
> Didn't test your code. Rolled my from the same libnet example, and it  
> does work against NT and 95/98.  
  
Your code, humerously enough, was almost exactly the same as mine, I was  
even using libnet. However neither your code nor mine causes more than  
one messagebox to appear on my NT4 sp4 machine.  
  
I actually tried this a month or two ago, and gave up since it seemed to  
have no effect on NT, I swear at the time I tested 95 and 98 too. Looking  
at it again, both your code and mine _do_ have the multi-messagebox effect  
on a 95B machine,  
  
Unfortunetly i don't have a 98 to test on, or an non sp4 NT machines. For  
those who have gotten it to work on NT, what sp level was NT at?  
BTW, this is all from linux 2.2.5.  
  
-chris  
  
_______________________________________________________  
Christopher Rogers Stevens Institute of Technology  
[email protected] http://www.pobox.com/~gandalf  
  
If at first you do succeed, try to hide your astonishment.  
  
----------------------------------------------------------------------------------  
  
Date: Wed, 14 Apr 1999 13:16:40 -0700  
From: [email protected]  
To: [email protected]  
Subject: Re: ARP problem in Windows9X/NT  
  
The poink program included in the message reliably kills the MS PPTP  
tunnel on my NT Workstation SP4 (PPTP client). Haven't tried it on the  
PPTP server yet...  
  
Aram  
  
----------------------------------------------------------------------------------  
  
Date: Wed, 14 Apr 1999 15:41:22 -0400  
From: Joseph Gooch <[email protected]>  
To: [email protected]  
Subject: Re: ARP problem in Windows9X/NT  
  
> -----Original Message-----  
> From: Bugtraq List [mailto:[email protected]]On Behalf Of  
> Alan DeKok  
> Sent: Tuesday, April 13, 1999 3:49 PM  
> To: [email protected]  
> Subject: Re: ARP problem in Windows9X/NT  
>  
>  
> [email protected] wrote:  
> > Didn't test your code. Rolled my from the same libnet  
> example, and it  
> > does work against NT and 95/98.  
>  
> I tested yours against a number of machines at work. Summary:  
>  
> NT4 sp3 displays one requestor. While it's on-screen, any  
> additional ARP packets are ignored. Clicking 'OK', and then sending  
> more packets results in another requestor.  
>  
> 95/98 displays one requestor per packet.  
  
  
Same behavior here, however NT LOGS all packets to the event log. I'm not  
sure of NT's logging behavior, it could either fill the drive or if it has a  
max size it could erase old events. Possibly cover up other vulnerabilities  
that were tested. Since the MAC address isn't a real one, it's alot harder  
to trace.  
  
9x is boring, just a lame message box.  
  
Later,  
Joseph Gooch  
  
----------------------------------------------------------------------------------  
  
Date: Thu, 15 Apr 1999 09:41:47 +0200  
From: Frank Tegtmeyer <[email protected]>  
To: [email protected]  
Subject: Re: ARP problem in Windows9X/NT  
  
> additional ARP packets are ignored.  
  
True for the message box. Additional effect: every packet is logged in the  
event log which gets filled quickly. During writing the log the machine  
is unusable (100% load).  
This load leads also to a loss of network connections that crashed at  
least one application.  
  
System: Windows NT 4.0 Workstation SP3 (German).  
  
Regards, Frank  
  
----------------------------------------------------------------------------------  
  
Date: Thu, 15 Apr 1999 09:24:37 -0400  
From: [email protected]  
To: [email protected]  
Subject: Re: ARP problem in Windows9X/NT  
  
On Wed, 14 Apr 1999, Joseph Gooch wrote:  
  
> Same behavior here, however NT LOGS all packets to the event log. I'm not  
> sure of NT's logging behavior, it could either fill the drive or if it has a  
> max size it could erase old events. Possibly cover up other vulnerabilities  
> that were tested. Since the MAC address isn't a real one, it's alot harder  
> to trace.  
  
The NT system logger has a size limit, on my system (and therefore I  
assume the default since I don't think I ever touched it) it is 512kb. It  
also will by default (this is configurable) not write over any  
entries less than 7 days old, which means when you fill all 512Kb it gives  
you a warning that the log is full, and _stops logging_.  
  
of course all of these attacks only work on the local subnet, which makes  
them a lot less worrisome then a more remote attack.  
  
> 9x is boring, just a lame message box.  
  
what versions? It definetly does work on some versions of 95  
(like 4.00.950 B)  
  
If people want to test and send me the exact version and the results on  
the version I'll collate and post a summary.  
  
-chris  
  
_______________________________________________________  
Christopher Rogers Stevens Institute of Technology  
[email protected] http://www.pobox.com/~gandalf  
  
I can prove anything with research except the truth.  
-Unknown  
  
----------------------------------------------------------------------------------  
  
Date: Tue, 27 Apr 1999 19:34:41 +0200  
From: ACAL - Cristobal Bielza Lino <[email protected]>  
To: [email protected]  
Subject: DoS ARP problem in Windows9X/NT  
  
Hello,  
  
(excuse me my english)  
  
When I was tested the winarp.c exploit for the ARP problem, I detected the  
victim machine didn't respond any tcp/ip conection after receive the packet.  
  
The problem is that the rest of machines in the same network get the false  
arp request with the Sender's hardware address to 00:00:00:00:00:00. I  
don`t know why the mecanism for duplicate IP address (article Q120599)  
don't work in this case. The victim machine don´t send the last broadcast  
arp request to update arp chace in all machines in the network.  
  
In new tests, this time with Network Monitor, I've seen that the systems  
don´t respond well (one arp respond to mac with IP duplicate and another  
arp broadcast with the correct mac+ip address), only send the first packet.  
Initilly, I thought that the problem was the MAC 00:00:00:00:00:00 but in  
my test with any arp request the systems don't respond in a correct way.  
  
  
This is very serious problem, because it is very easy to do a denial of  
service attack against a machine in a subnet. With one arp packet then  
machine don´t respond until the cache arp is update. The time for this  
update can be modified with two parametres in registry according to this  
articles:  
  
In article Q120599 is described the mecanism for the duplicate IP address.  
In article Q166750 is described the parameters to manage the time out for  
the arp cache.  
  
My network for test was:  
  
- Linux Slackware with winarp.c program (my first test), after this this  
machine was a Windows NT Server SP4 without hotfixes.  
- Windows NT Server with SP4 + roll-up fix (initial target system)  
- Windows NT Server with SP3  
  
The packet that produce the problem is a simple ARP request with a victims  
IP as Sender's IP. I modified the IP of a machine in the same network that  
the NT SP4 machine while I captured the datagrams with Network Monitor. The  
target system display a message warning a conflict IP. When I watched the  
network monitor capture, I saw that the process was absolutely correct. The  
target system when received the arp request duplicate, generated two arp  
packets, one to the other machine and another to all network, arp  
broadcast. all ok.  
  
But, I save my network monitor capture and restart both systems. Atfer they  
start I run my network monitor and send a simple arp packet. The same  
packtet tah was generated when I modified the IP in Control Panel.With this  
simpl epacket the target system ONLY send the arp request against the  
machine and NOT send the broadcast. Thas's the problem. The rest the  
machines in the network lost the conections with the target machine.  
  
I modified the packet to test why all this, but I not get any good conclusion.  
  
The problem is the same for the SP4 machines and SP3.  
  
Thanks,  
  
  
ACAL AUDITORES INTERNET   
c/ Galera 16 5ºA   
28042 Madrid   
SPAIN   
  
http://www.acalauditores.es  
  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation