Linux, Unix and Technology for the mere mortal
Linux, Unix and Technology for the mere mortal

Sysadmins Misbehaving – Episode 1 ssh-keygen

When I first started writing this post I was thinking about the dangers of generating and using ssh keys for authentication on shared platforms. If you’re like me and enjoy the convenience of using private and public key pairs for ssh authentication, you’ve probably heard it a million times that you should never share the private key data, but lets be honest, do you protect your keypairs with a passphrase? What about other sensitive data that you keep in your home folder. Is your home folder encrypted? If yes, well done! If not continue reading.

I’m a Platform administrator that looks after a bunch of systems which are hosted on shared platforms. In general once we build a system and hand it over to the client, we typically lose administrative access to it because their sysadmins usually go through the process of securing said built system by changing the passwords, configuring the local firewall, setting up monitoring etc.

As the Platform Administrator it’s your job to ensure availability and integrity of that system. Technologies like snapshots, replicas and clones make your job that much easier in case of something catastrophic happening. Creating a clone of a critical system in a different data center or availability zone can be the difference between a business taking a minor outage or that business completely closing its doors.

As amazing as these technologies are, this also creates opportunities for other shenanigans to take place with absolutely no evidence or visibility to the fact that the system was tampered with or completely compromised.

While a system is running we can create a consistent snapshot and clone of its hard drives / file systems. Once we have these clones we can simply attach them as slaves to a different operating system where you can mount them and extract all sorts of sensitive data.

In the example below I’ve cloned a disk and attached it to host named custard as disk /dev/xvdc.

We can see that the root filesystem is on partition 1.

So I’ll go ahead and make a temp directory and mount the partition there and as you can see,it’s the root file system of the cloned system.

Next I’ll check what valid users are available by opening up the etc/passwd file. Sensitive data has been blacked out, but for the time being lets just note that I’ve found a valid user ‘JoeSoap’ with home directory being ‘/home/JoeSoap/

As the admin you would already know this, but for interest sake I can verify what version of the operating system is by looking up what’s in the release file

Now that I know the user a little more I can check out what data they’re storing in their home folder.

 

When I started writing this post, all I was interested in was getting a copy of the ssh private key. Once I had this I could potentially log into other known systems and completely bypassing any sort of password authentication by copying the keypair to my machine and masquerading my identity as ‘JoeSoap’ from the cloned system. Seeing as though the known hosts file is a hash of the hostname or IP address, all I’m really trying to determine is if the server has ever ssh’d into other systems and if a private and public keypair exist. If yes they may have been distributed to the known hosts. As you can see there is definitely at least 1 known host and a quick browse through the bash history exposes the IP address and the username on the target system. I can now try log into that target system as that user using the keypair obtained from the users home. Obviously this will only work if the public key has been copied to the remote known host.

** This is where things get a bit dark

What you may not have noticed is that in the users home folder they appear to also be using the server as a crypto currency wallet.

The monero-v0.11.0.0 folder and the .skycoin folder are holding some very sensitive data that may actually have real world monetary value attached to it.

Now if the users home folder was encrypted both the ssh private keys and this data would have appeared as unintelligible garbage and I would’ve never known of it’s existence.

I’m pretty interested in the data that’s sitting in the .skycoin folder. If the user that created the data hasn’t gone and sanitized this folder after creating a wallet. The private key and or seed data used to encrypt and create the wallet will still be on disk in clear text.

It’s clear that JoeSoap has not secured the wallet.

After a quick Google, I learned that the wallet folder contains seed data used to create the wallet address. If I was a malicious person I could use this data to recreate a copy of this wallet and potentially steal all the funds that are kept in it. After opening the wallet file I can see the seed data as well as the wallet address.

Before doing that I wanted to see if there was a way to see if the wallet was holding any value. One Google search later i came across https://explorer.skycoin.net/.

I pasted the address string found in the .wlt file and learned that wallet contained 15 sky. At the time of writing this was equivalent to ~R5000.

In conclusion, if you have any sort of private data sitting on computers that are not 100% owned and administered by you, encrypt your data!  Better still always encrypt irrespective of where that system exists.

 

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.