Fyodor's new rant on Windows, Raw Sockets and Nmap

Looks like one of the loop holes used to get around the lack a Raw Socket support with SP2 has been killed by another patch. I know this has been covered a bit before, but some might like to hear the extra details. Guess what it comes down to it, if you want to run Nmap with the best performance choose a *nix platform.

Quote:

---

Many of us were annoyed last year when Microsoft intentionally broke
raw sockets on Windows XP, while leaving the feature enabled in
Windows 2003. MS is well known for maintaining the upgrade treadmill
by dubious means such gratuitous file format incompatibilities, but
this is a new low. People pay $299.99 for WinXP Pro with working raw
sockets, then MS cripples their systems and demands $1019 (WS2003
retail price) to return the functionality. Of course Microsoft claims
this change is necessary for security. That is funny, since all of
the other major platforms Nmap supports (e.g. Mac OS X, Linux, *BSD)
offer raw sockets and yet they haven't become the wasp nest of
spambots, worms, and spyware that infest so many Windows boxes.

This takes us back to 1996, when MS released Windows NT 4.0
Workstation with a limit of 10 incoming connections per 10 minutes[1].
They (falsely) claimed this limit was due to substantial technical
differences between Workstation and Server, and wasn't just a way to
force an $800 upgrade. But at least that was a new product -- MS
didn't proactively break existing, working web servers. Soon hackers
discovered that the "substantial technical differences" were just a
registry key setting. MS backed down and removed the limitation.

Well, they haven't backed down this time! I know that some of you
have been avoiding SP2 to keep your system fully functional. MS made
a blocking tool available to Enterprises, but they overrode it on
April 12 and forced the upgrade through Automatic Update anyway[2].
And now they have quietly snuck the raw sockets restriction in with
their latest critical security patch (MS05-019). The loophole that
allowed users to defeat the limitation by stopping the ICS service has
also been closed by MS05-019. I have appended an informative
NTBugtraq post by Robin Keir on this topic. Pick your poison: Install
MS05-019 and cripple your OS, or ignore the hotfix and remain
vulnerable to remote code execution and DoS.

Nmap has not supported dialup nor any other non-ethernet connections
on Windows since this silly limitation was added. The new TCP
connection limit also substantially degrades connect() scan. Nmap
users should avoid thinking that all platforms are supported equally.
If you have any choice, run Nmap on Linux, Mac OS X, Open/FreeBSD, or
Solaris rather than Windows. Nmap will run faster and more reliably.
Or you can try convincing MS to fix their TCP stack. Good luck with
that.

Rand mode off,
-Fyodor

[1] http://tim.oreilly.com/articles/10-conn.html
[2] http://it.slashdot.org/article.pl?si...id=172&tid=218

From: Robin Keir <[email protected]>
To: [email protected]
Subject: MS05-019 breaks TCP raw socket sends
Date: Tue, 12 Apr 2005 20:37:02 -0700

Today's bugfix MS05-019 ("Vulnerabilities in TCP/IP Could Allow Remote
Code Execution and Denial of Service" - KB893066) appears to break TCP
raw socket sends on XP (tested with SP1 and SP2). Windows Server 2003
appears unaffected.

It is a documented fact that TCP raw socket sends were disabled with
XP SP2. This was easily circumvented by disabling the Windows Firewall
service ("net stop sharedaccess"). It now appears that with the
MS05-019 hotfix a similar situation has arisen whereby TCP raw socket
sends are prevented, not only in SP2 but also SP1 (and probably
SP0). This does *not* seem to be able to be overcome by stopping the
firewall service(s).

I don't know if this was intentional but I don't see any reference to
this behavior.

Incidentally, with Windows Server 2003 MS had "accidentally" also
disabled TCP raw socket sends as with XP SP2 until they were notified
of this unintentional regression and "fixed" it in RC2 and the final
release. One wonders whether they "accidentally" used a component from
XP SP2 in this hotfix causing this undesirable behavior.

--
Robin


_______________________________________________
Sent through the nmap-hackers mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-hackers

---

While unfair, people will adapt and find a different program rather than completely switch OSes for a singular problem.

Same thing would apply even if this was winamp. People will simply use a different program.

Maybe, but is there anything that compares to the features of Nmap on the Windows platform? That does SYS, Ack, FIN, XMAS Scans, OS detection, version detection all in one tool? Quite frankly, I can't see a pen-tester being without a *nix box of some kind.

Doesn't foundstone's superscan basically do that? IIRC, it's basically nmap for windows. At least I use it that way.

Quote:

---

all in one tool

---

See, that's the handicap right there. There are multiple tools on Windows that will accomplish the same goals as nmap, you just have to use then in conjunction with one another. Nothing wrong with that at all, especially if you are up-to-par on data collection entry for easy recording. And if you do minimalization penetration testing, then crafting packets by hand specifically for Xmas and FIN testing should be a walk in the park.

I dislike many all-in-one tools because if that tool breaks completely, then I will be stuck not knowing what other alternatives are out there to accomplish the job per feature.

Quote:

---

I can't see a pen-tester being without a *nix box of some kind.

---

Custome live CD would seem to be the answer

Well,

As I have said before, how many of the millions of Windows users have ever heard of nmap? Of those who have, how many actually use it?

Raw sockets do present a potential security weakness, and are best not provided to the general "off the shelf" Windows customers. They have no use whatsoever for raw sockets support.

What I do not understand is why it is not available off the CD or to be deliberately activated. Like make a positive decision that you want to run raw sockets. That would give the best of both worlds?

After all it is available with professional distributions like 2003 server, because that is not Joe Public's off the shelf choice of OS?

just my thoughts

:)

Foundstone's superscan suffers the same problems as nmap, because it also uses raw sockets, and will be similarly affected.

-Maestr0

Quote:

---

Originally posted here by jinxy
Custome live CD would seem to be the answer

---

I use live CD distro for pen tesing. Nessus is terribly slow on a CD distro utilizing RAM. Slow to the point that is does not fulfill the needs I require to get the job done.

You also have to read this post very carefully:

Quote:

---

Nmap has not supported dialup nor any other non-ethernet connections
on Windows since this silly limitation was added.

---

Which IMPLIES that it still works correctly on ethernet connections.

And as the majority of users will be using it on ethernet (well, almost everybody), it just isn't a problem.

YES, it works correctly on dial-up connections under (for example) Linux or Mac, but most people who are using nmap are security professionals scanning corporate networks on ethernet**.

If they *really* need to scan using a dial-up connection, they can always either get a Linux box, or use a hardware router to route their dial-up into ethernet, and then use nmap under Windows anyway.

Slarty

** Or so we hope

In case anyone is interested, here is the technical breakdown on RAW socket support on Win32 platforms. It came from the NMAP mailing list...

From: Robin Keir <[email protected]>
Date: Mon, 25 Apr 2005 14:33:01 -0700
Subject: Raw sockets, MS05-019 and Windows Firewall -- Summary

With the advent of XP SP2 and the recent MS05-019 patch, using raw
sockets for scanning from a Windows platform has proven to be very
problematic. I thought I would summarize the situation.

Based upon the presence of MS05-019 and the state of the Windows
Firewall service(s) we have to decide whether we need to stop or start
the firewall service(s). Even then there may still be issues. The logic
is as follows:

Windows 2000 is unaffected. It fully supports all raw socket actions and
since it doesn't have the Windows Firewall/ICF we don't have any of
those associated issues.

XP SP0 should have the firewall stopped ("net stop sharedaccess"). Even
though TCP raw sockets are unaffected by the firewall the ALG service,
which is intimately tied to the firewall service on XP, prevents
discovery of several ports such as 21, 389, 1002 and 1720 when using TCP
raw sockets. Stopping the sharedaccess service thus automatically stops
the ALG service and we're good to go.

XP SP1 *without* MS05-019 functions the same as XP SP0.

XP SP1 *with* MS05-019 needs to have the sharedaccess firewall service
*running* (see http://support.microsoft.com/kb/897656) otherwise TCP raw
sockets are blocked. Because the sharedaccess service needs to be
running to enable sending of TCP packets using raw sockets we have the
problem with the ALG service blocking sending to certain ports, but it's
better than nothing.

XP SP2 *without* MS05-019 functions the same as XP SP1 without the patch
apart from a driver-level restriction on the number of
in-the-process-of-connecting TCP connections. This can affect regular
socket style scanning. The only known workaround to the driver issue is
a TCPIP.SYS hack.

XP SP2 *with* MS05-019 is unusable for raw-socket TCP scanning. It
totally blocks TCP raw sockets with or without the firewall enabled.

Windows Server 2003 acts like XP SP0. The ALG service, which is now no
longer tied to the sharedaccess (Windows Firewall) service, should be
stopped ("net stop alg").

What a mess :-)