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.

Colours

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);
    $year+=1900;$mon++;
    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
keyinfo($root_key,'.');
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:

"\\DosDevices\\E:"=hex:5c,00,3f,00,3f,00,5c,00,53,00,54,00,4f,00,52,00,41,00,\
  47,00,45,00,23,00,52,00,65,00,6d,00,6f,00,76,00,61,00,62,00,6c,00,65,00,4d,\
  00,65,00,64,00,69,00,61,00,23,00,37,00,26,00,31,00,66,00,65,00,39,00,65,00,\
  35,00,63,00,34,00,26,00,30,00,26,00,52,00,4d,00,23,00,7b,00,35,00,33,00,66,\
  00,35,00,36,00,33,00,30,00,64,00,2d,00,62,00,36,00,62,00,66,00,2d,00,31,00,\
  31,00,64,00,30,00,2d,00,39,00,34,00,66,00,32,00,2d,00,30,00,30,00,61,00,30,\
  00,63,00,39,00,31,00,65,00,66,00,62,00,38,00,62,00,7d,00

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

\??\STORAGE#RemovableMedia#7&1fe9e5c4&0&RM#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}

means.

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.

Avarice

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:

2. 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.