Targeted financial fraud

We were recently alerted to an example of an attempted highly-targeted financial fraud. Now, we see fraudulent emails all the time, but fortunately most are immediately apparent to the recipients. In this case, however, the attacker had done their homework. The initial email used a forged From address in order to appear to be from the head of department; the recipient was a member of the department’s financial team (names have been changed):

From: Professor George Challenger []
To: Edward Malone
Subject: Request

Hello Edward,

I will need you to do a wire transfer as soon as possible.Please,get back to me via email for the beneficiary details.


Professor George Challenger.

The recipient of the mail initially considered this plausible and sent a reply, failing to notice that the original email had a Reply-to address set to go to a Gmail account with no obvious connection to the head of department. They received the reply shown below, but thankfully became suspicious and consulted a member of IT staff:

From: Professor George Challenger []
To: Edward Malone
Subject: RE: Request

Hello Edward,

Though, the invoice not yet received from the solicitor. I will send you the invoice as soon as possible.

kindly process a Wire Transfer to the below banking details.

Bank Name: HSBC bank
Account Name : MR DAVID AGNEW
Account Number : 98765432
SORT CODE: 123456
Amount : 9,236.83 GBP

Kindly Make the transfer same day transaction and send me the bank confirmation copy for payment references via email.


Professor George Challenger.

Remember, it’s all too easy to impersonate someone by email. Be especially wary of anything involving money, passwords or personal details, or that seems a little out of the ordinary. Contact the person in question by other means. Get a second opinion as to whether the email seems genuine. A little scepticism can avoid an expensive and embarrassing mistake.

Posted in Current Threats, Email, General Security | Comments Off on Targeted financial fraud

‘CTB-Locker’ Ransomware Campaign

Over the last several days, Oxford users have reported a growing number of suspicious emails to the OxCERT team; this has coincided with the discovery of a number of personal and University machines afflicted by a new ‘ransomware’ variant known as CTB-Locker aka ‘Critroni‘, a sophisticated variant of the better-known CryptoLocker ransomware family.

It's a bit harder than this in real life

It’s a bit harder than this in real life

What is Ransomware?

Ransomware is a relatively new form of computer crime, whereby a malicious file is sent to infect the target PC, generally (albeit not exclusively) by email containing an attachment or weblink to the attachment. Upon downloading and running the malicious attachment, the ransomware is quietly installed in a similar manner to a computer virus; the distinction is that ransomware does not immediately spread to other computers, but instead begins to silently pursue its dark agenda.

Once entrenched within the target computer the ransomware begins to silently encrypt every non-system file that it can reach; this includes network drives, USB sticks, even Dropbox accounts can be affected in this way. Once the encryption process is complete, files cannot be accessed by the user and cannot be retrieved by IT support staff; the files are now available only to the owners of the ransomware program.

The user will then be extorted via an on-screen prompt to deliver some currency in the form of BitCoins or other anonymised internet coinage to the ransomer; this, it is promised, will allow you to retrieve your files, for the low low cost of 3 BitCoins (BTC), approximately equivalent to 640 Euro.

If you don’t know what it is, don’t open it

CTB-Locker stands for ‘Curve-Tor-Bitcoin‘, in reference to the three core technologies that make up this newer form of ransomware. Briefly;

  • Curve‘ refers to Elliptic Curve Encryption, an extremely strong form of encryption based on number theory and effectively impossible to decrypt this side of a trillion years.
  • Tor‘ refers to The Onion Router network, an anonymised form of communication that renders the call-home process extremely difficult to detect and intercept
  • Bitcoin‘ refers to the virtual currency extorted from victims of the ransomware,  problematic to trace or block by law enforcement

To our knowledge, this is the first variant of ransomware to employ such a wide range of emerging technologies in pursuit of its goal.

The CTB-Locker ransomware currently affects Microsoft Windows operating systems only; if further variants affecting Linux and/or Mac OS X are discovered then further bulletins will be released.

How do I recognise it?

The current CTB-Locker campaign is spread by email; inside the email there may be an attachment, usually a .zip or .cab file, that the recipient must open in order to become infected. The accompanying emails are often blank or nonsensical;

CTB-Locker emails often look like this

CTB-Locker emails often look like this

Together with many global CERT teams and vendors, OxCERT are supplying samples of CTB-Locker to our antivirus partners at Sophos; you may receive a mail that has been caught by the mail filtering system;

Sophos PureMessage has caught this mail

Sophos PureMessage has caught this mail

In this case you are likely safe, but remember the format of the mail so that you may protect yourself in future from new variants that may not be detected. This screen is an example of an infected machine:

If you see this, your data is likely already gone

If you see this, your data is likely already gone

If you see this screen then the files are effectively lost, we have no reliable way of retrieving them at present and victims of the ransomware are strongly discouraged from acceding to the demands of the extortionists; in short, do not give these people any money. Inform OxCERT immediately at You may wish to try some of the

Good general advice to protect yourself and colleagues from this new campaign is to avoid opening attachments that you do not recognise;

  • Check the file type: is it really an Office document or is it really a .zip, .cab, .exe or another system file?
  • Check the sender: have you ever heard of these people before or is it just an official-looking mail from a random sender?
  • Check the context: do you often receive this type of mail or is it unfamiliar?

If you receive a suspicious mail from a colleague or other Oxford user, it is possible that the user’s account has been compromised; in this case please inform OxCERT immediately at

I’m infected, what can I do?

The only substantive defensive against infection and subsequent data loss remains conscientious checking of email attachments before opening, and ensuring that all critical machines are supplied with up-to-date antivirus software from a reputable vendor. Should the worst happen there are some potential steps to recover some lost data, but it must be stated that these measures should be considered a last resort and are in no way guaranteed to produce results.

Restore from Backups

Regular, complete backups are a natural defense against data loss, but take care not to restore files onto a machine that is still infected.

Because ransomware isn't the only risk to your data

Because ransomware isn’t the only risk to your data

A complete rebuild of the affected machine should precede any backup restoration.

Forensic Data Recovery

Variants of CTB-Locker follow a predictable process when encrypting files; before the encryption can take place, the malware creates a copy of the target file. It then encrypts this file, and deletes the original. This has the unintended benefit of leaving a pristine copy of the original on the drive media, provided nothing overwrites the space in the mean time. Forensic data recovery software can, under the proper circumstances, recover a portion of the lost data if the infection is recognised early enough.

An example of commercial data recovery software

An example of commercial data recovery software

It is important to remember that once deleted, Windows believes files are effectively ‘free space’ and may overwrite parts of them.

Volume Shadow Copies

If your system has Microsoft’s VSS enabled, there is a chance that ‘shadow’ copies of the encrypted files remain on the drive. The recovery of VSS data varies by Operating System version, but a rough guide to the process can be found here: Users are advised to refer to local IT Support for additional assistance in restoring VSS data if it exists.

An example of a Windows 7 file with a Shadow Copy

An example of a Windows 7 file with a Shadow Copy

Please note that more recently-observed versions of CTB-Locker are attempting to delete VSS copies to counteract this method.

Cloud Storage Recovery

As CTB-Locker will also encrypt files on certain cloud storage providers such as DropBox and SkyDrive, it is worth noting that many cloud providers create deep copies of all data when it is modified. This means there may well be an extant backup of the lost data, you just need to know how to find it. DropBox as a prime example make this process extremely easy. If you find your DropBox files have been encrypted, please follow this excellent guide on the DropBox website to help you to recover previous versions;

DropBox File Recovery Interface

Many cloud storage hosts offer similar functions, please refer to the relevant support sites for further instruction.

Preventive Measures

Besides the standard countermeasures of user awareness and antivirus packages, proactive steps that can be taken where appropriate by proficient individuals. Please note that these measures may well conflict with existing configurations or software dependencies, so should only be taken only in full awareness of the consequences.


A free utility designed specifically to target ransomware, CryptoPrevent uses a variety of local system settings to restrict the ability of known ransomware to execute and encrypt data via Windows Software Restriction Policies. It is by no means foolproof and may conflict with desktop management configurations, but may offer some measure of protection;

Not for the faint of heart

Not for the faint of heart

CryptoPrevent is available here:

Further Reading

Posted in Current Threats, Email, Microsoft | Comments Off on ‘CTB-Locker’ Ransomware Campaign

GHOST in the Shell – CVE2015-0235

Continuing the trend set by Heartbleed, Shellshock and POODLE comes another named vulnerability, welcoming us into the new year with the promise of remote code execution and buffer overflows against all the servers we’ve locked in cupboards and forgotten about.

Allow me to introduce to you CVE 2015-0235; ‘GHOST‘.

It’s not a real exploit without a cute logo


This newly-exploited weakness has been christened ‘GHOST’ in deference to the GetHOST function call in which the vulnerability exists; this lies within the linux-based glibc library, specifically a function heavily used to convert hostnames into IP addresses, gethostbyname(). This function improperly handles certain string processing operations, opening up potential for an overflow of the memory buffer. As the function by nature is employed in communication with the wider internet, there is potential for exploitation of any service or daemon that calls it from the glibc library.

This is a classic buffer overflow attack, and bypasses existing mechanisms designed to complicate such techniques, including NX, ASLR and PIE.

The earliest vulnerable version is identified as glibc-2.2, released on November 10, 2000. Versions subsequent to glibc-2.17 are not vulnerable; unfortunately this means a lot of Long Term Support releases for various core linux distributions remain exposed to the attack until they are patched including CentOS/7, Debian 7, RHEL 6/7 and Ubuntu 12.04.

It is worth stating clearly at this point that Proof-of-Concept code is available to attack the popular ‘Exim‘ mail service through this vulnerability (mitigation here), and reports are filtering in that attempts to exploit the hole are beginning to be seen in-the-wild. To quote from the official announcement:

Despite these limitations, arbitrary code execution can be achieved. As a proof of concept, we developed a full-fledged remote exploit against the Exim mail server, bypassing all existing protections (ASLR, PIE, and NX) on both 32-bit and 64-bit machines. We will publish our exploit as a Metasploit module in the near future.

Keen observers will note that the imminent publication of a Metasploit module significantly increases the risk posed by the exploit if left unpatched. Please read the OxCERT Security Bulletin OSB2015-014 for further information and remediation advice. Software vendors should be updating their repositories with a patch very shortly, if they have not already done so.

This of course applies only to services that are run on supported operating systems.

You ARE running a supported Operating System, right?

You ARE running a supported Operating System, right?

Am I vulnerable?

The full attack surface exposed by the exploit is currently not known, which complicates automated non-destructive testing. The Proof-of-Concept code listed in the original announcement could certainly confirm the presence of the vulnerability on your servers, but as it displays a tendency to SEGFAULT services it is launched against we would advise against this approach in a production environment.

A rough test for vulnerable C libraries on unpatched systems can be performed thus;

ldd --version

This should allow you to identify that your version is higher than 2.17 (not vulnerable) or between 2 and 2.17 (vulnerable). It is also possible to establish which applications depend upon glibc with the following command string:

lsof | grep libc | sort

Example output:

Guru meditation

Guru meditation

Note: Please be aware that once your system has received patches, the major version may be retained. In this case a recently-patched system might retain a ‘vulnerable’ version string in the test above, this is intended only as a quick test for operators who are certain their systems have not yet received the glibc patches from their vendor and are uncertain if they are running a vulnerable major version.

Known-vulnerable versions of linux include:

  • Arch Linux glibc version 2.18-1 and prior
  • Centos 5, 6 and 7
  • Debian Linux 7
  • Fedora 19 and prior
  • Linux Mint 13
  • OpenSUSE/SUSE Linux Enterprise 11 and prior
  • RHEL 5, 6 and 7
  • Ubuntu 10.04 and 12.04 LTS

Operators of vulnerable platforms are advised to remain vigilant to patches that refer to the glibc packages, and additionally to consider applying these patches ahead of any regularly scheduled maintenance.

Let us know how you get on

How does it work?

The GHOST vulnerability is exploited via the gethostbyname() glibc function, or more precisely __nss_hostname_digits_dots(). This code is invoked when a glibc-linked application wishes to resolve a DNS entry. As developers of connected applications can attest, this can be an extremely common event.

We're gonna exploit like it's 1999

We’re gonna exploit like it’s 1999

The attacker crafts an invalid hostname argument which is then supplied to the application; the application passes this argument to the vulnerable glibc function for processing, and it is here that the buffer overflow occurs. Once successfully exploited, the attack gains a limited yet arbitrary remote code execution privilege, in evasion of standard NX (No eXecute) bit protection and malloc hardening techniques. Similar exploitation can occur in a number of tools and services that make calls to this library.

As a service dependent upon these vulnerable calls, Exim can be attacked via a crafted HELO/EHLO exchange:

Bang, you're dead

Bang, you’re dead

For the brave and the curious, the PoC code is obtainable through links elsewhere in this post, it is distributed in C and is simple to compile against the vast majority of linux distributions. Please be aware that the code can frequently cause segmentation faults, as is to be expected from any exploit that can seize control of unallocated memory space.

May I again discourage the exploiting of production servers

Mitigation and Resolution

Currently there is a lack of conclusive research into which applications are exploitable and which are not. The bug itself was actually discovered and patched in 2013, but was not at that time recognised as a security risk. As such, not all vendors took the decision to include the patch into their newer major version updates; this significantly complicates the task of identifying affected systems by release and version numbers alone.  Contact appropriate software vendors if patches are not forthcoming through regular channels, and ensure that when patches are made available they are applied to all relevant systems as soon as possible.

Once a patch is applied, it is critical to restart all services that depend upon glibc

If your server cannot be fully rebooted at time of patch, a service restart will suffice until a full reboot can be scheduled.

As a general rule, any server operating a version of glibc greater than 2.17 can be considered safe. Enhanced risk applies to operators of Long-Term Support releases as their ‘stable’ release trees currently still include the vulnerable packages, and these releases are more commonly chosen  for ‘set and forget’ deployments where administrative interaction may be at a minimum for long periods. It is imperative that inventories are reviewed for the presence of these older versions.

Operators of unsupported platforms are at potentially greater risk still due to the current absence of back-ports for the relevant patch. as the bug was not seen to represent a critical security threat when it was discovered in 2013; this is a classic example of the risks inherent in maintaining services on unsupported platforms.

Mitigation advice remains as ever; be alert for glibc patches and apply as a matter of urgency, restart affected services, ensure that less visible machines are not overlooked.

Operators of Exim mail servers are advised to refer to the official Exim comments on the subject, which lists some helpful configuration changes that can mitigate the risk of the PoC HELO/EHLO attack vector.

Further Reading

Posted in Uncategorized | 2 Comments

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 on Bodleian Libraries Targeted Phish

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 on TRANSITS II Workshop, Utrecht

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 on Scam Calls Claiming to be from OxCERT

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 on How To Train Your POODLE part II – Servers and Infrastructure

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 on How To Train Your POODLE part I – Clients

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 on Sandworm 0-Day Exploit