Someone had to open it sooner or later.
Do you have any ideas on how to solve it?
Busybox does not appear to be the latest version, perhaps there is an exploitable vulnerability
Exploit works locally , but some issue in remote
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
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.
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!
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!
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
Click here to create an account.