SecuritySpace.com - My "assessment"

[Tiger Shark]

Unfortunately I can't find the thread where somebody recommended www.securityspace.com so I can't point you to it. Having made some significant changes to my systems in recent days I thought I'd go ahead and see what this company has to say about my "most exposed" system. Bear in mind this is not the first security audit I have done on this box since the changes and nor will it be the last.

So off I go and sign up for the two free tests, (the basic and the "No Risk"). The basic test is a simple portscan to tell me what ports are open. Ok, I can live with that. So I moved on to the "No Risk" which is their full scan with the results being "crippled" until you pay them ca$h....

The things I _know_ about the box are:-

1. It's a standard Win2k server, SP2, all patches
2. It is only allowed to accept connections from anywhere on ports 21, 25, 80 and 3389 due to the IP filtering I have in place.
3. The firewall blocks all but 21 and 25 to that box from the public network.
4. Port 80 is closed on that box at present.
5. Port 3389 can only be accessed from a short list of machines on the trusted network, (this box is in the DMZ).
6. Port 25 is managed by Microsoft's SMTP server under IIS 5. No effort has been made to hide this.
7. Port 21 is managed by a proprietary FTP server, fully patched, no attempt made to obfuscate the system.

The security scan took two hours to come up with the following findings:-

Low risks, (Which it laid out for me): 3
Medium risks, (hidden from me) : 0
High risks, (hidden from me) : 5

The scan claims to do some 2000 checks of my system and says up front it uses NMap and Nessus for the exploit scans. I specifically told the scan _not_ to perform any kind of DoS attack.

Notable things about this company and it's "product":-

1. Even though I specifically stated "No DoS" the scan was so noisy that they claim my firewall must have blocked their scan. BS. The firewall logs clearly show their attacks on the FTP server, (which they concentrated on almost exclusively), being allowed in from the start of the period right to the end.

2. Their scan was _very_noisy and triggered the Snort sensors immediately. (OK, that's not a problem insofar as I authorized the scan - but why make it noisy if you then accuse me of blocking you - which I didn't!!!! It's MY security I'm testing, not your ability to scan me more quickly!!!!!

3. The first "low risk" they mention is the fact that the SMTP port is open and that information can be gleaned from the header they pulled..... "220 SMTP service ready" is the banner.... Yep, I gave the game away there.

4. The second "low risk" was the same as for the SMTP port. The banner they pulled there was "220 ftp.mydomain.com"..... Damn, I'm just giving it all away today.

5. Get this one...... They can run a tracert...... Bugger me!!!!!!

(To scare me they then threw in 7 items that need consideration.....

6. They can resolve the IP to an FQDN - thats a bit of a bugger too.... It is a mail server!!!!!!

7. This one makes me laff......

smtpscan was not able to reliably identify this server. It might be:
Symantec Enterprise Firewall 7.04 (Windows)
Symantec Velociraptor 1.5
Postfix-20010228-pl08
The fingerprint differs from these known signatures on 2 point(s)

If you known precisely what it is, please send this fingerprint
to smtp-signatures@nessus.org :
:503:250:501:250:553:250:452:214:252:252:500:500:500:250:250

It's IIS for god's sake!!!!!

8. Now I'm just giggling.....

Remote OS guess : Linux 2.0.32-34

CVE : CAN-1999-0454

This plugin determines which operating system
the remote host is running.

Guessing the remote operating system allows
an attacker to make more focuses attacks and
to achieve his goal more quickly
This plugin uses the code from Nmap - see www.nmap.org
Risk factor : None

OMG..... I scan it with NMap - don't ping - OS detection - stealth scan, (which they used per my Snort logs), normal speed - very verbose, and it tells me Win2k SP4 or WinXP SP1.... Funny that, huh?

9. I'm really not getting this one....

Nessus cannot reach any of the previously open ports of the remote
host at the end of its scan.

This might be an availability problem related which might be
due to the following reasons :

- The remote host is now down, either because a user turned it
off during the scan or a selected denial of service was effective against
this host

- A network outage has been experienced during the scan, and the remote
network cannot be reached from the Nessus server any more

- This Nessus server has been blacklisted by the system administrator
or by automatic intrusion detection/prevention systems which have detected the
vulnerability assessment.


In any case, the audit of the remote host might be incomplete and may need to
be done again

I did nothing to stop it. There are no active defense systems except the firewall blocking all communication with the attacker - which it didn't do, it allowed connections right up to the end of the audit. The FTP server will automatically ban users who attempt certain exploits, it didn't. The firewall did strip attempted buffer overflows which the scanner tried for _ever_ but it never gave up and moved to a different test...... But the FTP log shows the scanner opening connections right to the last minute of the audit too...... So it was getting to the server!!

10. They then go on to repeat things already mentioned to scare me more I guess and then there are two pages of how to mitigate issues that it didn't even find.... What's that all about?????

My Assessment of this "Product"

It is a badly done scan/audit with tools being used improperly. I dread to think what the 5 "High Risk" vulnerabilities are.... But I'm pretty sure they aren't worth $49 to find out. It identified 2 open ports yet managed to fill some eight pages of a report with what I can only describe as "scare tactics", repetitive "vulnerablilities" and mitigation techniques for vulnerabilities it doesn't find, (they are a "canned' script they add to the end of the report to bulk it out).

In short..... Buyer BEWARE!!!!!

[Tiger Shark]

Ohhh.... Does the plot thicken..... Unfortunately not for the better. After returning or lunch I find an email that is exerted below:

A manual review of your audit results has been conducted by SecuritySpace staff, and based on the results received, we are not certain whether or not the high/medium risk item(s) reported are legitimate or not. In cases like this where we cannot make a determination remotely of the legitimacy of discovered vulnerabilities, we mark the report as fully viewable without charge, which allows you to review the report for yourself and make this determination on your own.

Why do I think this means they don't understand what they are looking at..... and why do I think that it's because they aren't doing the job correctly in the first place?

My 5 "High Risks are as follows, (comments added by me )

1.

smtp (25/tcp)
For some reason, we could not send the 42.zip file to this MTA
BID : 3027

This script sends the 42.zip recursive archive to the
mail server. If there is an antivirus filter, it may start eating huge
amounts of CPU or memory.

Solution: Reconfigure your antivirus / upgrade it

Risk factor : High

Let me get this right!!!!! They say "we could not send" so to them it is automatically an AV filter, (which they fail to identify - important later), and a DoS can be carried out by sending lots of mail to it..... Well, anyone can send a lot of attachments. Fact is:- The zip was stripped by the firewall.... I don't allow them in via SMTP..... But c'mon.... This is a "High" risk????

2. This is a doozy......

It was possible to kill your FTP server
by reading a MS/DOS device, using
a file name like CON\CON, AUX.htm or AUX.

A cracker may use this flaw to make your
server crash continuously, preventing
you from working properly.

Solution : upgrade your system or use a
FTP server that filters those names out.

Risk factor : High

The only way to check for this is to do it..... If they did it, which they claim, why didn't my FTP server show any errors? In fact, when I try this I get "access denied"..... Are they confusing that with DoS - they both have the letters "den" at the beginning of one of the words.....

3. Remember point number 1 where my AV scanner was my problem in a DoS.

It was possible to perform
a denial of service against the remote
Interscan SMTP server by sending it a special long HELO command.

This problem allows an attacker to prevent
your Interscan SMTP server from handling requests.

Solution : contact your vendor for a patch.

A buffer overflow exists in the HELO command in Trend Micro Interscan VirusWall SMTP gateway 3.23/3.3 for NT, which may allow an attacker to execute arbitrary code.

Now it's become the problem itself. They can mess it up by sending it a long helo..... Funny, it never showed errors last night either..... I searched high and low for the logs for last night and then I remembered...... I have never used InterScan Viruswall - ever - in my life..... But they found it on my server......

4.

It was possible to crash the remote SMTP server
by opening a great amount of sockets on it.


This problem allows an attacker to make your
SMTP server crash, thus preventing you
from sending or receiving e-mails, which
will affect your work.


*** Note that due to the nature of this vulnerability,
*** Nessus can not be 100% positive on the effectiveness of
*** this flaw. As a result, this report might be a false positive

Well.... I don't know what to say..... Anyone can open a lot of threads.... or lots of people can open one...... I still don't see this a "serious".... So my email goes squirrely for a while..... But then I notice at the bottom

Denial of service in MDaemon 2.7 via a large number of connection attempts.

Now I see..... Someone has ported this to Win32, installed it on my box and I'm not running IIS after all..... My problems are solved........

5. But the winner is........ Tada......

It was possible to crash the
remote server using the linux 'zero fragment' bug.

An attacker may use this flaw to prevent your
network from working properly.

Solution : if the remote host is a Linux server, then install
a newer kernel (2.2.4). If it is not, then contact your vendor
for a patch.

Risk factor : High
CVE : CAN-1999-0431
BID : 2247


Additional Information:
Customer reports indicate that this test may cause D-Link DI-614+ Wireless routers to crash, requiring a power-cycle to recover

Let me start by saying that I am not using a D-Link Wireless router here so we can count that out. Now..... They clearly say "It was possible to crash the remote server".... Implication: they actually did it! Funny.... The box stayed up the entire time... Not to mention that I can't see the linux exploit working on my Win2K box.......

I'd like to reconsider my "Buyer BEWARE" comment since it is clearly untrue......

I will say at this point that this isn't a "scan" it's a SCAM. The only thing they got right about this box was it's IP Address, and I had to tell them that was correct before they began the scans.

If nothing else this proves how the "automated" scans on the internet may not be worth the transfer of the bits and bytes required to put the sales pitch on your monitor in the first place.

I will not be revisiting them again......

[chsh]

What kind of firewall do you have? If you are doing any traffic normalization it could indeed screw up the remote OS guesses in NMap and others. I checked my box and it showed as all ports closed, which is as it should be.

[MrCoffee]

TigerShark:

This is a really good review and I am sure it will save a lot of people time chasing their tail trying to resolve incorrect flaws reported by these guys.
I was wondering after reading it, what tools do you think are worthwhile that fall into the same catagory as this one, and if you have heard of or tried SonicWalls scanning service. It is free of charge (or it was for me, a customer). I would be interested in your view on it's abilities.

Thanks again for the Post!
MrCoffee

[Tiger Shark]

Ok.... You beat me to another follow-up.... After adding the FTP server and opening the firewall to allow access to it I didn't rescan with NMap remotely....

I just did..... It comes up with what they said..... I think thats a major NMap error there....It's relying on the FTP data it gets much more than it should if this is the case.... Unfortunately, I can't take the box back to the state it was in without a major issue of functionality to "prove" my point.

The simple fact is though, the "audit" comes across as a bunch of wild asses guesses.. They include windows deficiencies along with linux deficiencies... We both know that can't be... they "sensationalize" minor "issues" as "high", "serious" or even "low" - the fact is that my server suffered no consequences, it functioned exactly as I expected it to..... But they told me it was full of "holes"...... The logs show differently....

It was not a service I would pay $49 for let alone the higher priced services they profess to be able to provide.....

[PoSer]

thanks for exposing one of the many sites that claim way more than they deliver.
it just goes to show that you can't have great security unless you learn what it take to secure your box. never trust the all inclusive solution that sell for $19.95 or $49.95.
wait I've got it if you want a great security check just send me $9.95 by mail(pm me for the address) and I will check you box for you...just make sure its in cash.

[jinxy]

Checked my box for hell of it to. All ports closed. 1 low level tracert=No responce.
Ok i'm behind a router so no suprises there. But i have Bittorrent running and port forwarding. So should not the scan have picked up on that as a threat??

[Tiger Shark]

If your firewall forwards incoming traffic destined for certain ports to a machine on the inside that has a service running on that port then most certainly the scan should have determined that there was a response, (even if it is "closed"), from the internal machine.

I really don't know what these people are doing.... Then again, I really think that they aren't _entirely_ sure either......

[jinxy]

Tiger,
Thats exactly what i thought, i had torrent running during the scan. I think they do no what they are doing, supply a second rate service for top rate dollar= Large profits.

By the way i'm not farwarding the default torrent ports. So anyone thinking of having ago don't and i change them regularly. Lol

[MrLinus]

Tiger Shark, you might want to look at this thread from the Nessus mailing list. I was looking into it more when you posted to see what kind of results we'd get from the No Risk scan. I've fired up some packet sniffers as well and it seems they are probing a dead port I have open (I had taken down my FreeBSD box a few weeks ago and forgot to close the ports that were pointing to 80, 135, etc. -- I had them open because I was thinking of honeypotting the FreeBSD box). It shall be interesting to see the results of their scans.