Bitscalper passwords have been leaked

[Matthew N. Wright]

I guess it wouldn't surprise anyone here to know that when KalyHost went down over that one weekend a few weeks back, the reason BitScalper was freaking out is because if he never bothered to backup the wallets OR his site's code.

[1713544181]

1713544181

[1713544181]

1713544181

[1713544181]

1713544181

[1713544181]

1713544181

[splatster]

The fact that they didn't have SSL says even more about their [il]legitimacy.
I'm glad I didn't fall victim to this.

[Raoul Duke]

The fact that they didn't have SSL says even more about their [il]legitimacy.

Yes, because only legitimate persons can get a free SSL cert at startcom. 

[cablepair]

The fact that they didn't have SSL says even more about their [il]legitimacy.

Yes, because only legitimate persons can get a free SSL cert at startcom. 

lol

not to mention anyone with a linux box can install openssl and generate their own cert, it really means nothing unless its a cert from a reputable certification agency

[toffoo]

So what's the story here, has anybody been able to pull any deposits out since this news hit or are the coins officially gone?

[marked]

Clearly there was no validation on input on the sql statements.

I'm currently seeing password in cleartext on an error page, across a non-encrypted link.


Error 1054 : Unknown column 'readable' in 'field list'

SQL = [UPDATE spyuser SET readable ='PASSWORD' WHERE email = 'user@example.com']
Array (

• => Array ( [file] => /var/www/p/app/database.php [line] => 19 [function] => db_report_error [args] => Array (
• => UPDATE spyuser SET readable ='PASSWORD' WHERE email = 'user@example.com' ) ) [1] => Array ( [file] => /var/www/p/app/index.php [line] => 14 [function] => db_query [args] => Array (
• => UPDATE spyuser SET readable ='PASSWORD' WHERE email = 'user@example.com' ) ) )
  
  [/tt]
  
  

[bitscalper]

Because of personal freedom concerns, management of bitscalper was forced to leave the site alone for the last ten days. We did just notice the security breach and we do apologize about any issue that this might cause. We want to clarify that we did not store any password in plain text, rather the server was compromised to add a textual password column to the database, supposedly for the hacker to get all the user's passwords.
We did store all the passwords in MD5, while we acknowledge that it is not the state of the art, it still works for decently choosen passwords. We will be posting any update/finding on here. Thanks and apologizes for delaying intervention.

[Nachtwind]

umm.. md5 is not just not State of the Art - md5 is just as good as plaintext for almost every password with a length of less than maybe a quadrillion characters..

[caveden]

What you're saying doesn't make much sense to me.

If the passwords were hashed (even unsalted MD5), how could an attacker create a clear text column with everybody's password? At most he would get some through rainbow tables, but not all.

Unless the attacker actually manage to inject code into your server. That would be a more serious flaw, not just a password leak. And still, he would only be able to get the clear version of each password after everybody logs in.

[Nachtwind]

What you're saying doesn't make much sense to me.

If the passwords were hashed (even unsalted MD5), how could an attacker create a clear text column with everybody's password? At most he would get some through rainbow tables, but not all.

Unless the attacker actually manage to inject code into your server. That would be a more serious flaw, not just a password leak. And still, he would only be able to get the clear version of each password after everybody logs in.

Well.. if you had a look at the javascript of bitscalper you would have spotted theyre actually using md5 hashed passwords.. so i guess he is not lieing about that..
Looking at the list of withdrawals: Any word to those.. i guess 70 or 80 people who try to cash out? Will they get their BTC back?

[theymos]

Because of personal freedom concerns, management of bitscalper was forced to leave the site alone for the last ten days. We did just notice the security breach and we do apologize about any issue that this might cause. We want to clarify that we did not store any password in plain text, rather the server was compromised to add a textual password column to the database, supposedly for the hacker to get all the user's passwords.
We did store all the passwords in MD5, while we acknowledge that it is not the state of the art, it still works for decently choosen passwords. We will be posting any update/finding on here. Thanks and apologizes for delaying intervention.

The security vulnerability I used still exists. Read the email I sent to info@bitscalper.com.

[caveden]

What you're saying doesn't make much sense to me.

If the passwords were hashed (even unsalted MD5), how could an attacker create a clear text column with everybody's password? At most he would get some through rainbow tables, but not all.

Unless the attacker actually manage to inject code into your server. That would be a more serious flaw, not just a password leak. And still, he would only be able to get the clear version of each password after everybody logs in.

Well.. if you had a look at the javascript of bitscalper you would have spotted theyre actually using md5 hashed passwords.. so i guess he is not lieing about that..

I'm not disputing that. But it seems the exploit allowed the retrieval of clear text passwords. If they are not stored in clear text, how would that be possible?

But wait, you're saying that there's a javascript performing the hash on the client? That's pretty much the equivalent of storing them as clear text.

[Matthew N. Wright]

What you're saying doesn't make much sense to me.

If the passwords were hashed (even unsalted MD5), how could an attacker create a clear text column with everybody's password? At most he would get some through rainbow tables, but not all.

Unless the attacker actually manage to inject code into your server. That would be a more serious flaw, not just a password leak. And still, he would only be able to get the clear version of each password after everybody logs in.

Well.. if you had a look at the javascript of bitscalper you would have spotted theyre actually using md5 hashed passwords.. so i guess he is not lieing about that..

I'm not disputing that. But it seems the exploit allowed the retrieval of clear text passwords. If they are not stored in clear text, how would that be possible?

But wait, you're saying that there's a javascript performing the hash on the client? That's pretty much the equivalent of storing them as clear text.

+2

[rjk]

What you're saying doesn't make much sense to me.

If the passwords were hashed (even unsalted MD5), how could an attacker create a clear text column with everybody's password? At most he would get some through rainbow tables, but not all.

Unless the attacker actually manage to inject code into your server. That would be a more serious flaw, not just a password leak. And still, he would only be able to get the clear version of each password after everybody logs in.

Well.. if you had a look at the javascript of bitscalper you would have spotted theyre actually using md5 hashed passwords.. so i guess he is not lieing about that..

I'm not disputing that. But it seems the exploit allowed the retrieval of clear text passwords. If they are not stored in clear text, how would that be possible?

But wait, you're saying that there's a javascript performing the hash on the client? That's pretty much the equivalent of storing them as clear text.

+2

Can we please make javascript illegal? Thanks.

[Wandering Albatross]

Can we please make javascript illegal?

Yes, agree, it's a huge exploit running in every browser.  These forums suffered from javascript exploits  recently...maybe you knew that already.

[RaggedMonk]

But wait, you're saying that there's a javascript performing the hash on the client? That's pretty much the equivalent of storing them as clear text.

This is how most modern websites work.  You have to hash your password somewhere, so you do it locally in your browser on your machine before transmitting it.  Take a deep breath, guys.

If plaintext passwords were stolen, either the attacker modified the code of the website to prevent pre-transmisssion hashing, or passwords were not salted before they were hashed, so the attackers just brute forced a rainbow table.

[rjk]

But wait, you're saying that there's a javascript performing the hash on the client? That's pretty much the equivalent of storing them as clear text.

This is how most modern websites work.  You have to hash your password somewhere, so you do it locally in your browser on your machine before transmitting it.  Take a deep breath, guys.

If plaintext passwords were stolen, either the attacker modified the code of the website to prevent pre-transmisssion hashing, or passwords were not salted before they were hashed, so the attackers just brute forced a rainbow table.

Uh, no. Maybe, just maybe, if someone was using SSL... which this site wasn't. But "most modern websites"? Utter BS.

[caveden]

But wait, you're saying that there's a javascript performing the hash on the client? That's pretty much the equivalent of storing them as clear text.

This is how most modern websites work.  You have to hash your password somewhere, so you do it locally in your browser on your machine before transmitting it.  Take a deep breath, guys.

If you're sending the hash to the server for authentication, hashing has no point: if your database leaks, anybody in possession of the leak can authenticate himself as any of your users. Remember the client is in control of whatever he sends to your server. He doesn't need to execute the javascript you send him, he can forge any requests as he pleases.

The whole point of hashing a password instead of storing it in clear text is to prevent issues in case of a database leak. The hashing operation must be done in the server.

[caveden]

This is how most modern websites work.  You have to hash your password somewhere, so you do it locally in your browser on your machine before transmitting it.  Take a deep breath, guys.

If plaintext passwords were stolen, either the attacker modified the code of the website to prevent pre-transmisssion hashing, or passwords were not salted before they were hashed, so the attackers just brute forced a rainbow table.

Uh, no. Maybe, just maybe, if someone was using SSL... which this site wasn't. But "most modern websites"? Utter BS.

SSL wouldn't be of any help. Hashing in the client and authenticating the hash == storing passwords in clear text.

To be honest, it is a little less bad than storing clear passwords because at least a leak wouldn't allow an attacker to screw users who use the same password on different sites. But in what concerns your server, it is the same.

[rjk]

This is how most modern websites work.  You have to hash your password somewhere, so you do it locally in your browser on your machine before transmitting it.  Take a deep breath, guys.

If plaintext passwords were stolen, either the attacker modified the code of the website to prevent pre-transmisssion hashing, or passwords were not salted before they were hashed, so the attackers just brute forced a rainbow table.

Uh, no. Maybe, just maybe, if someone was using SSL... which this site wasn't. But "most modern websites"? Utter BS.

SSL wouldn't be of any help. Hashing in the client and authenticating the hash == storing passwords in clear text.

To be honest, it is a little less bad than storing clear passwords because at least a leak wouldn't allow an attacker to screw users who use the same password on different sites. But in what concerns your server, it is the same.

Yes that was my point.