Day: February 7, 2008

Lousy Security from Phone Conferencing Companies

The other day I was assisting a group that needed to attend one of these “webinars” where we’re projecting a laptop onto a screen while we’re listening to a speaker over a POTS line. As the e-mail from the company sponsoring the webinar suggested, I dialed in about 20 minutes before the conference started to test, etc.

Except I wasn’t dumped into the conference I was supposed to be in. Instead I was now participating in some sort of briefing between salesman at a company that provides services to a number of large insurance companies. The salesmen could not hear me and were apparently completely unaware of my presence as they discussed the best approach to take with a particular client, and one chimed in with a list of things not to say during another.

Finally at the appointed time my call was supposed to start, the salespeople all hung up and the person from the company I was conferencing with was added to the call.

Now typically the security for these calls is you have to call a phone number and then enter an arbitrary number that corresponds to your particular call. So there are likely two possibilities for the mishap.

First, the people at the conference company could be complete morons and use a single ID # for a single conference slot and then give that conference ID out to different people, assuming they won’t call in outside their normally scheduled time.

Another possibility is that the algorithm the company is using to generate conference ID # is flawed and doesn’t generate truly unique IDs. One of the things I noticed is that with most audio conference companies I use, I typically get a 9-12 digit code for the conference, whereas these folks only used a 6 digit code which struck me as kind of odd.

Regardless if it was something like this or something completely different, this sort of thing is completely unacceptable and should never happen. I had never used this particular company before and certainly will warn other people in my organization about them.

Given how important security is in third party hosted audio/video conferencing, its surprising how cavalier some companies are about security.

SmugMug Re-Visited

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.