Bancor posted early details of an investigation into a security breach regarding a smart contract. A wallet used to upgrade smart contracts was used to steal somewhere in the range of $23M. Some amount of this was mitigated by protocol level features that allow the freezing of BNT tokens.
A wallet used to upgrade some smart contracts was compromised. This compromised wallet was then used to withdraw ETH from the BNT smart contract in the amount of 24,984 ETH ($12.5M). The same wallet also stole: 229,356,645 NPXS (~$1M) 3,200,000 BNT (~$10M)
Note: Charting as “unknown” until the method used to compromise the method is described.
On June 10, there was a system check due to the hacking attempt at dawn. At present, we have confirmed that 70% of the coin rail total coin / token reserves are safely stored
I moved to a cold wallet and it’s being saved. About 80% of coins that have been confirmed to be leaked have been frozen / withdrawn / redeemed or equivalent, in consultation with their co-workers and related exchanges, while the remainder are under investigation with investigators, related exchanges and coin developers.
Interestingly, South Korean Law Enforcement worked pretty quickly to help contain the issue with maintainers of the coins that had theft.
This is Bithumb’s second appearance in the graveyard. 35 billion Korean won (around $31 million) is estimated to have been stolen, and data about root cause is sparse.
Taylor is described as a “smart cryptocurrency trading assistant” which allows people to day trade cryptocurrency.
Today we arrived at the office and found out that we’ve been hacked and all of our funds have been stolen. Not only the balance in ETH (2,578.98 ETH), but also the TAY tokens from the Team and Bounty pools.
Lots of write ups from their executives shed light on their incident (1, 2, 3). The root cause appears to be a 1Password file theft. It is not clear how the file was accessed, how a hacker had positioning to view it, or whether it contained cryptographic secrets or infrastructure secrets.
Somehow the hacker got access to one of our devices and took control of one of our 1Password files.
The following is also interesting:
Although we are all aware of the good practices, we confess that we may have neglected some very important details — we know that the devil is in the details.
As far as we know, the hacker is same person/group that supposedly hacked CypheriumChain (more than 17,000 ETH were stolen).
The hacker collected the amount from multiple sources in a single wallet, then transferred it to a bigger one.
What we can say is that it was not a smart contract exploit.
A failed cold storage restoration exercise seems to have exposed private keys intended for offline storage (effectively making them online). However, the CEO has expressed an insider’s involvement. Police found private keys exposed online for more than 12 hours.
Our system itself has never been compromised or hacked, and the current issue points towards losses caused during an exercise to extract BTG to distribute to our customers. Our CSO, Dr. Amitabh Saxena, was extracting BTG and he claims that funds have been lost in the process during the extraction of the private keys.
This is one of the harder breaches to decipher, as there are a lot of conspiracy articles and accusations by all parties involved. Underlying the Bitgrail breach seems to be some kind of application error of some sort, as opposed to a fully hijacked wallet, but this doesn’t have a lot of certainty involved. The Nano core team (the currency involved) announced suspicion of the exchange and their claims.
We now have sufficient reason to believe that Firano has been misleading the Nano Core Team and the community regarding the solvency of the BitGrail exchange for a significant period of time.
However, the Bitgrail accusations have pointed towards a thief, and blockchain viewing software developed by Nano.
BitGrail Srl once again confirms that it was the victim of a theft, which took advantage of malfunctions of the software made available by the NANO team (rai_node and official block explorer) and, therefore, also for these reasons and according to the law, is not absolutely responsible, for any reason, of the incident.
Coincheck is a Japanese exchange that works with multiple blockchains, including NEM. Around January 26, 2018, XEM valued at approximately $400m USD were stolen. Initial cause was unclear to Coincheck according to their statements.
After hours of speculation Friday night, Coincheck Inc. said the coins were sent “illicitly” outside the venue. Co-founder Yusuke Otsuka said the company didn’t know how the 500 million tokens went missing, and the firm is working to ensure the safety of all client assets. Coincheck said earlier it had suspended all withdrawals, halted trading in all tokens except Bitcoin, and stopped deposits into NEM coins.
According to the exchange’s representatives, the hackers have managed to steal the private key for the hot wallet where NEM coins were stored, enabling them to drain the funds.
BlackWallet is a wallet used to send and receive Lumens (XLM) on the Stellar network. The creator of BlackWallet announced on Reddit an infrastructure compromise resulting in in a hacked website that attacked users who entered private keys into it. It should be noted that BlackWallet was not in possession of user private keys, but it was a more of a wallet client that could be used to view a wallet.
BlackWallet appears to have existed since August 2017, with a DNS hijack on January 13 pointing traffic towards Cloudflare, and a malicious browser based wallet. BlackWallet only existed for five months before being victimized.
I am the creator of Blackwallet. Blackwallet was compromised today, after someone accessed my hosting provider account. He then changed the dns settings to those of its fraudulent website (which was a copy of blackwallet).
Youbit was hacked on December 19th at 4:35 am. They had previously been breached earlier in the year, with South Korean officials indicating North Korean involvement. Their hot wallet containing 17% of their assets, was breached and stolen, indicating that cold storage was useful. Assuming server breach of some kind.
After the accident in April, we have done our best to improve the security, recruitment and system maintenance, and
have managed to lower the hot wallet rate.
Then, at 4:35 am, we lost our coin purse due to our hacking.
- The coin loss at 4:35 am is about 17% of total assets. The other coins were kept in the cold wallet and there were no additional > losses.
- Loss ratio is low compared to last April, but the management of Yaffian Co. , Ltd. is going to proceed with the process of stopping the transaction, stopping deposit and withdrawal, and bankruptcy on December 19, 2013 ,
- Accordingly, all coins and cash withdrawals and withdrawals will be suspended at 12:00 pm on December 19, 2017.
- Due to bankruptcy, the settlement of cash and coins will be carried out in accordance with all bankruptcy procedures.
- However, in order to minimize the damage to our members, we will arrange for the withdrawal of approximately 75% of the balance at > 4:00 am on December 19, The rest of the unpaid portion will be paid after the final settlement is completed.
- We will do our best to minimize the loss of our members by 17% , through various methods such as cyber comprehensive insurance (3 > billion) and selling the operating rights of the company.
- After the announcement date, your assets will be adjusted to 75% at 4:00 pm on December 19 , 2017. Cash and coins deposited after 4:00 pm will be 100% refunded.
Nicehash was a cryptocurrency mining service and marketplace, allowing users to buy and sell their own mining power. While not necessarily a mining pool of its own, it still maintained a wallet for customer funds. Nicehash appears to have shuttered their website with a notice saying “a security breach involving NiceHash website” and “our payment system was compromised and the contents of the NiceHash Bitcoin wallet have been stolen”.
A Facebook livestream has further notes on the issue. This is hard to archive so I will transcribe useful points. Overall, this was lateral movement from a remote IP address, gaining access to a VPN, possibly through an employee computer, and moving laterally into production systems. This appeared to all have happened within a couple of hours, when the attacker decided to work actively.
- “We became a target and someone really wanted to bring us down.”
- “We are cooperating with local and international law enforcement”.
- ~4700 BTC stolen on early morning 12-06-2017
- Can’t discuss everything due to investigation.
- Hacker(s) were able to infiltrate our internal systems through a compromised company computer.
- Unknown how company computer was compromised.
- VPN had visibility into abusive behavior, IP address was outside of European Union.
- “Made a crucial VPN login using an engineer’s credentials”
- After VPN login, learned and simulated the workings of our payment system.
- Managed to steal funds from accounts (indicates that the active attack timeline was only a couple hours)
Tether lost $31 million in “tokens”. Tether tokens allow you to “store, send and receive digital tokens pegged to dollars, euros, and yen person-to-person, globally”. Based on wording in Tether blog posts, a “treasury wallet” was drained by an external attacker. This infers that some sort of key material, or signature generating process was misused, so I estimate this ultimately required the breach of a high risk server. This estimation is low confidence and could change with new information, for instance, if the treasury wallet was cold, or held on a compromised endpoint by an employee. Remote access requires some aspect of wallet “warmth” which makes me believe it was online on a server. The Tether team claims high confidence in identifying their root cause so this is not an “unknown” root cause.
On Sunday, November 19th, $30,950,010.00 in Tether tokens were stolen from our treasury wallet through malicious action by an external attacker. While we are in the process of co-ordinating and co-operating with law enforcement on this matter, we are satisfied that we have found the cause of the breach of Tether’s systems. We are taking measures to recover the Tethers and are migrating the platform to a new infrastructure. More information about our initial response to this breach is here.
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.
Cold storage is said to have limited losses greatly.
The consequence, allegedly, is that hackers sent deposit transactions for large amounts, e.g. 100,000, to Justcoin. They set the tfPartialPayment flag to something like .0001. The transaction would be perfectly valid, and any client unaware of this behavior in the protocol would likely not be checking for the DeliveredAmount field – since it was never documented until a week ago. The transaction Amount field says “100,000” but the DeliveredAmount is only .0001. The hacker gets credit for 100,000 but only deposits .0001. Then they make a small withdrawal, check the balance on the hotwallet address and drain as much as they can.
Ripple commented on the issue here and puts blame squarely on Justcoin’s implementation.
Justcoin did not implement partial payments correctly. The exchange falsely credited a non-KYC’d user for a deposit, and then allowed the user to illegitimately withdraw the funds from its hot wallet. For every transaction, an exchange needs to ensure the total of user balances plus the new deposit matches the balance of its Ripple cold and hot wallets. If these balances don’t match, the exchange should stop processing the transaction. Ripple Labs has engaged Justcoin in ongoing discourse about its lack of risk and compliance controls. As demonstrated by this incident, a non-KYC’d user can steal with little fear of being identified and owning the consequences.
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.
Poloniex is a Bitcoin exchange that has been operating since 2014. In March of 2014, an Application Vulnerability was exploited and
caused a loss of 97 BTC (a 12.3% loss on the exchange). The reported cause of the hack was that they did not properly check for a negative account balance
while processing multiple, simultaneous withdrawals.
The hacker found a vulnerability in the code that takes withdrawals. The hacker discovered that if you place several withdrawals
all in practically the same instant, they will get processed at more or less the same time. This will result in a negative
balance, but valid insertions into the database, which then get picked up by the withdrawal daemon.
What Will Be Done to Prevent Further Exploits?
Withdrawals and order creation have been switched to a queued method, where the first step is to add the task to a global
execution queue that is processed sequentially. Each step of critical database operations is verified before proceeding, and such
operations are in the process of being converted to transactions. I have hired additional developers to help with tightening up
security at Poloniex, as well as created a bug bounty.
“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 188.8.131.52 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]” vulnerability.
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.
This was a clear application vulnerability with a potentially fraudulent cover up and incident response. On July 28, 2013, hackers discovered an application condition that allowed them to credit accounts from a wallet supporting multiple organizations (Bitfunder and WeExchange). While the SEC found fraud, this seems to be more related to handling of the breach and operating an unregistered exchange.
During the summer of 2013, one or more individuals (the “Hackers”) exploited a weakness in the BitFunder programming code to cause BitFunder to credit the Hackers with profits they did not, in fact, earn (the “Exploit”). As a result, the Hackers were able to wrongfully withdraw from WeExchange approximately 6,000 bitcoins, with the majority of those coins being wrongfully withdrawn between July 28, 2013, and July 31, 2013. In today’s value, the wrongfully withdrawn bitcoin were worth more than $60 million. As a result of the Exploit, BitFunder and WeExchange lacked the bitcoins necessary to cover what MONTROLL owed to users.
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.
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.
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.
In this article, I’m going to be outlining how to securely erase data on a device while running a GNU/Linux-based operating system. This process can be used to wipe a device, such as a USB drive, while running your normal GNU/Linux operating system; or it can be used to wipe your hard drive from a GNU/Linux live CD/USB.
There are many reasons you might want to erase data from a device. It’s possible that you are selling an old computer, and need to eliminate private data. It’s possible your identity has been compromised, and you need to eliminate evidence. Whatever the situation is, simple deletion of files will not securely erase data. If you truly need to erase data from a device, you will need to wipe the device. What’s the issue with simply deleting your data? Deletion of a file does not actually remove the data from a disk; it only deletes the entry in the filesystem metadata. This informs the operating system that the space is free and can be written to. The actual raw data is still located on the disk. Even if a disk is reformatted or repartitioned, the raw data may still remain on the disk. With widely-available data recovery software, most of this data can be quickly recovered. The only way to assure that data cannot be recovered is by verifying that all space on a disk, including inodes, are overwritten with new data.
How does data wiping work? The term “wiping” is actually a bit misleading, because wiping is not just the removal of data. Wiping software actually overwrites all sectors of a disk or partition, ensuring that none of the original raw data remains. Software generally overwrites this data with a combination of zeros and random numbers. These random numbers are produced by a random number generator. /dev/random is a random number generator in the Linux kernel. When /dev/random is read, it will return pseudo-random bits generated from sound produced by device drivers. /dev/random and /dev/urandom are both commonly used to produce pseudo-random bits. However, /dev/urandom reuses the bits in the internal pool to more quickly produce more bits. /dev/urandom is generally considered to be less secure than /dev/random; however, it is much faster and less resource-intensive than /dev/random. For something like cryptographic key generation, you would want to use /dev/random. However, for something like data wiping, the use of /dev/urandom is considered secure.
The wiping utility of my choice is sfill, a small command-line utility that is lightweight but very effective. If you are running a Debian-based distribution, the package should be included by default. Otherwise, this tool is included in the ‘secure-delete’ package. If you are wiping the primary hard drive in your computer, you will need to use a bootable Linux Live CD. You also need to locate the partition or disk you want to wipe (ex. /dev/sda2). For this, you can use GParted or any partition editor. At this point, be sure to verify that you have identified the correct disk. Once you locate this, you will need to run sfill from the command line, pointing it to this disk. The default parameters are secure, so you only need to apply additional arguments if you want to use verbose mode or want additional options. The technical process used by the software is outlined in the sfill Manpage. sfill first overwrites data with zeros. This is only one pass. The next 5 passes overwrite the data with random data from /dev/urandom. After this, data is overwritten 27 passes with values defined by Peter Gutmann, the developer of sfill. The next 5 passes again overwrite with data from /dev/urandom. After this process, temporary files are created to fill inode space. Inode stands for “index node”, and these are used to index the files on a partition. After all free space on the partition is filled, the temporary files are removed and the wiping is finished. At this point, the data wiping process is complete. You can now be confident that your data cannot be recovered.
The version lines that are usually shown by default in PGP keys and PGP signature blocks, often reveal which OS the person is using.
PGP/GPG Version strings:
You can tell a fair bit about a user’s PGP/GPG setup from their Version: string. Here are some typical examples:
Version: GnuPG v1.4.11 (GNU/Linux)
This key belongs to a Linux user.
Version: GnuPG v2.0.19 (MingW32)
This key belongs to a Windows user.
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
This key belongs to a Mac OS X user.
Versions that should make you nervous:
This person is using the official PGP version, as published by Symantec. I’ve read statements by Kevin Mitnick that he no longer trusts PGP, since it was acquired by Symantec. In his post, Mitnick refers to the case of Diskreet, which back in the early days, was an encryption package sold by Symantec. This software purported to use the full 56-bit DES cipher algorithm, which was quite strong for its day. Mitnick stated that he acquired a copy of the Diskreet source code, and discovered that the actual key was nowhere near 56-bits, but was incredibly weak. He went on to say that based on his experience, he would not trust any version of PGP published by Symantec.
His caution is only underscored by the Snowden revelations earlier this Summer, which set out the NSA’s campaign of attempting to weaken or backdoor crypto.
I, for one, would not trust any closed-source crypto software published by an American company — that goes double for companies with a history like Symantec.
To the best of my knowledge, Symantec does not publish PGP source code, and as an American company, their crypto software is now suspect.
Versions of PGP that should make you run away screaming:
Versions of PGP with these Version: strings are based on the BouncyCastle Java crypto libraries. They should be avoided like the plague.
Version: BCPG v1.45
Version: BCPG v1.47
These versions of PGP are absolutely NOTORIOUS for generating MASSIVELY UNSAFE PGP keys by default. These versions typically generate DSS/Elgamal keys
with signing keys with a size of 1024-bits, and an encryption sub-key of as little as 512-bits.
512-bit keys are so unsafe, that they were being broken by hobbyists on spare hardware a dozen years ago. 1024-bit keys were deprecated by NIST more than 3 years ago.
Version: BCPG C# v184.108.40.206
This version of PGP generates by default a PGP key of 1024-bits, with NO encryption sub-key. Again, these keys are unsafe/obsolete.
Any software that uses the Java Bouncycastle crypto libraries (like PortablePGP) should be avoided like the plague. These typically contain BCPG in the Version: string.
GPG4Win/Kleopatra/GPA are also deprecated — Kleopatra generates RSA keys without an encryption sub-key. Dual RSA keys, with one RSA key for signing, and the other exclusively for encryption have been standard since the Fall of 2009.
GPA will not generate keys over 3072-bits in length.
GPG4USB or Gnu Privacy Tray (GnuPT) are recommended, as they are:
* Easy to use
* Standards compliant
GnuPT, in particular, is frequently updated. Usually, when there is a new GPG version (e.g. 1.4.15), the GnuPT developers issue an update with a day or two, reflecting the change.
GnuPT: http://www.gnupt.de/ (Site is in German)