Thursday opened with a keynote from Olaf Kolkman of the Internet Society, looking at how to maintain an open but secure internet through effective collaboration. The open nature of the internet has meant that individuals and organisations have been at liberty to innovate, but that same openness that allowed Tim Berners-Lee to develop the web has allowed the bad guys to invent malware. He stressed that “if you are on the internet, you have a responsibility towards it”. Likewise manufacturers and vendors of internet-connected equipment have a similar responsibility to ensure that their products. CSIRTs have a role to play not just in responding to incidents but in promoting industry best practice within their communities, for instance mutually agreed norms for routing security (MANRS).

Next was our good friend Andrew Cormack of Jisc on “Protecting Privacy through Incident Response”. Security teams will inevitably be working with data which has the potential to breach users’ privacy, but should only do so lawfully and in a minimally-intrusive manner, proportionate to the threats they are trying to address. Simple measures can reduce the invasiveness of routine work, such as ensuring that access logs are kept separate from login records, only bringing the two together at the point where a person clearly needs to be identified – for example at the point at which a system has been confirmed to be infected with malware and its owner or user needs to be traced and informed.

Quadriga, Brandenburg Gate

One presentation described a study of how incident responders think, working with four experts on a small selection of incident scenarios and studying their decision-making processes. It was interesting that that the experts responded to some of the scenarios in quite different ways, although it was noted that there was more commonality when the incident report was more structured, something that might be improved if those reporting incidents are encouraged to do so in a more structured manner.

Jeremy Sparks of the US Air Force gave an interesting talk entitled “Effective Team Leadership and Process Improvement For Network Security Operators”. This looked at taking established techniques used on military missions and applying them to security incident response, with well-defined phases of detailed planning, brief, execute and debrief. The importance of effective debriefing must not be underestimated, and no team member should be afraid to speak up, even if their superior made a mistake.

The talks ended earlier than usual to make way for the annual ritual that is the FIRST AGM, limited to team representatives, their proxies and invited guests only. A vital component is the steering committee elections, which were hotly contested this year. Much of the meeting was spent reviewing the many activities of FIRST and the plans for the future.

The Berlin Wall at the East Side Gallery

The final morning began with Chema Alonson of Telefonica/Eleven Paths looking at the evolution of cybercrime towards the world of mobile applications. Most mobile malware is for the Android platform, where unfortunately Google Play are struggling to tackle the problem on their app store; as an iOS user it came as something of an eyeopener as to just how bad the problem can be. Often several apps will purport to do the same thing but it is hard for less savvy users to identify which are legitimate. Sadly it takes time for the rogue applications to be noticed and to receive negative reviews or be removed as a result of antivirus detections. The speaker examined the possibilities of using profiling techniques to identify likely malicious applications.

It was then time for the final breakout sessions, where I attended a talks by two national CERTs, firstly Id-SIRTII (Indonesia) on the use of machine learning in improving the accuracy of intrusion detection signatures. This was followed by JPCERT/CC (Japan) on “ChkDeface”, a tool they have written for the identification of defaced websites, capturing contents and taking screenshots in a “safe” environment but with a single request, aware that behaviour may change if they attempt a reload. We are all too familiar with the problem of defaced websites, and if the tool is made public we would certainly be interested in making use of it.

The conference was then wrapped up for another year, with the all-important prize draw, farewell speeches, good wishes for safe journeys home, and the hope of seeing us again at next year’s conference, which will be in South Korea.

Time to go home…but perhaps not in a Trabant

As usual it has been a very enjoyable conference, with numerous excellent talks, whether strategic, deeply technical or taking the operational management perspective. It’s also been a great opportunity to meet with teams from all over the world and spanning many different industries. We look forward to attending further FIRST events, whether annual conferences or smaller regional events, in the future.

Posted in FIRST Conference|Comments Off on 2015 FIRST Conference: Thursday and Friday

Wednesday’s keynote was from Philipp Amann of the European Cybercrime Centre, examining the subject of cybercrime. The boundaries between the “real” and online worlds are rapidly disappearing. Indeed plenty of “traditional” crime is now online – for instance drug sales are common on the “dark” internet through services such as Silk Road, and may reduce “traditional” crime, for instance by removing the need to operate on street corners.
Law enforcement must adapt to the changes and challenges, and cope with the ever-increasing volume of communications. Increasingly, to be successful law enforcement agencies need to work as part of international collaborations. An appropriate balance between protecting the privacy of their citizens while being able to conduct the investigations necessary to protect those same citizens, but of course the right balance is the subject of considerable debate.

Next was a talk on “passive SSL“, the use of passive information to monitor for vulnerabilities, making use of existing public data sources to track X.509 certificates and look for possible weaknesses, an area that has been of particular concern over the past year or so following vulnerabilities such as POODLE.

Lower level of the Postbahnhof

If there were an award for the best presentation title of the conference, it would surely have to go to that entitled “How We Saved the Death Star and Impressed Darth Vader”, given by two members of Cisco’s CSIRT. From a security perspective, a popular movie could be described in terms of Princess Leia stealing data, evading monitoring systems and exfiltrating data to unauthorised parties, who consider themselves “rebels”. The stolen data reveal a major vulnerability, exploitation of which leads to a disastrous compromise. Naturally Lord Vader calls for a new security team, and wants to see results. So how does a security team demonstrate its effectiveness? What metrics are called for in order to demonstrate how team members are performing, which alerting systems are providing the most useful results, and where should resources be best deployed?

Many of this year’s talks have considered the subject of threat intelligence, and I attended two during the afternoon. The first used statistical techniques to assess the effectiveness of different sources of threat information. Many sources are available, both free and paid services, but which are the good ones? It’s vital to look at the rates of false positives and false negatives in a statistically-sound manner. Don’t consider just the amount of information in the feed, but how many new entries are being added? Are they removed promptly or left to go “stale”? Recognise also that, even if one were able to combine all available sources of intelligence, it would still be far from comprehensive.

Bruce Schneier draws the winner of the sponsor’s prize draw

The other looked at how to ensure that threat intelligence feeds are turned into useful alerts. Testing that simple threat indicators can be used reliably to detect malicious behaviour is fairly straightforward. Testing that they won’t generate false positives is a much harder problem – you cannot test with absolutely all circumstances that might arise, but repeat tests every time the environment is changed, and adjust rules and retest in response to feedback. Good intelligence requires associated metadata to represent the level of confidence that something bad is going on, and the criticality – just how bad is it? Prioritise use of the intelligence that is most effective at finding the things which matter the most to you.

The final session was another series of lightning talks. Topics covered included “cyber insurance”, data visualisations and information exchange. However, for me the most interesting one was by Alexander Talos-Zens of the University of Vienna. He described a useful analogy of password security to aid user understanding, thinking in terms of an evil knight trying to gain access to a castle and his techniques for doing so, for instance by overhearing a farmer on legitimate business providing the correct password when challenged, the equivalent of eavesdropping on an unencrypted session.

Evening entertainment at the Postbahnhof

The conference banquet this year took us to the Postbahnhof, a former railway station for mail trains on the opposite side of the city, close to the longest surviving stretch of the Berlin Wall. Having travelled there on the city’s excellent S-bahn network, a drinks reception was followed by an excellent sit-down dinner, and then by live musical entertainment, prompting many of the attendees to take to the dance floor. A most enjoyable evening.

Tuesday’s presentations began with a keynote from Mikko Hypponen of F-Secure entitled “Securing our Future”, looking at current and future risks as more and more systems and data go online. He considers the risks to user privacy from the likes of Google and Facebook to be far greater than those from hackers – most users would be very surprised by just how much these organisations know about them, and their ability to link their online and “real-world” profiles, typically through their mobile phone numbers.

From a security point of view, all sorts of things will be internet-connected, whether domestic lightbulbs as part of the “Internet of Things”, or commercial aircraft. And state-sponsored attacks and espionage are not going to go away. Applying the wording of the Geneva Convention to cyber-warfare, even anti-virus companies could be considered a legitimate target.

There are other ways past your network perimeter

For the remainder of the day, the conference again split into streams, and I picked a selection from across them. First was David Jones of Cisco on advanced persistent threats (APTs), discussing the various methods by which they may enter an enterprise network and how they could be mitigated. He stressed that system administrators’ own computers are a particularly attractive target given the level of access they have into critical systems, and estimates that around 5% of system administrator accounts or computers are likely to be compromised at any given moment.

Many talks looked at vital components in the operation of an incident response team, such as threat information and how to assign metrics to demonstrate the value of the data obtained from different sources. Many teams suffer the problem of receiving a high volume of alerts, of variable reliability, with the results that analysts are spending far more time managing the data and too little responding productively to alerts. Teams should instead be looking to receive a volume of alerts that they can reasonably deal with, and have ready access to further data to enable those alerts to be handled with the appropriate contextual information.

A talk entitled “Bring Your Own Internet Of Things” followed on from some of the themes raised earlier by Mikko Hypponen, and stressing the huge increase in the number of connected devices over the next few years, with estimates of between 25 and 100 billion devices online within five years. These introduce new risks to enterprise networks, both from the devices themselves and from external suppliers who may be supporting them. Indeed the Target breach in December 2013 has been traced to a company responsible for Target’s HVAC systems.

Target your PR at the man in the street

Target were again mentioned in a talk by Scott Roberts of GitHub spoke on crisis communications, looking at some major data breaches and the quality of their response, especially how it is perceived by customers and the general public. In particular, it’s vital to use easily-understood language, being seen to be apologetic and to be taken all the appropriate steps. Ideally the response should be co-ordinated and include a detailed FAQ.

Following the formal presentations, there was a drinks reception among the stands of the various vendors present at the conference. Some are regulars at the conference, while others are exhibiting for the first time, and a wide range of services and technologies are covered. Afterwards many attendees adjourned to the cafe in the nearby Tiergarten for food, drinks and further networking opportunities.

It’s mid-June again, time for the annual FIRST Conference, and following on from Bangkok and Boston, this year it’s another “B”, namely Berlin. Our venue for the week is the Intercontinental Hotel, adjacent to the green oasis of the Tiergarten.

As usual the official start of the conference was an icebreaker reception on Sunday evening, but various training events were scheduled during the daytime. Of those on offer I was most interested in a day-long session on CSIRT Teamwork, organised by the group at George Mason University who presented last year. Through a series of exercises and discussions this examined some of the obstacles to effective collaboration and knowledge-sharing, both within a single team and as part of a “multi-team system”, with complex workflows between multiple teams necessary to effective incident response.

The evening reception was as usual a great opportunity both to make new contacts and to renew existing ones, from across the global security community. This year again sees a record attendance of 790 people from 68 countries, 359 of whom are at a FIRST conference for the first time.

Encryption has advanced a long way since the days of Enigma

Formal proceedings began the following morning with a welcoming keynote from Cornelia Rogall-Grothe, State Secretary at the Federal Ministry of the Interior and Federal Government Commissioner for Information Technology. Following an introduction to the numerous events planned during the week, it was time to choose the first of the “breakout” sessions to attend. As usual I ended up jumping between the different “streams”, starting with a presentation by the Polish national CERT on their fight against malware targetting the financial sector, both individual and corporate users. It was interesting to hear the various modes of attack, and the constantly-evolving tactics used to evade security measures.

The first of the afternoon talks considered the problem of effective communication of security problems with external parties, reaching out to the right people, passing on useful information and helping them understand the problem without resorting to “shock tactics” or speculation as to why it might be a problem for them. As someone with a longstanding interest in DNS, I was fascinated by Bill Horne of HP discussing the effective use of the billions of daily DNS queries within their corporate network in order to identify suspicious events requiring further analysis. Other talks included threat intelligence, and use of the R statistical programming language for security purposes.

Lightning over Berlin

The final session was a series of five-minute “lightning” talks, as always covering a diverse range of topics, spanning the deeply technical, tools of interest to the community, and pearls of wisdom of general interest. The evening then offered numerous networking opportunities, with some going to the traditional FIRST football tournament, and others opting for less energetic options in the hotel bar and nearby restaurants.

Posted in FIRST Conference|Comments Off on 2015 FIRST Conference: Sunday and Monday

After a relatively long period without a potentially-catastrophic vulnerability to report, we must again break out the hard hats as the numerically-improbable ‘CVE-2015-3456‘ is here and it wants to kill your datacentre. It’s called VENOM, in case you were wondering.

Yes, this is the actual logo

Oh not again…

No, not again, this is nowhere near as bad as 2014’s raft of terrifying shell and cryptographic security holes that had teams across the world working late into the night. That being said, VENOM isn’t something you can ignore if you are responsible for a virtual machine host or cluster that uses the QEMU software framework; this includes:

Linux Kernel-based Virtual Machine (KVM)

Citrix Xen

QEMU

To be absolutely clear, Microsoft Hyper-V, VMware products and others are not affected.

The VENOM bug

In the proud tradition of backronyms like POODLE and GHOST, VENOM stands for ‘Virtualized Environment Neglected Operations Manipulation‘. The VENOM bug does not target the operating systems of the guest VM nor the host on which it runs; instead, it is the QEMU ‘hypervisor‘ that is at risk of exploitation. The VENOM bug is described in OxCERT Security Bulletin OSB2015-060

Your precious VMs?

The hypervisor code sits between the guest and the host, operating as the ‘bridge’ and abstraction layer relied upon by either side to communicate with the other. This hypervisor code is minimalist but wide-ranging, incorporating all of the memory mapping and device drivers required to trick the guest into believing it is operating on real hardware.

The problem is the middle bit

One of the functions of the hypervisor is to supply a virtual storage device to the guest OS; most often this is a virtual hard disk file held on the host, or an installation ISO file held in a virtual optical drive container. For the sake of compatibility with ancient and archaic systems, most hypervisor code comes with an emulated 3.5″ floppy drive option, and QEMU is no exception.

Time was, if you had a virtual floppy you hoped nobody found out

Due to the sheer unpopularity of even emulated floppy disks, this code is rarely invoked and even more rarely actually used in production, but the hypervisor nonetheless maintains a driver infrastructure for the ancient medium, and it is here that we find our VENOM bug.

Implications

A successful exploitation of the VENOM bug allows a program inside a Virtual Machine to ‘break out‘ of its guest OS jail, and to run arbitrary commands against the host operating system. Hypervisors need a relatively large privilege space if they are to accomplish their tasks, and any attacker able to exploit this bug can therefore do anything on the VM host that the hypervisor can do. Because the bug attacks the hypervisor code itself, it is platform-agnostic and may affect any host running the vulnerable QEMU code. It is relatively easy therefore, for a single attack to escape from an otherwise highly-secure VM, and break out into neighbouring ‘isolated’ VMs with minimal trouble.

Hostile code escaping a VM, obviously

Even if proper precautions have been taken and the hypervisor is assigned least privilege on the host OS, it would still be possible for an attacker to interfere with other virtual machines on the same host, operating as they do under the same global hypervisor process. Fortunately, the announcement describes an exploit of this bug to be ‘non-trivial’ and PoC code is not available publicly, so hopefully it will be possible to patch before any real harm is done.

Pictured: Non-trivial exploit

No ‘in-the-wild’ exploitations of VENOM have been observed at time of writing, and it should be noted that at present this is a local attack only; without first leveraging other vulnerabilities, an attacker would require user-level access to a guest VM. However, it is not uncommon to see communal VMs left relatively unsecured, on the basis that the virtualised infrastructure will minimise the extent of any abusive user behaviour; this is no longer true, any user on an affected system must be considered capable of executing code against the host Operating System, effecting arbitrary changes in the guest VM and beyond.

Exploitation

The discovery outlined in CVE-2015-3456 describes a technical attack against QEMU’s virtual Floppy Disk Controller (FDC). The prerequisite for exploitation is that an attacker is able to issue device commands to this FDC; please note that even if an administrator has disabled the emulated floppy disk, the commands may still be interpreted by the FDC.

The FDC code expects disk commands to arrive with a specific data payload, and as such allocates a fixed buffer to receive the data from whichever application wishes to access the drive (can you see where I’m going with this?). Certain commands do not properly handle their memory indexes, and thus will write to FIFO memory if supplied with too much data as a parameter.

Yep, it’s a buffer overflow attack

By crafting a specific floppy disk command and aiming it at the FDC’s virtual interface inside the guest operating system, the attacker can overflow this fixed buffer. As with most buffer-overflow attacks, this one can be leveraged in a variety of ways, but the most common outcomes will be either a Denial-of-Service condition (by crashing the FDC and/or the hypervisor) or more seriously, the potential for arbitrary code execution in the context of the hypervisor process.

Mitigation and Resolution

Fortunately, software vendors are aware of the bug and are patching it ahead of any potential Proof-of-Concept code releases; provided vendor patches are applied swiftly, there is minimal potential for exploitation at this time. Patches are available for all major platforms, although it is worth verifying that they are being properly applied.

Chance favours the prepared mind

Any operators of KVM, Xen or QEMU-based virtual machine clusters are advised to patch as soon as possible; further, many network appliances make use of this code behind their proprietary interfaces, and it is not always clear which vendors are making use of this code.

Check with your vendors, and if you run an appliance that operates any form of internal virtualisation it is worth seeking updates for it also.

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):

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

Thanks.

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:

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

Thanks.

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.

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

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

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

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 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 oxcert@it.ox.ac.uk. 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 phishing@it.ox.ac.uk

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

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

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: http://www.cabrini.edu/itr/help/help/vss.pdf. 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

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.

CryptoPrevent

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;

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.

Summary

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?

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

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

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

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.

OxCERT have received reports of very convincing looking phishing emails appearing to originate from an @bodleian.ox.ac.uk 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

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!

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!

… And its windmills.Credit: John Morgan

Netflow

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.