February 22nd, 2010 | Author: theharmonyguy | Tags:

I’m happy to make several announcements today. First, I’ve long felt this blog had a rather staid design that needed upgrading. Over the last several weeks, I’ve worked on putting together the new look you now see at theharmonyguy.com. I went ahead and brought the theme live, but I still plan on making further adjustments to the code, so I’d ask for patience as the site developers. Thanks to Elegant Themes for providing the basis of the new design. I have some ideas for further updates to the content of this site to match the theme change, but those will have to wait until later.

Second, I’d like to introduce myself. I’m known to many online as “theharmonyguy,” a screen name that goes back many years for me. Using it as my moniker for writing about security research was a split-second decision when TechCrunch covered my first major “hack” in 2007. Part of my decision came from wanting to keep my hacking endeavors separate from other development projects I had in mind back then. More recently, though, security research has become more than a small hobby, and I think it’s time to shed the anonymity. While I’ll continue to use “theharmonyguy” as an online identity, my real name is Joey Tyson. I graduated from Wake Forest University last year with a masters degree in mathematics, but I’ve spent several years working in IT consulting and web development prior to my career as a hacker.

And that brings me to my third announcement. I’ve officially joined the team at Gemini Security Solutions in Chantilly, Virginia, and look forward to starting work with them in March. A big shout-out to the Liquidmatrix Security Digest for the job posting that led me to Gemini. I’m excited about serving Gemini as they provide quality information security consulting to other companies. Also, I’ve been graciously allowed to continue this blog and my personal Twitter feed with the caveat that they don’t interfere with my work duties. Please note, however, that everything I post here is my own perspective and does not in any way reflect on my employer.

Over the next few weeks I’ll be moving to a new state, adjusting to a new area, and getting settled in a new job, so I may not be posting as frequently during the transition. But I still plan on maintaining (and perhaps expanding) both this blog and my Twitter feed for the near future. Thank you so much to all my readers for your help and support!

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Comments Off
February 15th, 2010 | Author: Tom | Tags: , , ,

I always thought the Facebook Application for BlackBerry was a buggy, slow piece of junk.  Now I have noticed that this application is being abused by spammers to propagate Viagra and Percocet SPAM.  The screen shot to the right is an actual Facebook notification I received on my BlackBerry.

There seems to be an interesting bug in the Facebook Application for BlackBerry in which a spammer can spoof the “facebookmail.com” domain to have SPAM messages show up in your notifications list within the BlackBerry Facebook application.  This only works if you have the Facebook for BlackBerry Application installed AND you have an email account configured on your BlackBerry (yes, this includes a corporate email account as well).  The email account you have configured on your BlackBerry is where you actually receive the SPAM message, not through Facebook.

The Facebook Application for BlackBerry appears to notify on any new email in one of your BlackBerry mailbox’s with “*.facebookmail.com” in the sender or return-path field.  This is a win for the spammer because now you think Facebook is spamming you and with the addition of an email, you’re more tempted to click on the link.  The Facebook Application for BlackBerry is no stranger to controversy and this particular bug has been noticed recently by others as well.  It also appears that this bug only affects the BlackBerry Facebook application.  When testing the iPhone app I couldn’t replicate the issue.

To test this bug I used EXIM4 in Ubuntu as a mail relay with mailtools to send the email.  This allowed me to send a spoofed email as “agent0×0@facebookmail.com” to one of the email accounts I have configured on my BlackBerry.  Here are screen shots of the spoofed email in my inbox and what it looks like in the Facebook Application for BlackBerry:

My opinion is that a mobile Facebook application should never be polling your personal email for these messages…but then again this could be a “feature” of this nicely designed application, right? :-) Special thanks to Kevin Johnson for helping with some of the research/testing.

Comments Off
February 12th, 2010 | Author: Tom | Tags: , , , , , , , , ,

This is the 10th episode of the Social Media Security Podcast recorded February 8, 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!

 
icon for podpress  Social Media Security Podcast 10 [33:25m]: Play Now | Play in Popup | Download
February 12th, 2010 | Author: theharmonyguy | Tags:

I’ve discovered another trick that may surprise some, this time relating to Google’s services. I don’t view the issue as a vulnerability, but it likely goes against user privacy expectations. In short, having a public Google profile (which you might have created when checking out Google Buzz) can allow others to figure out your Gmail address.

This really shouldn’t be that surprising, given that your username is generally consistent across Google services, and a public profile is public. But those who currently have numeric profile addresses (e.g. http://www.google.com/profiles/104424237445852766735) might think their profile is not easily tied to their username.

But by using Picasa, Google’s photo sharing service, it’s often quite simple to go from a numeric profile address to an actual username. To protect yourself from this access, visit the Picasa settings page.  Under “Your gallery URL,” add a new username and select the new username for your gallery URL. Also, you may want to edit your nickname.

In my testing thus far, it matters little whether you’ve used Picasa before – if you have a Gmail account, Picasa is also enabled on your account. And while individual Picasa albums have privacy controls, I have not found a way to block simply loading your Picasa home page.

With the introduction of Buzz, Google is encouraging users to take advantage of Google profiles. But in the process, Google is tying together services that many users may have treated quite distinctly in the past. If you want your Gmail address to remain private, you need to manage properly the other Google services you use to avoid one of them exposing your Gmail username.

Update (Feb. 13): It appears Google has adjusted their services to prevent the original URI trick from working. Previously, adding a profile number to picasaweb.google.com (e.g.  http://picasaweb.google.com/104424237445852766735) would either load a page with the username visible, the username embedded in the page’s source code (_user.name in JavaScript), or an error page in a few particular instances. One configuration that would simply produce an error page was if you had Picasa setup under a different username than your Gmail username, hence my advice. It now seems that using a numeric Picasa URI will either load an error page if the user does have Picasa setup or a page indicating the user does not have Picasa galleries but with no username anywhere in the page.

I’ve already done some preliminary testing to see if Google Reader could also be used to discover usernames, but so far that does not seem possible. Still, it’s wise to be cautious when using a tool that interacts with so many other services.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Comments Off
February 9th, 2010 | Author: theharmonyguy | Tags:

In yet another example of security through obscurity, Facebook modified their platform last July to prevent applications from accessing public photo albums for users that were not friends of the logged-in user. Facebook had previously said such applications did not violate the site’s privacy policy, since the behavior followed photo album privacy settings – applications could only load albums marked as visible to “Everyone.”

But “Everyone” is the default privacy setting for photo albums, and many users probably don’t mean for everyone to see their photos. As a CNET report noted:

A Facebook spokesperson said the company made the change so the technology more closely matched users’ privacy expectations.

“We made this change in order to ensure that users who have their profiles set to a privacy other than ‘everyone’ are not surprised by photos being exposed through the API,” Facebook engineer Matt Trainer wrote in response to complaints on the developer forum site.

In other words, Facebook introduced inconsistent application of privacy settings (are the albums available to everyone or not?) so that users would continue to believe a false representation of who could access their content.

Fast forward to 2010, as Facebook users grapple with revamped privacy controls, new default settings, and the general introduction of “publicly available information,” or PAI. With the announcement of PAI, Facebook removed users’ ability to control access for certain bits of information. Among the data now included in the PAI category: the list of your Facebook friends.

That particular change riled many critics, and Facebook eventually backpedaled a bit, allowing users to remove friends lists from their profiles. But the company made quite clear that your list of friends was still considered publicly available information. With this behavior, Facebook setup a strange distinction between permission and visibility. Everyone was technically allowed to see your friends list, but had no means to do so if you removed it from your profile.

Of course, it wasn’t long before someone discovered a “means to do so.” In December, I posted a simple trick that would reveal the names and profile pages of any user’s friends, regardless of whether they blocked such a list on their profile. I try to follow principles of responsible disclosure with security vulnerabilities, but in this case, my “hack” in no way violated or worked around Facebook’s stated privacy policy, since friends lists were now public.

But the other day, I tried using my trick once more, and noticed that it no longer worked for users who chose to hide their friends lists. I’ve also found that issuing an FQL query for the friends list of a user beside the currently logged-in user fails – I don’t recall precisely the behavior of such a command back in December.

Oddly enough, Facebook has yet to block my trick for viewing a user’s public photo albums, which avoids last July’s changes as it does not involve the Facebook API.

It seems Facebook wants to have their cake and eat it too – give users the impression they still maintain control over their data, but still classify the data as public if circumstances warrant. Personally, I think it better for the company to treat “public” information consistently so that any user surprises come now and not later when people discover other means of accessing content.

By the way, a simple adaptation of my photos trick lets you discover a user’s full name based on their profile ID (which, by the way, is included in the filename of every photo you post – and that filename may be maintained if you upload the photo to sites such as Twitter), regardless of their profile privacy. (Some users restrict access to their profile, so trying to load it directly or request their name via the Facebook API Test Console would fail.) Is this new trick a violation of user privacy or a demonstration of “publicly available information?”

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Comments Off
January 30th, 2010 | Author: Tom | Tags: , , , , , , , , , , ,

This is the 9th episode of the Social Media Security Podcast recorded January 26, 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!

 
icon for podpress  Social Media Security Podcast 9 [42:08m]: Play Now | Play in Popup | Download
January 30th, 2010 | Author: theharmonyguy | Tags:

You have ten seconds to spot the problem in the image below. Ready? Go!

Example of ESPN's "Report a Bug" page

I hope you spotted the problem right away, as it’s a classic example of a cross-site scripting hole. The page mentions that the report will reference a particular URI, and that address also appears as a parameter in the page’s URI. As you might guess, the parameter is not being filtered, allowing one to insert any HTML code.

I found it rather ironic that I came across this problem as I was looking for a means to contact ESPN about two other XSS holes. All three issues were reported to ESPN back in late November, then reported again via different means earlier this month. After receiving no response to either report, I decided to go ahead and release this hole publicly.

By the way, I realize some of my posts about XSS issues aren’t directly related to social networking sites and thus diverge from the usual fare on this blog. However, I think they can serve as important lessons for all developers, including those building social networking applications. This sort of vulnerability is exactly the type that leads to FAXX hacks in Facebook applications. And perhaps it will serve as some comfort to smaller developers that even large sites are susceptible to such problems. Anyway, I also think it’s important to record these finds for future reference, and this blog is about the only place I have to do so.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Comments Off
January 23rd, 2010 | Author: theharmonyguy | Tags:

It’s easy to assume that when it comes to data and software development, “open” is always better than “closed.” We’ve seen an explosion of open source software, praised companies for supporting open standards, and breathlessly tracked products with “open” in their name, from OpenID to OpenSocial. “Closed” has become the scarlet letter of the Internet, at times expressed by the censure of being branded a “walled garden.”

Facebook has often faced this criticism, particularly after unveiling the Facebook Platform in 2007. Several bloggers compared Facebook unfavorably to AOL of yesteryear, eschewing Facebook’s “proprietary” (gasp!) FBML and FQL interfaces. Some even portrayed Facebook as a competitor to the Web itself. While the definition of “walled garden” was not always particularly clear, observers were unhappy with so much data flowing into Facebook and so little flowing out.

One would think that now, with the Facebook API able to expose your wall, News Feed, inbox, and just about every bit of profile data (even e-mail addresses to some degree) Facebook would be allowed in the open club. Indeed, some writers have noted changes since 2007 that justify dropping the dreaded horticultural moniker. But others continue to speak worriedly of Facebook’s dominance, even still drawing comparisons to AOL.

I, for one, not only have full confidence in the Web outlasting any supposed competition but also see Facebook as very much a part of that resilient network. In fact, I’d like to propose a bit of Internet heresy by according walled gardens a place among the open fields of the online realm.

First, let’s establish one fact: Facebook has always been part of, not opposed to, the Web. Disregard ridiculous arguments over FBML and FQL, which were no more of a threat to HTML and SQL than Smarty and WordPress template functions. Open any Facebook application, choose to “view source,” and all you’ll see is good ol’ HTML, CSS, and JavaScript. The Facebook Platform allowed developers to build on top of Facebook, just as Movable Type and Joomla allowed developers to write plug-ins using Perl and PHP. (Differences: you could not roll your own Facebook, Facebook essentially installed every plug-in, and you have to host the code.) That Facebook disallowed certain HTML security risks and added a few convenient tags for interfacing with their content in one approach to development (one could always write full-blown HTML using canvas iframes instead of FBML) hardly meant they were reinventing Web standards.

Technical considerations aside, some writers argued that Facebook opposed the Web in spirit – more specifically, the spirit of openness. Even though Facebook applications (and inverting Facebook’s criticized original setup, other web sites via Facebook Connect) have wide access to Facebook data now, average users still face hurdles if they wish to view posts and information from other Facebook users. At minimum, one has to create an account and login to Facebook to see beyond bare basics. Prior to recent privacy changes, access to content from non-friends was highly limited even after logging in. And while some of Facebook’s data should start appearing in search engines this year, very little has been indexed by Google so far. As I said before, users generate much content within the context of Facebook, but that context usually remains locked away from public access.

Before I respond directly to such charges, I’d note that Facebook (or any social networking utility) serves a limited purpose. Did you catch that? Facebook serves a limited purpose. Facebook was never meant to duplicate the Internet. If I need reference material on world history, I might turn to Google or (as a starting point) Wikipedia. If I want to know the latest technology news, I can bring up Techmeme. If I want to catch up on a favorite TV show, I’ll probably load Hulu. None of these tasks have any inherent social component that would cause me to first open Facebook when fulfilling them.

Last summer, however, I wrote a series of articles on particular doctrinal issues that affected certain people in churches and organizations I’ve been a part of. I’m not ashamed of my opinions, but they involve points that would not make sense to someone who did not have the background and context of the limited audience I had in mind when writing. Consequently, I would prefer such musings did not appear in the Google search results of an acquaintance unfamiliar with my topics. I shared my thoughts with certain friends via Facebook Notes.

I have friends who live several states away that wish to keep me and others posted on life in their growing family. They want to share what adventures their children are having with extended family across the country. Friends desire to see how they’ve decorated their new home and exchange tips on managing it. Rather than open themselves to potential hazards of their house and kids being featured in an image search, my friends can use Facebook’s photo albums to control who can observe their daily life.

These are but two use cases out of a hundred or more that (1) inherently involve a user’s social graph and (2) inherently involve content not intended for public consumption. To argue that Web-based services other than Facebook could provide similar functionality in an open context misses the point. Yes, I could have published my articles with Blogger, my friends could post their photos on Flickr. But these particular examples are not simply about sharing ideas and pictures – they involve sharing ideas and pictures with certain people.

Are you dissatisfied with Facebook limiting access to content? That’s where the rest of the Web (again, Facebook is one part of the Web) comes in handy. If you’re a blogger who wants the world to hear your thoughts, forget Facebook and start a blog. If you’re a photographer who wants to advertise your portfolio, forget Facebook and use a more open service. If you’re looking to interact with a small subset of the world, however, a walled garden may be just the thing for you.

Of course, these days Facebook’s leadership may cringe at my last paragraph, as they seem to be taking a new angle on their service’s purpose. But a few years ago, privacy and control (in essence, the very things that made it a “walled garden”) are what distinguished Facebook from competitors. Personally, I have trouble buying Mark Zuckerberg’s story that “if he were to create Facebook again today, user information would by default be public” (ReadWriteWeb), as such a site really wouldn’t have been much on an innovation. Recall that prior to Facebook’s rise, MySpace dominated social networking sites, and many (if not most) MySpace profiles were publicly accessible. Limitations are what made Facebook novel – originally, only college students were even allowed to create profiles on the site, and all profiles followed a strict layout.

In my experience, friends flocked to Facebook because it let them participate in new technologies (sharing digital photos, for instance) but in a controlled environment where they could enjoy a level of privacy. The garden walls were selling points – college students didn’t want just anyone seeing their photos and messages; later on, parents didn’t want their teenagers communicating with just anyone. I think that’s partly why Facebook’s recent moves encouraging users to share more openly generated such controversy. Users felt they had fallen victim to a “bait and switch” scheme: they invited their friends to use Facebook so they could share privately, now suddenly Facebook has forced them to share certain information and is pushing them to share the rest.

It’s also worth noting that in its early days, Facebook offered little functionality that couldn’t be found elsewhere. The notion of a profile, the ability to send private messages, the exchange of ideas centered around certain topics – all of these features were hallmarks of forum sites for years. But while the members of a forum formed a particular social graph centered around a certain niche community, Zuckerberg portrayed a user’s social graph on Facebook as a mirror of their everyday, real-life connections. Facebook (and other sites, such as MySpace) took the features of forums and adapted them for a general purpose audience, where you essentially chose the members of your forum based on who you already communicated with offline.

This brings us back to Facebook’s limited purpose and why some of the hand-wringing over its “proprietary” nature strikes me as overreacting. For instance, back in 2007, Gervase Markham of the Mozilla Foundation expressed concern that the messaging system in Facebook or LinkedIn might turn e-mail into a closed system incompatible with outside domains – in short, a walled garden. But Facebook messages could never replace SMTP e-mail. If I want to interact with close friends, Facebook messages provide a convenient, hassle-free means of doing so. Yet if I need to exchange notes or documents with acquaintances, large groups, or even businesses, Facebook messages are hardly up to the task. Once again, such use cases do not involve my social graph. I think Facebook recognized this as they expanded and started trying to juggle multiple social graphs beyond a user’s closer friends, since messages from fan pages (essentially, communications for a business) are filed away in a folder quite separate from a user’s main inbox of messages.

All this being said, please don’t think I’m opposed to more “open” approaches to handling my social graph, such as distributed social networking – far from it. I think Facebook is still an early player in online social networking, and that we’ll see many more platforms and ideas develop in years to come. But I think we’re still a long way from a time where the open alternatives provide end users with more value than walled gardens in the types of use cases I’ve already outlined. As much as I’d like to see federated social networking platforms thrive, I foresee many hurdles that have yet to be overcome. Distributed networks will have to deal with issues relating to performance (imagine generating a news feed when your friends’ data comes from hundreds of different servers), retention (is data cached, how long, etc.), reliability (what happens when a few of your friends’ servers are down?), privacy (how will access be controlled and monitored), and security (avoiding injection attacks, ensuring all hosts stay up-to-date, etc.), not to mention monetization (a problem that still plagues closed systems). And when it comes to user value, remember that walled gardens have a few inherent advantages – in a security example, if Facebook detects a worm spreading malicious links via messages, they can block all messages with a certain signature or strip out links to a known rogue site.

I suppose my main point is that we need not be concerned if Internet users (even 350 million of them) find use for a service that strikes many technology-minded people as a walled garden. While the Internet was built on open, equal access, that very setup enables some services to provide certain features in a more limited context while still taking advantage of Web technologies. And for many people, these gated communities provide real value that would actually diminish if Google began indexing it all. While certain circles seem to think any notion of online privacy is at best naïve (and granted, some users need to exercise more caution in what they post online, regardless of what service they use), I tend to think that the only people saying privacy is dead are those named in its will. And when privacy does become a factor in sharing online, at times, a garden might need walls.

P.S.: Lest you think I’ve changed my opinion in light of recent privacy controversies, I’d note that I stated very similar thoughts back in 2007 when some of these debates over Facebook first developed.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Comments Off
January 21st, 2010 | Author: theharmonyguy | Tags:

I’ve demonstrated countless times over the past year that cross-site scripting vulnerabilities in Facebook applications can be exploited to make Facebook API requests on behalf of the application. This type of attack, which I called a FAXX hack, enables one to not only post links to Facebook for viral effects but also harvest a wealth of information on victimized users along the way, such as name, date of birth, interests, family members, photos, and so on. However, contact information lay outside the scope of available data.

Until now. Facebook has launched a new Platform feature that enables developers to request e-mail addresses from their users. An unfortunate side effect of this behavior is that Facebook applications have now become more promising targets for online attacks.

Over time, it’s likely that popular applications will routinely request e-mail addresses from users, meaning eventually certain applications could have millions of addresses saved. (Note that Facebook allows developers to store e-mail addresses indefinitely under this new setup.) One SQL injection hole could potentially compromise all of those e-mail addresses. Also, if the application had an XSS vulnerability, one could easily launch a FAXX attack that requests e-mail addresses from Facebook via FQL.

This certainly all depends on several factors, one being whether many users embrace sharing their e-mail addresses with applications. Some may question whether finding an exploitable vulnerability in a popular application would be likely, but based on last year’s Month of Facebook Bugs, I think the odds are not encouraging.

My recommendation to users would be against letting applications have your e-mail address; Facebook does provide a proxy system if you really want messages. But I do hope this new feature will bring more attention to issues of security on the Facebook Platform.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Comments Off

This is the 8th episode of the Social Media Security Podcast recorded January 8, 2010.  This episode was hosted by Tom Eston, Kevin Johnson 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!

 
icon for podpress  Social Media Security Podcast 8 [42:56m]: Play Now | Play in Popup | Download