[PWN] Kernel Adventures: Part 1

Someone had to open it sooner or later.
Do you have any ideas on how to solve it?

Spoiler Removed

Busybox does not appear to be the latest version, perhaps there is an exploitable vulnerability

Exploit works locally , but some issue in remote :confused:

1 Like

Just to confirmā€¦ Bruteforcing the hash is not the way to go, isnā€™t it?

@christrc check the note from the challenge and youā€™ll see why your remote will fail. Takes one small adjustment and youā€™ll have it!

I have mp you @will135 :confused:

Never mind

Starting off, but I donā€™t seem to be able to read the hashes hereā€¦

Great challenge, not that difficult after all, the most difficult part for me was to find out how to run the exploit

Can anyone dm me a hint or tell me if Im on the right track? Im stuck on this oneā€¦

So far, I read the remote hashes out, and I know the ins and outs of the ā€œmoduleā€. I tried bruteforcing the ā€œcheckā€, but it seems like the wrong way to go. Even if the check is passed, we are switched to a****, which does not seem to have any additional privileges (maybe Iā€™m wrong here?). Am I looking to exploit an additional logic bug in the d**_w**** function, or is the hash check the only thing going on here?

And for anyone who was as impatient as I was, you are supposed to straight up nc (or similar) to the remote instance. It is slow AF, so be patient and you WILL get a shell.

edit: nvm

It turns out the local version downloaded has no permissions for user (e.g. no directories are writeable by the user) while the remote does, this really should be mentioned or fixed. Also getting the exploit onto the remote I found annoyingly more difficult than the challenge itself, especially when attempting to split up my exploit into smaller parts to copy in and taking longer than around 2 minutes getting a sigterm 15 from another process. Other than that a very fun challenge.

Nice challenge so far, but I fell into the trap referenced earlier. Can escalate users, but to the wrong one! :o

It is possible to solve this challenge on a read only system. I found it to be more challenging than the original challenge itself. If you have nothing to do and like challenges assume that remote has no writable folders and try to solve the challenge under this restriction.

Here is an idea, why not make kernel part 2 and make all folders readonly on the remote.

Nice challenge, finally made it. Itā€™s scary to think that this could have been much harderā€¦!

Done and Dusted! Thanks to @flk for refocusing me and hint regarding kernel debugging.
Shout out to @sampriti for good challenge!

Wx

Hi, when connecting to the remote I donā€™t get a prompt like I do when running locally. Is this expected?..just to confirm. Thanks

This was interesting but the local copy had quite a couple of issues. I couldnā€™t run the ā€˜run.shā€™ file with the -no-kvm option and the permissions were all messed up. To fix the local copy, you can repack the local file and change the permissions of the home folders, also replacing the ā€˜-no-kvmā€™ option with ā€˜-enable-kvmā€™ seemed to make the local exploit finnaly work, just like the remote was

What was the difference between them?

Hey, even though /proc/sys/kernel/kptr_restrict is 0, when i try to read /proc/kallsyms with user, all addresses are zeros.
Is this a bug or is this intentional?