Hosted Solutions – A Hackers Haven

Human beings are lazy by nature. If there is a choice to be made between a complicated technology solution and an easy technology solution, then nine times out of ten people will choose the easy solution. The problem is that the easy solutions are often riddled with hidden risks and those risks can end up costing the consumer more money in damages then what might be saved by using the easy solution.

The advantages of using a managed hosting provider to host your email, website, telephone systems, etc, are clear. When you outsource critical infrastructure components you save money. The savings are quickly realized because you no longer need to spend money running a full scale IT operation. In many cases, you don’t even need to worry about purchasing hardware, software, or even hiring IT staff to support the infrastructure.

What isn’t clear to most people is the serious risk that outsourcing can introduce to their business. In nearly all cases a business will have a radically lower risk and exposure profile if they keep everything in-house. This is true because of the substantial attack surface that hosting providers have when compared to in-house IT environments.

For example, a web-hosting provider might host 1,000 websites across 50 physical servers. If one of those websites contains a single vulnerability and that vulnerability is exploited by a hacker then the hacker will likely take control of the entire server. At that point the hacker will have successfully compromised and taken control of all 50 websites with a single attack.

In non-hosted environments there might be only one Internet facing website as opposed to the 1000 that exist in a hosted environment. As such the attack surface for this example would be 1000 times greater in a hosted environment than it is in a non-hosted environment. In a hosted environment the risks that other customers introduce to the infrastructure also become your risk. In a non-hosted environment you are only impacted by your own risks.

To make matters worse, many people assume that such a risk isn’t significant because they do not use their hosted systems for any critical transactions. They fail to consider the fact that the hacker can modify the contents of the compromised system. These modifications can involve redirecting online banking portal links, credit card form posting links, or even to spread infectious malware. While this is true for any compromised system, the chances of suffering a compromise in a hosted environment are much greater than in a non-hosted environment.

Social Engineering – It’s Nothing New

With all the recent hype about Social Engineering we figured that we’d chime in and tell people what’s really going on. The fact is that Social Engineering is nothing more than a Confidence Trick being carried out by a Con Artist. The only difference between the term Social Engineering and Confidence Trick is that Social Engineering is predominately used with relation to technology.

So what is it really? Social Engineering is the act of exploiting a person’s natural tendency to trust another person or entity. Because the vulnerability exists within people, there is no truly effective method for remediation. That is not to say that you cannot protect your sensitive data, but it is to say that you cannot always prevent your people or even yourself from being successfully conned.

The core ingredients required to perform a successful confidence trick are no different today then they were before the advent of the Internet. The con artist must have the victim’s trust, and then trick the victim into performing an action or divulging information. The Internet certainly didn’t create the risk but it does make it easier for the threat to align with the risk.

Before the advent of the Internet the con artist (threat) needed to contact the victim (risk) via telephone, in person, via snail mail, etc. Once contact was made a good story needed to be put into place and the victim’s trust needed to be earned. That process could take months or even years and even then success isn’t guaranteed.

The advent of the Internet provided the threat with many more avenues’ through which it could successfully align with the risk. Specifically, the Internet enables the threat to align with hundreds or even thousands of risks simultaneously. That sort of shotgun approach couldn’t be done before and significantly increases an attackers chances of success. One of the most elementary examples of this shotgun approach is the email based phishing attack.

The email based phishing attack doesn’t earn the trust of its victims; it steals trust from existing relationships. Those relationships might exist between the victim and their bank, family member, co-worker, employer, etc. In all instances the email based phishing attack hinges on the attacker’s ability to send emails that look like they are coming from a trusted source (exploitation of trust). From a technical perspective, email spoofing and phishing is trivial (click here for a more sophisticated attack example).

The reason why it is possible for an attacker to steal trust from a victim instead of earning that trust is because “face to face” trust isn’t portable to the Internet. For example, most people trust their spouse. Many people talk to their spouse on AIM, MSN, Yahoo, Skype, etc. while at work. How do they know that they are really chatting with their spouse and not a hacker?

So how do you protect against the social risks and prevent the threat from successfully aligning with those risks? The truth is that you can't. Con artists have been conning people since the dawn of man. The better question what are you doing to protect your data from the hacker that does penetrate into your IT Infrastructure?

Why “DISSECTING THE HACK: The F0rb1dd3n Network” was written. By: Jayson E. Street

Note: This blog entry was written by Jayson E. Street and published on his behalf.

The consumer, the corporate executive, and the government official. Regardless of your perspective, DISSECTING THE HACK: The F0rb1dd3n Network was written to illustrate the issues of Information Security through story. We all tell stories. In fact, we do our best communicating through stories. This book illustrates how very real twenty-first century threats are woven into the daily lives of people in different walks of life.

Three kids in Houston, Texas. A mid-level Swiss businessman traveling abroad. A technical support worker with a gambling problem. An international criminal who will do anything for a profit (and maybe other motives). FBI agents trying to unravel a dangerous puzzle. A widower-engineer just trying to survive. These are just some of the lives brought together in a story of espionage, friendship, puzzles, hacks, and more. Every attack is real. We even tell you how some of these attack are done. And we tell you how to defend against varied attacks as well.

DISSECTING THE HACK: The F0rb1dd3n Network is a two-part work. The first half is a story that can be read by itself. The second half is a technical reference work that can also be read alone. But together, each provides texture and context for the other. The technical reference – called the STAR or “Security Threats Are Real” – explains the “how” and “why” behind much of the story. STAR addresses technical material, policy issues, hacker culture context, and even explains “Easter Eggs” in the story.

This book is the product of a community of Information Security professionals. It is written to illustrate how we are all interesting targets for various reasons. We may be a source of money for criminals through fraud, we might have computing resources that can be used to launch attacks on someone else, or we may be responsible for protecting valuable information. The reasons we are attacked are legion – and so are the ways we are attacked. Our goal is to raise awareness in a community of people who are under-served. Few of us really want dry lectures about how we should act to protect ourselves. But stories of criminals, corporate espionage, friendship and a little juvenile delinquency – now that is the way to learn.

Verify Your Security Provider -- The truth behind manual testing.

Something that I’ve been preaching for a while is that automated vulnerability scanners do not produce quality results and as such shouldn’t be relied on for penetration tests or vulnerability assessments. I’ve been telling people that they should look for a security company that offers manual testing, not just automated scans. The price points for quality work will be significantly higher, but in the end the value is much greater. After all the cost in damages of a single successful compromise is far greater than the cost of the best possible security services.

I’ve noticed that there are a bunch of vendors who claim to be performing manual testing. But when I dig into their methodologies their manual testing isn’t real manual testing at all, its just vetting of automated scanner results or testing based on the results. In other words they test on what the automated scanner reports and don’t do any real manual discovery. I’m not saying that tools like nessus (an automated scanner) don’t have their place, I’m just saying that they aren’t going to protect you from the bad guys. If you want to be protected from the threat, you need to be tested at a level that is a few notches higher than the threat that you are likely to face in the real world.

This is akin to how the Department of Defense tests the armor on its tanks, and I’ve probably mentioned this before somewhere on the blog. But, we don’t test our tanks against fire from bb guns and .22 caliber pistols. If we did that they wouldn’t be very effective in war. We test the tanks against a threat that is a few levels higher in intensity than what they are likely to face in the real world. As a result, the tank can withstand most threats and is a very effective weapon. Doing anything less isn’t going to protect you when the threat tries to align with your risks; you’ll end up being an expensive casualty of war.

So why do some security companies test at this lesser level? Its simple really, they are in the business of making money and care more about that then they do about actually protecting their customer’s infrastructure. Additionally, there is a market for that sort of low quality testing. There are some businesses that don’t actually care about their security posture; they just care about passing the test so that they can put a check in their compliancy box. Then there are other businesses that unknowingly get taken advantage by of vendors because they don’t know the difference between high quality and low quality services.

So what is the difference between high quality and low quality? From a high level perspective it’s the difference between real manual research based security testing or not. Once hackers have access, they can do anything to your data from steal it, to install back door technology in your product's source code. Its happened before, and its going to happen again.

When a company tells you that they perform manual testing hold their feet to the fire. You can do the following things to verify it:

• Dig into their methodology and ask them specific questions about how they perform their testing. (See our white papers on how to do that).
• Don’t swallow jargon and terms that sound cool and don’t mean anything, use Wikipedia to look up the terms and make sure that they make sense.
• Ask them for the names of their security experts and then use tools like Google, LinkedIn, Facebook and PIPL to do research on those experts. If nothing comes up then chances are their experts aren’t experts at all.
• Search vulnerability databases like milw0rm, securityfocus, sirtfr, secunia, packetstormsecurity, etc. for the vendor’s name to see if they have research capabilities. If you don’t get anything in return then chances are that they don’t have research capabilities. If that’s the case then how do you expect them to perform quality manual testing? Chances are that they won’t be able to.

Remember you’re putting the integrity of your business and its respective name into their hands.

SNOsoft - Blosoft - GLOsoft - Awesome!

Normally we wouldn't give an iota of attention to trolls, but there's always the exception to the rule. The past two advisories that we (Netragard/SNOsoft) released have been followed up by a troll publishing hilarious spoofs of those advisories. So far the spoofs they've released can be found here and are called "BloSoft" and "GloSoft". We're actually proud (and flattered) that these trolls think that we're important enough to spoof because that's a testament to our success as a security company. To us, its sort of like being the target subject for a Saturday Night Live skit. So for the first time ever, thank you to the troll whoever you are!

Aircell GoGo Inflight Internet - Hackers on a plane

GoGo Inflight Internet is a Wi-Fi service provided by AirCell and offered to an increasing number of airline passengers. This service enables users to connect to the Internet while in transit for business or pleasure. While the service is a great idea, its implementation is flawed and as such its users are put at risk. This blog entry is our effort to help educate GoGo Inflight Internet users about the risks involved so that they can make an informed decision about its use.

Over the past month we've made a continued strong effort to establish communications with AirCell regarding this issue.  We have not yet received any response from AirCell other than email disposition notifications and their CTO commenting on a blog.  We want to know what AirCell is going to do to protect its users and secure its Wi-Fi Access Points.  It is important to understand that public Wi-Fi isn't easy to secure by its very nature, but it shouldn't be completley open.  Especially since many of its users are business users who connect to their business networks while in-flight  (updated on 05/27/2009).

Lets begin...

The problem with GoGo Inflight Internet is that it doesn't offer any link layer security to its users. An example of Link layer security is Wi-Fi Protected Access (WPA) which provides a mechanism for encrypting wireless transmissions so that they are not intelligible to would be attackers. WPA is offered by most ground based Hot-Spot Wi-Fi providers including Starbucks which is the most commonly used Internet Cafe/Wi-Fi Hot-Spot.

Instead of GoGo Inflight Internet protecting its users at the link layer, it openly transmits its users network traffic in much the same way that a radio station transmits music. The primary difference between the two is that the GoGo Inflight Internet Wi-Fi transmission is bidirectional and radio stations are unidirectional. That means that anyone can listen to the network data being sent by the GoGo Inflight Internet service (or any unprotected hot-spot) and they can transmit to it.

This also means that a hacker can listen in on all network conversations and record all data that is sent or received by GoGo Inflight Internet users. Because the vulnerability exists at the link layer, there's no way to establish a trustworthy SSL connection or VPN connection. This means that a hacker can capture credit card information while GoGo Inflight Internet users purchase their in-transit internet service. This credit capture is done by using a Man-in-the-Middle attack to defeat the security of the SSL or VPN connection during the initialization process. Here's one example of an SSL Man-in-the-Middle from the SANS Institute.

Unfortunately the risk doesn't end there, and it is also possible to gain access to business networks by exploiting users of the GoGo Inflight Internet service (or any other unprotected Wi-Fi Hot-Spot). Remember, the attacker can receive and send network data. This means that the attacker can inject malicious content into a users network stream, or redirect the user to a malicious location. In both cases the attacker can gain access to a GoGo Inflight Internet users computer and even infect it with a worm, trojan, etc.

Once the attacker has access to the users computer there are two possible ways to get into the users business network. The most effective way would be to install a program on the laptop that calls home when the laptop is connected to the business network (bots do this). Once the computer calls home, the attacker would be able to establish a reverse connection into the business network and its game over at that point.

The other option might not be as successful depending on what sort of VPN client the user is using. But it is sometimes possible to wait for a victim to establish a VPN connection and then for the attacker to ride in on the VPN connection. In other words, the user won't be the only person using the VPN to access his or business network, the attacker will be there too.

Its important to understand that the risks associated with using an unprotected Wi-Fi network are well documented and have been for quite some time now. That begs the questions as to why Aircell didn't implement some form of link layer security for their users. More importantly, what is Aircell going to do to protect its users? While we did make multiple efforts to establish a communication channel with Aircell, we have yet to hear back from them aside from email return receipts.

We did however read some of their comments on the Economist, so we'll address those here. Aircell's CTO Joe Cruz said "Our capabilities are not much different from what you encounter in hotel rooms, in Starbucks and in public hotspots," he tells me. "And if you're on the ground, you're actually more susceptible to spamming because hackers know where you are."

We've already addressed his first point about "hotel rooms, in Starbucks and in public hotspots" and demonstrated that they do in fact offer WPA2 to their users. His second point about being more susceptible "to spamming because hackers know where you are" is inaccurate. Firstly, spamming has nothing to do with wether or not you're on an airplane, but the threat does. The fact of the matter is that on an airplane you are likely at a higher threat level than if you were on the ground.

Here's why...

If you think about the audience on an airplane and compare that to the audience in an internet cafe or other ground based Wi-Fi Hot-Spot there are two significant differences. The first is that the airplane will likely have a higher concentration of business people than the internet cafe. The second is that the Wi-Fi users on an airplane are likely to stay connected during the duration of the flight, while in an internet cafe they are likely to be connected quickly to check email or something similar. As a result, the Wi-Fi capable airplane is a much more high value target for malicious hackers than a cyber-cafe.

Joe Cruz goes on to say ""If you’re in an airplane, you’re with a select group of people," he says. "One of the great screeners is the $365 you pay to get on the plane." He's right about the select group of people, if one of them is a malicious hacker then you're effectively held captive until the plane lands. With respect to his comment about the $365 screener, a malicious hacker would think of that as a minor investment when compared to how much money can be made by doing the hack right.

Conficker (and friends) v.s. Quality Penetration Testing

Its funny to me that people haven't commented on the fact that the ability of a worm to spread is proof positive of just how insecure today's networks are. (Yet, even with this lack of security others are talking about this kick-ass idea of "Cloud Computing"). The fact is that if people managed their networks properly (which includes testing properly with quality security service providers) that worms would not be able to spread, or at least not so quickly and on such a wide scale.

As an example, we recently performed a penetration test for one of our customers. The time between project kickoff and successful penetration was less than 15 minutes. That is to say that we were able to hack into our customers network within 15 minutes of starting the project. The way we did it was to create a .pdf based invoice and send it to the customer from a trusted source. This particular invoice wasn't really an invoice of course, it was a pdf document designed to exploit a vulnerability in their adobe acrobat reader. In this case, when our victim opened the pdf document their computer established a reverse http connection back to us. We then tunneled back in over that connection and had access to our customer's network. If we were malicious it would have been game over.

So what does this have to do with worms? If you think about it a worm uses the same methodology for penetrating into networks as hackers do. Just like hackers, worms will penetrate your network by embedding themselves in files (like our PDF example above), or by exploiting vulnerabilities in computers systems, or maybe via social engineering. Either way, the technique is the same, and as such the defense should be the same. Why isn't it?

Most people _try_ to protect their networks with anti-virus scanners and other technology. They implement these scanners on their desktops, servers, gateway's etc. They also use Intrusion Detection/Prevention Systems, firewalls and other similar solutions in an attempt to prevent infection or penetration. They never stop to question the security of the technology that they install. In 2006 Symantec's own Antivirus technology was vulnerable to attack. Back then it was possible to send someone a specially crafted email to penetrate into their computer. The fact is that technology is, and will always be fallible unless it is proved to be secure with mathematics.

I'm not saying that technology is useless because it isn't. I am saying that technology should be augmented with frequent security testing. Those tests should be delivered by a quality security provider capable of creating a threat that is at least as intense as what customers will face in the real world. Once testing is done at that "real" level the resulting deliverable will enable people to build good defenses that are based on solid recommendations.

Continuing with the pdf customer... One of the recommendations that we made to our customer was that they install a proxy to control outbound http and https traffic. We also recommended that they drop all outbound traffic that is not necessary for day-to-day business operations. We made that recommendation because of how easily we penetrated their network with PDF and the reverse http connection.

The customer implemented our recommendations and when we retested their network were unable to get anything to call home. As a result of our work worms like Conficker can not function properly on our customer's network because they can not call home. Instead, if they do get in they sit on the network isolated and useless until they are eliminated by the anti-virus technology.

Cambium Group, LLC. CAMAS Advisory

We've finally released the Cambium Group, LLC Content Management System ("CAMAS") advisory after much waiting and debate. These security risks were discovered in CAMAS during a customer penetration test that we did in August of 2007 (we notified the Cambium Group about these risks on 08/24/2007). The security vulnerabilities that are disclosed in the advisory are kept very high level and low detail as to not arm any potentially malicious people. Unfortunatley the vulnerabilities still exist today (almost two years later) according to some recent Google research that we did. In fact, according to Google's cache the Cambium Group's own website was vulnerable as of Feburary 9th 2009 to the exact same vulnerabilities that we alerted them to on 08/24/07 (see the screen shot below).

We can't ethically test Cambium Group customer's websites without their permission, hence why we rely on Google for this information. Google sometimes triggers vulnerabilities in websites while crawling them and the results get recorded to Google's database. When that happens they become searchable (and get cached). Malicious hackers and script kiddies also use Google in this way to identify websites that are vulnerable to SQL Injection. This gives them an easy set of targets that they can compromise with little effort.

You can check to see if Google stumbled upon a vulnerability in your instance of CAMAS by using the following technique. Type the following string into the Google search engine but replace www.company.com with your company's domain (see the screen shot below as an example.) String (without the quotes): "inurl:www.yourcompany.com 1064 You have an error in your SQL"

When you hit the search button (and if Google has a cached version of your website being vulnerable) you will see a link that reads something like "1064: You have an error in your SQL syntax near '' at line 1 select * from Template where TemplateID =". That error is an SQL error that demonstrates that your website is (or was) vulnerable to SQL Injection. SQL Injection Vulnerabilities are one of the more serious risks because they can be used by hackers to gain administrative levels of access to websites, web servers and their respective content.

Unfortunatley, if Google doesn't respond with something like the response shown above, you might still be vulnerable. SQL Injection vulnerabilities can also be blind in nature, meaning that they do not throw errors back to the attacker but that they can still be used to penetrate into systems (in some cases they may throw non-informational errors). *Additionally, CAMAS isn't only vulnerable to SQL Injection, but it is also vulnerable to Cross-Site Scripting, Cross-SIte Request Forgery, Local File Inclusion, Remote File Inclusion, and some Cryptographic Weaknesses (*according to testing done in 2007 and to more Google homework).

The reason why we were unable to come forward with this advisory back in 2007 is because the Cambium Group hadn't yet fixed the vulnerabilities that we discovered in our customers instance of CAMAS. We were only recently able to come forward because an ex Cambium Group consultant exposed these same vulnerabilities in a posting that he made to the Full Disclosure mailing list. As a result we felt that it would be prudent to release a formal advisory to help CAMAS users become aware of the risks and defend against them.

Our normal process for vulnerability research and advisory release is to work with the vendor in a friendly and professional manner. We've got quite a bit of expereince in doing this with vendors like Apple, HP, etc. In most cases vendors respond with questions about how to fix the vulnerabilities that we discovered. We provide them with all of the information that we can and wait for them (while working with them) to create a fix.

In most cases this process takes anywhere from 3 to 6 months, but when its done, we've done our job and the risks are eliminated. Not only does this type of work help the vendor to keep their customer's safe, but it also enables the vendor to demonstrate to their customers that they take security seriously. We attempted to follow the same practice with the Cambium Group, LLC. but no fixes were ever pushed out to their customers (based on what we saw). To the best of our knowledge, this is the first time that a CAMAS advisory has been released about the vulnerabilities that we discovered in 2007. If that is inaccurate, please leave us a comment and we'll consider updating this entry.

In addition to our advisory being published, there also exists a good article that was written by Dan Goodin at the register. Dan Goodin took the time to contact the Cambium Group to hear their side of the story before writing the article (as any good reporter does). Something to make note of before reading the article is a quote from Scott Wells where he said "All of the recommendations that Netragard gave were followed and the site was then able to pass their validation process." We're not sure why he said that, we never rechecked the customer site and we don't have a "validation process".

If you are a Cambium Group customer then there are a few things that you can do to ensure the saftey of your website and its respective users. The first recommendation that we have is to perform a Web Application Penetration Test against your website. You can do this yourself in a light weight sort of way by using a scanner like NTOspider or WebInspect (we're not affiliated with either but we'd recommend NTOspider). Having said that, we're not too fond of relying on automated tools for security so we recommend that you hire a qualified third party to test the security of your website. Make sure that they do manual testing, not just automated testing.

We also recommend that any Cambium Group customer consider installing a reverse proxy with application layer filtering capabilities. These proxies are designed to analyze web traffic being sent from web users to your website. If the data is normal web traffic then it is allowed to reach your website, but if it contains malicious data that matches known attack patterns then it is blocked and never reaches your website. This prevents attackers from being able access the vulnerable components of websites that suffer from various risks. Examples of such proxies are ModSecurity and BlueCoat (there are many others and we're not affiliated with any of them).

The other way to defend against these vulnerabilities is to impliment properly designed parameterized stored proceedures and to use strong input validation and data sanitization techniques as defined by the Open Web Application Security Project. This is true for for any Web Application, not just CAMAS. Never the less, in the case of CAMAS the Cambium Group would need to impliment these changes, you would probably not be able to because CAMAS is not an open source product.

If you have any questions about this blog entry please do not hesitate to contact us with any of your questions or concerns. You can either leave us a comment on the blog and we'll respond promptly, or you can contact us off-line and we'll keep it confidential. Your privacy and security are our top concern.

Update:  One of our readers sent us a link to The Vermont Statutes Online, Title: 9 Commerce and Trade Chapter: 62 Protection of Personal Information 2435. Notice of security breaches.  If you are a CAMAS customer then it is our understanding that you should have received notification of these risks based on the aforementioned statute. 

Netragard : Facebook from the hackers perspective.

For the past few years we've (Netragard) been using internet based Social Networking tools to hack into our customer's IT Infrastructures. This method of attack has been used by hackers since the conception of Social Networking Websites, but only recently has it caught the attention of the media. As a result of this new exposure we've decided to give people a rare glimpse into Facebook from a hackers perspective.  Credit for designing this specific attack methodology goes to Kevin Finisterre and Josh Valentine both core members of our team. 

Lets start off by talking about the internet and identity. The internet is a shapeless world where identities are not only dynamic but can't ever be verified with certainty. As a result, its easily possible to be one person one moment, then another person the next moment. This is particularly true when using internet based social networking sites like Facebook (and the rest).

Image provided by Michael Painter

Humans have a natural tendency to trust each other. If one human being can provide another human with "something sufficient" then trust is earned. That "something sufficient" can be a face to face meeting but it doesn't always need to be. Roughly 90% of the people that we've targeted and successfully exploited during our social attacks trusted us because they thought we worked for the same company as them.

The setup...

Facebook allows its users to search for other users by keyword. Many facebook users include their place of employment in their profile. Some companies even have facebook groups that only employees or contractors are allowed to become members of. So step one is to perform reconnaissance against those facebook using employees. This can be done with facebook, or with reconnaissance tools like Maltego and pipl.com.

Reconnaissance is the military term for the collection of intelligence about an enemy prior to attacking the enemy. With regards to hacking, reconnaissance can be performed against social targets (facebook, myspace, etc) and technology targets (servers, firewalls, routers, etc). Because our preferred method of attacking employees through facebook is via phishing we normally perform reconnaissance against both vectors.

When setting up for the ideal attack two things are nice to have but only one is required. The first is the discovery of some sort of Cross-site Scripting vulnerability (or something else useful) in our customers website (or one of their servers). The vulnerability is the component that is not required, but is a nice to have (we can set up our own fake server if we need to). The second component is the required component, and that is the discovery of facebook profiles for employees that work for our customer (other social networking sites work just as well).

In one of our recent engagements we performed detailed social and technical reconnaissance. The social reconnaissance enabled us to identify 1402 employees 906 of which used facebook. We didn't read all 906 profiles but we did read around 200 which gave us sufficient information to create a fake employee profile. The technical reconnaissance identified various vulnerabilities one of which was the Cross-site Scripting vulnerability that we usually hope to find. In this case the vulnerability existed in our customer's corporate website.

Cross-site scripting ("XSS") is a kind of computer security vulnerability that is most frequently discovered in websites that do not have sufficient input validation or data validation capabilities. XSS vulnerabilities allow an attacker to inject code into a website that is viewed by other users. This injection can be done sever side by saving the injected code on the server (in a forum, blog, etc) or it can be done client side by injecting the code into a specially crafted URL that can be delivered to a victim.

During our recent engagement we used a client side attack as opposed to a server side attack . We chose the client side attack because it enabled us to select only the users that we are interested in attacking. Server side attacks are not as surgical and usually affect any user who views the compromised server page.

The payload that we created was designed to render a legitimate looking https secured web page that appeared to be a component of our customer's web site. When a victim clicks on the specially crafted link the payload is executed and the fake web page is rendered. In this case our fake web page was an alert that warned users that their accounts may have been compromised and that they should verify their credentials by entering them into the form provided. When the users credentials are entered the form submitted them to http://www.netragard.com and were extracted by an automated tool that we created.

After the payload was created and tested we started the process of building an easy to trust facebook profile. Because most of the targeted employees were male between the ages of 20 and 40 we decided that it would be best to become a very attractive 28 year old female. We found a fitting photograph by searching google images and used that photograph for our fake Facebook profile. We also populated the profile with information about our experiences at work by using combined stories that we collected from real employee facebook profiles.

Upon completion we joined our customer's facebook group. Joining wasn't an issue and our request was approved in a matter of hours. Within twenty minutes of being accepted as group members, legitimate customer employees began requesting our friendship. In addition to inbound requests we made hundreds of outbound requests. Our friends list grew very quickly and included managers, executives, secretaries, interns, and even contractors.

After having collected a few hundred friends, we began chatting. Our conversations were based on work related issues that we were able to collect from legitimate employee profiles. After a period of three days of conversing and sharing links, we posted our specially crafted link to our facebook profile. The title of the link was "Omigawd have you seen this I think we got hacked!" Sure enough, people started clicking on the link and verifying their credentials.

Ironically, the first set of credentials that we got belonged to the person that hired us in the first place. We used those credentials to access the web-vpn which in turn gave us access to the network. As it turns out those credentials also allowed us to access the majority of systems on the network including the Active Directory server, the mainframe, pump control systems, the checkpoint firewall console, etc. It was game over, the Facebook hack worked yet again.

During testing we did evaluate the customer's entire infrastructure, but the results of the evaluation have been left out of this post for clarity. We also provided our customer with a solution that was unique to them to counter the Social Network threat. They've since implemented the solution and have reported on 4 other social penetration attempts since early 2008. The threat that Social Networks bring to the table affects every business and the described method of attack has an extraordinarily high success rate.

They will protect my data (won't they?)

So the other day I was talking with my buddy Kevin Finisterre.  One of the things that we were discussing was people who just don't feel that security is an important aspect of their business because their customers don't ask for it.  That always makes my brain scream "WHAT!?". Here's a direct quote from a security technology vendor "We don't perform regular penetration tests because our customers don't ask us to do that."

Isn't it the service provider's/vendor's responsibility to properly manage and maintain the security of their infrastructure?  Don't they have an ethical obligation to their customers to protect the service that they are offering and any information that the customers decide to store on their systems?

The real question is, how many customers would they lose if the customers heard them say that? That is after all just like saying "We don't care about security because our customers aren't asking us to care about it."  

So who have I heard this from? Here's the (very) short list:

• Vendors that make security software (like email gateways, anti-virus technology, Intrusion Prevention Systems, etc).
• Vendors that make technology that is used to control our Nuclear Power Plants, Water Purification Plants, Traffic Control Systems, etc.
• Vendors that sell business enabling technologies like PHP based Content Management Systems, Commercial Web Servers, Server based applications, Web Applications, etc.
• Vendors that sell desktop applications like Financial Tracking Systems, Invoicing Systems, File Sharing Systems, Backup Solutions, etc.
• I've also heard this from MAJOR Service Providers such as Web Hosting Providers, Email Providers, Backup Service Providers, etc.
• The list goes on....
  

I think that people need a wake up call.  This strikes me as a serious ethical issue, what about you? Leave me a comment I'm very interested in feedback on this one. 

A Quality Penetration Test

Someone on the pen-testing mailing list asked me to write an entry about the difference between vulnerability scanning (and services that rely on it) and Real Time Dynamic Testing™. This entry is a sanitized description of a real Advanced External Penetration Test that our team delivered to a customer. Many details were left out and our customer’s information was removed or augmented to protect their identity. Our customer did approve this entry.

Our team (Netragard, LLC.) was hired to perform an Advanced External Penetration Test as a follow-up engagement to a pen-test that was delivered by a different vendor. This might seem unusual, but we get these types of engagements more and more frequently. This test was no different than most of them, and we found significant exploitable vulnerabilities that the other vendor missed entirely, which unfortunately seems all too common.

When we deliver Advanced services we expose our customers to specific type of threat. Our goal is to create a threat that is a few levels higher than what they would likely face in the real world. Testing our customers at a threat level that is less than that would do nothing to help them defend against the actual threat. Our services are not the product of automated vulnerability scanners and scripts; they are the product of human talent.

During this particular engagement we were authorized to perform Distributed Metastasis, Covert Testing, Social Engineering, Malware Deployment, ARP Poisoning, etc. All targets were also authorized and included Web Servers that were hosted by third parties, Web Servers that were hosted locally, VPN end points, FTP servers, IDS systems, DNS servers, Secure Email Servers like tumbleweed and so on. We were not given a list of IP addresses to target, we had to identify them and request approval.

We began the engagement by performing covert social and technical reconnaissance. Reconnaissance is the military term for the collection of intelligence about an enemy prior to attacking the enemy; in this case our customer was the “enemy”. Our philosophy is that we cannot produce an accurate threat level without first understanding some details about our target’s political structure, social behavior, and technology infrastructure. We might not use all of the information that we collect while testing, but more times than not it provides us with a good idea of what will be effective, and what will not.

During reconnaissance we focused on two separate target groups. The first target group was the social structure of the client’s employees that we felt was of interest. As such we collected information about those employees that included office-location, telephone extensions, email address, relationships to other employees, friends outside of work, etc. Our secondary sets of targets for reconnaissance were technical targets. Those targets included the identification of servers used by the client, vendor identification, partner identification, the identification of IP addresses belonging to the client, the internal IP addressing scheme, operating system information, patch frequency information, etc.


We were able to use the information collected during reconnaissance to begin performing vulnerability identification through analysis. Because this service was an advanced service and required covert testing, vulnerability identification was mostly done with manual testing (Real Time Dynamic Testing™) and during reconnaissance. As testing progressed we increased our noise level until we received notification from the customer that we’d been detected. This enabled us to identify what level of testing was considered “flying below the radar” and what level was “tagged”. (Knowing this enables us to help our customers retune their IDS technologies so that they are more difficult to evade. In most cases IDS technologies are not tuned properly, and yes this includes IPS and Correlation Systems too.)

Once we were finished with vulnerability identification we built a target matrix that was organized by probability of penetration. This matrix is used as a guide for the team and enables us to test the most probable points of entry first, and the least probable points of entry last. In the case of this particular customer we identified three probable points of entry along with a few other basic vulnerabilities like Cross-site Scripting, etc. (While Cross-site Scripting is useful for performing Social Engineering based attacks, we won’t go into the details about how we used them here.) The other vendor even with basic scanning services should have detected most, if not all of these vulnerabilities, but they didn’t.

The first point of attack that we focused on was the customer’s corporate website. This website was being hosted by a third party and was using a Content Management System (“CMS”) that was created by vendor that we’ll call the Noname Group. This particular CMS was written entirely in PHP, was closed source and had no security functionality to speak of. There were multiple points were unchecked variables were passed directly to SQL statements or other critical internal application components. We were able to use those unchecked variables to penetrate into our Customer’s Web Server and take control of it.

Upon accessing that web server we found customer data that was stored in the database in clear text. This information contained names, addresses, account numbers, social security numbers, etc. In some cases the information was from users requesting information, in other cases it was users looking to sign up. As a proof of concept we wrote a ruby script that would automatically dump the contents of the database when executed. That script was submitted to the customer. Because this server was not hosted within our Customer’s IT Infrastructure it did not provide us with a platform from which we could perform Distributed Metastasis.

The next target lined up for testing was another Web Application, this time it was hosted from within our customer’s infrastructure. Again, the application suffered from a basic SQL Injection vulnerability that could be triggered by a back-tick. We used the vulnerability to fingerprint the application’s backend database and learned that it was a MS-SQL database. We also learned that was hosted on a separate server from the Web Server. We then tested for “xp_cmdshell” access and found that the “sa” user had no password set and as a result we could execute arbitrary commands against the database server with administrator privileges.

Once we gained control over the database server we began to examine other systems within proximity to our new point of control (Distributed Metastasis). That was when we learned that we’d compromised a key server that was deep within the customers IT Infrastructure and had clear access to other critical systems. We also noticed that the server that we were controlling contained multiple databases that contained a wide variety of highly sensitive information including customer banking information, social security numbers, etc. In addition, while performing network probes we identified a secondary database server. Ironically this second database server was running on the web server with the SQL Injection vulnerability that we’d just attacked.

When we tried to connect to the second database server from the internal server we were unable to access it because this time the “sa” password was set and we didn’t know what it was set to. We did however know which system accessed that database server as a result of the Social Engineering efforts that were mixed into our Social Reconnaissance. The system with access was also the third system in our targeting matrix and contained another vulnerable Web Application. This time, due to the configuration of the application SQL Injection capabilities were limited. We did however manage to find an arbitrary file read vulnerability and were able to use it to read the application’s configuration file that contained the “sa” password.

This enabled us to go back to the previously inaccessible database and access it using the sa password. This also gave us access to the xp_cmdshell function that in turn allowed us to execute arbitrary commands against the system. At this point in the test we’d managed to penetrate into both the DMZ and the corporate LAN which also allowed us to connect to any other system within proximity without issue. In other words, there was no internal segmentation in the form of VLAN’s or physical isolation. The networks were flat.

The server that we penetrated in the LAN contained a SAM file. We were able to crack 90% of the passwords in that SAM file with rainbow tables, including the Administrator password. Once we had that password we were able to use RDP to access the Active Directory server and it was technically game over. If we had not discovered the SAM we were prepared to perform ARP Poisoning to collect data and possibly in-transit credentials. Our penetration of the AD server concluded the penetration test.

It is important to note that this is not a complete description of all of the testing that we did for the customer. As with any engagement we produce a deliverable that outlines all discovered points of risk with their respective methods for remediation. In this particular case our report identified 47 risks and provided 47 methods for remediation. Remember that this customer just completed a penetration test from a different vendor, how is it that they missed 47 risks? Their services certainly did not protect our customer from hackers.

Network Vulnerability Scanning Doesn't Protect You

Vulnerability scanning can have a detrimental negative impact on the security posture of your IT infrastructure if used improperly. This negative impact is due to a perceptional issue that has been driven by the vendors who sell vulnerability scanning services or the vulnerability scanners themselves. The hard facts prove that vulnerability scanners can not protect your IT Infrastructure from malicious hackers. (My team penetrates "scanned" networks on a regular basis during customer engagements). That is not to say that vulnerability scanners are useless, but it is to say that people need to readjust their perception of what vulnerability scanning really is.

While there are various types of vulnerability scanners they suffer from the same disease that most security technologies suffer from. That disease is that they are reactive to hackers and will never be proactive. The fact is that vulnerability scanners can not detect vulnerabilities unless someone has first identified the vulnerability and created a signature for its detection. This process can take quite a while and is often not an ethical one. So here is how it works...

A hacker decides to perform research against a common technology like your firewall. That hacker might spend minutes, months or even years doing research just for the purpose of identifying an exploitable security vulnerability. Once that vulnerability is identified the hacker has an ethics based decision to make. Does he notify the vendor of his discovery and release a formal advisory or does he use his discovery to hack networks, steal information and profit.

If the hacker decides to notify the vendor and release an advisory then there is usually a wait period of 1-3 months before the vendor releases a patch. This lag time means that the vendor's customers will remain vulnerable for at least another 1-3 months, most probably longer. What's even more interesting is that this vulnerability may have been discovered previously by a different researcher that didn't notify the vendor. If that's the case then that probably means that the vulnerability has been in use as a tool to break into networks for a while. Who knows, it could have been discovered months or even years ago? That type of unpublished vulnerability is known as a 0day and is the favorite weapon of the malicious hacker.

At some point the vulnerability does become public knowledge. Its also at this point that the vendors who make the vulnerability scanning technology become aware of the new risk. When they do learn about the new risk they need to develop a signature, or script for their scanning technology so that it can detect the risk. That development process can take anywhere from a few days to a few weeks depending on the complexity risk. As a result, the customers that rely on vulnerability scanning are in the dark until the vendor can publish a working and tested signature... but the hackers don't need to wait at all. The hackers can use it almost immediately.

So in summary, there is a large risk window between the point of discovery of a vulnerability and the point at which a vulnerability scanner can detect the vulnerability. This risk and exposure window is usually never smaller than a few months, and can be as large as several years. During that time there is a very good chance that malicious hackers will be using your undiscovered risks to penetrate into your infrastructures. Whats worse is that you'll have no idea that you've been hacked because like vulnerability scanning technology, Intrusion Detection technology also can't identify threats if it doesn't know what to look for. Moreover most Intrusion Detection technologies aren't configured properly and as such don't work properly.

Unfortunately the story doesn't end there. Vulnerability scanners also suffer from significant issues with accuracy. In all cases where I've used (various) vulnerability scanners, the best results that I've ever achieved were about 30% accurate. This means that most of the vulnerabilities that were detected during my various scans weren't actually vulnerabilities but instead were false alarms, also called false positives. More frightening is the number of vulnerabilities that I discovered while performing Real Time Dynamic Testing (manual hacking) that were entirely missed by the vulnerability scanner. If you don't believe me then go download a free vulnerability scanner, test your network and verify the results yourself.

This inaccuracy is partially due to the architecture of the vulnerability scanners and the fact that no two networks are alike. Vulnerability scanners use static signatures or scripts that are only capable of checking a target for a vulnerability if their syntax is exactly accurate and if the target responds in a way that the scanner can understand. If however the target, lets say its a computer system, is configured in a custom way then it may not respond in a way that the scanner will understand (how many of you keep the default configuration?). This communication barrier is a large part of what causes false positives and false negatives.

An important note about false positives and false negatives. Some vendors claim that their vulnerability scanners have low rates of false positives. As with Intrusion Detection, if low false positive rates are true then its usually reasonable to say that the technology has high rates of false negatives. You can think of it as a sliding scale of 1 to 10 where 1 is 100% False Positives and 10 is 100% False Negatives. As you move up and down the scale you inevitably end up with more of one or the other, you can never eliminate them. With that said, its my opinion that more false positives are better than more false negatives.

If vulnerability scanners aren't the right way to protect yourself then what is? You should protect yourself by exposing your business to an accurate and controlled reproduction of the threat by using a quality security provider. It is important to remember that no single hacker, good or bad, has access to all of the 0-day's in the world. As such, it is entirely possible for a team of ethical hackers to accurately reproduce the threat that unethical hackers can create. Testing at that level enables you to identify weaknesses in your defenses that would not otherwise be detected by testing at lesser levels. What good would a penetration test or a vulnerability assessment do if the malicious hackers will test you harder?

One of the many advantages of using a team of talented hackers for security testing instead of relying on automated vulnerability scanners is that those hackers can and should perform research against unique technologies that they encounter during a security test. I practice what I preach by the way. When our team delivers an Advanced Penetration Test to a customer we always perform our own research against interesting targets. Those targets can be Web Applications, Web Services, or even custom daemons running on systems. In the end, if we find something new we'll write an exploit (proof of concept) for the customer and include that in the final deliverable.

In closing, I am not suggesting that network vulnerability scanners are bad because they do have their place and they do serve a purpose. They are particularly useful in the hands of a skilled security expert especially when performing reconnaissance against large networks. In that scenario the scanner enables the expert to save time and to rapidly collect intelligence about targets given that the engagement is non-stealth in nature. With that said, I wouldn't rely on scanners for anything more than just reconnaissance, at least not yet.



Note: (Thank you to minoo for pointing out a few mistakes in my previous revision of this entry. I hope that this entry is as clear as I intend it to be. There is no one team that is the best, but there are only a few good ones. If this isn't clear enough or if it needs more revision please comment.)

Finding The Quality Security Vendor (Penetration Testing, Vulnerability Assessments, Web Application Security, etc)

While I've written several detailed white-papers on the subject of identifying quality security vendors, I still feel compelled to write more about the subject. It is my opinion that choosing the right security vendor is critical to the health and safety of a business.  Choosing the wrong vendor can leave you with a false sense of security that in the end might result in significant damages. Often times those damages can't be fully measured and appreciated, especially when they involve the tarnishing of a good name.

This problem of identifying quality isn't new but it does take on a new importance when it involves the safety of your trade secrets, source code, or otherwise critically sensitive information.  When you trust a security provider to test your IT Infrastructure, your people, physical security, etc. you are relying on them to identify risks that malicious hackers might otherwise discover.  If the provider does not test you at the same threat level as the malicious hackers then their service is almost useless. 

If that doesn't compel you to want quality security services then go ahead and take the risk.  I suppose the question really is, how much is your network (and its data) worth? If its worth more than $500,000.00 then its probably worth spending money on a quality security vendor to protect it right?

So how do you know which providers are quality and which ones are frauds?

The first rule of thumb is to watch out for the vendors that produce deliverables that are the product of vulnerability scanners.  There are two reasons for this, the first being that you don't need to pay anyone to run an automated scan when you can do it yourself for much less, or for free. You can choose from a variety of free tools like nessus, or you go out and buy a license for a vulnerability scanner.  

Don't be fooled though, vulnerability scanners do not produce accurate results. In fact most vulnerability scanners produce results that contain anywhere from 40-90% false positives with an unknown rate of false negatives.  While these tools are useful for reconnaissance they should not be used as the primary method for security testing. 

Watch out for the vendor that tells you that they will run a vulnerability scan against your network and then "vet" the results.  Vetting doesn't mean that they are going to do additional discovery. Vetting only means that the vendor will check the results of the vulnerability scan and eliminate the false positives. The quality of the end product is then only as good as the accuracy of the vulnerability scanner. Would you bank on that?

When you are choosing the vendor make sure to ask them specific questions.  Questions that I find helpful are realistic but based on theoretical architectures.  For example you could ask a vendor the following question:

"Suppose you are confronted with an architecture that consisted of 10 desktops behind a single firewall.  That firewall has properly configured IPS capabilities and there are no ports forwarded from the internet to any system behind that firewall. How would you [the vendor] penetrate into that network? Once you penetrate how would you perform Distributed Metastasis?" Email me for the answer if you don't know it already. 

You can also ask the vendor how they would use a directory traversal vulnerability to penetrate into a network.  This is a bit of a trick question but if they know what they are doing then they will be able to answer it properly.  The short answer is that you need to inject code into the web-server's error log and then use the directory traversal vulnerability to render the code. (Again, if you need the complete answer email me and I'll get it to you.)

 

Another good rule is to only choose security vendors who also perform Vulnerability Research and Development ("R&D").  That is to say that the vendor must frequently perform security research against technology, identify vulnerabilities in that technology, create exploits for those vulnerabilities and must release formal security advisories. If they don't then chances are they don't know how to do it, but why is R&D important? 

R&D enables the vendor to keep its penetration testing skills honed (so long as the research done by the penetration testers).  Penetration Testers who do not perform this kind of research are literally Script Kids (sorry guys).  Script Kids are people who download tools and use those tools to penetrate into networks. In almost all cases they don't have any understanding of how the tools work.  If you think about it, thats like giving a loaded gun to a 3 year old. 

You can also ask the vendor how they collect their threat intelligence.  Threat intelligence is a critical aspect of delivering quality security services.  If the vendor doesn't have current threat intelligence about the threat then how will they help you to defend yourself against the threat? While I won't tell you how my team collects this intel, I will tell you that its not from the news and most certainly not all public forum. 

In closing, my recommendation to you is that you do your homework before you choose a vendor. Research the components required for delivering a quality service, then use your research to question the provider.  As an example, if you were going to get a Web Application Penetration Test ask the vendor to define the term "Penetration Test".  Ask the vendor what the difference is between a Penetration Test and a Vulnerability Assessment.  Also ask them to explain RFI, LFI, XSS, SQL Injection, Blind SQL Injection, etc.  Remember, you are going to spend money on security, might as well make it worth while.  If you don't then you're just adding that money to the damages from the hack that you'll suffer in the end. 

If you have any questions please feel free to leave me a comment or send me an email.  You might also want to check out the white papers that I've linked at the upper right hand corner of this blog.  Those papers go into more detail about how to choose a good security vendor and how to select the right service. 

Followup to my last Brian Chess - Fortify Software post.

Recently I published a post about Fortify Software's Brian Chess because of some outlandish claims that he made in an article about penetration testing being "Dead by 2009". The off-line and 0n-line comments that resulted from that post were mostly in favor of what I'd written and one of those comments really caught my eye. So here is a post dedicated to Rafal in response to his comment on my article about Brian Chess.

Comment By Rafal shown below, verbatim in pink:


"If I may call a sanity timeout here folks - while I don't agree with Brian's assertions necessarily - if you combine a few factors you could conceivably come to the conclusion that penetration testing will start to dwindle (just not as quickly as 2009)."

Its only conceivable for those who do not know what Penetration Testing is, and many self-proclaimed security guru's don't. So lets start with some (partial) definitions here:

Vulnerability Assessment:
(Assessment: the act of assessing; appraisal; evaluation.)
A Vulnerability Assessment is a service that evaluates a particular target, or set of targets for the purpose of identifying points of exposure that are open to assault. A Vulnerability Assessment does not attempt to compromise or penetrate into a target once a point of exposure is identified, it only aims at assessing the target for points of risk. Vulnerability Assessments by their very nature are prone to False Positives and False Negatives as the findings are never validated via Penetration or Exploitation.

Vulnerability Assessment Tools include:

• WebInspect for Web Application Vulnerability Assessments
  
• Nessus for Network Vulnerability Scanning
• Fortify for Web Application Vulnerability Assessments
• Retina Network Vulnerability Scanning
• etc... you get the idea.
  

Penetration Test:
(Penetration: the act or power of penetrating.)
A Penetration Test is a service that evaluates a particular target, or a set of targets for the purpose of identifying points of exposure that are open to assault. A Penetration Test differs from a Vulnerability Assessment in that it attempts to penetrate into the target by exploiting any discovered points of risk and exposure. A Penetration Test when done properly will result in an accurate deliverable that contains no false positives. This is possible because exploitation of a risk or point of exposure is either successful or not. Penetration Tests can include theoretical findings but they should not be reported on as positives.

Penetration Testing Tools include (I'd recommend these):

• The Metasploit Framework
  
• CANVAS
  
• Core Impact
  
• etc...
  

You can use a Vulnerability Assessment or a Penetration Test against any type of target not just technology based targets. At Netragard we perform physical penetration tests, wireless penetration tests, network penetration tests, social engineering based penetration tests, web application penetration tests, etc. Likewise we can deliver vulnerability assessments against the same set of targets if penetration testing is too aggressive.

(I get the feeling that both Rafal and Brian Chess think that Penetration Testing is a Web Application only service)

"Here's my logic - feel free to scrutinize. For the record I work for HP (the SPIDynamics acquisition) so you guys can feel free to rip on the fact that our marketing folks I'm sure make interesting claims as well... but I digress. Here are some things to consider:

Actually we've got quite a bit of interesting history with HP, but that's a different story. With respect to SPIDynamics and the Web Inspect tool, I'm sorry that HP ever acquired SPIDynamics. WebInspect was a reasonable tool for doing preliminary reconnaissance against Web Applications during non-covert services. Once HP acquired the technology its quality went down the tubes. Not only that but the process of acquiring a license from HP is excruciatingly painful at best. What ever happened to being able to purchase the product online? /end rant

"1. When you do penetration testing, what are you really testing? Are you testing the system or the intelligence and skill of the pen tester? This is a very tough question to answer."

Why is that a difficult question to answer? If you've built your penetration testing team properly then your team will be able to expose its targets to the same or greater threat level than that which they will likely face in the real world. The fact of the matter is the more secure the infrastructure the more challenging the test and yes, its impossible to know everything but its not impossible to do a great job.

"2. Pursuant to #1 above, and the business' (living in reality land here) need to do lowest-cost vendors... what value do you suppose that the 90%+ of companies that go lowest-cost (outsourced to India, China, Mexico, etc) are getting?"

Businesses do not "need to do the low-cost vendors", they choose to because they are making uneducated decisions in most cases. Mind you the lack of education on their part is not their fault, its the fault of the poor quality vendors. Poor quality vendors advertise their services as if they are the same quality as the high quality vendors thereby causing confusion. When a business compares the two services they don't see the difference and so they choose the less expensive one.

"3. With every point-and-click testing tool there is a double-edged sword... here's why 3a. Tools make you more efficient BUT"

I only partially agree. When the tool spits out over 2,000 false positives (like WebInspect did the last time we used it) with only 3 real positives its doing very little to increase the efficiency of a team. Other tools that produce less false positives and more accurate results are very useful for time savings but their results should not be used to create an end product. Automated tools are not dynamic by nature and as such can not identify the same risks as talented penetration testers.

"3b. Tools can make you less "hands-on" when it comes to writing low-level exploits or code..."

Tools are also the root cause of the the fraudulent security experts. I'm not saying that tools don't have their place because they certainly do. But they allow people to become lazy and as such breed "experts" that are for all intents and purposes no better than script kids (which might I add are very dangerous because they don't know what they are doing).

"4. Penetration testing is an after-the-fact requirement... which is too late. You have to use tools to augment and empower your developers to write better code at the grass-roots otherwise you're hosed."

You're partially wrong. The tools that you speak of are derived from the attacks that were created by Penetration Testers (aka: hackers). With respect to the world of Web Applications, do you think that a tool discovered the first SQL Injection vulnerabilitiy and created a method for exploitation? Ofcourse not! Tools will always be a few steps behind the capabilities of a real hacker, regardless of that hackers ethical bias. The fact of the matter is that as hackers, we perform research and identify new methods for penetration that were not previously discovered and your tools can not and will not ever be able to defend against that.

"So - to summarize, penetration testing isn't going to be "dead" in this year of 2009, but it may start to dwindle down some depending on how good the marketing machines of the tools vendors are. Brian's statement is a self-fulfilling prophecy... he is making a statement that he hopes will incite people to make that statement come true."

I disagree, and again, you are working for a vendor that makes these tools. Its in your best interest to suggest that some how Penetration Testing will be less of a requirement because of the tools that you create. The reality of it is that if people drink that kool aid they will become more vulnerable, not more secure.

When our military tests the armor of its M1A2 Abrams Tank they test it against the real threat. So why aren't we pushing our customers to do the same thing, it makes perfect sense? In our case the real threat is always going to be the malicious hacker, not the software vendor making pretty and easy to use tools. The tools do have a place but they will only ever identify the low hanging fruit. It takes a professional hacker/penetration tester to actually test an infrastructure properly. Lets see your tools perform Social Engineering or drop USB sticks in parking-lots.

ROI of good security.

The cost of good security is a fraction of the cost of damages that usually result from a single successful compromise. When you choose the inexpensive security vendor, you are getting what you pay for. If you are looking for a check in the box instead of good security services, then maybe you should re-evaluate your thinking because you might be creating a negative Return on Investment.

Usually a check in the box means that you comply with some sort of regulation, but that doesn't mean that you are actually secure. As a matter of fact, almost all networks that contain credit card information and are successfully hacked are PCI compliant (a real example). That goes to show that compliance doesn't protect you from hackers, it only protects you from auditors and the fines that they can impose. Whats more is that those fines are only a small fraction of the cost of the damages that can be caused by a single successful hack.

When a computer system is hacked, the hacker doesn't stop at one computer. Standard hacker practice is to perform Distributed Metastasis and propagate the penetration throughout the rest of the network. This means that within a matter of minutes the hacker will likely have control over the most or all of the critical aspects of your IT infrastructure and will also have access to your sensitive data. At that point you've lost the battle... but you were compliant, you paid for the scan and now you've got a negative Return on that Investment ("ROI").

So what are the damages? Its actually impossible to determine the exact cost in damages that result from a single successful hack because its impossible to be certain of the full extent of the compromise. Never the less, here are some of the areas to consider when attempting to calculate damages:

• Man hours to identify every compromised device
• Man hours to reinstall and configure every device
• Man hours required to check source code for malicious alterations
• Man hours to monitor network traffic for hits of malicious traffic or access
• Man hours to educate customers
• Penalties and fines.
  
• The cost of downtime
• The cost of lost customers
• The cost of a damaged reputation
  
• etc.

(The damages could *easily* cost well over half a million dollars on a network of only ~50 or so computers. )

Now lets consider the Return on Investment of *good* security. An Advanced Penetration Test against a small IT Infrastructure (~50 computers in total) might cost something around $16,000.00-$25,000 for an 80 hour project. If that service is delivered by a quality vendor then it will enable you to identify and eliminate your risks before they are exploited by a malicious hacker. The ROI of the quality service would be equal to the cost in damages of a single successful compromise minus the cost of the services. Not to mention you'd be complaint too...

(Note: the actual cost of services varies quite a bit depending on what needs to be done, etc.)

So why is it that some vendors will do this work for $500.00 or $2,000.00, etc? Its simple, they are not delivering the same quality service as the quality vendor. When you pay $500.00 for a vulnerability scan you are paying for something that you could do yourself for free (go download nessus). Never the less, when you pay $500.00 you are really only paying for about 5 minutes of manual labor, the rest of the work is automated and done by the tools. (If you broke that down to an hourly rate you'd be paying something like $6000.00 an hour since you're paying $500.00 per 5 minutes). In the end you might end up with a check in your compliance box but you'll still just as vulnerable as you were in the beginning.