If you tell enough stories, perhaps the moral will show up.


Unnatural Selection

I've just started on my Christmas present, Kolmya Tales, by Varlam Shalamov. The introduction describes Shalamov's time in the mid-century Soviet labour camps and mentions the strokes of luck which allowed him to survive. I've read a little of the popular history and translated literature of the camps and the system that required them, and it struck me that all political survivor's stories have one feature in common: the amazing luck -- a necessary skill leading to a warm job, awakened sympathy in a guard or criminal, wasted food found or any of a host of other things -- that saved the witness' life. You could end up thinking that the penal labour was a happy-go-lucky setting where something would always turn up in time....

Of course that's wrong. There are no first person stories that don't have that lucky break, because all the potential authors -- without the lucky breaks -- died. By focussing on eyewitness accounts -- the best possible sources -- we've gone wrong. The camps were not about misery overcome by good fortune; they were about misery closed with death. Everyone is telling their truth, but the sample is bad, and so the picture is false.

Sex Differences

As I write, the three household males are all in front of general purpose computers of one sort or another. The MMS is building layouts with his Trainz program; not a Christmas present, but running much better on the new computer. He's passed a little milestone that no-one else seems to have noticed -- he's saving files with worthwhile names, so it's probably time to get a modern version for his birthday. The LMS is playing Half-Life downloaded as a Christmas present (very Christmassy...) and I am writing this.

The females are on the sofa, with a nice fire, watching High School Musical...

Which is better?


Happy Christmas

This hedging porn looks a bit Christmassy so it seems appropriate. Both taken on the solstice, truly just an hour before the thaw turned the rime to drips.

The hedge is my current work in progress -- you might just see I've reached the limt of my dewiring, and as the ground is too hard for stakes, I spent the time peeling back the stockfence and tidying up.

If you think the stakes look a bit dodgy, you're right. I salvaged them out of some chesnut paling lattice. Years old, but still hard enough to drive with a hammer, once I've opened up the ground with the iron. Almost any stake makes the job much easier.

The second picture looks very frigid indeed, but that's what happens if you go outside with the white balance set to flourescent...


Paid-for Malware

I sometimes get asked what anti-virus software I recommend for use on the home PC. I've tried a number of possible answers but my heart isn't in any of them: I know McAfee is a pain; bouquets for Norton outweigh the complaints, but not by much, so I've been recommending Kapersky -- I know it works and and the price is closer to reasonable. So a story like this one is a bit disconcerting. What are the lessons?

  1. Don't trust software more than you need to. We had all the warning we needed when McAfee pulled this same stunt on a bunch of system files a few years ago. Don't delete: Quarantine.
  2. It's time to start getting more assertive about my true answer....
Which is this: I don't run AV software at home. I never have. I don't do stupid things, mostly, and I don't let the children or Mrs U have administrator accounts. I know how to use autoruns (though I've never needed it) and there are the web scanners. I've never had any trouble, even on Windows, and my truly personal computer runs Linux.

Even just writing that, I can see how eccentric and impossible it seems.... really I should just say that I've no useful advice to give.


We are Them

Interesting session with Mrs U in which she dammed her mother's eccentricities. I think she was completely unconscious that the traits she found most obnoxious were those shared most identically between mother and daughter.

We believe that introspection is the most reliable source of knowledge -- it certainly feels that way. In fact, we are strangers to ourselves.

For an accurate portrait we need the opinions of those who know us, expressed in their private conversation and writing. But an accurate portrait is almost unbearable. The shocked diary snooper or eavesdropper -- the relationship changed needlessly but forever -- is one of those cliches that's trite because it's so real and so common.

I wonder whether this is the real reason why words like "nosing" and "prying" carry such an ugly load: not defence of privacy, but psychic self-protection. We can't bear to know.


Insourcing Authentication

It's appraisal time and the focus is on the performance management system. That's outsourced -- Internet delivered and hosted somewhere in Florida.

The issue that was brought to me was concern that users might be saving their performance management password in the Internet Explorer credential cache. It's never something that's worried me very much -- if you lose control of your workstation session, you've lost a lot more than the right to express an opinion on that annoying support guy with the awkward questions....

But it tied up some ideas that have been rather weakly formed in my mind.

We're outsourcing more and more, and the result is that our users do their jobs with accounts on this system and accounts on that, and I have no real confidence that there's even a consistent list. I'm certain that there are some systems a leaver will retain indefinite access to, simply because the whole service was set up by the business with no IT involvement and the helpdesk will never know to cease the account. This is pretty galling when we've recently put so much work into the Joiners/Leavers/Absentees process and the unused account purge. We're actually getting on top of this, but it's slipping away though a side door. There's certainly no hope of enforcing a consistent account name or password complexity policy.

At the same time, to deal with the many sites like Blogger, Delicious and others that I use all the time from loads of PCs, I've been looking at OpenID, a public authentication system, that allows the administrators of an Internet hosted application to securely trust a logon completed at a different site. I've gone so far as to set up an OpenID on the Verisign test site, even though I've nothing to log in to it with.

So I've been toying with the idea that authentication was a service we could outsource -- to Verisign or perhaps a two-factor supplier. In fact, I had that exactly wrong. Authentication is the one service we can always do better than anyone else because no-one can know better than we do, who works for us. This is true even if we don't know very well ourselves....

So we shouldn't outsource -- we should insource. We should provide an OpenID service as part of our infrastructure support for application outsourcing. Then we become the authority on who works for us, and what tests they have to pass to prove it:

  • Log on from inside, and you just need a logged-on Windows session; log on from the Internet and it'll ask for your RSA token.
  • The helpdesk can cease your OpenID when you leave, so terminating access to services they don't even know exist.
  • The authenticator could decline to recognise remote applications completely or on a per user basis.
  • Choices about access to the dodgier stuff like the password reset tool, or remote access can all be made here.
So it would all be fabulous. Just a couple of problems:
  • There doesn't seem to be OpenID software with the flexibility and convenience I need, and
  • The chances that application hosts can be persuaded to recognise their customers' OpenIDs seems close to zero.
So this frankly rather wonderful approach, which ought by rights be standard, is dead. But I think I'll put OpenID support on the qualification form just to watch them squirm.


Only a year old

First encounter with a Vista installation today -- a factory fresh Compaq.

  • Loved UAC -- it's definitely the future (that is, it's as good as sudo, so Windows has caught up with 1985 flavours of Unix.)
  • Loved how the compatibility with DOS3.3 is way better than W2K (don't ask.)
  • Hated the difficulty of finding where to give the Ethernet adapter a static IP address (got there in the end though)
  • Hated that the integrated Intel graphics with an experience index of 3.3 couldn't make Aero look like anything better than Ubuntu with a translucent theme on a mobile Pentium
  • Hated -- really hated -- having to wait for a dual-core 1GB laptop to pop up a printer property box or move some files. How sad. Maybe SP1 will sort it out.
In the meantime, the Dell I bought a few weeks ago turns out to be the ideal XP machine. So that's where it's staying.


How policy suceeds, for once

I've been purging out a dying domain. Disabled accounts with a last logon more than three months ago are deleted; enabled accounts with a last logon more than one month ago are disabled with a note in the comment. Do that every week or so. Keep a safe list for genuine service accounts and the domain will be nicely compliant by the time it stops.

The reason I've had to do this myself is a bit sad: the helpdesk, who own all account administration, will go through any distortion to avoid account difficulties. An odd-looking account -- precisely what should be disabled -- won't be touched for fear of breaking something. The policy itself gets re-interpreted to be "disable after ninety days" with no-one able to trace where that decision came from.

It's understandable. The best outcome from good application of the policy is that no-one complains. The likely outcome is senior staff complaining that the helpdesk has broken their account -- and no-one wants to hear that.

So, I've been doing it myself, and that makes everything different. Everyone knows that I break stuff, but everyone also knows that challenging me on what I break can leave them on the wrong side of a clearly distributed policy that they didn't read or understand....

Yes, and in this case I did a blinding job: The account policy allows just two types -- owned, which are subject to the AUP, and service which have to be on my list. The AUP says that owners are responsible for owned accounts, have to log on more often than once a month, and log off after no more than a week. That was carefully chosen to update the last logon time, and to transfer blame.

And it works! Hundreds of users deleted, a few tactful explanations, and no trouble at all. This is the root of the security truism that you start with a policy. You can't act without it -- but it has to be a good'un.


Audits fall with autumn leaves

We've just been visited by one of the many audits to which a regulated firm is subject. We didn't come out as well as I would have hoped but the point for me was different and more worrying.

These were competent people. They were clear about their wants: Evidence that the controls we publish and claim to adhere to are actually working. And they knew what "working" meant -- that the circle is closed with human escalations and choices on exceptions. So that was good (and a lot of work for us) except for one teeny issue.

"Working" also means that the control environment will actually stop trouble. And these guys had essentially no interest in the technical effect of the controls. If I said "this is a report that shows yesterday's changes to all application admin groups", that was the truth. No test that we have the same reporting on all production DCs. No enquiry about alternative ways to get the privilege. No test that our installations actually adhere to the admin group conventions. If I listed a firewall policy, or handed over the perimeter network diagram, that was it. No enquiry about how often I checked the cable patching....

Now I know that they can't check everything. And I wouldn't want them to.... I know that they're at the wrong end of a crushing knowledge asymmetry. But all the same, it reminds me of the drunk searching for his keys under the lamp post: not because he lost them there, but because the light is so much better.

In the mean time, remember:

  • A big four signature on a statement of controls -- SAS70 or whatever -- means less than you think.
  • Somewhere in the big city, a security guy is neglecting controls that expose trouble in favour of those that'll audit well.


Choice. I hate it.

I bought a new computer last night. Even though I'm not exactly Mr. Desktop I thought I would be able to make a sensible choice. In fact I was so overwhelmed, I nearly bought nothing.

First: supplier. I've bought from Morgan before and had a slightly patchy experience (but nothing unfair, and nothing that couldn't be resolved with my own skills.) This time I was going to avoid trouble by sticking to brand new stock -- retired from shops after going out of date. I liked the look of the HP media PCs with TV tuners and big plug-in HDs -- they were old enough to be packaged with XP Media centre (I really don't want that "which Vista edition" issue until SP1 --maybe not then), they were fully loaded with ports and the more expensive models had Intel dual cores, 2GB memory and GEForce 7600 with 256 MB. I didn't want a screen package because the more mad son has a history of headbutting flatscreens to death: CRTs are tougher and I have them already.

So I thought that was pretty cut and dried. But I can't resist a quick visit to Dell.

First impressions are low price -- Dell include VAT, and Morgan exclude it (which I think is a tad dodgy on consumer kit sold retail). Now I know that Dell charge a shameless £50 for delivery but it turns out it's free until the end of the month. Second thing is that XP is back on offer -- it was Vostro-only in September but now the consumer pages have it too. And it's XP Pro which is a big plus.

So into the configurator to be faced with all those tough choices. Many of the base builds lack 2GB and the prices start notching up as I make those tempting choices. Not all models let me configure "no screen" and if I'm having a screen maybe I should get the posh graphics as well.

I finally settle on a bearable heuristic. I'll only get factory fitted upgrades where I haven't upgraded myself successfully in the past.

I end up with PC Duo 6550, 2GB (I've had problems with dodgy 1GB parts), the base graphics (because no-name GEF8600 will be cheap and good in a years time), the base HD (definitely getting NAS ....) And a screen, which was too good to give up for £80 and I will put on the PC upstairs to keep the less mad son happy until he gets his laptop.

All that choosing left me emotionally committed to the Dell. I matched it to an HP package from Morgan and found it close (screen to placate LMS with graphics upgrade option in the future vs. no screen, and better but obsolete graphics now; no media centre tuner remote & wireless vs. XP pro and the confidence I wouldn't use that stuff; in stock vs two week delivery ouch) but a few pounds less.

So I bought the Dell. But it wasn't easy.


Secure Timestamp

I enjoyed watching the moon race past some bright planet a little above the sunrise last week. I guess it was Jupiter -- a bit too far along the ecliptic to be Venus.

Over the weekend, there was a news feature about the Mahdi army in Iraq. At one point the camera zoomed in on the moon to show this conjunction closer than I ever saw it. For me, that dated the report better than any digital means -- no encryption, no secure timestamp -- just very hard to fake.



Every morning lately, when I've been there to see, a train of twenty or so flatcars each with twelve colossal steel billets heads east, to Ashford and I guess the tunnel. This morning they were behind a class 92. In my mind this question: If the country is so prosperous that the government can offer flexible working hours to every employed parent, how can anyone make money exporting raw steel? Am I that detached from the real world?


Geek Alert

The shed computer has been on my queue for a very long time. It was running an elderly Kubuntu (6.04?) and I've never found it entirely satisfactory -- Konqueror is not supported in Google Docs, I couldn't get Firefox to install and in fact I couldn't get anything to update or install. Well, I can see which way the world is going, so I wanted to put a current Ubuntu, and I've finally done it. It wasn't easy. The PC is a Dell Latitude PIII. It was classy in its day, but I think it has problems, especially with the CD drive. The steps I've had to take to get it installed are these:

  • Switch off the Hot-Switchable Floppy option in the BIOS. I don't even have an FD, but with the switch on, the boot was delayed for tens of minutes negotiating /dev/fd0 errors.
  • Don't even try to boot the live CD into safe video (forcevesa). It would boot, in an hour or two, but it was continuously frobbing the CD and it would be impossible to get to the fourth screen of the installer. And the bars ar the top and bottom of Gnome were lost.
  • And I gave up on the live CD. The text mode install CD (select it with the check box on the Ubuntu download page) installed first time. The live CD install failed at random points copying files to the HD. My burn of that image passes the veracity test, and I exchanged HDs, and the problem was still there. But the text installer just works.
And once it's up, it's pretty good. I was notified of 16 updates, all of which applied even though one was for Firefox which was open at the time. I've added MPEG codecs (which I suspect are excluded from the build to preserve its freehood -- Fraunhofer have some MPEG patents) directly from the player, mc (which I have to have) through apt-get, and Penguin Command (which I've missed ever since I tried Suse 7.2) through the Synaptic package manager. It all works. The only real hiccup was the networking -- it needed a few restarts to work -- I think it wasn't playing nicely with DHCP on the firewall. I've tried tuning the display, but the automatic setting seemed best. Sudo works nicely. It's not quite as responsive as W2k but it is all so much better done than I remember -- and I don't miss KDE at all. Best of all -- malware won't run. I can browse on! Oh -- and on the whole, I don't think it's as stable as Windows. The kernel is better (though the scheduler is cruder) and the management GUI and command-line stuff is fine, but in userland many of the third-party apps can silently disappear.


Die Daylight Saving Die! Die! Die!

Hurrah! The log files make sense again, and the gods of time have punished the impious humans for pretending that the solar zenith is 13:00....


Physical Insecurity

A frisson walking across the fields on my way home this evening -- that lively sound of bullets wheeling past my head. It wasn't a demented assassin emerging from my ugly past -- the faint red light gave it away as an incompetent lamper with a silenced rifle killing rabbits behind Forstal farm. He carried on firing as I walked out of danger even though I was shining my torch at his likely location. Once I'd got to the safety of the lane I walked along to find out what was going on, and encountered a man claiming to be Shay Harbour(?) He knew about the footpath, he said, and thought his line of fire would be OK.

Any more of that sort of thing, and I'm getting a 50mW green laser and a night vision scope -- after this shone down his bins he'd be hard put to tell up from down, let alone fire his weapon.


Read a Text File with Comments

This is a little Perl idiom to open a text file and read all the non-comment lines.

Key parts are

  • <LINELIST> yields all the lines in the filehandle into the default scalar $_
  • s/^\s*//; s/\#.*$//; s/\s*$//; removes (==substitutes nothing in place of) first any space at the front of the line second any trailing comment and third any trailing space in $_
  • chomp strips the newline from $_
  • next if /^$/ skips past the rest of the loop processing if $_ is empty (it matches beginning of line immediately followed by end of line)
All of this could be directed to a named scalar variable, but using the default pays off in compact code that can be cut and pasted elsewhere.
my $listfn="linelist.txt";
open LINELIST, "<$listfn" or die "Open $listfn $!";
while (<LINELIST>) {
    s/^\s*//; s/\#.*$//; s/\s*$//; chomp; next if /^\s*$/;
    print "$_\n"; # Or whatever else you want to do.....
Obviously printing is a bit dull -- instead you could drop the lines into an array:
push @linelist, $_;
Use grep to search it:
@results = grep((/$mypatt/i), @linelist);
The i after the pattern makes for case insensitivity, and you have to
use locale;
to get it right for all character sets.



This is a perl script that shows what perl does well. It takes a couple of programs which provide useful output -- nmap and nbtstat -- and combines them into a single daily archive showing what's on your network. Key features are:

  • The input is a list of named IP ranges.
  • The output is written to hosts.txt and yyyy-mm-dd.hosts.txt automatically building an archive of what's up in the networks you care about.
To run it
  1. Install nmap and make sure it's in the path. nbtstat is part of any Windows installation.
  2. Install Perl, which means Active State.
  3. Create a range file that's just a text file with a few lines like these: (Obviously with your network ranges. You can use any range specification that nmap will accept.)
      # my range.txt 
  4. Make sure your reverse DNS is working, or you won't get any DNS names.
  5. Run it with a command like c:\perl\bin\perl nmap.pl range.txt
  6. check the output in hosts.txt to see server names, and, for windows servers, domain and server names.
To get the benefit, set it to run every day using a scheduled task (I find this is easiest with a .CMD file containing full path names for everything) and in a few months you'll have some worthwhile history.

# Start of nmap.pl by umacf24
# This program takes a single parameter -- a file containing  pairs.
# Example (but leave off the #)
# servers
# perimeter
use strict;
use warnings;

# NBTSTAT codes from Jim Halfpenny
my %group  = (  hex("00"), "00 Dom",
  hex("01"), "01 M Browser",
  hex("1C"), "1C Domain Controller",
  hex("1E"), "1E S Browser", # Browser Elections
my %unique = (  hex("00"), "00 WS",    # Workstation service
  hex("01"), "01 Msgr", # Messenger Service
  hex("03"), "03 Msgr", # Messenger Service
  hex("06"), "06 RAS Server Service",
  hex("1B"), "1B Domain Master Browser",
  hex("1D"), "1D Master Browser",
  hex("1F"), "1F NetDDE Service",
  hex("20"), "20 SVR", # File Server Service
  hex("21"), "21 RAS Client Service",
  hex("22"), "22 MS EXC Interchange(MSMail Connector)",
  hex("23"), "23 MS EXC Store",
  hex("24"), "24 MS EXC Directory",
  hex("30"), "30 Modem Sharing Server Service",
  hex("31"), "31 Modem Sharing Client Service",
  hex("43"), "43 SMS Clients Remote Control",
  hex("44"), "44 SMS Administrators Remote Control Tool",
  hex("45"), "45 SMS Clients Remote Chat",
  hex("46"), "46 SMS Clients Remote Transfer",
  hex("4C"), "4C DEC Pathworks TCPIP service on Windows NT",
  hex("42"), "42 McAfee AV",
  hex("52"), "52 DEC Pathworks TCPIP service on Windows NT",
  hex("87"), "87 MS EXC MTA",
  hex("6A"), "6A MS EXC IMC",
  hex("BE"), "BE Netmon Agent",
  hex("BF"), "BF Netmon Application",

# results stored in an array for re-use
my @nmapout;

my $ofn='hosts.txt';
my $opath='.\\ip\\';

my $header = "Key\t++ Up but unnamed, \n\t** Named but not responding to ping.\n\t?? Improper NBT names\n";
$header .= "Ping scan run between ".localtime(time())." ";

my $ipall; my $ipup; my $ipdown; # Address counters

# Process the file of network names. Run NMAP against the network spec (iprange).
while (<>)
  next if (/^\s*#/) ;
  my @line = split /\s+/;
  if (2==@line)
      my $ipname = sprintf "%-15.15s ", $line[0]; # Fixed width
      my $iprange = $line[1];      

      my $cmd = ".\\bin\\nmap -sP -R -oG - $iprange |";    # local nmap
      print STDERR "$cmd\n";
      open (NMAP, $cmd);
      while ()
          next if /Smurf/;
          if (/^Host: /)
              my $hostline=$_;
              $ipdown++ if ($hostline =~ /Status: Down$/);
              $ipup++ if ($hostline =~ /Status: Up$/);
              my $flag ='   ';
              $flag = '++ ' if ($hostline =~ /\(\)\tStatus: Up/) ;# Un-named
              $flag = '** ' if ($hostline =~ /\([^)]+\)\tStatus: Down/) ;# Named, but not responding
              my $hostip = $1 if ($hostline =~ /^Host: ([0-9\.]+) .+ Up$/);
              my $prefix=$ipname . $flag;
              my $postfix=nbtstat($hostip) if ($hostip);
              $hostline =~ s/^Host: /$prefix/;
              $hostline =~ s/Status: Up$/NBT: $postfix/ if ($postfix);
              # print STDERR "Host Line $hostline | $postfix | $hostip\n";
              push @nmapout, $hostline;
$header .= "and ".localtime(time())."\n";

if ($ipall)
{    # Some addresses seen
  $header .= "$ipall addressses pinged:- Up: $ipup, Down: $ipdown\n";
  $header .= "No addresses scanned. NMAP in path?\n";

# Preserve an archive Version
my ($sec, $min, $hr, $day, $mon, $yr, $wday, $yday, $isdst) = localtime(time());
$yr = $yr + 1900;
$mon = $mon + 1;
my $prefix = sprintf "%04d-%02d-%02d.", $yr, $mon, $day ;
my $afn="$opath$prefix$ofn";
my $hfn="$opath$ofn";

#Don't overwrite existing hosts file until we have finished scanning.
open (AHOSTS, ">$afn") or die "could not open $afn $!";
open (HOSTS, ">$hfn") or die "could not open $hfn $!";
print AHOSTS $header; print HOSTS $header;
foreach my $hostline (@nmapout)
  print HOSTS "$hostline\n";print AHOSTS "$hostline\n";
close HOSTS; close AHOSTS;

sub nbtstat
  my ($hostip) = @_;
  my $cmd = "nbtstat -a $hostip |";
  my %survey; my $ret;
  my $domain; my $server;

  # print STDERR "survey $cmd\n";
  open (NBTSTAT, $cmd) or die "can't run $cmd $!";
  while ()
      # print STDERR;
      # The meat of the NBTNAME command is in this format: name  type
      if (/^\s+(\S+)\s*<([0-9A-F]{2})>\s+(GROUP|UNIQUE)/i )
          my $nbtname = $1;
          my $nbtclass = $2;
          my $nbttype = $3;
          if ('00' eq $nbtclass)
              $domain = $nbtname if ('GROUP' eq $nbttype);
              $server = $nbtname if (('UNIQUE' eq $nbttype) && ($nbtname !~ /(\~)|(MSBROWSE)/));
          my $desc = ('GROUP' eq $nbttype)? $group{hex($nbtclass)} : $unique{hex($nbtclass)};
          $desc = "$nbtclass $nbttype Unknown" unless $desc;
          # print STDERR "$nbtname $nbtclass $nbttype $desc \n";
          push (@{$survey{$nbtname}}, $desc);
  close NBTSTAT;
  # We should have a good domain name and a good server if we have anything
  if (%survey)
      $ret = ($domain and $server) ?  "$domain\\$server" : '??';
  foreach my $nbtname (keys %survey)
      $ret .= " $nbtname: ("  . join (', ', @{$survey{$nbtname}} ). ")" unless ($nbtname =~ /(\~)|(MSBROWSE)/) ;
  return $ret;
# End of nmap.pl



Here's the Interpol (rare to see a .int domain) release on operation Vico. That's impressive work by the image experts, but I think the credit lies with the investigator who had the imagination to see that information was still there and the thing was worth trying. That's the leap I would have failed to take, and it's the difference between a proper investigator and the guy who looks at proxy logs.

After red-eye reduction, obscuring faces is probably the second most popular use for home image processing, the home porners generally botch it, and I've often wondered why packages don't include a better tool. Perhaps they can't find a suitably euphemistic name. Anyway, I suppose we'll now see a slew of unswirl tools.


The Approver as a Conceptual Bottleneck

I'm looking at a list of domains groups which control access to removable devices and media through Pointsec Protector (which used to be Reflex Magnetics Disknet Pro). We've had groups for various types of devices and now I'm trying to simplify -- to operate a much cruder level of control.

I'd prefer to leave it as it is, but the membership of the current groups is a mess. The technology is fine, but the control environment stinks. At present we allow or deny access to the groups based on a managers approval: "he has a business need to use a USB key" -- and that makes a good deal of sense. Who else can make that choice?

Who else indeed? Because the managers aren't technical -- so they don't understand what they're approving -- and they don't see any downside from insecure access. Essentially every request gets approved. And in six months time when the the lists have to be recertified, it's probably a different manager, or the original justification is forgotten, and it's easier just to agree. We've got adequate technology, and a process that the auditors think is just fine, and there's no real control at all.

Of course, this isn't just a problem for USB devices. It very easy to fail at this last hurdle by asking approvers to use a discretion that they just can't understand.

I've thought about making these accesses part of the permissions attached to the job description global groups. But that doesn't reduce the problem unless IT security can engage with the role definition approvers, and we don't.

So this is my plan: I'm going to name the groups after the risk, with alarming group names and descriptions:
Risk In -- "Trusted to read data from unknown sources"
Risk Out -- "Trusted to send corporate data to unknown destinations"
Device Risk -- "Trusted to attach untrusted and untested devices"

Let's see whether that gets the message across.


War Against the Aliens

In Arthur C. Clarke's Rendevous With Rama, the world of the 23rd century prepares for a visit by potentially hostile aliens. A minor character, a general, justifies military preparations by claiming that even though humans have complete dominion over a wasps nest, we still leave it alone if we possibly can. So even though the aliens may be vastly more powerful than we are, they would still care enough about nuclear missiles to leave us alone.

I suppose that's comforting. But it's not very comforting. The wasps nest I destroyed on Sunday afternoon had little idea who I was, and no idea why I was attacking. Alas! they didn't know I was afraid of their stings and I would have left them alone if only they weren't so dangerous. Even worse, the means chosen by the superior alien -- me -- was an organophosphorus agent: nerve gas. We might be better off without our stings.


Absolutely the Last Apple Entry this Year

It's been an astonishing year for fruit, but there's a price to pay. In ordinarily heavy years, plum tree branches can easily break with the weight of fruit. This year has had so much water that the damsons were the size of plums and edible straight off the tree while the table plums have needed props, to hold up the masses of disappointing bland fruit. And while the flavours been fine, we've had apple branches broken to create more challenges for the winter pruner. I drove past this old orchard today and saw trees pulled over or split in two -- it'll take more than pruning to fix that.


Proxy Access for Services

Of course you want to use a web proxy, but some of your services need web access. Proxy settings are per-user, and if you run services as specific users you can log on and set them. But for the built-in anonymous accounts SYSTEM, SERVICE, how can you tell them where to find the proxies?

The obvious need for this is to get Windows Update working behind a proxy server. It's needed even if you are using the web interface, because WU still depends on the BITS service.

Well there are a number of ways. But what's easy is proxycfg, a command-line program that will create the appropriate entries in

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\WinHttpSettings

The program is in the XP build, but it runs fine on W2K -- just copy it over. Running it with the -u option will copy the current user's settings in to the service default and you're done.

Of course, you still need to ensure that the requests will be permitted by the proxy: The service can't authenticate. On our Bluecoats, you make a combined destination object that precedes authentication and is accepted on the first rule.



Last weekend I picked a lot of apples: 50% Bramley, 30% James Grieve, 20% Spartan with oddments of John Downie crabs and Conference pear, and screwed it down to a bit over four gallons of juice. I'd say there was a ratio about three gallons of loose apples to one of juice, but that may be optimistic, They were all fresh off the tree and hard, so I don't think I mashed them as well as I should have. Anyway, after a rather slow start, it's fermenting nicely with whatever Wilkinson sell as wine yeast at this time of year.

It was extremely hard work. The book had been rather lyrical about the benefits of community endeavour with everybody helping to get the work done. Mrs U left me to it, driving off to visit her parents, and I pounded out the whole lot using the boss on a 17lb fence post digger and a six liter screw press myself.

Since I set that lot going, I've learnt that 80% cookers is a bad thing (too acid), that using fresh apples reduces the juice yield (too hard, and too tart), and basically I've done it all wrong. So today I filled the mower trailer with 60% eaters and the balance mostly Bramleys and I've hidden it in the shed. In a fortnight's time I'll see whether they've softened up, and perhaps make myself some less acid cider to blend. For certain the Spartans had the dullest juice so I'm afraid the cider will be bland, but we'll have to see how that goes.


Idle Sods

I've just been through my spam, and I'm disgusted. Where are all the Northern Rock "After the difficulties on our website, please re-enter your details to restore your access..." or "The bank has been nationalised. Please provide details to validate access to your deposit...." ?

Don't these people read the news?


I know a secret

And it's a surprise: the best juice comes from crab apples.

Admittedly they were ripe red John Downie, but straight off the tree they were still a lot more like hard red berries than proper apples, and they were the devil to crush. I got three pints from a gallon of mush, and it was sweet and appley with a lot of the puckering richness which I think is malic acid. Drinkable - delicious - running off the press.



Anyway, yes Holiday time in the very wonderful Isle of Wight. If you've got odd ASD children, you probably should be booking about now for one of next years Freedom Family week at East Dene. Why? a) Ventnor is a smashing little seaside resort. If you like walks, there are lovely walks there and back, or to Shanklin. b) The IoW railway will engage any train fiend, especially if you go all the way to the end of the pier, and it connects with steam trains if that's your bag. c) If you prefer to do nothing, the outdoor pool is heated, attended and open for hours a day. Most ASD kiddywinks and their siblings will play happily and tiringly in the pool for hours, and if they don't want that, there are activities most days. d) The air and views are conducive to a feeling of irrepressible well-being. e) It's catered. If you've been driven to self catering just to avoid the odd looks, it's amazingly wonderful not to have to hit the supermarket, look for pepper or whatever.

But none of that matters, because the real colossal advantage is is that however weird, badly behaved or just plain crazy your kiddies are, other children are crazier. Howls like a gibbon in the swimming pool? No problem. Unreliable judgement on wearing trousers? Don't we all. Turds on the staircarpet? Got to do it somewhere. True for all the other guests, true for staff. Amazingly relaxing, even if you're sleeping in a bunk and eating canteen food.

As a bonus you get to meet all the other odd children. Other people's kiddies are always more fun (because you get to hand them back) but this year I had the odd sensation that I was meeting children who were amazing. That's not a conventional wishy-washy feelgood disabled rights amazing, but absolutely fuck-off precocity and ability. Some were diagnosed, and some were slightly dodgy "we think he's all right" siblings. Amazing. I wish I could publish a list of names to watch out for because some of those kiddies are going far.......


Physical Security

I would have said there was nowhere in the UK, certainly in England, where you could run rocket engines for an orbital lifter without it being obvious to everyone around. It's all too small, and rockets are so very, very obvious.

Sucks to me then, because from the late 50's up until 1972, Saunders-Roe in Cowes managed strict secrecy while test firing assembled Black Knight and Black Arrow rockets right next to a tourist attraction on the Isle of Wight! Tucked away in a fold of Tennyson Down above the Needles Battery was a complete static test rig, with exhaust and cooling steam directed out to sea high above the cliffs. Less than a mile from the archetypical 50's tourist resort of Alum Bay, they kept their secret with nothing more than a wire fence, MoD police and a slightly deceptive line of sight.

Actually, there's one other thing you can only appreciate if you visit the site. The fantastic wind may not be louder than a rocket engine, but it would disperse it utterly.

This is all very fine, and the exhibition in the chalk bunkers of the new battery is well worth a look. But you have to be a real nerd to know that in Moonraker -- published in 1955 -- Ian Fleming had Hugo Drax, his nazi revanchiste, building and launching the rockets to destroy London from silos in the chalk cliffs between Dover and Folkstone. Fleming's intelligence contacts were the best: he must have known. Did the S-R security officer have kittens? Were there hard words exchanged? Was James Bond, of all people, responsible for a breach in national security?


Don't fear the Domain

This month has been packed with Windows servers not wanting to go in the Windows domain. Telephony servers, firewall management. And every time, the reason given is: it's more secure.

This reason is bollocks.

I can see the psychological justification: it feels like you are mixing your security sensitive servers with the common run. There is a sensation of "taint". But every time, it comes down to this: Domain membership lets domain admins do what they want with it.

The simple answer to this is that if you don't trust your domain admins you have your domain management wrong. And, more importantly, if you have more than one admin, the weakening of control caused by the shared user that will be used on the non-domain system substantially outweighs the possibility of a rogue assigning rights improperly. Let's be clear:

Not a Domain Member = Anonymous User IDs

Do you still want to be out of the domain. Really, what's possibly worse or less controlled than a shared user? Nothing!

The real agenda is designer/programmer laziness. If you don't plan to be in the domain, you can say that it doesn't matter if you run as an admin, so you don't have to worry about permissioning, you don't have to engage with Windows management and the whole thing becomes very much more like DOS. Which is of course what all programmers want.

There are still reasons to leave a server out of your production domain.

  • Because it is especially exposed to compromise. Servers in the DMZ might fall into this category. This is why we put application proxies of various sorts, in the DMZ, in front of domain member servers which are inside the firewall.
  • In theory, because the hardening requirements are incompatible with domain management. But if so, why are you running Windows?
  • Because, by design, this is not an area for your administrator team. The only case I've ever seen is retention of administrator access logs, where admin access would rather negate the point.
I reckon that's the lot.


The Emir

I shouldn't really comment on terrorism, or trials -- GNUWin32 is more my schtick. But I couldn't help noticing that all the reports of the second July bombers trial called Muktar Ibrahim the "emir" of the plot, and helpfully translated that word as "ringleader" or "kingpin".

I just wonder how the Foreign Office would take it if the BBC started writing about the Ringleader of Kuwait...


More GNUWin32

Just a quicky. If you need to dump a raw disk on windows, you can do it with the GNUWin32 dd(1) program. But

dd if=d:
won't work. You need a little sprinkle of stardust with the device reference:
dd if=\\.\D:
seems to do the trick.



Light grey sky with a gentle mottle. At my feet, I can see green June grass, but looking across the meadow to the ragged black-green hedge, the colour is lost under the floating carpet of pure yellow buttercups and smoky lilac ryegrass tassels.


In the Raw

Just as a glimpse of on-the-fly development to satisfy investigation needs, here's a hack using James Macfarlane's Windows registry parser to get a timeline of registry key timestamps.

This is a source code module -- no DLLs -- and so even though I've never been able to get ActiveState PPM to install CPAN modules, it's easy to set up. Just download, open the package and drag the components into the corresponding directory locations under C:\perl. Why not use TieRegistry or something? Because we need this to work on "dead" files and the Windows API won't do that. The extra benefit is that this will run on Linux.

Only remaining frustration: there doesn't seem to be a timestamp on values as well.

use strict;
use warnings;
use Parse::Win32Registry qw( :REG_ );
my $time_fmt = '%04d-%02d-%02d %02d:%02d:%02d';

my $usage="$0: hive_file_name\n";
my $fn=shift or die $usage;

my $registry = Parse::Win32Registry->new($fn);
my $root_key = $registry->get_root_key;

my %keytimes=(); 

sub keyinfo
    my $key = shift or die "no key to recurse";
    my $nm = shift or die "no name";
    my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=gmtime($key->get_timestamp);
    my $ts = sprintf($time_fmt,$year,$mon,$mday,$hour,$min,$sec);
    $keytimes{$ts." ".$nm}=[$nm,$ts];
    my @subkeys = $key->get_list_of_subkeys;
    foreach my $subkey (@subkeys) {
        keyinfo ($subkey, $nm."\\".$subkey->get_name);
# Main execution starts here
foreach my $keytime (sort keys %keytimes) {
    print "$keytime\n";

Dumphive and the unicode registry strings

The handy dumphive utility will list out registry and SAM files, but a lot of the content is left as unicode strings represented as octet sequences like this:

Well, you can pick your way through that with an ASCII table, but here's a bone-headed script to get the gist out.
use strict;
use warnings;
my $av=join(',' , @ARGV) ;
foreach my $c (split(/,+/,$av)){
    if (my $a=oct("0x$c")) {
        printf "%c", $a;
It would be cooler to read the blocks directly -- backslashes and all. Maybe next time. Anyway, all you have to do is figure out what


GnuWin32 is the Shortcut for the Old and Feeble

I wrote about getting round the simple LUA bug in Steam. Essentially, the installer runs as an admin, which is fine, and it permits the entire installation directory to the admins only, which is not fine, because to use the app, you need write acces to at least some of the files. To get it working, and because the only documentation suggests that you have to be an admin to run steam, the simple route is to set permissions on that directory to Users/Full.

That's a bit of a challenge in XP on an isolated workstation, because the security tab is hidden, and on XP home, at least, it's hard to get it back. Last time, I bodged it with SubInACL. A bit like writing a program in COBOL to change the name of a file.

What I wanted to do was use chmod -- the Unix command. That's because I'm a crusty old fart, and it's hard for me to imagine anything easier than writing chmod -R a+rw "C:/program files/steam/" That may look involved, but the Windows command line equivalent, cacls, is way tougher and you have to use a different program to make it recurse. That's why I ended up with SubInACL.

I'm not the only person to prefer to work this way, but be stuck using Windows. (Because I am, OK?) A lot of people turn to CygWin -- a complete *nix environment hosted on Windows. That's good -- you get shells, utilities, compilers, familiar filing system, the lot, but the very compatibility makes it alien within Windows, and it's really too much of a commitment for me.

So instead, I move further back along the compatibility spectrum, and get to GnuWin32, and that makes me happy. Essentially I can download the stuff I want: grep, less, the core command line tools like ls and chmod, and OpenSSH without making a big production out of pretending to be on Unix. The working ports come as nice friendly installers and the only manual step is to set your path. Because it's not Cygwin, there's no issue using these tools alongside Activestate Perl, or Windows scripting. And the license is impeccable, of course.

Perfect? Almost. Some problems just can't be mentioned ("where's the GNU vi? Tee hee!") and some systems would suit me but aren't there. (I know RCS is obselete, but I don't want to learn SVN.) But GnuWin32 is part of the toolkit.


Quickest Compromise

Browsing round Ikea today I saw sales workstations left logged on to a Windows console, and that set me thinking. Our AUP requires users to lock their workstations on leaving them because the default screensaver lock of fifteen minutes is easily long enough for a malicious passer by to compromise the whole network, and I think that's fair enough. But I wouldn't have fancied standing in front of one of those screens trying to hack Ikea for more than about ten seconds. "Hey you..." So what's the quickest possible way to carry out an opportunistic compromise?

  1. It's a real console -- a PC screen keyboard and mouse.
  2. The logged on user is not an admin or a power user.
  3. You can reboot (but not change a password), but the only boot device is the HD. USB, floppy etc. are all closed.
  4. Internet access is through a proxy server running a business-access-focussed site category policy
Extra credit for universal applicability, and evading basic security precautions:
  • ICAP server running signature checks on downloads
  • No access to root of C:\ or anything other than the local profile
  • Mo command line, regedit, ....
  • Minimal profile in the event and proxy logs
  • Hacked user can return to the console and notice nothing

I suppose the key points here are the exploit itself and the phone-home to control it. My mind is running to a binary exploit file, customised enough to pass signature checks, uploaded somewhere innocuous, and renamed after download to the desktop. The phone home is tougher.


Lunar Velocity

On Saturday evening there was a pretty but not unusual conjunction of Venus and the moon in the remains of the sunset. Venus made the apex of an equilateral triangle with the horns of the quarter moon, about 3 lunar widths east. Looking at the same time on Sunday, the moon had moved about a full hands span at arms length east in the 24 hours. I had thought it was faster.


Five nines

About four years ago, we were having trouble with the Group mail gateways, and I set up a half-hourly email to the helpdesk and some other support people to allow them to ensure that mail was being received.

I needed a platform that would be a lot more reliable that the Group gateways I was testing. So I put it on a box built from consumer-grade parts and a free operating system, with a power supply extended out of the house into a fifty-year old fuse box (real fuses) in a rat-infested shed which bakes in the summer, and literally freezes in winter. As you would expect, it's run reliably ever since, popping out the emails every half hour on the half hour.

(Perhaps there are some machine room management lessons here for us. But I hope not.)

Well, that issue is over now, and it was the last application on that machine, so I've shut it down to make room for the hydroponic cannabis farm which is the current fashion in rural enterprise.


Personal Service from Dawn's Rosy Fingers

Luscious pink sunrise this morning faded abruptly at 04:10 (GMT, natch). It felt as if it had been laid on for my benefit and switched off when I'd enjoyed it. Solipsism rocks.


We'd come to the view that the more mad son had insuperable difficulty with arithmetic. We tried counting straws, counting up, writing dots, but the idea of adding just seemed to pass him by.

But lately he's been bringing home money work sheets. Ask him for the total price of a watch at 8p and a stick of rock at 4p (really) and he'll tell you. (Actually he got that one wrong, but normally he just stares a little up and to his left and pops out the answer.)

We should have known there'd be no fundamental problem. This is the boy who, still completely mute and detached, and still in nappies aged two, startled us late one night by ordering his magnetic numbers on the fridge door. I expect he just needed the money to give it some flavour.


Harvest Moon In May

The full moon rose at 21:20 or so last night, and it was the colour of the setting sun.


Barefoot PKI 2: X.509 PKI

This post is part of a series introduced here.

Certificate PKI. For Simpletons.

In the previous post we saw how successful use of public key encryption (PKE) replaces one difficulty with another. We don't have to worry about sharing secret keys, but we do have to get trustworthy copies correspondents public keys. The solution to the problem — a trustworthy means of distributing keys — is called a Public Key Infrastructure. The X.509 PKI uses the certificates mentioned in the previous post: X.509 is the standard that defines the format and the meaning.

The certificate is the instrument that allows trust. Looking more formally:

  1. A certificate is a structured text document which asserts — certifies — that a particular name will use a particular public key for a particular purpose over a particular period.

If you trust the assertion in the certificate , and trust the entity named to manage their private keys securely, you can make the public key magic work for you — encrypt, decrypt or check a signature and all the rest. Unfortunately, by itself, the plain certificate is worthless: anyone could draft such a document. I might generate a key pair; write myself a certificate that said that the public key belonged to Citibank; and start signing banker's drafts! So we need another stage:

  1. Certificates are trusted if they are signed by a trusted certification authority (CA). Trust is a belief that the CA a) will follow a defined policy to ensure that it only signs "true" certificates, and b) keep its private key a secret so that no-one else can sign certificates that will validate with the CAs own public key.

Signed here means signed in the PKE sense. The signed document is a) the plain text document, and b) an encrypted hash of the document. If you know the CA's public key, you can decrypt the signature: if it comes out the same as the hash of the plain text, then the encryption must have been done using the CA's private key. If you trust the CA to keep their private key secret you can be sure that the document text offered to you is the same as that signed by the CA. If you trust the CA to only sign true certificates, you can be sure you have the public key you want to use.

(Diversion no. 1: You can see that this works off-line. A lot of the weirdness and toughness in X.509 PKI comes from the requirement for off-line working. It's a child of the eighties and it shows.)

(Diversion no. 2: Discussions of PKI tend to ignore the really important points like the diligence and process at the CA, and the ability of parties to look after their private keys. Consider that the most common use by far of certificates is to certify the identity of a public web server, and consider that that server probably has to be able to start-up, unattended, on an inaccessible hosting site and you can see that privacy of the private key is a bit of an issue.)

So: how do you know the CA's public key? You have to get it some way you can accept. CA keys arrive as so-called self-signed certificates: you can't check them, you just have to take care to get a true one. Browsers come with a long list of CA certificates pre-installed, Windows has a certificate store interface and tools to add CA and other certificates to it.

(Diversion no. 3: Check out the list of CA's your browser has decided that you need to trust. Then research Go Daddy's signing policy. That's a lot of why I think PKI doesn't work — you can't actually trust them to the level you want. Remember, you have no legal agreement with any of these CAs: You won't be able to sue e.g. Belgacom (who?) if you get robbed by a merchant abusing one of their certificates.)

It's a good deal more complicated than this. Certificates have limited validity and limited capability. Very often, intermediate CAs — CAs whose public key is signed by another, "higher" CA — do the actual signing, and you have to trust them too.

X.509 Certificates for Simpletons

So we can use certificates to build a PKI. Obviously these certificates need to be in a standard format and the universal format is X.509, an ITU standard which attempts to define a PKI. X.509 is old — pre-Internet — and as with so many international standards, it's oriented to a world which never happened. For our purposes, X.509 defines data formats for key parts of the certification process, most importantly the certificate itself. But we have other standards as well, notably Public Key Certificate Standards (PKCS) from RSA, which define the format of .Pnn files like the .p12 file which is crucial to Windows.

What is a certificate on the disk? It's a data-structure, unambiguously encoding all the values in such a robust way that the same encryption processes will yield the same result. The requirement for repeatable, checkable, bit-for-bit identicality, despite byte-endian reversals, network transmission, packing and unpacking, and fixed line lengths means that plain text won't do.

X.509 defines the structures using ASN.1. ASN.1 is a data-structure definition language with primitives like octet, integer, sequence etc. It doesn't define formats, but it does define content and order. For example, a simple certificate (not X.509) might be defined as a sequence consisting of a serial number which is an integer, a common name which is a character string, a public key which is .... That ties the content down very precisely, but it doesn't for example say whether the serial number is going to be a 128-bit GUID or a 32-bit long int. So X.509 defines the ASN.1 code for a number of data structures in the certificate process, including the certificate itself.

So those are the formats. Actually representing the content of a data structure is a job for an encoding method. There are many defined encodings for ASN.1, but X.509 uses just one, the DER which creates a binary octet stream. So an actual certificate, or a request, or whatever is a DER string in a file. In Windows, this carries the .CER extension. (Watch out: there is a CER encoding method, and CER is a superset of DER; nonetheless, .CER files contain .DER sequences.)

The DER format with the .CER extension is usual in Windows, but Unix goes one stage further. An early and now obselete use for X.509-style certificates was called Privacy Enhanced Mail (PEM), and it had to pass certificates over the old seven-bit, fixed-line-length mailers common at the time. The solution was the old favourite (really old — it goes back to uucp) base64 encoding, which encodes octet data in a set of 64 7-bit characters, with fixed line length. PEM is gone now, but .PEM files are still widely used — they're the OpenSSH default, because text is always convenient, and you can mix text and data without confusion. A .PEM file is a base64 representation of a DER octet sequence.

So that's the format, and it's pretty obvious that the public key, the name and the CA signature are going to be included in the certificate details. But there's more: the applicability period and the usage types.

The period just means something like : "I will use this key throughout 2006". NB that the validity of the certificate is not affected by the expiry of the applicability period. The key and the certificate may still be required long after its expiry, or the expiry of the key used to sign it: it may be needed to check a signature made in that year, or decrypt a message sent then. The validity refers to intended use rather than actual integrity of the certificate.

And finally, the usage types limit what the certificate can be used for. It may be an encryption key. It may be a signing key. It may authenticate the name of the entity for SSL challenge-response. These purposes are divided up by X.509 into capabilities, V3 capabilities and extended capabilities, with a detailed, extensible underlying structure (called OIDs ). However for all practical purposes they can be regarded as a set of check marks saying what the key can do. One capability to watch out for is "CA": the capability to sign certificates which will inherit the trust of the root certificate.

Other X.509 and PKI Data

The certificate is just one item. To ensure that certificates do what we want, other files and formats are defined by the basic workflow around certificate issue. The basic sequence of operations is linear:

  • It starts with generation of a key pair. This is a standard cryptographic function — nothing to do with X.509 or the the CA — the user should do it locally to reduce the risk of exposing the private key. Not all applications can generate a key pair and so it's a standard CA function to do so, with the private key being returned (password encrypted) alongside the certificate in a PKCS12 (.P12) file.
  • The application has to give something to the CA to sign. That is the job of the certificate request. PKI users which can generate a key can also generate a certificate request, otherwise the CA has to do it. The request is defined in X.509 — a DER-encoded ASN.1 data structure which contains all the user-specific content for the certificate, including the name, requested validity period, the "capabilities" requested and the public key to be used. It's a bit like an unsigned certificate. It's not confidential because it doesn't contain the private key, but CRs can be passworded to stop casual snooping. OpenSSL can generate CRs from a public key, by default in PEM format. Some public CAs, outside our current scope insist on DER requests.
  • When a CA sees a request, it has to decide whether to sign it. Some tests are simple: few CAs will routinely sign a request that requests CA capability. Others are more complex: is the name requested legitimate? and does the period exceed our policy? Where theses choices are mechanical they are encoded into the setup of the CA software: The OpenSSL CA functions get this policy from the openssl.conf file.
  • Signing produces a certificate. For some apps, that's sufficient. Others may just need the format translated (from PEM to DER, say). But apps that didn't generate their own private key will need the key pair back too, and, for Windows apps, this is the job of the .P12 file. The .P12 file is a DER stream, not defined by X.509 which contains a certificate and the corresponding (encrypted) private key. This file will install into the Windows certificate store with a double click.

Simple And that is really all there is to it. I've left out the the Certificate Revocation mechanism. All I'm going to say about that is that if you have a system which depends on X.509 certificate revocation to communicate withdrawal or ceasing of access, you have already failed.


Computer Investigation is not about Images of Children. Mostly.

This is just a rant really. I can't justify what I'm going to say, but it's been growing on me for a long time, and some publicity material at Infosec tipped me over. (You'll have to forgive me some circumlocutions, as I don't want to skew Adsense towards the P-word.)

As far as I can see, the whole field of computer forensics is obsessed with sexual images of children.

Is that fair? The material exists, and is just as vile as it seems, or worse. It fuels hideous organised violence and abuse. And the investigators are, after all, sincerely trying to shut down the obnoxious trade. So what can I object to?

I object to the way the topic is used.

  • Used to stifle argument: "We must accept any invasion of privacy, because otherwise an abuser might not be punished (which is definitely not a matter of police convenience -- oh no.)"
  • Used to garner prestige: "My work helps to protect society from this filth (and is definitely not one of the duller branches of system engineering or forensic accountancy.)"
  • Used casually -- it always seems to be the first example picked.
I'm not an experienced investigator. But I've done a few, and everything I've done has been related to the text, dates or addresses of documents or email, or activity from attack tools. I've never so much as once had call to open a JPEG (GIFs as web design elements are another matter...)

Bridget Jones called it mentionitis: when fascinating topics — even un-admitted ones — keep cropping up. That was fiction but the effect is real, and I think it's what's happening here. So this is the challenge: if you are writing about computer forensics, lay off that area.

This stuff exists. It's a danger to my children. We're all against it, and some people have to investigate it. But there's no need to let it take over our un-thought thoughts. It's never necessary. If you want to talk about file types and signatures, take examples from Excel accounts disguised as DLLs. If you want to talk about image content, talk about copyright violation, or even voyeurs. If you want to talk about the rewards of the job, talk about the email bully forced to apologise. You'll feel better for it.

The Show

Infosec at Olympia this week and a fine show. The firms are still sorting out who gets a separate stand after all the mergers over the year.

The best novelty for me was Lockdown Networks with a box that watches for "port-up" events on your switches and makes VLAN choices based on what's plugged in. Printer? Put it on the printer LAN. Computer, no agent? Put it on the Contractor Convenience LAN. Looks like a real labour saver.

Still a very fragmented world, though. The nearest approach to a theme is that all the vulnerability and event scanners are putting workflow/annotation/presentation tools into their products. It's only after you buy these things that you discover that raw automatic events are unusable, and this is the vendors' first cut at making them useful.


More Colours

In the pre-dawn twilight, looking south west across saturated acid yellow of fresh flowering mustard rape into the darkest steely clouds of an approaching storm.

First rain all month.


Blind for Forty Years

I never noticed this before: The flowers on an oak tree are pretty bundles of loose catkins about an inch long. I checked with Mrs. U: she hadn't noticed either. But all the oaks we've checked are covered with them.


Barefoot PKI 1: Asymmetric Encryption

This post is the first is a series. I want to create a "barefoot PKI" to record my own experience and share the lessons. I found I needed to know more about PKI when I saw a sudden flurry of certificate requirements. Outlook users wanting to engage in S/MIME email. The MS Ops Manager implementation authenticating non-domain machines with certificates. Sensitive machines needing certificates to communicate over IPSEC. HTTPS-delivered applications needing server certificates.....

In the past I'd said "We don't do certificates." A good response, if you're a simpleton, because this is tricky stuff -- not conceptually difficult, but hard to keep straight and get all the bits lined up. But it's not good enough any more. So this is the Security Stories guide to PKI, for simpletons. By an authentic, accredited, self-taught simpleton.

Even for simpletons though, this is bigger than a single post. So I'm going to break it up.

  1. Absolute minimum concepts for working with asymmetric encryption (Public/Private Key encryption), and some links to get more. (This post.)
  2. The X.509 Public Key infrastructure
  3. Simple PKI operations.
  4. Tools and techniques and implementation with OpenSSL

I'm going to use OpenSSL for the practical stuff. This is not really a political statement: because a) It's what I actually used when I realised I was in trouble, b) it exposes a little more of the gory details, particularly in terms of getting things working with Microsoft systems, and c) what swung it for me was that it's an easy install -- I didn't feel that I was making ill-informed choices that would bind the firm into the future. I installed on Linux, but I'll be talking in terms of a Windows setup.

Asymmetric Encryption for Simpletons

Encryption used to be easy, and symmetric. Alice encrypted her plaintext message with a secret key (which is really just a string of bits) using a (hopefully) robust encryption algorithm. She sent the resulting unintelligible ciphertext to Bob. Bob knows the secret and can run the encryption in reverse to yield the plain text. This is the way it's always been -- the history of cryptography is mostly the history of better and clearer understanding of symmetric encryption.

To benefit from symmetric encryption Alice and Bob need to

  1. Agree the encryption to be used. That's easy -- it's not a secret. Modern encryption doesn't rely on obscurity of the algorithm.
  2. Keep the secret key secret, to prevent anyone else reading the message
  3. But nonetheless share it between the two of them. That's difficult -- they need to have a means of communication which is secure so that the key won't leak. The historical solution has been a key of the day or the hour, in a code book. You don't need me to tell you how horrible that is, especially in a situation where Alice and Bob will never meet, or Alice is dealing with multiple mutually untrusting Bobs.

Public Key — asymmetric — encryption seems to have arrived in a bit of a rush between 1975 and 1980. There's still an encryption algorithm which uses a key. But there's no reverse process for decryption -- instead we use a key pair. The pair are chosen to be related by a property which at first sight seems magical: If you encrypt with the first key to get a ciphertext, you must encrypt again, using the same encryption algorithm with the second key, to get back to the original plaintext. And the same is true if you use the keys in the other order (though the intervening ciphertext would be different). It is spooky, but it does work and the smart types who fret about this sort of thing have not been able to find any conceptual weaknesses.

This magic offers a solution to the key sharing problem. Alice and Bob both create independent — different — key pairs. Each designates one of their keys as "public" and one as "private". The private key is kept secret — it never has to be shared with anyone. And the public key is actually published, to the whole world if necessary. To send a message to Bob, Alice encrypts it with his public key, knowing that the only person who can read it will be Bob, because the only way to decrypt needs the private key which only Bob knows.

It also offers some other wins:

  • Alice can sign a file by encrypting it with her private key. Anyone can check that Alice's private key was used, by decrypting it with her public key and checking that it comes out right. Since Alice's private key must have been used, only Alice can have signed it.
  • Once it's encrypted it can't be altered, or it won't decrypt right, so its authenticity is guaranteed — the text decrypted is definitely the text that was encrypted.

(Diversion: PK algorithms are relatively slow and require long keys of one or two thousand bits. Instead of using them directly:

  • For encryption, the only message encrypted in the PK system is a randomly chosen key for the ordinary symmetric encryption which will protect the rest of the message — typically just 128 or 256 bits to protect a message that that may be megabytes long. So symmetric encryption is as important as it ever was.
  • To avoid encrypting the entire document, a hash algorithm is used. A hash is a fixed-length digest of a message. It can't be used to recreate the message, but a change to the message is supposed to be very unlikely to produce the same hash. By convention therefore, Alice signs a hash. This is a little worrying as it appears the this promise is not entirely true in the case of the MD5 hash algorithm which is very widely used.

But the logic works much the same if you think of the PK crypto being used directly. The hash or the key exchange is a convenience only.)

To be secure, the public key must give no clue to the private key. As an example (there are other techniques) RSA encryption uses a key pair which are the (only) two prime factors of a very large number. Because large numbers are hard to factorise, the public key gives no hint of the private.

There are still a couple of problems: The first is practical: private keys have to be kept secret, or all the guarantees fail. The second feels a bit like we've gone round in a circle: we have to have a trustworthy means of finding out the public keys that their counter-parties will be using. It has to be trustworthy because a malicious person can read or spoof traffic if they can deceive either end about the right public key to use. The reason we haven't returned to the secret key distribution problem is simply that it doesn't have to be secret — just trusted.

Mechanisms set up to distribute and validate public keys are called Public Key Infrastructure (PKI). Certificates are the tool used to make it trustworthy. And X.509 is the standard for certificate formats. And that is quite enough for today.


Triple A

We have Authentication, Authorisation and Accounting. And the least of these is Accounting, because no-one bothers about computer time these days. But its presence in the triad reminds us that username and password authentication dates back to a time when the only reason to log on was to select the account to be billed for your FORTRAN session on the teletype.

Using a password to prove identity is a later loading of this basic idea. Which is why it doesn't work.


Log Lust Blog

Long train ride today, for a futile meeting.
Looking out of the window, I see it's not just in the south east that there have been many trees felled all along the track to control leaf fall.
Left behind: piles of logs, entire tree trunks. It's obvious they'll just be left. And I am consumed by lust to possess them.



As it's the holidays, the kiddies would stay on the PCs all night. To get them into bed, stern measures are needed:

First you need to set the accounts they are using (you're not letting them be admins, are you?) to have fixed logon hours. You can't do this through the GUI on XP Home, so you need a batch file of commands like this one to set times when it's possible to log on. Call it accounts.cmd -- you'll need to re-run it when anything changes:

net user mmadson /times:sunday,08:00:-21:00;monday-saturday,09:00-21:00;saturday,08:00-21:00
The /passwordreq:no directive can be useful here too.

Unfortunately, Windows won't enforce that logoff. (A domain would, but Windows itself will not.) So the second step is to force it. There would be any number of ways to deal with this, but I chose the ugliest: run the the Sysinternals psshutdown command at bedtime. I chose to run it from a command file so that I could get a log. Put this text into enforcer.cmd, make the obvious modifications and set it up as a Windows scheduled task. (In the control panel, under Performance and Maintenance.)

@echo off
echo "-start-" >>d:\at\log.txt
date /t >>d:\at\log.txt
time /t >>d:\at\log.txt
d:\at\psshutdown -o -f  >>d:\at\log.txt 2>&1
echo "-end-" >>d:\at\log.txt
I set it to run twenty minutes past the last log on time. Hey presto! Instant rage from the younger generation.

The obvious improvement is to only log off console sessions which are members of the kiddiewinks group. It's really annoying when it logs ME off! I think I could script that up, but I'm too idle.


Why is X.509 so grim?

I've been intending to assemble some notes about the way I've been using an OpenSSL install to knock off some certification requirements. I was going to start with a round-up of the ways that X.509 was needlessly confusing, redundant and bizarre. And I was going to say that large-scale, public, multi-party PKIs are wrong-headed and dangerous.

There's still room for the OpenSSL cookbook -- I'll do that. For such a long-lived product, the documentation just doesn't say what a typical newbie user will want to know. And there's room for me to come clean (if no-one else will) and say that the worst initial obstacle was that I got confused with OpenSSH!

But the rest has been done a long time ago. I wish I'd found it earlier. It's sufficient to say:

  • X.509 PKI solves the wrong problem. It's not you. It really is too hard to get right.
  • The semantics of the trust and reliance which X.509 attempts to create between unrelated parties are much more tricky than they look, do not address vital issues like counterparties' management of private keys and do not correspond with the ordinary requirements of law and regulation
  • X.509 PKI only makes sense between parties who have a pre-existing legal structure (perhaps they're part of the same organisation), and have a means to deal with cancelling authorisation that does not depend on certificate revocation
Why? Witness Peter Gutman's PKI Introduction. And while you're at it, check out his other stuff too. I found the Encryption and Security Tutorial was particularly helpful.



The new URL makes much more sense. I doubt I've inconvenienced anyone, but if I have, I'm sorry, and thank you for finding your way here.


Obligatory Tribute to Homer Simpson

Just back from three days in a caravan on the Isle of Grain. Literally three days -- I slept at home, commuting with Comedy Dave and the dog, neither of whom were really happy with the caravan concept.

The spookily-named Allhallows Camp is great for bike-mad boys, even if they are a bit iffy about brakes. And the more mad son is very iffy on the brakes -- or at least that's a much more palatable theory than accepting that he's played too much "The Simpsons Hit and Run". Of course, when he runs into an occupied, parked van, and then sidesteps the inevitable argument with the Homer collision soundbite from the game: "Ow! My neck!" you have to wonder.


Desperate for a Wii

(This is my entrant for "most peurile reference to a Nintendo gaming console 2007".)

Now that the less mad son's eagerly desired birthday present has arrived from a reputable supplier (gamestation) I feel that it won't be tempting fate to describe what happens when you try and order from some other suppliers.

About ten days ago, Mrs U was desperately looking for a Wii. It launched months ago -- how could it possibly be in short supply now? The LMS was on a promise but there were none to be found with a fixed delivery date anywhere in the UK. Until she came across a site that magically was promising a five day delivery. Just time! So she shopped, waved her credit card, and waited.

No confirmation email: that's odd. Five days later, no Wii: that's a nightmare. Check the bank account: £2,500 debited by a restaurant in Surrey. Oooh.

Now I'm not naming the site because it's just possible that the cause of the trouble is actually this. But I don't think so.

The point to this sad story is that Mrs U is a competent shopper and competent security consumer. She declines to speak to the bank when they ring her up and ask her to confirm her identity. She knows what the padlock means. But as soon as she was a little bit needy, she was willing to deal with a site she'd never used before, without doing research that could have shown the slagging it got on Yahoo answers, she was willing to ignore the absence of a phone number, and she clicked straight through the warning from the self-signed certificate that was pointing to a "commerce" site hosted the Dear knows where. Education and common sense swept aside by need and "experience" of good shopping outcomes in the past.

It's worse for the restaurant: they've accepted a bad card without a PIN and that'll mean a monster charge back straight off their margin. Grief all round.

Education is supposed to be the key security tool, but it seems to me that the only education that works is to screw up.


Going to Work in the Dark Again

You don't have to work with audit logs to be a GMT bigot. But it helps.


Limited User? Limited programmer if you ask me.

Less mad son's birthday and the Wii hasn't turned up, so I had to fall back on an old promise to install Steam and pay for a copy of Garry's Mod. Whatever that is.

What it is, is an easy install, together with -- in Steam -- the crappiest LUA bug ever. Obviously it needs to be installed as an admin, and equally obviously, after a deplorable spyware incident, the less mad son is not an admin. So I installed it myself, tested, and then we flipped over to his account to run it there. Well, to cut a long story short, to run Steam as a non admin, all you have to do is make sure that BUILTIN\Users have read-write permission from the install directory (\Program Files\Steam) on down. That's a bit of a palaver on XP Home, as it's hard to get the security tab to show, and I ended up going nuclear with a copy of subinacl, but conceptually it's the simplest possible LUA bug -- the installer doesn't bother to set the right permissions.

I'm not a bigot. Steam runs on Linux as well, so I can see that creating local application settings might not be the right thing to do. But I don't think it was too much to ask the testers to check that files shared among users were permissioned to BUILTIN\Users. Not to BUILTIN\Administrators.

In my opinion, programmers who test code using administrator accounts should never be admins again.

Still, at least Steam is free. Matlab costs £2-12K depending on what you buy, and our unfortunate application packager is going to have to spend days figuring out what part of the machine registry it's writing user settings to before I will sign it off for use in the firm. Slimy negligent gouging incompetents.


Trees from Whips

The last thing I did before I was locked up was plant some fresh ash whips. I smeared off the lower buds, stuck them eight or ten inches in, wrapped rabbit guards round, and bundled in threes in the hope that one will grow. I've tried hazel in some hedges and they look like they're going to break out, so we'll see.

Hospital Protocols

I spent last week in hospital with an infected joint; I've had to find out about StickyKeys, and I'm using the mouse wrong-handed. I didn't feel ill, I just had to be around for regular surgery and IV penicillin, so there was a lot of time to kill with no desk, no computer, no Internet and one or two compromised hands (you can't read when your hands hurt and you haven't got a desk).

Better people than I am would have done something useful with all this time. I just wished it was finished. But I saw a lot of security protocols:

  • When you are prepped for a local anaesthetic, it's the same as for general: eight hours starvation. For why? So you can be conveniently be put right under when it all goes tits.
  • Every single person who planned to do anything substantial at all asked me whether I was allergic to anything. Every time. I was the second longest term resident on the ward at the end, and the nurse who'd infused the same prescription all week still asked the same question every time.
  • Everybody asks your name and date of birth, and then checks the band on your wrist. Every time.
I got pretty sick of this and I was brewing up some smart answers. Until the porters turned up to collect the appendectomy next to me. He was starving and ready to go. They asked his name. Wrong guy. I love security protocols.


Light Feet on the Drive

OK -- the scenario is that you really, really want to know what's on a Windows workstation hard drive -- you plan to look in the IE cache, system logs, registry, SAM, etc. You can't/won't be arsed to image it and work on the image and you are not going to take this rather urgent moment to learn about excellent Linux based tools. But you do want to take all reasonable precautions. (What's reasonable? I'm less sure than I was after reading this document. It's a normally reliable source, but the example scenario contains an eyepopping amount of work on a live system. Maybe evidence rules are different in the States. My approach is to kill the disk and only ever read from it.) Here's the plan.

  1. Prepare an investigation machine. You need a computer with Internet access where you can work privately. You also need a USB disk housing that will fit the disk in question. Maplin do an IDE/SATA for 3 1/2 inch disks, while 2 1/2 inch laptop disks still seem to be small format IDE and there are lots of housings for those. Since we really don't want to write to the evidence disk, run the Read Only registry file below, and test that you can't write to a scratch USB device. Load tweakui (Microsoft Powertoys) and make sure that you're not set to autoplay anywhere to reduce the risk of malwaring your investigation machine.
  2. Give the job a name. The Remedy number, "2007 02 Hotmail Complaint" -- whatever.
  3. Get a chain of custody log. The idea here is that you have a collection of evidence for the investigation, and as you collect each item, you sign it out and and back in when you return it. so that you can swear to where anything was at any future tribunal.
  4. Get a log book. Or open a file, or something, anything where you can write everything down. Computer records are good here as you can paste in log entries and images. Finish each day with next steps so you don't forget, then print the day's record, and sign and date each page. Enter it into your evidence store.
  5. Pull the power on the workstation. Record make model and serial number. Remove the disk, and record the make, model and serial. Put this diskless carcass into your evidence store with a label that says "2007 02 Hotmail Complaint Exhibit A". You shouldn't need to boot it, but you never know. Anyway it's evidence.
  6. The disk is Exhibit B. Log it, and sign it out to yourself. Mount it in the USB housing. Check that you've run readonly.reg on your investigation machine. Plug it in and make sure it comes up on you're investigation machine. Don't let it auto play.
  7. Where you go now is up to you. Check the tools below to look at Windows file contents, and there are others to look at file times.
Read Only.reg

Create a file called readonly.reg using notepad. Save it on your desktop. The file contains just these lines:

Windows Registry Editor Version 5.00

Double click on the file and confirm you do want to load the settings. Then test on a scratch USB stick -- you should see a "Write Protect" warning come up when you try and save something. To get back to read/write you need another file with that last dword set to 00000000.

Read Event Log Files

The log files you want will be in d:\windows\system32\config\ assuming d: is where your disk is. Sometimes you can load the .evt files from the subject disk into the log viewer. I find that it always says they're corrupt though.

So I use Activestate Perl, add the Parse::EventLog module and a few lines of code to list them out into an easy text format. Here's the code -- you'll want to tweak it.

use strict;
use Parse::EventLog;

my $elogfn = 'd:\\windows\\system32\\config\\SecEvent.Evt';
print "Loading Event log: $elogfn .." ;
my $elog = Parse::EventLog->new($elogfn);
print "..loaded\n";
my %c = $elog->getOldestEvent();
while (%c = $elog->getNextEvent())
  my $str;
  if ($c{Strings})
      $str = join('|', @{$c{Strings}}) ;
      $str =~ s/\t/\\t/g;
      $str =~ s/  / /g;
  my $evt = $c{EventID};
  my $time = localtime($c{TimeGenerated});

  my $ msg = "$time: $evt <$str>\n";
  print $msg unless grep({$_ == $evt} (560, 576, 515, 600));

The good bit here, is that this will work from a Linux machine just as well as Windows.

Read Registry and SAM files

The most amazing thing thing I've learnt recently is that the SAM is in the same format as a registry hive. This means you can use this tool to print out the system registry and the SAM (from d:\windows\system32\config\) as well as user registry from ntuser.dat in the appropriate profile.

You should also be able to use Parse::Win32Registry though I haven't done that. It would work from Linux, too. There's scope for a useful script here, as the SAM is in a desperately unhelpful format.


Investigate That!

When you have to investigate a PC, there's the ideal approach, and the actual approach.

The ideal approach calls in a firm of investigators -- I use Kroll Ontrack as the sucessors to Vogon. They send in an engineer to take forensically sound images, and retain them on their systems until they can schedule an investigation to answer some of the basic questions. Two weeks to get there, and then further rounds of questions and answers ending in a report. Meanwhile you have managers wanting answers.

So there's the actual, otherwise known as DIY. Everyone does this sometimes, so here's a few pointers to protect your arse.

1) Give Babylon Her Due.

If this is one of the cases where the police need to be called, then you must do that. You can't be ordered to conceal it by your boss -- your duty as a subject trumps your duty as an employee. Definitely talk it over with a sane advisor who's familiar with the situation, but if it's ugly then you have to give the cops the option. Don't go mental about this: for certain spyware breaches the Computer Misuse Act, but what are the chances of some random piece of spyware originating from someone subject to the Act?

2) Get it Cleared.

You need a pretty explicit memo from your source of arse covering (your boss, HR) saying that the answers are wanted tomorrow, there is definitely no intention to rely on your investigation in any sworn proceedings, and that your advice to go the ideal route is not wanted or not practical in this case.

3) Take Care Anyway.

When you're half way into a DIY investigation and you realise that you are going to have to complain about the behaviour of an employee, or call the police, you do not want a sinking feeling that you've trampled on the only copy of the evidence. See the next post has basic tips for getting the data you need without booting the evidence disk or writing to it.

4) Keep it Locked Up.

One of the best reasons for working on images is that the record keeping to prove evidence is easy: you can keep the original locked away for long periods. If you're actually working on it, you have to sign it in and out, secure it when you leave your desk.... No fun, and not impressive when you have to swear a long chain on ins and outs, but better than no records kept at all.


Busy Weekend

OK. I finished pollarding the old willows by the pond. The take from that is going to be a lot of crappy firewood and a lot of waste, unless I can make faggots. The sanest use for the land we have would be to grow enough willow or poplar to fire a woodchip boiler -- as we burn oil at the moment that's twelve or sixteen hundred savings from something that currently yields nothing.

The big winds last week blew out some of my dodgier hedgelaying, so I've put that back. And I've planted another twenty-five hazels on a rather tight spacing. When they're established I'm putting in ash behind them with a view to eventual firewood coppice.

And I put in seventy-five hornbeams for Mrs U's garden.

Just one magic point: if you've struggled as I have to put bare-root trees into heavy clay you need this spade or one like it. If you want to let the plants in down the back of the spade in the traditional way, and you're strong enough to open up the slits in the soil, the metal shaft means you can push as hard as you need without breaking the handle off, and if you do decide to dig a trench, it needn't be a wide one. You'll need metal re-inforced boots to use it though -- and be prepared to jump on it to get it in to clay.



Just to note that Mrs U. got her chickens at last -- on the same day that this hit the news. Every day, I expect to come home and find she's been tarred and feathered by the neighbours.


The .Net Developer's Guide to Windows Security

Just a quick note to big up Keith Roberts and his book "The .Net Developer's Guide to Windows Security". Don't be foxed by the ".Net" bit -- it just means "Modern Windows". The whole text is online but it's well worth buying the book simply because it's broken down into five and ten minute chunks, so that a couple of month's toilet visits will have you knowing more than you want about every major topic in Windows Security.

It's not a management or policy text and knowing all of it is not obligatory, but this book has helped me deal with issues that ended up on me because apparently I know this stuff. I don't -- I stole it from Keith. Just as examples, check out How to Develop Code (and do other stuff) as a non-Admin or How to Store Secrets on a Machine

Serious, practical stuff.