Tag: SmugMug.Com

A couple weeks ago I mentioned the security problems that had been discovered in photo sharing site SmugMug.Com, which were exacerbated by SmugMug.Com CEO Don MacAskill’s arrogant response to people who bothered to point out the problems with his company’s security model.

In response to the publicity across the Internet, MacAskill issued a challenge — he would pay $600 to anyone who could access a specific image secured by his service. This was a convenient challenge because the security hole didn’t have to do with being able to access a specific arbitrary image. Still, Sunnet Beskerming has written an interesting analysis of SmugMug’s security model for protectiong images like the one that is part of the challenge. And his conclusions are not encouraging for anyone still using SmugMug,

Disturbingly, it is only through the use of the password that a user can protect images from viewing. Any other choice of setting will still allow direct request of both images and albums. It is also apparent from random test selections that there is a loose correlation between album ID and image ID. Basically, the newer an album, the newer the images are that are in it. Using this approach, it is possible to establish a bracket of likely album IDs that have an image of interest, even if they are password protected and the image can not be directly accessed.

It is here that another unexpected weakness arises. Despite all the steps taken to protect the album name and user name, the page title helpfully announces both of these details when a request is made for a protected album.

Beskerming also postulates a different attack — rather than retrieving a specific user’s private images, what about making it appear as if the user is hosting an image that is in fact not in his or her albums,

To make matters worse, it is possible to spoof image origination, which could be used by someone with a malicious anonymised account to blackmail or harass legitimate account holders. By manipulating the URL, it is possible to load any non-password protected image in any non-password protected album. Passing a URL of the following form to a victim will make it appear that they have a malicious image (what sort of content that is is left to the reader) in their legitimate album:

http://victim.smugmug.com/gallery/legit_album_id#malicious_photo_id

If this URL is passed to others, it would appear that the malicious image has been placed there by the victim, while there is no way to determine who placed the malicious image on the site in the first place (though SmugMug should be able to work that one out). If such a URL held referenced an image of illegal content, the implications for the victim are significant, especially if it is passed to law enforcement agencies or those with limited technical knowledge.

So, for example, one of the non-password protected images that was exposed in the initial wave of reporting about SmugMug was a picture of a woman reclined on a bed. Using Beskerming’s technique, a savvy hacker could e-mail my wife a URL that would appear to show that image as part of my non-password protected SmugMug album.

As Beskerming concludes, what SmugMug needs to do is dispense with the silly challenges and pay someone to audit their security. Moreover, they should bite the bullet and transition to GUIDs even though that might break the URLs that some users have used to give family and friends access to their pictures. I know I would much rather receive an e-mail from a company saying, “we’ve discovered a serious security hole that has to be plugged now, and as a result all of the URLs will change” rather than instead wake up one day and find what I thought were my private pictures littering the Internet.

Philipp Lenssen of Google Blogoscoped created a mini-storm this week when he discovered a major security hole in the way photo-sharing site SmugMug.Com implements its privacy settings for photos people have uploaded to the site. Unfortunately, SmugMug’s reaction so far has been very…well…smug.

People who post photos on SmugMug want to be able to share their photos with friends but not necessarily share them with the entire Internet. Moreover, they don’t necessarily want to have their friends to know a username, password, etc. So SmugMug has a “privacy” setting which doesn’t require a password but does require someone to have the exact URL to the photo being shared.

This is not a bad idea, especially if done with a Globally Unique Identifier. With a GUID, each photo would have an arbitrary identifier in the URL that would be very difficult to guess or brute force. But, as SmugMug’s CEO confesses, they didn’t know what GUIDs were when they first started SmugMug, so they didn’t use them.

Instead, SmugMug uses the incredibly stupid system of simply starting at 1 and incrementing up for all its photos and galleries in the form

http://smugmug.com/gallery/1000

http://smugmug.com/gallery/1001

…meaning it is trivial to write a script to crawl the site and easily view any and all “private” photos on the site. According to Jensen, there are other security problems that make it possible to view even some password-protected photos and galleries at SmugMug.com

SmugMug’s response is basically a) users of SmugMug aren’t complaining yet, b) implementing GUIDs would be expensive at this point, and c) using this method you can’t get at specific photos.

I’m not surprised that SmugMug users aren’t complaining yet, but I wonder how happy they’d be if they knew that, say, that “private” photo taken in a hotel room posing with lingerie is easily downloadable by anyone with enough patience (and most users seem to have their names on their galleries, so it wouldn’t be too difficult to download all of John Doe’s embarrassing pictures and then post them elsewhere on the Internet and associate the pictures with the individual who posted them). And all this from a site that trumpets it is “Safe and secure” on its front page pitch.

Definitely a service to avoid.