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."
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
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.
Um, I think we all know exactly what he has up his sleeve.
While of course it is not good practice to rely on a single method to secure one's network and then dream about it beeing "unhackable", security by obscurity might be part of a good security concept.
Jay Beale (from Bastille Linux) wrote a nice article about security through obscurity a while ago.
Unless you tell specify otherwise dont all httpd servers report their version in the "server" response header?
There is nothing special about detecting the version of Apache, since Apache reports it in every response.
Take make sure noone can tell what you're running, put this in your config:
ServerTokens Prod
ServerSignature Off
Here is the documentation for ServerTokens and ServerSignature.
grisha.org
It's trivial to see that anyway. telnet host.that.youre.unsure.of 10025
Trying 2001:618:15:226::237...
Connected to gk.
Escape character is '^]'.
220 gk.umtstrial.co.uk ESMTP Postfix
quit
221 Bye
Connection closed by foreign host.
Get your own free personal location tracker
I think it has something to do with the fact that telnet can be used for a lot of things. I mean you can telnet to an HTTP server, SMTP server, etc
You're confusing telnet-the-app and telnet-the-protocol. When companies block telnet, they usually block telnet-the-protocol. You can still use the app to connect to arbitary port 80s. If you can't, it means http has been blocked as well.
And if you believe this journal by sllort is true, read his username backward. Sllort and Sdem have a long history of pretending they have been hacked. Sdem is also the one impersonating security expert Theo de Raadt here