11 ms·

I can't get to the article at the moment, but I'd love to know why they failed to update their app especially since it handles financial transactions. I had se

• kindaobv 14y ago
  Hey, are you also basically free, well-advertised and available to everyone in the world who is running rails simultaneously I don't understand why they also didn't use you then.
• anonymouz 14y ago
  Cache: https://webcache.googleusercontent.com/search?q=cache%3Ahttps%3A%2F%2Fbitcointalk.org%2Findex.php%3Ftopic%3D135919.0 https://webcache.googleusercontent.com/search?q=cache%3Ahttp... . It's a forum post without any details - your question is raised, but has (so far) not been answered.
• utnick 14y ago
  It's not excusable really, but I'm not too surprised. It was only a day or so from when a patch was available to when a public exploit was everywhere. Maybe they were on vacation, maybe the site was built by contractors who have since moved on, maybe they don't read hackernews or other programming news sources. I expect to see similar stories in the coming weeks.
• revelation 14y ago
  Or, you know, why their wallet is compromised just because the web interface is. It's like a CA that creates the certificates in PHP right there.
  • btilly 14y ago
    This is a remote code exploit. For the web interface to do its job, it needs to be able to manipulate the wallet. They can stare at the code that does that, write their own, and do whatever they want.
    • revelation 14y ago
      Why does a web interface need to directly manipulate the wallet? It needs to store the transactions somewhere where the machine that executes them (using the wallet) can find them. You need the seperation and you need to closely monitor and control the transactions requested from the web interface to detect any fraud or misuse.
      • btilly 14y ago
        Doesn't matter whether you do it directly or indirectly. There is some way of automatically manipulating money, and it will discover what it is. I can dream up architectures which limit manipulations, require the user to constantly type in passwords, etc. A company not security conscious enough to update is unlikely to have done that. But suppose they did, what happens? EVEN THEN you can turn the website into the digital equivalent of an ATM skimmer, and steal money. That is, of course, assuming that I have not managed to turn shell access into some more direct compromise of your whole network. Here is the moral. If you're directly handling money or a money equivalent on your website, and someone has shell access, they will be able to steal from you.
        • cstejerean 14y ago
          That's why you put velocity controls in place, so that if things go south you can limit losses. Coupled with alerting/reporting on transaction volumes and you should be able to get ahead of someone that bypassed your front end before they make off with all of your cash. That said, if the backend is also vulnerable to the same or another exploit, that's not going to buy you much.
    • rprasad 14y ago
      A secure bitcoin service provider should never manipulate the wallet directly, or in realtime. Transactions should be handled transparently, logged, and then actuall excuted on the offline wallet later after fraud and loss mitigation routines have been applied.
• bradleyland 14y ago
  This vulnerability went from disclosure to exploit extremely quickly. The CVE was published on the 8th. I can't speak for them, but in the process of trying to update, we ran in to some issues with therubyracer (a core component of the Rails asset pipeline) and libv8 (the library that therubyracer uses to embed the V8 engine). It was extraordinarily bad timing, and it slowed down our update process by almost a day while waiting on a new version of therubyracer and libv8 to hit. Having said all that, if our upgrade holdup had taken any longer than it did, we would have implemented one of the mitigation strategies.
  • tptacek 14y ago
    You cannot leave your site open to a pre-auth remote code execution vulnerability while you wait for fixes to the asset pipeline or to any other component of Rails. I don't know that that's what you're saying you did but we need to be glacier-blue-ice-clear about this. Nobody gets to wait on bugs like this. You patch or workaround immediately or, most probably, you shut your app down.
    • jimktrains2 14y ago
      Weren't there patches for rails, and release for rails with the patches, really quickly from release?
      • tptacek 14y ago
        Yes, along with workarounds. I'm reacting to the inference that someone might wait to apply the patches because they broke the Asset Pipeline somehow.
    • bradleyland 14y ago
      It slowed down the update (to 3.2.11), but it didn't prevent us from removing the XML parser from DEFAULT_PARSERS immediately. I'm not defending anyone here. I'm simply pointing out that the scenario wasn't exactly status quo. This has all moved very quickly. EDIT: I guess that qualifies as a mitigation strategy, but when I said that, I was talking more along the lines of the patches, or like another person I know, even more dramatic steps like forking Rails. There are regressions in the 3.2.x updates since 3.2.9 that affect some sites. Bottom line is that there was a lot of bad timing here that sucked up a lot of time in securing a Rails site.
• jart 14y ago
  I think an even better question is why they didn't have multiple layers of security that would have prevented a bug in a public facing server from compromising financial data. When systems are designed with security in mind, rather than simply throwing together a web/sql application, people put a lot of time and effort into constructing barriers to protect the integrity of their data. Take for instance the CACert certificate authority. They designed their system in a way where the master key that signs certificates is stored in a computer that isn't connected to any network. The actual servers then talk to this computer over the serial port using a carefully crafted API when they actually want a certificate signed. This means signing certificates is slow and the key is inaccessible. So if all their servers got remotely compromised, a hacker would never be able to get the key and at best would probably be able to sign a short list of certificates before being detected.
  • runeks 14y ago
    This is really the proper way to do it. Other people have suggested that this black box should store public/private key pairs generated from the user's password for each user on the exchange. So when a user signs up for an account on the exchange, Javascript code generates a private key from the user's password, client side. The corresponding public key is sent and stored in the offline transaction signing box. Whenever the user wants to initiate a withdrawal, the transaction signing box creates a random number that needs to the signed with the private key that corresponds to the public key it has on store. This way an attacker need to compromise a server and install an eaves dropping application that replaces new users' (or existing users changing their password) real public keys with its own. Just breaking into the server wouldn't do the attacker any good at first.
    • politician 14y ago
      Bitcoin supports "cold storage" which is effectively a wallet that can receive funds, but is offline so you cannot transfer funds out of it. That is, the private key is stored offline. There is really no excuse for exchanges not using cold storage.
      • 14y ago
• rmc 14y ago
  The simple, and harsh reason is because they are incompetent.
• illuminate 14y ago
  "I'd love to know why they failed to update their app especially since it handles financial transactions" Because these exchanges focus more on promoting the "world changing" ideology than they do on taking their users' money seriously.
• kawsper 14y ago
  They should have pulled the plug on it, if they couldn't manage to upgrade in time.