An IPv6 Secret Address Generation Algorithm

Tags

client, ipv6, messaging, random, security

How would two clients communicate over IPv6 without a third-party knowing which addresses are used? This is one of the abstract problems I tried to solve back in 2013, when developing the idea of a secure messaging client that makes use of certain features associated with IPv6 (many thanks to Sam Bowne and Chris Tubb for the inspiration). It was based on two assumptions: a) both parties are assigned a block of IPv6 addresses rather than a single address, and b) communicating parties are able to arbitrarily select addresses from within their address ranges.

Address Spaces and Allocations
Given the number of possible IPv6 addresses (2^38 minus a few reserved address ranges), it’s possible that a person would be assigned a sizeable block of addresses from this, such as a 32-bit address space with 4294967296 possible addresses.

I’ve done a bit of research to determine the likely address space a person would typically be assigned. RFC 6177 reccommends allocating /48 blocks to each individual ISP customer. Whether this would actually happen in the real world remains to be seen – it’s also strongly recommended because IPv6 removes the requirement for Network Address Translation, which in turns means that an ideal allocation for a home network would be large enough to make network enumeration a little more time consuming.
IPv6 also allows for stateless address configuration, which should enable clients to select their own addresses, although this depends on how the local router is configured.

The Address Generation Algorithm
My solution is something like:

The session key is secret between two clients – how they share this is another problem which might require out-of-band communication using a public key system. Actually my proposal would be a good candidate for an instant messaging system or social network that works alongside Dark Mail.

The second parameter is the system time, in ‘HHMM’ format, because the algorithm should generate a different IPv6 address every x number of minutes, and HHMM should also be the same for both communicating clients. With a little more coding later, two clients might get this value from a shared source, perhaps over NTP.

Python Implementation
The following imports are required for implementing the concept as a Python script:
* string
* hashlib
* netaddr
* pprint
* time.gmtime and time.strftime

New addresses are generated from a current IPv6 address and a session key that might be shared between peers. These might be read from an application database and/or network interface.


selfAddress = '3ffe:1900:4545:0003:0200:f8ff:fe21:67cf'
selfKey = 'mypassword123'
peerAddress = ' '
peerKey = ' '
currentTime = strftime("%H%M")


In order to get the current address, we require a networking/NIC module that enables us to select the network interface to read from. I’m most of the way through coding a C# version of the client, using System.Net.NetworkInformation to populate a drop-down list of interfaces.

Using the netaddr and pprint modules, an address can be formatted as a hexadecimal string – basically to get the digits without the octet delimiters. The line ‘selfAddressToHex[2:]‘ removes the ‘0x‘ characters from the output.


ip = IPAddress(0, 6)
ip = IPNetwork(selfAddress)
selfAddressToHex = hex(ip.ip)
selfAddressString = selfAddressToHex[2:]


Then a SHA256 fingerprint is generated with [sessionKey+HHMM] as inputs.


hashInput = (selfKey + currentTime)
print('Hash Input: ' + hashInput)
hashedValue = hashlib.sha256(hashInput)
hashedValueString = (hashedValue).hexdigest()
print('SHA256 Fingerprint: ' + hashedValueString)


Now we can substitute the last eight bytes of the current IP address with the last eight bytes of the SHA256 value to generate a new address:


final32 = hashedValueString[56:64]
print('New Suffix: ' + final32)
newAddressString = selfAddressString.replace(selfAddressString[24:32], final32)


Finally, reformat the hex string as a valid IPv6 address by adding the delimiters between octets:


newAddress = ':'.join([newAddressString[i:i+4] for i in range(0, len(newAddressString), 4)])
print('New Address: ' + newAddress)


The running script will produce something like:

We can later write newAddress back to the application database as ‘currentAddress’, and have something that triggers this part of the application every 15 minutes.
There are other things I’d like to build on this, namely components for setting newAddress as the local IP address, and messaging between two clients running the script.

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.