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: help@it.ox.ac.uk

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

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

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

Apache

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

IIS

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.

NGINX

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 Chrome.app” –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

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 http://help.it.ox.ac.uk/infosec/protectyourself/.

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.

Ambulances

A different kind of first responder…
credit: Graham Richardson

Option one – Patch and patch again

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

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

hello kitty plaster

Patches come in all shapes and sizes
Credit: Nomadic Lass

Option two – Restricting access to vulnerable services

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

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

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

Keep your first aid kit stocked
Credit: Christina Xu

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

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

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

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

Option three – High risk strategies

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

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

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

We’re not out of the ER yet

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

Posted in Uncategorized | Comments Off

Bash ‘Shellshock’ Bug – Now You Can Panic

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

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

Got anything nice planned for the weekend?

Got anything nice planned for the weekend?

Huh?

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

To directly quote from the official announcement;

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

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

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

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

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

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

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

A not-so-subtle visual metaphor

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

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

Who is at risk?

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

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

The smart money says, all these servers need a patch

The smart money says, all these servers need a patch

What can I do?

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

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

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

Seriously Apple, no rush fellas.

Seriously Apple, no rush fellas.

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

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

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

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

Why all the concern?

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

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

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

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

An even less subtle visual metaphor

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

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

Patch Bash as soon as possible.

Further Reading

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

Google Hacking – Making Use of the All Seeing Eye

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

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

Blue eye

I Spy With My Little Eye
Credit: Fabio

Google Hacking – What is it?

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

Is it Legal?

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

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

Three robots

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

How can I use it?

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

operator:term

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

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

site:example.ox.ac.uk exam

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

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

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

site:example.ox.ac.uk inurl:phpmyadmin/index.php

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

site:example.ox.ac.uk intext:”404 Object Not Found” Microsoft-IIS/5.0

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

Pills on a keyboard

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

What else can I search for?

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

Posted in General Security | 1 Comment