A thin line Between Challenge and Exploitation
Yet another 'challenge' of the form of 'break into our website for free, tell us exactly how you did it, and we might pay you a token amount' has been found on the web, only this time there were quite a number of serious holes found rather early in the process. Even though the main challenge still stands, there are sufficient concerns about the basic technological design to suggest that some of the currently-found problems will not ever be completely fixed.
The team behind Flickr-competitor SmugMug have issued a challenge to the wider web to break into their site and retrieve a specific image, along with the album it came from, and who uploaded it.
The first few people to take a serious look at the challenge soon discovered a couple of glaring problems:
- Firstly, the photo IDs are sequential, making it a relatively simple proposition to retrieve every image that has been uploaded and not protected correctly.
- Secondly, the system used to redirect direct requests for a protected image to the correct album and uploader, which allowed the early testers to grab a thumbnail version of the image (but not the actual image).
SmugMug's CEO, the person behind the challenge, has already taken steps to address the first couple of problems identified, though he does admit that the first problem came about because they did not understand GUIDs when they initially created the site. Retrofitting the site to use GUIDs instead of sequential IDs will break links that users have already passed on to others, unless the site silently converts the sequential ID into an appropriate GUID - though this has the net effect of no overall change. With this sort of design decision being applied, what other critical weaknesses have been designed into the system?
How does the site security actually work? That seems to be a closely held secret by SmugMug's site owners, but there are enough clues that a couple of simple requests can turn up. The image that SmugMug's owners want you to try and recover is http://www.smugmug.com/photos/248415594-O.jpg. Direct requests for this image will return an empty page, which suggests that something is being done on the server side to determine access rights for an image. Despite the claims of the CEO that steps have been taken to rectify the sequential image problem, it is still possible to access images and albums through sequential guesstimation, through URLs of the following form:
http://www.smugmug.com/gallery/album_id
http://www.smugmug.com/photos/photo_id.jpg
for albums and images respectively. What the site seems to prefer, though is the following form for accessing content:
http://user_name.smugmug.com/gallery/album_id#photo_id
This will load the SmugMug image and album viewer scripts, though there is still the occasional URL where it is
gallery/album_id/1/photo_id
Once the site visitor accesses an image through the SmugMug site, it applies a right-click prevention script that is meant to stop the theft of images from users who don't want them taken. The easiest method to bypass this step is to note the #photo_id URI component and then plug that photo_id directly into one of the above URLs for directly accessing content. A minor complication to this is the suffix that is added to images that have been directly requested, but that is simply decoded as follows:
photo-O.jpg - Original size
photo-M.jpg - Medium
photo-L.jpg - Large
photo-S.jpg - Small
A similar looking code is applied to images viewed through the main site, but in this case the -LB addition indicates that the image is being viewed through the site's LightBox feature.
Going back to the image that forms the core of the test, it is discovered that images 248415594, 248415595, and 248415596 can not be directly requested, though there are others before and after them that can. This suggests that they belong to the same album, and have been protected through the use of the password function in the user's account.
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.
Through simple testing, it is apparent that SmugMug sniffs for authentication, even on direct requests for an image file (i.e. .../blah.jpg), and it is the presence of an authentication token that determines whether a file that is protected should be displayed. This authentication token only really takes effect for images that are otherwise password protected. Through the main site, this authentication is backed up by the cookie that the site has set, but when direct image requests fail it points to some server-side IP-based filtering and authentication management taking place. This could be leveraged if a number of users are accessing the site via a single gateway, as an unauthenticated user could make successful direct requests for images belonging to authenticated users behind that gateway that otherwise would be password protected, though the use of a different User-Agent seems to be enough to fail.
Leveraging already-existent XSS vulnerabilities could allow a motivated attacker to create an attack that would extract all of the password protected images belonging to a user (once a user has logged in, direct requests for protected images are possible). The heavy reliance on JavaScript for site functionality makes it impossible to avoid through the disabling of JavaScript / Active Scripting.
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.
All this for $1000 USD, now $599.99 USD (thanks to taxes)? Competitions might be fun, but this sort of weak reward borders on exploitation, though it is voluntary exploitation. Considering the above was found after a little bit of idle poking around, the motivated individual is probably going to find a number of vulnerabilities that promise greater reward.
If or when the SmugMug site owners read this, there are two options:
- Ignore the valuable advice you have received up to this point, and gain security from the voluntary exploitation of the honourable (the dishonourable will not have made it public).
- Make it right. Pay someone to sit down and conduct a thorough review of your security, from both the design and implementation perspectives, and retain them to provide ongoing services to protect your site and its users.
5 February 2008
Social bookmark this page at eKstreme.
Alternatively, Bookmark or Share via AddThis
Do you like how we cover Information Security news? How about checking out our company services, delivered the same way our news is.
Let our Free OS X Screen Saver deliver the latest security alerts and commentary to your desktop when you're not at your system.
Comments will soon be available for registered users.
Subscribe to our feed.
