Posts in 2020 jul

overthewire bandit walkthrough (computer CTF)

### overthewire-bandit walkthrough (computer CTF) bandit is the simplest levels on and one of the simplest CTF (capture the flag) wargames there is. it uses various bash functions and tricks. several things at first: - one might find it helpful to specify a bash function that automatically ssh into the various bandit levels like such: - ```b () {ssh -p 2220 bandit$}``` in ```~/.bashrc``` - don't forget to ```source ~/.bashrc``` - bandit is the first CTF wargame i played. the first time i tried it, i got to around level 15 by myself. i was okay on the git levels and several other levels but i searched for a lot of solutions on the internet. since then i've replayed it a couple of times, but even then i have to go back to notes on a couple levels. so don't be discouraged at this seemingly perfect and compact solution and have fun. - there are other ways to solve some of these levels, but this walkthrough is already pretty optimal. - saving passwords (a.k.a. flags) can be a good habit on the first try. 0. ssh - ```b 0``` - password: bandit0 1. ```ls```, ```cat``` - ```ls -a``` to look around in home directory - ```cat readme``` to get password for bandit 1 2. ```cat``` special symbol - a weird file named ```-``` that is hard to ```cat``` - but we can always ```cat ./*``` to list all the non-hidden files in the current directory 3. same as level 2 4. hidden file - ```~/inhere/.hidden``` is a hidden file because its name starts with a dot - to read it, ```cat ./.*``` - this along with ```cat ./*``` sweeps all files in a directory 5. use the last three levels to extract this, the password is rather apparent. - use ```python -c "print len('koReBOKuIDDepwhWk7jZC0RTdopnAYKh')"``` to verify the length of the supposed flag 6. ```find``` part 1 - this time ```du ~/inhere``` tells us that the folder is much larger, around 1.3 megabytes - follow the requirement and write: - ```cat $(find . -readable -size 1033c \! -executable)``` - after a bit of trimming the password is apparent again. 7. ```find``` part 2 - follow the requirement again - it'd be useful to redirect all the permission errors to ```/dev/null``` - ```cat $(find / -size 33c -user bandit7 -group bandit6 2>/dev/null)``` 8. ```grep``` intro - linux commands can often be combined into moderately powerful scripts - ```cat data.txt | grep millionth``` 9. ```sort```, ```uniq```, ```tail``` - this level is the first complex level that requires some planning - to play CTF, planning and reconnisance is always better than blind trail and error - but i suppose a swiss army knife (such as a good injection book) is handy - follow the specification, we have the following code - ```sort data.txt | uniq -c | sort | tail -1``` 10. ```strings```, ```head``` - this is similar to the last level - follow the instructions, we have the following code - ```strings data.txt | grep === | head -10``` 11. ```base64``` - ```base64 -d data.txt``` 12. rot 13 - there are many ways to solve this level, the best way is to use a library, like Python's ```Rot13``` or CyberChef, i used CyberChef. 13. decompression - this is the longest level in bandit, if one does not get stuck - some of the steps can be tricky - follow manual and error message closely - complete solution: - ```cd $(mktemp -d)``` makes a temporary directory that has write access - ```cp ~/data.txt .``` so that we can play with it - ```xxd -r data.txt a``` output a reverse hexdump of ```data.txt``` with name a - ```file a``` tells us that it is compressed using ```gzip```, was ```data2.bin``` - if we use ```a``` or ```data2.bin``` as its name and call ```gunzip```, however, an error occurs - ```mv a data2.bin;gunzip data2.bin``` throws an error: ```unknown suffix``` - after some searching online, i found that the extension should be ```gz``` - ```mv data2.bin data2.gz;gunzip data2.gz``` fixed the error shown above and peels off the first layer of the flag - ```file data2``` to see its format, ```bzip2``` - ```bunzip2 data2``` get ```data2.out``` - ```file data2.out``` to see it's gzipped data. this time we know what to do - ```mv data2.out data2.gz; gunzip data2.gz``` gives ```data2``` - ```file data2``` to see it's ```POSIX tar arhicve``` - ```tar -xf data2``` to get ```data5.bin``` - ```file data5.bin``` to see it's another ```POSIX tar arhicve``` - ```tar -xf data5.bin``` to get ```data6.bin``` - ```file data6.bin``` to see it's another ```bzip2 compressed data``` - ```bunzip2 data6.bin``` to get ```data6.bin.out``` - ```file data6.bin.out``` to see it's another ```POSIX tar arhicve``` - ```tar -xf data6.bin.out``` to get```data8.bin``` - ```file data8.bin``` to see it's another gzipped data. - ```mv data8.bin data8.gz; gunzip data8.gz``` gives ```data8``` - ```file data8``` to see it's ```ASCII text```! - ```cat data8``` to get flag 14. ```scp```, ```ssh``` part 2 (part 1 is bandit0) - another way to authenticate is to use a private key - first, copy that private key to local machine. in local machine, do: - ```scp -P 2220 .``` - then, modfy the permission of the key - ```chmod 600 ./sshkey.private``` - finally, ssh into the next level - ```ssh -p 2220 -i ./sshkey.private``` 15. ```telnet``` - telnet is what was used before browsers are a thing, i suppose - ```cat /etc/bandit_pass/bandit14``` to get the current level's password - ```telnet localhost 30000``` to open up a loopback portal - once the portal opens and system is done printing, paste the result of the ```cat``` instruction to the portal to get the password for the next level. 16. ```openssl s_client``` - ssl encrypts the message over the network, supposedly - very similar to last level - ```cat /etc/bandit_pass/bandit15``` to get the current level's password - ```openssl s_client -connect localhost:30001``` - once the portal opens and system is done printing, paste the result of the ```cat``` instruction to the portal to get the password for the next level. 17. ```nmap``` - portscan is another important aspect to CTF games - nmap has scripts to probe other machine's ports - ```nmap --script ssl-enum-ciphers -p31000-32000 localhost``` to find out there are two ports that corresponds to the written requirement: 31518, 31790 - trial and error, and the correct port is 31790: - ```cat /etc/bandit_pass/bandit14``` - ```openssl s_client -connect localhost:31790``` - submit the current password to the loop to get flag, an RSA key - just like level 14, submit the rsa key to level 17 to enter as bandit17 - ```chmod 600 bandit17_rsa``` where ```bandit17_rsa``` is the rsa key - ```chmod 600 bandit17_rsa``` - ```ssh -p 2220 -i ./bandit17_rsa``` 18. ```diff``` - ```diff ./*``` 19. ```ssh``` part 3 - there are many ways to talk to a remote machine, some of which comes in handy when we are deined permission to log on noramlly. here's one of them that solves this level: - ```ssh -p 2220 "cat ~/readme"``` 20. ```setuid``` - ```setuid``` is common in CTF games, as it esscalates priviledge of current user - usually accompanied with ```ltrace``` if we need to hack it but this is the first time so this is easy, as shown below: - ```./bandit20-do cat /etc/bandit_pass/bandit20``` 21. ```tmux```, ```nc``` - ```tmux``` is a good window manager, great tool in general - ```nc``` needs two flags - the first one is ```-l```, which is reasonable because we want to get the password for the next level. - the second flag, after some search, is ```-p```. this allows ```nc``` to run on local ports. - this is not usual behavior in modern linux. bandit servers used ```Deuvan Linux 2.1```... - ```nc -lp 30002``` on one window - then run the setuid with 30002 on the other window - read the flag from the window with ```nc``` 22. ```cron``` part 1: intro to cornjob - ```cat /etc/cron.d/cronjob_bandit22``` to see that upon reboot and every minute, ```/usr/bin/``` is executed - ```cat /usr/bin/``` to see that the flag is in ```/tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv``` with appropriate read permissions (4 for group) - permission is very important in a later level, bandit24. - ```cat /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv``` to get flag 23. ```cron``` part 2: reverse engineering - reverse engineering is a great way to think about a lot of problems. reversing is an important spirit of hacking and creative problem solving in general. - '[a general who] knows his own army as well as the enemie's will not lose in a hundred wars.' ---- the art of war - ```cat /etc/cron.d/cronjob_bandit23``` to see that upon reboot and every minute, ```/usr/bin/``` is executed - ```cat /usr/bin/``` to see that the level is more complex than the last one. basically it use some rules to write its password in a readable file. but the file's parent directory, ```tmp```, is itself unreadable. we need to reverse the filename. - ```export myname=bandit23``` because we want to impersonate bandit23 to get his pasword - then we want to do basically the same thing as the bash code to get flag: - > ```cat /tmp/$(echo I am user $myname | md5sum | cut -d ' ' -f 1)``` 24. ```cron``` part 3: file inclusion - for every minute, the bash code ```/usr/bin/``` checks ```/var/spool/bandit24``` and tries to execute each file in there for sixty seconds, then it wipes everything in that folder. - if one merely writes ```cp /etc/bandit_pass/bandit24 /tmp/somefile``` and include it in ```/var/spool/bandit24```, nothing will happen. this is because bandit24 lacks permission to execute it. - one also needs to set group write permission for target folder so that bandit24 can write. - this is another case of walking in other's shoes - lastly, one needs to write ```chmod 777 /tmp/some_tmp_dir/somefile``` so we can read it - so ```chmod 777 /tmp/some_tmp_dir/``` and ```chmod 777 /tmp/some_tmp_dir``` before the inclusion - ```cp /tmp/some_tmp_dir/ /var/spool/bandit24``` , wait a minute, and ```cat /tmp/somefile``` - thinking through and constructing a series of gadgets to achieve something is common in CTF games, such as making an exploit sandwitch. 25. ```nc``` part 2: brute force - create and run the following bash script: - ``` for i in {0000..9999} do echo UoMYTrfrBFHyQXmg6gzctqAwOmw1IohZ $i >> attempts.txt done``` - then ```cat attempts.txt | nc localhost 30002``` 26. ```find```, ```grep```, ```more```, ```vim``` - finding things is a great skill in hacking and in life in general. if we can't find matching folder (first try), we try to find matching content (second try). - however, matching content can be very slow on a spinning disk with a large file tree (see broot's running speed on an old drive when fed in something like c/xyz). - first try: ```find / -iname "\*bandit26\*" 2>/dev/null```, no good. - second try: ```grep -rnw / -e bandit26 2>/dev/null```, lead us to ```/usr/bin/showtext``` - ```showtext``` tells us that ```TERM``` is messed up, and the connection gives a ```more``` program - the character of ```more``` is that it becomes more flexible when the window is smaller than all the texts it's trying to show. - resize the window so that the height is smaller than that of 'bandit26' and press v to trigger vim - once in vim, do each of these instruction following a colon: - ```set shell=/bin/bash``` - ```!./bandit27-do cat /etc/bandit_pass/bandit27``` 27. ```git``` part 1: ```clone``` - saving passwords can be helpful for the git levels. - this level is simple - ```cd $(mktemp -d)``` - ```git clone ssh://bandit27-git@localhost/home/bandit27-git/repo``` - ```cat ./repo/*``` 28. ```git``` part 2: ```log```, ```checkout``` - password in an earlier commit - ```cd repo; git checkout HEAD~1``` - ```cat ./*``` 29. ```git``` part 3: ```branch``` - ```no password in production``` says local repo - so password is in development - ```git branch --remote``` to see ```dev``` branch - ```git checkout -b origin/dev``` - ```cat ./*``` 30. ```git``` part 4: ```tag``` - this is one of the harder levels. after some reading one can see there's another piece of information, the tag. - ```git tag``` gives us ```secret``` - ```git show secret``` - (in practice, add tag from github's GUI...) 31. ```git``` part 5: ```push```, ```gitignore``` - this has more practical value compared to the last level. - if one naively push the repo, one would get ```everything up to date``` and nothing else. - ```echo 'May I come in?' >> key.txt``` - ```git add -A; git commit -m "solve"; git push origin master``` - but if one reads the messages from ```git```, ti's not hard to figure out waht's wrong - firstly, ```git add``` has no reaction. this is abnormal. we just created a file and wrote some things to it! - secondly, ```git commit``` says ```nothing to commit```, but again there is one more file this time - this leads to a look at ```.gitignore``` - ```cat ./.*``` gives us ```*.txt``` - git ignores all ```txt``` files. - so remove ```.gitignore``` and try again 32. 'uppercase shell' (ad hoc) - this is one of the harder levels and it's also interesting. - if one tries the same trick as level 26, there's no luck. - ```du uppershell``` gives a scary 8 kb file size. (which means it's at least 4 kb) - first observation: numbers are echoed with ```not found```, letters are capitalized with ```not found``` - second observation: special symbols generally trigger special responses - third observaton: ```.``` triggers no response - fourth observation: ```./*``` triggers welcome response, ```WELCOME TO UPPERCASE SHELL``` - fifth observation: ```../*``` gives us ```../bandit0: permission deined``` - sixth observation: ```../../*``` gives us ```../../: permission deined``` - best guess at this point: this code rests in bandit32's home directory, capitalizes all letters and tries to run the result - so to make progress, we cannot use any letters. that means we cannot go to the password file directly - we have to get shell without explicitly writing ```/bin/bash``` - this suggests ```$0```, the first variable is always the current shell - then simply ```cat /etc/bandit_pass/bandit33``` to finish the last level.

Daily Quote

This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should no deserve the computer at all! It has allready taught us a few lessons, and the one I have chosen to stress in this talk is the following. We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremenduous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsec limitations of the human mind and approach the task as Very Humble Programmers. -- E. W. Dijkstra, The humble programmer