backtop

Internet British Police Arrest OiNK Uploaders
Tom Corelis (Blog) - June 3, 2008 8:10 AM
Print E-mail del.icio.us 35 comment(s) - last by overzealot.. on Jun 4 at 11:43 AM
BPI hounds music leakers

Six OiNK users faced arrest late last month as part of “Operation Ark Royal,” a sting orchestrated by Cleveland, England police and the British Phonographic Industry (BPI) designed to crack down on uploaders who shared music with the late, private BitTorrent tracker.

According to police statements and an investigation by TorrentFreak, Cleveland Police arrested five men and one woman, aged between 19 and 33, on May 23 and May 28. Suspects were questioned on their relationship with OiNK and its founder, Alan Ellis, and were forced to provide DNA samples and fingerprints before being released on bail.

The BPI confirmed its involvement in the sting, telling The Register that it “provided the information” to assist the investigation, but refused further comment due to the fact that the case “is now a police matter.”

Those arrested appear to have been chosen because they had access to music CDs before release, and decided to share them with OiNK before the album’s street date in a process called “pre-releasing.”

“The illegal online distribution of music, particularly pre-release, is hugely damaging,” said the BPI. “OiNK was the biggest source for pre-releases at the time we moved to shut it down.”

According to TorrentFreak, two of the users arrested uploaded no more than a single album to the site.

OiNK’s status as the preeminent source for pirated music came to an abrupt halt last October, after authorities raided the site’s servers and arrested its owner, 24-year-old IT consultant Alan Ellis. The users arrested last month faced intense questioning on the nature of their relationship with OiNK and its owner, and investigators were reportedly extremely interested in their passwords. TorrentFreak thinks that this is strong evidence pointing towards the belief that key aspects of user data were “successfully” encrypted with a salted MD5 hash, thereby rendering passwords –and possibly other user data – nearly immune to discovery by investigators.

“The logs we store aren’t enough to incriminate users,” said Ellis in a previous interview with TorrentFreak, conducted days after the site’s takedown. It is unclear how investigators were able to divine the identities of the users arrested.

It is believed that the six users will appear before police on July 1st, which is the same day that Ellis is scheduled to answer his bail.

Cleveland Police refused further comment, although there appear to be more arrests in the future as all six users were released “pending further inquiries.”

Comments     Threshold


This article is over a month old, voting and posting comments is disabled
Nearly immune?
By chsh1ca on 6/3/2008 9:25:11 AM , Rating: 3
quote:
TorrentFreak thinks that this is strong evidence pointing towards the belief that key aspects of user data were “successfully” encrypted with a salted MD5 hash, thereby rendering passwords –and possibly other user data – nearly immune to discovery by investigators.

The only way this works is if the salt itself was kept secret and/or wasn't something obvious (like login id). If they procured OiNK's servers, chances are pretty good that they have the hashing algorithm, and from that they can generate rainbow tables. Then it's just a matter of looking up the MD5 hash. Each step in this process is relatively simple (albeit time consuming). Unless they were somehow able to destroy the salt and/or keep it out of the hands of the investigators, it's far from "nearly immune."




RE: Nearly immune?
By masher2 (blog) on 6/3/2008 9:38:57 AM , Rating: 3
If the salt is user-specific -- such as a login id -- a rainbow attack isn't feasible, whether or not the salt is known.


RE: Nearly immune?
By chsh1ca on 6/3/2008 12:13:18 PM , Rating: 2
quote:
If the salt is user-specific -- such as a login id -- a rainbow attack isn't feasible, whether or not the salt is known.

Why do you believe it isn't feasible?

As long as the algorithm is known and the salt is based on data available it is possible. The salt would need to be based on data available if this is part of the regular authentication process. It just requires generating the rainbow tables for each salt. It may be prohibitively expensive and time consuming, but this is the recording industry and its ilk, and they seem happy to throw thousands of dollars and time into pursuing this kind of thing.


RE: Nearly immune?
By masher2 (blog) on 6/3/2008 2:11:07 PM , Rating: 3
> " It just requires generating the rainbow tables for each salt. "

That's just the point. A Rainbow table trades time for space....a LOT of space and time. Non-salted tables require gigabytes of storage and take huge computational resources to generate. Adding a salt can move that to hundreds of gigabytes and more time...and that's per salt. If the salt is per-user, you now need to generate thousands of such tables.

Now we get to the crux of the issue. Even assuming you have the hundreds of petabytes to store these tables, you still have to spend the time to pregenerate them. And since each single Rainbow set is valid only for a single user, the time spent to generate the table + the time spent to run the attack is greater than a single brute-force attack against the password itself.

In short, its faster simply to try every random combination of password+salt, than to generate a rainbow table that will be used only for a single password.


RE: Nearly immune?
By TomCorelis (blog) on 6/3/2008 2:47:29 PM , Rating: 2
No, he has a point. Now that I think about it, if you have the decryption algorithm in hand, the salt can be rendered needless -- instead, you brute force the password via the site's authentication function -- I'm sure it'd be easy to isolate this into a seperate PHP/whatever script -- as opposed to brute-forcing the salt+md5 itself. It will still take a while, but with enough time, conceivably you could acquire at least all the simple user passwords. I am sure a basic dictionary+7 character brute-force attack would crack a sizable percentage of user data.


RE: Nearly immune?
By masher2 (blog) on 6/3/2008 2:55:03 PM , Rating: 2
No, if the passwords are salted before hashing, you're not going to be able to isolate either portion out for a separate attack.

"Feasible" in cryptographic terms doesn't mean merely possible, it means more efficient than a brute-force attack. If individual entries (passwords or whatever) each receive unique salts, a rainbow attack isn't feasible. Its still possible...but it would be far easier simply to brute force the result.


RE: Nearly immune?
By chsh1ca on 6/3/2008 3:23:32 PM , Rating: 2
quote:
No, if the passwords are salted before hashing, you're not going to be able to isolate either portion out for a separate attack.

"Feasible" in cryptographic terms doesn't mean merely possible, it means more efficient than a brute-force attack. If individual entries (passwords or whatever) each receive unique salts, a rainbow attack isn't feasible. Its still possible...but it would be far easier simply to brute force the result.

Masher is correct under the circumstances that a hash is done on a per-user basis and the algorithm itself is unique. If the algorithm is not unique, brute forcing will be faster for processing a single site, but possibly for processing multiple sites (depending on complexity) that utilize the same salting method, it will be reusable.

There are definitely some potentially better solutions, but they depend on the complexity of how the passwords are stored (information we don't have, or at least, I don't).

This actually only serves to further my point about the "nearly immune" wording, since we've now covered several ways in which this can be cracked.


RE: Nearly immune?
By chsh1ca on 6/3/2008 2:55:05 PM , Rating: 2
quote:
That's just the point. A Rainbow table trades time for space....a LOT of space and time. Non-salted tables require gigabytes of storage and take huge computational resources to generate. Adding a salt can move that to hundreds of gigabytes and more time...and that's per salt. If the salt is per-user, you now need to generate thousands of such tables.

Salting is part of the algorithm. It isn't any more space than MD5 itself.

Example: My salt is "ABCDEF", so I begin by checking my password as "a" + the salt munged into it in whatever fashion, then MD5 the result, and repeat for every possible combination from minimum to maximum password length.
This is no different in resulting space used than if you just took vanilla MD5.

Doing it per user (assuming a different salt for each user) is where the larger amounts of time/drive space use occurs.

Again, that's assuming the salt isn't application-wide (which I sincerely hope it isn't).

quote:
In short, its faster simply to try every random combination of password+salt, than to generate a rainbow table that will be used only for a single password.

Possibly. It depends on the resources available to the people working on this. Rainbow Table generation is a very scalable operation. Provided you have the space, a couple quad-core boxes can churn out rainbow tables in pretty short order, and plus, disk is cheap.

Either way, data that's been seized by law enforcement isn't as secure as people would like to believe.


RE: Nearly immune?
By masher2 (blog) on 6/3/2008 3:07:57 PM , Rating: 2
> "This is no different in resulting space used than if you just took vanilla MD5"

Yes it is, because Rainbow tables don't commonly use the entire address space -- instead the tables are generated for alpha characters only (upper, lower, or both) or possibly alphanumeric + a few special characters. But this doesn't work for salted passwords -- your table has to contain the entire address space, including nonprintable characters, etc.

> "Possibly. It depends on the resources available to the people working on this"

No, you're still confusing "feasible" with "possible". No matter how many resources you apply, the fact remains that a brute force attack will still be more efficient than trying to rainbow attack individually salted passwords.

There are millions of "attacks" that can eventually decrypt a block of text...but most of them are worse than brute force. So why would anyone ever use them?


RE: Nearly immune?
By chsh1ca on 6/3/2008 3:42:12 PM , Rating: 2
quote:
Yes it is, because Rainbow tables don't commonly use the entire address space -- instead the tables are generated for alpha characters only (upper, lower, or both) or possibly alphanumeric + a few special characters. But this doesn't work for salted passwords -- your table has to contain the entire address space, including nonprintable characters, etc.

If the salt is known, and how it is added to the password before hashing is known, then only the range of characters used in the password need to exist in the table.

If you're thinking that it can't be done that way, consider storing the algorithm in a reference table, and keeping an integer-based key on it that is then used in the rainbow table itself to track which algorithm is associated with which result (assuming you want to store multiple results in one go). A salt is really an algorithm detail, not a password detail.

quote:
No, you're still confusing "feasible" with "possible".

From: http://www.merriam-webster.com/dictionary/feasible
quote:
1 : capable of being done or carried out <a feasible plan>


quote:
No matter how many resources you apply, the fact remains that a brute force attack will still be more efficient than trying to rainbow attack individually salted passwords.

This is true provided you are 100% accurate in your assumptions.
Also, I've not argued brute forcing can't be faster, just that it isn't necessarily faster.

Either way, again, it's only further proving my point about saying it's nearly immune.


RE: Nearly immune?
By masher2 (blog) on 6/3/2008 8:54:47 PM , Rating: 2
quote:
"If you're thinking that it can't be done that way, consider storing the algorithm in a reference table, and keeping an integer-based key on it that is then used in the rainbow table itself to track which algorithm is associated with which result (assuming you want to store multiple results in one go). "
But storing all those multiple results is effectively identical to storing a larger version of the table itself.

You can get around the address space expansion by using a reduction function which maps a salted password back to the original address space. But then you have to resalt the password each time you calculate each step of the chain. You're back to old time-space tradeoff again. Go with a larger table...or deal with millions of extra steps during the precalculation itself, but thousands of extra steps for each attack. Ouch!


RE: Nearly immune?
By Xerstead on 6/3/2008 2:17:33 PM , Rating: 2
quote:
It may be prohibitively expensive and time consuming...

Just answered your own question. 'Not feasible' is not the same as 'Not possible'.


RE: Nearly immune?
By chsh1ca on 6/3/2008 2:41:03 PM , Rating: 2
Read the next part of that sentence; Feasibility is based on several things. Feasibility for you or I is a different playing field than feasibility for a large organization hellbent on making examples of people.

For the BPI/RIAA/CRIA/et. al., it's entirely feasible.


RE: Nearly immune?
By masher2 (blog) on 6/3/2008 3:11:59 PM , Rating: 2
You've misunderstood what feasibility implies in a cryptographic sense. An attack less efficient than brute force is never feasible, no matter how many resources one throws at it.


RE: Nearly immune?
By chsh1ca on 6/3/2008 3:55:58 PM , Rating: 2
quote:
You've misunderstood what feasibility implies in a cryptographic sense. An attack less efficient than brute force is never feasible, no matter how many resources one throws at it.

In certain conditions, it is far and away more efficient than brute forcing (which is why it was developed in the first place).
You have arbitrarily created assumptions for yourself that lead you to believe it is not feasible. I am taking the approach that we just don't know how it's being done, and that it could be a feasible attack.


RE: Nearly immune?
By masher2 (blog) on 6/3/2008 7:06:49 PM , Rating: 2
> "it is far and away more efficient than brute forcing (which is why it was developed in the first place)."

Again, you're not understanding how salts change the picture, or *why* rainbow tables are more efficient than a brute-force attack.

A rainbow rable isn't an algorithmic "shortcut" of any sort, as some attacks are. It's simply a large set of precomputed hash chains, generated by performing the same function with which the plaintext was itself hashed. So why is it faster than a brute force attack, when you're doing the same hashing? The answer is that you've traded time for space...the time required to generate the table, vs. the space it occupies. Since tables can be precomputed, that time can be amortized across many different attacks...attacks not only for each of the thousands of passwords on a single machine, but potentially for thousands of different machines.

But now let's throw salt into the picture. If its a simple salt -- say just 4 bits worth -- then you can still precompute the table. It takes 2^4=16 times as long to generate, and requires (roughly) about 32 times as much storage space -- 16 x 2 (assuming a doubling of the character space) but its still feasible in theory.

But no one uses 4 bit salts. The smallest in practice are 8-12 bits, and modern systems are usually 32 bits. That's far too large to precompute the entire table, meaning each individual password has to have its own separate rainbow table generated.

See the problem now? The time to generate a sufficiency of chains for for a single salt, then run the attack itself (which consists of repeatedly hashing until you find a match from the values you've already generated) is much more expensive than simply trying all the possible values itself.

You're right -- rainbows were developed because they're more efficent than brute force attacks...but only on unsalted passwords. But salting was likewise developed to prevent rainbow and other such precomputation attacks. Even a single system-wide salt can make a rainbow attack infeasible in practice. And a user-specific salt of sufficient complexity makes it infeasible, even in theory.


RE: Nearly immune?
By chsh1ca on 6/3/2008 10:25:40 PM , Rating: 2
quote:
Again, you're not understanding how salts change the picture, or *why* rainbow tables are more efficient than a brute-force attack.

No, I really do know what you're attempting to say, and what you are attempting to put forth. I'm well aware of the issues surrounding this particular type of attack, as I've done a bit of work with it. You're placing arbitrary assumptions of your own on the whole scenario to try and invalidate what I mentioned was a *possibility*, which is the real issue here. This is a point I've mentioned a few times, but I fully expect you to continue ignoring it out of convenience.

Some of what you have written is accurate, some is not, but you persist in believing there is only one way to salt passwords, and I assure you from all the varied software I've developed for/used/technically examined, that's far from the case.

I would reply to the rest of your post, but you seem either unable or unwilling to fully read and comprehend what I'm saying, and appear to believe that every time I respond I'm saying you're wrong about everything, and then take a small portion of what I say and respond only to that, out of context. That is not conducive behaviour to constructive discussion.


RE: Nearly immune?
By masher2 (blog) on 6/4/2008 12:47:55 AM , Rating: 1
I fully comprehend your point, which is that it's possible to break individually-salted passwords with a rainbow attack. Which is true. It's possible. However, it's simply much easier to use a brute force attack.

And that, sir, is the point you've perpetually misunderstood. Unique salts render rainbow attacks infeasible. It doesn't matter how many resources you throw at the problem-- if you can break it in less time with the simplest brute force attack, why bother?


RE: Nearly immune?
By quickk on 6/3/2008 1:09:46 PM , Rating: 2
What about the pepper? You could always apply it to a stormcloud and find the silver lining.


Britain is scary
By Polynikes on 6/3/2008 12:08:28 PM , Rating: 3
quote:
...and were forced to provide DNA samples and fingerprints before being released on bail.

DNA samples? What the hell for? That's some bullshit.




RE: Britain is scary
By Gastrian on 6/3/2008 12:33:41 PM , Rating: 2
Its standard practice for all people arrested, even if they are later found to be innocent. Its the easiest method (from an aggro point of view) for the police to gather a database of fingerprint and DNA data on possible criminals.


RE: Britain is scary
By Polynikes on 6/3/2008 9:13:09 PM , Rating: 3
I still think it's crap. What if they turn out to be innocent? Does the government destroy the records? Of course not. Might as well fingerprint and take DNA samples from everyone at birth.

Oh, and don't forget a wireless tracking device implanted as well.


RE: Britain is scary
By barjebus on 6/3/2008 12:37:26 PM , Rating: 5
Well, we all know what a gateway drug file sharing can be. Don't you remember the words of the Great Leader, Attorney General Michael Mukasey, when he told us all that file sharing funds terrorism?

One second you're putting a CD in your optical drive, and the next, you're funding terrorism. It's a fine line these people are walking between music piracy, and killing people.


Actually.....
By Alexstarfire on 6/3/2008 8:44:16 AM , Rating: 2
there isn't really anything to complain about this time. Sucks for those guys, buy it doesn't sound like the BFI and UK police are being douche bags about it like the RIAA. These guys were the uploaders and were getting stuff before it's official release. This is how you should go about taking down piracy. Perhaps the RIAA and/or MPAA could learn a lesson or two.




RE: Actually.....
By FITCamaro on 6/3/2008 10:11:05 AM , Rating: 2
I agree. Stop the source. Fining those who merely download does nothing to prevent piracy.


RE: Actually.....
By saiga6360 on 6/3/2008 10:29:34 AM , Rating: 2
This is what happens when law enforcement is left to those whose job it is to actually do it, not some deputized vigilante company that 'accidentally' shoots down innocent bystanders.


RE: Actually.....
By masher2 (blog) on 6/3/2008 7:07:59 PM , Rating: 3
RIAA suits aren't attempting to enforce criminal law; they're attempting to recover civil damages....an entirely different matter, with different standards of proof.


RE: Actually.....
By saiga6360 on 6/4/2008 7:21:50 AM , Rating: 2
I am not talking about their ridiculous lawsuits. I am talking about Denial of Service attacks on legitimate business.


My bad!
By sporr on 6/3/2008 1:06:22 PM , Rating: 5
I almost read,

quote:
British Phonographic Industry (BPI)


as

quote:
British Pornographic Industry (BPI)


Come on, an easy mistake to make!




RE: My bad!
By Cullinaire on 6/3/2008 3:50:57 PM , Rating: 2
Sorry to say, but that's more of a reflection of the state of the reader's mind than anything else.

/High horse

...I did the same thing you did.


RE: My bad!
By Cullinaire on 6/3/2008 3:51:58 PM , Rating: 2
Damn you Bill Watkins!


This is how you get results.
By Reclaimer77 on 6/3/2008 12:15:24 PM , Rating: 2
While here in the US the RIAA is hopelessly trying to battle the TECHNOLOGY of p2p, Britain is actually going after the enablers of file sharing. Those who upload the originals !

You can't stop p2p technology. You just can't. There will always be a way or a work around to any limitations. But you CAN get results by punishing uploaders. After all, they are the ones who originally violate the 'intillectual property' of an artist or movie right ?




RE: This is how you get results.
By michal1980 on 6/3/2008 12:37:41 PM , Rating: 2
in a bit torrent enivorment, doesnt the downloader become the uploader?

thereby all torrent users sharing copyright material should be arrested


By Reclaimer77 on 6/3/2008 12:55:29 PM , Rating: 2
quote:
in a bit torrent enivorment, doesnt the downloader become the uploader?


Not exactly. Hes more like one of several hosts.


By overzealot on 6/4/2008 11:43:52 AM , Rating: 2
More like a pawnbroker, selling goods without asking if they're stolen.


"If you look at the last five years, if you look at what major innovations have occurred in computing technology, every single one of them came from AMD. Not a single innovation came from Intel." -- AMD CEO Hector Ruiz in 2007

DailyTech Poll
Which web browser do you use on your primary personal machine? 






44 Comments









botimage
Copyright 2009 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki