Sep 222015
 

So it looks like Volkswagen has been fixing emissions testing in the US …

220px-Volkswagen_logo_2012.svg

It seems that they have probably built into the engine management software something that detects when the engine is being tested for emissions. This apparently detects testing conditions and switches to a test mode where the engine power is reduced sufficiently to reduce emissions below the legal limit. Real emissions are up to 40 times the legal limit.

Volkswagen are apparently very sorry about this, but probably more about being caught than anything else. It could be just a one-off aberation, but frankly it is more believable that this sort of thing only happens within a company that has a culture where deceiving the customers and regulatory authorities is seen as perfectly acceptable practice.

So what else are they up to?

In a Science Fiction story by Charles Stross (Halting State), auditors do a much more thorough job of checking companies for ethical behaviour and screening executives for sociopathic tendencies; Volkswagon's path out of this mess involves and up close and personal relationship with a savage group of auditors looking into the ethics of the company. 

But who else is using engines that lie to emissions tests? Not only do many other car manufacturers use Volkswagen engines, but other car manufacurers also have an incentive to do the same sort of thing. How much do we trust them?

How many Volkswagen engineers and managers involved in this "special" project have gone on to work for other manufacturers?

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.