Pen Testing

One of the pillars of security prevention measure, call it due diligence, if you prefer, is the so called “pen test“.

In the eyes of many, this stands for penetration testing, and, undoubtedly, that’s how the name originated. However, what people normally call pentest is nothing at all like a real penetration testing. To clarify, in most cases, it’s a simple port scanning. If it’s “deployed well” then maybe there is some additional in-depth analysis of the traffic accepted by the open ports, more commonly known as a vulnerability assessment.

So, when we hear pentesting, we should rather say vulnerability assessment. That is because a true and in-depth penetration testing implies a lot more than what is done even in the most thorough of vulnerability assessments. In fact, it is merely the starting point of a real and full blown penetration test. Once the open ports have been found, and the vulnerabilities assessed, the real penetration test begins, by attempting an exploit of the vulnerabilities; by attempting to actually gain access to the internal systems; by attempting to steal data – or in short, by attempting an actual hack.

A vulnerability assessment stops short of attempting to hack those vulnerabilities for many reasons.

The first is cost.

While a vulnerability assessment can be mostly, if not entirely, automated, and the cost somewhat contained, a penetration test requires a human actually attempting to get in, and this greatly increases the cost (whitehat hackers aren’t cheap). It also takes a lot of time, as is easy to imagine, since each vulnerability found will have to be tested, in multiple ways.

But there is also another issue, likely even more important. While a vulnerability assessment is relatively harmless, attempting to penetrate a network can result in loss of data or broken servers, i.e., it can cause damage to the network. Even an experienced whitehat hacker could inflict some serious harm while conducting a penetration test. There is always a risk, no matter how low; and it is one that most companies don’t wish to undertake.

Vulnerability assessment has become an accepted way to determine whether a network is safe from cyber hacks.

AND THAT IS A PROBLEM

Because, in reality, a successful assessment (one that reveals no apparent vulnerabilities), will give network owners in question a false sense of strength and security. A successful vulnerability assessment means nothing. Truthfully, it simply means the auditor wasn’t able to find a vulnerable port open but that does not mean the network cannot be attacked. Attacks can come to a network in many different forms, from different places. The exploitation of a vulnerability on an open port from the Internet is almost a rare occurrence, given the many other ways that a network can be attacked, and given the fact that firewalls are relatively inexpensive nowadays.

Which brings me to a very important point – outbound testing.

No one, and I mean _no_one_, does outbound testing to see what is open in a firewall. Only recently (in 2017, mind you) have I seen some auditors _finally_ starting to manually check outbound firewall rules in an attempt to understand what might be allowed. However, doing so manually is limiting at best, as most likely, the assessment will reveal grossly incorrect results. Reading a firewall configuration can, in most cases, be difficult and time consuming. When you have to interpret maybe hundreds of lines of code manually, it is extremely easy to miss things, or to not realize something is open when it shouldn’t be. But at least, this is better than ignoring egress rules altogether, or accepting an “allow all” outbound, only because there are people who still insist in considering the LAN a trusted network in 2017.

I cannot count the number of times when I check firewall rules for devices we’re replacing, only to find something like this in the configuration “ip any any permit”.

This is CISCO lingo for “allow everything, from any source to any destination“. And is easily the single most dangerous statement in a firewall configuration. One that should _always_ be avoided.

Referring to IP in an access list refers to all IP based protocols. This includes TCP, UDP, but also OSFP, and so forth. If you have a Linux machine, check the file called /etc/protocols, and behold the full list of such protocols!

Why am I so adamant about this being _very_ bad practices? 

Because that is what trojans _hope_ you have done in your network. A full blown trojan is an executable file. Hackers don’t send those as attachments to emails anymore, because any halfway decent email scanner is capable of blocking such things. What they send you is a downloader. A smaller piece of code, maybe a script, maybe a macro in a document. Something that cannot immediately be recognized as executable, and that your gateway filter may not block. If that passes through, then it tries to connect outbound to a command and control center, from which it will download the actual trojan. The way it typically makes this connection is by scanning your firewall for outbound open ports. Therefore, the single most effective way to protect a network from such exploits is to ensure that there are no unnecessary outbound open ports in the firewall. You definitely do not want an “ip any any permit“, ever!

At this stage, it should be clear that vulnerability scanning is misleading for an array of reasons.

It creates a false sense of security and safety.

Companies think they have all ports locked down, and therefore, their network is impenetrable. Or, alternatively, they may worry about a result of the scanning, when there really are no actual vulnerabilities (or no exploitable ones) behind that port. However, at the same time, this scan does not check for outbound ports, and a user could accidentally download a trojan that will take down the entire network; yes, the same one that was just declared safe by the scanning. This is happening over and over again, every day, to companies that spend millions of dollars to protect their networks, routinely scanning them for vulnerabilities. It matters not that inbound traffic is protected if outbound traffic is not even checked.

What I propose should become a new standard, egress scanning of the firewall should. Run the test from inside out. Provision a server outside the network, to listen to all 65,536 available ports. Then attempt a connection from inside the network to that server. In a well configured firewall, you should not succeed on almost any port.

I say almost because you will (unfortunately) need to open ports such as domain (UDP/53), http (TCP/80), https (TCP/443), time server (UDP/123). But, if you do find other ports open, check the firewall configuration, find the line that allows that connection, and lock it down by limiting the source and/or the destination.

FAST.

Lock down your egress rules; and witness your security posture immediately increase tenfold.  With minimal effort.  And observe how the scanning becomes so much more meaningful!