Isn'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.
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.
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.
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.
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.
...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.
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.
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.
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.
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?
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.
Los Angeles
California
ISP: Hugeserver Networks Llc
It's very unusual for malware to be hosted in USA so I would assume that either it is a compromised computer/bot or it is some script kiddie using his home connection, the latter is more likely since there were no exploits used just social engineering and luck.
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.
> 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.
+-------------------------------------------------------+
| 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 |
+-------------------------------------------------------+
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."
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?
> 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.
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.
> 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.
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.
> 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.
Bitcoin: a currency for regular, everyday exchange.
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.
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.
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.
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.
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.
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.)
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.
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.
>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.
Yep, probably an exploit, there aren't many good reasons for a 10x10 applet. Let's download the jar. It contains a single 3.5KB payload. Let's use a Java decompiler (JD-GUI).
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.
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."
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.
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.
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.
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.)
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.
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.
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.
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).
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]
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.
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.
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.
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.
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.
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.
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.
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);".
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 ...
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.
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.
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).
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.
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
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 :-)
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.
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 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.
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.
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 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?
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?
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?
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.
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.
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.
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.
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).
This particular attack doesn't even involve a Java exploit. The weak point here is users who are accustomed to clicking "allow" on any security warnings without reading them.
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.
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.
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.
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.
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.
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.