Memory Forensic — Linux Kernel Confusion
Memory forensics is one of the sub-categories of digital forensics that I usually find in ctf competitions. Where it is necessary to analyze the results of a memory dump of an operating system such as windows or linux.
I found this topic after joining the Cyberscape ctf yesterday, which was held by autobahn security. I found difficulty in a digital forensic category problem in analyzing forensic memory.
Usually in the case of forensic memory, the most commonly used tool is volatility. Besides doing manual crafting on raw data, using volatility makes it easier to do analysis such as system processes, or command history. But of course, in the effectiveness of its use, I just realized that there are obstacles that can occur in the process of identifying the memory dump itself. By default, volatility recognizes windows profile, so in the case of linux operating systems, it is necessary to understand how volatility works by identifying table symbols.
In this case, it happens because of the development of various and up to date Linux kernel updates, so the use of volatility itself requires the introduction of kernel versions and linux operating system versions. So to be able to start analyzing with volatility we need to generate our own Linux profile according to the kernel version obtained.
Identifying kernel and OS Version
Based on the volatility documentation, it is mentioned that there is a possibility to create a symbol table file for the kernel to be analyzed. So to proceed to the next stage it is necessary to know the kernel used. To identify the kernel version, it can be done in 2 ways, volatility has a utility to recognize the kernel used in the memory dump by using the banners plugin.Banners
python3 vol.py -f ../../ctf/autobahnctf/orange/orange.mem banners.Banners
Volatility 3 Framework 2.4.1
Progress: 100.00 PDB scanning finished
Offset Banner
0x32d58c98 Linux version 5.19.0-32-generic (buildd@lcy02-amd64-026) (x86_64-linux-gnu-gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #33~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Jan 30 17:03:34 UTC 2 (Ubuntu 5.19.0-32.33~22.04.1-generic 5.19.17)or just read the strings and grep it
strings ../../ctf/autobahnctf/orange/orange.mem | grep -ai "Linux Version"
MESSAGE=Linux version 5.19.0-32-generic (buildd@lcy02-amd64-026) (x86_64-linux-gnu-gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #33~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Jan 30 17:03:34 UTC 2 (Ubuntu 5.19.0-32.33~22.04.1-generic 5.19.17)So, we have got the os and kernel version:
-OS: Ubuntu 22.04
- Kernel: Linux version 5.19.0–32-generic
Next, which also no less time-consuming step is to find the reference of the obtained kernel. While working on this challenge, it was quite time consuming to find the right reference, until I found the debug symbol (dbgsym) kernel version reference.
Creating ISF (Intermediate Symbol Format)
because I use wsl in the process, so I need to do this step on my own virtual machine according to the identified os.
required at this stage are the linux kernel and dwarf2json debug symbols.
To install debug symbols, as explained earlier, you can do the following preparations.
echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse" | \
sudo tee -a /etc/apt/sources.list.d/ddebs.list
sudo apt install ubuntu-dbgsym-keyring
sudo apt-get update
sudo apt-get install linux-image-$(uname -r)-dbgsymfor this case i got the kernel from different directory listed there.
after that clone and build dwarf2json from the volatility repository.
git clone https://github.com/volatilityfoundation/dwarf2json
cd dwarf2json/
go mod download github.com/spf13/pflag
go buildFinally create a symbol table profile with linux debug in the /usr/lib/debug/boot/ directory.
and copy the created json file to the linux symbol folder in the volatility directory.
A few tips from the events that I experienced were to prepare enough storage and ram, because I had experienced problems in that regard.
Read the memory
After the process is complete, go back to volatility and run linux related plugins to find more information.
You can start by looking at the bash history.
python3 vol.py -f ../../ctf/autobahnctf/orange/orange.mem linux.bash.Bash
Volatility 3 Framework 2.4.1
Progress: 100.00 Stacking attempts finished
PID Process CommandTime Command
1987 bash 2023-02-17 19:06:54.000000 ssh-keygen -t ed25519 -C moeslh
1987 bash 2023-02-17 19:06:54.000000 uname -r
1987 bash 2023-02-17 19:06:54.000000 ls -la
1987 bash 2023-02-17 19:10:11.000000 cd .ssh
1987 bash 2023-02-17 19:10:12.000000 rcmoeslh@al
1987 bash 2023-02-17 19:10:12.000000 GTK_MODULES=gail:atk-bridge
1987 bash 2023-02-17 19:10:12.000000 ls
1987 bash 2023-02-17 19:10:15.000000 cat id_ed25519
1987 bash 2023-02-17 19:10:32.000000 cat id_ed25519.pub
1987 bash 2023-02-17 19:10:36.000000 cd ..
1987 bash 2023-02-17 19:12:39.000000 sudo apt install git make
1987 bash 2023-02-17 19:12:55.000000 sudo apt install gcc -y
1987 bash 2023-02-17 19:13:42.000000 git clone https://github.com/504ensicsLabs/LiME.git
1987 bash 2023-02-17 19:13:54.000000 cd LiME/src
1987 bash 2023-02-17 19:13:56.000000 make
1987 bash 2023-02-17 19:14:29.000000 lsmod | grep lime
1987 bash 2023-02-17 19:15:15.000000 insmod ./lime-5.19.0-32-generic.ko "path=../moeslh.mem format=lime"
1987 bash 2023-02-17 19:15:23.000000 sudo insmod ./lime-5.19.0-32-generic.ko "path=../moeslh.mem format=lime"
1987 bash 2023-02-17 19:15:33.000000 ls ..
1987 bash 2023-02-17 19:15:38.000000 ls -la ..
1987 bash 2023-02-17 19:16:27.000000 rm -rf ../moeslh.mem
1987 bash 2023-02-17 19:18:29.000000 ssh moeslh@52.77.200.197 -p 18002
1987 bash 2023-02-17 19:18:58.000000 rmmod lime
1987 bash 2023-02-17 19:19:05.000000 sudo rmmod lime
1987 bash 2023-02-17 19:19:19.000000 lsmod | grep lime
1987 bash 2023-02-17 19:19:25.000000 sudo insmod ./lime-5.19.0-32-generic.ko "path=../moeslh.mem format=lime"
1987 bash 2023-02-17 19:19:35.000000 sudo insmod ./lime-5.19.0-32-generic.ko "path=../moeslh.mem format=raw"
1987 bash 2023-02-17 19:19:45.000000 sudo rmmod lime
1987 bash 2023-02-17 19:19:48.000000 lsmod | grep lime
1987 bash 2023-02-17 19:19:51.000000 sudo insmod ./lime-5.19.0-32-generic.ko "path=../moeslh.mem format=raw"
1987 bash 2023-02-17 19:20:07.000000 ls -la ..
1987 bash 2023-02-17 19:20:11.000000 lsmod | grep lime
1987 bash 2023-02-17 19:20:17.000000 sudo rmmod lime
1987 bash 2023-02-17 19:20:40.000000 sudo insmod ./lime-5.19.0-32-generic.ko "path=../moeslh-l.mem format=lime"identified some information, such as users and activities performed.
The user is seen doing ssh activities. and then perform the memory dump process using liME.
From the information obtained, no information about the flag was found. Then I tried to identify the ssh server done by the user, and it looks still active.
nc 52.77.200.197 18002
SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.1the most likely thing is to find out the communication carried out during the ssh process. Because the user uses id_ed25519 private key. we find out the use of ssh keygen here.
Trying to manually search the private key using recognizing the known signature, and find them
strings orange/orange.mem | sed -n -e '/BEGIN OPENSSH/,/END OPENSSH/ p'
...
...
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACD3eUbWoKFww/GO1sUKVxgqcqpLKINUiL62pez9Sfoa2wAAAJCDyUIsg8lC
LAAAAAtzc2gtZWQyNTUxOQAAACD3eUbWoKFww/GO1sUKVxgqcqpLKINUiL62pez9Sfoa2w
AAAEBMcvp0cSgjsQaMpxQR8EVefDdwVUY30wSWAowE7FRYg/d5RtagoXDD8Y7WxQpXGCpy
qksog1SIvral7P1J+hrbAAAABm1vZXNsaAECAwQFBgc=
-----END OPENSSH PRIVATE KEY-----after finding the private key. we use the private key to connect to the ssh done by the user.
sudo chmod 700 ~/.ssh/moeslh_key
ssh -i ~/.ssh/moeslh_key moeslh@52.77.200.197 -p 18002
Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-1030-aws x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
This system has been minimized by removing packages and content that are
not required on a system that users do not log into.
To restore this content, you can run the 'unminimize' command.
Last login: Mon Feb 27 04:34:09 2023 from 182.1.101.152
$ lss
-sh: 1: lss: not found
$ ls
$
$ ls -la
total 48
drwxr-x--- 1 moeslh ctf 4096 Feb 25 16:48 .
drwxr-xr-x 1 root root 4096 Feb 20 10:23 ..
-rw------- 1 moeslh ctf 1386 Feb 26 10:07 .bash_history
-rw-r--r-- 1 moeslh ctf 220 Jan 6 2022 .bash_logout
-rw-r--r-- 1 moeslh ctf 3771 Jan 6 2022 .bashrc
drwx------ 2 moeslh ctf 4096 Feb 20 10:38 .cache
-rw-r--r-- 1 moeslh ctf 807 Jan 6 2022 .profile
drwx------ 1 moeslh ctf 4096 Feb 20 10:23 .ssh
-rw-r--r-- 1 moeslh ctf 165 Feb 25 04:22 .wget-hsts
$ cd ..
$ ls
TALK_HERE moeslh
$ cat moeslh
cat: moeslh: Is a directory
$ ls moeslh
$ cat TALK_HERE
1 : roger moeslh
2 : yo I'm here
1 : can we do 'solar-wind' operation right now?
2 : i think we can
1 : ok, cool
1 : so can we do it on 11 or 12 march?
2 : gas sambit
ABC{f12e7a24f76e2e42eb7b5df03fa14fab}$and rightly found a file containing the flags we are looking for.
Thanks to the ctf implementer and problem setter, especially because there is learning related to the application of kernel versions and symbol tables to maximize tools so that they don’t rely too easily on tools alone.
