Subgraph OS

Tags

censorship, Investigatory Powers, kernel, linux, Metaproxy, Operating System, os, security, Subgraph, surveillance, tor

As you probably know already, I’m rather zealous in my belief that freedom of expression and privacy are fundamental rights, and they could only be guaranteed with technical safeguards.

Around the same time the Investigatory Powers Act (without opposition from New Labour) granted 40-odd public authorities access to most peoples’ Web browsing histories, Tory politicians took it upon themselves to submit a bill (also unopposed) to ban online pornographic videos that contain anything that wouldn’t be allowed on a commercial DVD. Meanwhile in the United States, The Powers That Be have given themselves a mandate, in the form of what’s referred to as ‘Rule 41‘, to maliciously hack any computer on a Tor circuit.
Given the mainstream media’s campaign against alternative media ‘fake news’ and the associations made between non-mainstream opinion and the ‘far right’, I wonder if tomorrow would see the banning of non-mainstream ideas, and maybe our browsing histories being made available to private sector organisations.

Obviously the solutions must be open source, they must be resilient against adversaries with advanced resources and their designs beyond the control of The Powers That Be. Subgraph OS provides us with an operating system security model needed for the current age, in one installation. As well as being a Linux distribution, I like to think of Subgraph OS as a template or pattern that other Linux installations can be configured to emulate with a little work. This is what I’ve done with my own Linux system over the years.

Application Layer
The first security measure is sandboxing of processes, using Linux namespaces to segregate resource usage. Conventionally a Linux system has a root process, and a single process tree that grows the more programs are running on the system. Linux Namespaces provides a way to logically isolate processes and process trees, so that each uses a separate instance of whatever system resources it needs. Since Linux Namespaces has been a native part of the kernel for a while, anyone could set this up on their own system.

As far as a compromised process is concerned, the root process is the first within the container, and the root privileges won’t extend outside to resources outside the namespace, and neither would the process be able to navigate beyond the virtual root directory – it shouldn’t, for example, be able to spawn a malicious process capable of installing rootkit components in the system directories. The namespace itself might be compromised, but its effects are isolated.

Tor
Based on the older YAZ proxy, Metaproxy creates an independent Tor circuit for each application, and handles the session routing between the applications and Tor proxy.
What protection does this provide? Despite being referred to as an anonymising technology, it only masks the IP addresses of the source and destination servers, and other layers of security are needed to strip payloads of anonymising data.
I should point out there are other options (e.g. VPNs and I2P) to fall back on, for anyone who doesn’t trust Tor.

Kernel Security
Although the containers and namespaces at the application layer are good for isolating compromised processes and containing the damage, ideally the first line of defence is to prevent exploits executing in the first place, at a low level.

PaX provides three low level security measures: Fields are added to the ELF as it’s loaded into memory, so the stack can be made non-executable and the executable section as non-writeable. This effectively prevents the functionality of a running program being extended by malicious code. Address Space Layout Randomisation (ASLR) makes it much harder to an exploit creator to predict memory addresses, assigning a different memory map whenever a process is spawned from an executable file.
Modern operating systems already have similar native components, and existing kernels can be upgraded with versions incorporating the PaX extensions.

Filesystem Encryption
The full disk encryption included with Subgraph is based on the mature and open source dm-crypt. This is an effective defence against threats who gain physical access to the hardware while it’s switched off – for example, if it’s a laptop that’s stolen or mislaid. Often this is provided with mainstream distributions (Linux Mint and openSUSE) as an option during the installation process.
Storage volumes using dm-crypt can also be mounted on Windows systems using LibreCrypt Explorer, by the way, so that potentially allows for some portability.

Payload Anonymisation
One pretty essential layer of security that appears missing from Subgraph is payload/traffic anonymisation, but it should be possible to install Privoxy or Ghostery for this. I strongly recommend this. During the typical browsing session, the payload of browser traffic contains identifying data, and potentially the browser could fetch malicious code from compromised ad servers, even when using Tor.

FreeBSD System Security Overview

Tags

bsdconfig, exploit, FreeBSD, patching, security, update, upgrade, vulnerability

Elsewhere on this blog I’ve probably mentioned that patching, a properrly configured firewall and updated anti-malware protection will prevent 99% of security threats. Fortunately all three can be readily added to a FreeBSD installation, and there are some other native features in this operating system that can provide pretty solid security.
The most important things, in my opinion, are exploit prevention and mitigation – that is, making it hard as possible for something to exploit software vulnerabilities, and restricting what an exploit could do if executed.

BSD Configuration Options
Already present in a FreeBSD installation is the ‘bsdconfig’ utility, which enables low-level configuration changes. The Security and Startup options are the ones we might want to configure, after everything’s set up.

The Securelevel options are used for limiting the actions that could be performed with root privileges, assuming no malicious program is capable of undoing these configuration changes. In Highly secure mode, the loading/unloading of kernel modules, the mounting of additional filesystems and certain configuration changes are disabled. This could provide an additional safeguard against the installation of kenel-mode rootkits. There is a help page describing what each Securelevel option does.

Patching
If an anti-malware system has reacted to a malware infection attempt, it typically means a vulnerability has already been exploited and shellcode was executed. Patching known vulnerabilities and removing software we don’t need really is the first line of defence, if the operating system doesn’t have native exploit prevention measures such as ASLR.
The following commands are used to fetch available updates to the base system, and install whatever has been fetched:
#freebsd-update fetch
#freebsd-update install

This sorts the updates for the core operating system, but there are also a load of other packages that were added later. The following looks for vulnerability notices associated with installed applications:
#pkg audit -F

Vulnerability disclosures are posted quite regularly, so it makes sense to make periodic checks.

To check for packages that could be upgraded to a more recent version:
#pkg version

Another tool we could use for checking for outdated pakages is portmaster.
#portmaster -a

Exploit Mitigation
PolicyKit/PolKit is something I’d need to look into further, but it seems the rough equivalent of SELinux here. Essentially it checks a request to a privileged process from an unpriviliged process, according to specific policies. The idea is that an exploited or compromised program remains limited by whatever policies are set.
A configured PolKit is included as part of the base system, and a GUI for it’s included with KDE by default.

Jails
There is a ‘jail’ utility native to the system, which is based on the chroot concept. Essentially this changes the root directory location for a given process, so that it cannot refer to anything beyond it. The FreeBSD jail adds further mechanisms to restrict access to hardware resources from a process in the chroot, so it almost provides a fake environment with predefined resources. For this to work, the FreeBSD jail requires its own jail name, host name and IP address attributes. A jail could be made to resemble a complete FreeBSD system, or a ‘service’ jail dedicated to one or two processes.
We might use this for compiling a new Linux/UNIX system within a pre-existing host installation, and the FreeBSD handbook makes reference to extracting the contents of an ISO file into the /mnt directory.

Anti-Malware
With UNIX-based systems, the anti-malware solutions have the advantage of performing more thorough checks for anything suspicious in the operating system components.
With FreeBSD’s package repositories, we have a choice of rkhunter, chkrootkit and clamAV. Each has a different method of looking for activity associated with malicious programs, but generally they check for signs of privilege escalation, replaced binaries and processes being hidden from user space.

It might take a little knowledge and experience to understand the command line output from these programs. Of course, the full output of these programs can be dumped to a text file using a command like:
#rkhunter -c >> scanlog.txt

Since all three employ slightly different methods for uncovering rootkits, best results are gained by running all three separately periodically.

Firewall and Packet Filtering
Packet filtering in FreeBSD (and Linux) happens at the kernel level, with the packets passing through the network interface and then the packet filtering module. I think this is more for FreeBSD boxes on the network perimeter, or even to use a FreeBSD box as a firewall, but it’s not a bad idea to have a host-based setup as threats are stopped at the kernel level.

FreeBSD includes three firewalls: PF, IPFW and IPF. IPFW seems the default choice here, as there’s already a ruleset file in /etc/rc.firewall, and it might be easier for most users to simply modify this as needed. There seems to be a disadvantage that IPFW only works with IP addresses, port numbers and transport layers, whereas PF looks at the session layer as well and includes a few other proxying and NAT features.

To enable the IPFW as a service at startup, add the following lines to /etc/rc.conf:

The firewall profiles are listed in rc.firewall. The alternative for a desktop system is ‘client’. For an offline machine it might be ‘closed’. Or we could set this variable to ‘filename’ if we wanted to load all the rules from elsewhere. To list the currently applied firewall rules:
#ipfw list

Then, if any changes were made and the ruleset needs reloading:
#service ipfw restart

inetd
Slightly related to the packet filtering and firewall features, FreeBSD’s repositories include xinetd, which can replace the pre-installed inetd. These programs listen for incoming network traffic, and starts a predefined server process to handle requests for whichever port, while applying any relevant policies. This ensures the right programs respond to incoming requests, and to prevent servers being misused. For example, we might want Apache to handle incoming traffic on ports 80 and 443 only, and to limit the number of session attempts for each IP address.

The rules are defined in /etc/inetd.conf, and the port-service mappings in /etc/services.

DICOM

Tags

application, dcmtk, dicom, encryption, entity, file, medical, pydicom, security

The Digital Imaging and Communications in Medicine (DICOM) standard is something I omitted from a project last year, but I’ve had to revise it again for something else. DICOM can be briefly described as an application layer protocol that enables medical devices (including workstations) to exchange, process and retrieve images (and sometimes documents) associated with patient records.
The basic idea is that patient and machine-readable information is embedded within a file (usually an image) as it’s created or converted, that file could be uploaded to a repository on the network, and any machine (workstation, CAT scanner, printer, etc.) with DICOM-compliant software could process it. The information is always associated with the same patient/entity record throughout, and consequently the images should never be attributed to the wrong records, since the information couldn’t unintentionally be separated. The general concept is also very similar to that of the ‘Semantic Web’, in which a variety of systems could present information from the same file/source in different ways.

Being an application layer thing, DICOM should work regardless of how the data is transported – an ‘Application Entity‘ sends a file through the TCP/IP stack, and the file is received and processed by another Application Entity on the other end. A DICOM Application Entity might be a CAT scanner machine, sending images to a central DICOM repository (a PACS server). From there, the images can then be accessible to other workstations in the facility.
In theory DICOM therefore could be deployed on a conventional LAN, and I’ve tried emulating this on my own network with partial success. So far, I’ve installed and played around with the following:
* Aeskulap DICOM viewer
* dcmtk
* gdcm
* OFFIS DICOM Viewer
* python-dicom

DICOM Directories and Repositories
One of DICOM’s selling points is the files could be stored in a special directory called ‘DICOMDIR’, the root of which contains a data file that enables the application to find relevant images without having to read every file. Unfortunately, the way things were developed, a valid filename is limited to capital letters, numbers and underscores. Also, the dcmmkdir utility cannot work with ‘big endian’ data, because of the way bytes are arranged in certain filesystems. Perhaps it works okay on the FAT32 or FAT16, but certainly not on EXT3/EXT4.
On a PACS server, it appears that DICOM files can be stored in a conventional database, and DICOM operations, such as C-STORE, C-FIND and C-GET can be translated by a database management application to SQL operations.

File Conversion
Let’s see first what happens when a standard JPEG is converted to a DICOM file. I’ve used a random .jpg file and added a comment in the image properties, just to show roughly where stuff is in the data structure. Here’s part of the hex dump:

As expected, there’s the ‘magic number’ sequence that marks it as a JPEG, followed by the metadata, followed by some zero bytes before the main image bytecode.

What happens after the file is converted to DICOM? I used the img2dcm utility:
$img2dcm ibm-z10.jpg ibm-z10.dcm

This time there isn’t a ‘magic number’, but instead the initial 256 bytes are zero (not shown), and this is followed by the DICOM file’s data elements including their two-letter field identifiers. Finally there’s the bytecode that makes up the image itself. I guessed that the initial 256 bytes are reserved space for the image and patient record data. There’s no routing data in the file that I can see, so again it appears DICOM is purely an application layer thing that sends data down the TCP/IP stack, and the receiving application will listen for the incoming data on a fixed port at whatever address (Aeskulap uses ports 6000 and 6100 by default).

The hex dump for a converted PDF is even more interesting, as the PDF file structure, following the zero bytes and DICOM fields, is readily identifiable:

DICOM Data Elements
So what does the file contain, other than the image bytecode?

This is roughly what you’d see on medical workstations, but presented in a different way. The hex codes to the left are references to the DICOM fields, and my guess is the codes specify where given data is located within the initial 256 bytes as certain fields are populated. Kind of like offsets that count backwards.

Accessing and Modifying the DICOM Fields
The following utility will print the ‘metadata’ within the DICOM file:
$dcmdump ibm-z10.dcm

The fields can also be updated with dcmodify. e.g.
$dcmodify ibm-z10.dcm -i "PatientName=Michael"
$dcmodify ibm-z10.dcm -i "PatientID=20523386"
$dcmodify ibm-z10.dcm -i "PatientBirthDate=May 1983"

And when the image is opened in a DICOM image viewer again, we can see the fields have been updated.

What’s also notable is the initial 256 bytes of blank space has decreased to 160 bytes, so my initial hypothesis was kind of right.

Python DICOM Module
We could also manipulate DICOM files in Python using the pydicom library:
import dicom
fields = dicom.read_file("hive.dcm")
print fields

The fields can also be modified:
fields.PatientID = "00144"
fields.PatientsName = "Michael"
fields.PatientsBirthDate = "May 1983"

But how would I know the field names within the .fields namespace? Fortunately pydicom has a dir() function that enables us to determine the field name to use. e.g.
To find the field names starting with ‘bit’:
fields.dir("bit")

Gives us:
['BitsAllocated', 'BitsStored', 'HighBit']

So we can pick any of these and substitute the earlier line with it to change whatever fields.

Security
Without encrypted connections between the Application Entities, anyone on the network could intercept the DICOM files and extract the patient information. DICOM specifies a security layer, and several ‘security profiles’ that involve the use of a public key scheme to encrypt the connections between Application Entities and a PACS server, the files and specific information within those files. This public key scheme might also be integrated with Active Directory or a Kerberos server, using one of the fields within the files as the user/account name to find the relevant private key.
Another consideration is the sharing of images with third parties for research. Obviously the data should be anonymised by removing or replacing the information fields within DICOM files. The GDCM toolkit has a utility called ‘gdcmanon’ for this.

The Class of 2014

Tags

blyth, computer, computing, degree, glamorgan, infosec, masters, mcomp, newport, security, south, tubb, university, wales

I finally and officially graduated with the Masters’ degree yesterday. Things have taken a surprising turn this last months. After ten months of bricking it to avoid failing the course, it turned out I was getting pretty decent grades almost right the way through, and I ended up being awarded the degree with distinction.

I’d have to say it was largely Newport university that got us here, and a handful of brilliant lecturers (namely Eric – especially, Chris, Andy, Stephen, Blyth, Kosta). The prim Mrs. Evans definitely deserves mentioning, having made a lasting impression on us back in 2011 – we’ve been working to her standards ever since.

Everyone on my course did really well. Passing in itself wasn’t easy. We had more literature and tools than we knew what to do with, and spent plenty of time on proof-of-concept work – I could still probably do a few hundred highly technical blog posts around Prof. Blyth’s lecture notes alone (which I will do, eventually), and perhaps a good fifty more on software development methodologies from what I learned chatting with Dr. Tubb. That’s on top of the huge archive of hacking tools we gained along the way.

Someone did ask whether I thought about doing a PhD. It’s very tempting (especially in Newport) and I’d probably love teaching as well, but four years is probably the limit unless you really want a long-term career in academia. It’s definitely time to get more heavily involved in the operational side of things.

And I’m already moving on next week, having joined a highly talented (and very busy!) international team of security analysts, and pretty much hit the ground running with them already. Security-Forensics Ltd. should be back in action before too long, after the three of us settle into our day jobs and get certified properly for pen testing.

Now it’s time to get my Tiger Scheme Associate certification sorted and start preparing for the GCIA.

Ways to Fortify a UNIX Machine

Tags

apparmor, enhanced, iptables, kernel, linux, module, netfilter, policies, security, selinux, unix, xinetd

Bruce Schneier made a statement last September to the effect: If the NSA wants in on your computer, it’s in. I’m not so sure. When putting together a report around roughly this issue, I arrived at the conclusion there is indeed a methodical way to bulletproof a UNIX system.

Host security is normally dependent on commercial anti-malware products, patching and various administrative controls, any of which could be a single point of failure. Almost no system had the layered security model I’m attempting to formalise. On top of that, relatively few systems are protected against the unknowns – the truly sophisticated malware and the zero-days.

What I’m proposing is an extremely secure configuration for UNIX installations by combining stuff at a very low level. What’s more, the components to do this are free, and in combination they provide a type of security unattainable by expensive ‘high-tech’ security products exposited in glossy brochures.

At the moment the model looks something like this:

The following are just a few notes, until I refine the idea and write something up in more depth.

Stack Protections
What this measure provides is the option to add stack protections when compiling software, specifically using fstack-protect with GCC. I’ve put this near the user level because it’s an option for users and developers, depending on whether the software’s distributed as source. Unfortunately it’s only useful where users are compiling their software from source, on systems where very few proprietary components exist.

Address Space Layout Randomisation
Again, patching only provides security against the known vulnerabilities, and these days the zero-day stuff is becoming a real concern. The next layer in the model randomises some of the process addresses – an exploit developer must somehow determine where the return address lives, the buffer sizes, the buffer addresses and whatnot. If some of the addresses are unpredictable enough, the task of creating a working exploit becomes extremely awkward.

No add-ons are needed as such. Apparently ALSR has already been included in mainstream Linux since 2005, and it’s definitely native to Ubuntu, Linux Mint and Oracle distributions. The value in /proc/sys/kernel/randomize_va_space indicates the mode it’s being used in. If it has a value of ‘2‘, the positions of the stack and the .data segment are randomised for programs configured to use ASLR protection.
The bad news is ASLR is not universally applied, being another compile-time option.

xinetd
This is more relevant to UNIX machines operating as servers, but anyone using Linux Mint or Ubuntu can install it from the package repositories. Configured correctly, it can prevent Denial of Service attacks, port scanning, port redirection and allow connections only from predefined IP addresses. Access control and resource usage limiting are the main reasons to configure xinetd on a server. The first line of protection for bastion hosts. More detailed write-up here.

iptables and netfilter
Ultimately how firewall policies are implemented in a Linux system, netfilter is a kernel module that drops, accepts or forwards incoming packets before the OS does anything with them. The netfilter module policies are administrated by the iptables command line executable, and the degree of control it allows is highly granular.

Alternatively netfilter/iptables can be ultimately administrated through desktop GUI applications such as gufw, if configuring it through the command line proves too much of a learning curve.

Linux Security Modules Framework
A native feature of the Linux kernel since version 2.6, the Linux Security Modules (LSM) framework on its own adds almost no security. It provides an interface for optional modules that intercept system calls to critical kernel functions, in other words implementing various forms of access control for programs running in user space. This is an important distinction from security measures that apply to users.

SELinux
The National Security Agency has been getting a lot of bad press lately as a result of the Snowden/Greenwald drama. What’s less commonly known is the NSA also has an ‘Information Asurance Directorate’ (now the Trusted Systems Research Group), tasked with actually making stuff secure.
One good thing the NSA did produce enhances security by adding a module to the LSM framework – Security Enhanced Linux (SELinux), plus a load of documentation to go with it.
SELinux has been around a while, it’s still actively being maintained, and it’s available from the Ubuntu and Linux Mint repositories.

The general idea is the SELinux module enforces a kind of role-based Mandatory Access Control (MAC), where programs and daemons are granted the least privileges required to function. Even if applications running with root privileges are compromised through unpatched vulnerabilities, the potential damage is quite limited.

Each process is assigned a user name, role and domain. SELinux determines what processes belonging to a given domain are allowed to access. The role tag is used by SELinux to separate administrative from non-administrative processes, which in turn limits the scope of programs that could be compromised and made to perform administrative actions.

AppArmor
SELinux received some criticism for being rather tricky to implement, so along came an easier alternative called AppArmor. It is also included or available in mainstream distributions, in particular SUSE/openSUSE.

AppArmor provides a security module that enforces security policies accrording to the profile set for each program on the system, with the idea that programs are then given only the access to resources that their profiles define. This is rather like SELinux, but AppArmor can be configured to operate in ‘learning’ mode.

Anyone with a spare box could install Ubuntu, grab the components I’ve described here from the repos, have a play around with them and have a far more secure installation as a result.