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. 

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.