Facebook From A Hacker's Perspective
14 Mar 2009
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.
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).
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 the group that 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 "Omitted 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.
Adriel T. Desautels
ad_lists@netragard.com
(Please leave comments.)
◊