Sandworm 0-Day Exploit

Information has been circulating online regarding Sandworm, a vulnerability affecting Microsoft Windows versions from Vista SP2 onward, and Windows Server 2008 onward.

Despite the name, the Sandworm bug is not known to be exploited by self-propagating malware. Instead, attack code is currently reported to be delivered via a malicious PowerPoint document.

Indications are that Microsoft will be releasing a patch soon, but it is likely that more malware authors will attempt to exploit the flaw in the coming weeks. This is a good opportunity to remind everyone to use caution when dealing with all email attachments, and to be particularly wary of attached PowerPoint files.

Not really a worm, but the code has lots of 'Dune' references

Not really a worm, but the code has lots of ‘Dune’ references

Posted in Current Threats, Microsoft | Comments Off

Fraudulent VC Emails Targeting Finance Departments

We’ve been made aware of a couple of University finance departments having received fraudulent email requests.   The requests advise that the vice-chancellor required assistance with a money transfer or purportedly from the vice-chancellor at their institution asking for assistance with an outgoing money transfer. In both cases the finance departments were sufficiently vigilant so the attempts to transfer monies failed so be on your guard.  For more advice on spotting phishing emails see

Posted in Current Threats, Information Security | Comments Off

Shellshock Intensive Care – Part 2 (Clients)

Update: Apple have now released patches for Bash on the following versions of OS X: Lion v10.7.5, Lion Server v10.7.5, Mountain Lion v10.8.5 and Mavericks v10.9.5. These patches are understood to address vulnerabilities CVE-2014-6271 and CVE-2014-7169, but not CVE-2014-7186 and CVE-2014-7187. These patches are not being distributed via the App Store, but can be found at the following locations:

Update: For Oxford University IT Staff, a briefing has been organised for Tuesday at 12.45pm 30/9/2014, book your place here.

Following on from our previous blog post detailing server-side mitigations to the Shellshock Bash vulnerability, this post will concentrate on the steps that can be taken to protect client machines.

Patching – Déjà vu?

As with the servers, applying vendor-supplied patches to vulnerable systems is the preferred mitigation. Once again, there may well have been two rounds of patches so if you have already updated, it is worth double-checking if a second update has been released.

We might sound like a broken record, but patching really is the way forward
Credit: Cernavoda

The elephant in the room – What to do about OS X?

At the time of this writing Apple have not released an official statement regarding OS X’s vulnerability to Shellshock. However, as recent versions of OS X do make use of Bash we can infer that OS X is affected and as such a patch should be available in the near future.

Which begs the question, what should Mac users (and users of other unpatched client machines) do in the mean time? Our current advice is:

  • Disable SSH access
  • Enable the local firewall and set it to block all non-essential network connections
  • Ensure the device will not connect to untrusted wireless networks. There have been rumors (and some proof of concepts for various operating systems) of a possible attack vector via a DHCP client. Even with DHCP disabled, other protocols may still be open to abuse. Network admins are advised to ensure DHCP snooping is turned on, as this will stamp on rogue DHCP servers attempting this particular trick.
  • Multi-user Mac systems are also a source of concern. Given access to a vulnerable application, a malicious local user could potentially escalate their privileges. VMware Fusion is known to allow this, but other such applications will certainly exist. It may be necessary to restrict use of multi-user Mac systems until a patch has been applied.

Until a patch is available – Shields up
Credit: West Midlands Police

Hey – What about smartphones?

Google’s implementation of Android does not use Bash and is therefore unaffected. This does not guarantee that other manufacturers have not implemented it in some way – your mileage may vary. If in doubt, seek confirmation for your model. In the mean time, you may wish to follow the same steps as for an unpatched desktop device. By default, Apple IOS does not appear to use Bash.

Still not out of the ER yet

No we’re not, but the triage should be well and truly underway. OxCERT will continue to monitor the situation and will update this blog with any new developments.

Posted in Uncategorized | Comments Off

Shellshock Intensive Care – Part I (Servers)

Update: For Oxford University IT Staff, a briefing has been organised for Tuesday at 12.45pm 30/9/2014, book your place here.

As the sun has risen on another day of broken bash, we’ve decided to put together a couple of blog posts detailing the steps you can take to mitigate the risks posed by the Shellshock vulnerability. This post will deal with server side remedies; the next will focus on the clients.

If you have, by some miracle, missed the details of this particular bug; you may wish to read our previous blog post on the subject. Unfortunately, there are many subtle ways in which this vulnerability could potentially be exploited, the answers are neither easy, nor complete, but the triage needs to begin.


A different kind of first responder…
credit: Graham Richardson

Option one – Patch and patch again

Vendors whose products contain a vulnerable version of bash have begun shipping patches, these should be applied as soon as possible. Vendor supplied patches should be considered the first choice fix. They stand the best chance of addressing the problem, without creating collateral damage by breaking existing applications, or storing up compatibility issues for the future.

For those of you who have been hot off the mark and applied appropriate patches, well done, but it might not be time to rest on your laurels just yet. The early wave of patches has been shown to provide only partial protection and your vendor may have now released an updated fix, as described by Red Hat here.

hello kitty plaster

Patches come in all shapes and sizes
Credit: Nomadic Lass

Option two – Restricting access to vulnerable services

Realistically, you may have a server you cannot patch, or where your software vendor has not yet confirmed the vulnerability status of a given operating system and/or released appropriate patches. For example – at the time of writing – OS X server. If this is the case, read on for further mitigating techniques.

To exploit this vulnerability on a server, the attacker must have access to a service that makes calls to Bash. Web servers are particularly at risk, due to being typically open to the world and frequently hosting scripts that make calls to bash, usually to provide some active content. In the first instance, a code audit to identify at-risk scripts to be temporarily disabled would be a wise move. Bearing in mind that this, almost undoubtedly, will affect website functionality. In the event that a code audit is deemed to be beyond the available resources of time, skill or inclination, consider disabling CGI functionality entirely.

As we have observed, Web servers are an obvious target, proof of concept code is already widely available and we have detected frequent scans against our network to identify vulnerable machines. That said, we shouldn’t disregard hosts providing other services.

Keep your first aid kit stocked
Credit: Christina Xu

Unpatched servers providing limited shell access will be vulnerable to local privilege escalation. Consider revoking access to unprivileged accounts until the system has been patched.

Think about where your server should be accessible from, and apply appropriate ACLs to limit access from the wider Internet. This is good practice in any event and will help to limit your attack surface.

Turn off unnecessary or low priority services. Does your server need to be running FTP? No? Then switch it off. Again, this is another example of general good practice.

You may be using a firewall to restrict access to your server, as described in the paragraphs above. Investigate any intrusion detection functionality it may also provide that will allow you to monitor the situation. These logs, along with thorough server logs, will help you to determine the efficacy of attacks against your infrastructure, and will be invaluable if the worst happens.

Option three – High risk strategies

If all else fails, replacing Bash with an alternative shell such as Dash (which is not vulnerable) is an option. Like an organ transplant, this should resolve the original malady by removing the affected part, but is likely to introduce complications of its own. If you decide to go down this route, please use caution, as it is likely to throw up compatibility issues with existing programs, and may interact badly with future patches released by the vendor.

Should the content of the server be too sensitive, or the risk of maintaining a potentially exploitable server judged to be too high, another option is to migrate the content to a non-vulnerable platform (either one that has been patched, or was not vulnerable in the first place). Do bear in mind that knee-jerk migrations have a habit of coming back to bite those that attempt them, take the time to ensure the new server is properly configured and secured – or risk leaping from the frying pan into the fire.

Operation: a game for those with steady hands
Credit: Shawn Rossi

We’re not out of the ER yet

The situation may still be critical, but by understanding the risks and taking mitigating action, we may be able to move to critical, but stable. Hopefully the advice in this post will be helpful in getting us there. Stay tuned for Part 2 – client side.

Posted in Uncategorized | Comments Off

Bash ‘Shellshock’ Bug – Now You Can Panic

UPDATE: The initial round of patches to fix CVE-2014-6271 have proven ineffective at fully resolving the issue; a new CVE code has been issued, “CVE-2014-7169“, use this to track news and updates regarding this bug and patch status.

Remember Heartbleed? Get ready to bleed again, ‘Shellshock’ looks set to equal or even exceed it.

Got anything nice planned for the weekend?

Got anything nice planned for the weekend?


A short while ago it was publicly revealed that a massive security hole, formal name of ‘CVE-2014-6271‘ and recently christened ‘Shellshock‘, exists in the Bourne Again Shell. Commonly known as ‘bash’, this command-line interface that ships by default with almost all modern distributions of Linux, many commercial variants of UNIX and UNIX-like systems, embedded systems, NAS systems and Mac OS X with Bash as the default shell; currently this includes all versions subsequent to 10.2 (earlier OS X versions shipped with tcsh rather than bash). If you have installed Bash from ported code, even FreeBSD and OpenBSD can be affected, although the base installation for these systems seems secure for now.

To directly quote from the official announcement;

Bash supports exporting not just shell variables, but also shell functions to other bash instances, via the process environment to (indirect) child processes. Current bash versions use an environment variable named by the function name, and a function definition starting with “() {” in the variable value to propagate function definitions through the environment. The vulnerability occurs because bash does not stop after processing the function definition; it continues to parse and execute shell commands following the function definition.

The critical bug permits arbitrary code to be appended to an environment variable within a Bash environment, or within a service relying upon Bash to process environment variables. This last point is especially concerning, as large tracts of familiar services rely heavily upon Bash processing and Bash environment variables for basic functionality. You may think that your machine doesn’t interact with any Bash scripts, but if your web application calls a Bash shell command like exec(), the potential for exploitation still exists.

Push it. There's never been a better time.

Push it. There’s never been a better time.

Machines vulnerable to this bug are subject to, at the very least, the following remote exploitation:

    • Fork bombing – instant remote Denial-of-Service with a single GET request
    • Data theft – any file accessible (/etc/shadow anyone?) can be exfiltrated
    • Ping flooding – any server can be co-opted to flood-ping another, instant DDoS potential
    • Backdoor installation – a shell can be spawned and bound to a port on the server
    • Rootkits – malicious code can be downloaded from elsewhere and executed directly

Due to the ubiquity of the Bash interface and how deeply interwoven it has become with standard network services such as OpenSSH, Apache webservers, Common Gateway Interface and any number of daemons like DHCP it is now trivial to remotely exploit a Bash-dependent service for arbitrary code execution.

A not-so-subtle visual metaphor

A not-so-subtle visual metaphor for our current situation

This is just as bad as it sounds. A quick Google search for vulnerable CGI servers reveals results numbering in the millions.

Who is at risk?

Anyone responsible for a machine that runs Bash, right now, personal or otherwise, that is even vaguely connected to the internet. That’s a sizeable chunk of normal internet users with computers running Mac OS X or any Linux-like operating system; this can include Android versions that run bash, this can include your home servers and NAS boxes if they run embedded Linux with Bash.

It also includes an enormous proportion of what people think of as ‘The Internet’: production servers, web servers, firewalls and databases, anything that is touched by the current Bash codebase is plagued by this vulnerability and must be patched immediately.

The smart money says, all these servers need a patch

The smart money says, all these servers need a patch

What can I do?

Update your Bash-enabled systems, all of them. Right. This. Second. Stop reading this blog post and apply your patches. If a patch is unavailable, apply mitigations as suggested by your vendor until the patch is released ; if no mitigations are available either, consider creative alternatives or shout at negotiate with your software vendor until they make some available. Once that is done, check with the following Bash code snippet:

x='() { :;}; echo vulnerable' bash

If following this your command line outputs the string ‘vulnerable‘ then bad luck, you have a problem, as a patch is not yet available for your system and it remains vulnerable to attack. It is critical that you pursue a patched status as aggressively as possible, this is honestly not something that can wait longer than it needs to. Keep an eye on the news released by your software vendor, Apple in particular can occasionally be somewhat reticent in their patching of major vulnerabilities.

Seriously Apple, no rush fellas.

Seriously Apple, no rush fellas.

Certain vendors such as RedHat are producing quick-fix mitigations to reject the incoming bad code, but as poorly understood as the variety of vectors are it is unlikely that all avenues can be covered by band-aid solutions. The only true path to salvation is to apply all the patches from the Bash upstream codebase and rebuild / update your Bash installation.

For critical machines without available patches, the good option is to rebuild the Bash packages manually with the updated source code. The procedure varies from system to system, we can only advise you to refer to the current upstream codebase for rebuild instructions.

If it is simply impossible for a machine to receive a patched Bash version, the easiest solution is simply to eliminate the possibility of Bash being called. This can be accomplished by altering the file structure to replace calls to Bash to Dash or another unaffected shell. This may very well break some scripts or calls, so use with extreme caution;

$mv /bin/bash /bin/_bash
$chmod ugo-x /bin/_bash
$ln -s /bin/dash /bin/bash

Why all the concern?

For a start, Proof-of-Concept exploit code is already floating around on Pastebin, so the cat is very much out of the bag mere hours after the official announcements. Patches have already been released by major vendors to coincide with the lifting of the public embargo on this information, so the security teams of major Linux distributions certainly consider it of the very highest priority.

Depending on system configuration and levels of inbuilt security, the potential vectors include, but are in no way limited to, the following:

    • Malicious HTTP-GET requests running code against public-facing web servers
    • Crafted SSH connections abusing allowed scripts like rsync and rlogin
    • Crafted CUPS print requests delivering exploit code between networks
    • Rogue Wifi Access Points delivering hostile code via the DHCP negotiation process

The full range of vectors by which this bug can be exploited hasn’t been explored yet, but even the earliest indications are all bad news and getting worse. Remote code execution appears to be a reality for the overwhelming majority of Bash-enabled systems, which in turn represents the majority of internet-connected computers.

An even less subtle visual metaphor

An even less subtle visual metaphor for next week’s situation

Crucially, this form of vulnerability is very attractive to the authors of malware, viruses and worm code due to its simplicity, flexibility and universal presence.

Patch Bash as soon as possible.

Further Reading

Posted in Apple, Current Threats, General Security, Web Security | Comments Off

Google Hacking – Making Use of the All Seeing Eye

You don’t need me to tell you, that the Google search engine is a vast and powerful tool. Or that, Tor aside, it pretty much holds the whole of the Internet in the palm of its hand. What you may not know, is that the Google behemoth might have more information about your websites than you do (or at least, more than you would like it to).

But the good news is, using a technique known as Google Hacking, it’s quite simple to leverage Google’s extensive resources to your advantage. Effectively turning the search giant into a quick, cheap and easy tool to detect vulnerabilities, and alert you to malicious activity on your websites.

Blue eye

I Spy With My Little Eye
Credit: Fabio

Google Hacking – What is it?

Don’t be put off by the flamboyant name; Google Hacking is actually just making clever use of Google’s built in Advanced Operators, to search for telltale signs of abuse, vulnerabilities, or just information you’d prefer wasn’t publicly accessible.

Is it Legal?

Against domains for which you are the administrator, or are otherwise appropriately authorised, Google Hacking is definitely legal (in the UK at least). Beyond that, we would strongly discourage you from trying these techniques out on other websites. If in doubt, always ere on the side of caution.

One thing to note at this point; making repeated searches using advanced operators can appear suspicious, and is likely to trigger Google’s own security alerts. While experimenting, expect to solve a captcha (to prove you’re not a bot) every now and then.

Three robots

Google may think you’re a robot, try not to take it personally!
Credit: Jeff

How can I use it?

Google operators are added as part (or even the entirety) of a search query, and use the following syntax:


Different operators can be combined, possibly along with a keyword search, to create a very specific overall search.

An important step to start with, is to narrow your search to a specific domain. This is achieved by using the ‘site:’ operator, for example: exam

Will do a search for the word ‘exam’, but only on pages in the domain.

Replace the word ‘exam’ with the name of a common, branded pharmaceutical product, for instance; and you have a convenient way of checking whether any of your sites have been hacked and defaced with references to the aforementioned drug. Often, these defacements are done in such a way that they only become obvious when the site is accessed with the Google user agent, meaning you could visit the site normally via a browser every day and never find the problem.

The ‘inurl’ operator, predictably, searches for a term within the URL. This can be especially useful for turning up pages you’d rather weren’t Internet-facing. Because if Google can find it, so can anyone who might just fancy trying to brute force an inadequate password, such as in the example below: inurl:phpmyadmin/index.php

Another way to make use of Google hacking is to search for old (and vulnerable) web platforms. For example, the following could turn up webservers running IIS 5.0, based on their error messages: intext:”404 Object Not Found” Microsoft-IIS/5.0

This post only covers a few examples of what can be achieved, but hopefully it will give you enough to get started and begin to see some results!

Pills on a keyboard

Is your website being used to peddle pills?
Credit: Mattza

What else can I search for?

Apart from experimenting with your own searches, the Google Hacking Database is an excellent resource. Many of the examples in this post come, in whole or in part, from this website. Google searches are recorded here under useful and faintly entertaining categories, such as ‘Files containing passwords’ and ‘Sensitive Online Shopping Info’.

Posted in General Security | 1 Comment

5 Million Google Accounts Leaked

Details are emerging of a very recent large-scale leak of Google’s account database, centring around their flagship email service Gmail. Google’s official word on the subject can be read here.

CC Wikimedia Commons

CC Wikimedia Commons

The credentials were posted to a Russian BitCoin mining forum earlier this week. It is understood that the list of compromised accounts has been in circulation since at least September 8th, the exact date of the compromise is thought to be around this time but not precisely known.

Current estimates indicate that around 5 million Gmail credentials are involved in the current leak, although what proportion of them are currently active is unclear; Google themselves are estimating only 2% of the leaked credentials are current credentials. What is clear is that at least some users of Gmail will need to look into changing their passwords as soon as possible, and there is currently no way of knowing which credentials are ‘live’ and which are not.

What can I do?

OxCERT currently advise all users of Google services, including Android Market Services and Chromecast devices, to review their passwords and to take this opportunity to update them. Regular password updates are always good practice, and this recent incident is sound motivation to apply a new and strong password to your Google accounts.

Users concerned about their Gmail security can visit a webpage run by Microsoft-employed security tester Troy Hunt, which (securely) checks your email address against this recent and many other data breaches against major service providers in recent years. The colourfully-titled ‘Have I Been Pwned?‘ can be accessed from this link or by clicking the image below. This service checks your email address against the list of compromised accounts, and can indicate if you are at greater risk. Users are advised that this list is not perfectly accurate.

Well, have you?

Well, have you?

A very important concern is that for the sake of convenience, many users like to use the same passwords for many different services, for example Facebook, Gmail, and University email.

If you have used your current Gmail password for you University SSO credentials also, OxCERT would strongly advise you to update your University credentials to a unique password as soon as possible.

"Good Morning Vietnam!" is a great password. "Grandma64" isn't.

“Good Morning Vietnam!” is a great password. “Grandma64″ isn’t.

Sharing passwords across accounts is generally ill-advised, and this incident highlights how easily a breach of a third party could potentially lead to a further compromise of your University email account and any other systems with which a user is entrusted access.

Further Reading

Posted in Current Threats, General Security, Google | Comments Off

Kyle and Stan Malicious Advertising Network

OxCERT have been made aware of malicious adverts, placed on legitimate websites, which redirect to a network of sites that download malware. The malware served is bundled with legitimate applications, it varies based on the user agent and is known to target both Windows and Mac machines accordingly.

The adverts are understood to have first appeared in early May 2014, and have been displayed on several popular websites including and

To help protect yourself, please remember:

  • Be cautious, even when visiting a site you trust
  • If a download begins unexpectedly, do not open the received file
  • Ensure anti-virus is installed and up to date*

* Please note, the “Kyle and Stan” network serves a subtly unique package of software every time, this interferes with anti-virus detection – proving that while anti-virus programs are important, they are by no means a panacea for all ills.

For further information please see Cisco’s excellent blog post:

Beware unexpected diversions credit: Daniel Lobo

Beware of unexpected diversions
credit: Daniel Lobo

Posted in Current Threats | Comments Off

Scam Calls Claiming to be from IT Services

OxCERT have been made aware of scammers, calling from international numbers, claiming to be from “IT Services at 146 Banbury Road”. These calls seem to be in a similar vein to the “Microsoft” scam calls described here:

Please note, the IT Services helpdesk does not make unsolicited phone calls. If you receive a call claiming to be from a representative of IT Services please exercise caution, especially if any of the following points apply:

  • You are not a member (or previous member) of the University
  • The call is unsolicited
  • The call comes from a number outside of the UK

If in doubt; we suggest asking the caller for a contact number, if they refuse to supply one, or give a non-Oxford (01865) number, it is highly likely to be a scammer.

If you are a member of the University of Oxford, and believe you may have fallen for this scam, please contact:

Further details will be added to this post as they become available.

A new twist on an old scam. credit: Frédéric BISSON

A new twist on an old scam
credit: Frédéric BISSON

Posted in Current Threats | Comments Off

New e-Mail Malware Campaign, “Order Number…”

OxCERT have received a large number of reports regarding a large-scale malware distribution campaign currently targeting University staff and users.

This campaign operates by email, with the distinctive subject line ‘Order Number 86514719983′; the number seems to be random and many users are reporting many different numbers:

If you receive a mail like this, DELETE IT!

If you receive a mail like this, DELETE IT!

These emails universally offer a malicious attached .zip file with a string of random numbers in the name; the zip file contains a .dat and a .bat file, which contain strains of malicious software that are currently undetectable to most Anti Virus products.

To reiterate:    most antivirus packages are currently ineffective against this malware.

The only defence is common sense; do not download attachments from emails with the subject line similar to ‘Order Number: 86514719983′ unless you have absolute faith that it is an expected and legitimate attachment. We are submitting samples to Sophos who will begin to update their signature database in due course, but the VirusTotal scores for this malware are still very poor:


Only a minority of AV packages detect this malware

Do not download these attachments, delete them from your machine if you already have.

Becoming infected by this malware depends on several factors:

  • You are running a Windows-based machine; Linux, Mac and others are unaffected
  • You have received and downloaded the .zip attachment
  • You have unpacked the .zip attachment, and executed the .bat file

If you have not run the files as described, you are likely not affected. If any users are concerned that they may indeed have run the compressed attachment, it is important to contact OxCERT immediately as your personal files and University credentials may be at risk. Please inform colleagues as appropriate.

UPDATE: The malware in question seems to be the well-known ransomware package CryptoLocker . This malware encodes all of the documents on the infected machine and then demands payment from the user in order to unlock the files again. If you see a screen such as the one below, your machine is infected with CryptoLocker. It is essential that you contact local IT Support.


I wouldn’t pay them a penny, either

UPDATE 2: A new variant of this campaign is being widely reported by University users, in which the .zip file is instead replaced by an .arj file containing the malicious .exe . It is important to note that very few cloud-based antivirus engines scan .arj files as they are quite obscure and deprecated compared to the popular formats .zip, .gz and .rar. This format is currently affecting the personal email accounts of certain staff, particularly Google users as Gmail does not scan .arj files either.


Stay safe out there.

Further Reading:

Posted in Current Threats, Email, General Security | Comments Off