Bugtraq mailing list archives
Re: Invalid WINS entries
From: "Fulton L. Preston Jr." <fulton () PRESTONS ORG>
Date: Wed, 17 Jan 2001 23:04:42 -0500
Interesting perl script but this method works just as well for a good old fashioned DDoS: About two years ago a friend of mine and I did something similar with a Samba server. I configured Samba to be a PDC for a Domain and pointed it towards my friends WINS server for his network. The Samba domain name was the same as his. Using snoop on a Sun box I watched the traffic between the Linux server with Samba and the NT WINS server when I started the Samba server. I don't have the captures anymore but here is a basic re-creation of the events: Samba to WINS: I am the PDC WINS to Samba: Uh, I don't think so. Samba to WINS: Yes I am WINS to Samba: Didn't you hear me the first time? Samba to WINS (using Jedi hand waving motion): <<I AM THE PDC>> WINS to Samba: YOU ARE THE PDC Elapsed time: 2 seconds. Result: No one in that NT Domain could login, print, or use Outlook. It even caused the Exchange server to wig out. All workstations and member servers started sending their auth requests to the Samba server. I didn't check to see if it was LanMan or NTLM, that was not the point of the experiment at that time. Solution: Use static IP's for PDC/BDC's and enter static entries into WINS. More importantly, block TCP/UDP 135-139 at firewalls (or at least only pass trusted IP's) Interesting side effect: The PDC would not auth anybody even when static entries into WINS were added and the Samba server was shutdown. A reboot of the PDC and BDC was necessary to restore the trust of the PDC/BDC's. Lesson learned: Large corporations or military bases with large scale networks that let ports 135-139 through the firewalls without filtering are subject to this type of attack. Imagine a 25,000+ user network not able to login, print, etc... The overall costs are pretty staggering, especially if it continues for days, even more sickening is how many passwords could be snatched by doing this, even if only for a few minutes. Sad part of this lesson is that way too many large networks are STILL vulnerable to this. The only thing needed is a WINS server address. In the case of some NT DNS servers that information is easily harvested since there is a value for WINS recursive lookup if it is set by the admins (read: EVIL! Do not do this, only for internal DNS servers behind firewalls if it must be done!) Enjoy, Fulton Preston [This is supposed to be an annoying signature. Annoyed yet?] -----Original Message----- From: Byrne, David [mailto:dbyrne () TIAA-CREF ORG] Sent: Wednesday, January 17, 2001 4:36 PM To: BUGTRAQ () SECURITYFOCUS COM Subject: Invalid WINS entries After playing around with some WINS problems we were having, I discovered something that doesn't seem to bother very many people. WINS does nothing to verify the 1Ch (domain controllers) registrations sent to it. This allows an attacker to overwrite some or all of the Domain Controllers in the record. The new entries could be pointing at a box that will participate in the logon process long enough to capture user names and passwords. If the passwords are only hashed with LanMan (not NTLM), they can be easily broken with L0phtCrack. A less malicious problem can occur if someone brings up a server that incorrectly thinks it is a Domain Controller. Although the server cannot participate in the domain, it will register itself with WINS in the 1Ch record and workstations will still send logon requests to it. The best work around I could think of is to use static entries for records that are sensitive (there are probably more besides 1Ch). Domain Controllers shouldn't be changed very often, so the management work would be minimal. When I contacted Microsoft, I was told that they were aware of this, but did not consider it a significant problem. They confirmed that static records were the best solution. Attached is a PERL script that can demonstrate the problem. Use it cautiously. David Byrne, MCSE TIAA CREF <<wins2.pl>>
Current thread:
- Invalid WINS entries Byrne, David (Jan 17)
- Re: Invalid WINS entries Attonbitus Deus (Jan 18)
- Re: Invalid WINS entries 3APA3A (Jan 18)
- Re: Invalid WINS entries Paul L Schmehl (Jan 18)
- <Possible follow-ups>
- Re: Invalid WINS entries Fulton L. Preston Jr. (Jan 18)
- Re: Invalid WINS entries Byrne, David (Jan 18)
- Re: Invalid WINS entries Attonbitus Deus (Jan 18)
- Re: Invalid WINS entries Russ (Jan 19)