Dr Web Flashback Virus checker accurate?

jsd2 wrote:

The commands as written without the quotes look OK to me

Precisely.

defaults read /Applications/Safari.app/Contents/Info LSEnvironment

will return the value of the LSEnvironment key in Safari's Info.plist; whereas

defaults read "/Applications/Safari.app/Contents/Info LSEnvironment"

will return an error, because the blank space will be interpreted literally (instead of as the separator between the domain and the key). Defaults will attempt to read the file </Applications/Safari.app/Contents/Info LSEnvironment.plist>, which, of course, does not exist.

MadMacs0 wrote:

I've scanned through all the test that were run and they all seemed to have focused on removing a full infection. You've told us that you have Office 2008 installed, so a Type 2 infection probably could not have happened. I think we can rule out a Type 1 infection from the "K" variant, ...

Yeah, I've lost track of type 1s and type 2s and K's and Q's and 36's. I have seen suggestions:

http://macmark.de/blog/osx_blog_2011-10-d.php

http://macmark.de/blog/osx_blog_2012-04-a.php

that say any type of infection other than the basic user-level ~/.MacOSX/environment.plist doesn't actually work. It seems that the MacOS X system architecture is designed to prevent that. If you attempted to use that method, it would just crash the software. That is what I found when I tried to install my own demo trojan at the system level. Apple's documentation backs that up.

And yes, I can't dismiss the possibility that Dr. Web is wrong or that duplicate UUID's exist. Just thought it might be worth looking a little harder at this since it's apparently our first effort at a Dr. Web positive and possibly something new that we won't read about until the bloggers get back to work after their Easter weekend.

I am not interested in "bloggers at work". They seem to be more of a problem than a solution. All they have done is spread fear about unproven claims by people with a financial interest in said fear.

I'd be interested in looking at a sanitized version of the log.

Thanks.

Robert

Not sure how accurate is Dr. WEB (found timestamp between 03-07 Apr when I ran it) BUT in my case there was definitve flashback.36 and I used f-secure's command based check and found nothing, then I used 3 different antivirus, all found it but unable to clean. It looks like it infects deep into safari.app. I mistakenly supplied admin password while it first attacked. And then it was all over. I just finished wiping and clean new install of OSX.

jo823 wrote:

I do not have Little Snitch installed. I don't have any sort of malware or anti-virus scanners running on my Mac at all. I know for certain that there were no dialogs requesting the admin password or any sort of downloads recently. I completed the most recent Apple Software update yesterday (10.6 update 7 on 4/7/12), and prior to that the only changes I remember is a previous software update (10.6 update 6 on 3/4/12).

Those look to be the last two Java Updates that were posted and there should have been a Security Update 2012-001 made available in February, but none of those really matter. The dialog in question did not identify the software being installed, it just would have asked for your password. It would have looked something like this

I also don't recall any strange activity on the dates that came up in the Dr Web check. I only even looked into this because I kept hearing about it on the news, and didn't think I'd have a problem.

After giving this more thought last night, I realize that my logic was quite faulty concerning the date of infection. I now think that that first date and time are more likely when Dr.Web got their server on-line to start collecting data. It's possible you were infected long before that date.

We haven't had much luck with this one, but there is this site that is supposed to be able to detect bot activity http://botnetchecker.com/.

Most ISP's have software that can check for this, but some seem notorious for falsely detecting.

Perhaps the quickest way to resolve this would be for you to install the three hour trial of Little Snitch ($30 if you purchase) and see what it has to say. Another option is Hands Off! in demo mode ($25 to purchase), but I'm not familiar with it.

And then there's always the Terminal to look for something that looks like the downloader:

ls -la ~/

ls -la ~/Library/LaunchAgents/

rajanatwal wrote:

Not sure how accurate is Dr. WEB (found timestamp between 03-07 Apr when I ran it) BUT in my case there was definitve flashback.36

Yes, I've revised my thinking on that. Looks like the 3 April date is when they got their server up and collecting data, so you were undoubtedly infected way before that.

Glad you're back in business.

rccharles wrote:

I'd be interested in looking at a sanitized version of the log.

Here you go:

For all 4 defaulsts commands listed, I get the "does not exist" response.

Not sure about the Launch Agents list however:

Last login: Sat Apr 7 18:12:21 on ttys000

new-host:~ username$ defaults read ~/.MacOSX/environment

2012-04-07 18:12:38.021 defaults[11021:903]

Domain /Users/username/.MacOSX/environment does not exist

new-host:~ username$ defaults read /Applications/Safari.app/Contents/Info LSEnvironment

2012-04-07 18:12:55.444 defaults[11022:903]

The domain/default pair of (/Applications/Safari.app/Contents/Info, LSEnvironment) does not exist

new-host:~ username$ ls -la ~/Library/LaunchAgents

total 16

drwx------ 4 username staff 136 Mar 27 19:09 .

drwx------+ 39 username staff 1326 Mar 12 2011 ..

-rw-r--r-- 1 username staff 919 Sep 15 2009 com.apple.CSConfigDotMacCert-username@me.com-SharedServices.Agent.plist

-rw-r--r--@ 1 username staff 488 Mar 27 19:09 null.plist

new-host:~ username$ grep "/Users/$USER/\..*" ~/Library/LaunchAgents/* | grep -v "/Users/$USER/\.Trash" /Users/username/Library/LaunchAgents/null.plist:<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"> <dict><key>Label</key><string>null</string> <key>ProgramArguments< /key><array> <string>/Users/username/.null</string></array> <key>RunAtLoad </key><true/><key>StartInterval</key> <integer>4212</integer><key>StandardErrorPath</key> <string>/dev/null</string><key>StandardOutPath</key> <string>/dev/null</s tring></dict></plist>

new-host:~ username$ defaults read /Applications/Firefox.app/Contents/Info LSEnvironment

2012-04-07 18:15:04.187 defaults[11026:903]

The domain/default pair of (/Applications/Firefox.app/Contents/Info, LSEnvironment) does not exist

new-host:~ username$ defaults read /Applications/Safari.app/Contents/Info LSEnvironment

2012-04-07 18:15:17.155 defaults[11028:903]

The domain/default pair of (/Applications/Safari.app/Contents/Info, LSEnvironment) does not exist

Ok, I re-ran with those commands in quotes and got the same responses.

new-host:~ username$ defaults read "/Applications/Safari.app/Contents/Info LSEnvironment"

2012-04-07 18:33:38.620 defaults[11054:903]

Domain /Applications/Safari.app/Contents/Info LSEnvironment does not exist

new-host:~ username$ defaults read "/Applications/Firefox.app/Contents/Info LSEnvironment"

2012-04-07 18:33:55.733 defaults[11055:903]

Domain /Applications/Firefox.app/Contents/Info LSEnvironment does not exist

new-host:~ username$ defaults read "/Applications/Safari.app/Contents/Info LSEnvironment"

2012-04-07 18:34:07.821 defaults[11056:903]

Domain /Applications/Safari.app/Contents/Info LSEnvironment does not exist

new-host:~ username$

etresoft wrote:

rccharles wrote:

I'd be interested in looking at a sanitized version of the log.

Here you go:

For all 4 defaulsts commands listed, I get the "does not exist" response.

Not sure about the Launch Agents list however:

Last login: Sat Apr 7 18:12:21 on ttys000

new-host:~ username$ defaults read ~/.MacOSX/environment

2012-04-07 18:12:38.021 defaults[11021:903]

Domain /Users/username/.MacOSX/environment does not exist

new-host:~ username$ defaults read /Applications/Safari.app/Contents/Info LSEnvironment

2012-04-07 18:12:55.444 defaults[11022:903]

The domain/default pair of (/Applications/Safari.app/Contents/Info, LSEnvironment) does not exist

new-host:~ username$ ls -la ~/Library/LaunchAgents

total 16

drwx------ 4 username staff 136 Mar 27 19:09 .

drwx------+ 39 username staff 1326 Mar 12 2011 ..

-rw-r--r-- 1 username staff 919 Sep 15 2009 com.apple.CSConfigDotMacCert-username@me.com-SharedServices.Agent.plist

-rw-r--r--@ 1 username staff 488 Mar 27 19:09 null.plist

And there it is with a DTG of Mar 27 19:09 null.plist!

etresoft wrote:

http://macmark.de/blog/osx_blog_2011-10-d.php

http://macmark.de/blog/osx_blog_2012-04-a.php

that say any type of infection other than the basic user-level ~/.MacOSX/environment.plist doesn't actually work.

I've only read the first link, and it says the environment.plist doesn't work, because it is ignored. In fact, the author is wrong; it does work, and the library is loaded. We have plenty of proof here, in this forum—users who still ran Word 2004, which crashed because the loaded library was Intel, while Word 2004 is still PPC. Intel apps did not crash.

Apple's documentation backs that up.

Could you please elaborate on that? I see nothing relevant to this in the dyld manpage.

It launches this executable

<key>ProgramArguments< /key><array> <string>/Users/username/.null</string></array>

There was a recent thread here that reported the same names:

.null want to connect to krymbrjasnof.com-another Flashback variant

The other Terminal tests there were negative. The OP there suggested that the infection never got past the preliminary installation phase because Little Snitch reported the attempt and no further communication took place.

The problem is that you can't count on it having a name like "null.plist" or ".null". There is no DYLD_INSERT_LIBRARIES in this case. Perhaps it could get installed later.

I suppose I should update my script. While future variants could use different names, the updated Java should prevent any subsequent installations. I will have to hope that all malware exectuables start with ".".

etresoft wrote:

The problem is that you can't count on it having a name like "null.plist" or ".null". There is no DYLD_INSERT_LIBRARIES in this case. Perhaps it could get installed later.

That's correct. The two that are on his hard drive are part of the installer that are put there by the Java applet. The one in the Home folder is responsible for contacting the C&C Server to recieve commands about what to do next, check to see what Type of installation is possible, then download and install the appropriate binaries. Last weekend we found maybe a half dozen names for these two files. I'd have to wade through 200+ entries to find them all the pairings. The first reported was .rserv then .mkeeper, .null, .jupdate and probably one or two others. They were paired with titles like com.adobe.reader.plist (with a small "r"), null.plist, etc. It is thought that these two components are deleted as the final step in the infection process. Because so many Little Snitch users interupted the process at the beginning we were able to find them pretty easily and before they had a chance to do any real damage (we think). I can't really explain what happened here, but something must have interupted things, yet his transponder is still active.

I suppose I should update my script. While future variants could use different names, the updated Java should prevent any subsequent installations. I will have to hope that all malware exectuables start with ".".

I don't really think that's possible. My home folder is full of ".*" files that belong there and the LaunchAgents are often hard to pick out. Finding the date of installation makes it easier, but where do you go from there?

See the "Additional Details" discussion in the F-Secure Flashback-K page regarding the sequence - there is an "Installation" phase, a "payload download" phase, and finally, an "Infection" phase.

The first phase apparently also creates a "downloader" file in /tmp in addition to the hidden "updater" file in Home and the LaunchAgent. That downloader might still be around if one hasn't restarted.

MadMacs0 wrote:

I suppose I should update my script. While future variants could use different names, the updated Java should prevent any subsequent installations. I will have to hope that all malware exectuables start with ".".

I don't really think that's possible. My home folder is full of ".*" files that belong there and the LaunchAgents are often hard to pick out. Finding the date of installation makes it easier, but where do you go from there?

I've updated my script to be more thorough and check for partial installations. The LaunchAgents folder is tricky. Anything that starts with "." definitely needs to go. Anything else will have to be reviewed on a case-by-case basis. It is always a good idea to keep an eye on that folder anyway. Some legitimate applications have been known to drop auto updaters in there.