Blockchain graveyard

CoinDash appears to be victimized by a hacked website, which a supposed adversary swapped out a funding address with a malicious address immediately after a token sale was launched.

Contributors that sent ETH to the fraudulent Ethereum address, which was maliciously placed on our website, and sent ETH to the CoinDash.io official address will receive their CDT tokens accordingly. Transactions sent to any fraudulent address after our website was shut down will not be compensated.

It is unfortunate for us to announce that we have suffered a hacking attack during our Token Sale event. During the attack $7 Million were stolen by a currently unknown perpetrator. The CoinDash Token Sale secured $6.4 Million from our early contributors and whitelist participants and we are grateful for your support and contribution.

(Will update post when more thorough information is available. For now, view bravenewcoin.com

“The employee PC, not the head office server, was hacked. Personal information such as mobile phone and email address of some users were leaked. However, some customers were found to have been stolen from because of the disposable password used in electronic financial transactions.”

Due to a programming error in the implementation of Zerocoin, an attacker was able to exploit a single proof to generate multiple spends they could send to an exchange, in which the attackers then sold and withdrew funds.

Significant documentation on the breach is available.

From what we can see, the attacker (or attackers) is very sophisticated and from our investigations, he (or she) did many things to camouflage his tracks through the generation of lots of exchange accounts and carefully spread out deposits and withdrawals over several weeks. We estimate the attacker has created about 370,000 Zcoins which has been almost completely sold except for about 20,000+ Zcoin and absorbed on the market with a profit of around 410 BTC. In other words, the damage has already been mostly absorbed by the markets.

Most information related to this breach is in Polish. Bitcurex warned users not to use previous deposit addresses, which indicates a breach. No information on a root cause is easily available.

Follow up investigation of the blockchain is mostly done by Polish bitcoin press, which estimates a 2300BTC loss.

This is Bitfinex’s second appearance in the graveyard.

All below information is inferred or directly from reddit comments of Bitfinex employees. Employees repeatedly offer insight in comments that an internal breach allowed an attacker to interact with their BitGo implementation, and that BitGo’s security was not compromised.

Bitfinex suggests in these comments that several withdrawal limits existed per user and system wide, and employees are unsure how they were bypassed.

BitGo is a multisignature solution that heavily protects loss from a single key material breach. This approach greatly mitigates many of the risks associated with BTC, but still has a burden of securely storing API secrets or taking advantage of mitigations available to them in API implementation.

At the end of the day, an application interacts with an API that signs transactions.

The victims have strongly cleared BitGo of fault, it appears Bitfinex may not have taken advantage of (or incorrectly used) the security controls available to them through the BitGo API.

Employees have also stated that per user, HD wallets backed by the BitGo API were used in lieu of any truly offline cold storage solution. This implementation suggests that authentication to BitGo’s API was “warm” or “hot” leaving API and signing keys to reside on servers that could be remotely accessed by an attacker. It was also suggested that every Bitfinex BTC holder used this approach, meaning vulnerability carried 100% risk of bitcoin loss across the board.

It’s not currently suggested how servers were accessed for an attacker to position themselves into an attack like this, but will update if that becomes available.

We are investigating the breach to determine what happened, but we know that some of our users have had their bitcoins stolen. We are undertaking a review to determine which users have been affected by the breach. While we conduct this initial investigation and secure our environment, bitfinex.com will be taken down and the maintenance page will be left up.

While technically an application vulnerability, this breach is interesting in that the vulnerability was within an Ethereum Contract. This has made the ability to patch or restore funds a very dramatic and unique situation involving miner consensus and the philosophy of ethereum’s purpose as a technology. Hard and Soft forks were considered with contention to reverse the attack.

An attack has been found and exploited in the DAO, and the attacker is currently in the process of draining the ether contained in the DAO into a child DAO. The attack is a recursive calling vulnerability, where an attacker called the “split” function, and then calls the split function recursively inside of the split, thereby collecting ether many times over in a single transaction.

This breach is unique in that it attacked Cold Storage.

It is just as important to protect the deposits into cold storage as much as the cold storage itself. If cold storage deposit is modified, it’s as if you don’t have cold storage at all.

We have previously communicated the fact that most clients’ crypto-asset funds are stored in multi-signature cold wallets. However, the malicious external party involved in this breach, managed to alter our system so that ETH and BTC deposit transfers by-passed the multi-sig cold storage and went directly to the hot wallet during the breach period. This means that losses of ETH funds exceed the 5% limit that we imposed on our hot wallets.

Not much data available, but in a transition to shut down their wallet product, they somehow leaked a password database.

While we were turning off servers, disabling firewalls and cleaning up backup systems today, we may have leaked a copy of our database. Although passwords into Coinkite.com are not useful anymore, you can rest assured that passwords were salted and SHA256 hashed with 131,072 rounds. If you used the same password on other sites, as a precaution, you may want to consider changing those other accounts. It’s possible you will see spam to your related email addresses.

Application vulnerability due to a lack of input sanitation, type unknown, though it does reference a “database call” which implies some form of database injection like SQLi.

Strangely, they claim that no coins were lost, though CoinWallet shut down anyway.

It is with great regret that we announce the closure of CoinWallet.co. Our decision to close is based on several factors. Primarily, on the 6th of April we suffered a data breach.

Despite our best efforts there was a small error in a part of our code that should have checked and sanitized user input on a recently added function. Checks were in place but the check was then subsequently not used to block the database call.

Our backup security system kicked in as it was designed to and no coins were lost. We have since patched the vulnerability but are still trying to determine the extent of the breach. However it would be advised to change passwords on any other crypto related websites where you use the same password and username as coinwallet.co. We used encrypted and salted passwords but given enough time these should be assumed compromised.

Effective immediately, we have reset all passwords, deleted all API keys, and halted the twitter Tip Bot.

This incident prompted us to reassess the viability of running coinwallet.co and it was decided it is just not viable taking into consideration the risk, costs and time involved.

Not much data available, other than that it has completely shut down after a suspected breach.

This issue is currently under investigation and it is our intention to have the balance of your account settled as soon as possible. We sincerely apologize for this unfortunate inconvenience and will keep you posted on the progress of this issue. In the meantime, we have halted deposits, withdrawals and trading activity until this matter has been resolved.

Not much detail provided, and appears damage was fairly limited for unknown reasons.

On Monday, March 14, 2016, our server fell victim to an attack that gave the attacker unauthorized administrative access. The breach was immediately noticed, and the server was shutdown to prevent any further damage. We are still performing a formal investigation to determine the attack vector, and specifically what information was obtained from the server. Due to additional security mechanisms in place, no funds were taken, and all ID’s (driver’s licenses, passports, etc.) and emails remain secured. Sellers were emailed withdrawal instructions Tuesday evening. All outstanding orders and withdrawals have been processed. Only 3% of all funds remain unclaimed.

Extremely detailed post-mortem’s available from this breach, involving an external hacker collaborating with an insider threat.

On March 14th, ShapeShift had 315 Bitcoin stolen from its hot wallet. It was quickly discovered that an employee at that time had committed the theft. It was reported to relevant authorities, and a civil suit was opened against the individual. As we had quickly figured out who it was, and how to resolve it internally, we were able to keep the site running uninterrupted. We planned to get the stolen property returned, and thought that was the end of it.

Maliciously placed Application vulnerability after a dependency (Lucky7Coin) was backdoored by a malicious developer, and abused for months to pull off an attack.

After a period of time of investigation it was found that the developer of Lucky7Coin had placed an IRC backdoor into the code of wallet, which allowed it to act as a sort of a Trojan, or command and control unit. This Trojan had likely been there for months before it was able to collect enough information to perform the attack.

Very little information, other than that wallets were compromised.

BIPS has been a target of a coordinated attack and subsequent security breached. Several consumer wallets have been compromised and BIPS will be contacting the affected users.

Most of what was recoverable from our servers and backups has now been restored and we are currently working on retrieving more information to get a better understanding of what exactly happened, and most of all what can be done to track down who did it.

The attacker spearphished the CFO (with what looks to be a compromised email / server of someone else, this is unclear) and successfully acquired his credentials with a phishing page.

These credentials were then used to communicate with the CEO and request multiple large transfers to the amount of $1.8 Million USD. A customer pointed out the fraud.

Below is the root cause as pointed out by court documents.

On or about December 11, 2014, Bryan Krohn, the CFO of Bitpay, received an email from someone purporting to be David Bailey of yBitcoin (a digital currency publication) requesting Mr. Krohn comment on a bitcoin industry document.

Unbeknownst to Mr. Krohn, or anyone at Bitpay, Mr. Bailey’s computer had been illegally entered (i.e. “hacked”).

The phony email sent by the person who hacked Mr. Bailey’s computer, directed Mr. Krohn to a website controlled by the hacker wherein Mr. Krohn provided the credentials for his Bitpay corporate email account.

After capturing Mr. Krohn’s Bitpay credentials, the hacker used that information to hack into Mr. Krohn’s Bitpay email account to fraudulently cause a transfer of bitcoin.

The hacker illegally hacked Mr. Krohn’s computer so he could use his or her computer to send false authorizations to Bitpay on December 11 and 12, 2014.

It is this hacking which fraudulently caused the transfers of bitcoin and therefore the loss to Bitpay of bitcoin valued at $1,850,000 (the “Loss”).

Bitpay cannot recapture the lost bitcoin.

An attacker defaced the cloudminr.io website with a “database for sale” message containing usernames and passwords.

According to various reports, the site was hacked on or about July 7th, with the main page of the service being amended over the weekend to offer the sale of customer login and personal information, along with a CSV (comma separated values) taste-test of the details of 1,000 customers’ personal details by the hackers to demonstrate that they were the “real deal.”

If a leaked incident report is to be believed, a VBA script embedded in a Word document was delivered via social engineering tactics over Skype to several employees. This malware was detonated on a system administrator’s machine who also had access to wallet.dat files and wallet passwords. 18,866 BTC lost as deposits were stolen over the course of several days.

Bitstamp experienced a security breach on Jan. 4th. Security of our customers’ bitcoin and information is a top priority for us, and as part of our stringent security protocol we temporarily suspended our services on January 5th. All bitcoin held with us prior to the temporary suspension of services starting on January 5 (at 9 a.m. UTC) are completely safe and will be honored in full. We are currently investigating and will reimburse all legitimate deposits to old wallet addresses affected by the breach after the suspension.

A small hot wallet compromise, although uncertain how they were accessed.

Dear Customer although we keep over 99.5% of users’ BTC deposits in secure multisig wallets, the small remaining amount in coins in our hot wallet are theoretically vulnerable to attack. We believe that our hot wallet keys might have been compromised and ask that all of our customer cease depositing cryptocurrency to old deposits addresses. We are in the process of creating a new hot wallet and will advise within the next few hours. Although this incident is unfortunate, its scale is small and will be fully absorbed by the company. Thanks a lot for your patience and comprehension. Bitfinex Team”

An attacker used a simple account takeover with multiple pivots to gain server access to a wallet.

With administrative access to Wordpress, the attacker was able to upload PHP based tools to explore the filesystem and discover stored secrets. From there, database credentials were accessed and another PHP based database tool was used to access a database and modify a off-chain ledger. The attacker then dodged double accounting systems by discovering loopholes around the purchase/sale of bitcoins.

This deserves a full read and is one of the better post mortems in the graveyard.

Around 8PM on Sunday (all times EDT) our marketing director’s blog account requested a password reset. Up until the writing of this post (Wednesday morning, 10am) we do not know how the thief managed to know the marketing director’s (will refer to this as MD from here) account. Our best guess is it was an educated guess based on info found (more on that in a moment). The MD saw this email come in, and forwarded it to myself, and another team member (a technical lead/temporary assistant support staff), letting us know what happened and that he did not request the password reset. I did not see the email at the time, as I was out, and it was not a huge red flag that would require a phone call. Once I returned home later, I saw the email, and logged into the server to double-check on things. That’s when I discovered the breach.

Apparently, the thief had gained access to the tech assistant’s email account. That email was hosted on a private server (not gmail, yahoo, etc). We have no idea how the password was acquired. We spent a lot of time this week downloading password lists from torrents, tor sites, etc, and could find his password in none of the lists. He assures us he did not use the password in multiple places, and that it was a secure password. Our best guess is that it was a brute force attempt. The mail server he uses used the dovecot package for IMAP mail, which, for reasons we cannot comprehend, does NOT log failed password attempts by default. Because of this, at first, we believed that the hacker somehow had the person’s password. But we do not know, and there is no way to know at this point how the password was found.

Application vulnerability involving a race condition for multiple currencies at Cryptoine.

According to a statement on the Cryptoine website, the firm claims that a “hacker found some race condition bug in our trading engine. Manipulation of orders gave him false balances.”

In a further update, Cryptoine claims that the hack only targeted hot wallets, saying that “our hot wallets was [sic] drained, coins: bitcoin, litecoin, urocoin, dogecoin, bitcoinscrypt, magi, darkcoin, dogecoindark, cannabis” but promises that all coins they still have will be returned to users “in correspondingly smaller quantities.”

Not much detail, other than a database breach and it seems all customers were paid back.

Effective immediately, CAVIRTEX intends to cease carrying on an active Bitcoin business and will be winding down its operations in an orderly manner. As a result, effective immediately, no new deposits will be accepted by CAVIRTEX. Trading on CAVIRTEX will be halted effective March 20, 2015. Effective March 25th, 2015, no withdrawals will be processed. CAVIRTEX will communicate with any account holders that continue to hold balances after March 25, 2015.

We have maintained 100% reserves. CAVIRTEX is solvent and remains in a position to accommodate all customer withdrawal requests received prior to March 25, 2015. However, On February 15, 2015 we found reason to believe that an older version of our database, including 2FA secrets and hashed passwords, may have been compromised. This database did not include identification documents.

Not much data, other than the name of a hacker and that they stole the entire wallet, shutting down ExCoin.

February 6th and 10th, the user ‘Ambiorx’ was able to gain access to all the Bitcoins on the Exco.in exchange. As a result we no longer have the means necessary to continue operation and are deeply saddened to announce we will be shutting down operations this month. The trading engine has been disabled and Exco.in user accounts will remain active, with the exception of Ambiorx’s account and those who may be affiliated.

Cloud infrastructure account takeover without a lot of detail.

Several hours ago one of our hosting accounts was hacked and the hacker got 50m NXT from this server. It’s totally our fault and we are trying our best to cover all the loss. However 50m nxt is huge for us, we cannot afford it at the moment.

Not much information available, other than the victim stating that the hacker was putting a lot of effort towards their attack.

We have been constantly monitoring the hacking activities on our servers and 3 months back then we took the precautionary step to migrate our servers to a highly secured cloud site. Unfortunately, that didn’t stop the incident from happening last night. In the last 24 hours, our security team worked around the clock to trace back the codes and processes. At this moment, we have a pretty good idea of exactly how they did it. This was not a generalized attack. The hacker’s strategy was precisely calculated and well targeted to compromise a certain weakness on our server.

Not much data available, other than that a hacker supposedly stole a wallet and then extorted the operator for further funds.

While preparing for the final audit results, a task we were working on for weeks now, our bitcoin wallet has been hacked and emptied, just after exchanging our fiat holdings within the exchanges to bitcoin and transferring our entire holdings to our wallet, in order to proof our solvency.

It is a known fact that I personally opposed any proof of solvency, but agreed to conduct it for the sake of a few dozen small and medium investors.

The hacker contacted me shortly after he took advantage of our holdings and demanded a ransom in order to transfer the coins back. I have agreed to a 25% ransom of the entire sum, but haven’t heard back from him for several days now.

Very traditional application vulnerability (SQL injection) that was brought in by a third party library. This modified their “escrow” product.

Whilst we have not yet completed our investigation, we have identified the attack vector as a vulnerability in a third party plugin. This was used to inject SQL queries into our database and manipulate the amounts on transactions being released from escrow. What we have not made public until now is that we have seen sustained and almost-daily attack attempts on the site for many months. We have been in contact with the Australian Federal Police regarding this, and will be sharing with them all data that we have on this attack as well as all previous attempts.

Little information provided.

A few hours ago we were unfortunately the subject of a successful attack against the exchange. Our investigations have shown that whilst our security was breached, VeriCoin was the target. We would like to stress that VeriCoin and the VeriCoin network has not been in any way compromised. We have worked to secure the exchange and the withdraw process from any further attack.

Little information provided, though the attackers seemed to have accessed the DogeVault servers and accessed a wallet directly.

We regret to announce that on the 11th of May, attackers compromised the Doge Vault online wallet service resulting in wallet funds being stolen. After salvaging our wallet we have ascertained that around 280 million Dogecoins were taken in the attack, out of a total balance of 400 million kept in our hot wallet. 120 million Dogecoins have been since recovered and transferred to an address under our control. It is believed the attacker gained access to the node on which Doge Vault’s virtual machines were stored, providing them with full access to our systems. It is likely our database was also exposed containing user account information; passwords were stored using a strong one-way hashing algorithm. All private keys for addresses are presumed compromised, please do not transfer any funds to Doge Vault addresses.

Not enough information, other than a infrastructure intrusion that breached the wallet.

Long story short: yes, our wallet server got hacked and all funds were withdrawn.

“Front End” flaw implies an application vulnerability involving transactions between users of their application. It sounds like a race condition given the use of thousands of requests that were necessary to deplete the wallet before the off-chain ledger could update.

During the investigation into stolen funds we have determined that the extent of the theft was enabled by a flaw within the front-end. The attacker logged into the flexcoin front end from IP address 207.12.89.117 under a newly created username and deposited to address 1DSD3B3uS2wGZjZAwa2dqQ7M9v7Ajw2iLy. The coins were then left to sit until they had reached 6 confirmations. The attacker then successfully exploited a flaw in the code which allows transfers between flexcoin users. By sending thousands of simultaneous requests, the attacker was able to “move” coins from one user account to another until the sending account was overdrawn, before balances were updated.

If you trust the operators, they blame the famous “[transaction malleability][1]” vulnerability. [1]: https://en.bitcoin.it/wiki/Transaction_Malleability

Our initial investigations indicate that a vendor exploited a recently discovered vulnerability in the Bitcoin protocol known as “transaction malleability” to repeatedly withdraw coins from our system until it was completely empty.

Very little information available.

As a result of a hacker attack it was robbed portfolio BTC and LTC. This fact was reported to law enforcement authorities.

They were stolen currency BTC and LTC belonging to all users. If they recover they will be returned to users in accordance with the state of the balance on the day 17.11.2013r.

Cloud infrastructure account takeover. Some kind of 2FA bypass exploit as well. Source code, wallets, and user data exfiltrated by attacker.

Two hacks totalling about 4100 BTC have left Inputs.io unable to pay all user balances. The attacker compromised the hosting account through compromising email accounts (some very old, and without phone numbers attached, so it was easy to reset). The attacker was able to bypass 2FA due to a flaw on the server host side. Database access was also obtained, however passwords are securely stored and are hashed on the client. Bitcoin backend code were transferred to 10;[email protected]:[email protected] (most likely another compromised server).

Cloud infrastructure compromise. After an initial credential breach, the attacker escalated access through social engineering. The victim blames the hosting provider for violating their own procedure for password resets.

The attacker has acquired login credentials to our VPS control account with our hosting service provider and has then asked for the root password reset of all servers which – unfortunately – the service provider has then done and posted the credentials in their helpdesk ticket, rather than the standard process of sending it to our email address (which has 2FA protection), also the security setup of allowing only our IP range to login to the management console was not working. It was an additional security feature the provider offered but was obviously circumvented by the attacker. As a result out of this incident we have moved all our services to a new provider who offers 2 factor authentication for all logins as well as other verification processes that we hope will make similar attempts impossible in the future

This was an account takeover on the victim’s cloud provider, allowing access to a server hosting a hot wallet. This was part of a larger breach.

Someone managed to reset the password from our hosting provider web interface, this enabled the attacker to lock us out of the interface and request a reboot of the machine in ‘rescue’ mode. Using this, the attacker copied our hot wallet and sent away what was present.

This very hosting provider (OVH) had been compromised a couple of days ago, in the exact same way, leading to loss of funds on mining.bitcoin.cz.

Given that a database was accessed, this was probably a breach of infrastructure. Their comment about being “impossible to reopen” makes me wonder if it was off-chain and if they couldn’t trust their ledger.

The Instawallet service is suspended indefinitely until we are able to develop an alternative architecture. Our database was fraudulently accessed, due to the very nature of Instawallet it is impossible to reopen the service as-is.

This is a tough translation but it seems like a clear application vulnerability involving some kind of coupon code system.

(Translated)

The Bitcoin market suffered an attack, which unfortunately was successful in its implementation redeem code. Due to a coding error, it was possible for an attacker to generate new credit codes, without the value was properly charged to your final balance. Getting thus generate a false amount of bitcoins within the system and rescue him in time during the night.

Attacker pivoted several times after initially gaining access to the victim’s domain registrar via social engineering. This then allowed a DNS hijack, allowing them to route password resets to the attacker. Attacker then took over cloud infrastructure hosting wallets.

The attacker contacted our domain registrar at Site5 posing as me and using a very similar email address as mine, they did so by proxying through a network owned by a haulage company in the UK whom I suspect are innocent victims the same as ourselves. Armed with knowledge of my place of birth and mother’s maiden name alone (both facts easy to locate on the public record) they convinced Site5 staff to add their email address to the account and make it the primary login (this prevented us from deleting it from the account). We immediately realized what was going on, and logged in to change the information back. After changing this info and locking the attacker out, overnight he was able to revert my changes and point our website somewhere else. Site5 is denying any damages, but we suspect this was partly their fault.

After gaining access, they redirected DNS by pointing the nameservers to hetzner.de in germany, they used hetzner’s nameservers to redirect traffic to a hosting provider in ukraine. By doing this, he locked out both my login and Gareths’s login and they used this to hijack our emails and reset the login for one exchange (VirWox), enabling them to gain access and steal $12,480 USD worth of BTC. No other exchanges were affected due to either Mult Factor Authentication, OTP, Yubikey’s and auto lockdowns.

The hacker was also able to pull a few hours of internal company emails. However due to mandatory PGP encrytion between members of our company and tools like Cryptocat, sensitive information was not breached.

The big one. Lots of speculation and not a lot of hard data. Everything from negligence, insider threat, and fraud has been speculated.

On Monday night, a number of leading Bitcoin companies jointly announced that Mt. Gox, the largest exchange for most of Bitcoin’s existence, was planning to file for bankruptcy after months of technological problems and what appeared to have been a major theft. A document circulating widely in the Bitcoin world said the company had lost 744,000 Bitcoins in a theft that had gone unnoticed for years. That would be about 6 percent of the 12.4 million Bitcoins in circulation.

Mark Karpeles, the former CEO of Mt. Gox, told the Daily Beast last month, “I suspect that some of the missing bit coins were taken by a company insider but when I tried to talk to the police about it, they seemed disinterested.

Attackers likely gained access through a cloud infrastructure provider and accessed a server with unencrypted hot wallet.

Last night, a few of our servers were compromised. As a result, the attacker gained accesses to an unencrypted backup of the wallet keys (the actual keys live in an encrypted area). Using these keys they were able to transfer the coins. This attack took the vast majority of the coins BitFloor was holding on hand. As a result, I have paused all exchange operations. Even tho only a small majority of the coins are ever in use at any time, I felt it inappropriate to continue operating not having the capability to cover all account balances for BTC at the time.

Infrastructure breach with access to a large hot wallet.

It is with much regret that we write to inform our users of a recent security breach at Bitcoinica. At approximately 1:00pm GMT, our live production servers were compromised by an attacker and they used this access to deplete our online wallet of 18547 BTC.

A breach at Linode was the root cause here and there’s plenty of information to understand the breach. Credentials for a customer support team member were used and eight Linode customers were compromised for having affliations to bitcoin.

After accessing the customer support interface, the attacker was able to access the individual account interface for their victims and change root passwords on customer’s machines. To apply this root password change, servers were rebooted.

A VP at Linode responded.

Somebody hacked my backup machine with pool data hosted on Linode and steal 3094 BTC (“hot” coins ready for payouts). Cold backup was not affected in any way by this hack.

It looks that also user database has been compromised. Although passwords are stored in SHA1 with salt, I strongly recommend to change your password on the pool immediately.

Robery of Bitcoins has no impact to pool users, I’m covering the loss from my own income (although it means that many months of my work is wasted Roll Eyes ).

Attackers made it onto Bitcoin7 infrastructure, due to wallets and database data being accessed. Given that “other websites” were owned, it’s possible a larger unknown shared hosting provider with other customers was compromised.

On Oct 5th 2011 Bitcoin7.com became the victim of a number of pre-planned hacker attacks. While our investigation is still going, evidence reveals that the attacks originated from Russia and Eastern Europe.

The attack itself took action not only against the bitcoin7.com server but also against other websites and servers which were part of the same network. Eventually the hackers managed to breach into the network which subsequently lead to a major breach into the bitcoin7.com website.

As a result of the hacking, unknown individuals managed to gain full access to the site’s main bitcoin depository/wallet and 2 of the 3 backup wallets.

In addition the hackers gained access to our user database.

This sounds like an application vulnerability that allowed forged deposits that could eventually be withdrawn from a hot wallet. This sort of attack is more common with “off blockchain” wallets.

After careful analysis of the intrusion we have concluded that the software that waited for Bitcoin confirmations was far too lenient. An unknown attacker was able to forge Bitcoin deposits via the Shopping Cart Interface (SCI) and withdraw confirmed/older Bitcoins. This led to a slow trickle of theft that went unnoticed for a few days. Luckily, we do keep a percentage of the holdings in cold storage so the attackers didn’t completely clean us out. Just to clarify, we weren’t “fully” hacked aka “rooted”. You can still trust our PGP, SSL, and Tor public keys.

The cause is very uncertain. The operator suspects a third party destroying a host on AWS, but it looks like operator error is highly possible due to the “breach” occurring during a major upgrade.

(Translated)

On 26 July 2011, at about 23:00 am, I have found the overloaded the Bitcoin server and I had to increase the RAM. As a result of this operation, the entire virtual machine was removed, and with it all the information, including the wallet and all of its backups. I have found that the data did not go into Nirvana because the Virtual Machine settings have >been changed, even though I have changed even nothing. Our Hoster, Amazon Web Services Company, indicates that the deleted machine was adjusted so that they are once you shut down irrevocably “destroyed” (including all data on the hard disks).

I am still determine who changed the settings on the VM and whether it is possible to recover the deleted data. Unfortunately, the collaboration with Amazon Web Services (AWS) to be very difficult. Once I realized that the virtual machine is lost, I immediately ordered AWS premium support, talked to the manager and asked for protection of my data. So far without success.

To this day I could not find out the exact reasons for the misery. I suspect the actions of third parties, which wanted to cover up their illegal activities, or even wanted to crash the whole service, responsible for them. Should my suspicions in that direction harden, I’ll go with the case to the police and prosecutor’s office. For this I need but the cooperation between AWS and which is (as mentioned above) currently very difficult. Efforts of data recovery are of course still in progress.