`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