Not Victim Blaming. Risk Reduction.

 General, Security  No Responses »
Jan 302015
 

There's a game called "victim blaming" which is where people decide the victim of a crime is somehow partially or wholely respomsible – the old "if she hadn't worn such a short skirt …".

Which is rubbish of course. The perpetrator of a crime is the one responsible for carrying it out whatever the circumstances.

But the shouting down of the "victim blamers" can perhaps drown out messages that allow risk reduction, and allow certain myths to be perpetuated. For example, many women believe that they are more at risk from strangers whereas most rapists are known to the victim.

Take a slightly less contentious crime – a phishing spam that criminals use to empty the bank accounts of the victim. Whilst the criminal here is obvious – the person who used stolen credentials to empty the bank account, the criminal needed the victim to make certain risky decisions.

2015-01-29_1517As you cannot look at the link contained within that, it's worth pointing out that if you paste the URL into a notebook, you will get a brazilian site … and I strongly suspect that Lloyds Bank is not very likely to use a Brazilian site (.br) for hosting their online account service.

And we call such victims "gullible". In the case of phishing, there are some simple procedures to follow :-

  1. Email doesn't necessarily come from whom it claims to be from. I can send you an email that will look as if it comes from Goodluck Johnathon without having anything to do with his email account.
  2. Don't click on links in emails.
  3. If your bank sends an email asking you to do something, shut down the email and open a web browser and use your existing way of getting to your bank's web site. Same applies to shopping sites, your workplace's IT department, etc.
  4. If you are determined to use a link from an email, copy the link into a notebook and read it. Does it make sense? Does the first part mention an organisation that has nothing to do with the organisation it is supposedly from? Don't trust it.

Plus a whole bunch more.

Detailing and quantifying risks isn't victim blaming; it's empowering someone to make educated decisions about their behaviour

Sony’s Tale of Woe

 Computing, Security  No Responses »
Dec 272014
 

What with North Korea’s latest explosion of bile, Sony is having a network security issue that will be used as an example of how bad things can get for probably decades. The phrase “I’m in the middle of a Sony” will be regularly used within the industry for the worst types of incidents.

It is not clear just what happened to Sony during the incident, and it will quite possibly never be clear. There are rumours that it may be something as simple as a phishing attack, and the FBI has claimed it has recovered code with similarities to code used in previous attacks against targets the North Koreans would wish to target.

It seems pretty certain that the North Koreans were involved in the attack against Sony; in addition to the code fragments, the North Koreans have gone out of their way to claim the attack was orchestrated by themselves. Yes they denied the attacks, but in the same way that a little kid denies having stolen the cake with all the evidence on his face.

Normally a corporation under attack from a state actor can be forgiven for getting opened up like a can of peaches, but this is Sony and a bunch of idiots who if they hadn’t lucked out by being in charge of North Korea would have trouble getting a job flipping burgers.

So Sony Pictures needs to have a good long look at it’s security. Two big tips for Sony:

First of all, change the name of the security team to the insecurity team. That is not a criticism of the team that does security at Sony right now, but because there is an assumption that the security team handles security and the rest of us doesn’t have to bother.

In reality, security is everyone’s responsibility.

Secondly take a second look at every recommendation that your security team has ever made and you have said No to. And reconsider.

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.

 Older Entries  Newer Entries