BTC-E.COM NICE RECOVERY FROM THE HACK! =)

[ErebusBat]

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  

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

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

All of this, especially the bolded part.

[1713558288]

1713558288

[1713558288]

1713558288

[pekv2]

Got mine back and returned theirs. I was told the USD was faked.

[Energizer]

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  

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

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

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 ".

[ErebusBat]

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  

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

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

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 ".

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.

[runeks]

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 ".

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]

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 ".

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.

[kano]

...
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 ...

[notme]

...
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.

[Energizer]

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 ".

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]

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 ".

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.

[rjk]

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.

[runeks]

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]

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 ".

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.

[runeks]

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]

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 ".

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]

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]

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]

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]

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.

[runeks]

^ Good info. I read the Flickr vulnerabilty paper and it also appears than an attacker needs to know the length of the original message M, in order to perform a length-extension attack. Because the length of the original message is added to the end of the data that is hashed.

I presumed that performing a pre-image attack on such a construction (a secret with known information added to the end) would not require 2^n attempts, on average, for a n-bit entropy hash function. But I think that may be wrong, since a full iteration of the compression function for SHA-256 hasn't been broken yet. And as was proved by Merkle and Damgård, if a full iteration of the compression function is secure, then doing them sequentially is also secure, as I understand it.

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.

Well they would need to circumvent the HTTPS encryption first. If they didn't use HTTPS then yes, they were very poorly protected against MITM attacks.