Tag: penetration testing

Penetration Testing and Vulnerability Scans

In our compliance services, oftentimes, we are tasked to assist our clients in security testing – either conducting those ourselves, or to verify previously conducted tests for compliance purposes. There are many occasions where clients decide to perform the scanning on their own, aside from the obvious option of engaging another party to do this. When we receive the test reports from our client to verify, that’s when the excitement begins.

The fundamental question we often face is, what should a penetration testing report look like? What does a vulnerability scan looks like? This age old question has been haunting PCI-DSS for years, so much so that the council decided to publish a guidance on this, found: https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf

It’s a good read, if not fairly simplified, but it seeks valiantly to answer the question of what is a penetration testing vs vulnerability scans. This is important, because in PCI-DSS, the latter needs to be done quarterly, while the former needs to be done annually. When you multiply that by the costs and number of assets in scope, we could be looking at a decision involving tens of thousands of dollars.

In the document, section 2.1 dives into this and attempts to seek a differentiation between these two. In the basic concept of penetration testing methodology, these two activities serve specific purposes, for instance in the activities of Discovery, Enumeration, Footprinting, Exploitation, Cleanup etc, depending on which approach you take. And while there are many ways to explain the differences, to summarise:

A penetration test can be a vulnerability assessment (or scan, we will use interchangeably for the sake of this article) and beyond, while a vulnerability scan is not a penetration test.

A Penetration test can be initiated with a vulnerability assessment. The result from the vulnerability assessment will be used by the tester to penetrate or perform a more detailed assessment to circumvent controls or exploit the discovered vulnerabilities. In the process, the tester will also use manual methods to “test” the vulnerable system and likely during this process of poking around, discover more vulnerabilities or loopholes in the system that may not be detected during the initial scan. In the presentation of the findings of a penetration testing report, typically the ‘Proof of Concept’ (POC) detailing how the vulnerability was exploited will be documented.

Vulnerability assessment is the process to find out known vulnerabilities by using an (oftentimes) automated method (such as scanning software or scripts) against the targeted system. The result of the scanning will detail down the vulnerabilities, the risk exposures and action that can be taken to remediate these vulnerabilities. There is typically no manual proof of concepts that is done in the penetration test. The objective of a vulnerability assessment is to discover and report known vulnerabilities, not to exploit them.

A penetration test will normally take longer time to complete, i.e. few days, considering the manual verification or activities that need to be carried out to ‘penetrate’ the vulnerabilities. A vulnerability assessment can be completed in a shorter time frame, depending on the size of scope and software installed on the target system and it can be run on automated or scheduled basis. In our vulnerability scans, we also refine the results further by eliminating false positives, such as a patch that might not have been applied, but other secondary controls like virtual patching are in place to mitigate the risks. In either case, these are different activities, and in PCI, we need to understand what is NOT Penetration Testing.

We once received a 250 page report from our client who proudly said this was a professional work done by an outsourced security testing company offshore. Surprised as such a tome, which we assumed must have excerpts of Tolkien’s Lord of The Rings in there for good measure – we went through it. We found that it was nothing more than a raw report of the entire software inventory of the entire scope of around 50 plus assets. Meaning it listed down in excruciating detail what are the software installed in each of these systems, the licenses the OS versions etc. It was nothing more than a dump of the system’s software and nothing more. Not even the courtesy vulnerability scan. We told our bright eyed customer that we cannot accept this, and while this is a good book to have in terms of detailing the software they have, it has nothing to do with penetration testing, or vulnerability assessment. From singing praises of the offshore company, he ended up throwing them invectives that would make a pirate cringe.

We do need to be careful. We are not saying that the entire industry is filled with such charlatans peddling so called pentest services for a song and giving you a report that only provides you with the figurative emperor’s clothing for your security needs…but we must be able to differentiate what is, and what is not, security testing.

If you have further questions on security testing, drop us a note at avantedge@pkfmalaysia.com and we can quickly assess your needs and advice you on your next options to take.

The Obfuscation of PCI Standards

pci-compliance

When you go through the PCI-DSS standard, while in most part, the sections are clear, there are some that just annoys the heck out of me, for good reasons.

Stateful inspection and Anti-spoofing in firewalls – I know these are useful features, but it is extremely rare these days to encounter clients going for PCI-DSS that own firewalls without these capabilities inbuilt. Even the humble ScreenOS running on your tiny SGs (Juniper) are enabled by default. While this isn’t an issue, we’ve faced vexing times when our clients are sometimes asked by their QSA, to show the firewall rules that prove that Stateful inspection and anti-spoofing is turned on. We have to come in and explain to them that its already enabled by default, and they insist on us testing and showing them traffic captures. Sometimes, I just show them the manual and entitle my email “RTFM: Stateful Inspection was first introduced in 1994.” You would think that PCI would do something better than to ask this question.

AntiVirus and AntiMalware – the researchers at Imperva, a couple of years back, did a study of effectiveness of antiviruses.They collected 82 new computer viruses and ran the malware against antiviruses from some of the largest companies like Symantec, Kaspersky, McAfee. The results: initial threat detection rate was 5 percent. That’s detection. This means 95% of malware is undetected. I don’t know how strong this hypothesis is, but frankly, we have known for years antiviruses, while there are limited uses, presents to us a false sense of security. Just because the antivirus says, “ALL IS SECURED” doesn’t really mean anything. The annoyance here is not that PCI has antivirus as part of their controls, they dedicated an entire requirement to it. It’s not effective – move on!

Confusion of application testing – Requirement 6.6 states:

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

a) Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

b) Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.

Now, we need to clarify this because this is obfuscation. Note the nice caveat they put into 11.2. Now, if you go to 11.2, you get a whole bunch of requirements for vulnerability scans, quarterly ASV etc.This is understood, right

So the above, you would surmise this: if I have a WAF (web application firewall), I do not need to do any web applications review, correct? What IS a web application review anyway? In a lot of instance, QSA will interpret it as web application testing, covering OWASP top 10. In pentest world this is called WEB APP PENTEST. This tests issues like cross site scripting, validation etc. You can find more here

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

A web app PT can set you back around RM10 – 25K depending on your web app and the provider. I’ve seen web applications go into the RM50 – 80K regions before for massive applications, but in general for a web application payment system, you would get that range (unless the provider is looking to rip you off, in which case I suggest you give us a buzz).

So if you have 10 – 20 Web App, that would set you back a mile, so the suggestion is to “Let’s invest in WAF”, where you pay a license and every year you don’t have that WEB APPLICATION testing headache siting on your books. In the long run, it makes more sense if you have a lot of web applications to test.

Now, here is the PCI problem.

Requirement 11.3 – Implement a methodology for penetration testing that includes the following:

blah blah blah

 – Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5

Unfortunately the presence of 11.3 renders the earlier requirement choice useless, because now QSA interprets at despite having invested in WAF, they are still insisting on getting 11.3 passed, which requires this application layer PT!

My question to the PCI-SSC, why don’t you include this 11.3 caveat in the earlier 6.6 requirement instead of the useless 11.2 caveat which anyone knows how to read? And if my interpretation is wrong, I am going to war against some of these QSAs because they basically said, it’s nice to have WAF, but you still need to do App PT. In fact, one of them actually said: “Well, the advantage is that you are more secure.” Yes – but our client’s goal was to pass PCI. If they wanted financial modelling and investment advise from you, they would ask it, if not, just do our job and interpret the standards properly! Will someone from PCI-SSC actually clarify this because I’ve talked to some QSAs on either side of this opinion – some say WAF OR APP PT, some say, APP PT regardless of WAF.

To be safe – get your QSA to interpret this before making a decision to invest in WAF, because this is a major roadblock in a lot of cases we are in.

Penetration Testing: What to Expect?

After a relatively quiet 2012 on the penetration testing (PenTest) front, we’ve got quite a number of requests on our penetration testing services in the first month. A lot of clients we speak to don’t really have an idea of what a penetration testing exercise should be. Many of them expect us to do stress testing, load testing and basically all the scope that a QA/QC group should be doing for their software development. We do that as well, but that’s slightly different from a penetration test. Slightly here means, related, but with different objectives. Some pentest scope does have stress test elements, such as breaking the system with DDOS. In other words, the objective is to expose weaknesses and vulnerabilities, as well as to create exploitations, either through a conceptual or practical standpoint on these vulnerabilities.

The first thing to do is to define the objectives and scope. Most companies we’ve dealt with prefers a quick assessment to see immediate weaknesses. While there is nothing wrong with this, as pentesters, we must make our clients realise that this is simply a snapshot vulnerability and it’s not a catch-all. Scoping is usually done with a meeting with the business owners. IT infrastructure can be very large and complex. To pentest the entire infrastructure is obviously not practical, so we need to define a narrower scope based on risks and sensitivity of data. It’s a lot like our IT audits. We establish our audit universe and our incoming points, and then run our pentest exercise against it. Another scope is to establish the type of pentest. We’ve done pentest emulating disgruntled employee with authorised access looking to escalate privileges or remove data. We’ve simulated as script kiddies aiming for a take down on resources and DOS attacks. We’ve simulated concentrated attacks on a group of IP addresses, utilising OSSTMM methodology. Recently we just completed an OWASP Top Ten Web app penetration testing. We’ve had another where multiple attack vectors were looked into, such as HR weaknesses, process weaknesses and a vulnerable FTP server where other attacks can be launched from.

Mostly, the scope will be determined by cost and time. Due to the non-regulated world we live in, most companies won’t want to spend too much on a penetration testing exercise. This is unfortunate, because usually, only after we give our presentation of report, do people realise, “Man, we have all these problems??”

Another point is to define the rules of engagement. Unlike other engagements, penetration test is high risk. It’s controlled, but it’s still simulating an attack. In many apps we’ve tested, we’ve found that they have NEVER gone through any QA/QC testing in the first place. In one engagement, our benign scan brought down the whole HA cluster. Luckily, our Rules of Engagement was already in place, to do testing in a non-peak hour and had a standby team, and we brought back up the systems with no significant impact. Still, it highlights the criticality of treating the pentest exercise with utmost seriousness. We cannot determine how systems will react to our exercise 100%, but we can draw boundaries. For instance, in one project, we were only allowed to create a benign file to demonstrate compromised access. In another, we were permitted to put in a keylog software to demonstrate the ineffectiveness of both host controls and network controls. Most of all COMMUNICATION is the most important thing. We are not a bunch of dark-cloaked hackers out to destroy our client’s credibility. We inform our clients on progress daily, and in some instance, as we go through a critical exercise, step by step, through Skype of Gtalk. The client must feel secure and the only way is through properly diseminated information.

I spoke to a client before who had hired someone from the net to do a pentest. Not only was the pentest successful, but he suspects some data was even taken. Because there was no communication or rules of engagement, he couldn’t get a proper report out and because he did not know what has been compromised, he had to completely change his security passwords and such.

We’re not saying we’re the best in the world. We’re saying that in whatever we do, our best interest must be the client’s best interest. As a company, there is absolutely very little benefit in us destroying our reputation by doing a shoddy job or stealing information, and putting our business at risk.

If you want to know more about what we do, drop us a line at avantedge@pkfmalaysia.com and we will get one of our consultants to get back to you directly.

In the meantime, here’s to a great 2013 ahead to all!

 

Stopping Insider Scans

I’ll admit it. I’ve knocked on doors before, while sitting at Starbucks.

“Knocking on doors” here means running port scanners like Nmap, or vulnerability scanners like Nessus or Nexpose, to see if that guy in the suit across the room is using a laptop that’s vulnerable to exploits. I was much younger then. WiFi was just introduced, and to a guy born with a curious mind like mine, this was exciting stuff. I wasn’t a hacker or cracker by any means, neither did I dwell too much in doing malicious scripts, but it was just curiosity that got me going.

I did find myself on the good side of the law soon, running DHL’s global security group in Asia, and there faced monumental challenges like random denial of services,and naughty scans from external.

However, it is usually the insiders that do us in.

I’m sure you heard before, a secured perimeter is only as strong as its weakest link. And the weakest link is usually inside. A disgruntled employee. A corporate spy. A curious, idle employee with too much time on his hands, and reading too much Network Security Online articles. Whatever the case, every company will have its day in the sun. It’s just a matter of when.

For instance, we ran our penetration testing services for a network. We usually don’t have too much issues in the scanning phase, where we enumerate services and probe a little for vulnerabilities. Our standard process was to inform our client when we were doing exploits. One thing we’ve learnt in almost every project we’ve done.

Not everything goes according to plan.

It was an internal penetration testing, but we weren’t given much details on the network or servers as agreed and we ran several IPs scan at once. Soon, our technical client came back to inform that their servers were not doing too well, and one of the virtual servers running HA has rebooted. We immediately stopped the scans and realised that the IPs given were all running on VM. Nessus and VM does not play nice. Do a search on nessus on communities.vmware.com and pick your poison.

Thankfully, nothing serious occurred, which shows us again how important it was to have people ready and standby especially in PenTest and to follow certain set procedures and standards. We continued the pentest exercise with greater care, taking into account the vulnerabilities of Nessus and VM, and using alternative scanners.

Which shows, how simple it is for someone to DOS (Denial of Service) a network, with just a vanilla Nessus running. What can a company do about it?

Well several options are there:

1) IPS/IDS (Intrusion Prevention/Detection System). These babies usually run on the network points and works wonders to detect scans and stop them, among other thing. We used to run Tipping Point a lot in my previous companies. The problem here is that for a flat network, how do we want to run this? The server needs to be segregated into its own server segment, and an IPS laid out in front of the network point. In a flat network where everything is plugged into a single IP address space, it still can be done, I suppose, but probably not the best way.

2) HIPS/HIDS (Host IPS/IDS). It’s like a mini gun compared to a gatling gun. It runs on critical servers and works about the same way, except that the network interface gets hit before the intrusion prevention services kicks in. It’s pretty effective and we ran a lot of Symantec previously.

3) If those don’t do the trick, then we could probably secure every end point. If we want to secure internal attacks, the best way is to properly guard your asset. Control all your laptops through proper asset management, no administrative capability to install Nessus and an asset scan to ensure nothing naughty has been somehow installed on by enterprising employees. You might want to control/choke up the USB ports as well.

4) Finally, set corporate policies. Many companies fail to do this and we don’t know why. Document what will happen if activities like scanning is done. Make sure employees understand their obligations to the company and sign acceptable use policies before giving them corporate-owned assets, bought by corporate owned money. Sometimes a little awareness works better at prevention.

There are probably other ways I’ve missed out, but generally this would be how we’d deal with idle employees with too much time on their hands scanning our network. That, and putting them on a cold-storage project to wash out their curiosity, maybe.

© 2020 PKF AvantEdge

Theme by Anders NorenUp ↑