Sep 122015
 

According to the latest advice from CESG: "Regular password changing harms rather than improves security, so avoid placing this burden on users."

Wrong!

(Thanks to xkcd.com).

Most of the advice given is eminently sensible, and indeed forcing password changes on a frequent basis does more harm than good – when forced to change their passwords every 30 days (yes really!), people will commonly resort to sanity and use passwords of the form: someword-${month} (such as "happy-July"). However the advice to never force password changes was obviously written by someone who is under the belief that staff accounts have a somewhat limited lifetime – people change jobs, etc.

There is still a great deal to be said for changing passwords less frequently – say every couple of years. Or even a random number of days between 730 and 1,095, which will help to randomise calls to the Helpdesk. Amongst other things :-

  1. The concept of a strong password changes over the decades; allowing account passwords to remain the same for the lifetime of a staff account will mean that a considerable number of staff accounts will have weak passwords.
  2. There is such a thing as "accidental shoulder surfing" whereby someone acquires knowledge of part of your password by merely being present when you enter it. Over time they can acquire more and more of your password. 
  3. Only changing an account password when there is a suspicion it has become compromised means that there is no mechanism to lock stealthy intruders out. Whatever kind of anomolous account behaviour detection mechanism you have in place, there is always the chance that a compromised account can remain below the radar; periodic password changes do lock this intruder out.
  4. Less directly, but forcing regular account password changes on an infrequent basis does have the side effect that it allows the education of people that passwords can be compromised.

Of course every security person who read the CESG advice on passwords probably thought "Great. Now who is going to educate the auditors?". 

Jun 122015
 

This is going to be relatively lightweight in terms of technical content; most explanations of what a security exploit is do tend to be very technical in nature. 

So what is an exploit? At the most fundamental, it is what an attacker uses to take control of your computer. It can be compared with the installation routine you normally run to install a new application, because an exploit is effectively how an attacker installs their agent onto your computer.

There are on a simplistic level two kinds of exploits out there – the kind that works against people (the attacker tricks the person into running their code) or the kind that works against software. Of course there are exploits that sit in the middle and defy this simplistic classification, but as this is a simplistic posting, we'll gloss over those.

Exploits against people are frankly quite boring. All that is needed to protect against them is to apply the relevant operating system patches and avoid turning off malware protection. Unfortunately people tend to be very resistant to operating system patches and often indulge in practices that turn off their malware protection (drinking!).

The technically interesting exploits are the exploits against software. And when I say "technically interesting", it means that they get very technical and difficult to describe very quickly.

But at the core, such exploits involve tricking the computer into treating what should be considered as data as code. As a very simplistic example, imagine you have a web form that takes input from random strangers on the Internet, and the input from that form is added to a database. If the code has been written naively an attacker can simply append their code to the end of the input and it will be run.

All computer data is at the lowest level nothing more than numbers. The word "Hello" is actually encoded as a stream of numbers: 72, 101, 108, 108, 111, 10. Taking just the first three numbers, and I find there is a photo of myself with that sequence. And one of the editors I use (EMACS) also contains that sequence. The meaning of a sequence of numbers is dependent on how the computer chooses to interpret it.

A great deal of computer code is dedicated to interpreting those sequences of numbers as intended – so a picture is shown as a picture and not run as code in a Python interpreter. If a computer mistakenly (or is tricked into) misinterpreting a sequence of numbers as some kind of data that it is not, then the result could be just about anything but is most likely to be a crash or displaying garbage.

And just occasionally the computer will run that misinterpreted data as code.

And that in some circumstances can be called an exploit. But what happens after the exploit? What does the attacker do then? 

That's something for another time.

Elements Have Their Way

May 222015
 

So on my upgrade from Wheezy to Jessie, I found myself (amongst other issues) looking at a graphical interface where the mouse worked fine, but no mouse pointer was visible. After trying a few other things, it turned out that :-

gsettings set org.gnome.settings-daemon.plugins.cursor active false

Did the trick.

Of course that tip came from somewhere else, but as it worked for me, it’s worth making a note of.

May 102015
 

Whilst messing around with malware, memory dumps, and memory forensics, it is kind of handy to be able to use VirtualBox. Particularly when that is your virtual machine "weapon of choice".

According to the documentation, Volatility can read core dumps from VirtualBox. Once you realise that you need to specify a “profile” to read the result, this is quite simple :-

✓ mike@pica» VBoxManage list vms | grep Windows
"Windows" {9cefc95e-eaf2-4052-b466-cb665c73a36a}
✓ mike@pica» VBoxManage debugvm "Windows" dumpguestcore --filename ~/windows.elf
✓ mike@pica» ls -l ~/windows.elf
-rw------- 1 mike mike 2.1G May 10 14:11 /home/mike/windows.elf

If you specify the right profile option, then Volatility can make use of this :-

✓ mike@pica» volatility -f ~/windows.elf --profile=Win7SP1x86 cmdline          
Volatility Foundation Volatility Framework 2.4
************************************************************************
System pid:      4
************************************************************************
smss.exe pid:    260
Command line : \SystemRoot\System32\smss.exe
{Long list of processes removed}

All fairly obvious really, but if you do not specify the profile, volatility will present you an error that indicates it does not understand the format of the memory dump which is a bit confusing :-

✓ mike@pica» volatility -f ~/windows.elf cmdline                     
Volatility Foundation Volatility Framework 2.4
No suitable address space mapping found
Tried to open image as:
{Long list of memory image formats}

At least to someone as thick as me! Yes it took me ages to get this figured out.

May 022015
 

I have recently been upgrading my Linux containers from Debian wheezy to jessie, and each time have encountered a problem preventing the container from booting. Or rather as it turns out, preventing the equivalent of init from starting any daemons. Which is systemd of course.

Now this is not some addition to the Great Systemd Debate (although my contribution to that debate may well arrive someday), but a simple fix, or at this stage a workaround (to use the dreaded ITIL phrase).

The fix is to re-install the traditional SystemV init package replacing the new systemd package. This can be done during the upgrade by running the following at the end of the usual process :-

apt-get install sysvinit-core

Of course you will probably be reading this after you have encountered the problem. There are probably many ways of dealing with the situation after you have tried rebooting and encountered this issue, but my choice is to run the following commands from what I tend to call the "global container" :-

chroot ${container root filesystem}
apt-get install sysvinit-core

As mentioned before, this is not a fix. And indeed the problem may be my own fault – perhaps it doesn't help having the "global container" still running wheezy. Perhaps there are some instructions in the Debian upgrade manual that details some extra step you should run. And of course by switching back to System V init, we are missing out on all of the systemd fun.