.

The Use of Buffer Overflow Exploits During Pentests

<<

24772433

User avatar

Newbie
Newbie

Posts: 34

Joined: Thu Oct 20, 2011 3:22 pm

Location: UK

Post Fri May 18, 2012 4:16 am

The Use of Buffer Overflow Exploits During Pentests

Should pentesters be runing these types of exploits against live servers? Sure, I understand any Ethical hacker worth his salt will go at great length to explain the risks involed with testing in a production environment and the need for system backups, and no doubt there will be wording in any agreement to this effect, but should pentesters be taking such risks?

In my expereience of having pentests run against my companie's network I have had servers hang and firewalls fail to push policies. In a recent penetest Domain Admin was only compromised by running a buffer overflow against an old Symantec vulnerability (Domino). Was this wise?

Are pentesters too concerned about gaining 'root' at any cost? After all, you wouldn't expect to DDos tools run against your live network! So are buffer overflows any different?

Steve
<<

dynamik

Recruiters
Recruiters

Posts: 1119

Joined: Sun Nov 09, 2008 11:00 am

Location: Mile High City

Post Fri May 18, 2012 7:20 am

Re: The Use of Buffer Overflow Exploits During Pentests

It kind of defeats the purpose of the pen test if they don't. Without exploits, how is that different than a vulnerability assessment? The purpose of a penetration test is to demonstrate the actual impact of a compromise, and you're significantly limiting the testers' ability to do that if you take exploitation off the table.

The DDoS analogy really isn't a fair one since that intentionally focuses on disrupting services with a very high likelihood of success. I've seen testers inadvertently take systems/devices/appliances offline with nmap, hydra, and MITM attacks. Should we take network scanning, password cracking, and ARP-poisoning off the table too? You know, just in case...

There's an enormous difference between someone coming in and running autopwn and someone carefully researching and executing a specific exploit. Someone inexperienced and reckless can cause problems regardless of the tools or techniques used. You also need to remember that fluke circumstances may cause problems regardless of the skill or experience of a tester. There is always going to be some inherent risk (then again, I've seen regular users do worse, so that risk may always be present).

An experienced tester/company will work with you to scope the engagement properly to help ensure the impact of such incidents is kept to a minimum. For example, critical systems may be tested after hours, or their test/QA equivalents may be tested instead. This starts to deviate from a "true" penetration test, but it's often necessary to balance business and security requirements. On the other hand, if such a DoS condition exists, when would you prefer to learn about it? It's extremely unlikely that a tester would be the sole person capable of triggering it.

Regarding your Domino server, what value would the deliverable have had if they didn't? Why not just do a vulnerability scan and write, "This vulnerability could be leveraged to compromise the network," next to each finding? Seeing is believing and an actual results seem to get stronger executive attention and support for remediation.
The day you stop learning is the day you start becoming obsolete.
<<

24772433

User avatar

Newbie
Newbie

Posts: 34

Joined: Thu Oct 20, 2011 3:22 pm

Location: UK

Post Fri May 18, 2012 8:27 am

Re: The Use of Buffer Overflow Exploits During Pentests

In posing the question I'm very much playing Devil's Advocate. I do value the benefit of going beyond a simple vulnerability assessment and looking to demonstrate an exploit.

I do agree, it's a balance between business continuity and exposure to risk. A malicious hacker won't care less if the server blue-screens, other than maybe attracting attention to their nefarious activities.

So it's a case of saying who do want to be the first to find these vulnerabilites? A pentester, working in agreed boundaries, or a hacker who doesn't play by the rules?

I have seen (not many) security companies offering Penetration Testing services who claim they do not run buffer overflow exploits against live systems. Are they pulling the wool over their clients eyes?  maybe!

Steve
<<

sil

User avatar

Hero Member
Hero Member

Posts: 551

Joined: Thu Mar 20, 2008 8:01 am

Location: ::1

Post Fri May 18, 2012 8:37 am

Re: The Use of Buffer Overflow Exploits During Pentests

24772433 wrote:Should pentesters be runing these types of exploits against live servers? Sure, I understand any Ethical hacker worth his salt will go at great length to explain the risks involed with testing in a production environment and the need for system backups, and no doubt there will be wording in any agreement to this effect, but should pentesters be taking such risks?

In my expereience of having pentests run against my companie's network I have had servers hang and firewalls fail to push policies. In a recent penetest Domain Admin was only compromised by running a buffer overflow against an old Symantec vulnerability (Domino). Was this wise?

Are pentesters too concerned about gaining 'root' at any cost? After all, you wouldn't expect to DDos tools run against your live network! So are buffer overflows any different?

Steve


My answer will likely annoy some so I will explain it as best as possible. When it comes to buffer overflows and outright full blown exploitation, it really depends. If there is a mechanism I can use to validate that a specific vulnerability is exploitable, I will offer the proof while trying not to exploit it and leave the option to the client of going that distance to the client. There is a separation here which is going to catch someone reading this off guard:

When I perform a penetration test for a client, my goal is to get in, out, family jewels. Bottom line. I am not there to perform free security testing (fuzzing, reversing) for Cisco, or Microsoft, nor whatever other product my client is using. This is what recon, research and prototype labs are for.

Suppose I am testing a "known to be vulnerable/exploitable" version of say Coffee 2.0. I can try to see whether or not I can obtain my own copy of the same exact version my client is running, exploit my own and offer it as a result: "I exploited Coffee 2.0 in my lab which is similar to your Coffee 2.0" and then work with their staff to match any differences. Sometimes a Proof of Concept is enough.

Now, when you state that pentesters are hellbent to get root at all costs, I beg to differ. Getting root or administrator access is 3rd on my list when I perform penetration. My first goal is to get into an environment period. That alone is cause for concern as there is the possibility that if I got that far, I will get further. My second concern is getting data, and I don't always need to be root/admin to do so. I can compromise an SA/DBA account and still have the same impact. If I can, by all means I will go the distance to get root, but most times, getting in, getting data is enough, showing the passwords/accounts of other users is often enough.

Too many individuals aiming that high (3y3 h4v3 r00t) leave a lot to be desired in a penetration test and need to gain a lot more experience in the real world. So think about this for a minute:

HellbentOnRoot Pentester: "We were unable to obtain root access. Seal of approval your safe"

Experienced Pentester: "After getting into your infrastructure, I was unable to gain root but I did manage to use  the credentials of a DBA account and obtain a list of your clients, partners, and employees. I decided not to exploit a known to be vulnerable version of Coffee 2.0 since I had obtained the family jewels however, Coffee 2.0 has known holes which attackers are known to have exploited and in my pilot lab, I was able to exploit it. Here are the references to the exploit and here is a video demonstration of me exploiting it in my lab."

At the end of the day though, it all boils down to the SOW between the tester and the client. In many high end environments, I have done testing on failovers and backup systems as they were exact copies of the running environments. I did so to avoid taking out mission critical equipment yielding the needed results. I have yet to crash anything on a client's network and this is because there is a set of exploits I know will crash a particular, so I avoid them at all costs. Most of the times, I don't even need them. That's just me though.

Return to Network Pen Testing

Who is online

Users browsing this forum: No registered users and 2 guests

cron
.
Powered by phpBB® Forum Software © phpBB Group.
Designed by ST Software