Operation Oni picoCTF 2022 Solution

Description

1. Step 1Locate the SSH key with Sleuth Kit

   Observation

   The challenge gives a raw disk image, not a mounted filesystem. Sleuth Kit handles that: mmls reads the partition table, fls lists inodes recursively, and icat extracts the private key from the .ssh directory without mounting anything.

   Run mmls disk.img to find the last (and largest) partition's starting offset, then use fls -r -o <offset> disk.img to list files recursively. Search the output for .ssh to find the directory and the private key's inode number.

   bash

   mmls disk.img

   Copied!

   bash

   fls -r -o <OFFSET> disk.img | grep -i ssh

   Copied!

   bash

   icat -o <OFFSET> disk.img <INODE_OF_PRIVATE_KEY> > key_file

   Copied!

   What didn't work first

   Tried: Run fls -r disk.img without the -o offset flag, expecting to see the .ssh directory.

   Without -o, fls starts at sector 0, where the partition table lives rather than the ext4 filesystem, so it errors out or returns garbage. Read the offset from mmls first, usually the last partition's start value, and pass it so fls addresses the right filesystem.

   Tried: Use icat with the directory's inode instead of the private key file's inode, hoping to dump the key.

   icat on a directory inode dumps the raw directory block, a binary blob of filenames and child inodes rather than any file content. The fls output lists several inodes under .ssh: the directory itself, authorized_keys, and both halves of the key pair. Take the private key, the one without the .pub extension.

   Learn more

   The Sleuth Kit is a suite of command-line forensics tools. mmls lists partition offsets, fls lists filesystem entries (including deleted files), and icat extracts a file by its inode number - all without mounting the image. On the picoCTF web shell these tools are preinstalled.

   SSH key files in /root/.ssh/ or a user's ~/.ssh/ are some of the most sensitive files on a Linux system. The private key allows authentication as that user to any server that has the corresponding public key in its authorized_keys file.

   In real forensics investigations, recovering SSH private keys from a disk image is a significant finding - it means the attacker may have had (or still have) access to other systems. The investigation would expand to identify which servers have the corresponding public key in their authorized_keys files.

2. Step 2SSH into the box

   Observation

   A key extracted with icat lands world-readable, and SSH refuses those with a permissions-too-open error. chmod 600 it before passing it with -i and the challenge's port.

   Fix permissions (chmod 600 key_file) and connect with the provided port. Once logged in, ls reveals flag.txt.

   Learn more

   SSH enforces strict permissions on private key files: if the key file is readable by anyone other than the owner, SSH refuses to use it and displays a "Permissions too open" error. chmod 600 sets read/write for owner only (rw-------), satisfying this requirement. This is a security measure - it prevents other local users from reading your private key.

   The -i key_file flag tells SSH to use a specific identity file instead of searching the default locations (~/.ssh/id_rsa, ~/.ssh/id_ed25519, etc.). The -p 53918 flag specifies a non-standard port - running SSH on a non-default port is a common practice to reduce automated scanning noise, though it provides minimal actual security since port scanners like nmap find it easily.

   This challenge combines two skills: disk forensics (extracting artifacts from an image) and SSH authentication (using a key to log in). Both appear together in real incident response scenarios where an attacker left behind persistence mechanisms like authorized SSH keys, and the investigator needs to understand what access was established.

Flag

This exercise reinforces basic SSH hygiene and disk forensics simultaneously.