Wednesday, Debtember 21, 2005
“OMG! You're running server software older than two days! Pwned!”
I was just given a security scan compliance report, run by XXX XXXXXXXX XXXXXXXX & XXXXXXXXXX XXXX on behalf of one of our customers, and it's rather amusing at 502 pages in length.
The security company wanted a list of everything that is even remotely associated with the customer's dedicated server that is publically accessible via IP—stuff like name servers, mail servers and routers. Well, the customer's server handles everything except DNS and routing, so I sent along the IP address of the DNS servers and the primary router here at The Company.
The security company did their scan, and sent along their 502 page report.
Ho ho ho.
There are five levels of vulnerabilities. One and two are in the “Well,
we don't like that these exist, but I suppose we'd get
too many complaints if we actually recommended that people be
unable to use ping or traceroute, or force people
to forge WHOIS contact information” (heaven forbid anyone
wanting to trouble shoot networking issues). Think I'm kidding about levels
one and two? Here are some sample level one and two
“vulnerabilities:”
- Web Server Supports HTTP Request Pipelining [it's part of the HTTP protocol as specified in RFC-2616]
- Mail Exchange (MX) Record Gathered from DNS Server [um … I suppose disabling of SMTP entirely might be considered a Good Thing™, given the levels of spam, but people still use email, and this is part of the SMTP specification]
- SMTP Service Detected [at level two no less!]
- DNS Hierarchy of Target DNS Server Traced [just writing about these is causing my blood pressure to escalate—is this security company on Crack or something?]
- Host Names Found [oh dear we seem to
actually have DNS
PTRrecords!] - Target Network Information [this means
The Company is listed in the
WHOISdatabase as owning the IP address. The fact that for any given publically routable IP address on the Internet someone somewhere owns said IP address has probably escaped this security company]
Levels three and four are in the “There exists a theorectical exploit that in reality is impossible to actually exploit, but since it does exist, and the fact that the server software you are running is older than twenty minutes old, means we don't like it and therefore you don't pass. Please upgrade immediately to the latest codebase; we don't care if it causes the server to become inoperable (actually, that's a Good Thing™)—upgrade now!” And level five is “OH MY GOD THE INFOCAPALYPSE IS NIGH UPON YOU! YOU ARE PWNED! GET AWAY FROM US YOU VENOMOUS CRETINS FOR EVEN THINKING OF RUNNING SERVER SOFTWARE THAT IS OLDER THAN TWO DAYS!”
Of course, I have issues with the report.
Okay, one of the three bazillion “vulnerabilities” on the customer's server, at level “Infocapalypse” is the following:
Title: Multiple Apache Web Server < 2.0.51 Vulnerabilities
Severity: 5
Diagnosis: There is an input validation issue in IPv6 literal address parsing which can result in a negative length parameter being passed to memcpy.
A buffer overflow in configuration file parsing makes it possible for a local user to gain the privileges of a httpd child, if the server can be forced to parse a carefully crafted “.htaccess” file.
A segfault in “mod ssl” can be triggered by a malicious remote server, if proxying to SSL servers has been configured.
A potential infinite loop in “mod ssl” can be triggered given particular timing of a connection abort.
A segfault in “mod dav fs” can be remotely triggered by an indirect lock refresh request.
Consequence: An attacker may get control of the server.
(Yes, that is one “vulnerability,” by the way)
Can you say “overboard?”
We don't run IPv6 on our
network. Even if we were, this would most likely cause the server to crash
on startup (or at the worse, if trigger by a directive in
.htaccess, crash just that child process).
We don't proxy SSL servers. Even if we were, this would just crash that particular request. Yes, it could lead to a denial of service attack, but those are rather hard to guard against anyway.
We don't have mod_dav running. And again, even if it were,
it's just a replay of the above problem.
Of the two remaining “issues,” one sounds theoretical, and even if it were possible, is just a (heh—“just a”) type of denial service attack. Hard to gain control of a server that way (well, for certain values of “control” I suppose).
That does leave the last “issue,” which is a valid issue, but one
that's (in my humble opinion) rather moot—if someone can place a carefully
crafted .htacces file on the server, they already have
access to the server!
Um … yeah.
I would also be more impressed if the report did not contain five duplicates of this “issue.” And I don't mean because there are five different IP addresses on the server—no, this was six instances reported for a single IP address. I'm guessing that a 502 page security scan compliance report is more impressive than a mere 302 page security scan compliance report.
In fact, of the 216 “vulnerabilities” listed for the customer's server, 129 were duplicates. Sure, some of them are interesting, but the sheer repetition (and the silliness of some of them) lessens the impact for me. It makes reading the report rather tedious, which in my mind, lessens the worth of this 502 page report.
I just hope Smirk can calm down the customer.
