OxCERT's blog

Over the past couple of weeks, OxCERT have been somewhat overwhelmed by Mac malware. This isn’t quite the first time we’ve dealt with problems on Macs – we’ve seen several compromised over the years through weak or exposed ssh credentials, and others infected as a result of installing pirated software. But with Flashback, the game has changed forever. We are seeing huge numbers of attacks of the sort that Windows users have had to contend with for years. Apple users, and indeed Apple themselves, just have not been ready. We are dealing with what is probably the biggest outbreak since Blaster struck the Windows world all the way back in the summer of 2003. That time OxCERT dealt with around 1000 incidents; we have seen several hundred Flashback incidents and they keep on coming.

What is Flashback?

Flashback is not in fact that new, it has been around in various forms since September 2011. Like much malware, multiple variants exist, as the attacks evolve to exploit new vulnerabilities, avoid detection and adapt to new purposes. Early versions required user interaction in order to execute, but in recent weeks the malware has been exploiting a vulnerability in Java, allowing for “drive-by” exploits where all a user has to do is to visit a webpage hosting malicious content (perhaps via a third-party advertisement).

Once on the system, Flashback gives the attackers the ability to do pretty much whatever they like with it, at least until someone stops them; it will depend on the particular variant and what the command-and-control systems tell it. In the Windows world, a common approach has been to capture users’ keystrokes and other information from the system in order to gain access to their online banking. Others may be interested in what other resources they can access, whether on the compromised system itself, or via resources to which the user has access. Some University users have access to some very sensitive data.

The Java vulnerability is one that Oracle fixed on 14 February. Anyone using Oracle’s auto-update mechanisms would have received this update shortly after, but under OS X, Java is distributed by Apple and most users have to wait for Apple to release the update. In this case, Apple did not release it until 3 April, some seven weeks later, by which time the vulnerability was being widely exploited. The reason behind this delay is unclear, but it is not a one-off: Apple have consistently lagged weeks behind Oracle on Java updates. For all we know there may be good operational reasons as to why it takes so long for Apple to release the updates, but as is usual they have been completely silent on the matter.

Java is not the only application being exploited – there are reports of others being targetted, such as emails containing malicious Word attachments. All too familiar in the Windows world of course.

“But Macs don’t get viruses!”

Sadly far too many users still appear to be under the misapprehension that “Macs don’t get viruses” in spite of decades of evidence to the contrary. Indeed, at the time of writing, Apple themselves still state that a Mac “doesn’t get PC viruses”. Technically true, perhaps, but very misleading: PCs get PC viruses, Macs get Mac viruses which may be extremely similar to that common on PCs, in spite of the “built-in defences”. (Note also the claim that “Apple responds quickly by providing software updates and security enhancements” – as we’ve seen, this depends very much on your definition of “quickly”.)

There was perhaps a time when the threat of viruses was sufficiently low that Mac users didn’t have to worry too much about having antivirus software installed, but that time is long gone. Apple’s “built-in defences” weren’t saving users from Flashback infections. It’s true recent versions OS X have a built-in antimalware capability, but it is extremely limited and no substitute for a proper third-party antivirus system. Sophos is widely used and supported in the University but no doubt most of the major players have equally good solutions.

What should Mac users do to protect themselves?

Really, it’s a case of taking the same precautions are required as on a Windows system.

• Install antivirus, and ensure it updates frequently, preferably several times a day.
• Keep the operating system up-to-date (but see below) – ensure Software Update checks on a daily basis, and that security-related updates are applied promptly.
• Keep third-party applications up-to-date, especially anything that may handle untrusted data from the Internet. Browsers (eg Firefox, Chrome, Opera), mail clients (eg Thunderbird, Outlook), Flash, Java, Acrobat, Office.
• Be wary. Don’t open email attachments you don’t expect, especially if from unknown senders. Only download software from trusted sources.
• Enable the built-in firewall.
• Disable or remove software you don’t use. Under OS X 10.7 (Lion), Apple now do this automatically with Java.

There is however a nasty catch with operating system updates, of which many users will be unaware: Apple security support lifetimes are much shorter than in the Windows world. This is an issue which we discuss further in a second post.

Ultimately though, the game has changed for Mac users. They can no longer sit smugly thinking that few people are going to bother attacking them – Macs are being attacked on a very significant scale, and complacency is asking for trouble. Mac malware has gone mainstream, and will likely remain so.

In a companion article I discuss Mac malware, and how this has recently become much more of a problem than has previously been the case. As well as Apple’s apparently slow response to a recent vulnerability, and general air of secrecy, one of the problems that the attacks have highlighted is Apple’s product support lifecycles, which are much shorter than in the Windows world. Many users are unaware of the issues and will not realise that their systems may be insecure as a result.

Software support

Let’s look first at software. To the best of our knowledge, Apple do not officially state their software support policy anywhere, but from what we can gather, only support the two most recent versions of OS X. Currently that is 10.6 (Snow Leopard) and 10.7 (Lion). 10.6 released in August 2009, which means that any Mac purchased prior to that date and not subsequently upgraded will be running a version which receives no security support. That’s for a system purchased under three years ago. Granted, users can upgrade – but at a cost. Users don’t like being told that they have to spend money. Moreover, 10.8 is due out sometime this summer – based on past experience, we can expect 10.6 systems to lose security support once that happens.

Compare that to the situation in the Windows world. Windows XP was released in summer 2001, and will receive security support until April 2014 – twelve and a half years since it released, over seven since it ceased to be the “current” Windows version, and even for those who refused to touch Vista, nearly five years after the release of Windows 7. During that time functionality has been improved considerably by the release of three service packs, available at no charge. Windows Vista and 7 are both scheduled to get over ten years of security support. With around two years between OS X releases, Apple have been struggling to reach four years, and unless their support policy changes as they move to an iOS-style annual release cycle, that could come down to two years.

Now, granted, users can upgrade to a newer OS X release than their system came with. Plenty of users are unlikely to bother unless forced – their system seems perfectly adequate, why spend money and risk breaking it? One college has reported almost 50 systems known to their student registration system running OS X 10.5 or earlier.

Hardware support

But there comes a point at which a system can be upgraded no further. With Apple hardware, that can happen surprisingly rapidly. 10.6 does not support PowerPC-based hardware (last sold new during 2006); 10.7 does not support 32-bit Intel systems – most were superseded in late 2006, but in the case of the Mac Mini, not until August 2007. 10.8 is expected to release this summer and will drop support for even more recent systems, including any MacBook made before late 2008, although 10.7 should continue to be supported.

Thus in little over five years, it’s not just that the latest version of OS X may not run on your hardware, but that no currently-supported version of OS X will. If you want security support, buy a new system. Or change operating system. For old PowerPC systems, that limits you to certain distributions of open-source operating systems (e.g. OpenBSD or Debian GNU/Linux) – in all reality probably not something the average user is willing to consider. If 10.6 loses security support this summer, the best option for owners of early Intel Macs will most likely be to install Windows, heretical as it may sound to many Mac users. Vista’s probably good until 2017, and if the hardware’s up to Windows 7, they’ve got until 2020.

Five years is not a long time to retain a computer, especially in these cash-strapped times. In many departments, it will be their typical hardware replacement cycle, while others don’t even have one. Privately-owned systems may well remain in use until the hardware gives up. For the environmentally-conscious, throwing away perfectly functional machines is hugely wasteful (Apple have made considerable efforts to improve their green credentials in recent years), and the secondhand market relies on people not knowing or caring about the lack of security support, or being willing to run alternate operating systems.

In the PC world, many machines made last century can still make a decent stab at running Windows XP. It would be good to see Apple commit to their hardware being able to run a supported operating system for longer, with a minimum perhaps in the range seven to ten years. The supported operating system needn’t be what the machine shipped with for all that time, nor the current version, nor need all the whizzy new features of newer versions be available (just as Windows Vista would run better on old machines with Aero disabled). The important thing is that the hardware is still fit for use rather than the scrapheap.

The cost

Now, improving support lifetimes is going to cost money, and may deter a few customers from upgrading to newer Apple systems. But equally, customers are going to be less keen to stick with Apple if they learn that Apple are not looking after them. Apple may not have much a place in the enterprise market, but they do in the educational market, and people like us exist to ensure that people do care about security. And let’s face it, these days Apple are most definitely not short of cash.

Now, please don’t get me wrong: there is much about Apple that I like, and I use Apple products daily. I appreciate that Apple are also out there to make money. But they have been complacent in terms of their attitude to security and support, especially when compared to their chief competitor. Microsoft have learned a huge amount from past mistakes, support their products for many years, and these days I feel do an excellent job. By comparison, Apple appear to be making minimal effort, and are putting their customers at risk as a result

So in summary, I’d like to see from Apple the following:

• Timely security updates
• Greater openness regarding security issues
• Minimum hardware and software support lifetimes stated clearly up-front
• Longer operating system security support lifetimes: at least five years
• Hardware that runs a supported operating system version for longer: minimum of seven years perhaps?

Whether anything will change any time soon remains to be seen, but as the threats towards Macs increase, surely Apple cannot afford to stand still.

As I write this, it seems that my fears on Friday have not come true over the weekend. To date, things have been quiet. Nevertheless, we still expect a storm. We just don’t know when. While we wait, let’s consider the story so far.

The MS12-020 RDP vulnerability

On Tuesday 13 March, Microsoft released updates on their regular monthly cycle, including one addressing a vulnerability in the Windows Remote Desktop Protocol (RDP) service. This is remotely exploitable by an unauthenticated user. Microsoft themselves rate this as a “critical” vulnerability and likely to be exploited. In posting our own bulletin on Tuesday evening (sorry, only available within the University network), we drew particular attention to this, knowing that RDP is widely used within the University.

In the past there have been many notable computer worms – self-propagating malicious software. Examples include Code Red, Blaster, and SQL Slammer – the last one significant enough to paralyse a significant proportion of the global internet. It has been a while since we have seen a major new internet worm. In recent years there have been two major factors at work: firstly, Windows has shipped with a firewall enabled by default since the release of XP Service Pack 2 in 2004; secondly, attacks are increasingly the result of criminal gangs seeking to profit from their work, resulting in a trend towards stealthier malware. The most major worm in recent years has been Conficker, something that we still see on our network from time to time, particularly on systems belonging to visitors to the University.

Developments during the week

After internal discussion on Wednesday, we decided to perform a scan of the University network the following lunchtime for systems listening on the standard Microsoft RDP port, tcp/3389. We knew that RDP was widely used within the University but quite how much, we weren’t sure. We scanned all systems from within the University network initially, with followup probes from an external host as we suspected a common configuration would be for systems to be accessible from within the University but not open to the world at large. Our results showed several thousand systems listening on port 3389 and we proceeded to pass the results to the relevant IT officers on Thursday afternoon and Friday morning. Our scans could not determine whether systems had been patched against MS12-020 or even what software was listening on that port, merely that the port in question was open.

Some may ask why RDP isn’t firewalled within the university. We have always operated an extremely open network, with few centrally-imposed restrictions on what people may run; any attempt to impose restrictions tends to result in howls of protest. Only a few very specific threats are blocked across the site, and experience has shown us that anything for which we grant exceptions will tend to impose massive management overheads. Additionally, a perimeter firewall cannot protect against threats from elsewhere on the University network. It is therefore left to individual colleges and departments to operate their own firewalls according to their local requirements. From the centre, we can recommend particular configurations, but not dictate.

Microsoft themselves announced on Wednesday that they expected exploitation of MS12-020 “within thirty days”. If it took, say, a couple of weeks for the bad guys to develop an exploit then this is clearly of concern but gives IT staff a reasonable amount of time to address the problem, taking into account needs to test patch deployments and schedule necessary downtime.

The threat as seen on Friday

Unfortunately, the situation appeared to have changed by Friday lunchtime: reports stated that “proof of concept” exploit code had already appeared on message boards in China. Moving from proof-of-concept to a fully “weaponised” system may be a matter of days or even hours going by past experience. With hours to go before the weekend, this was cause for concern: under 72 hours had occurred since Microsoft had released patches and published their bulletin, exploit code had seemingly already been produced, and the weekend was fast approaching.

We felt that the chances of significant malicious activity before Monday morning were high enough to warrant a strong warning to IT officers. Something that would get their attention to the seriousness of the situation. As we stated, if our fears came true, there was a high probability of major disruption by Monday, requiring major effort to resolve. If our fears were unfounded, efforts had merely gone into securing systems sooner than might otherwise have been the case.

The important message to get across was to ensure all systems were patched if at all possible; if this wasn’t feasible before the weekend, to restrict access. A vulnerable system poses far less of a risk if it is only accessible from a handful of trusted hosts than if it is accessible from anywhere on the global internet.

Systems running RDP will not be a randomly-selected set of systems across the University, but will be heavily biased towards key assets: servers, desktops used by senior staff members, systems holding valuable or sensitive information. Compromises of such systems would clearly be far more damaging and time-consuming to address than compromises of a typical student-owned laptop.

The situation now

Now, the weekend has gone by without significant incident, as far as we are aware, although there has been a further development. On Friday evening, it became evident that the published exploit code was not the work of the “bad guys”. Instead, the code appeared to be that supplied to Microsoft by the researcher who originally discovered the vulnerability, and this had somehow been leaked. Possible sources for the leak are the discoverer, Microsoft or a partner in the Microsoft Active Protections Program, which shares vulnerability information with (supposedly) trusted industry partners; in time we may perhaps see more details of what actually happened.

What none of us can know is what is yet to come; all we can do is make educated guesses. We must still assume that an RDP worm will appear at any moment, The threat is real, it is still there. It is critical to ensure that appropriate protection is in place as soon as reasonably possible. Security researcher Dan Kaminsky estimates around 5 million globally-accessible systems running RDP; even if many have been patched, a very significant number remain vulnerable.

What lessons can we learn?

Much of what we have been saying to IT officers is not new. For years we have been recommending that services are not made globally-accessible unless absolutely necessary. For instance, a public webserver has to be able to serve pages to the world. It probably doesn’t require RDP to be globally accessible. Those needing RDP access most likely only come from a handful of hosts or networks, perhaps only internal to the University, perhaps their home addresses, perhaps also some external contractor has access. There may be a requirement to support mobile users or users without fixed IP addresses. Nevertheless for such users, perhaps a facility such as VPN would be acceptable, providing a “layered” security model. Successful attack requires compromising the VPN (or at least one VPN account) and the RDP daemon. This is unlikely to be a deterrent to targetted attacks but will guard against the random attacks that would result from worm activity.

Allowing access from within the University network alone is far better than allowing from anywhere, but is still inherently risky and is not an alternative to keeping systems patched. Such systems are likely to be attacked as soon as another host within the University network is infected, or a pre-infected host is brought within the University network. We have seen this in the past and will inevitably see it again.

A flexible approach is required to patch management. Some may be happy for patches to be applied as soon as they are released; others may be more conservative and wish to test things before deployment to production systems. This is perfectly understandable; updates certainly have been known to cause unexpected problems, as indeed happened last week on a major University service when another vendor’s updates were applied. If policy is that patches are not immediately applied but must await testing and/or a scheduled maintenance window, then it is useful to have plans for addressing emergencies. Can procedures be fast-tracked in the event of a “zero day” vulnerability, or a significant probability of exploitation in the very near future, where the risks of inaction outweigh the risks of an untested update or of inconveniently-timed disruption to service?

No doubt there will be further lessons to be learned when (we still consider it a “when”) the attacks come. No doubt some systems will have been missed. With so many threats to University IT systems around we cannot go overboard on one particular risk at the expense of neglecting the others. For now, we feel we’ve done what we can given our resources, and must move on.

Over the last two months OxCERT have been inundated with compromised University accounts being used to send spam.  So how are so many accounts being abused, what are the risks, and what is the cost to the University?

Let’s deal with the how first.  It appears that the vast majority of the accounts we see abused for spamming purposes, are compromised due to users replying to phishing emails or filling in phishing forms.  What is rather depressing is the fact that in about 99% of these cases, the attackers have gone to little effort to masquerade as genuine University services.  Sadly it seems that users are more than willing to enter their credentials into any old random web form, or reply to any email that asks them for their password. The other prime suspects are key-logging malware such as Zeus or, perhaps, compromised websites where University members have used the same password and email address to register for some third party service.  It certainly seems pretty plausible that users who enter the Oxford SSO password via some Internet cafe, hotel room or other untrusted device around the globe, may fall victim to having their account accessed by the bad guys.

What about the risks associated with phishing? For the University as a whole, compromised accounts – at best – don’t look good and spam runs could have an adverse effect on the reputation of the University.  However, more importantly, they could lead to University mail servers being blacklisted which would have a knock-on effect to all other users of the service.  In fact, University users were unable to email users of a major service provider for several days as a result of one recent incident. Additionally, for the users in question, they can (and do) have their important emails read and deleted, they can be inundated with bounces and replies (causing a denial of service) and, of course, they will have their account disabled until the incident has been dealt with.  This can sometimes be a considerable period of time, particularly if users are in the far corners of the globe.

Perhaps the most immediate impact to the University however, is the cost associated with dealing with phish. Last year, following a spamming incident OxCERT calculated that the time spent dealing with spammers in OUCS amounted to approximately 24 hours per incident.  That is, at least, 3 working days of one person and doesn’t take into account costs incurred by local IT support staff (ITSS), costs to the user, or other potential costs which are harder to put a figure on.  Placing a monetary value on staff time is difficult, especially if the staff are being employed anyway – there is no direct additional cost to the University.  However, working on the basis of a mid-point, grade 7 employee that probably works out in the region of around £360 per phish.  Not much then?  But given that OxCERT have dealt with around 20 spammers in last 2 months that is  approximately £3600 a month.  Admittedly that is more spammers than we’ve dealt with than the entire previous 10 months put together, but that may be because we  have started looking more closely recently.  Either way, if this trend continues that is about £43,000 per year.  That’s easily one full time employee dealing purely with Oxford accounts being used for spam.  It’s perhaps also worth bearing in mind that these costs (while only a very rough estimate) don’t take overheads into consideration, or (as mentioned) the time of local ITSS.  Neither do they take into consideration incidents where compromised accounts are used to access journals or databases worth thousands, and sometimes tens of thousands, of pounds.

If you were looking at this from the point of view of risk, where Risk = Asset Value/Cost * Vulnerability * Threat then it would certainly seem something worth trying to mitigate.  Given the costs involved, the vulnerability of users to hand out their SSO credentials and the fact that we get phishing attempts reported to us every week, it seems like a high risk to the University.  But what can be done?  OxCERT, of course, already take mitigating action where possible.  We can block links to certain phishing forms, prevent e-mail from getting to certain email addresses etc.  But that only works when users are on the University network. There are also some forms which are more difficult to block ( I don’t think we’d be too popular if we sink-holed spreadsheets.google.com for example) and service providers can sometimes be slow in taking down phishing sites.  We do have detective and reactive controls in place in order to spot spammers quickly and significantly lessen the impact on the University, and we blocked in the region of 700 machines, which were infected with key-logging malware, over the last 12 months. Whilst I’m sure not all of these would have been used to send spam, I have no doubt that some of them would.

Yet despite all of these measures, this is a problem which is still costing the University time and money. Surely the real question has to be how we can prevent this from happening in the first place and how we can get users to question the legitimacy of emails they receive and sites they visit.  These are not new questions and are not easy to answer.  I know the vast majority of ITSS do their bit to educate users but is there more we can do?  I don’t have all of the answers, but would love to hear the thoughts and views of Oxford ITSS on this issue.  Can more be done to educate our users and make them aware of the impact of their actions – both on themselves and on the University as a whole?

OxCERT recently received a request for guidance on URL shortening with regards to using such services to re-direct users to sites that may ask for sensitive personal information.  The concern was that the third-party offering the service may be able to track who visits the sites behind the links.  If those sites collect sensitive information is this a risk worth considering?

As with all questions related to privacy then there is a balance between the invasion of privacy and the benefit of what you are doing.  The first question to ask may therefore be “why use URL shortening?”  Of course URL shortening can be useful, for example where there is lots of embedded data in the URL.  However, if there is no need then why bother?  Additionally, have you considered using your own internal redirection scheme if your current URL isn’t memorable enough or sufficiently aesthetically pleasing?

However, this seemed an interesting example of how risks to information can be misunderstood and/or overlooked.  Yes there may be privacy concerns in that the service provider may be able to trace certain activity and obtain information on (for example) the web browser being used, the OS, the referring URL and the IP address of the visitor.  Is this “personal information”? Possibly, if the service provider can trace the IP back to a living individual.  It’s also possible they could associate that information with past sites you visited via the same service (i.e. from the same IP address).  Is this all so bad?  Maybe. If simply having visited a site is considered sensitive then this could be a reason to avoid URL shortening but the risk seems low if there is a good reason for using it.

What would be of greater concern to me is the risk of shortened URLs being used to “phish” the information by directing users to malicious sites.  The problem with URL shortening (in this respect) is that users don’t know where they are being redirected to.  And how many users check the validity of the site behind the link?  OxCERT still witness users filling in phishing forms on third party sites that have made little or no effort to masquerade as a genuine University site so how many would fall victim to a legitimate looking site asking for sensitive personal information if it appeared to come from a legitimate source?  Users can also be re-directed to sites hosting malware or containing other unwanted content so it is important to bear in mind that, to an extent, trust is being place in the URL shortening service provider.  Therefore it is worth considering which service provider you use.  Are they a well-known, reputable provider who are likely to take swift action for example?

Of course there are also preview tools available in order to allow users to check where the shortened URL takes them, but I think that this is only part of a greater problem.  That is one of teaching users to question who is asking for their information and educating them as to how to verify their identify.  When it comes to a breach of user privacy then, checking the authenticity of the actual site being used to harvest the information, seems a much more important message to get across.