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.

Apr 252015
 

So for ages I've been having these mysterious slow downs in connecting to some of my internal servers. A few seconds, but once connected things are working normally.

And of course I kept putting off having a look into the problem, because firstly I'm lazy, secondly there are other more interesting things to look at, and thirdly I'd already discounted the obvious (actually I'd "fixed" it but made certain assumptions). But it's finally time to have a look.

Now I said I'd earlier discounted the obvious but decided to have a look any way. The thing to remember is that when you connect to a server it almost always performs a DNS lookup on your network address, so a mysterious slow down could well indicate that DNS resolution is to blame. You could perform diagnostics to determine what the problem is, but in all the decades I've been solving issues with computers whenever a mysterious slow down has occurred when connecting over the network, then the problem has almost always been the DNS resolver.

Taking a look at /etc/resolv.conf on the relevant server (a Linux container), and I find the file has a nameserver within it that was retired several weeks ago! Fixing that solved the issue.

Lessons learnt :-

  1. Just because you have a centrally distributed /etc/resolv.conf that is automatically installed on all your home network doesn't mean to say that it is always automatically installed. My Linux containers don't get that centrally distributed file (which had been corrected!).
  2. Don't assume that it's not the obvious even if you have reasons for thinking it couldn't possibly be the obvious (see #1).