Hacking Your Location With Facebook Places

I just published a post over on the SecureState blog about how to hack your location using Facebook Places.  The post brings up some interesting questions about how social networks are going to have a problem with fake location check-in’s. In the meantime, it’s a way to have fun with your friends…:-)

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


Facebook Privacy & Security Guide Updated to v2.3

Just a quick post that I have updated the Facebook Privacy & Security Guide to include information on configuring the privacy settings for Facebook Places.  You can find this on the first page under “Sharing on Facebook”.  Stay tuned for more information on Facebook Places in the next day or so!

Download the updated Facebook Privacy & Security Guide here (pdf download).

Facebook Places Brings Simple Location Sharing to the Masses

Yesterday, Facebook announced a much-anticipated feature that allows users to easily post their current location on the site. The new setup, known as Facebook Places, works much like other location-based services, such as Foursquare or Gowalla, by letting users “check in” at nearby places. Geolocation providers, such as a mobile phone’s GPS, pinpoint the user, and Localeze provides the initial database of places. Eventually, users will be able to add their own locations to the Facebook map. Inside Facebook has a run-down of the overall functionality.

Facebook also allows your friends to check you in at locations, and these check-ins are indistinguishable from ones you made for yourself. In typical opt-out fashion, you can disable these check-ins via your privacy settings, and you’ll be asked about allowing them the first time a friend checks you in somewhere.

Even if you stop friends from checking you in to places, however, they can still tag you with their check-ins, similar to how friends can tag you in photos or status updates. Such tags will appear on your wall, as tagged status updates do now. You’ll be able to remove tags after the fact, but it doesn’t seem that you’ll be able to prevent friends from tagging you altogether.

Applications have two new permissions related to places. One gives access to your check-ins, the other gives access to your friends’ check-ins as well. Both will appear in the list of requested permissions when you authorize an application, and they are required for API access to check-ins. If your friends grant an application access to friends’ check-ins, you can prevent yours from appearing via “Applications and Websites” privacy controls.

API access is currently read-only – authorized applications can access your check-ins, but can’t submit check-ins to Facebook. That sort of functionality is currently in closed testing, though.

ReadWriteWeb has a nice guide to applicable privacy settings. When these controls first appeared on my profile, Facebook set the visibility for all my check-ins to “Friends Only” by default and disabled API access to my check-ins via friends by default. But they also enabled by default another setting which makes individual check-ins visible to anyone nearby at the time, whether friends or not. The option for letting friends check me in was not specifically set, but apparently I would have been prompted the first time a friend checked me in.

According to Facebook, you will only be able to check-in at locations near where you are, as determined by the geolocation feature of your browser (or your phone’s GPS for the iPhone app). I’m a bit suspicious on how difficult faking a check-in will be, but I don’t yet have the ability to test that out.

Facebook’s initial geolocation rollout brings a fairly modest feature set, but when integrated with Facebook Pages and made available to a network of 500 million people, the service offers great potential. As with other recent changes, adding check-ins reduces friction for users to share their location and provides Facebook with another valuable set of data about people’s daily activities. It remains to be seen whether users will react with discomfort over the potential for an entirely new meaning of “Facebook stalking” or with excitement over potential new product offerings. Either way, the amount and variety of information under Facebook’s control continues to expand rapidly.

Social Media Security Podcast 17 – ICanStalkU, QR Codes, Facebook directory via Torrent, LinkedIn CAPTCHA’s

This is the 17th episode of the Social Media Security Podcast recorded August 13th, 2010.  This episode was hosted by Tom Eston and Scott Wright.  Below are the show notes, links to articles and news mentioned in the podcast:

Please send any show feedback to feedback [aT] socialmediasecurity.com or comment below.  You can also call our voice mail box at 1-613-693-0997 if you have a question for our Q&A section on the next episode.  You can also subscribe to the podcast in iTunes and follow us on Twitter.  Thanks for listening!

Security Through Obscurity and Privacy in Practice

Yesterday, security researcher Ron Bowes published a 2.8GB database of information collected from public Facebook pages. These pages list all users whose privacy settings enable a public search listing for their profile. Bowes wrote a program to scan through the listings and save the first name, last name, and profile URI of each user (though only if their last name began with a Latin character). The database includes this data for about 171 million profiles.

On the one hand, I wasn’t entirely surprised by this news – it was only a matter of time before someone started building up such a dataset. I’ve previously mentioned that developer Pete Warden had planned on releasing public profile information for 210 million Facebook users until the company’s legal team stepped in. But nothing technical prevented someone else from attempting the task and posting data without notice. I imagine Facebook may not be too happy with Bowes’ data, but I’m not going to delve into the legal issues surrounding page scraping.

However, the event did remind me of a related issue I’ve pondered over the last few months: the notion of “security through obscurity” as it relates to privacy issues.

I’ve often referenced the work of danah boyd, a social media researcher that I highly respect. In a talk earlier this year at WWW2010 entitled, ”Privacy and Publicity in the Context of Big Data,” she outlines several excellent considerations on handling massive collections of data about people. One in particular that’s worth remembering in the context of public Facebook information: “Just because data is accessible doesn’t mean that using it is ethical.Michael Zimmer at the University of Wisconsin-Milwaukee has made similar arguments, noting that mass harvesting of Facebook data goes against the expectations of users who maintain a public profile for discovery by friends, among other issues. Knowing some of the historical issues with academic research involving human subjects, I tend to agree with these positions.

But a related point from boyd’s talk concerns me from a security perspective: “Security Through Obscurity Is a Reasonable Strategy.” As an example, she notes that people talking in public settings may still discuss personal matters, but they rely on being one conversation among hundreds to maintain privacy. If people knew other people were specifically listening to their conversation, they would adjust the topic accordingly.

In this “offline” example, taking advantage of obscurity makes sense. But boyd applies the same idea online: “You may think that they shouldn’t rely on being obscure, but asking everyone to be paranoid about everyone else in the world is a very very very unhealthy thing…. You may be able to stare at everyone who walks by but you don’t. And in doing so, you allow people to maintain obscurity. What makes the Internet so different? Why is it OK to demand the social right to stare at everyone just because you can?”

I would respond that at least three aspects make the Internet different. First, you rarely have anyway of knowing if someone is “staring at you” online. Public content on Facebook gets transferred to search engines, application developers, and individual web surfers every day without any notification to the creators of that content. Proxies and anonymizers can spoof or remove information that might otherwise help identify the source of a request. And as computing power increases each day, tracking down publicly accessible resources becomes ever easier.

Second, the nature of online data means that recording, parsing, and redistributing it tends to be far simpler than in the offline world. If I want to record someone’s in-person conversations, it’s theoretically possible that I could acquire a small recording device, place it in a convenient location, save the audio from it, type up a transcript of the person’s words, then send it to another person to read. But if I want to record someone’s conversations on Twitter (as an example), I can have all them in a format understandable to various computer-based analysis tools in just a few clicks. In fact, I could setup an automated system which monitors the person’s Twitter account and updates me whenever certain words of interest appear. Add the fact that this is true of any public Twitter account, and the capabilities for online monitoring grow enormously.

Finally, while digital content is in some ways more ephemeral than other media, web data tends to persist well beyond a creator’s ability to control. Search engine caches, archival sites, and user redistribution all contribute to keeping content alive. If someone records a spoken conversation on a tape, the tape can be destroyed before copies are made. But if you (or a friend of yours) post a sentence or photo on a social networking site, you may never be able to erase it fully from the Internet. Several celebrities have learned this the hard way lately.

From a privacy perspective, I wholeheartedly agree with boyd that we can’t expect users to become paranoid sysadmins. The final point of my own guide to Facebook privacy admonished, “You Have to Live Your Life.” But from a security perspective, I know that there will always be people and automated systems which are “staring at you” on the Internet. I’ve seen time and again that if data is placed where others can access it online, someone will access it – perhaps even unintentionally (Google indexes many pages that were obviously not meant for public consumption).

In my opinion, the only way to offer any setup online which resembles the sort of “private in public” context boyd described requires some sort of a walled garden, such as limiting your Facebook profile to logged in users. That alone still doesn’t provide the same degree of privacy, since many fake profiles exist and applications may still have access to your data. But while “security through obscurity” (or perhaps more accurately, privacy through obscurity) may be a decent strategy in many “offline” social situations, it simply can’t be relied on to protect users and data online.

Facebook users are starting to discover this firsthand. I’ve seen several reactions to Bowes’ release that characterize it as a security issue or privacy issue, and people have seemed quite surprised that building such a dataset was even possible. Yet it really shouldn’t come as a surprise to someone familiar with current technology and ways of accessing Facebook data. And it won’t be the last time we see someone make use of “public” data in surprising ways. Some of these uses may be unfortunate or unethical (see above), but we’ve often seen technology steam ahead in pursuit of fortune, and the web has many users with differing ideas on ethics. Reversing the effects of such actions may prove impossible, which is why I would argue we need to prevent them by not trusting obscurity for protection. And how do we balance this perspective to avoid unhealthy paranoia? I’m honestly not sure – but if content is publicly accessible online without any technical limitations, we can hardly consider it immune to publicizing.

Spam via Facebook Events Highlights Ongoing Challenges

Earlier today, I received an invitation to a Facebook event from “Giovanna” – someone I’d never heard of and certainly never added as a friend. The invite came as a bit of a surprise, since my profile was fairly locked down. While anyone could search for it, all profile information was set to “Friends Only,” and sending messages or making friend requests was limited to “Friends of Friends.” None of my friends seem to know Giovanna, and her profile is probably fake anyway.

The event title proclaimed “iPhone Testers Needed!” and might be enticing to users who want an iPhone. While the event page included more information on the supposed testing program, the invite was followed by a message from the event creator. Once you’re on the guest list for a Facebook event, the event administrators can send out Facebook messages you’ll receive, regardless of privacy settings. This particular message (which also arrived in my e-mail inbox due to notifications settings) included a link to the iPhone opportunity, which unsurprisingly was a typical “offer” page that required me to submit personal information and try out some service before I could get my fancy new phone.

I began investigating how this all happened. When you create a Facebook event and try to invite people, you’ll only see a list of your friends to choose from. But it turns out that on the backend, nothing prevents you from submitting requests directly to Facebook with other people’s Facebook IDs. In my testing, I’ve been able to send event invitations to other users even if we’re not friends and they have tight privacy settings. I’m guessing that using this technique to invite more than a few people could raise a spam alert, but I’m not sure. Also, an event invitation does not give the event creator increased access to any profile information of guests, but as already noted, it does let event administrators send messages to people they might otherwise not be able to contact.

I’m sure Facebook will take action soon to clamp down on this particular loophole, so I think it unlikely we’ll see it exploited too widely. (The iPhone testing event currently has around 1800 guests – significant, but tiny compared to other Facebook scams.) But it does demonstrate the sort of challenges Facebook is having to handle as their network and power expand. Several years ago, when the site was used for little besides keeping in touch with college classmates and other offline friends, Facebook was seen as mostly spam-free, in contrast to services like Myspace. Now that applications, social gaming friends, and corporate brands have all become integral parts of the Facebook experience, black hat marketers keep finding new ways to spread links among users. And worse, those tricks can often be used to spread malware as well.

I do think that Facebook wants to avoid annoying users with spam, and works to prevent your inbox on the site from becoming as flooded as a typical e-mail account. But a network of 500 million people presents a very enticing target, and we’ll keep seeing new scam ideas pop up as Facebook expands and adds features. In the mean time, continue to be wary of any links  promising a glamorous reward for free.

Social Media Security Podcast 16 – Diaspora News, FTC and Twitter, Twitter XSS, Facebook App Permissions

This is the 16th episode of the Social Media Security Podcast recorded July 2, 2010.  This episode was hosted by Tom Eston and Scott Wright.  Below are the show notes, links to articles and news mentioned in the podcast:

Please send any show feedback to feedback [aT] socialmediasecurity.com or comment below.  You can also call our voice mail box at 1-613-693-0997 if you have a question for our Q&A section on the next episode.  You can also subscribe to the podcast in iTunes. Thanks for listening!

Secure Your WordPress By Learning From My Mistakes

Several weeks ago, I managed to create a small ruckus on Twitter by issuing a warning about a possible WordPress vulnerability. I was rather embarrassed to eventually discover that the actual problem related to a backdoor still on my server from a previous hack. This was not my first lesson in WordPress security, but it was certainly a memorable one.

I first created this blog in 2007 after finding basic CSRF issues in the first publicly available OpenSocial application. At the time, I admittedly knew very little about application security (not that I know much now!), but I was interested in many aspects of building online social networking systems, and that led me to research security issues more and more. Over time, this blog grew and several other projects hosted on the same server fell by the wayside. As my understanding of security also grew, I found some of my sites hacked a few times, and I undertook a number of steps to secure this WordPress installation.

That maintenance contributed to the confidence I had in my warning on Twitter – malicious scripts kept popping up in my site’s footer, and the only apparent problem were some suspicious requests to a particular WordPress interface. I had looked gone through all my plug-ins (the apparent source of previous attacks), double-checked my permissions, changed passwords, etc. I finally did a thorough sweep of every single folder on my site, and lurking in an upload folder, I found a sophisticated PHP backdoor.

I’m guessing that file originally been placed during a much older attack and I’d simply missed it until now. Since deleting it and taking even more steps to protect my blog, I’ve not had any more trouble. I wouldn’t presume to think this site is 100% secure and I’ve never claimed to be an expert on application security, much less WordPress or PHP security, but I’m now quite confident that I’ve taken enough precautions to avoid most attacks.

That leads me to the following list of steps I’ve performed to harden this particular WordPress site. If you’ve not taken the time to ensure your blog is secure, this may be a good guide for you to start with. I’m indebted to many websites on WordPress security, and while I would want to link to all of them, I’m honestly not sure of all the specific ones I’ve drawn from and it would take a while to piece them together. A quick search will bring up many helpful recommendations, and I encourage you to check them out in addition to these tips.

  • Stay updated. Running the most current version of WordPress is probably the most important step. My host offers automatic updating for my installations. Also, be sure to keep your plug-ins updated as well.
  • Protect other sites. If you have more than one website running on the same server, make sure all of them are secure. One vulnerable application can compromise others. If you have sites that you don’t maintain, consider deleting them or locking them down to avoid future problems.
  • Scan through all of your folders. If you haven’t done this in a while, now would be a good time. Look through what files are present and keep an eye out for anything suspicious. Check your WordPress files against a fresh download to make sure they line up.
  • Scan through all of your permissions. This should be fairly easy with an FTP program that displays permissions settings. With rare exception, I keep files at chmod 644 and folders at chmod 755.
  • Periodically change passwords. Definitely modify your passwords if you’ve recovered from an attack. Remember to change your database password (and corresponding line in wp-config.php) as well as account passwords.
  • Use modified passphrases. This is one tip I don’t see often, but it’s one of my favorite tricks. Rather than simply jumbling characters into a password you have trouble remembering, start with a sentence. Not something terribly common, but something familiar to you. Pick one with at least six words in it. Take the whole sentence, with capitalization and punctuation, and add some complexity – append some numbers and punctuation at the beginning or end, and maybe change a few letters to numbers (such as “3″ for “e”). You should then have a very strong “password” that’s much easier to remember. Many websites and applications will let you use spaces and hundreds of characters in your password. But once again: avoid common phrases, include at least six words, and don’t just use a sentence without adding some numbers and special characters.
  • Check your users table in the database. I’ve seen attacks before that lead to the creation of an administrative account which is then hidden from the list of users in the web-based control panel. I’ve never quite understood why hidden users should be allowed, but that could be part of the attack to begin with. Anyway, just to be careful, I like to look at the actual table in the database and see if any other accounts have administrative privileges.
  • Double-check and clean up all plug-ins. I’ve deleted every plug-in I don’t use, and I try to keep all of my active plug-ins current. If you have a plug-in that’s no longer maintained or hasn’t been updated in a long time, you should probably check and see if a newer replacement is available. In my experience, plug-ins can be one of the weakest points in your WordPress installation. It’s kind of like a certain other site I know well – Facebook itself tends to be pretty secure, but you can often access data through vulnerable Facebook applications.
  • Add HTTP authentication to your wp-admin folder. This is covered in many places online so I’ll not recap specific steps here. And I’ll add that I realize this is not a silver bullet – basic authentication sends passwords in cleartext (so don’t use the same credentials as your WordPress account), and the traffic is not encrypted if you’re not using SSL/TLS. But adding another login prompt for the admin panel adds friction and may repel less-determined attackers. (This tip is obviously geared towards those who don’t have user accounts for non-admins.)
  • Move wp-config.php to a folder not as easily accessible. You can place wp-config.php one folder above your WordPress install; under my hosting setup, this location does not correspond to any public website folder. I also set mine to chmod 644 after changing it.
  • Rename your admin account. Several means exist to do this; I simply edited the record in the database.
  • Change your table prefix. This can be a bit of a hassle, but plug-ins exist (see below) to help. I’ll admit that I still need to check this one off my own list; long story.
  • Disable interfaces such as XML-RPC if you don’t use them. I don’t doubt that the programmers behind WordPress have worked hard to secure these interfaces, but I simply don’t like having another avenue of accessing administrative functions. And I think it’s not a bad idea to disable features you don’t actually need.
  • Use security tools. I installed the WP Security Scan plug-in after reading about it on WordPress’ own hardening guide.
  • Keep monitoring your site. I make a habit of loading up my homepage ever so often, hitting “View Source,” and scanning through the HTML. If I ever see an unfamiliar script or iframe element, I look closer.

That’s my personal list of WordPress security tips, based on many helpful resources and my own experiences of getting hacked. These certainly don’t apply to everyone, more could be added, and your mileage may vary, but hopefully this will help others avoid some of the problems I encountered. Be sure to look at other people’s advice as well and watch out for any WordPress security news.

1 5 6 7 8 9 35