About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Home » Learning Curve

Flashback: What Do You Do When It Strikes Again?

You didn't think about that, did you?


Buy It

Try It

Feathers are ruffled. Most Maccies don't want to take it seriously. The Rock Solid Foundation™ under attack? Oh noes! So let's write about the new iPhone or something else and completely ignore the fact there's a botnet out there today that's comprised almost exclusively of hundreds of thousands of Apple Macs.

And watch how all those grubby little hands fight for a piece of the pie. Watch how Kaspersky's Twitter feeds try to spread fear uncertainty and doubt. As if using their products would help one iota. They won't. Virus signature lists were mostly ridiculous already years ago. They protect only against known threats.

Seriously: get a clue. The first thing the malware writers do when setting up a business is purchase licences to all those products. The second thing they do is concoct new malware packets. And the third thing they do is make sure none of the AV products can detect them.

So is there an endemic systemic weakness in Apple's Rock Solid Foundation™? No. So how were all those Macs compromised?

Attack Vector

Charlie Miller pointed out a long time ago that hacking a Mac is child's play. Did anyone care? Not until now. Was Charlie pointing to endemic systemic weaknesses? No - he was pointing to Apple's almost nonexistent policy for handling critical patches for zero day vulnerabilities.

Of course Charlie was castigated and dismissed in the 'Mac media'. He was arrogant and insufferable and whatever else they could come up with. Sure enough - Apple's open source modules were hopelessly out of date, and sure enough - a lot of the patches took care of critical vulnerabilities. But that doesn't equate to a Mac actually being pwned, does it?

Those sites aren't worth reading. Because they're more interested in preserving an illusion than getting at the truth and trying to keep safe online. Sites like that aren't worth a single hyperlink click.

So what happened with Flashback? Simple. Oracle - who are caretakers of Java today - were alerted to critical vulnerabilities. They rushed to get their code fix out. That was over two months ago. Apple - notorious for not playing well with others in the software market - sat on the fix from Oracle for two months.

It's no coincidence that so few Windows and Linux users were hit by Flashback - they had the fix.

Injection

The makers of Flashback have used different attack vectors over the months and years - different tricks to get their payload on computer systems. But what happens once it's there?

The 'bad stuff' tries a trick one might call 'code injection'. It can do this on OS X systems by mucking with application configuration files. This isn't Unix per se - it's NeXT code.

There are two ways to achieve this injection, both using the configuration key DYLD_INSERT_LIBRARIES.

  1. Contaminate the Info.plist of a web browser. Most web browsers will be placed in /Applications and other user config files point to them all anyway.
  2. Create the nasty subdirectory .MacOSX to user root ~ and place the file environment.plist in there. This has basically the same effect. This is legacy NeXT/OPENSTEP. And it can be lethal.

What happens is that code is injected either into web browsers (the Info.plist approach) or into each and every single Cocoa application that runs (the .MacOSX approach). Flashback seems to try both methods.

Recovery

Ever since Dr.Web published the first report on Flashback there's been a flurry of chaotic and hysterical activity surrounding the attack. We've seen pathetic attempt after pathetic attempt to 'cash in' on other people's misery.

We've seen the Windows antivirus peddlers once again try to 'FUD' Mac users into buying their shoddy wares. (Don't be taken in - they're essentially worthless.)

We've seen programming amateurs peddle strange apps that in 300 lines of code do what the F-Secure instructions do in 2.

We've seen several AV vendors falling over one another to get you to their sites so they can get you to send them your Mac UUID in the clear instead of you just running the two short commands F-Secure suggested. We've seen tens of thousands of hopeless Mac users fall for such a ruse out of an irrational fear for the dreaded COMMAND LINE.

And finally we've seen Apple finally - finally - issue a 'fix' for corrupted machines. After leaving their faithful unprotected for two months, vulnerable to all kinds of butt hurt.

But here's the catch: none of those geniuses protect you against the same thing happening again.

So you choose your favourite brand of Kool-Aid and then typically think you're OK again. But what about the weaknesses Flashback exploited? Are they fixed?

Oops!

Don't Let It Happen Again

If you have any sense of system intrinsics, and even if this is your first encounter with this savoury news topic, you should be able to figure out how to secure your system against any and all future attacks of this kind. But in case you're not part of this elite, here's what you should do.

Note that this discussion will explain what each remedy is, offer different solutions, compare the solutions, and then show how ACP users would go about it. People without the ACP will have a tougher time of it. But they can either get down to a command line or get the ACP. That's how far we'll take it.

Step One: Protecting Your Web Browsers

  1. Launch Safari. Safari is always polite enough to show you your available browsers (unlike some other nasty apps - hi Google guys). Note what browser options you have.
  2. Drill down into the bundle of each browser. Check the graphic below. You ultimately want root:wheel ownership and 0644 access. This way only root can change anything and hopefully your system doesn't have loopholes so bad code can piggyback on your use of sudo.

  3. Use Xfile's 'Terminal' command as necessary. So you immediately get in the right directory to change ownership if needed.

Step Two: Protecting Your User Root

  1. Navigate to your user root directory. This the 'home' toolbar button on Xfile (or the equivalent from the menu) or simply use the 'Goto' sheet.

  2. Check the contents of your user root directory. What you don't want to see is a subdirectory called .MacOSX.

  3. Move the contents of that directory to another location if it exists. Then delete the the directory .MacOSX.

  4. Secure your user root directory. Check the graphic below. You want the mode set to 0500 (read access and no more) and you want the system/user flags set to 00000012 (immutable and 'no unlink').



    For added protection you can set the same flags but at system level. But remember you'll need to do a hard reset. And you can apply a little 'ACL' gunk (but it's not necessary).
  5. Reboot.

What Have You Done?

A quick recap.

  • The Flashback family attack by injecting code in your Cocoa applications at runtime. This is unfortunate and perhaps should be removed from the system but you can protect against it.
  • There are two ways the code injection can work: by specifically compromising the runtime linkage of one or more of your web browsers; or by corrupting your entire login environment.
  • So if you've followed the above instructions: you've just removed both. And your system should be protected against future attacks.

And keep Java turned off. OK?

See Also
The Technological: Apple's Achilles Heel
The Technological: Apple and the War on Stupidity
Industry Watch: Flashback Botnet Recruits 550,000 Macs

About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.