Lessons to Learn from the AllCrypt Hack

On March 18, 2015, AllCrypt, a small crypto currency exchange posted what may very well be one of their last posts on their blog. The Bitcoin exchange had been hacked, resulting in stolen crypto currency.

The AllCrypt Team described the attack in detail in their blog post. The attacker managed to somehow get access to a Technical Assistant’s email account. The attacker then proceeded to request a password reset for the Marketing Director’s WordPress account. The Marketing Director, possibly unaware that the email contained the key to resetting his WordPress account, forwarded this email to the compromised Technical Assistant’s email account saying he never requested a password reset.

At this point the attacker could reset the Marketing Director’s WordPress password. The blog post goes on to describe how the attacker managed to upload PHP files to the WordPress site, install Adminer (a web based database management utility similar to PHPMyAdmin) and then create fake crypto currency balances in the system. From there, using a fake account, the attacker could then trade crypto currency and transfer earnings to a Bitcoin wallet owned and controlled by the attacker.

Here are a few takeaways from this incident and how it could have been either entirely prevented, or at least mitigated or controlled.

Restrict WordPress Admin by IP

Let’s assume the email account was compromised and the Marketing Director forwarded the email, the attacker could have still been prevented from logging in or even following that reset password link. By only allowing a limited number of IPs access to the WordPress Administration area, the incident would have probably been prevented altogether because the attacker would have been connecting through a different IP address than genuine users.

Restrict malicious file upload

Assuming there was still no IP whitelisting in place, the attack could still have been mitigated. Uploading files to the site may have been part of the Marketing Director’s role, so it would have been counter-productive to restrict all files uploads, but it seems that the attacker managed to upload a PHP file. That should have never happened. The attacker could have uploaded this file in a number of ways.

Taking advantage of a file upload vulnerability on an older, insecure version of WordPress or a WordPress plugin (which as we all know should always be kept up-to-date)

If the Marketing Director’s account had the role of an ‘Administrator’, the user was probably allowed to upload/install plugins, themes and even make use of the ‘Editor’ feature to modify existing code. This is a critical mistake, especially when less tech-savvy users are concerned. WordPress has user-roles for a reason and they should be used accordingly.

Prevent installation of plugins and themes

Furthermore, let’s assume that an ‘Administrator’ WordPress account had to be hacked, it would still be easy for the hacker to upload files and gain access to sensitive data stored within the database. The best way to mitigate this is to sacrifice some cool WordPress functionality for some better security and not allow plugins to be installed/edited without command-line or SFTP (because you shouldn’t be using FTP anyway!) access.

Separation of concerns

Finally, it would be advised to separate software such as forums, blogs wikis and so on from other core services. In this case the compromise of the WordPress account was the key to the attack, but that would probably not have happened if AllCrypt’s exchange service was hosted on a separate server. By separating the WordPress site from the rest of the service, the attack may have been far less damaging, since it would have only affected the WordPress site..

For more WordPress security tips, including step by step guides on how to configure your WordPress installation, please visit our WordPress Security series.