Bitcoin Forum
January 21, 2018, 05:23:07 AM *
News: Electrum users must upgrade to 3.0.5 if they haven't already. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 »  All
  Print  
Author Topic: BTC-E.COM NICE RECOVERY FROM THE HACK! =)  (Read 50585 times)
piramida
Legendary
*
Offline Offline

Activity: 1120



View Profile
July 31, 2012, 08:03:17 PM
 #361

I think it should be pretty obvious that nobody bruteforced sha-256 or the key, you are overcomplicating - there are so many ways the password can be leaked and so few ways it could be cracked, that I'd bet my car against a beer on chances of crack vs leak  Smiley

In most of these API implementations, they key is checked by an endpoint, and in some badly written systems it stores the key for verification directly in code or config files, which in some badly managed systems can be seen by developers or god knows who while in transit. Even if they key only exists on production servers where only trusted admin has access to, who can be sure that their cheap hosting company (interserver) which does backups for them does proper encryption?

All in all, if site operators really believe in what they posted, then it's a good enough reason to never put any BTC on that exchange, as they obviously don't understand what happened. Or lied. Or both Smiley

PS but at least they handled the situation well. Better than most other victims of the bitcoin economy Smiley

i am satoshi
1516512187
Hero Member
*
Offline Offline

Posts: 1516512187

View Profile Personal Message (Offline)

Ignore
1516512187
Reply with quote  #2

1516512187
Report to moderator
1516512187
Hero Member
*
Offline Offline

Posts: 1516512187

View Profile Personal Message (Offline)

Ignore
1516512187
Reply with quote  #2

1516512187
Report to moderator
1516512187
Hero Member
*
Offline Offline

Posts: 1516512187

View Profile Personal Message (Offline)

Ignore
1516512187
Reply with quote  #2

1516512187
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1516512187
Hero Member
*
Offline Offline

Posts: 1516512187

View Profile Personal Message (Offline)

Ignore
1516512187
Reply with quote  #2

1516512187
Report to moderator
ErebusBat
Hero Member
*****
Offline Offline

Activity: 560

I am the one who knocks


View Profile
July 31, 2012, 08:43:47 PM
 #362

I think it should be pretty obvious that nobody bruteforced sha-256 or the key, you are overcomplicating - there are so many ways the password can be leaked and so few ways it could be cracked, that I'd bet my car against a beer on chances of crack vs leak  Smiley

In most of these API implementations, they key is checked by an endpoint, and in some badly written systems it stores the key for verification directly in code or config files, which in some badly managed systems can be seen by developers or god knows who while in transit. Even if they key only exists on production servers where only trusted admin has access to, who can be sure that their cheap hosting company (interserver) which does backups for them does proper encryption?

All in all, if site operators really believe in what they posted, then it's a good enough reason to never put any BTC on that exchange, as they obviously don't understand what happened. Or lied. Or both Smiley

PS but at least they handled the situation well. Better than most other victims of the bitcoin economy Smiley

All of this, especially the bolded part.

░▒▓█ Coinroll.it - 1% House Edge Dice Game █▓▒░ • Coinroll Thread • *FREE* 100 BTC Raffle

Signup for CEX.io BitFury exchange and get GHS Instantly!  Don't wait for shipping, mine NOW!
pekv2
Hero Member
*****
Offline Offline

Activity: 770



View Profile
July 31, 2012, 09:46:58 PM
 #363

Got mine back and returned theirs. I was told the USD was faked.
Energizer
Sr. Member
****
Offline Offline

Activity: 274



View Profile
July 31, 2012, 10:32:02 PM
 #364

I think it should be pretty obvious that nobody bruteforced sha-256 or the key, you are overcomplicating - there are so many ways the password can be leaked and so few ways it could be cracked, that I'd bet my car against a beer on chances of crack vs leak  Smiley

In most of these API implementations, they key is checked by an endpoint, and in some badly written systems it stores the key for verification directly in code or config files, which in some badly managed systems can be seen by developers or god knows who while in transit. Even if they key only exists on production servers where only trusted admin has access to, who can be sure that their cheap hosting company (interserver) which does backups for them does proper encryption?

All in all, if site operators really believe in what they posted, then it's a good enough reason to never put any BTC on that exchange, as they obviously don't understand what happened. Or lied. Or both Smiley

PS but at least they handled the situation well. Better than most other victims of the bitcoin economy Smiley

It seems more like a Man-in-the-Middle attack, there would have been sniffing involved in uncovering the secret keys. It is also possible that a simple XSS "Cross-Site-Scripting" vulnerability been involved in revealing the secrets "it could be the account number field Wink".
ErebusBat
Hero Member
*****
Offline Offline

Activity: 560

I am the one who knocks


View Profile
July 31, 2012, 10:39:23 PM
 #365

I think it should be pretty obvious that nobody bruteforced sha-256 or the key, you are overcomplicating - there are so many ways the password can be leaked and so few ways it could be cracked, that I'd bet my car against a beer on chances of crack vs leak  Smiley

In most of these API implementations, they key is checked by an endpoint, and in some badly written systems it stores the key for verification directly in code or config files, which in some badly managed systems can be seen by developers or god knows who while in transit. Even if they key only exists on production servers where only trusted admin has access to, who can be sure that their cheap hosting company (interserver) which does backups for them does proper encryption?

All in all, if site operators really believe in what they posted, then it's a good enough reason to never put any BTC on that exchange, as they obviously don't understand what happened. Or lied. Or both Smiley

PS but at least they handled the situation well. Better than most other victims of the bitcoin economy Smiley

It seems more like a Man-in-the-Middle attack, there would have been sniffing involved in uncovering the secret keys. It is also possible that a simple XSS "Cross-Site-Scripting" vulnerability been involved in revealing the secrets "it could be the account number field Wink".
Except this API key shouldn't be doing anything that would be overly vulnerable to XSS.  MiM is possible, but if LR isn't using HTTPS, or they were not verifying the certificate chain (entirely possible) then someone is an idiot.

░▒▓█ Coinroll.it - 1% House Edge Dice Game █▓▒░ • Coinroll Thread • *FREE* 100 BTC Raffle

Signup for CEX.io BitFury exchange and get GHS Instantly!  Don't wait for shipping, mine NOW!
runeks
Legendary
*
Offline Offline

Activity: 952



View Profile WWW
July 31, 2012, 11:05:45 PM
 #366

It seems more like a Man-in-the-Middle attack, there would have been sniffing involved in uncovering the secret keys. It is also possible that a simple XSS "Cross-Site-Scripting" vulnerability been involved in revealing the secrets "it could be the account number field Wink".
Except this API key shouldn't be doing anything that would be overly vulnerable to XSS.  MiM is possible, but if LR isn't using HTTPS, or they were not verifying the certificate chain (entirely possible) then someone is an idiot.
I often hear man-in-the-middle attacks mentioned, but how do they work exactly? I mean, I know the attacker is able to position himself between the target and whatever server the target is trying to reach, but how on earth does he do this? By poisoning the DNS cache of the target? Or through some other means? I mean, I find it pretty hard to understand how I can connect to a site, and someone can somehow inject himself into the path between me and the site.
notme
Legendary
*
Offline Offline

Activity: 1890


View Profile
July 31, 2012, 11:29:46 PM
 #367

It seems more like a Man-in-the-Middle attack, there would have been sniffing involved in uncovering the secret keys. It is also possible that a simple XSS "Cross-Site-Scripting" vulnerability been involved in revealing the secrets "it could be the account number field Wink".
Except this API key shouldn't be doing anything that would be overly vulnerable to XSS.  MiM is possible, but if LR isn't using HTTPS, or they were not verifying the certificate chain (entirely possible) then someone is an idiot.
I often hear man-in-the-middle attacks mentioned, but how do they work exactly? I mean, I know the attacker is able to position himself between the target and whatever server the target is trying to reach, but how on earth does he do this? By poisoning the DNS cache of the target? Or through some other means? I mean, I find it pretty hard to understand how I can connect to a site, and someone can somehow inject himself into the path between me and the site.

DNS poisoning, ARP poisoning, script kiddie at your ISP, malware editing your hosts file, etc.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
kano
Legendary
*
Offline Offline

Activity: 2338


Linux since 1997 RedHat 4


View Profile
August 01, 2012, 12:49:51 AM
 #368

...
DNS poisoning, ARP poisoning, script kiddie at your ISP, malware editing your hosts file, etc.
Well unless they were hacked, none of those should work over a secure link ...

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
notme
Legendary
*
Offline Offline

Activity: 1890


View Profile
August 01, 2012, 01:01:04 AM
 #369

...
DNS poisoning, ARP poisoning, script kiddie at your ISP, malware editing your hosts file, etc.
Well unless they were hacked, none of those should work over a secure link ...

But how do you know it's secure when there are 10 routers belonging to 10 different companies between you and them?

If we're talking SSL they can verify the certificate with a trusted authority, but sometimes even the "trusted authorties" get hacked.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
Energizer
Sr. Member
****
Offline Offline

Activity: 274



View Profile
August 01, 2012, 01:05:15 AM
 #370

It seems more like a Man-in-the-Middle attack, there would have been sniffing involved in uncovering the secret keys. It is also possible that a simple XSS "Cross-Site-Scripting" vulnerability been involved in revealing the secrets "it could be the account number field Wink".
Except this API key shouldn't be doing anything that would be overly vulnerable to XSS.  MiM is possible, but if LR isn't using HTTPS, or they were not verifying the certificate chain (entirely possible) then someone is an idiot.
I often hear man-in-the-middle attacks mentioned, but how do they work exactly? I mean, I know the attacker is able to position himself between the target and whatever server the target is trying to reach, but how on earth does he do this? By poisoning the DNS cache of the target? Or through some other means? I mean, I find it pretty hard to understand how I can connect to a site, and someone can somehow inject himself into the path between me and the site.

There are multiple MITM techniques. The simplest ones are the ones that take place in the same local network where you and the attacker are connected to the same network/subnet. Anyways, what I mean by MITM attack here is that the secret keys were not cracked but been captured. It could have been done by an insider or even someone in the ISP!
mb300sd
Legendary
*
Offline Offline

Activity: 1260

Drunk Posts


View Profile WWW
August 01, 2012, 04:32:33 AM
 #371

It seems more like a Man-in-the-Middle attack, there would have been sniffing involved in uncovering the secret keys. It is also possible that a simple XSS "Cross-Site-Scripting" vulnerability been involved in revealing the secrets "it could be the account number field Wink".
Except this API key shouldn't be doing anything that would be overly vulnerable to XSS.  MiM is possible, but if LR isn't using HTTPS, or they were not verifying the certificate chain (entirely possible) then someone is an idiot.
I often hear man-in-the-middle attacks mentioned, but how do they work exactly? I mean, I know the attacker is able to position himself between the target and whatever server the target is trying to reach, but how on earth does he do this? By poisoning the DNS cache of the target? Or through some other means? I mean, I find it pretty hard to understand how I can connect to a site, and someone can somehow inject himself into the path between me and the site.

There are multiple MITM techniques. The simplest ones are the ones that take place in the same local network where you and the attacker are connected to the same network/subnet. Anyways, what I mean by MITM attack here is that the secret keys were not cracked but been captured. It could have been done by an insider or even someone in the ISP!

Not even ISP. BGP is very insecure, anyone able to publish routes can have traffic for any address on the internet routed to them.

1D7FJWRzeKa4SLmTznd3JpeNU13L1ErEco
rjk
Sr. Member
****
Offline Offline

Activity: 448


1ngldh


View Profile
August 01, 2012, 07:31:30 AM
 #372

Not even ISP. BGP is very insecure, anyone able to publish routes can have traffic for any address on the internet routed to them.
Sure, but that is fairly easy to detect and will result in alarm bells ringing all over the world. Remember when China tried that stunt? Big press all over the place about it.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
runeks
Legendary
*
Offline Offline

Activity: 952



View Profile WWW
August 01, 2012, 01:21:10 PM
 #373

BGP is very insecure, anyone able to publish routes can have traffic for any address on the internet routed to them.
And who are able to publish routes? Is it likely that the attacker was able to do this?

Could an attacker have used a tool like sslsniff?

Upon further research, it looks like authentication via the Liberty Reserve API involves hashing (SHA-256) ones secret key with the current time (in a certain format ("<secret>:20070225:14" if the date/time is 2007-02-25 14:xx)). So if the attacker was able to retrieve the plain text HTTP request, he could perhaps be able to brute force the secret key (provided it was weak enough) by simply hashing "<secret>:20070225:14" over and over again, changing <secret> until it matches the hash in the request.

But then, how would he be able to use this information to deposit USD on BTC-E? As far as I know, he'd need to impersonate LR's servers in order to do this, wouldn't he?

As far as I can see though, there's no response to the authentication request from the LR server that uses the secret key in any way. I'd assume the server would reply to an authentication request with something that proves that the server also has the secret key. If it doesn't, BTC-E's servers could connect to anyone in the world and they'd just reply "Sure, that looks good. We approve your authentication". If the server had to respond with, for example, a hash of the authentication data with the secret key added to it, BTC-E's server would be able to verify that whomever they are connected to knows the secret key.
Also, the LR API server can be configured to only accept request from a single IP. I'd sure enable that if I were running an exchange (I presume these have a static IP).

My immediate guess would that the attacker got the secret key off of BTC-E's servers, and not by performing a MITM attack. But yeah, I'm no expert.
ErebusBat
Hero Member
*****
Offline Offline

Activity: 560

I am the one who knocks


View Profile
August 01, 2012, 02:03:56 PM
 #374

It seems more like a Man-in-the-Middle attack, there would have been sniffing involved in uncovering the secret keys. It is also possible that a simple XSS "Cross-Site-Scripting" vulnerability been involved in revealing the secrets "it could be the account number field Wink".
Except this API key shouldn't be doing anything that would be overly vulnerable to XSS.  MiM is possible, but if LR isn't using HTTPS, or they were not verifying the certificate chain (entirely possible) then someone is an idiot.
I often hear man-in-the-middle attacks mentioned, but how do they work exactly? I mean, I know the attacker is able to position himself between the target and whatever server the target is trying to reach, but how on earth does he do this? By poisoning the DNS cache of the target? Or through some other means? I mean, I find it pretty hard to understand how I can connect to a site, and someone can somehow inject himself into the path between me and the site.
Generally MiM attacks are only useful on wifi type links for consumer attacks.

HOWEVER lets assume that:
 1. LR allowed API access over HTTP; and
 2. BTCE was stupid enough to use it; and
 3. There was a curious party anywhere in the path between them....

If they grabbed a packet capture... happened to know what it was.... and were 'smart' enough to use it then it is possible.

However the above scenario is HIGHLY unlikely, to the point I have a better chance of answering my door to find mila kunis there ready to be my sex slave AND my wife being ok with it.

░▒▓█ Coinroll.it - 1% House Edge Dice Game █▓▒░ • Coinroll Thread • *FREE* 100 BTC Raffle

Signup for CEX.io BitFury exchange and get GHS Instantly!  Don't wait for shipping, mine NOW!
runeks
Legendary
*
Offline Offline

Activity: 952



View Profile WWW
August 01, 2012, 08:16:59 PM
 #375

However the above scenario is HIGHLY unlikely, to the point I have a better chance of answering my door to find mila kunis there ready to be my sex slave AND my wife being ok with it.
Mmmm.

Wait, what were we talking about?
dree12
Legendary
*
Offline Offline

Activity: 1246



View Profile
August 01, 2012, 09:13:33 PM
 #376

It seems more like a Man-in-the-Middle attack, there would have been sniffing involved in uncovering the secret keys. It is also possible that a simple XSS "Cross-Site-Scripting" vulnerability been involved in revealing the secrets "it could be the account number field Wink".
Except this API key shouldn't be doing anything that would be overly vulnerable to XSS.  MiM is possible, but if LR isn't using HTTPS, or they were not verifying the certificate chain (entirely possible) then someone is an idiot.
I often hear man-in-the-middle attacks mentioned, but how do they work exactly? I mean, I know the attacker is able to position himself between the target and whatever server the target is trying to reach, but how on earth does he do this? By poisoning the DNS cache of the target? Or through some other means? I mean, I find it pretty hard to understand how I can connect to a site, and someone can somehow inject himself into the path between me and the site.
However the above scenario is HIGHLY unlikely, to the point I have a better chance of answering my door to find mila kunis there ready to be my sex slave AND my wife being ok with it.
What if Mila Kunis is your wife?
runeks
Legendary
*
Offline Offline

Activity: 952



View Profile WWW
August 01, 2012, 10:24:42 PM
 #377

I just thought of something. The way one authenticates with Liberty Reserve is flawed because they don't use, at the least, HMAC in the HTTP requests that are supposed to authenticate a user of their API.

When using SHA-256 (as opposed to HMAC-SHA-256) the problem is that it iterates through the message 512 bits at a time. This means that if I hash:

<secret>+<message>

and an attacker knows the hash of this, an attacker can find the hash of a message with something appended to the end, like:

<secret>+<message>+<hacker's message>

which will be as valid as the previous message. He can do this by figuring out the internal state of the variables in the hash function, initializing the hash function with these variables, and continue from where the previous hash function left off.

I'm not good enough at this stuff to figure it out, but this may be exactly what happened. If it is fatal enough, it's possible that an attacker could intercept the HTTP request to LR, which is in the format "<secret>:date:hour", and would currently be:

Code:
<secret>:20120801:23

and then, using the hash in the HTTP request, restore the internal state of the SHA-256 hash function and change the hour value to an hour later and use this to authenticate with LR.

In any case, if a hacker gets the plain text of the HTTP request, he would be able to authenticate with LR for up to an hour - without knowing the secret key - depending on when he intercepts it (if he is able to guess the "API Name") which, as far as I can tell, isn't supposed to be that secret/hard to guess.

In fact, a similar vulnerability was present in Flickr's API and was discovered back in 2009: http://netifera.com/research/flickr_api_signature_forgery.pdf

I'm not sure if, when using a "secret prefix" (as its known), one is able to replace the last part of the message, or if it's just possible to add something to the end though.

In any case it seems LR's API is pretty broke.
tgsrge
Member
**
Offline Offline

Activity: 70



View Profile
August 02, 2012, 02:40:00 AM
 #378

if indeed they dont use any scheme to integrity protect their messages, someone that is sitting ANYWHERE between lr and btc-e can modify/inject anything they want into the messages...this could give the person essentially free reign to do whatever it wanted actually.
mobile4ever
Hero Member
*****
Offline Offline

Activity: 518


View Profile
August 02, 2012, 02:57:52 AM
 #379

They are still your bitcoins, because they can be used as them on demand.
Tell that to ThiagoCMC.

Really, all money is just an obligation of someone to pay me back for something.
No. Money is not necessarily an obligation. Money is the most fungible commodity in an economy. And just like with every other commodity, no one is obligated to give you anything for the money commodity.

Now, currencies - or money substitutes - are obligations. Traditionally, the dollar was an obligation (of the Federal Reserve) to pay someone back in gold, on demand. The British Pound was an obligation of the Bank of England to pay back the holder of said currency in sterling silver. Neither of these currencies are obligations any longer.


Right. Thanks for clearing that up.
JoelKatz
Legendary
*
Offline Offline

Activity: 1582


Democracy is vulnerable to a 51% attack.


View Profile WWW
August 02, 2012, 03:11:28 AM
 #380

I'm not sure if, when using a "secret prefix" (as its known), one is able to replace the last part of the message, or if it's just possible to add something to the end though.
You can only add something to the end. And you have to add the original padding first. So if you have SHA256(M), where M is the original message, you can compute SHA256(M+P+A) where M is the original message, P is the original padding (which is a function of the length of M) and A is what you want to add onto the message.

A simple fix for this is to use SHA256(SHA256(M)) instead of SHA256(M). Now the hash you are revealing is the hash of a fixed-length message, making length-extension attacks impossible. You would need to know the secret to invert the last hash.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!