Pintsized malware packs punch —

New family of Mac malware masqueraded as printer software.

Researchers have identified the Mac malware that infected employees of Apple, Facebook, and Twitter, and say it may have been used to compromise machines in other US organizations, including auto manufacturers, government agencies, and a leading candy maker, according to a published report.

Pintsized.A is a new family of Mac malware that uses an exploit to bypass Gatekeeper, an OS X protection that allows end users to tightly control which sources are permitted to install apps, according to an article published Monday by The Security Ledger. Mac antivirus provider Intego says the trojan masquerades on infected machines as Linux printing software known as cupsd, although it runs from a different location than the legitimate title. It's unclear exactly how the malware gets around Gatekeeper.

Once installed, Pintsized establishes a reverse shell to a command and control server controlled by the attackers. It uses a modified version of the OpenSSH utility to encrypt traffic, a measure that can help it remain undetected on infected networks. One of the domain names that hosted such a server was corp-aapl.com. It caught the attention of members of Facebook's security team, tipping them off that there was an infected machine inside their network. When they later took control of the domain, they discovered multiple other companies were also compromised by the same attackers. Around the same time, Apple, Twitter, and Microsoft were also hit with attacks that meet the same pattern.

The Security Ledger brought to light several other new revelations about the attacks. For one, attackers used a variety of third-party websites to infect employees who frequented pages involving a variety of topics, including the development of applications for Google's Android operating system. Previously, only iphonedevsdk.com, a website for iPhone developers, had been identified as being compromised. Also interesting, the latter site was booby-trapped in such a way that it attacked some visitors and not others. Investigators are still investigating exactly what caused the selective exploiting and how specific targets may have been chosen.

Wasn't this related to the recent Java exploits? Previous articles on Ars mentioned the same companies and websites were affected/exploited via Java.

It's possible that Java was the attack vector. This is talking about how the sandbox was defeated. GateKeeper should still restrict executable binaries delivered to a user's hard drive by a compromised Java VM.

It's possible that Java was the attack vector. This is talking about how the sandbox was defeated. GateKeeper should still restrict executable binaries delivered to a user's hard drive by a compromised Java VM.

GateKeeper works by checking if the executable has the `com.apple.quarantine` metadata attribute. You can remove that attribute using the command `xattr -d com.apple.quarantine file-path`, so it's not a very strong measure. It works only if applications voluntarily flag downloaded executables as quarantined, which a virus obviously won't do.

In other words, it's not surprising that the virus bypassed GateKeeper. GateKeeper was designed to protect users from themselves, not from malicious programs already running on their computers.

I admire hacker skills. Exploiting software vulnerabilities isn't easy when the end-goal is remote control or data access. Finding those software vulnerabilities in the first place is even harder. Some serious talents are need to pull this off.

Based on the article description, this exploit used social engineering to get installed...

No. The virus installed itself by compromising websites to insert a malicious Java applet. It is a "true" virus, as it required no interaction from the user (aside from visiting the infected web page with Java enabled).

It didn't bypass Gatekeeper; Gatekeeper simply doesn't apply. Assuming GK is set to allow non-Appstore apps, it only checks executable files flagged by Safari, etc. as having been downloaded. If the user approves the app once, the flag is cleared and the app is never checked again.

Executables that are copied from a CD or drive, or that are downloaded by software that doesn't set the flag, or that are written by a hacked version of Java, will never even be checked by Gatekeeper. That is probably a problem worth solving, but it isn't the problem Gatekeeper solves.

It works only if applications voluntarily flag downloaded executables as quarantined, which a virus obviously won't do.

I vaguely recall that there is also a master list of apps that have quarantine turned on for any files that are created, regardless of the application's setup. Apple essentially opted all the web browsers into this when they created the quarantine functionality, since that was sold as an OS X feature rather than a Safari feature and having it not work for other web browsers would be unexpected. I can't find the list or any documentation on it, so I might be hallucinating this. This automatic protection is supposed to protect even apps that run plugin where they have no direct control over the code.

Besides this, apps can manually opt in to quarantine, and need to manually set the attributes for where the file was downloaded from.

It's possible that Java was the attack vector. This is talking about how the sandbox was defeated. GateKeeper should still restrict executable binaries delivered to a user's hard drive by a compromised Java VM.

GateKeeper works by checking if the executable has the `com.apple.quarantine` metadata attribute. You can remove that attribute using the command `xattr -d com.apple.quarantine file-path`, so it's not a very strong measure. It works only if applications voluntarily flag downloaded executables as quarantined, which a virus obviously won't do.

Correct. GateKeeper generally just prevents the scenario like "Person downloads what they think is a video or picture or whatever, and unknowlingly runs a malicious application".

I guess the obvious next step for GateKeeper would be an "only run signed code" mode a la iOS, but this would render lots of perfectly good software unrunnable. And this obviously isn't a bulletproof solution, for the same reasons that jailbreaks exist.

Pop Quiz: What do Mac users and the Iraqi information minister have in common?

Why did this get down-voted? That was damn funny! Some apple fanboys are waaaaaaay too sensitive.

I expect to get down-voted into oblivion. So much for being allowed to think differently.

I knew full well what was coming, but I couldn't pass up the opportunity.

On a serious note, this was targeted directly at computer professionals that did everything that we're told couldn't happen to the latest and greatest security technologies baked right into the OS. Honestly this should be the best case scenario for the platform yet it clearly failed to tip off the user when bad things were going down.

Frankly, none of the platforms out there right now would have fared any better.

Pop Quiz: What do Mac users and the Iraqi information minister have in common?

Why did this get down-voted? That was damn funny! Some apple fanboys are waaaaaaay too sensitive.

I expect to get down-voted into oblivion. So much for being allowed to think differently.

I knew full well what was coming, but I couldn't pass up the opportunity.

On a serious note, this was targeted directly at computer professionals that did everything that we're told couldn't happen to the latest and greatest security technologies baked right into the OS. Honestly this should be the best case scenario for the platform yet it clearly failed to tip off the user when bad things were going down.

Frankly, none of the platforms out there right now would have fared any better.

which really just highlights what sane ppl said from the start; simply beating your chest does not make you better than the rest.

ALL systems are breakable. the only difference is method and motivation.

There are plenty of legitimate apps that haven't been through Apple's vetting process, and users have to manually bypass Gatekeeper to do this.

Gatekeeper compatible apps have not been vetted by Apple.It just means that you bought a signing key from Apple (through a Developer account).Apple knows who you are and can invalidate they key.That's all Gatekeeper means, except when you limit it to AppStore-only.

Wasn't this related to the recent Java exploits? Previous articles on Ars mentioned the same companies and websites were affected/exploited via Java.

It's possible that Java was the attack vector. This is talking about how the sandbox was defeated. GateKeeper should still restrict executable binaries delivered to a user's hard drive by a compromised Java VM.

Ah. Interestingly, I noticed that Apple's Java 6 plugin seems to obey Gatekeeper rules, and doesn't allow unsigned Java applets to run at all unless you completely disable it. It's annoying because there's no easy bypass like with regular programs where you can right-click and select "Open". You have to go into the Security prefpane, manually disable Gatekeeper, accept the "This may make your Mac less secure." warning, and restart the browser.

With Oracle's Java 7, it seems to completely ignore Gatekeeper settings, but it gives you its own warning with "Allow" or "Deny" buttons. I'm guessing this, combined with how the Java exploits work around the warning screen could have been the reason the malware could get in.

It's possible that Java was the attack vector. This is talking about how the sandbox was defeated. GateKeeper should still restrict executable binaries delivered to a user's hard drive by a compromised Java VM.

GateKeeper works by checking if the executable has the `com.apple.quarantine` metadata attribute. You can remove that attribute using the command `xattr -d com.apple.quarantine file-path`, so it's not a very strong measure. It works only if applications voluntarily flag downloaded executables as quarantined, which a virus obviously won't do.

Hence the name "Gatekeeper." The idea is that it guards the gate of the garden, preventing malware from getting in in the first place.

Unfortunately, there's another way into the garden: dig your way in through the Java sandbox.

It's possible that Java was the attack vector. This is talking about how the sandbox was defeated. GateKeeper should still restrict executable binaries delivered to a user's hard drive by a compromised Java VM.

So either the original exploit included an exploit of Gatekeeper, or the exploit managed to run with the Java VM's permissions?

which really just highlights what sane ppl said from the start; simply beating your chest does not make you better than the rest.

ALL systems are breakable. the only difference is method and motivation.

Well, if we have learned ANYTHING at all in the last 20 years, there ARE new technologies that were not incorporated into say, XP. Today's Windows and OSX are vastly superior to those systems, that's completely indisputable. Apple's iOS adds a further layer of security by allowing only two ways to put executable code onto your device: through the Apple store, or thru an exploit of their javascript engine. How is that the same as platforms where dozens of malware vectors exist?

And on to the particulars: unlike the subset of Ars commenters who use Macs, your average Mac user has almost no reason to attempt to run Java in the browser, and Apple has worked hard to limit it. If there was ever any truth to the “Apple gets a pass due to its tiny market share” argument, this Java-dependent exploit does not exist—it's fiction.

People who actually care about security don't go around trying to turn issues into FUD talking points for why Apple is as bad as everybody else.