Network Penetration Testing
Posted October 29, 2015. 1581 words.
Using Nmap, I was tasked with scanning an IP range, to evaluate and report vulnerabilities.
|HyperText Transfer Protocol||80||29||5||Unknown||Unknown||?||5|
|Node.js||Express middleware||≥ 1||1|
|8080||1||0||Tomcat||7.0.22 + Coyote 1.1||28||1|
|5000||1||0||Node.js||Express framework||≥ 1||1|
|Lightweight Directory Access Protocol||389||0||454||Unknown||Unknown||?||454|
|HyperText Transfer Protocol Secure||443||10||2||Unknown||Unknown||?||2|
|H.323/Q.931 VOIP Signaling||1720||502||0||Unknown||Unknown||?||502|
|Universal Plug ‘N Play||5000||0||454||Unknown||Unknown||?||454|
|Symantec Intruder Alert||5051||0||454||Unknown||Unknown||?||454|
|Session Initiation Protocol||5060||0||454||Unknown||Unknown||?||454|
Versions of nginx were missing, so if the two adjacent versions both contain the same CVE, it’s counted for the missing version. In addition, one nginix and two Node.js servers didn’t give a version number, so I assumed they were running the latest version. Unlikely, so the numbers should be taken as a lower bound.
Analysis of Results
Scanned 512 hosts in 188.8.131.52/23, 502 responded after 5 hops. Completed on 2015-10-14 12:08 GST.
All 502 hosts reportedly have filtered the Printer Spooler (515) port and have the H.323/Q.931 Signaling port open. I believe this is a Router/Firewall filtering rule.
454 servers in this subnet have identical port signatures, which I suspect means that there are, at most, 49 servers in this subnet. Another possibility would be that these are all identically imaged machines, none of which are servers, to me this seems unlikely. However, there is no way for me to tell from NMap alone.
In total the range contains 31 unique web servers, 2 of which are have port 80 closed and instead, choose to open only port 8080 or 443 instead. Roughly a third of web servers choose to run HTTPS in addition to HTTP. Unfortunately, every single server has a self-signed certificate, meaning your information could be stolen via a Man in the Middle attack – although you can say the same thing about plain HTTP.
The vast majority of Web servers run either Apache HTTPd, or nginx – although one was running Node.js, another was running Apache Tomcat with Apache Coyote. Version 7.0.22 of Apache Tomcat has 26 CVEs with the highest rated 7.8 (Out of 10). This vulnerability (CVE-2014-0230) allows an attacker to easily perform an effective denial of service attack (thread consumption) by sending many aborted upload attempts.
Whereas most gave just the server software and occasionally OS. One server gave us a very specific version:
|Software||Apache httpd 2.4.7||OpenSSL 1.0.1e||PHP 5.5.6||mod_perl 2.0.8||Perl 5.16.3|
In addition to at least 104 CVE’s, the version of OpenSSL is vulnerable to Heartbleed. The sad thing is, that chances are both this server, and every other server scanned likely have a similar number, after all, these are the server’s that aren’t maintained properly and are in the DMZ.
5 servers are running OpenSSH version 5.3, a very old version with 5 CVE’s. The joint highest rated vulnerabilities (CVE-2010-4478 & CVE-2014-1692) both relate to an experimental implementation of J-PAKE, a key exchange protocol. The flaw allows an attacker “to bypass the need for knowledge of the shared secret”, allowing them to authenticate.
From NMap and version numbers alone, you can determine that all of the servers, bar one, have known vulnerabilities. It is kind of sad that to fix it, all that is required would be to login and type a couple of commands. The package manager would update everything installed.
Note that many Linux Distro’s such as Debian and Red Hat Enterprise Linux backport critical security patches to older versions of their distro’s. Unfortunately there is no, legal, way to determine if a particular server is up to date with these patches short of asking. As a result, I am going to assume the worst, which means that the server’s likely will be less vulnerable than the above table suggests. Regardless, we can conclude that the 49 servers in the DMZ are likely, very vulnerable and should be immediately updated.
Short-comings of Network Penetration Testing
Network penetration testing is a fantastic tool in the arms race against cyber-criminals abusing the Internet. A comprehensive, ethical test can help you secure your network by showing that you need to close unnecessary ports, and update mission critical software. However, network penetration has its short-comings and if performed incorrectly, can go horribly wrong. It will not provide your staff training so as not to fall victim to social engineering such as phishing.
A network penetration test starts with defining a scope for the test to be carried out within. If the scope is too small, then vulnerabilities could easily be missed by an ethical tester, sticking within the bounds given. Worse is if the scope is too large or the tester is reckless. By using automated tools or acting unprofessionally, the tester could cause real harm to the target by taking down a vital server, causing data corruption in important data or even causing a loss of life.
When you commission a network penetration test, you are putting your network in the hands of the tester. While professional testers will have certifications including the (ISC)2 Code of ethics, the tester is still human, still fallible. Worse is when, to save money, a novice or enthusiast could be hired.
A network penetration test is a huge risk, and it won’t even find all the known vulnerabilities, how many found depends on the time given and the imagination of the tester.
An ethical tester will be unable to look for every flaw that a criminal would try to exploit, as many could cause real damage to the network. A skilled tester would have to have to expect the worst and potentially report non-existent vulnerabilities, taking time and money to resolve.
Regardless of skill, the tester can never find vulnerabilities that aren’t publicly known. As a piece of software is used, more vulnerabilities are discovered, reported and fixed for the next version (Sometimes backported by various distributions). A skilled attacker could find a 0-day vulnerability and use it against a network. No matter how often the network is penetration tested, any test is unlikely to discover a 0-day vulnerability, until it’s too late.
Some organizations may feel uncomfortable to hire a tester to ethically exploit their network. After all, the only way someone can perform a network penetration test is to know how to successfully exploit a network themselves. The tester might be experienced at exploiting networks to cause damage or gain money, vetting who is hired is incredibly import.
Few typical network penetration tests will cover one of the most important aspects of security, social engineering. This is because asking a tester to exploit staff to gain additional privileges to allow them to further exploit your network is incredibly risky. Not forgetting that some staff may be over-eager to help, or have poor password habits such leaving them attached to a monitor, or creating passwords that are easily guessable. Humans are usually the weakest link, therefor there is little point securing the network but neglecting to train staff about the importance of security.
To re-iterate, network penetration tests are a fantastic tool to increase security, but they are not without their downsides and should always be treated carefully in order to get the most out of the test. They are a crucial step in Vulnerability Analysis and Management. Unfortunately, risk adverse organizations may shy away from network penetration testing, leaving an untested and potentially insecure network at the mercy of the Internet.