Dr Web Flashback Virus checker accurate?

fane_j wrote:

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 isn't that environment.plist doesn't work, that file (at the user level) does work. Indications are that the same method using DYLD_INSERT_LIBRARIES may not work at the system level. It requires DYLD_FORCE_FLAT_NAMESPACE to be set as well. If you try that in /etc/launchd.conf, you can't even log it. I suspect that if you try that in some (but perhaps not all) applications, they will just crash.

etresoft wrote:

It isn't that environment.plist doesn't work, that file (at the user level) does work.

The blog's author says the instruction is ignored:

"es nicht funktioniert: Mac OS X ignoriert diesen Eintrag in der ~/.MacOSX/environment.plist"

and he's wrong.

As to environment.plist, how could it work at system level? The question does not arise—it sets environment variables for the current user session.

Indications are that the same method using DYLD_INSERT_LIBRARIES may not work at the system level. It requires DYLD_FORCE_FLAT_NAMESPACE to be set as well.

I don't see how that has anything to do with the system level. By itself, DYLD_INSERT_LIBRARIES will not work with two-level namespaces images, period. DYLD_FORCE_FLAT_NAMESPACE does what its name says (which may create problems on its own, but that's another story). However, if the imported library uses a flat namespace, there's no need for DYLD_FORCE_FLAT_NAMESPACE.

Be that as it may, and assuming it doesn't work at the system level, so what? This malware doesn't need to get there. At its most basic, this thing is designed to steal money. And it doesn't need to get to the system level to steal money.

fane_j wrote:

The blog's author says the instruction is ignored:

"es nicht funktioniert: Mac OS X ignoriert diesen Eintrag in der ~/.MacOSX/environment.plist"

and he's wrong.

As to environment.plist, how could it work at system level? The question does not arise—it sets environment variables for the current user session.

Environment variables can be set at any point and will be in effect for any subsequent processes. The environment.plist file sets environment variables to be active for processes launched by the Aqua user interface.

You can do the same thing at a system level by adding commands to /etc/launchd.conf. You can do it for a specific application by modifying the info.plist file. Both of these modifications (may) require administrative rights with are all to frequently granted.

Indications are that the same method using DYLD_INSERT_LIBRARIES may not work at the system level. It requires DYLD_FORCE_FLAT_NAMESPACE to be set as well.

I don't see how that has anything to do with the system level. By itself, DYLD_INSERT_LIBRARIES will not work with two-level namespaces images, period. DYLD_FORCE_FLAT_NAMESPACE does what its name says (which may create problems on its own, but that's another story). However, if the imported library uses a flat namespace, there's no need for DYLD_FORCE_FLAT_NAMESPACE.

Because if you try it at the system level you won't even be able to log in.

At its most basic, this thing is designed to steal money. And it doesn't need to get to the system level to steal money.

No one knows what it is designed to do.

etresoft wrote:

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.

A couple of observations:

It would appear that nothing really happens unless you detect active DYLD_INSERT_LIBRARIES. Since the .updater/LaunchAgent componet is active before installing the payload and supposedly deleted after doing it's thing, shouldn't those be the first things checked? I'm guessing it would not have detected those files for this user or any of the Little Snitch folks last week.

I see you have an option to scan all applications for the presence of payload binaries. I suspect that is overkill at the present time. The "K" variant only injects into Safari but previous versions apparently involved Firefox, Chrome and Skype. From the information I have for a Type 2 infection, code is injected into all launched applications after they are in RAM, not on the hard drive. So I would be surprised if it show up during your scan. Perhaps better safe than sorry, but I assume it is time consuming.

etresoft wrote:

Environment variables can be set at any point and will be in effect for any subsequent processes.

…For the current session, if defined in environment.plist. Because we're not talking environment vars in general. This is about a specific instruction in a specific file, and the German blogger was wrong about it. And the system level is not relevant, because environment.plist is not relevant at that level.

You can do the same thing at a system level by adding commands to /etc/launchd.conf.

What has launchd.conf got to do with our specific issue? I saw no reports of Flashback attempting to create launchd.conf or modify it (if it exists). Are we talking hypotheticals, or are we talking real-world malware?

No one knows what it is designed to do.

I beg to differ. I think the evidence shows quite clearly what it is designed to do.

First of all, do you have a real mac computer? As I know some hackintosh has identical UUID. And our service provide infected information only for Backdoor.Flashback.39 which uses .plist in ~/Library/LaunchAgents and arbitrary file in user home directory ~/.<filename>

lytic wrote:

First of all, do you have a real mac computer? As I know some hackintosh has identical UUID. And our service provide infected information only for Backdoor.Flashback.39 which uses .plist in ~/Library/LaunchAgents and arbitrary file in user home directory ~/.<filename>

I eventually found his LaunchAgent null.plist and we're waiting for him to come back to tell him how to proceed.

Are you saying these files persist after a complete infection? We were under the impression that they were deleted after either a Type 1 or Type 2 completed and Binary 1 (these are F-Secure terms) took over the communications function.

The reason we were finding the first two last weekend was because of Little Snitch, but he doesn't have it installed, so we can't quite figure out why those files are still present and active.

MadMacs0 wrote:

It would appear that nothing really happens unless you detect active DYLD_INSERT_LIBRARIES. Since the .updater/LaunchAgent componet is active before installing the payload and supposedly deleted after doing it's thing, shouldn't those be the first things checked? I'm guessing it would not have detected those files for this user or any of the Little Snitch folks last week.

I might be better to make these comments on the User Tip itself, but I appreciate the feedback.

You seem to be refering to the old version. I recently updated it to be much more paranoid. Now, the only thing that is dependent on an active DYLD_INSERT_LIBRARIES is a launchctl command to remove that variable. The LaunchAgent would be already gone at that point.

I see you have an option to scan all applications for the presence of payload binaries. I suspect that is overkill at the present time. The "K" variant only injects into Safari but previous versions apparently involved Firefox, Chrome and Skype. From the information I have for a Type 2 infection, code is injected into all launched applications after they are in RAM, not on the hard drive. So I would be surprised if it show up during your scan. Perhaps better safe than sorry, but I assume it is time consuming.

It's all overkill. The 600k number was just bogus. The only meaningful impact is the perception that Macs are now at risk for viruses. All I'm doing is trying to reassure people that they aren't at risk. Plus, I want to show how easy it is. The anti-virus companies are posting very complex command-line scripts in an effort to show how complex and difficult it is to remove the pathetic excuse for a trojan. They just want to sell software. Removing the trojan is easy. Writing the trojan is eady. Getting Applescript to work - that's hard. I finally figured out that in order to move a file to the trash, I had to cast the path name string as a string first. Silly me. Why didn't I think to cast the string as a string?

When run on my Snow Leopard machine it completes fine. When run on my Lion machine I get the following error;

Got any ideas?

Steve H

Maybe this decompiled java class from exploit could useful for you:

etresoft wrote:

I might be better to make these comments on the User Tip itself, but I appreciate the feedback.

I tried that once before and was unable to post, but next time I'll try again.

You seem to be refering to the old version. I recently updated it to be much more paranoid. Now, the only thing that is dependent on an active DYLD_INSERT_LIBRARIES is a launchctl command to remove that variable. The LaunchAgent would be already gone at that point.

I was just going by the AppleScript you posted and didn't try to download it.

jo823 wrote:

Any advice about how to proceed?

I've got mixed feelings about this one. Until recently I was under the impression that the two files you've found were deleted after the infection process completed, but now I'm not so sure that information was correct and I haven't been able to get confirmation one way or the other. For those that had Little Snitch in originally, most of us ended up deciding it was sufficient to delete those and move on. Since most of the testing you had already done when I got here came up empty, I'm at a loss to know the real state of your computer. So here's the advice I've been giving to everybody suspected of being infected by the last couple of variants, Courtesy of Linc Davis:

You installed a variant of what’s commonly called the “Flashback” malware, although the name is obsolete.

If you’re certain you know when that happened, and you back up with Time Machine or something similar, you can save yourself a lot of time by restoring your whole system from the most recent snapshot taken before it was infected. Then take Steps 7, 8, and 10 below.

How can you tell when the infection took place? All you can be sure of is that you were infected some time before the problems started. You may have visited a blog that prompted you to install some kind of software, or a “certificate.” If you remember doing that recently, mention it in a reply, but don’t post a link.

If you don’t know when you were infected, there's no easy, reliable way to remove the malware, because it's constantly changing. I suggest you take the following steps immediately:

1. Back up all data to at least two different devices, if you haven't already done so.

2. Boot from your recovery partition (if running Mac OS X 10.7 or later) or your installation disc (if running an earlier version of the Mac OS), launch Disk Utility, and erase the startup volume. This action will destroy all data on the volume, so you must be sure of your backups.

3. Install the Mac OS.

4. Reboot and go through the initial setup process to create an account with the same name as your old one. Don’t import anything from your backups at this stage.

5. If running Mac OS X 10.6.x or earlier, run Software Update. You may have to run it more than once to fully update your system.

6. Restore the contents of the top-level subfolders of your home folder except “Library” from the most recent backup. The Library folder may contain components of the malware. It’s best not to restore anything from there. If you must do so, restore only files, not folders, and only if (a) they’re visible in the Finder, and (b) you know what they are, and (c) they haven’t been altered. Don’t restore anything in the home subfolder Library/LaunchAgents, if it exists, or any hidden files or folders, no matter where they are.

7. If you’re running Mac OS X 10.5.8 or earlier, launch Safari and select Safari ▹ Preferences… ▹ Security from the menu bar. Uncheck the box labeled Enable Java. Because of known bugs, Java in those OS versions is unsafe to use on the Internet. (Note: I’m not referring to JavaScript, which is unrelated to Java, despite the similar names.) If you’re running Mac OS 10.6.8 or later, you should still disable the Java web plugin unless you really need it. Few websites have legitimate Java content nowadays. If you encounter one that does, enable Java temporarily.

8. Change every Internet password you have, starting with banking passwords. Check all financial accounts for unauthorized transactions. Take this step only after you’ve secured your system in the preceding steps, not before.

9. Reinstall your third-party software from fresh downloads or original media, not from backups which may be contaminated.

10. If you use any third-party web browsers, disable Java in their preferences. As with step 7, this step is mandatory if you’re running any version of Mac OS X older than 10.6. Otherwise it’s optional, but recommended.

I suspect others will be here shortly to offer alternatives if you find this too difficult. I know that etresoft modified his script https://discussions.apple.com/docs/DOC-3271 last night to eliminate the two files you found.

jo823 wrote:

Update-downloaded Little Snitch and got the message "Little Snitch: .null wants to connect to vxvhwcixcxqxd.com"

Bad, bad bad. 😟

Your infected, that url and many others like it all all over these forums and other Mac sites related to Flashback.

urlQuery gives

URL	http://vxvhwcixcxqxd.com/info.html
IP	91.233.244.102
ASN	AS57636 Olborg Ltd.
Location	Russian Federation
Report created	2012-04-05 23:00:49 CET
Status	Report complete.
Alerts	- No alerts detected
Reputation	Suspicious