Bodleian Libraries Targeted Phish

OxCERT have received reports of very convincing looking phishing emails appearing to originate from an email address. The phishing emails use the subject “Library Account Access” and contain links, which are disguised to look like they lead to our own webauth pages.

The phishing emails claim, “Your access to your library account is expiring soon and it won’t be accessible for you. You must reactivate your account in order to continue to have access to the library services.”

If you receive one of these emails, please delete it without clicking on the links. If you are a member of the University of Oxford and think you may have been taken in by this scam, please contact your local IT support staff as soon as possible.

Posted in Current Threats | Comments Off

TRANSITS II Workshop, Utrecht

At the end of September I attended the TRANSITS II workshop organised by The GÉANT Association (previously TERENA), kindly hosted by SURFnet at their offices in Utrecht, NL. This course follows on from the TRANSITS I workshop that I blogged about at the beginning of the year, but focuses more on specific technical skills, rather than the overall workings of a CERT.

Inadvertently breaking with OxCERT tradition, I neglected to take any photos during this trip. Instead I’ve included images from the Internet for visual relief, they’re probably better than anything I could have achieved myself anyway!

Red tulips

Of course, Holland is famous for its tulips…
Credit: Jan Ramroth

Digital Forensics

Day one kicked off with a fascinating overview of computer forensics from Jaap van Ginkel. These sessions covered general digital forensic principles, combined with practical, hands-on exercises in acquiring forensically sound disk and memory images for analysis. The theoretical explanations were interspersed with real world examples, which always help to bring things to life.

Jaap went on to describe various places that evidence might be found on a disk, along with a selection of tools to help automate the process.

While it was noted that a short course like this couldn’t turn a novice into a forensics expert, the information is particularly useful for our team as we are looking to enhance our own digital forensics capability in the near future.

Human Communication

Don Stikvoort broke up the straight technical talks with an interesting module on Human Communication. Historically, IT is not an industry that has been seen to value communication skills; but the ability to both listen and explain effectively, in a variety of formats, is essential in a modern workplace – technical or not. Certainly, OxCERT are required to communicate regularly with colleagues throughout the University, and in the wider information security community.

The communication sessions touched on various valuable areas, such as how to build rapport with others by subtly and unobtrusively matching or mirroring their pose. It was also interesting to learn that only 7% of typical communication is conveyed by the words used, the rest is interpreted from body language and tone of voice. Perhaps this explains some of the misunderstandings that lead to spiraling arguments on mailing lists!

Windmill in Holland

… And its windmills.
Credit: John Morgan


Wim Biemolt started the final day with some engaging talks about Netflow, particularly using the Nfdump and Nfsen tools. OxCERT already make extensive use of Netflow to investigate security incidents, but the refresher was welcome. I was not personally familiar with the Nfsen web interface so enjoyed having the opportunity to experiment with it.

These sessions also opened up useful discussion of the practical uses of Netflow for a CERT, and the appliances that can be used to generate flow data from traffic.

ENISA Exercises

We rounded off the course by working through one of the ENISA CERT exercises. These exercises are freely available from the ENISA website and present various scenarios.

Our exercise instructed us to assume the role of the national CERT of a small, fictional country. In the scenario, the country in question is subjected increasingly serious and politically motivated cyber attacks. This opened up some interesting discussions and differing points of view, these exercises would certainly provide a useful starting point for anyone planning their own security fire drills.

In Summary…

All in all, another very worthwhile course with a nice mix of hands-on exercises and background theory, and a great follow up to TRANSITS I.

Posted in Uncategorized | Comments Off

Scam Calls Claiming to be from OxCERT

This blog appears to have attracted a new kind of reader, the telephone scammer. Back in September, we reported that scammers had begun impersonating IT Services staff; in a recent twist, it appears that the miscreants are now claiming to be members of OxCERT.

As before, these imposters are still purporting to call from “146 Banbury Road”, and the calls are from international withheld numbers.

OxCERT only contact end users directly on exceptionally rare occasions, and the IT Services Helpdesk does not make any unsolicited calls. If you receive a call claiming to be from a representative of IT Services or OxCERT, please exercise extreme caution, especially if any of the following points apply:

  • You are not currently affiliated with the University of Oxford
  • The call is unsolicited
  • The call comes from a non-UK number

As before, if in doubt; we suggest asking the caller for a contact number to test, 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:

smashed phone

Scam calls are frustrating. But don’t take it out on the hardware!
Credit: Solarbotics

Posted in Uncategorized | Comments Off

New Malware Campaign – ‘Dyre’ Banking Trojan

In recent days OxCERT have witnessed a sharp rise in the incidence of emails associated with the ‘Dyre’ banking malware family. This strain of malware concerns itself with the theft of financial data including credit card details, logins to payment services such as PayPal, and access to online banking websites.

Yoink! CC: Edwind Soto

CC: Edwind Soto

This campaign is quite easy to spot – keep an eye out for emails with the following characteristics:

  • Subject: “Unpaid invoic” (Spelling errors in the subject line are a characteristic of this campaign)
  • Attachment: Invoice621785.pdf (The number is random, but the format is constant)

If you see ANY email matching this format, DO NOT OPEN THE ATTACHMENT unless you are 100% positive that it is a genuine and expected email from a trusted sender. Instead, either contact the sender to verify the message or forward the message to OxCERT via

Like many similar campaigns, this one encourages the user to download a malicious attachment; the attachment could be any of the usual suspects (.zip, .rar, .doc and so on) but is currently taking the form of ‘a weaponised PDF document‘. If you download and open the malicious PDF document, it will attempt to exploit some relatively elderly vulnerabilities in Adobe Acrobat Reader, CVE-2013-2729 and CVE-2010-0188. Once opened, the PDF will install a version of the ‘Dyre’ banking malware which will remain resident on the system and listen for financial information.

As long as you ensure your version of Adobe Reader is up-to-date this should not be a problem, but the potential always exists for a ‘zero-day’ exploit that could affect even current versions.

As always, the best defense is common sense. Do not open PDF attachments matching the format of the malware campaign, do not open attachments from unfamiliar sources, always verify with the sender if in any doubt.

Further Reading:

Posted in Current Threats, Email | 1 Comment

How To Train Your POODLE part II – Servers and Infrastructure

In our previous blog post, we gave a quick overview of the ‘POODLE’ SSLv3.0 vulnerability, followed by tips for mitigating the risks on client applications. In this post, we will focus our attention on server side strategies.

For servers using SSL, there is only one sure-fire fix; disable SSL in favour of TLS. Aside from the obvious and pressing concerns regarding the protection of user data, here’s another point for sysadmins to bear in mind. Several application developers have already indicated that they will be disabling SSLv3.0 support in the coming months. So if you’re running a server, best make sure you’re ready well in advance.

Isn’t Turning Off SSL Going to Cause Problems?

Yes, it probably is. Depending on your user base and their connection habits, this may be more or less of an issue. Consider your situation, plan, run tests, inform your users, do whatever it is you need to do. But do not ignore the problem, it isn’t going away.

Do I Need to Turn Off SSLv2 Too?

Yes. While POODLE does not target SSLv2, it has been considered insecure for several years. So if you’re still supporting it, now is a good time to switch it off.

Credit: Joi Ito

SSL has got to go, don’t give in to anyone’s puppy dog eyes
Credit: Joi Ito

Is Turning Off SSL All I Need To Do?

Possibly not, but it’s a good start. In addition, it would be wise to review the cipher suites you choose to support. TLS (and SSL) use asymmetric, public-key cryptography during the handshake process. This allows the client to verify the identity of, and communicate securely with, a server that they have not previously connected to.

As useful as asymmetric encryption is, it’s also far more resource-intensive than symmetric encryption using a pre-shared key. TLS and SSL neatly sidestep this issue by using asymmetric encryption to securely share a symmetric key, which is then used to encrypt the rest of the traffic for the session.

TLS and SSL can be configured to use a range of cipher suites for the symmetric portion of the transfer, and some are safer than others. Check out the ones you’re using, and see if they’re still up to scratch.

Credit: Philip Bump

Time to teach an old dog some new tricks
Credit: Philip Bump

Without Further Ado, Here’s Our Roundup of Server Side Tips


To disable SSL versions 2 and 3, modify the SSLProtocol line in the apache config file to read:

SSLProtocol all –SSLv2 –SSLv3

To alter the supported cipher suites, modify the SSLCipherSuite line in the SSL config. The available ciphers are grouped, but specific ciphers may be excluded using the ! operator. For example:

SSLCipherSuite HIGH:!aNULL:!MD5

More useful information about the groups (HIGH in this example) can be ascertained using the following command:

openssl ciphers –v ‘HIGH’

Don’t forget to restart Apache when you’re done. Apache have provided a useful howto and general documentation covering configuring SSLCipherSuite


SSL/TLS support is defined in the following registry key:

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols

This will contain subkeys for each protocol version. To disable support for a protocol, set the DWORD value to 00000000.

The Microsoft Howto can be found here.


Update any instances of the directive ‘ssl_protocols’ in the NGINX configuration to read:

ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;

Don’t forget to update the http and mail config blocks in the nginx.conf configuration files to change the default behavior. Finally, restart NGINX.

NGINX’s POODLE advice and howto can be found here.

Credit: Matt Zimmerman

We’ve run out of tenuous dog metaphors, so here’s a cat with a Mac!
Credit: Matt Zimmerman

Network Printers

For network printers that provide IPP functionality over SSL, you may need to wait for a patch from the manufacturer (assuming they still support your model). In the meantime, firewalling the printer is a good start; also consider allowing access to VPN users if remote printing is a requirement.

You may also wish to consider the sensitivity of the material being sent to the printer. If your users mainly print confidential documents, perhaps it’s time to get into the market for a new printer (that supports TLS). As always, it’s about weighing up the risk.

Network Infrastructure

Cisco are reviewing their product range and will be releasing patches as necessary, their advisory can be found here.

HP are also conducting a review of their product range, and will be updating this page with information as it becomes available.

That’s All For Now

We hope this information has been helpful, and that you now feel better equipped to eradicate SSL support from your systems. We appreciate that there might be some pain to go through yet, but it’s certainly time to let this venerable old protocol slip into the history books.

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

How To Train Your POODLE part I – Clients

As you may be aware, a serious vulnerability dubbed ‘POODLE’ has been discovered in SSL version 3.0. A successful POODLE attack could allow a malicious person (with network access) to decrypt an SSLv3.0 connection.

What does that actually mean? Well, SSL is used to authenticate a server (proving they are who they say they are), and to encrypt subsequent network traffic, protecting it from eavesdropping. For instance, SSL is often used to protect communication between a browser and a webserver, or between a mail client and mail server.

SSL has been superseded by various flavours of TLS, which aren’t vulnerable and provide the same functionality. However, many applications still retain the ability to make use of SSL for compatibility reasons. A sneaky attacker (with network access) could cause sufficient disruption that a TLS capable client and server end up using SSLv3.0 instead.

So, in practice, what could an attacker pull off using the POODLE trick? They could, for example, set up a malicious wireless access point in a public place, and wait for innocent passers-by to connect their phones, laptops, etc. Once connected, the attacker could force the use of SSLv3.0 as described above, and help themselves to the encrypted traffic, pilfering online banking details, email, etc.

For a more detailed description of how the attack works, please see this excellent paper by the team who discovered it. Our blog post will focus on mitigation techniques for clients, with another to follow examining servers and infrastructure.

POODLE, stands for:  Padding Oracle On Downgraded Legacy Encryption, Incase you were wondering... Credit: Greg Westfall

POODLE short for: Padding Oracle On Downgraded Legacy
Encryption, incase you were wondering…
Credit: Greg Westfall

We Know the Drill – Time to Patch, Right?

Not exactly. The first thing to understand about POODLE; is that it exploits a fundamental flaw in the SSLv3.0 protocol. The key is not to fix antiquated SSL, but to abandon it entirely for newer and better solutions, such as TLS.

Which isn’t to say that there won’t be any patches to apply. On the contrary, vendors have already begun to release patches that disable the use of SSLv3.0; but that is precisely the point, we need to disable the use of SSLv3.0 entirely.

From a user perspective, the most effective way to protect yourself is to remove support for SSLv3.0 from your client applications. Of course, this is likely to break things while service providers get up to speed, but it’s a matter of weighing up the risks. I won’t sugarcoat the situation for you, things are fairly awkward at the moment, as different vendors take subtly different approaches to the problem. Some are disabling SSLv3.0 altogether, others plan to in the future, and some are implementing a variety of weird and wonderful mitigations.

If you’re in a hurry, and just want to know what to use; Internet Explorer with SSLv3.0 disabled, or Firefox with the SSLv3.0 extension installed are both good bets. You may also wish to avoid public WiFi hotspots, as described in the example above. For more detailed advice, please read on.

Time to take your poodle to the vet? Credit: Army Medicine

Time to take your poodle to the vet?
Credit: Army Medicine

Mozilla Firefox

Firefox version 34 (scheduled for release on November the 5th) will drop support for SSLv3.0. In the meantime Mozilla have released an extension, which turns off SSLv3.0 and below. The extension is available here.

Google Chrome

Google are planning to remove support for SSLv3.0 from all their products, ‘In the coming months’. Unfortunately, in the meantime there is no way to disable SSLv3.0 via the user interface. It is, however, possible to adjust the minimum TLS version when starting Chrome by adding the following flag: –ssl-version-min=tls1

The practical steps to achieve this vary depending on the operating system. In Windows, the flag may be appended to the ‘Target’ box of a Chrome shortcut. Other operating systems can launch Chrome from the command line using the flag, for instance in OS X:

open -a “Google” –args –ssl-version-min=tls1

Google Chrome also supports a mechanism called TLS_FALLBACK_SCSV which, when implemented by both the client and server, helps to prevent the use of SSL when TLS is available. It’s not widely supported yet, but it’s a neat idea and there’s a lot more to say on the subject; but that’s a blog post for another day.

Google’s POODLE statement can be found here.

Microsoft Internet Explorer

Disabling SSLv3.0 in Internet Explorer is fairly straightforward. Simply launch Internet Options and uncheck the SSL tick boxes in the advanced tab.

According to Microsoft’s POODLE security advisory, they are still looking into the vulnerability and have not yet decided on what action, if any, to take.

Apple Safari

Apple have released security update 2014-005 to address the POODLE problem in OS X Mountain Lion and Mavericks, the same fix is also applied in OS X v10.10 Yosemite.

Rather than preventing the use of SSLv3.0 entirely, Apple have just disabled the parts that are vulnerable.  As SSLv3.0 remains supported, pointing updated Safari at a testing site will often still produce a ‘vulnerable’ result – your mileage may vary. Apple’s own information regarding this update can be found here.


Opera are also continuing to support SSLv3.0 in Opera 25 for desktop and Android, for the time being. As with Google Chrome, Opera will support TLS_FALLBACK_SCSV. In addition, Opera are implementing a countermeasure known as ‘anti poodle record splitting’.  The idea behind anti poodle record splitting, is that the attack is only successful against SSL records of certain lengths. Opera will split the lengthy chunks up, which should negate the attack.

Sites that only support SSLv3.0 or below will also lose the Opera secure ‘badge’, so the user should get some warning when visiting these websites.

The one exception to the above is Opera 12 for Linux, for which SSLv3.0 support will be disabled in the coming days. Opera’s POODLE statement can be found here.

Mitigations come in all shapes and sizes  Credit: Carterse

Mitigations come in all shapes and sizes
Credit: Carterse

Settings, Updates and Patches, oh my!

From a client point of view, this vulnerability is somewhat fiddly to mitigate, each application must be considered and dealt with accordingly. SSL will eventually limp off this mortal coil, hastened by ever diminishing client support, but until then it pays to be aware of the risks, and reduce them where possible.

Other Helpful Advice

  • ZMap have provided some very useful step by step guidance here.
  • Another nice round up of Poodle advice for servers and clients
Posted in Apple, Current Threats, Google, Microsoft | Comments Off

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