Analyzing the $5.6M Exploit and Cryptsy's Security Failings | Hacker News Reader

Analyzing the $5.6M Exploit and Cryptsy's Security Failings

earlz.net

39 pointsearlz10 comments

Well, this is assuming the story given by Cryptsy is accurate; without a proper third-party investigation we should consider it likely that the coins have been stolen by the operators as an exit scam.

A sentence from the middle:

They didn't care about exploits as long as they exited before the coin was worthless. This is a very common trope of the altcoin world.

When given a choice between painstakingly building a secure system, or throwing something together to make a quick buck from other gullible greedy people, it seems that everyone has chosen the latter.

Does the very nature of "cold storage" mean they are not monitoring for dramatic drops over SIX months?

I mean they took their damn time emptying that thing out.

It's like robbing a physical bank one wheelbarrow load of cash at a time every day and no-one notices?

The very nature of cold storage would mean that if they'd actually implemented cold storage this hack wouldn't have been possible, because the key wouldn't have existed online in any form.

It's like robbing a bank by hiding around the bank employees until overhearing the combination to the get you behind the tills (the "hot wallets" in a crypto exchange) only to find out that instead of just giving you access to the small amounts in the tills, it actually also gives you full access to the vault (the "cold storage") that should have been time-locked and require at least two separate physical keys to access.

It's hard to secure crypto exchanges sufficiently because of the very nature of it, but it is not hard to come up with security schemes that would make this kind of breach far less costly, and cold storage is one of them.

In other words, as the article writer pointed out:

> Your cold storage should be actually cold. If you can get at your cold wallet's private keys without physically getting out of your chair and walking somewhere, it's not cold.

I think the attackers didn't take anything until 6 months after providing the malicious wallet code. Apparently they were making use of the exploit during that time, probably gathering information on how to get to the important "cold" wallets.

It may have taken them the whole 6 months to figure out how to do that, because I can't imagine them waiting once they had the info they needed; the risk of someone else stealing it first would have been very high. Cryptsy's always been sloppy. They had obvious race conditions in their trade execution, and people regularly complained about stuff like seeing their market orders matching against offers in the middle of the order book instead of the best price. It also used to be easy to end up with a negative balance in one currency (these are unleveraged spot trades mind you, we're not talking options or something). I really have no idea how they made it this long.

Lesson for people to never trust any service provider or wallets (hardware or software) other than deterministic wallets that could be fully reconstructed from a phrase.

Use any service or exchanges for trading only and then swipe funds back to your deterministic wallet after which destroy it, keeping the phrase printed on paper in the safety deposit box.

Light on details here. Better operational security would have prevented this outcome for a time, but they had malicious developer(s) in their code. Game over.

Are all of these *coins written in C? If you had a language not so easily obfuscated you could at least more readily find crap like this.

Writing it in Java or whatever other language doesn't help. All programming languages can be obfuscated as fuck if you want it. Java and other OO languages actually encourage the trend to wrap everything in dozens wrappers, singletons, factories and other stuff, where malicious code can be spread over.

> Java and other OO languages actually encourage the trend

Java, yes. Other OO - not so much. Java is getting better now, but, for a long time, it was simply a weak language, with primitive type system and lots of necessary boilerplates.

If you look at other implementations of OO, you'll see that the trend of "wrapping everything in dozens of wrappers and other stuff" is definitely not universal among them. Dynamic, reflective languages like Ruby and Python tend to have shallow class hierarchies and few wrappers; especially in Python, heavy use of inheritance and creation of classes for every little bit of data is considered un-pythonic. Then you have Smalltalk, which allows arbitrary code transformations on runtime, which further decreases boilerplate and makes a language more expressive. There's also Dylan and, of course, Common Lisp with CLOS. I'm working with StumpWM lately, a window manager written in Common Lisp - it does use classes and multi-methods, but very sparingly. WM is a piece of software, which is almost GUI only, and so in Java, you'd get a monstrous framework with myriads of classes and relations between these. In CL you don't need that at all - standard defuns and built-in data structures are enough for most things.

Anyway, Object Oriented Programming comes in various sizes and shapes, and it's unfair to see bad Java code as "representative OO" code. JavaScript is OO, Smalltalk is OO, OCaml is OO(/FP), and Julia is OO. Take a moment (more like a couple of years, but...) to look at them and try to compare the languages' object models and the common practice of writing code. You'll see something amazing, more than once, I promise.

The problem is that the moment you think that code review will stop an adversary (and you should treat all the coin developers as adversaries as a matter of course here), odds are good you've lost, no matter what the language is.

You should still review, but couple that with sandboxing the code in VMs (and as much as I love Docker etc.: that's insufficient), and make sure that you fully firewall that VM and the entire machine the VM is on off from everything else in your system. And crucially, that means ensuring that outbound access is also firewalled and filtered.

In this case, the coins use of IRC (for discovery or something?) ought to have been a red flag and made them ask for a precise spec of what IRC traffic should be expected and ensure they were proxying and filtering and logging all the IRC traffic. This wouldn't stop the creator from embedding more convoluted command channels in something that looks like the normal message exchange with peers, but this was just way too easy.

There'd still be plenty of scope for malicious code. E.g. the daemon could still have stolen all LuckyCoins deposited, for example, without requiring any suspicious communication, but at least with proper sandboxing and firewalling it'd be (if done right) isolated to that specific coin.

Reply on news.ycombinator.com