You should complete Kernel Security module and Kernel Exploitation module before these challenges.

Notes

These challenges use /challenges/run.sh as a starting point. They do not use vm script at all.

You might run /challenges/run.sh <bin path> to copy the exploit binary to the vm. In most cases, the exploit binary should be statically compiled since there is no glibc runtime inside the init rootfs.

There are hints encoded in base64. However you should avoid hints and find the bug yourself.

In practice mode, to aid debugging, edit run.sh to modify qemu arguments:

  • Add nokaslr after the -append flag.
  • Enable kvm with -enable-kvm flag for better performance.
  • Add -s flag for gdb port 1234.


Challenges

Learn msg_msg.

Notes

I fixed the SMEP config bug in the original qemu run.sh script.

Add #include <linux/slab.h> if you wanna use vm build /challenge/ips.c.

Hint 1:

T2ZmLWJ5LW9uZSBpbiBlZGl0Cg==

Hint 2:

VGhlcmUgYXJlIDIgYnVncy4K

Connect with SSH

Link your SSH key, then connect with: ssh [email protected]

Elastic objects seem to have even more power in many more slabs!

Could you use UAF-Free-Leak, Retspill, and FG-KASLR bypassing to solve this ?

Notes

  • The kernel is compiled without block device support. You will have to send the exploit binary manually via console stdin.
  • The original event does not provide firewall.c during the contest. But to focus on bug, here I gift it to you.

Hint:

aGludDogRGl2ZSBpbnRvIHRoZSBzb3VyY2UgY29kZSBmb3IgdGhhdCBvYmplY3QncyBrZXJuZWwg
ZnVuY3Rpb25zIGFuZCB5b3UnbGwgc2VlIG1hbnkgdGhpbmdzISBZb3UgY2FuIHN0aWxsIGFjaGll
dmUgdGhlIHNhbWUgcG93ZXJmdWwgcHJpbWl0aXZlcywgYnV0IGJvdGggcHJpbWl0aXZlcyBub3cg
aGFzIG5vdCBiZWVuIGRvY3VtZW50ZWQgb3Igd3JpdHRlbiBleHRlbnNpdmVseSBhYm91dCB0byB0
aGUgZXh0ZW50IG9mIG91ciBrbm93bGVkZ2UuCg==

Connect with SSH

Link your SSH key, then connect with: ssh [email protected]

After repeated attacks on poor kernel objects, I've decided to place pwners in a special isolated place - a marooned region of memory. Good luck escaping out of here :^)

Notes

  • The kernel is compiled without block device support. You will have to send the exploit binary manually via console stdin.
  • The original event does not provide mod.c during the contest. But to focus on bug, here I gift it to you.

Connect with SSH

Link your SSH key, then connect with: ssh [email protected]

Instruction

  • You have a busybox shell running as user user
  • /home/user/rose.ko is a vulnerable kernel driver
  • Try exploiting /home/user/rose.ko to achieve privilege escalation
  • You may assumed that Busybox, the Linux kernel, and Qemu are not vulnerable.

Files

  • ./share/rose.ko: The vulnerable driver
  • ./src/rose.c: The source code of rose.c

Notes

  • FG-KASLR is enabled
  • Your exploit should be kernel-agnostic. In other words, it should not rely on any kernel offsets

Connect with SSH

Link your SSH key, then connect with: ssh [email protected]

Format string but in kernel ?

Notes

Now you could use vm script to start the challenge.

Connect with SSH

Link your SSH key, then connect with: ssh [email protected]

30-Day Scoreboard:

This scoreboard reflects solves for challenges in this module after the module launched in this dojo.

Rank Hacker Badges Score