Friday, April 18, 2014

Investigation report of the claimed security breach at LocalBitcoins

LocalBitcoins received a lot of media attention on the 17th of April 2014 regarding claimed security breaches. On the 17th April, 98% of LocalBitcoins trades where conducted without an opened support ticket. LocaBitcoins have been operating since summer 2012, being one of the oldest living sites for exchanging Bitcoins. There has been one known site security breach in the past (summer 2013) where the loss of Bitcoins could be due to an issue on the site.

LocalBitcoins team did not found any evidence of compromised site security.

Claimed two-factor authentication breach

LocalBitcoins allows its users to protect their user accounts with two-factor authentication. In two-factor authentication you need an additional one time token to operate your user account besides knowing your password. Two-factor token generator is stored separately, so that in the case your computer gets compromised the attackers cannot operate your user account with only knowing your password, which has been hijacked either by extracting it from the computer memory or keylogging.

During the history of LocalBitcoins, there have been now two claims (including this one) where the user claimed loss of Bitcoins and the two-factor authentication was enabled before the incident.

In the case of user don4of4, the following is what happened.

21. March 2014, the user activates his/her user account

21. March 2014, the user conducts series of trades, using a desktop browser

16. April 2014, the user conducts series of trades, using a desktop browser

17. April 2014 03:52, the user activates the two-factor authentication, using desktop browser

17. April 2014 12:40, the user does his/her first two-factor login using an Android device

17. April 2014 15:45, the user Bitcoins are transferred away using the two-factor codes and login session the user opened earlier. This request came from a Tor browser, as opposite to the user's Android device.

17. April 2014 ~17:00, the user posts to Reddit claiming that the LocalBitcoins security is compromised

17. April 2014 ~17:00, the user open a support ticket for resolving the incident

The user has admitted storing his two-factor codes on the Android device. In this case if the user used this particular Android device to access LocalBitcoins and the device was compromised, the attacker gained access to user password, user session id and two-factor codes. Furthermore, it was reported on the Reddit that the credentials of this particular user have been found on known compromised user account lists spreading in the Internet.

If one needs to operate LocalBicoins site from a mobile phone, LocalBitcoins offers a paper codes based two-factor authentication which is based on printed one-time passwords. Even if the mobile device is compromised the attacker cannot gain access to the physical printed paper.

This cannot be clickjacking or XSS attack, because the user must always give their password or two-factor code to operate the LocalBitcoins Bitcoin wallet. An automated attack possessing only the user session id is not possible.

In this case, the request for transferring Bitcoins from the users wallet came from an different IP address the user used to log in to the site. LocalBitcoins currently does not use session fixation to an IP address as a further layer of security. However if the attacker is in the control of the device of the user, the attacker can also use this device and its same IP address to make requests to LocalBitcoins. LocalBitcoins team will further discuss whether session fixation to an IP address should be enabled for some users.

This case is also very unlikely to be an inside job. LocalBitcoins logs all the actions done by its support staff and developers to an audit log, so potential abuse of staff privileges is easily uncovered. Two-factor authentication codes and passwords are not accessible by the support staff. Furthermore, it would not be very rational for an insider to attack against one particular user and his/her wallet only if the insider would have access to all wallets.

Due to media reporting of the case, the users where panicing and moving their Bitcoins away from LocalBitcoins. Most of Bitcoins stored on LocalBitcoins are in cold storage. Even if the LocalBitcoins servers were compromised, the attackers would still not get access to stored user Bitcoins. When the LocalBitcoins hot wallet was being emptied due to high volume of withdraws, the withdraws started to delay. LocalBitcoins choose not to top up the hot wallet until the incident is investigated.

Other claimed Bitcoin losses

On the week of 17th April, 11 separate incidents of claimed Bitcoin losses were reported. In these cases the pattern is that the user bought Bitcoins on LocalBitcoins and then there was a Bitcoin transaction which the user claimed he/she did not make himself/herself.

LocalBitcoins security automatically blocks automatic logins and attemps to log in if one particular IP address seems to behave malicious. However if the username and password is known by the attacker and two-factor authentication is not enabled, then it is not possible for LocalBitcoins to differetiate between legit logins and logins done by the attacker.

Could your team please respond to my ticket? I am seriously trying to get to the bottom of this and I could use help. I have friends at Google and have a conference call on Google Authenticator security later today.

From the given information, the theft depended on 1) session hijacking and 2) compromised 2FA. Although this is certainly indicative of a compromised user device, LocalBitcoins needs to take more aggressive action to inhibit session hijacking.

Even with 2FA enabled, requests which originate from a user with a different IP address and browser than that which was recorded at the initiation of a session should be responded to by immediately destroying that session and asking the user to reauthenticate. In this particular case, the withdrawal request was associated with an IP address and user agent header which were distinguishably different from that which was recorded at the start of the session. As a result, the request should have been flagged as suspicious and denied.

Of course, such policies may not have been able to prevent the theft in this particular case. If the attacker was able to gain not merely read-only permissions but also execution permissions on the user's device, then the attacker could have sent the request directly from the user's device using the existing session, and the request would not appear suspicious to the server. If the attacker was able to access both the user's password and 2FA code, then the attacker could simply establish a new session from anywhere and subsequently send the withdrawal request.

Nonetheless, it is alarming to find that the security of session management at LocalBitcoins is certainly lacking. Taking a more proactive approach to session security would help to inhibit attacks and bolster trust in the LocalBitcoins platform. A good technical overview of the topic can be found here: https://wblinks.com/notes/secure-session-management-tips/