Apache: Disable the ETag Header

By default, the Apache web server has an information disclosure vulnerability where the ETag header shows information about the file containing the object in question. This can contain an “i-node” value which in combination with the use of NFS can permit certain forms of attack.

Whilst not especially serious, it is worth disabling this header given how easy it is to do (and the security people will stop complaining about it). Simply add :-

FileETag None

to an Apache configuration file and restart in the usual way. You can make this change in almost any of the files commonly found under /etc/apache2 but two possible locations where it is ready to go are :-

  1. For Ubuntu/Debian-derived Linux systems, look at /etc/apache2/conf-enabled/security.conf (it is present but commented out)
  2. For SLES-derived Linux systems, add the line to /etc/apache2/conf.d/local.conf

Of course with any Apache change you will need to restart it (and preferably in a safe manner) :-

✓ root@pm-log2# apachectl configtest
Syntax OK
✓ root@pm-log2# apachectl graceful  

 
 

Posted in Technical | Tagged , | Comments Off on Apache: Disable the ETag Header

Apache: Disabling TRACK and TRACE Methods

By default Apache supports a number of HTTP methods in addition to the ones we normally use – GET (to get objects) and PUSH (to push form data although you can send form data with GET too). These additional methods are mostly harmless, but two do leak information about a server that you may not want an attacker to know.

Fortunately turning this off is a single line configuration change; simply add the following to one of the Apache configuration files :-

  TraceEnable off

And you will be protected (and won’t receive any more nasty messages about that bit of configuration).

You can make this change in almost any of the files commonly found under /etc/apache2 but two possible locations where it is ready to go are :-

  1. For Ubuntu/Debian-derived Linux systems, look at /etc/apache2/conf-enabled/security.conf (it is present but commented out)
  2. For SLES-derived Linux systems, add the line to /etc/apache2/conf.d/local.conf

Of course with any Apache change you will need to restart it (and preferably in a safe manner) :-

✓ root@pm-log2# apachectl configtest
Syntax OK
✓ root@pm-log2# apachectl graceful  

 

Posted in Technical | Tagged , | Comments Off on Apache: Disabling TRACK and TRACE Methods

Apache: Blocking “Dangerous” Files

There are all sorts of “dangerous” files that can appear within a web server’s document root; some are merely potentially dangerous but some can be genuinely dangerous. For example, if someone uses an editor to change a .php file, it is possible that a backup file for that script will be created within the document root called something.php~, and because this isn’t a genuine php file, it won’t be interpreted by php so the source code of your php script could be visible publicly :-

This is not something you want to see!

To protect against a whole set of similar attacks, blocking access to certain file “patterns” is a sensible precaution. The following can be added to a .htaccess file or to the main Apache configuration file (preferred) :-

<FilesMatch "(^\.htaccess|\.sql$|\.svn$|\.git$|\.DS_Store|.*~$|\.old$|\.bak$)" >
  Order allow,deny
  Deny from all
</Files>

The contents of the “FilesMatch” directive is effectively a list of regular expressions alternatives (grouped by enclosing in “(” and “)” and separated with “|” = standard syntax). For the benefit of documentation the individual clauses are :-

  1. “\.htaccess” (files containing the string “.htaccess”) – blocks access to Apache options file.
  2. “\.sql$” (files ending in “.sql”) – blocks access to SQL files.
  3. “\.git$” (files ending in “.git”) – blocks access to git repositories which are contained within directories named “.git”.
  4. “\.svn$” (files ending in “.svn”) – blocks access to svn repositories as above.
  5. “\.DS_Store” (files containing the string “.DS_Store”) – blocks access to OSX “droppings” left in directories.
  6. “.*~$” (files ending in “~”) – blocks access to emacs style editor backups.
  7. “.*old$” (files ending in “old”) – blocks access to a typical backup file.
  8. “.*bak$” (files ending in “bak”) – blocks access to vim style editor backups.

The configuration can be added to any Apache configuration file in the global context (rather than specific to a particular virtual server), but suggested places are :-

  1. For Ubuntu/Debian-derived distributions: /etc/apache2/apache2.conf (at the end of the file).
  2. For SLES-based servers, /etc/apache2/conf.d/local.conf

Once the change has been made, check the configuration with apachectl configtest. Providing that returns no errors, restart Apache gracefully with apachectl graceful.

Posted in Technical | Tagged | Comments Off on Apache: Blocking “Dangerous” Files

Processor Bugs: Meltdown and Spectre

There has been lots of stories relating to two new severe security vulnerabilities (one of which is in every Intel processor for over a decade); the trail of stories starts here. The details of the vulnerability are very highly technical so this post will concentrate on the less technical aspects.

As the original papers highlight, this is a result of a decades long policy across the industry of increasing complexity in pursuit of performance over security.

What Is Vulnerable?

For Meltdown, practically everything with an Intel processor; it is known that patches for Linux and Windows are being prepared. macOS was patched in December (if you have patched recently!).

Information on the vulnerability of other processors to Meltdown is a bit varied at present. It may be that AMD processors are vulnerable under certain conditions (although AMD have claimed that they are not vulnerable).

It is probable that Spectre is effective on rather more processors – AMD, and possibly some ARM processors (smartphones).

What Is The Effect?

In short, this is unknown. Technically Meltdown allows an attacker to access parts of kernel memory from any user process. This by itself sounds not so bad, but it allows an attacker to defeat defenses that have made whole classes of old attacks no longer viable. Essentially in combination with other attacks, the machine can be totally compromised.

In the case of Spectre, the effect is to be able to use the same sort of side-channel to view data from other processes address spaces, and in addition to escape “sandbox restrictions”. This means data leakage.

However this requires an attacker to be in control of data that controls the execution path through the victim’s code. Which is generically a hard thing to do, although in some cases (browsers) it is likely to be quite easy. Expect browser (and other application) patches to be released shortly … and apply them!

What Does The Meltdown Patch Do?

With the rumour that the the Meltdown patch causes a performance hit of 5-30%, there is some concern over it.

Technically the Meltdown patch is a work-around for the problem – it moves the kernel address space out of the user address space. Every time a system call is made, the processor has to reload the memory management unit, which takes time. Thus the performance hit.

How exactly this will effect performance remains unknown to a certain extent. Essentially applications that make very heavy use of system calls will notice a performance hit, and those that don’t will probably not notice a hit. In terms of desktop applications, it is likely that the web browser will be hit, but most other applications are likely to be unaffected.

It is likely that servers will notice the effect the most, and it is likely that only on heavily loaded servers will the effect be noticeable.

Summary

This is a serious set of vulnerabilities, and there is a significant risk of those vulnerabilities being used. In addition the mitigation for Intel processors has a significant risk of causing a performance issue.

However there is no reason to panic – patches are currently being prepared for release or have been released already.

There are many sources of information on these vulnerabilities being published; not all of which can be assumed to be totally correct (this posting included).

Links to further information :-

Posted in Technical | Tagged , | Comments Off on Processor Bugs: Meltdown and Spectre

The New Mirai

According to one news report, a new version of Mirai has recently been released causing an increase in the number of scans against port 2323 and port 23. According to our firewall logs, the number of scans against tcp/2323 has increased over the current month :-

There is indeed a big increase on the 22nd when the new malware was released, but interestingly enough, there is also a big increase in the week before, indicating that perhaps the new Mirai variant was released earlier than the researchers identified.

As a comparison, the same graph for tcp/22 – ssh, and a very heavily probed port looks like :-

Posted in Active Attacks, Technical | Tagged , | Comments Off on The New Mirai

Serious OSX Vulnerability – Get Root Without A Password

Apple’s latest version of their OSX (or macOS) operating system – High Sierra – has been found to have a serious vulnerability that allows anyone with access to the device to have full administrative access (“root”) without a password.

On any vulnerable device, you can login as the root user without a password from the lock screen (or login screen). A software update to fix the problem is being prepared, but it would be very sensible to apply a fix in the short-term.

To fix the problem, simply set a password for the root user; start a Terminal and from the command-line, run the following command :-

sudo passwd root
Password: {Enter your own password here}
Changing password for root.
New password: {Enter root's new password}
Retype new password: {Enter it again}

You should probably store the new password for the root user in an appropriate password store (Keepass, or KeepassX), although you will probably never use it.

Links for further information :-

The vulnerability is an interesting one in a sense – in theory there is no need for the root user to have a password as it is not intended for direct use, but if the account accidentally becomes enabled then it becomes a dangerous (and easily exploitable) security hole. To be safe, Apple should not only have disabled the root user, but also generated a random password for that account.

The vulnerability can be exploited locally (with access to the keyboard) and in some instances remotely.

Posted in Active Attacks, Passwords | Tagged , , , , | Comments Off on Serious OSX Vulnerability – Get Root Without A Password

BadRabbit Up And Running

According to reports, a new ransomware infection dubbed “BadRabbit” is spreading in Russia and Ukraine, and one or two other places further afield. Early indications are that this is not going to become a really nasty problem, but that could be wrong.

The infection spreads via one of three methods known :-

  1. Via email promising an update to Adobe Flash player, which is a widely exploited piece of software that has had many updates distributed although not in this way.
  2. By scanning for and exploiting an old vulnerability in Microsoft’s file sharing protocol (“EternalBlue”).
  3. By making use of MiniKatz to break in with compromised credentials.

Of the methods, the last is the most serious as it would allow the infection to spread within the University. But the most likely method to break in from outside the University is the first method.

Once a machine is infected, it will immediately try to spread itself, and infect local files.

In terms of genuine measurements of how bad this problem is, the firewall is blocking incoming traffic to the Microsoft file sharing service, and the sum of each day’s block over the whole of October amounts to about 15-25 million per day. Whilst there is some increase in the last week, there is nothing to indicate that BadRabbit is having a significant effect on the network.

Posted in Active Attacks, Malware | Tagged , | Comments Off on BadRabbit Up And Running

KRACKing Wireless

The latest big security exploit is a mechanism by which WPA2 secured wireless networks can be compromised to disclose previously encrypted traffic in the clear, and to insert malicious traffic. The original web site announcing the vulnerability can be found here with a translation into more ordinary language here.

Although a serious vulnerability, there are several elements that make this attack somewhat harder to carry out :-

  1. It is a very technical attack that has not been “bundled” into a ready to use form.
  2. The attack involves creating a “fake” access point with the same name as the network under attack. This implies physical proximity, although with wireless networks that can be a great deal further than you imagine – an attacker able to use this vulnerability is quite likely to be more sophisticated than usual, and have access to specialist wireless equipment that can extend the range of wireless networks.
  3. Whilst all WPA2 networks are vulnerable, impersonating a enterprise wireless network is somewhat more complex than impersonating a personal/home wireless network. This means that the EDUROAM wireless network may be somewhat safer than your home network.

Having said that, this vulnerability is harder to fix than usual and is likely to remain around long enough that it will be regularly used. Fixing just the wireless access points isn’t sufficient; it is necessary to fix those and the client devices connecting to the network. And in many cases (IoT devices and/or older Android phones), the client devices will never be fixed.

Remediations

To prevent this attack there are a number of things you can do yourself :-

  1. Use a VPN. The University runs a VPN service, and any traffic that goes over the VPN is not subject to this attack. To put it another way, if you have the VPN turned on, an attacker can be busy compromising your wireless network as much as she likes, but your traffic will be safe. We recommend the use of a VPN when working whilst travelling anyway.
  2. Upgrade your wireless router’s firmware as soon as possible. We are. If your wireless router is supplied by your ISP, nag your ISP about an update. Otherwise check with the manufacturer for a firmware update.
  3. Upgrade all your client wireless devices – laptops, phones, and all those “IoT” devices that you have.

Bear in mind that advice elsewhere suggests using tethering; if you set up your phone as a mobile wireless hot-spot then you may still be vulnerable if one of the phone or the connecting device has not been updated.

Posted in Technical | Tagged , , , | Comments Off on KRACKing Wireless

Patching Your Mouse? Yes, Really!

Strange as it may seem, if you have a certain type of wireless mouse you may be vulnerable to an attacker being able to inject keyboard keystrokes into your computer; with this they are able to do just about anything you can imagine (and a fair bit you cannot) to your computer and use access to your computer to spy on your activities.

Now this attack does require physical proximity. The advertised range of the vulnerable devices is 10m, and an attacker could well be using an external antenna to extend that considerably, so physical proximity is not impossible.

The main vulnerable device are the Logitech family of wireless mice and keyboards – basically anything using the Unify wireless dongle :-

Whilst the problem may have been fixed in the newest devices, it makes sense to assume you are vulnerable with any device purchased any time before 31st March, 2017 (older devices can stick around on shelves a long time).

To fix the problem merely requires a firmware update, but who thinks of checking whether their mouse needs a firmware update? And how frequently?

The firmware update is relatively easily applied, and can be applied with all of the major desktop operating systems – Windows, OSX, and Linux.

Direct Updates (Temporary)

Unfortunately it would appear that Logitech have broken their update mechanisms by re-vamping their websites. As a temporary measure, it is possible to download the update directly: https://community.logitech.com/s/question/0D531000058b3B7CAI/logitech-response-to-research-findings.

As a side effect, the update mechanisms below will fail to identify outdated versions. If your firmware version does not end in ‘029’ or ‘030’ (or later), then you need an update.

Updating the Firmware with Windows (and OSX)

The process of updating the firmware with OSX is as similar to updating with Windows, that repeating the instructions with OSX screen shots instead of Windows screen shots would be unnecessarily repetitive.

To start with, you will need to download and install the Logitech software (http://support.logitech.com/en_us/software/unifying). Once installed open it :-

Click on the “Advanced” option :-

At this point, click on “Check for updates” to ensure that the software’s idea of what the latest firmware is reflects the latest changes. Then for each of the devices listed in the left hand side (including the “Unifying receiver”), click on the “update firmware” button if it is not greyed out.

Once clicked, the screen will show :-

(Yes I have changed mice)

Simply click “Update”, and you will then be asked to turn off your mouse and turn it back on again.

Repeat this process for all of the entries in the “tree” of devices (including the wireless dongle itself).

Updating the Firmware with Linux

If you just happen to be running Fedora Core 26 (or Ubuntu 17.10), the firmware updates may show up automatically within GNOME Software where the operating system updates also show up :-

If you wish to do this the manual way, you can open up a terminal and running the following commands :-

$ sudo fwupdmgr refresh
$ sudo fwupdmgr update

With the exception of the diversion into geek-land, this is how firmware updates should be managed – one central place to get and apply updates without having to know that your mouse needs a firmware update.

Having said that, only two major manufacturers (Logitech and Dell) have currently signed up to this piece of Linux.

Posted in Technical | Tagged | Comments Off on Patching Your Mouse? Yes, Really!

Think Work, Think VPN

We are encouraging everyone who works remotely to immediately start up a VPN connection (to our VPN of course!) whenever they start working remotely. This is for a variety of reasons, but includes :-

  1. Any on site services that you might need for working are being made available only via the VPN. This includes some on site services that were previously more widely available.
  2. Any site where you might connect to Google service and/or UoP services may be compromised and your traffic would be visible to hackers. Using the VPN means all traffic is encrypted – a hacker will see that you are connecting to a UoP VPN but that is all. Without a VPN, any amount of additional information may be leaked – perhaps WordPress credentials to an official UoP blog site!
  3. By using the UoP VPN, all your traffic goes via our firewall which gives you an additional level of protection against malware that you are unlikely to find on the average cybercafe’s firewall (if they have one at all).

Apart from all those reasons, it is also sensible from a practicable point of view – if you immediately bring up the VPN when working, you won’t be slowed down when you need to use the VPN. Rather than trying to use an internal service, wait for an error to occur, and then remember that you need to use the VPN, it will just work.

The “Work Anywhere” articles for Personal Devices and UoP Laptops will give you directions to the relevant article on setting up the VPN.

Posted in General | Tagged , | Comments Off on Think Work, Think VPN