posts/overthewire/bandit/level33/

[utterances-bot]

OverTheWire Bandit Level 32 -> 33 - Walkthrough - MayADevBe Blog

A walkthrough of Level 32 -> 33 of the Bandit wargame from OverTheWire. - Linux Variables and shell escape.

https://mayadevbe.me/posts/overthewire/bandit/level33/

[hyperswiss]

Thanks a lot

[stemar88]

Thanks alot . my hero

[personguy]

Man, I spent so long trying to figure this one out on my own. Even after seeing the solution here I'm still quite confused as to what I experienced (still trying to wrap my head around shells).

I found that I could run "uppershell" again with "./*", but not with "./uppershell". I think "./*" is running the first executable that is found in the working/lowest directory.

>> ./*
WELCOME TO THE UPPERCASE SHELL
>> ./uppershell
sh: 1: ./UPPERSHELL: not found
>> 

However, when I passed "/*" it would return "/bin: Permission denied", which made me think the lowest directory was /bin. While passing $PWD returns /home/bandit32: Permission denied, so it looks like the working directory is /home/bandit32/. So why does ./* execute "uppershell" which lives in /home/bandit32/ and not /bin/?

I also made the mistake/discovery of passing "/*/*" which spat out a long stream of impressive-looking gobbledygook with a few chunks of human-readable text ... and then turned every typed A-Z character into garbage, as well as the terminal responses, though the text that was passed in the terminal seemed to register correctly on the other end. Very strange.

>> ␌┌␊▒⎼
⎽␤: 1: CLEAR: P␊⎼└␋⎽⎽␋⎺┼ ␍␊┼␋␊␍
>> ┬␤⎺▒└␋
⎽␤: 1: WHOAMI: P␊⎼└␋⎽⎽␋⎺┼ ␍␊┼␋␊␍
>>

(The behaviour is stuck like this even after breaking out of the shell.)

I'm still stumped as to why $0 exited the shell. I take it as read that simply typing the variable is equivalent to typing what's stored in the variable. Once outside the restricted shell, echo $0 returns sh, yet inside the restricted shell sh returns permission denied.

Is it simply that most/all commands (including sh) are forbidden inside "uppershell", while executing whatever is inside an environment variable (by typing it) is allowed?

[MayADevBe]

@personguy Ok, so there is a lot coming together here. 'uppershell' as the name suggests replaces your input lowercase characters with uppercase, this is why the not found error references './UPPERSHELL', not './uppershell'. Special characters, such as the characters './' do not have an uppercase version, and therefore give the normal/expected result. Regarding `./, the point ('.') indicates the current working directory - in combination with the slash ('/'), it indicates running the script afterwards - like./uppershellwould run the 'uppershell' script in the current directory. The asterisk '*' is a so-called wildcard that matches any character, without further narrowing down what matches, it would match anything (file, script, directory) that are in the current directory. Knowing this the behaviour of/is explainable. Since you are removing the point, you are now not looking at the working directory but at the root ('/') of the whole linux system. (If you usels /you can everything in there). This means the asterisk matches everything, so you try executing the bin folder - no permission and impossible. With same reasoning//*this would try to execute everything in the subfolders of every folder in the root. $0is a special parameter see: https://bash.cyberciti.biz/guide/$0 Lastly, the permissions can be explained because of the SUID that is set. (You are user bandit32 with the permissions, but 'uppershell' is run with bandit33 permissions, which is what leads to the privilege escalation). So running$0in the uppershell means you will runsh` but with bandit33 permissions.

Hope this helps!

[personguy]

@MayADevBe Thanks so much for taking the time to help me understand that!

The difference of ./ vs. / being the current working directory vs. the root directory is a useful distinction. I was getting confused partly because the only way I know to run an executable is prepending it with ./, but I hadn't put 2+2 together to wonder what the . was actually representing.

In fact I was familiar with . indicating the cwd because (at least) on Mac in Terminal you can always type open . and the GUI will open a new window in the current directory. I also did some more reading on why ./ is required in order to run an executable (tldr, a nix security measure). What I guess is still surprising is that `/without the.will (at least try to) run an executable (or try to execute everything, since it's a wildcard matching 'all'). I tried/and//on my Mac and, sure enough, it tries to execute the first file (alphabetically) in the root directory, and the first file in that directory, respectively. I guess I'm just surprised that/has any effect without a.orcdorlsetc. in front! At any rate, thank you for setting me straight on "I think./` tries to run the first executable in the folder" because I was way off on that assumption.

As for the point about permissions, your explanation makes perfect sense and matches with the experience the game provided of escalating privileges that way. I think I just need more experience with these CTF challenges and managing files/permissions in *nix in general for it to really sink in, because I still struggle to understand why/how a user having permission to run a file also causes them to run the file as the user who owns it (e.g. bandit32 has permission to run uppershell but I still don't get why the shell then thinks bandit32 is bandit33 while inside the executable). I'll keep reading and practising and I'm sure one day it will click.

edit:

because of the SUID that is set

You gave me the answer and it flew right past my tired head. I thought SUID was simply referencing the permissions scheme in general, but after further reading I now see it's a specific permission bit that can be set to accomplish exactly that (letting a non-owner execute a file as the owner). Also explains why those files were always highlighted differently. 👌

Thanks for helping me learn with your replies and all your great write-ups on these challenges! ✌️

[phatbs21]

Thanks a lot

[SpaceCadet2000]

I actually used an alternative approach for this one. Early on I understood that I had to use an upper case environment variable to call a shell. My first attempt was to use ssh's SetEnv or SendEnv options to inject a custom variable into the uppercase shell. Unfortunately, setting variables via ssh is disabled on the server side by default, and indeed also on the bandit sshd server.

However, then I realized there is one variable you can always set remotely: $TERM.

So I did the following:

ssh bandit32@bandit.labs.overthewire.org -p 2220  -o "SetEnv TERM=/bin/bash"
...
WELCOME TO THE UPPERCASE SHELL
>> $TERM
bandit33@bandit:~$ whoami
bandit33