The Profiling team at SecureState discovered a critical flaw in an older version of Courion’s Access Risk Management Suite. This vulnerability allows an unauthenticated attacker to remotely compromise a system by leveraging functionality exposed within the Remote Desktop Protocol service. Continue reading
Imagine your company just had a penetration test and the ethical hacking firm was successful in gaining access to your confidential data and/or systems. Not too hard to imagine, as it happens to companies all the time. You review the recommendations and fix the hole(s) they’d used to gain access, but what about the other vulnerabilities that the ethical hacker did not exploit?
As medical science advances, so too does the equipment used to deliver care. In a modern-day hospital, more and more medical devices, such as IV pumps, ventilators, MRI, CAT Scan and X-Ray machines are attached to hospital networks. Putting medical devices on the network provides a large number of benefits, such as supporting telemedicine and the easy transfer of test results to electronic medical records (ERM) systems. However, putting these devices on a network also introduces a number of risks.
Simply put, a Vulnerability Management Program is a program an organization develops in order to manage its vulnerabilities. A good Vulnerability Management Program gives an organization a great view of the effectiveness of the security controls they have implemented.
Many organizations are caught in a vicious cycle when it comes to information security, and it probably feels like there is no hope of escape.
Have you ever had a penetration tester ask permission to execute an attack or perform some other action? You should have, because we would prefer to do that rather than just try that “risky” exploit or make the configuration change. To be clear, most penetration testers don’t go rogue. If the company that does your assessments is doing these types of actions without checking with you first, it’s time to reconsider who you are contracting for your assessments.
What is the difference between vulnerability assessments and penetration tests?
In the IT industry, a number of people have the same common misconception: penetration tests and vulnerability assessments are the same thing. There are differences that I don’t think enough people are aware of. I would like to clear up any sort of confusion. First, let’s take a look at what each of these assessments are, and why you would want or need these assessments.
A Penetration Test is an assessment that exploits known and unknown vulnerabilities on a web application, operating system, web server, and network. Once a vulnerability has been exploited, a Penetration Test can then show what data can be accessed. For example, if there is a missing patch on a system, and exploiting this missing patch gives you access to a system with credit card data, the Penetration Test frames the criticality of the missing patch. A Vulnerability Assessment cannot do that.
A Vulnerability Assessment is a scan that will identify known network, operating system, web application, and web server vulnerabilities with the use of automated tools such as Nessus, WebInspect, Netsparker, and Qualys, just to name a few. Using an automated tool can give you an overall picture of the technical risk of a company’s network. A vulnerability scan is a good way to identify vulnerabilities on a large number of systems, in a shorter period of time. The Vulnerability Assessment will only recognize a “signature” of a weakness, and give it a technical risk rating. Most vulnerability scanners do not do a good job of finding the same vulnerabilities that come up in a Penetration Test.
The Payment Card Industry Data Security Standard (PCI DSS) is one reason why a company would need to have a Vulnerability Assessment or Penetration Test performed, and it identifies the difference between the two. PCI DSS Requirement 11.2 mentions that a Vulnerability Assessment is an automated tool that is run against external and internal network devices. PCI DSS Requirement 11.3 says that network and application Penetration Tests are different from vulnerability scans in that Penetration Tests are a lot more manual, and can attempt to exploit vulnerabilities that are found in a Vulnerability Assessment. Simply put, a Vulnerability Assessment is a piece of code that will identify and report on known vulnerabilities. Because of the way vulnerability scanners identify vulnerabilities, a scanner will more likely run into false positives. A Penetration Test goes a step further in that a human exploits vulnerabilities that are found. And because there is a human exploiting vulnerabilities, false positives do not exist.
In my opinion, it is impossible to say that a Vulnerability Assessment is better than a Penetration Test, or vice versa. Both Vulnerability Assessments and Penetration Tests are very valuable to an organization’s network security. So depending on what steps you want to take to securing your network, you can have one or the other, or even both, performed. When you are looking to have these two assessments performed, keep in mind that you will get two different outcomes.
A vulnerability assessment is an important element in understanding a company’s threat profile. When performing a threat vulnerability assessment, it should include more than just running a scan, printing a pretty report and sending it out to a client, management, or administrator. It must also be about confidence and accuracy. What makes you confident in the report you send to a client, your management, or administrator? What makes YOUR report more accurate than others? Validation. What is validation? Validation is testing a vulnerability that has been found. Depending on how far you dive into validation, it can contain many elements of a penetration test. What makes validation most important is identification of false positives. Every vulnerability scanner, no matter how many bells and whistles it has, will produce false positives. There is no scanner on the market that can find every vulnerability and not produce false positives.
When performing threat vulnerability assessments I see a lot of “SSL Certificate – Subject Common Name Does Not Match Server FQDN” vulnerabilities. A majority of the time I come across this vulnerability it’s a false positive because of the common name (CN) of the certificate. There are many companies that use the wildcard (*) in the CN field, for example, *.myhappydomainname.com. It isn’t necessarily bad that companies use the wildcard, but because the scanner is unable to associate the wildcard with the FQDN of the system being scanned, this is flagged as a vulnerability. To exploit this vulnerability, an attacker could use a man-in-the-middle attack along with some DNS cache poisoning and then lure a client to another server and steal the encryption communication.
Let’s say you are an intern or a co-op and your task is to run a vulnerability assessment on a specific range of IP addresses. The report shows a vulnerability where you can get to management interfaces on a Cisco device. You then validate this interesting vulnerability by using a great tool called telnet. Not only did you just validate a “Management Interfaces Vulnerability,” but you also just found a different vulnerability of using clear-text protocols. Now that you are being asked for a username and password on this Cisco device you enter “admin” for the username, and “admin” for the password. Now you see a place to enter commands. Congratulations, you just found and validated a “Default Passwords Vulnerability”. Let’s also say that during this assessment you find other vulnerabilities that deal with a vulnerable version of SSH and readable SNMP information, and through validation you were able to confirm these vulnerabilities exist. Because this was done, you were able to find out that someone put a Cisco device on the network, and somehow forgot to securely configure it. Knowing that validation was done on these systems, more confidence and accuracy can be put in the report.
Too often I, as well as many of my co-workers, go into a client and throughout whatever assessment I am working on, general questions come up like, “when’s the last time you’ve had a pen test?” And the client responds, “Ohhh, we do those annually with ‘Some Corporation.’ ” And after looking at ‘Some Corporation’s’ website and seeing what they consider to be a penetration test, I am again disgusted to see that they show up with a vulnerability scanner, run it, validate some findings, and are off to their next client.
Now I know these are some brash comments made toward some random security companies, but let’s be honest here: If you’re going to do something, do it right the first time and provide your client the value of the assessment they paid for. Additionally, give the client what they paid for. If I go to a salesman to buy a sports car and he tries to sell me a Honda Civic, I’m going somewhere else to get what I asked for. On the other side of the coin is the fact that a lot of companies that want a penetration test don’t really understand what it is to begin with. It seems to me that gone are the days of true pen testing when the dreaded “Red Team” shows up to strike real fear into the hearts and minds of Security Practitioners at Fortune 1000 companies.
Any kid in their parent’s basement with savvy computer skills can fire up a Nessus scanner, Web Application Scanners, or Qualys Guard against a network and some of those people can actually interpret the results to make sense out of them. Trust me, everyone on SecureState’s Profiling Team can do that with their eyes closed, but how many security companies out there can actually run a legitimate pen test? I’m not calling anyone out and challenging them, but in all reality, I just want to know how many companies are willing to admit that what they call a “Penetration Test” is actually just a vulnerability assessment? Even worse is the number of companies who perform so called “penetration tests” and truly believe that a vulnerability assessment is the same thing as a pen test.
So let’s all be clear here: a true penetration test is over 85 percent manual and the remaining 15 percent can be a vulnerability scanner to get some other findings in a report in order to provide additional value to the client. And let’s also define manual attacks as to not be ruling out all tools. Using a port scanner is way different than using nCircle, Qualys, or Nessus. Automated scanners like these are the tools that don’t really help a pen test. And just because you use a tool like the Metasploit Framework and many of the tools in Back|Track 4, doesn’t mean you are running a vulnerability scanner. NMAP has the ability to run scripts as well, but again, it doesn’t belong in the Vulnerability Scanner category.
Many times, companies perform Attack and Penetratio’s due to compliance, or potentially other reasons, which is a bad idea. It gives those companies the opportunity to choose malicious compliance over the desire for truly assessing the security of the entire company. Malicious compliance is a term used when companies do the bare minimum in order to achieve a stamp of approval for whatever standards they are trying to satisfy the needs of. When companies choose to perform pen tests on only their systems affected by compliance, such as PCI or HIPAA systems, they are missing entire networks of systems which aren’t tested. When this happens, companies aren’t getting the true value of what a Pen Test can provide.
SecureState is a trend setting company, and this is where we are going to step in and say, “We Pen Test!” The PCI DSS Council has at least defined what they consider a penetration test. In section 11.3 the Council defines it to be: “vulnerability assessment simply identifies and reports noted vulnerabilities, whereas a penetration test attempts to exploit the vulnerabilities to determine whether unauthorized access or other malicious activity is possible.” Even the EC Council states that, “Penetration testing simulates methods that intruders use to gain unauthorized access to an organization’s networked systems and then compromise them. Penetration testers may use proprietary and/or open source tools to test known technical vulnerabilities in networked systems. Apart from automated techniques, penetration testing involves manual techniques for conducting targeted testing on specific systems to ensure that there are no security flaws that may have gone undetected earlier.”
The SecureState Profiling Team utilizes lower risk vulnerabilities in some systems with additional vulnerabilities in other systems and links them together into larger attacks. By pulling off an attack in this fashion, the Profiling Team utilizes what is called the Vulnerability Linkage Theory in which we can show why it’s important to maintain system baselines and other security measures. The Vulnerability Linkage Theory shows how the attack was pulled off by coupling vulnerabilities in many systems to result in the end compromise. For instance, username enumeration from a website, coupled with a brute force attack on the mail system, could allow SecureState to access mail from a company. From here we can email the tech support team and social engineer them into divulging information on how to access the corporate VPN and voila: access to the internal corporate network. There is no way a vulnerability scanner can do that.
Penetration tests zero in to specific systems in order to break in and see what information can be divulged. Pilfering computers and file shares will explain the benefits of Pen Tests by finding the important documents and unencrypted data. Even finding password protected Microsoft Office files can be cracked to release potentially serious data about a company we’re hacking into. Pen Tests can also be used by Security Departments to show why things need to be fixed and get budget to move forward.
There are conflicting views on Pen Tests and Vulnerability Scans. Pen Tests aren’t performed to find vulnerabilities; they are done in order to compromise systems and networks. The main difference between the two is that in a pen test the attackers are actually exploiting vulnerabilities in systems, adding user accounts, and compromising machines across the network. A full or total compromise, which means total control over the entire network, is the end goal of a pen test. Throughout a pen test, the attackers will inevitably generate a list of findings. Many of these findings may be the same as what a vulnerability assessment will also come up with, but there are many vulnerabilities that scanners just can’t find, which leads to the fact that tools can’t think; consultants can. Consultants are able to interpret results and decide on how to use them in order to leverage certain attack vectors against machines and networks.
Don’t get me wrong: I am not discounting the need, want, or value of a vulnerability assessment. These assessments, as well as pen tests, have their place and need. What I am saying is that these assessments need to be better understood in order to know how and when they should be performed. Additionally, there have been companies that run regular vulnerability assessments and the same vulnerabilities keep coming up every single scan. These companies are either overwhelmed with the amount of vulnerabilities present in their networks and don’t know how to fix them, or they don’t see the value or need in fixing them. Penetration tests can enforce the reasoning. In turn, by better understanding what the difference is, the clients will understand what to expect as a final product and won’t be dissatisfied with the results of each test.