Ok, first order of business, I love Dropbox. If you are unfamiliar with Dropbox it is a popular cloud based syncing / storage / sharing application for your files. It allows you to store files, roll back changes, etc. You can get more familiar with them by visiting their site https://www.getdropbox.com

Now that I am done singing the praises of Dropbox, it’s time to get to the nitty gritty. This issue isn’t necessarily devastating for Dropbox, but could lead to some larger issues with other cloud based providers. The reason I am writing about this issue is because I think it can aid other individuals in the design of their applications. Let’s face it, cloud based applications and storage aren’t going anywhere.

What You Should Notice

One of the first things you should notice after installing Dropbox is that it sets up some files and folder structure for you.

A few of the folders are Documents, Photos, and Public. A couple of files that show up are This is your Dropbox.txt and if you have installed the iPhone app you get the iPhone intro.pdf. Your Public folder is where you can put files that you want to share with via a public URL.

So by default you get a Public folder with a public file that is shared called “Top Secret.txt”. If you go to the Dropbox menu you can obtain a link for the public file that has the following structure:

http://dl.dropbox.com/u/{acct number}/Top%20Secret.txt

So now you have a known resource  with a known location. By simply requesting this resource and changing the account number you can enumerate through valid accounts. In doing this it will become apparent relatively quickly that account numbers are sequential. You would also notice that most people do not delete any of pre-installed default files even though they are unnecessary. These files are Dropbox’s way of communicating with you about what the folder should be for or about something the application does.

It is fairly simple to enumerate through account numbers and come up with a list of valid users, you could do this in just a couple of lines of Python code:

#!/usr/bin/env python
 
import httplib
 
f = open("dropbox_accts.txt", "w")
 
for num in range(1440000, 1450000):
    request_string = "/u/{0}/Top%20Secret.txt".format(num)
    conn = httplib.HTTPConnection("dl.dropbox.com")
    conn.request("GET", request_string)
    req = conn.getresponse()
    if req.status == 200:
        print(req.status)
        f.write("{0}\n".format(num))

What this does is enumerate through account numbers from 1440000 to 1450000, and if there is a return on Top Secret.txt, it records the number in to a file called dropbox_accts.txt.

Why This Is A Problem

This is a problem for multiple reasons. First of all, it allows an attacker to determine valid accounts on the system. This gives an attacker a starting point for an attack on an account. Another thing to note is that it shows accounts are created sequentially which could lead to other issues.

Working on account enumeration it would be possible for an attacker or someone tracking Dropbox to determine how many new users they have per a certain period of time just by starting where they left off with their previous enumeration activities.

The issue might allow an attacker to try to obtain some information about a particular user through sifting through their public files, if they were guessed. Yes, an attacker would have to guess the name of a valid file but we as humans tend to name files descriptively, so it may be easier than it seems. There is no randomness attached to the filename /URI that would deter this type of activity. After sifting through this data it may be possible to determine the name of the individual who owns the account. Another thing you might find from this activity is an email address associated with the login of the account. If they were to obtain the email they would have the login (email), account number, and the person’s real name. It would not completely out of the question to find something like resume.doc in a user’s Public folder. This is a lot more than an attacker should have.

Now this shouldn’t be a huge deal because it is a “public” folder, it should be assumed that everything in there could be accessed by anyone, but people don’t always make the best choices when it comes to sharing. Many people who use Dropbox use this folder to share things with their friends, not the entire world.

Probably most important, is that they are using known resources and locations. This can be a particularly bad issue for cloud based applications due to their public nature. Every Dropbox account has several folders set up by default along with several files added. These rarely get changed and just get utilized by users. Giving an attacker known resources and locations goes a long way to a successful attack. It allows an attacker to gauge success or failure of a given attack and gives them ready-made resources on which to focus their attacks.

Dropbox uses these files in their private directory structure as well, which opens the doors for some interesting possibilities. I have not really dug in to their API or too much in to their web interface to really say where this might be an issue, but the groundwork can be done in relatively small period of time.

Without having any kind of knowledge how the back end of Dropbox works, it’s hard to tell whether any of the information (ie Account Number) that can be be enumerated can be used to attack user files at rest. It may be hugely important or totally innocuous. I am assuming they have probably thought of this, but you never know.

What’s The Takeaway

People designing cloud based applications and storage should be aware that creating items with known locations could increase their attack surface by giving attackers something to work with. This should be kept to a minimum. Users should be defining the structure of their storage and setting up names for their resources. If you need to communicate with users, it should be done in a message format vs leaving a standard named file in a known location.

Public resources, even though they are public should have some form of randomness added to their resource locations. This way, it is not extremely easy for an attacker to enumerate resources and gain information about the application and its users. It would be a better idea to take the approach that Flickr does with it’s randomized URLs for photos. That way it is not easy to map a resource to a given user or account number.

When numbers associated with accounts are exposed, they should take on some form of randomness or there should at least not be any exposed method that would allow someone to enumerate through them easily.

Threat modeling should be done on the application during the design phase allowing for the identification of issues before they get worked in to production. Always think about how the application could be abused. You would think this would be second nature by now, but so many organizations are not doing this.

If you are Dropbox user you should delete the default files that are created by Dropbox, especially the Top Secret.txt that is in your Public folder.

In Closing

In closing not extremely devastating on the surface for Dropbox, but definitely food for thought for anyone working on the design of cloud based applications. Issues like this are definitely not isolated to Dropbox. I wrote a tool about a year and a half ago (that I had forgotten about by the way) for pulling valid users and data out of Apple’s MobileMe service. An issue that still exists to this day. Cloud providers need to be thinking about this stuff in the design phase because it is hard to make changes after deployment.

]]> http://www.neohaxor.org/2009/12/11/enumerating-dropbox-resources/feed/ 3 http://www.neohaxor.org/2009/09/17/social-media-strategy-and-implementation/ http://www.neohaxor.org/2009/09/17/social-media-strategy-and-implementation/#comments Thu, 17 Sep 2009 14:38:58 +0000 Nathan Hamiel http://www.neohaxor.org/?p=216

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.

I haven’t really written much about Python lately. I have a feeling that is about to change Python is great because it is powerful and allows you to do things very quickly. I figured I would write a short post to show how to remove duplicates by just using the set type. This is probably the quickest and easiest way of removing duplicates in Python.

I don’t think I need to get in to how useful it can be to easily remove duplicates. I have used this many times in the past for doing everything from removing duplicate values from a list of SQL Injection checks to just determining how many unique occurrences I have for a given test.

set

Python has a type called a set. A set is basically an unordered collection of unique values. You can create a set by specifying a new empty set and adding values to it or by converting another type. The set conversion can be done over any iterable object.

Create a new empty set called myset:

myset = set()

You can add values to your set by using add or update:

myset.add("hello")
myset.update("world")

Convert another type to a set called newset:

newset = set(another_type)

Sets in Python are nice for a couple of reasons. The first being they only keep unique values. This means that any type you convert to a set or anything you add to a set is unique. It will discard duplicate values. Secondly, you can test for membership in the set. Testing for membership will give you a True / False response based on whether a value exists in the set.

Here are some examples

Converting a list to a set.

Even strings are iterable objects in Python. String conversion to set.

The following shows True / False values for membership tests from the previous string conversion.

Practical Example

Let’s say you wanted to write a small program that took a file, removed the duplicates, and created a new file with only unique values. The file that contains the duplicates has one value per line, which means there is a newline at the end of each item. You want to maintain the newline in the new unique file that you are writing to as well. You will see the newlines in the following specified by “\n”.

The following is an example:

#!/usr/bin/env python
 
import sys
 
if len(sys.argv) < 3:
    print "Usage: remove_dups.py original_file.txt unique_file.txt"
    sys.exit(1)
 
file1 = open(sys.argv[1])
file2 = open(sys.argv[2], "w")
 
unique = set(file1.read().split("\n"))
 
file2.write("".join([line + "\n" for line in unique]))
file2.close()

I will explain a bit of what’s happening here. Let’s say we have copied this in to a file called remove_dups.py. This program takes two arguments, your original file and the name of the file you want to create without the duplicates. If it doesn’t have the two arguments the program exits.

Next both files are opened, with the second file opened for writing. The first file is read in splitting on newlines. The unique variable now contains the unique values. We then write to the second file every line concatenating a newline on the end. This makes the second file contain the unique values one per line.

You now now how to remove duplicates in Python using the set type. Knowing is half the battle

Update

I wrote this post very quickly and didn’t explain about my use of read() vs using readlines(). Marcin pointed out yesterday that it wasn’t clear. I wanted to show how you could use read() and split on newline characters. My hope was that you would see how you could split on any character when reading a file like commas, semicolons, asterisks, or anything really.

In the code example above, if you wanted to read in a file per line instead of splitting on the “\n” character you could just use readlines() instead.

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.

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.

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.

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.

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.

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.

Hello Everyone. I just thought I would drop a quick note. Shawn Moyer and I are speaking at Black Hat US 2009. Our talk is called Weaponizing the Web: More Attacks on User Generated Content. We are going to be talking about attacking sites with user controlled content. In the modern web environment, that’s a whole lot of sites. This content can be turned around and used against the site, the user, or other sites.

If you are going to be out at Black Hat this year also check out Michael Murphy and Aaron LeMasters’ talk Rapid Enterprise Triaging(RETRI). Mike and Aaron are fellow members of Hexsec. Anyway, that’s all for now.

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.

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