Slashdot Mirror
Nmap Gets Version Detection
Anonymous Coward writes "Up until now, everyone's favorite port scanner, nmap has had decent OS detection (through TCP fingerprinting) and service identification based on the open port, but the latest version, 3.45 released today, has version detection for each service! This means not only can nmap tell you that httpd is running on port 80, but that it is `apache httpd version 2.0.39`! While this is a little bit worrisome because of what malicious purposes people might use nmap's version detection for, this should make the jobs of admins everywhere easier and keep us all more on our toes when it comes to security. Fyodor has also published a paper on how the version detection works."
If you plan your network security through obscurity...thats asking for trouble.
If you hope nobody can hack you or cause any problems with your servers because you assume they dont know what you are running...that is a problem.
How about being accountable, upgrading and securing your system, instead of being alarmed that "suddenly" (like they couldnt before) people can see specifically what you are running.
Hats off to nmap...first matrix reloaded, now a drastic improvement! Who knows, matrix revolutions may be sporting a new nmap!
[I can picture a world without war, without hate. I can picture us attacking that world, because they'd never expect it]
In the past, my kit contained THC's Amap, Ofir Arkin's Xprobe, and of course, Fyodor's nmap. Its good to see all of these toys (or at least the functionality) coming into one wrapper. I really like Xprobe's probabilistic model for O/S detection. Its a shame that what's good for the hacker is good for the cracker . . .
Oh, and by the way, is anyone watching the global 593 spike?
trustedworlds.net - gaming, security, and the gunk that lives in between
While Nmap does many things (remote OS detection via TCP/IP fingerprinting, ping sweeps, uptime calculation, protocol scans, etc.), its raison d'etre has always been port scanning. Point Nmap at a remote machine, and it might tell you that ports 25/tcp, 80/tcp, and 53/udp are open. Using its nmap-services database of more than 2,200 "well-known" services, Nmap would explain that those ports probably correspond to a mail server (SMTP), web server (HTTP), and name server (DNS) respectively. This lookup is usually accurate -- the vast majority of daemons listening on port 25 are, in fact, mail servers. But you shouldn't bet your security on this! People can and do run services on strange ports. Perhaps their main web server was already on port 80, so they picked a different port for a staging/test server. Maybe they think hiding a vulnerable service on some obscure port will prevent "evil hackers" from finding it. Even more common lately is that people are choosing ports based not on the service they want to run but based on what will get through the firewall. When ISPs blocked port 80 after major Microsoft IIS worms CodeRed and Nimda, hordes of users responded by moving their personal web servers to different ports. When companies block telnet access due to its horrific security risks, I have seen users simply run telnetd on the secure shell (SSH) port instead.
Even if Nmap is right, and the hypothetical server above is running SMTP, HTTP, and DNS servers, that is not a lot of information. When doing vulnerability assessments of your companies or clients, you really what to know which mail and DNS servers are running, as well as the version number if possible. Having an accurate version number helps dramatically in determining which exploits a server is vulnerable to.
Yet another good reason for determining service/version numbers is that many services share the same port number - making a guess based on the nmap-services table even less accurate. Anyone who has done much scanning knows that you often find services listening on unregistered ports - these are a complete mystery without version detection. In addition, filtered UDP ports often look the same to a simple port scanner as open ports. But if they respond to the service-specific probes sent by Nmap version detection, you know for sure that they are open (and in many cases exactly what is running).
The new Nmap version scanning subsystem tries to answer all these questions by connecting to open ports and interrogating them for this information using probes that the specific services understand. This allows Nmap to give a much more details assessment of what is really running, rather than just what port numbers are open. Here is a real example:
# nmap -A -T4 -F www.insecure.org
Starting nmap 3.40PVT16 ( http://www.insecure.org/nmap/ ) at 2003-09-06 19:49 PDT
Interesting ports on www.insecure.org (205.217.153.53):
(The 1206 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.1p1 (protocol 1.99)
25/tcp open smtp Qmail smtpd
53/tcp open domain ISC Bind 9.2.1
80/tcp open http Apache httpd 2.0.39 ((Unix) mod_perl/1.99_07-dev Perl/v5.6.1)
113/tcp closed auth
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux Kernel 2.4.0 - 2.5.20
Uptime 108.307 days (since Wed May 21 12:27:44 2003)
Nmap run completed -- 1 IP address (1 host up) scanned in 34.962 seconds
Now I don't claim that Nmap is the first program to ever implement this sort of port interrogation. Jay Freeman (AKA Saurik) posted an Nmap patch he calls Nmap+V more than three years ago. Even if Nmap+V was rather slow and cryptic at the time, it demonstrated the value of advanced port interrogation. It has improved substantially since then. There is also the excellent THC Amap, and Nessus even has a (very) rudimentary service detection framework. While we could have saved months of work by simply integrating one of these open source implementations
While this is a little bit worrisome because of what malicious purposes people might use nmap's version detection for
hmmm I think NMAP will only report the version that service will respond. I can make my Apache instance respond with anything, for e.g. "saqib webserver ver. 9.0"
Version detection can also be very helpful
It is good to know that NMAP support version detection. There have been mny instance in the past, especially during the recent virus outbreaks, where I wished I could find the Service version.
Consensus is good, but informed dictatorship is better
Gosh, who could possibly imagine that, with the
addition of version detection, the most 'white hat'
tool out there that could never possibly be used for
anything bad suddenly becomes a 'black hat' tool..
It's a complete 180!
For every problem, there is at least one solution that is simple, neat, and wrong.
This will be great to see if people have wonkyed their port numbers to try to obfuscate what they're doing, like running smtp on 10025 or something silly. You'll be able to check that there is an MTA on 25 and SSH on 22.
Most likely the #1 Unfunny Meta/Moderator on
This, on top of it being in the matrix will have every pimply 13 year old trying to haxor the gibson.
scott
Security through obscurity never worked that much, will work much worse now. However, I do not see worms using such tools to propagate better. Worms just try to infect everyone and do not care about being glued in honeypots.
While this is a little bit worrisome because of what malicious purposes people might use nmap's version detection for [...]
By the same logic, one might consider it "worrisome" that there even exists software packages like "Nessus" and "Saint".
Adding features such as version detection to a tool that can be used for both good and bad purposed shouldn't be considered "worrisome". It is just something that makes the tool better, for good and for bad. And unless we are talking about software which by design always causes destructive damage when used, I will always consider it a good thing that there are such excellent security auditing tools available to the public. With all respect, sorry to hear that someone finds this "worrisome".
Speaking of bad versions.
0 Day SSH EXPLOIT out today..
CVS DIFF patch Here
Details are sketchy here
Redhat and others haven't released patches yet.
ChiefArcher
That's good and all, but the thing is that most vendors don't increment version numbers. Take the sendmail header overflows from earlier this year: Sun, RedHat, SuSE, HPUX all had patches for the bundled apache server, but those just fixed the binaries - they did not update the banner info. This is of dubious value because of that.
Unfortunately, there is no easy answer to this dilemna for security professionals - do you trust the banner info and get a bunch of false positives? Do you attempt an exploit and possibly crash the machine (not as likely with this sendmail header overflow, but moreso in the case of the apache chunked encoding overflow)? Or do you log onto each host (or use an agent based check system, like NetworkShell)?
Perhaps Fyodor should tackle these questions and not hack pranksters in his spare time.
Trolling is a art,
Slashdot Trolls better hunker down, Fyodor has new weaponry! And we all know what happened last time he went blackhat.
Being a system admin for a college, having this updated tool out for the world really doesn't bother me. Honestly, I'd rather have it in my hands to know what's running on my server, than to be ignorant and hope everything is ok. It also is a good tool to for testing things like if your firewall is configured properly. After all... all the script k1dd13z are going to have these programs too, so it's best to know what you've got exposed to the internet. Besides, in a lot of the programs out there, you can turn off the server identification so that when you connect, you don't know what the host is running for programs. Apache does this (I know because I turned it off myself). And you could probably even hack the source code to them if you really wanted. My FTP server at home just says "Go away!" when you connect so you don't even even see which program is running, much less what version.
Now for a *real* tool for making sure your sytems are up to date, try Nessus. It not only scans your system for what programs are running (using nmap no less), but it finds out what versions they are if they can, and it tries to run common exploits on them too! I use it perodically just to make sure that all the bases are covered so that none of the holes for common exploits on the internet are left open.
-Through the server, over the router, off the firewall... Nothing but 'Net!
Spoil sport... :)
I put a timed block on all ips that port scan me persistantly, I doubt the heuristics will even change. Once it's a distributed scan I'm screwed...
Certainly be useful for the internal audits though.
Q.
Insert Signature Here
When you have to keep track of many different servers of different OSes, sometimes you forget things, or stuff that you thought you turned off you find out you didn't. It happens to the best of us.
It's the first thing I always do when I put a new server on the network. It never hurts to do a double-check to make sure that your servers are behaving the way that you think they are. Just like it doesn't hurt to reboot a linux box perodically to make sure that all your startup scrips work as expected in case of a power outage or whatever.
-Through the server, over the router, off the firewall... Nothing but 'Net!
When you support 10,000 servers and 30,000 desktops
There's no way to support this many machines alone. It's simply an impossible workload. As for making the lives of SKs easier, yep, it'll help em target machines, no doubt about it. There's a positive though, at least this tool is public and we're all aware of it now. It's the tools I don't know about that worry me.
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
the kids just run scripts. no one cares about what OS you are running much less what versions.
/scripts/root.exe?/c+dir HTTP/1.0" 404 284 /MSADC/root.exe?/c+dir HTTP/1.0" 404 282 /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 292 /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 292 /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 306 /_vti_bin/..%255c../..%255c../..%255c../winnt/syst em32/cmd.exe?/c+dir /_mem_bin/..%255c../..%255c../..%255c../winnt/syst em32/cmd.exe?/c+dir HTTP/1.0" 404 323 /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c 1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 339 /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 305 ??
how many lines in your apache logs look like this ?
"GET
"GET
"GET
"GET
"GET
"GET
HTTP/1.0" 404 323
24.91.103.152 "GET
24.91.103.152 "GET
24.91.103.152 "GET
Sanity is the trademark of a weak mind. -- Mark Harrold