Live data from Hacker News

Bitcoin exchange hacked via Rails exploit, funds stolen

bitcointalk.org

261–270 of 279 posts

Re: Bitcoin exchange hacked via Rails exploit, funds stolen

#261
post #76

Earlier quoted context omitted.

Bullshit. Rails pushes low time to market. That is all. Its built with precisely no engineering design or quality control on top of a poorly specified rickety language in a community of hype. However, my original generalizes the problem as a human issue which is where the real problem is: Did they do a risk analysis on rails - no Did they verify their architecture - no Did they perform input/type checking - no (sorry…

>Did they do a risk analysis on rails - no Actually, this bug was discovered precisely because people began to perform a more in depth analysis. >Did they perform input/type checking - no (sorry but statically typed languages win here) LOL. It's 2013. Can we stop having this preposterous argument?

"Actually, this bug was discovered precisely because people began to perform a more in depth analysis."

From Wikipedia: Ruby on Rails - Initial release July 2004

Eight-and-a-half years later, in depth analysis has come about to find this? (The exploit is present through 3.2, meaning it's been around all that time).

Re: Bitcoin exchange hacked via Rails exploit, funds stolen

#262

Earlier quoted context omitted.

Are you thinking of Heroku? Heroku isn't a bank.

It was probably Santander: http://www.h-online.com/security/news/item/Santander-s-onlin... , though there have been other instances of bad bank web practices.

Putting plaintext passwords in a cookie doesn't sound anything like incrementing an integer in a URL.

Re: Bitcoin exchange hacked via Rails exploit, funds stolen

#263
post #36

Earlier quoted context omitted.

Bitcoin bank developers commonly "do it wrong."

Seems like it's high time for someone to come along who knows how to do it right.

I think someone has, but they ran off with the money of their users.

Re: Bitcoin exchange hacked via Rails exploit, funds stolen

#264
post #228

Earlier quoted context omitted.

You're still making no sense. Various large projects, including the kernel, have seen silent security patches (yes, even by Linus himself). Also there is no "downplaying" in declaring any kind of problem as a remote SQL injection vulnerability. That is still obviously urgent enough for everyone to patch immediately. Yet it doesn't attract blackhats in the same way as blarting "remote code injection".

Mis-labeling a Remote Code Execution vulnerability as SQL-I is absolutely downplaying the severity. SQL-I is a bad finding, RCE is tantamount to the worst thing you could possibly find in an application. There were people on this very site who were commenting about whether they should concern themselves with this patch (initially because people erroneously attributed the vuln to SQL-I, and then later because they "we…

Well, the votes are strongly in your favor, but I remain unconvinced - accepting that I'm in the minority here.

For me this very article (bitcoin exchange being hacked) demonstrates that despite the harsh wording, the advisory didn't reach everyone in time. Not even those who should really care (like bitcoin exchanges).

I still think the explicit disclosure did more harm than good, by drawing maximum attention from the blackhat-community without really improving the reach amongst the oblivious. I still think a "staged" disclosure might have worked better, even at the risk of the timeline being short-circuited by a malicious party spilling the beans early.

However, there's little point bemoaning this particular baby or bathwater much more now.

I'm more interested in the steps that the Rails-team will be taking to lessen the blow by future security incidents. As I've said in another thread I'd be in favor of an optional (opt-in) kill-switch, to be triggered only in drastic cases like this one. Perhaps that is a point where we can agree again - otherwise we'll have to part in disagreement. :)

Re: Bitcoin exchange hacked via Rails exploit, funds stolen

#265
post #264

Earlier quoted context omitted.

Mis-labeling a Remote Code Execution vulnerability as SQL-I is absolutely downplaying the severity. SQL-I is a bad finding, RCE is tantamount to the worst thing you could possibly find in an application. There were people on this very site who were commenting about whether they should concern themselves with this patch (initially because people erroneously attributed the vuln to SQL-I, and then later because they "we…

Well, the votes are strongly in your favor, but I remain unconvinced - accepting that I'm in the minority here. For me this very article (bitcoin exchange being hacked) demonstrates that despite the harsh wording, the advisory didn't reach everyone in time. Not even those who should really care (like bitcoin exchanges). I still think the explicit disclosure did more harm than good, by drawing maximum attention from t…

I don't understand how the Rails team could plausibly have slowed down the disclosure. The exploit wasn't proprietary information, and it was easy to find.

Re: Bitcoin exchange hacked via Rails exploit, funds stolen

#266
post #264

Earlier quoted context omitted.

Well, the votes are strongly in your favor, but I remain unconvinced - accepting that I'm in the minority here. For me this very article (bitcoin exchange being hacked) demonstrates that despite the harsh wording, the advisory didn't reach everyone in time. Not even those who should really care (like bitcoin exchanges). I still think the explicit disclosure did more harm than good, by drawing maximum attention from t…

I don't understand how the Rails team could plausibly have slowed down the disclosure. The exploit wasn't proprietary information, and it was easy to find.

I don't want to drag this out further (all said and voted I think), so I'll only briefly refer to my idea of an "obscured" patch. Not pretty by any metric and definitely not a template for future incidents. But I still think it could have stretched the timespan a bit between the discovery by security-researchers/rails-hackers - and that afternoon when our Rails-intern (beginner ruby frontend coder) proudly showed us how he reproduced it in his rails console...

Re: Bitcoin exchange hacked via Rails exploit, funds stolen

#267
post #207

Earlier quoted context omitted.

No. A thousand times. A bit more creativity should be allowed when handling a vulnerability of this magnitude. For example, publish a patch that escapes all input in curious ways, presumably to prevent SQL injection. Pad it, obfuscate the actual fix with code-noise, make it annoying to read. Then release it as some handwavy, semi-plausible "follow-up" to the previous SQL-injection, urging everyone to upgrade in small…

This is terrible. The OpenBSD/SSH team tried this once, with the channel bug. They released the privsep version of ssh which didn't fix but mitigated the bug, and told everybody there was a critical bug and you really, really wanted to upgrade. What happened next? Everybody from Alan Cox on down started complaining about how they weren't going to dance to somebody else's tune and they were going to wait to see the re…

Now that's an interesting reference!

I actually remember this incident (albeit blurredly, hell, was that really 10 years ago...).

I dug up a few snippets[1] and I think the main sources of the animosities back then were certain regressions caused by privsep (not a hassle-free change) and a bit of ego-clashing (Alan Cox, Theo).

Your summary of the events may be about right, but is "not wanting to dance to someone else's tune" really a good argument against an attempt at responsible disclosure?

[1] http://www.baylisa.org/pipermail/baylisa/2002-June.txt (at the bottom)

[1] http://seclists.org/bugtraq/2002/Jun/300

Re: Bitcoin exchange hacked via Rails exploit, funds stolen

#268

Earlier quoted context omitted.

Gold is inherently useful as a tangible object with exploitable physical properties. Gold, for example, has good conductivity and is used to plate electrical connections. Gold is also useful for its rust-resistance. Thus, on this basis, like all useable physical goods, gold has some inherent value as a commodity.

Bitcoin has inherent value and "physical properties" that far exceed what Gold can offer. 1. Bitcoins can't be counterfeited. If you receive them with even just a few confirmations on the blockchain, it's probably going to be there forever. 2. You can confirm the legitimacy of Bitcoins, en masse, without any cost. 3. You can store bitcoins without any cost. 4. Bitcoins are much easier to transfer to other people. 5.…

None of these points have anything to do with an intrinsic value for bitcoin; all of them presuppose that bitcoin is intrinsically valuable.

Bitcoin can be worthless and yet hard to counterfeit; I can sign a random number right now and it's worth nothing. I can Tweet that number or create a permanent record in any number of other ways.

Your second point is the same as your first; it again presumes that there is some value to bitcoin.

I can store a lot of things without meaningful cost. That doesn't make them valuable. My application server with seven gigs of dev logs isn't a treasure trove either, despite the ease with which I managed the data relative to bars of gold.

Bitcoins are easier to transfer than gold coins. That is true. But spent facial tissue is also easier to transfer than gold.

You can form contracts with all manner of instruments, from cows to gravel to pork bellies. Every commodities trader in Chicago has a story about a friend of a friend who ended up with a garage full of pork when they failed to sell a futures contract in time.

Re: Bitcoin exchange hacked via Rails exploit, funds stolen

#269

Earlier quoted context omitted.

Why do you need to government to require that? How about you only rent from land lords that disallow tenants from renting out their apartment. Maybe some people don't mind this and would like to have that as an option.

Because that's not always an available option in the housing market. There are some cities (for example, present day San Francisco) where city wide apartment vacancy is so low that tenants basically have to take what they can get. Tenants are at a serious disadvantage to the whim landlords in this kind of market. Thus laws exist that restrict what landlords are allowed to provide, which serves to protect the tenants.…

And the inadequate amount of housing availability is because of government regulation as well. If they would allow more building this would be less of an issue.

Re: Bitcoin exchange hacked via Rails exploit, funds stolen

#270
post #171

Earlier quoted context omitted.

How are those "problems inherent in the peer-to-peer model"? Aren't those problems any business in the industry has to face?

They are inherent in peer-to-peer because peer-to-peer transactions are based on trust, and trust ultimately has to be based on accountability. If I'm in a small town, I can trust a local resident because I know their history and where they live. If they injure or steal from me in some way, I have some recourse, if nothing else with the social shame that can be brought to bear in a small society. But in a large-scale…

Are you saying that AirBnb, for example, can't be the regulatory body for its customers? Or is there a reason why it's necessary for the government to step in?
Post reply on HN