Apple pie order?

2010-08-01

David Harley

ESET, UK
Editor: Helen Martin

Abstract

‘Over 40% [of computer users] think [that Macs are] only “somewhat” vulnerable.’ David Harley, ESET


Back in the 1990s, when I was working for a medical research organization, I wrote a report on the virus landscape. For completeness, I included a section on Mac issues. A Mac specialist whom I was working with at the time remarked that he was quite impressed with the report generally, but he confidently informed me that there weren’t any Mac viruses (there were, of course). Have things changed since then?

Last year, a survey carried out on behalf of ESET’s ‘Securing our eCity’ initiative found that many Mac (and PC) users in the US still assume that the Mac – or at any rate OS X – is a safe haven. More people own PCs than Macs, more people own both types of computer than own Macs alone, and 2.1% of users in the survey didn’t know what kind of computer they own (perhaps they’re the same 2.1% who think there are no PC vulnerabilities). Of all these groups, nearly 10% think that Macs aren’t vulnerable at all, and over 40% think they’re only ‘somewhat vulnerable’ – although it’s not obvious what the survey respondents understood by the term ‘vulnerable’.

According to the survey, no Mac user believes that PCs are safe from malware attacks, and only 1% of PC users do. (Perhaps that 1% accounts for the millions of machines that are still infected with Conficker, or are patiently broadcasting ancient mass‑mailers.)

I’d contend that while ‘somewhat vulnerable’ might be about right for systems/application vulnerabilities and exposure to current malware, the figures would be more alarming if the survey were more focused on the vulnerability of users rather than systems. Any computer user who believes his system is so safe that he doesn’t have to care about security (i.e. not vulnerable at all) is prime material for exploitation by social engineering.

In fact, while the general decline of old-school viral malware is reflected in the Macintosh statistics, there’s no shortage of other malicious code targeting OS X, including rootkits, fake codec trojans, DNS changers, fake AV, keyloggers and adware. Numerically, this is a fleabite compared to the many tens of thousands of unique malicious Windows binaries AV labs see on a daily basis, but ‘safe haven’ doesn’t seem quite the right description.

The last time I pointed to user complacency as a risk here (see VB, August 2004, p.2) it was condescendingly explained to me that Apple’s security model saves their customers from themselves (see VB, October 2004, p.16). At one time, Apple’s security model led the way on patching, and it still includes many potentially useful defensive techniques, but they’re generally more limited in implementation than is often assumed. This is certainly a far cry from the picture Apple has painted for so long where PC viruses are no threat at all (tell that one to the multi-platform enterprise administrator!) and your Mac is ‘safe out of the box’. In fact, looking at Apple’s notorious security page while writing this piece, I see some small but significant changes from previous versions. The ‘safe out of the box’ claim has gone, and security is now achievable ‘with virtually no effort on your part…’ The disparity between protection on 32-bit and 64-bit apps is addressed, with some positive spin. There’s even an admission that ‘since no system can be 100 per cent immune from every threat, anti-virus software may offer additional protection.’

Indeed, there’s probably no absolute need for anti‑malware on many Macs at the moment (as if most Mac users are going to be persuaded otherwise, short of an Autostart-sized panic!). Mac users are similarly placed to Windows users in the late 1990s: if you’re impervious to social engineering and can accept the risk from zero-day, self-launching exploits and cross‑platform malware, fine – only don’t assume that there is no Mac malware or that only viruses matter.

Of course, I haven’t even mentioned iGadgets and the limitations of security based on whitelisting and restricted privilege. But you may not want to get me started on that...

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.