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 
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
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?