Social Media Strategy and Implementation

SocmedStrategy

I will be speaking at MITRE’s Social Media Strategy and Implementation Workshop in the Washington, DC area on September 28th. My topic is Attacking Social Networks. The goal of the talk is to show some of the darker aspects of social networking. These will be items and attack vectors that people may not be thinking about. Believe it or not some people are still oblivious to common social network attacks ;) If you are in the DC area stop on by.

MonkeyFist Fu: The Intro

MonkeyFist Image

MonkeyFist is a dynamic request attack tool. It allows you to do some interesting things with various forms of cross-site requests and play them back to the user’s browser. These requests may contain session information bypassing Cross-Site Request Forgery protection mechanisms. It’s really a lot more simple than it seems.

MonkeyFist is basically a small web server that performs some attacks on the data it receives based on information you provide in the payloads.xml file. To do a deeper dive in to the issues that MonkeyFist exploits you can refer to the white paper we wrote prior to Black Hat on Dynamic CSRF located on the docs page of Hexsec http://hexsec.com/docs

The best way to get familiar with MonkeyFist is just to dive right in. If you haven’t done so, you can go here to download it from the Hexsec Labs page http://hexsec.com/labs

MonkeyFist requires you be intimately familiar with the request you want to forge. This should be painfully obvious because you need to tell the tool how to construct the request in order for it to be successful.

The Files

There isn’t much to MonkeyFist, all of the files are pretty small. There are a few items in the zip file, but you really only need to worry about MonkeyFist.py and payloads.xml. All of the configuration for payloads in MonkeyFist is done through payloads.xml. We will get in to syntax in another post. In case you didn’t notice the .py extension, MonkeyFist is written in Python. So if your operating system doesn’t have Python installed (Probably just Windows systems) you are going to need it. I suggest version 2.5 or greater. The version that comes with most Linux distributions and OSX is fine. As a final note about the files, ensure that you run MonkeyFist from the same directory as the other files that come with it. Otherwise, it won’t know where they are located ;)

Dependencies

In the beginning there were no further dependencies but I a saw it was necessary to potentially need to do some more complex parsing for the fixation payload. For that reason I decided to add lxml. I could have gotten away with a more simple parser, but was trying to think ahead a bit. To use the Fixation payload you are going to need to install a 2.x version of lxml. This would be different depending on your operating system. If you are using Ubuntu / Debian don’t just to to apt install lxml, it will give you an old version. Python setuptools helps a lot, it’s just a good idea to use that anyway.

For OSX Leopard (Make sure you have the development tools installed) I just ran:

sudo easy_install lxml

For Ubuntu you have to take a few other steps because you need a few dependencies and the development headers for Python.

If you don’t have setuptools installed:

sudo apt-get install python-setuptools

Then you need to apt-get install the following if you do not have them installed:
libxml2-dev
libxslt1-dev
python2.5-dev

After that you can go ahead and:

sudo easy_install lxml

If you have build problems you probably don’t have the build tools installed:

sudo apt-get install build-essential

Then run easy_install again.

If you decide not to run lxml or do not have the ability to install it, the tool will still run you just won’t be able to use the Fixation handler without a nice failure and error message :)

Payload Types

There are several types of payloads you can construct with MonkeyFist. Each of these would depend on what the goal of the attack would be or the type of content on a site you would have control over. The basic payload types are dynamic redirect, POST construct, dynamic page, and fixation.

Dynamic Redirect

The dynamic redirect payload simply parses any cross-domain information looking for session data to dynamically construct in to a GET based payload to send back to the user’s browser. Basically, the user would request something and the tool would respond with a 302 redirect to a location. The location value would be the constructed payload. The user’s browser would just request content like normal and follow the redirect and execute the payload.

This payload type is best used in instances where you have the ability to add images tags or other HTML to a site. This way it could be relatively hidden from a user’s browser.

Dynamic Page

This payload constructs a page that performs several functions depending on what type of attack you are performing. You can either have the page perform a GET or a POST for an attack. Both the GET and POST types will be submitted by the user’s browser. So what does the page do? The attack that you construct gets embedded in the page and after the attack happens the user is immediately redirected to a location of your choice. So you could perform an attack and immediately send someone to the Benny Lava video ;) This could be combined with an URL shortener for further obfuscation.

This payload is best used in instances where you have the ability to embed hyperlinks to pages. Another thing to note about the dynamic page payload is that it makes POST based CSRF a whole lot easier to pull off. If you thought submitted data as a POST was a protection mechanism for CSRF you might want to rethink you point of view ;)

POST Construct

This payload is a bit different because the POST request is made by the tool and not the user’s browser. This needs to be kept in mind when using it. You will not have the advantage of the browser being helpful and submitting header information. If the cross-domain leakage is enough that you can perform an entire POST request without the user’s browser then this payload can be used. Otherwise, it will be pretty useless to you :)

Fixation

The fixation payload allows you to make a request for data that you fixate on to the attack you send to the user. This is still experimental and only works in some narrow situations. This will be expanded later. This works as a modified page payload that performs and extra request and parses the response and gains the necessary information to perform the attack. This would be commonly used to make a request for tokens that you can fixate on to a request forged by the user’s browser.

Default Payload

The default payload gets matched when there is no cross-domain information for the tool to match with your entries in the payloads.xml file. It’s best to not perform an attack with this ;) The best thing to do is to make this a link to some real content like an image. This can make the tool a bit more stealthy.

You need to specify a default payload. Not doing so would be like crossing the streams. Well maybe not that bad, but it wouldn’t be good.

MonkeyFist Running Options

There are only a couple of running options with MF and well, all of them do not work as of yet. So, the main one you need to be familiar with is -s. This is the standard attack mode. The -p option specifies the port you would like MF to run on. You won’t need privileged access unless you are trying to run on a low order port. The following would run MonkeyFist on port 8080 using standard attack mode:

./MonkeyFist -p 8080 -s

You can get the about information by running -a, just in case you were curious about what version you are running.

./MonkeyFist -a

Of course, if you need some reference there is always the ole’ help with -h

./MonkeyFist -h

There are a couple of other options that are planned for the future. A testing mode and a random mode will be added as well, but currently, they are not implemented.

Payloads

The payloads.xml file is where you define your attacks. This is where all of your work will be done. The exact options that are specified in this file are still being worked out. This is because as content goes, there needs to be flexibility when identifying these issues. There is a basic set of options that allow you to pull of some attacks even as MonkeyFist sits at version 0.4. Expect some changes in these options. The payloads.xml file will be covered in more detail in a future post.

The Others

You will notice a few other files in the MonkeyFist zip file. You might not want to delete them or you may have some unintended consequences. The page2.html file is blank, but it won’t be if you pull off any Page attacks. Contents are put in to this file dynamically and change per attack. Markup.py is something I didn’t write, it just allowed me to quickly generate some HTML. This was before I made the decision to use lxml. For now I am going to leave it in there, even though it is not the best option. FistLib.py is the most important. This is the workhorse that takes care of all the work.

In Closing

I think that’s it for a small intro on MonkeyFist. In future posts I will explain more about the payloads and how they are constructed. If you notice any problems while running MF please let me know. You can send an email to monkeyfist {at} hexsec {dot} com. This is still a work in progress so please don’t beat me up too bad. I do welcome your feedback though. Thanks.

Dynamic Cross-Site Request Forgery (CSRF)

Bypassing CSRF Protections With Dynamic CSRF

At our presentation at Black Hat and Defcon this year, Shawn Moyer and I gave a talk called Weaponizing the Web: More Attacks on User Generated Content. During the talk we discussed something we are calling Dynamic Cross-Site Request Forgery (CSRF). Dynamic CSRF methods can be used to create new attack vectors and compromise CSRF protection mechanisms. CSRF is often difficult to explain in the first place, so I just wanted to do a post about it and link our Dynamic CSRF White Paper.

Static CSRF Attacks

The current way people are exploiting CSRF issues is pretty static. A link may be crafted and people are tricked in to clicking on it or viewing a page with this link embedded. They may even do something such as create an auto-submitting POST that the user executes when visiting certain content. The moral is that someone crafts this attack for a specific location and chooses a vector for delivering it to users. On it’s own, this static CSRF attack method can be pretty devastating or perhaps totally innocuous. That’s just the nature of CSRF. There aren’t too many vulnerabilities that fall in to this category, which may be why it can sometimes be hard to understand.

Let’s just think about some things that would make CSRF even more dangerous. What if we had visibility in to CSRF tokens or even session identifiers? What if we knew for sure a user was on the site that we wanted to attack? What if we could use a central point to dynamically attack multiple sites? What if we could create a custom payload on the fly to include tokens and session data? What if we could request data in another process and fixate it on to a request that the user executes? CSRF would become much more dangerous. Well, it just did….

Dynamic CSRF Attacks

With Dynamic CSRF attacks the game changes a bit. Attacks can be adapted based on where requests are originating from. Sensitive information sent in a cross-domain fashion can be packaged in to a customized payload and sent to a location. Disjoined or bolted on components can be queried and fixated on to a user’s request. This opens up new opportunities for attacks. Dynamic CSRF allows you to run one central system and run attacks for multiple sites and applications with the ability to remove and repackage any leaked session information.

Dynamic CSRF

Using dynamic methods may allow for the bypass of CSRF protections. Whether these protections are leaked in the referer or if they can be requested by other means and fixated on to the request, bypassing may be possible. This makes requests that were previously not vulnerable to CSRF vulnerable again.

When not limited by static requests a few new attack vectors open up. I just wanted to highlight a couple here.

Getting Dynamic

In the next couple of sections I am going to point out some dynamic methods for bypassing CSRF protection mechanisms.

HTTP Redirect

A simple redirect attack can be made more devastating with the addition of session related data added to the request. So a user hits a piece of HTML on a web page that sends a GET request containing session data (Session IDs, CSRF Tokens, etc) in the referer. This session data can be taken from the referer and repackaged in to a payload that is sent to the users browser as a location for a 302 redirect.

HTTP Redirect

A scenario for this type of attack might be embedding a hidden image tag that links to a location offsite. This image tag may leak session data through referer allowing a tool to repackage that session data and get the user’s browser to execute it as a payload. This could be used to bypass CSRF protections by using the CSRF tokens from the referer.

HTML-based Redirect

For this scenario a hyperlink could point to a page that is created dynamically per-each request. This page contains a hidden GET or POST that could contain session data taken from referer as mentioned previously in the HTTP Redirect. The page would then refresh to a legitimate destination. To a user there would only appear to be a short pause prior to their landing on the legitimate destination, but in the background an attack has happened.

This attack could be made more interesting with URL shortening services. People have become accustomed to URL shorteners due to their use of Twitter and other social networks. Using a URL shortener would mask the location of the dynamic page and may not raise further suspicion.

HTML-based Redirect

A scenario for this would be posting a link that is shortened with a URL shortener on a web site that supposedly links to a video on YouTube. When the user clicks the link a hidden action (GET or POST) is executed. After the hidden action takes place, the browser does a refresh to the expected destination (the YouTube video). The victim may get little or no indication that the hidden attack has happened.

Fixation Based Attacks

Here is where things get a bit interesting. This attack hinges on the ability to have a valid CSRF token and a valid session identifier, but those two values aren’t associated together from a session perspective. Say you are posting on a message board. This message board issues you a Session ID in a cookie and also issues you a token for use when posting. If these two values aren’t linked from a session perspective, it would allow for any valid token to be added to the request. Since the Session ID is in the cookie value, if a forged request had a valid token appended this would bypass CSRF protections.

Fixation Attack

What makes this fixation attack an interesting scenario is it requires no leaking of any session data in a cross domain fashion. As long as you have some visibility to the token, it can be requested and fixated to the request.

Other Scenarios

There are other scenarios as well. It really depends on how much session data gets leaked in a cross-domain fashion. For example, if the full session ID is leaked, there could be some real problems. It could allow for a tool to construct any GET or any POST to the target application.

MonkeyFist

MonkeyFist is a tool I wrote to PoC Dynamic CSRF attacks. The tool runs as a small service on a system listening for all incoming input. When it receives a request it looks in the referer to determine where the request is coming from. It then uses this information to parse a payloads file and look for the specific attack to construct for that domain. You can have multiple entries in the payloads file performing multiple types of attacks. Redirect, POST, Page (GET and POST) and an Experimental Fixation handler are all included in the application. You can learn more about MonkeyFist on the the Hexsec Labs page. It is not exactly where I would like it to be, but it works. More streamlining and modifications will come soon. I am still recovering from Black Hat and Defcon :)

I have some posts on MonkeyFist that are coming soon as well.

More Info

That’s it for a quick intro to Dynamic CSRF. If you would like more information you can read our white paper which is available here.

Social Networks and Black Magic

Social networks are shrouded in mystery. Just their very existence defies the laws of physics. If it were the late 40′s men in strange suits would be trying to dissect them at some top secret facility, but we have come so far since then :) Even though this sounds ridiculous, this is what many would have you believe about social networks. Why you ask? Because many of the people that talk about attacks and the dangers of social networks don’t even use them. They make all kinds of assumptions about soc nets that are completely false. The funny thing about assumptions when you are theorizing attacks is if your assumptions are faulty then your conclusions are faulty. Let’s cut the crap and focus on the real threats to social networks and their users.

Bruce Schneier just had a post in his blog about Social Networking Identity Theft Scams. In this blog post he refers to an article on ITworld titled Why you can’t trust ‘friends’ on Facebook as clever. This isn’t clever, this is dumb and extremely improbable. This is a perfect example of people talking about social networks that have no idea how they are used. The explanation of the scenario shows a clear lack of understanding of how social network users view and interact with their network.

I will not go in to all the specifics of what they were talking about, but it is based on the premise that you view your social network “friends” as you view your friends and family from the non-web world. Now, it’s possible and even likely that you may meet someone on a social network and actually become friends with them. This may even be part of the appeal for someone participating in a social network. The problem for an attacker is cultivating a true friendship takes time, effort, and resources. Attackers and scammers are all about effort vs reward. They are not going to take 6 months to a year of effort to try and scam someone out of 100 dollars.

Some other faulty logic they used is blurring the lines between the topic they were talking about and the Nigerian scam where they compromised peoples actual accounts. They then sent messages to their friends saying they were stuck in Nigeria and needed money. Still dumb, but this is a compromise of an already established social network presence. A far greater difference than a friend of a friend that you don’t know asking for money. You can see more information about that here. True they both ask for money, but the scenarios are far different.

Now This is Nasty

If you want to talk about dangerous, during the talk Shawn Moyer and I did at Black Hat and Defcon last year and even our ShmooCon talk this year I mention a concept that involved attacking innocuous functions. On certain social networks this would allow you to semi-hijack a person’s social network identity. The concept deals with blocking communication and creating a denial of service condition for all visitors to someone’s social network profile. You could then create a new, duplicate identity with the user’s information and try to re-friend previous friends. In the message you tell them something went wrong with your account and you had to create a new one.

This is far more dangerous than the scenario that the article goes in to. It’s much easier than trying to compromise someone’s account, you are able to disrupt normal communications between friends, and you are able to potentially hijack already established trust. An attacker could then run a scam under this identity giving them a higher percentage of success.

Social Networks and Safety

I am the last one to say that social networks are safe, for example see here and here. I just can’t stand bad information and fear mongering. Yes, fear mongering. “The child molesters are going to get your kids on the social networks”. Yuck! In a comment on his own blog post Bruce said,

“I’ve seen some of my friends on Facebook put their address and phone number on their information page. Anyone they add can see it, and one such person I know has well over 1,000 friends. Not a good combination with videos of his two small children posted.”

Why is that not a good combination. You can’t possibly believe that 0.1% of the Facebook population are child predators?

Now it’s true that some people do put far too much information on their pages. This is due to the fact that it is not clear to them what is really sensitive.

A Note To Parents

Child predators are not trolling social networks (with any significance) trying to molest your kids. Child predators are opportunistic just like other types of attackers. They are not going to see an address on a social network and pay the house a visit. There are just too many variables for the predator to deal with. Parents, guns, neighbors, witnesses, geographic locations, and many other factors make this a prohibitive method for them to use.

Now as far as them using social networks to try and contact your kids there are many factors there as well. Social networks do monitor their network. Some networks are better at it than others, but there is the monitoring factor. Not to mention the person would have to spend quite a bit of time creating a relationship with your kids, which leaves them at risk for being found out by parents. I mean hopefully your kids don’t just go off to meet with strangers. If that is the case then you have much larger problems.

As parents you have control over the internet connection and your kids usage of the Internet. Know who they are talking to and what their activities online are. Remember your being curious not paranoid. You get paranoid over things you have no control over, these are your kids :) Know who they talk to and who their friends are. After all, a predator is going to try to get them alone and away from parents.

There is always the rare case that is the exception to the rule. Things happen and there are people who are just nuts and don’t think logically. People have been watching too much To Catch A Predator and think that the world is crawling with child molesters. Common sense should be your guide not a television show that is trying to get ratings. Besides in that show they had people posing as teens in an adult chat rooms, not social networks. Which just goes more to the point that I made about these individuals being opportunistic.

If you want more proof about the social network threats to kids being overblown you can read more about it from the New York Times here.

The Thief Scenario

Having your address on your soc net page and then a message saying, “On vacation out of the country” seems like (and really is) a stupid thing to do. Let’s look at it closer from the viewpoint of a thief. There are many variables here as well that still wouldn’t make this feasible. What about alarms, house sitters, family, neighbors, etc. This is on top of the information gathering activities that a thief would have to do prior to targeting someone anyway.

Now what is much more likely that attacker would target someone and augment their activities with information they find on social networks. These sort of targeted, personal information gathering activities can be pretty dangerous, but still not very realistic from a thief’s perspective. Thieves are opportunistic as well. What would change the scale is if you had known assets that someone REALLY wanted. This would warrant the time put in to the information gathering activities. Even in these scenarios the information from social networks only helps, the person would most likely be targeted anyway. There are rare exceptions, but just trying to put this in to perspective.

Social Landscape

There are aspects that make social network ripe targets for attack. They are a large collecting point for users. They are made up of mostly user generated content, many allow extensions and 3rd party applications. Any large collecting point of users is going to be looked at by an attacker. These are just the facts, but when discussing dangers and threats we need to look at them in terms of real risk. When we raise the danger flag for things that aren’t necessarily a risk we may draw attention away from things that really are a danger.

I particularly enjoy the individuals who say that they would never join a social network or communicate with people who do. As if people that use social networks somehow don’t know something that they do. I turn that around, why not use social networks? Are you socially inept and not able to communicate with your fellow man? Do you even know what social networks are used for? Of course, using social networks is a personal preference. It doesn’t have any bearing on the user’s awareness or intelligence level. However there are millions of the ugliest MySpace pages in history just waiting for you to view them :)

Now there are some social impacts when professionals use social networks that I may cover in another post, because these have impacts as well.

In Closing

The low level of probability of these attacks is no excuse to be careless with your information. I just wanted to put some things in perspective and curb potential fear mongering. When you participate in a social network you are responsible for the information you post about yourself.

I think ultimately if you read articles or hear people theorizing about attacks on social networks and they don’t have a social network presence, be skeptical. This is especially true when they are discussing social attacks. While it’s true that social networks are just web applications sometimes the vulnerabilities come from how users interact with them. This often requires participation for understanding.

Lastly, I want to make it clear once again, I am not vouching for the safety of social networks by any means. There are many dangers on social networks. I just want to make sure that we focus on the true dangers of social networks so we can raise awareness for those issues.

LinkedIn Profiles Are Not “Serving” Malware

LinkedIn_logo

The past few days there has been a bit of a stink about some bogus LinkedIn profiles. There have been plenty of news sources reporting that LinkedIn profiles are serving malware or making it seem like profiles are infected somehow. A few examples of that can be found here and here and here. At least The Register called these people falling for this fools. What the titles of these reports imply are dead wrong. LinkedIn profiles are not actively attacking users.

The issue is very simple, it is a hyperlink to another site that infects idiots with Malware. A hyperlink to another site, not getting attacked from viewing a profile. When you allow users to link to off-site content, you lose control of the request, however, this isn’t like allowing users to pull content in from other sites to display on their profiles. This typically has very little impact. This is no different than any other site, message board, or social network.

Give me a break, like Beyoncé Knowles has a LinkedIn page and is going to have a hyperlink on there to a place to view her nude pictures. That’s the issue these sites are referring to, dumb isn’t it? How does that get turned in to words like serving, harboring, or redirecting? These words imply some sort of active action on LinkedIn’s part, which doesn’t describe the situation here AT ALL. If you ran a message board and someone had a hyperlink to Goatse, does that mean you are serving, harboring, or redirecting to Goatse? Of course it doesn’t. This would just be an indication of your user base. I wonder how many people were brave enough to click the Goatse link above :) It’s not Goatse, promise.

Is there really no end of the Internet news stories this week to scare people with so people decided we should be scared of LinkedIn? This is basically spreading FUD. I personally don’t see why LinkedIn should take any heat from this. The feature of LinkedIn that allows you to link to your Company, personal site, or some other site should remain a part of LinkedIn’s features. I really hope they don’t go with something like MySpace did with the msplinks stuff. This would basically put a big obnoxious splash page up that states you are about to visit content off of the site. Yeah, well no crap I just clicked on the link so of course I want to visit the page. I personally don’t think that is a very effective control for these types of attacks anyway. The only time that control is effective is if it isn’t clear to the user that they are visiting content off the particular site they are on. I have seen in the past MySpace profiles that were compromised and the whole profile links to a bogus MySpace login page. In that case the user seeing the warning would be alerted that something is wrong, however, you are still going to have a large amount of people just cough up their credentials anyway. Sometimes all the controls in the world just can’t fix stupid. The same people that would fall for this are the same ones that click on spam emails claiming the same thing. It’s a mentality not a technical security issue.

Let me state this, if you are not a complete idiot then this issue will not affect you in the least bit. These profiles are not performing any active attacks on users of LinkedIn. There are much more scary things out there than this, trust me. Don’t fear using LinkedIn because of issues like this. LinkedIn really has a very limited feature set which lowers their attack surface. They have much less functionality that other social network such as MySpace, Facebook, Hi5, etc. Would you really care to see Beyoncé Knowles’ LinkedIn profile anyway? I bet she is boring and fake. Her LinkedIn profile would state, “I have never had to work for anything in my life and everything has been handed to me because dummies think I have talent. I love screwing over my friends and taking money out of their pockets”. She should apologize to the world for creating that DirecTV Upgrade song. Yuck! Wait a minute, she doesn’t write her own music… Anywhoo….

I can’t believe I had to write this blog post, but the sheer number of people talking about this and linking to these stories was too much. Just practice smart Internet browsing habits mixed with common sense and you will be fine. As always, I recommend using the Firefox web browser with the extensions NoScript and Adblock Plus. Have a good week, the end of the Internet is next week :)

LinkedIn Apps Announced

Posted originally on Neohaxor.org, re-posted with permission:

Business social network LinkedIn announced their LinkedIn Applications today. The applications directory can be viewed here There are only several applications to chose from at the moment. I am sure that number will grow soon. LinkedIn uses Google’s OpenSocial just like other social networks such as MySpace, Orkut, hi5, etc. I only spent like 5 minutes looking at a couple of things. So, the following are only my quick thoughts and impressions.

The applications are delivered though the domain lmodules.com. This makes them easy to identify and block if that’s what you would like to do.

At first glance it appears that the vetting process for LinkedIn is higher than some of the other social networks. They appear to only want known businesses to create applications for their network at this time. This would help root out some possible malicious users. A vetting process is a good first step in thwarting that type of malicious behavior. I didn’t look at the difficulty in attaining a developer account, but I am assuming it is much more difficult than other social networks like MySpace, Facebok, etc. Now, whether this vetting process will stay this stringent will remain to be seen. These procedures may be relaxed in the future due to demand.

Just because the name has changed doesn’t mean the threats have changed. As a matter of fact there may actually be more on the table. Business networks such as LinkedIn are more likely to contain real information about people vs other non-professional social networks. Not that people don’t share enough about their real self on other social networks. This means the same threats exist for the capture of information as on other social networks.

There are still technical threats from social network applications on LinkedIn as well. These are the very same issues as other social networks that we have discussed in the past and demonstrated. Malware distribution, social engineering, attacking clients, information harvesting, click fraud are just some of these threats from social network applications. Moral of the story is be careful. Don’t install apps you don’t need, even though you may do so on your iPhone ;)

So all in all the threats are the same with LinkedIn as any other social networks that employ applications. However, with a more stringent vetting process this should reduce the possibilities for malicious by making accounts harder to get.

Attacking Password Resets w/ Social Networks

Posted originally on Neohaxor.org, re-posted with permission:


Password Reset: Your passport to a fuxored account.

Password Reset Methods Vulnerable? Really? Get out of here, you mean that many password reset methods are vulnerable to attack? You have to be kidding. The fact that people think vulnerable password reset is newsworthy have got to be crazy. This is something that many of us have been talking about for years. Now Sarah Palin’s email gets attacked and it is big deal. It amazes me why we always wait to get screwed by something before we fix it.

Why does everything in the security world have to be a response to something. Ok, not the security world but the business security world. They are definitely two different entities. I am truly tired of reactive security. Just think if other professions followed this reactive model, like a cop asking for a bullet proof vest after they have already been shot. Nobody can say they didn’t see this coming either. People make more of their life known through social networks, photo sharing, and blogs than ever before. The simple password reset questions just don’t hold up.

There is a lot of unnecessary fear about data from social networks being used to steal someone’s identity. Although this is mostly FUD, social networks can be a great source for password recovery data. A while back we recovered a password (with his permission of course) from my friend Brian’s Sprint account using data from his MySpace page. This is when we were first starting our research for the social network hacking project.

Let’s take a step back from social networks for a sec, would your friends, co-workers, significant other, etc. be able to recover your password with the information they know about you? If the answer to that question is yes, then you need to change something. Passwords should be something that you know, not you and a couple of other people.

What Types of Data are on Social Networks?

The information that people put on their social network pages range from minimal to wildly over the top. Some people even go above and beyond by posting survey questions that tell a lot about their personalities. Although they want to show off the depth of their personality, all it really does is show off the shallowness of their brain.

Social networks by their default nature basically allow you to “friend” the world. The information on people’s social network page typically contains information that was previously only known to traditional friends and acquaintances. This can be a huge problem for the password reset mechanism, not to mention a person’s privacy. If it’s deep and kinda scary from a privacy standpoint then it is probably on a social network. Remember when I mentioned if your friends knew enough about you to reset your password then you are in trouble, well you just friended the world with the information from your social network profile. Beyond standard profile information there are a users actions taken on a social network site and possibly social network applications that are being used as well. All of this information can be leveraged when attacking a password reset mechanisms.

You can use an email address to look up people’s accounts on social networking sites. On the flip side, someone social network profile might directly tell you a person’s email address or you can use the search features of the social network to query owner’s of certain email addresses. There are no secrets in social networking ;)

Email Accounts are Gold

With password resets an email account is really the jackpot. Many password reset mechanisms, including the ones from social networks, rely on sending either the password or a temporary password to the email address of the account owner. Someone who gets their email account compromised might just find that they have every other account tied to that email account compromised as well. I mean, it wouldn’t be a far stretch to figure that out once someone had access to the email account. Just think of all the crap that sites like Amazon, eBay, MySpace, Facebook, etc. send to your email account.

Typical Password Questions

Typical password recovery questions really vary in complexity from site to site. What is the problem with password recovery questions in general? Well, they are not typically made up of data that is private. Unlike a password which is supposed to be something that only you know, recovery questions may be known to many people around you.

Here are some questions from Yahoo:

  • Where did you meet your spouse?
  • What was the name of your first school?
  • Who was your childhood hero?
  • What is your favorite pastime?
  • What is your favorite sports team?
  • What is your father’s middle name?
  • What was your hight school mascot?
  • What make was your first car or bike?
  • What is your pets name?

Some of these questions look like questions that social networks ask when you are filling out a profile, don’t they? If not questions they ask, certainly data that people put on their social network profiles or divulge through other means on a social network.

The Obvious

Take a glance at someone’s profile or maybe your profile on a social network. From just this page without further probing there may be an enormous amount of information. Depending on the mechanism that is being attacked, it may be all that is needed. Here is an example of some of the things that may be found just on the profile page:

  • Name
  • Date of Birth
  • Hometown
  • Current town
  • Favorite movies, artists, music, people, TV, sports teams, etc
  • High School
  • College
  • Personal description
  • Personality traits
  • Networks and Groups
  • Relationship information
  • Family information
  • Employer

The list really goes on and on. Remember that many people are on multiple social networks. Checking out other social networks may fill in the blanks. It is easy to see why this information could be a problem and I don’t think it needs any further explanation.

The Not So Obvious

Some data is not so obvious and might not be directly spelled out. This may be information that has to be aggregated or inferred from the profile data, friends list, blog, group, network, etc.

  • Photos and photo tags
  • Comments on other profiles
  • Photo data (cloths, background, other individuals, etc)
  • Pets
  • Children
  • Siblings
  • Relatives (potentially ones with your mother’s maiden name?)
  • Potential usernames
  • Instant messenger data
  • Blogs and comments in friends’ blogs
  • Favorite teachers
  • Sexual preference
  • Religious views
  • Political views

The data is really limitless, but after all isn’t that what a nice web 2.0 application is supposed to provide? On the surface some of this data may seem silly for password resets but it is really not. This not so obvious information can be really helpful when when non-standard questions are used in the password reset process. This typically happens when people are left to their own devices when creating security questions. They typically create questions that are common and familiar to them. Stupid things like pet’s names, favorite teams, favorite TV shows, etc.

Just think for a moment about tagging. People may tag photos themselves with useful information. Also, friends may tag people in photos helping better define a person’s relationships with people and activities they are involved in. The URL of the social network may lead you to potential usernames / IM information such as www.myspace.com/(username). Maybe the data is completely visual like photo data. A lot of information can be obtained by looking at pictures. Favorite places, sports teams, cars, and countless other possibilities. You name it, people like pictures with their favorite things.

The actions people take on social networks helps better define relationships, networks, group affiliations, and activities. The person may place comments on other people’s photos, profiles, walls, blogs, etc. You may see comments like “That is why you are my BFF”. You may also see that someone is a member of a political party or religious group. People may discuss on boards or blogs about certain things happening in their life. Sharing is caring right?

So what you get in the end is a clear picture of who these people are. You get their likes, dislikes, friends, and affiliations are all in a nice clean package. You may have never even met this person but you have all of the information a traditional friend may have, possibly more.

Need a bit more?

If you almost have the nail in the coffin then you can turn to other sites to complete the task. You could look for name / username collisions on other sites to gain more data. You could take their high school and age information and find out who they went to school with. The possibilities are endless.

The User’s Choice

When people are given the option to choose their own security it has historically been bad. There is nothing that seems to suggest that allowing user’s to choose their security will get any better, so some of this may be wasted breath.

When looking at sites like Google, it seems they have slightly better security questions. Questions such as your library card number, frequent flyer number, etc. I think sites like these with better security questions probably have a high amount of people that end up just choosing their own questions when this option is available. People don’t seem to understand that this isn’t a function that you are going to use everyday. It is ok and preferable to use data that you may not be able to recall without looking up.

So What Can We Do?

The problem of personal data leakage isn’t going to stop until people realize the potential impacts of their data being strung out for the whole world to see. I personally don’t think this will change, in fact, I think with time it will get a lot worse. We live in this voyeuristic, virtual world where people create digital representations of how they see themselves. I think that has an appeal to many people, especially those who don’t particularly find their lives that exciting.

Don’t play by the rules when dealing with a sites password reset questions. Put blatantly wrong, hard to guess, or nonsensical information in to the answer blocks. This will make any information gathered on you useless when attempting to recover your password.

It seems that many sites want you to log in. You shouldn’t use the same password on every site. Use a trusted password safe such as KeePass to store your login credentials. KeePass is open source and multi-platform. Using a mechanism like this allows you to be in control of your password recovery along with allowing you to use different passwords for different sites. It would also be a good idea to back up the database of whatever password safe you choose to use as well. Just a thought ;)

The biggest mistake someone can make is thinking that there is nobody out there that gives enough of a crap about them to attack their accounts. People do weird things. Anybody is capable of just about anything. This isn’t being paranoid, it’s being safe. Think of it as locking the door on your house when you leave, only instead of your valuables you are protecting your data.