MySpace Private Pictures Leak

Martin writes "We all heard about the MySpace vulnerability that allowed everyone to access pictures that have been set to private at MySpace. That vulnerability got closed down pretty fast. Unfortunately though (for MySpace) someone did use an automated script to run over 44,000 profiles that downloaded all private pictures which resulted in a 17 Gigabyte zip file with more than 560,000 pictures. The zip file is now showing up on popular torrent sites across the net."

You know what to do...

[grub]

fetch! [thepiratebay.org]

Re:You know what to do...

[JeepFanatic]

If you read the wired interview, it says:

DMaul: The script that I wrote uses the myspaceprivateprofile.com interface to find the images. Therefore, it uses the same criteria. From my own testing, it appeared that myspaceprivateprofile.com did not return public images from public profiles. It only returned public images from private profiles. It did not return private images from either public or private profiles.

So ... I'm guessing the really good stuff isn't there.

Re:Anyone know what the vulnerability was?

[Stavr0]

Looking for technical details... anyone?

Having not read TFA or anything about this, let me venture some educated guesses:

- The URI for the pics are based on a timestamp
- The URI for the pics are based on a sequential number
- ... a combination of the above
- The pics are not access-controlled in any other way than not being listed on a user's page

The hack was discovered when a user cut and pasted the URI of one of his private pictures, noticed one of the above and attempted to change a digit of the URI, then automated the process with a garden variety for() loop.

Crappy analogy: Even unlisted telephone numbers can be discovered by telemarketing wardialers.

Re:You know what to do...

[ArsenneLupin]

Unusually intelligent dog.

Most other dogs attempt to fetch no matter what you throw: sticks that are obviously too heavy to fetch, snowballs, small objects which you only pretend to throw but actually hide inside your sleeve...

Lotsa phun...

Re:It bears repeating:

[snarfies]

1) Money put in the bank is insured. FDIC and all that.
2) Money put in the bank is physically guarded. A robber would have to put life and limb on the line to get at it.
3) You can't identify me or anything about me from my money. Its just a pile of green paper.

NOTHING online is insured. And the hackers on steroids from Ebaumsworld are anonymous, so there's pretty much no risk to them haxing your shit.

Link at Pirate Bay

[Anonymous Coward]

This seems to be the torrent that is being discussed:
http://thepiratebay.org/tor/3985864/%5Btribalwar.com%5D_567_000_private_myspace_pictures [thepiratebay.org]

Re:Trap!

[jandrese]

Yes, I'm sure he programmed it in the easiest way possible just to avoid child porn charges... That's defiantly the most plausible explanation.

Re:Trap!

[Jarjarthejedi]

Mod Parent Up for best use of a humorous sad but probably true prediction :P.

Archiving != compression

[upside]

1) There's a subtle difference between archiving and compression
2) You can use zip with no compression for plain archiving
3) Since tar isn't that popular on Winblows it's pretty natural to use zip instead

There are plenty of benefits to using an archive
1) integrity checks
2) directory structures
3) single file vs thousands
etc

Re:Trap!

[AuMatar]

Prediction? Hell, its already happened.

Re:A 17Gb zip???

[urcreepyneighbor]

The torrent (myspacepicstorrent) is ~17.5GB. The torrent contains 17 zips:

0.zip, 1.zip, 2.zip, 3.zip, 4.zip, 5.zip, 6.zip, 7.zip, 8.zip, 9.zip, a.zip, b.zip, c.zip, d.zip, e.zip, f.zip - The pictures, or so it seems. Haven't downloaded the pictures, yet. Each zip is ~1GB.

html.zip contains html files that link, supposedly, to the original pictures. It's ~30MB.

Out of sheer curiosity, I viewed the source of a couple of the html files - wanted to see if they contained any friendID's or anything else that could link the pics to the user.

The links do not contain a friendID or anything else that would tie the picture back to the user. Unless, of course, there is a rainbow table floating around that contains the hashes of the pics and the associated friendID's?

The html files, however, do contain FriendFinder spam. (iFrame, of course. pid=g872417-pmem, if anyone cares.)

Sorta stoopid, if you think about it. All the authorities would have to do, if they are interested, is contact FriendFinder (or the parent company[1]), and get the contact details for the affiliate.

Anywho. I hope this answers the size comment. I'm sure every prevert from here to China is part of the torrent's swarm. :)

[1] I don't know if FriendFinder is an indy company or owned by someone else. I don't even care enough to visit the site. Sorry. I'm tired and I've got a toothache. :P

I've looked. Yaaaaawn.

[jridley]

I downloaded the first zip, which is the first GB of images. I unzipped it, and I looked at the first 4500 images before falling asleep. 999 out of 1000 are crappy cellphone pics of ugly people drinking a beer and flipping off the camera, or vacation pics, or pics of someone's crappy car, or just simply snapshots of people (the vast majority).
So far out of 4500 images, I found exactly zero images that I think anyone would give a crap about. I'm not even sure why the vast majority of them are even bothered marking private; nobody would care about them at all.

Static Content Server

[TheNinjaroach]

Myspace appears to use a static content server that does no validation of who you are before returning JPGs.

When not working or browsing Slashdot, a friend and I will exchange URLs to profile pics of "interesting" looking women. If the profile is private, the URL to the private JPG is not protected and we would exchange those instead. I haven't spent any time trying to find a pattern in the seemingly-random JPG names, so it appears difficult to pull the private images of any one person, but in general everyone's pics are available if you know the URL.

Re:You know what to do...

[Meneth]

Let's have a link to TPB description/comments page. [thepiratebay.org]

Re:Trap!

[corsec67]

It is really easy to predict something that has already happened [news.com].

Re:Dueling compression algorithms

[_xeno_]

In case you're new at this: a torrent file can contain more than one file, organized unto subdirectories. There's no need for any encapsulation.

Sure there is. Ignoring the way BitTorrent actually encodes the information, and assuming that somehow every file name could be stored as one byte (ignoring the obvious flaw with that), by keeping all of them at the torrent level you'd require "more than 560,000" bytes just devoted to file names. Since the general rule of thumb is to keep the actual .torrent file around 100KB, give or take, that's right out.

Now, throwing in the way the .torrent file actually stores the list of file names, you're looking at at least 21 bytes per file. Assuming 560,000 files, that bloats the .torrent file to over 11.2MB - and that's still not realistic, because it requires every file to be less than 10 bytes in size and all of them to have empty path names. (Which is obviously not valid.)

Throw in realistic constraints, and you're adding another 15 bytes, bringing us to a total of 36 bytes per file - bloating the .torrent to 19.2MB, just for file names.

So, in short, the reason to place them in a ZIP file and not use the multi-file feature is because using the multiple file feature would massively bloat the .torrent file. Now the final .ZIP file has similar requirements per file in the ZIP file, but that becomes payload as part of the BitTorrent download and not something that has to be downloaded via non-BitTorrent means first.

Finally, for an explanation of where those numbers above come from, the "smallest possible" form for a file would be:

"d6:lengthi0e4:pathlee" (21 bytes)

The "more realistic constraints" brings that to:

"d6:lengthi100000e4:pathl8:0000.JPGee" (36 bytes)

Yes, the .torrent file is essentially "plain text" although the piece hashes are stored as binary strings. It's encoded using "Bencoding [wikipedia.org]" - which isn't the most compact of formats.

Submitter should RTFA, bug was known for months

[infestedsenses]

From the summary:

We all heard about the MySpace vulnerability that allowed everyone to access pictures that have been set to private at MySpace. That vulnerability got closed down pretty fast.

No it didn't. MySpace let this thing go on for months. From TFA:

The MySpace hole surfaced last fall, and it was quickly seized upon by the self-described pedophiles and ordinary voyeurs who used it, among other things, to target 14- and 15-year-old users who'd caught their eye online. A YouTube video showed how to use the bug to retrieve private profile photos. The bug also spawned a number of ad-supported sites that made it easy to retrieve photos. One such site reported more than 77,000 queries before MySpace closed the hole last Friday following Wired News' report.

The irony (and scandal) is that they not only failed to uphold their privacy policy despite being in the public spotlight over the last 2 years precisely for privacy issues, but that they didn't bother to acknowledge or fix this bug until a high traffic site reported on it.

Re:Dueling compression algorithms

[Kayyham]

I didn't realize .zip compresses each file seperately [wikipedia.org]. I would have expected it to be able to optimize the compression across multiple files (which would net a better compression ratio than doing each file seperately).

Re:Trap!

[Anonymous Coward]

Yeap--I read about a case in PA a few years back--the girl was 15 or 16 and took a topless on the webcam. They not only charged her with production of CP--but charged her as an adult and forced her to register as a sex offender!

Re:Trap!

[ILuvRamen]

there's like 7 determinations always used to test if it's pornography in cases involving minors. The major ones are what part of the picture is the focal point of attention, what actions are being depicted in the pictures, how old does the person appear to be, what the intention of the picture was (education or arousal), release environment context, etc. So yeah that's the big art vs porn determination courts use. Call me a pessimist but somehow I think it's not 100% art being uploaded by kids to myspace.

Re:Trap!

[AuMatar]

http://netscape.com.com/Police+blotter+Teens+prosecuted+for+racy+photos/2100-1030_3-6157857.html [com.com]

Forgive me, but I didn't want to google child porn at work.

Re:I've looked. Yaaaaawn.

[Anonymous Coward]

any good BT client has the option of specifying the priority or order of download for the files that make up the torrent. Once the individual file you want is finished, you can open it, while the other files are still downloading.

Re:Dueling compression algorithms

[marcansoft]

The torrent itself - as in the peer to peer data transmission - is done at a piece level and the stream is logically equivalent to concatenating all files and transmitting them as a whole. Obviously, this never happens at a filesystem level. However, even though the actual filesystem data is split into files, the logical stream that is what gets shared is effectively the result of the concatenation of all files (this happens in real time: when someone requests a piece, it is done by position in the "whole of the torrent" and then the client determines which file(s) it has to read to find the data). The point is that there is no internal fragmentation on the transmitted data: (essentially) the exact same number of actual data bytes will be transmitted whether you split the torrent into files or tar it up into one big file (assuming no compression for the tar and ignoring overhead for it). It's not like downloading files over HTTP where there is an overhead per file. The bittorrent wire protocol doesn't even know about the existence of multiple files.

This is why if you download a single file out of a torrent, you will often get a certain percentage of the previous and following files completed even though you never checked them for download: the edges of the pieces weren't aligned with the file boundaries. If you uncheck, say, a "downloaded from foo" txt file, more often than not you'll get it anyway (the client stores the file anyway because it needs to store that portion of the block to be able to upload it to peers, since blocks are sent as full units).

The .torrent file is a separate issue, and it can get large with large amounts of files. However, it's not like you're saving bandwidth: the file names and info will just happen to be inside the rar files (as part of the rar format), instead of the torrent file, but you'll still have to download them. Having them in the rar files is arguably a better solution in this case, since it keeps the .torrent file small and transmits the relatively bulky file list over BT, but that's a different issue.

Review of Part 1 (1GB out of 17)

[Anonymous Coward]

After waiting an eternity to get this thing downloaded (one of the slowest torrents I've grabbed... and over a thousand seeders! not sure whats up there) I have a review from zipfile 1 (of 17 files included)

approximately 5000 photos
70% - make you wish Kodak didn't bring photography to the masses
45% - angsty emo poses
25% - alcohol-related potentially embarassing photos (if you knew who these people actually were)
0.5% - nudity (one topless woman, several artistic nudes, a few pregnant women)
2% - people showing off bruises or injuries
30% - pets
1 - fetal ultrasound
4% - people sleeping
7% - anime, cartoons, photoshopped artwork
10% - cars

(Sum exceeds 100% because of pics like the shirtless drunken emo guy with his puppy)

Lesson: If you want scandalous amateurs, go to xtube.

(That won't stop me from getting the rest of the torrent and seeding till you get your fill, though!)