Woah! 
Topic: BTC-E.COM NICE RECOVERY FROM THE HACK! =) (Read 51047 times)
hero member
Activity: 588
Merit: 500
Hero VIP ultra official trusted super staff puppet
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 for one would never get on the forums again.
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.". 
^ 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.
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. 
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.
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.
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.
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:
+
and an attacker knows the hash of this, an attacker can find the hash of a message with something appended to the end, like:
++
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 ":date:hour", and would currently be:
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.
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:
and an attacker knows the hash of this, an attacker can find the hash of a message with something appended to the end, like:
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 "
Code:
: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.
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.". 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?
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.". 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.
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 ("
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.
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. 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.". 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.
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.". 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!
...
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 ...DNS poisoning, ARP poisoning, script kiddie at your ISP, malware editing your hosts file, etc.
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.
...
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 ... DNS poisoning, ARP poisoning, script kiddie at your ISP, malware editing your hosts file, etc.
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.". DNS poisoning, ARP poisoning, script kiddie at your ISP, malware editing your hosts file, etc.
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 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
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
". Jump to: