Nmap กับ MS XP SP2 (2)

ฉบับที่ 2 ออกมาวันที่ 26/8/2004 หลังจากฉบับแรกออกมาเมื่อ 12/8 ครับ

---- (2)

Nmap Hackers,

I have released Nmap 3.55-SP2, which works around most of the
bone-headed raw sockets restrictions that Microsoft added to Windows
XP Service Pack 2. Many thanks to Dana Epp (dana(a)vulscan.com) and
Andy Lutomirski (luto(a)stanford.edu), who started working on the
problem immediately, and had patches to me within 24 hours of my last
nmap-hackers mail about the problem. I sent 3.55-SP2 to the dev list
on the 13th to solicit feedback[1], and have not heard many problem
reports. You can obtain the binaries from
http://www.insecure.org/nmap/nmap_download.html#windows .

The only difference between this and vanilla 3.55 is Dana’s short
patch [2]. So there is no reason to upgrade unless you are using Nmap
on Windows XP with SP2 installed (or if you are planning to install
it). But remember that SP2 may arrive through the Windows Automatic
Update system whether you want it or not. SP2 does offer many
valuable, real security improvements in addition to IP stack crippling
nonsense. Too bad they bundled it all together in one bloated,
quarter-gigabyte patch.

[ If anti-MS ranting offends you, stop reading here. I have to get
some things off my chest :slight_smile: ]

With SP2, Microsoft has crippled Windows in the following ways that
affect Nmap:

  1. TCP packets may no longer be sent through the raw sockets API
  2. IP spoofed UDP packets may no longer be sent through raw sockets
    (affects decoy and spoofed scanning).
  3. Outbound TCP connection attempts are throttled to a slow rate.

I think MS should focus on hardening Windows defenses to keep
attackers out (more timely patching, limiting services available by
default, code auditing, privilege separation, etc.) rather than
crippling the IP stack for legitimate users. Even if MS succeeds in
preventing users from scanning their own Windows networks for
vulnerabilities, attackers will rip right through them using superior
systems such as Linux and *BSD that suffer from no such limitations.

More details (and spin) from the horse’s mouth are available at [3].
This quote from that MS page sums up their attitude about breaking
Nmap and many P2P apps:

Q: What works differently?
A: This change may cause certain security tools, such as port scanners,
to run more slowly.

Q: How do I resolve these issues?
A: Stop the application that is responsible for the failing connection

If applications are broken by SP2, stop using them. Great solution,
Microsoft! Fortunately for Nmap users, Microsoft implemented the new
restrictions in their typical half-assed fashion. Instead of sending
raw IP packets, we move one layer down and send our raw IP packets in
raw ethernet frames. It took Microsoft years to develop SP2, but
attackers can completely defeat the raw socket and (with a little more
work) connect() restrictions in minutes! One downside is that Windows
Nmap now only works with Ethernet networks, while raw sockets were a
cleaner, more portable solution. If this is a problem for you, talk
to Microsoft! If enough people complain, they might actually listen
to their customers and roll back the new restrictions. I am in
communication with several Microsoft employees who are trying to
convince the powers-that-be to fix raw sockets, but customer support
for the change is critical. Mail me too, as we may be able to add
support for other interface types if their is significant demand. Or
write a patch and send it to me :).

I have not worried much about the connect() throttling at this point.
The default SYN scan is usually preferable anyway. If you really want
to use -sT on SP2, or if the restriction breaks your P2P or other
apps, a patch to tcpip.sys is available at [4].


[1] http://seclists.org/lists/nmap-dev/2004/Jul-Sep/0030.html
[2] http://seclists.org/lists/nmap-dev/2004/Jul-Sep/0031.html
[3] http://www.microsoft.com/technet/prodtechn…ion127121120120
[4] http://www.lvllord.de/4226fix/4226fix.htm