Tinkering With The Yubikey

 Computing, Working Notes  No Responses »
Dec 222014
 

This is a series of working notes on the Yubikey which is an interesting device used to supplement passwords to make two-factor authentication easier. It is essentially a hardware security token device that pretends to your computer to be a keyboard and enters a one-time only password that can be used to verify your identity – much like a password, but much more secure.

Well perhaps "easier" only if someone does all the configuration for you, although I am inclined to look a bit deeper into such things for my own amusement. My own key is a Yubikey NEO, but much of what follows also applies to the other Yubikey models.

Observations

This is the spot for observations on using the Yubikey over time.

  1. For some reason the Yubikey doesn't always "light up" on my workstation at work. It works fine at home – the green light always turns on ready for a key press – but at work it often seems to flicker and stay out. Not sure what causes this, but it always seems to be persistent when you really need to use it! 

Configuration

… is to some extent unnecessary, but under Linux there are three bits of software that can be installed to configure additional features of the Yubikey :-

  1. The library: https://developers.yubico.com/libykneomgr/
  2. The command-line tool: https://developers.yubico.com/yubikey-personalization/
  3. The GUI: https://developers.yubico.com/yubikey-personalization-gui/

All three build easily from the instructions given. Just make sure to remember to copy the udev rules from yubikey-personalization to /etc/udev/rules.d/ and run udevadm trigger to enable them. This will make sure you can access your yubikey as a console user, so you don't have to become root.

Enabling Linux Authentication

This was all done with a Linux container (LXC), so it could be relatively easily thrown away and restarted. The first step was to install the relevant PAM module :- 

# apt-get install libpam-yubico

This pulls in a ton of other required packages.

The next is to grab the unchanging part of your Yubikey token. This is the first 12 characters of what you get when you activate it. Whilst you have it to hand, now would be a good time to create the mapping file – /etc/yubikey-mappings :- 

# Yubikey ID mappings
# Format:
#       user-id:yubikey-id:yubikey-id:...
# (But usually only one)
user-id:ccccccsomeid

Next step is to add a little something to one of the pam files. For testing (assuming you have console) access, the relevant file might be /etc/pam.d/sshd but once you have things working, /etc/pam.d/common-auth might be a better choice. Right at the top of the file add :- 

auth       sufficient   pam_yubico.so debug id=16 authfile=/etc/yubikey-mappings
#       Added for Yubikey authentication.

Because these things always have problems when you first try them, it makes sense to set up the debugging log :- 

touch /var/run/pam-debug.log
chmod a+w /var/run/pam-debug.log

At this point, assuming everything works as expected :-

  1. You will be able to authenticate using ssh using either your Yubikey, or your password.
  2. This assumes your server is able to communicate with the Yubi Cloud.

There are further improvements to be made … and we'll get to those shortly.

But That's Not Two-Factor Authentication!

Indeed not, so we'll fix that right now.

Firstly remove the line we previously added to /etc/pam.d/sshd; because of the way that Debian configures pam, it is less disruptive (i.e. fewer changes) to make the change to /etc/pam.d/common-auth :- 

auth       requisite     pam_yubico.so id=16 debug authfile=/etc/yubikey-mappings
#       Yubikey configuration added.
auth    [success=1 default=ignore]      pam_unix.so nullok_secure use_first_pass

But before restarting sshd (you have been doing that haven't you?), you will need to add a Yubikey ID to /etc/yubikey-mappings for the root user.

At this point, you will only be able to authenticate if you enter your username, followed by both your Unix password and activate your Yubikey at the password prompt. Entering both at the same prompt is a little weird especially when you consider that there is no indications anywhere that Yubikey authentication is required.

But we can fix that. First of all, one small change to common-auth – remove the use_first_pass phrase.

Next edit the file /etc/ssh/sshd_config and find the ChallengeResponseAuthentication phrase and set to "Yes" :- 

ChallengeResponseAuthentication yes

And after a quick reboot, the log in process works in a sensible way :- 

» ssh chagers
Yubikey for `mike': (Press YubiKey)
Password: (Enter Unix password)
Linux chagers 3.14-0.bpo.1-amd64 #1 SMP Debian 3.14.12-1~bpo70+1 (2014-07-13) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Dec 31 15:37:05 2014
...
</pre>

Muting Smartphones

 Computing, General, iPhone  No Responses »
Dec 182014
 

Today I happened to come across a story about a priest who uses a signal blocker to stop phones from shrieking, bleeping, or blurting during church services. Very possibly illegal, although it’s quite understandable.

After all a church service is just like a theatrical performance and the distraction of phones is likely to put people off. We need more quiet at times – such as in the theatre, church, the quiet carriage in a train, or even a meeting room.

But a signal blocker is going too far – if there is an emergency, we need to be able to use our phones. And asking people does not work – there are always a few people who won’t bother to silence their phones. Not necessarily because they don’t care, but sometimes simply because they don’t think of it.

Rather than blocking phones, we need to tell phones to silent themselves automatically.

And it could be quite easy to do. In quiet zones, simply broadcast a well accepted SSID (“QUIETPLACE” perhaps?) and configure phones to automatically mute themselves when they see such an SSID. It would require support from phone manufacturers as most of us wouldn’t bother if we have to set something up – or even just install an App to do it, but it’s certainly possible.

NATS Software Failure: Old Code or Buggy Code?

 Computing, General, Media  No Responses »
Dec 142014
 

Anyone watching mainstream media for news about the software failure at NATS can be forgiven for thinking that old software is responsible for the problem that occurred recently causing many flight delays. The mainstream media seems to have clung onto the idea that the code is old and decided to blame that for the problems. You do have to wonder where they got these ideas from given that most journalists have the technology qualifications of a gnat. Perhaps from industry insiders who have a vested interest in selling new products perhaps?

Anyone who has written code can tell you that it is not old code that is responsible for software failures, but buggy code. Old code can be buggy, but so can new code. In fact as there has been less time to spend debugging it, new code is likely to have many more problems than old code.

That sounds like a recipe for leaving old code well alone. But it isn’t really. Old code needs to be updated and refreshed on a continual basis but not replaced in a “big bang” approach just because it is old.

Small changes and not big changes. Small changes are easier to do, quicker to do, and it’s feasible during testing to say that the small change is rubbish and to throw it away.

The more important a system is, the more important it is to evolve it towards the future rather than simply replace it with something newer and shinier.

And letting mainstream journalists dictate your IT strategy is always a mistake.

On Being A Shellshock Rider

 Computing, Security  2 Responses »
Sep 262014
 

(With apologies to John Brunner for stealing and mangling the title of one his books which happens to be a considerably appropriate choice)

What?

The Shellshock vulnerability, where a 23-year old vulnerability in the bash Unix shell can sometimes be exploited by attackers to run their own code on a vulnerable server. So far this vulnerability has been found to be exploitable with certain popular services running on Unix-based systems (including Linux).

Why?

Because I happen to be one of those going around telling people to fix their servers. And because I needed a place to mouth off about some of the more idiotic reactions I have encountered.

How Bad Is It?

Well it’s unlikely that this will cause the collapse of human civilisation, and it’s probable that your fridge will continue to work.

It’s like being asked how long a piece of string is whilst you’re still hauling it in and have not found the other end yet. It could be a great deal worse than expected or a bit of a damp squib :-

  1. The exploits may be much harder to make use of than expected. An attacker needs to find the vulnerable scripts on the web servers out there, and unless a very common web applications is found to be vulnerable, this may not be that easy to find.
  2. There may be a lot more vulnerable devices out there than expected – all of the embedded devices that idiots are assuming are safe because they come with BusyBox could have bash installed as well because some developer found that their script worked with bash and not BusyBox.
  3. An attacker may accidentally release something like SQL Slammer and cause widespread disruption.

Ultimately we have to wait and see how bad it is likely to be. Peering in to a crystal ball is always dangerous but my best educated guess is that :-

  1. We won’t see an Internet melt-down.
  2. Some sites will be broken into and some of those will have data leaked. This will happen anytime between 23 years ago (yes it could have been exploited in the past) and 23 years from now.
  3. Some unexpected ways to exploit this vulnerability will be discovered – for example there are plenty of people who believe that Windows is safe from this; as it happens my Windows 2012 server does have bash installed on it.

Bash? Unix Shell?

Most early operating systems were controlled with some sort of command line where you would enter a command at a terminal, hit return, and then the computer would respond to your commands – a bit like DOS whose descendent can be discovered on a Windows system if you ever run cmd.exe. One of the innovations introduced by Unix was the concept of the user selecting which command processor to use and this command processor become known as the shell.

Most Unix shells allowed some level of programming initially to make repetitive interactive tasks easier to perform, but this eventually become shell scripting where useful functions could be made available persistently and to other users by writing a sequence of commands into a file.

The concept of replaceable shells allowed early Unix users to chose between various different shells – initially the Bourne shell (sh), and the C-Shell (csh), with improved shells coming along over time – the TENEX C-Shell (tcsh), the Korn shell (ksh), my shell of choice: Z-shell (zsh), and of course the Bourne Again Shell (bash).

The Vulnerability

Unix (and Linux … and Windows too) have the concept of environment variables where variables can be set to some value and that value will be available to child processes. As an example, the PATH environment variable is set when someone logs in, and is used to specify where to search for programs that are not supplied with a full pathname.

For instance, if you were to enter the command ls into a terminal window, this would be translated to the absolute path /bin/ls or c:\cygwin\bin using a the PATH environment variable.

Bash has a feature where it allows shell functions to be defined within an environment variable; however trailing code following the function is run.

Normally that would not matter, but when an attacker can provide the contents of the environment variable, then that attacker has a way of running their own code where they should not be able to.

Because it is the most serious way of exploiting this vulnerability discovered so far, everyone has concentrated on exploiting this vulnerability through a web server.

Most web servers use environment variables as a way of passing information about a request (i.e. data supplied by an attacker) to any scripts they run; when this script is a bash script or the non-bash script invokes another program via bash (very common amongst lazy programmers) then an attacker can run their own code on the server.

So What Is Vulnerable? And Exploitable?

Let us distinguish between vulnerable where a program with a serious flaw is installed, and exploitable where an attacker can make use of that vulnerability. Because if you just fix situations where a known exploit exists, you are still exposed to unknown exploits. And it is distinctly possible that attackers will develop more and more ways of exploiting this vulnerability over time.

The short answer to the question of what is vulnerable is that every device with bash installed is vulnerable.

To those thinking that only Linux servers are vulnerable, the list of what is vulnerable will probably come as a bit of a surprise :-

  1. It should be assumed that all iThingies (iPhones, iPads, etc.) have bash installed. After all, OSX has been confirmed to be vulnerable and the iThingies run something very similar.
  2. Android phones can run bash and it may be installed by default. If it is, then it is vulnerable.
  3. Windows machines do not come with bash installed by default, but that does not mean that it has not been installed at a later date. Any large corporate application that started life as a Unix-based application may well have an installation of bash lurking somewhere within it.
  4. Similarly for any other non-Unix based servers (VMS, IBM Mainframes, etc.). In fact I would not be surprised if the proportion of IBM mainframes with a vulnerable version of bash installed is surprisingly large.
  5. Embedded devices, or the Internet of Things. One of my pet peeves is the assumption that because people usually find BusyBox installed on devices they are familiar with, that they assume that all IoT devices have BusyBox and not bash. All it takes is one developer who finds their funky script doesn’t work with BusyBox but does with bash to result in an IoT device to have bash installed.

In the long term, it is possibly the last category that is the most exploitable because such devices are rarely updated, are assumed to be safe, and are frankly the most likely to be running rancid code that is easily exploitable.

Mitigations

With worms actively exploiting this hunting down all the vulnerable web servers, it’s time to ask about means to limit the damage :-

  1. Why haven’t you patched yet? Hasn’t the vendor released the patch? If not, go and shout at them.
  2. Turn off any services that you don’t need. Now.
  3. Why does your web server need to make connections to the outside world? First indications are that the worms out there at present download a second stage to start behaving badly. If your server can just do it’s job but cannot download stuff then any worm won’t be able to fully activate. This is not a panacea as you can still be exploited, but you cannot be automatically exploited.

Naked Celebrities!

 General, Media, Security  No Responses »
Sep 042014
 

So apparently a whole bunch of celebrities have had their naked selfies leaked by some “hacker”. As to how this was done, we don’t really know and will probably never know given that Apple is so secretive. But we can guess some possibilities :-

  1. The hacker built up a list of possible account names – jennifer (Jennifer Lawrence) might be a good one to try – and then tried the top 100 dumbest passwords against each one in turn. You would not get every single account this way, and a fair few would turn out to be a fan of Jennifer Lawrence rather than the celebrity herself. But you would get a few that way.
  2. The hacker targeted the celebrities with a phishing attack – basically asking the celebrity what their account password is. This sounds too unlikely to succeed, but with a plausible looking login page it does work surprisingly often. It’s not just the terminally stupid that fall victim to such attacks; the victims are really those who are too trusting and often in too much of a hurry.
  3. The next method a hacker might use is to tackle Apple’s password reset service which uses “memorable information” such as the name of your first school, your mother’s maiden name, etc. There is always a bit of a problem with “memorable information” such as this – it isn’t really that private, and a celebrity is likely to have “leaked” all such private information over time.
  4. Through some unknown vulnerability in Apple’s iCloud service. Given that we suspect that iCloud has certain “issues” with security (apparently Apple has no intruder lock out to make password guessing attacks harder), this isn’t impossible but I would guess that it is less likely that the two more obvious attacks above.

There’s a great deal of hateful “slut-shaming” going on over this celebrity leak which apart from anything else is really missing the point. It may be embarrassing for naked selfies to be leaked, but other personal information could be dangerous if leaked – the celebrity’s home address and alarm codes?

It is not the victim’s fault; it’s the fault of the anonymous (at the moment) hacker.

But the victim can improve their behaviour to make it harder to victimise them :-

  1. First of all if you’re called Jennifer Lawrence, don’t use any permutation of your name as a username; or even enter that as your full name into any cloud service. Make one up.
  2. Make sure you are using a sensible password. It needn’t be excessive, but anything that is just a single word is just not good enough.
  3. Be less trusting with your acount credentials. Make sure you know what the location bar in your browser is and where it is, and check it when you login. And don’t click on links in emails.
  4. If the service you are using offers two-factor authentication, turn it on.
  5. Learn about security; you are a target. Don’t go overboard (but see step 6), but spend an hour a week doing a little reading and taking steps to improve your personal security.
  6. Hire or befriend a geek who can act as your early warning system for threats. And someone you can go to for advice.

Note that I haven’t said “don’t take naked selfies” – it may be a bit foolish, but a life without a bit of foolishness is hardly a life at all.

And of course most of those suggestions work for ordinary people and not just celebrities!

 Older Entries  Newer Entries