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);".
