Apache2 Version Analysis: Ubuntu Packaging
During a recent attempt at answering the Honeynet Log Mysteries Challenge, I wrote a series of reasoned analyses for the supplied Honeynet logging data. Unfortunately, teaching workloads stopped me from submitting any realistic challenge answer.
Inspired by the idea of applying the Scientific Method to Digital Forensics (see Casey2009 and Carrier2006) and using data visualisation (see Conti2007 and Marty2008), I set about attempting to apply the same principles to analysing the Log Mysteries data sets.
In the blog post Apache2 Version Analysis: Data Visualisation, we estimated that Apache2 is at a revision < 596448 (ie. tag release is ≤ 2.2.6) and, under minimal additional assumptions, we also estimated that Apache2 was at a revision ≥ 420983 (ie. tag release is ≥ 2.2.3). Obviously, these revision and tag numbers are taken relative to the Apache2 subversion repository and not the Ubuntu package repository.
As Ubuntu packages (like Debian packages) essentially consist of the original (pristine!) upstream source code (eg. a tagged release straight from the Apache2 subversion repository) with a patch that is to be applied on installation, we clearly have some extra work to do here!
A visual inspection of the bootup messages in
dmesg uncovers the following type of specimen log entry:
[ 0.000000] Linux version 2.6.24-26-server (buildd@crested) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #1 SMP Tue Dec 1 18:26:43 UTC 2009 (Ubuntu 2.6.24-26.64-server)
Clearly, this boot message suggests that we have some form of Ubuntu server. Performing a Google (restricted to the Ubuntu package management website), allows one to associate:
- the term
4.2.4-1ubuntu3with the Ubuntu package
- and the term
2.6.24-26.64-serverwith the Ubuntu bug report #499312.
At this point, all we have essentially proved is an association between two sets of string based data!
Via a constraint based analysis, we can use Ubuntu's package management system to identify the set of releases to which each installed Ubuntu package belongs. An intersection of the well-defined constraint sets then formally identifies and confirms that Hardy is the Ubuntu release from which these packages are being downloaded and installed.
Using the shell code:
grep -i "setting up" sanitized_log/apt/term.log
| cut -d " " -f 3 -f 4 | tr -d "()"
grep -i " install " sanitized_log/dpkg.log | cut -d " " -f 4 -f 6
we can obtain a list of installed Debian packages and Ubuntu version numbers.
Using this data to screen scrape
launchpad.net, we can now map a Debian package name and Ubuntu package version to the corresponding Ubuntu release. In doing this, we are able to confirm that all our installed Ubuntu packages are being sourced from an Ubuntu Hardy (8.04) repository (this statement is justified as, when our function
ubuntu_releases is applied to each line from our install list, Hardy is the only common release that's present amongst the results - of which: we manually verify
libstdc++6-4.2-dev, as they all return empty results; ignore
lsb-build as it is nil; and ignore
linux-libc-dev as it times out).
Now we have identified the version of Ubuntu running on our server, we can now determine the versions of Apache2 belonging to the Hardy release. A previous blog post has constrained Apache2 to have a major version number in the range 2.2.3-2.2.6 (both Debian and Ubuntu packages incorporate these major version numbers into their versioning nomenclature). Looking at the Hardy
apache2 package, we have a list of all versions of Apache2 associated with the Hardy release. Cross correlating these two information sources allows us to refine our Apache2 version estimate (expressed in terms of Ubuntu versioning) to be one of:
- or 2.2.6-3ubuntu2
Future blog posts will focus on using data visualisation and statistical analysis techniques to further analyse the Honeynet logging data.