"Rosetta" applications suddenly stopped working

MadMacs0 wrote:

One of the other users found out by double-clicking one of the files and having a quarantine warning pop-up (which is the first confirmation that quarantine even works with this variant), but that's not the safest method.

The file that you are referring to was called .FlashEXEShell.tmp and located in ~/Library/Application Suport/ this file is 404KB in size, and I suspect contains the code for doing the majority of the trojans dirty work.

This file was referenced from within the .libgmalloc.dylib which in turn was referenced from the environment.plist.

I didn't risk opening .FlashEXEShell.tmp by double clicking it, but I <ctrl> clicked it and used the "Open With" command to open it with TextEdit - this resulted in the warning pop up that shows what downloaded it and when it was downloaded :

Its a pity it doesn't list where it was downloaded from - does anyone know where this information comes from?

A few comments.

(1)

Brian Stroud wrote:

does anyone know where this information comes from?

I suspect it comes from the com.apple.quarantine extended attribute. It may be read with

$ xattr -p com.apple.quarantine path_to_file

Interpreting the result, though… that's another matter.

(2)

Regarding spreading through e-mail—that's unlikely. The Trojan Horse relies on two methods. First, it's ye olde social engineering trick, pretending to be a Flash installer, or Software Update, or something like that. As such, this is not possible in Mail. An app containing this code could be mailed as an attachment, but the user would have to jump through one or two hoops to execute it—it can't be no more than a pop-up asking for authentication (as it can in a web browser).

Second, it's using the Java vulnerability, which doesn't require user interaction. Mail doesn't do Java, so that's out.

(3)

Regarding getting rid of it. In a previous conversation with MadMacs0, a couple of weeks or so ago, I expressed my unease at the reliance on file names and paths to control this thing. I warned that there were other ways than environment.plist to load shared libraries, and, sure enough, its author(s) were using other ways.

So, yes, you can disable it with environment.plist, and get rid of the shared libraries, and go through all Info.plists and get rid of any shared library referenced by LSEnvironment keys. But how do you know that was all? How do you know there's no shared code library left behind in some convenient nook or cranny; and, that next week, or the week after that, they won't figure a way of getting back in (there are a dozen or so still unpatched vulnerabilities in Java), and, this time, instead of getting the payload from a remote server, it'll just look for something left behind by the previous infection? These guys are a little too clever for comfort; call me paranoid if you like, but I think that the only safe way of getting rid of it is a clean slate.

Brian Stroud wrote:

MadMacs0 wrote:

One of the other users found out by double-clicking one of the files and having a quarantine warning pop-up (which is the first confirmation that quarantine even works with this variant), but that's not the safest method.

The file that you are referring to was called .FlashEXEShell.tmp and located in ~/Library/Application Suport/ this file is 404KB in size, and I suspect contains the code for doing the majority of the trojans dirty work.

This file was referenced from within the .libgmalloc.dylib which in turn was referenced from the environment.plist.

I didn't risk opening .FlashEXEShell.tmp by double clicking it, but I <ctrl> clicked it and used the "Open With" command to open it with TextEdit - this resulted in the warning pop up that shows what downloaded it and when it was downloaded...

Thanks for refreshing my memory. I would normally have gone back to check, but this thread has grown so large and my time has been short today, so I failed to do that.

For anybody reading this, it's important to note that the file names are randomly assigned so don't waste your time looking for those specific names. If it's a hidden file, it's certainly suspicious. True, some of these directories do have legitamate hidden files in them, but most do not. The extensions should be the same for the same Trojan variant, but the rest of the file name will most probably be different for every user. So far we've seen hidden files with extensions of ".so", ".xls", ".png" and ".tmp" IIRC.

Its a pity it doesn't list where it was downloaded from - does anyone know where this information comes from?

I think we know where they come from. The server's IP address has been well documented by the A-V vendors blogs for quite some time. It distributes the Trojan components, records vital statistics about every infected machine, receives Tweets from all infected machines periodically, provides command and control of each infected machine and probably is capable of updating the Trojan to provide bug fixes and additional capability.

Let us know if your xattr check reveals any additional info.

Remember that the DYLD_INSERT_LIBRARIES defined by environment.plist defined /Users/Shared/.libgmalloc.dylib so that's already a file outside your home directory, i.e., in /Users/Shared. And if code is injected into Safari, that's Safari counts as two. And it was said no one is 100% sure where or if other code may be inserted into your system. So until or if (remember it's a moving target with each new strain of the trojan) it can be determined what files are inserted and where the best that can be recommended is the "shotgun" approach and replace everything.

In addition to what X4 says, not a solution, but, for now, if you keep that computer off line, which seems its usual posture, nothing will be able to get out and back to the bad guys. But doesn't mean they don't already have some stuff from when it was connected. Only you can know if there was or is anything senstive or worth worrying about.

Disregard.

X423424X wrote:

if code is injected into Safari, that's Safari counts as two. And it was said no one is 100% sure where or if other code may be inserted into your system. So until or if (remember it's a moving target with each new strain of the trojan) it can be determined what files are inserted and where the best that can be recommended is the "shotgun" approach and replace everything.

According to F-Secure, a Flashback.I Type 1 infection puts 2 files into /Applications/Safari.app/Contents/Resources/ and adds a line to /Applications/Safari.app/Contents/Info.plist.

a Type 2 infection adds a total of three files to ~/Library/Application Support/, /Users/Shared/ and ~/.MacOSX/. It only injects code into applications after they are launched into RAM.

Of course there is no guarantee that this is the "I" variant and in previous versions there have been additional files produced during operation, such as logs that are probably harmless, just taking up space.

In any case, your point is well taken.

Brad,

A quick question if you haven't done anything to that infected Mac yet. Can you double check on what version of Java that machine is running, either by entering "java -version" without quotes in Terminal or opening Java Preferences (found in /Applications/Utilities/)? It will say J2SE 6.0 and version 1.6.0_xx.... If xx is 29 then it's up-to-date and I don't understand how it could have been infected.

NuLynx wrote:

java version "1.6.0_29"

Thanks, that's consistent with what others have told me over the past couple of days. Appears that they have found another way to infect.

A different vulnerability in the _29 or some other attack vector, not Java?

Either the patch did not patch, or it's another vulnerability. But IMHO it's Java—and there's no report so far of anyone infected who had Java disabled.

From F-Secure news, April 2, 2012

----------------

A new Flashback variant (Mac malware) has been spotted exploiting CVE-2012-0507 (a Java vulnerability). We've been anticipating something like this for a while now.

..

Oracle released an update that patched this vulnerability back in February… for Windows.

But — Apple hasn't released the update for OS X (yet).

It appears that the Flashback gang is keeping up with the latest in exploit kit development. Last week, Brian Krebs reported that the CVE-2012-0507 exploit has been incorporated into the latest version of the Blackhole exploit kit. And that's not all. Though it is unconfirmed, there are rumors of yet another available exploit for an "as-yet unpatched critical flaw in Java" on sale.

So if you haven't already disabled your Java client, please do so before this thing really become an outbreak. Check out our previous post for instructions on how to disable Java on your Mac.

--------------------

Thanks, jsd2. That clears up a few things.

Oracle released an update that patched this vulnerability back in February… for Windows.

But — Apple hasn't released the update for OS X (yet).

Hm. Business as usual for Apple. I guess all the bright ones have moved to iOS. (Btw, my Fujitsu Lifebook, despite of its being still under XP, has been safe from this for weeks.)