Showing posts with label Wargames: Over The Wire. Show all posts
Showing posts with label Wargames: Over The Wire. Show all posts

Wednesday, July 2, 2014

Bandit - overthewire.org final stages

The key to most of these final stages was snooping around in the areas described. Using cat to view a file or strings to look into the guts of an executable was an important step in being able to discern what was going on at the level.
For example, for level 21, you wanted to get to the right place then take a look at the script that was being run.


bandit21@melinda:/etc/cron.d$> cat /usr/bin/cronjob_bandit22.sh 
#!/bin/bash

chmod 644 /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv

cat /etc/bandit_pass/bandit22 > /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv 

Now that we see that the password is being placed in a file in /tmp. /tmp is meant to be like a scratch pad or an extra hand to briefly hold onto something. We can see however that the script then does a chmod or 'change mode' which sets permissions on the file in to be readable by anyone. For a perms primer try:
http://www.tldp.org/LDP/GNU-Linux-Tools-Summary/html/x9543.htm

Now that you know where the file containing the password is just take a look at it:

$> cat /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv

Level 23: The trick here is that since you know what is being run by virtue of being able to view the script you can duplicate the output of the script. The output of the script is the name of a file in which the next password is created. So, by duplicating the output of the script you have the file name where the data is stored.

$> echo I am user bandit23 | md5sum

8ca319486bfbbc3663ea0fbe81326349 -

$> cat /tmp/8ca319486bfbbc3663ea0fbe81326349

Finally we hit the last level which wants us to write a script. I guess I had written a few specifically for the game by this point even though the game says this will be your first one. A bash script starts with a sh-bang! That is: #! and then is generally followed by /bin/bash, so the first line of a bash script should look pretty much like:

#!/bin/bash

More on that here: http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_02.html

So you could write a simple script to do the thing that gives you the answer and it certainly is good practice to do so if you haven't written very many, and it's always fun to explore the environment of the game by seeing how it reacts when you give it the script  .... 
or you can game the game.

And isn't that what hacking is really all about? Why write a script when a thousand other people before you already have? As we know the code of the script you would write are the same as what everyone else has already written and the answer already stored in a predictable location. Use what we did in level 23 to achieve the same result, the file may still be hanging around in /tmp with the answer just waiting for you to find it. The same vulnerability of temp that we learned about in level 23 still exists to be exploited.

Hope you have enjoyed the tour of bandit. And don't keep . in your path!

Thursday, June 12, 2014

Bandit - overthewire.org 15-19


Level 15 wants you to use SSL. At the time of writing this, the heartbleed fiasco is still in recent memory, and I actually did this level only a month or so before the news broke. Funny that the site actually indicates that "HEARTBEATING" is a problem, as it turns out heartbleed was the real problem. *rimshot*

Despite that, the level was straight forward with the command format:

openssl s_client -quiet -connect localhost:port

Level 16 was a little more fun because I got to write a script, which may not have been the most efficient way, but was pretty short and good practice for fun:

#!/bin/bash

for port in {31000..32000}; do                       

        echo "cluFn7wTiGryunymYOu4RcffSxQluehd"  |  \
        timeout 2 openssl s_client -quiet -connect  \

        localhost:$port                             \
        2>/dev/null >>/tmp/geo250/results.txt
done


Line by line this does the following:
* sets the magic cookie indicating that this is a bash script.
* assigns a number to port and for each number
* echoes the required password to
* the server at the port specified previously in the loop (but only hold the connection open for 2 seconds tops) using openssl and then
* dump any error messages in the trash and the good stuff in a file called results
* repeat until done.

Man pages and a little help from your pal google can bring you up to speed on the details if you want to delve deeper into openssl.

In the file you get the private key for the next level. You'll want to use that key as if it were your own. I copied results.txt to my machine and edited it so that only private key info was in the file. Chmod 600 results.txt so that it is private and then you can ssh -i /path_to/results.txt user@host.com to get in.

Level 18 was pretty fun too: you try to log in, then you get trolled and booted. However, if the password is valid you can still run commands on the server, you just have to do it by putting the command as part of the ssh command just by appending it to the ssh command. For example:

$> ssh user@host.org ps ps -ef | grep foo >> logfile.txt 

will ssh to host.org as user and run the command: "ps -ef | grep foo" and put the results in a file called logfile on your machine. So, in this case to get the password from the file on the machine you could run a command like:

ssh bandit18@bandit.labs.overthewire.org cat password
which will dump the password to your screen. After which the connection will be closed - in fact with this kind of command, the connection will be closed even if you don't have someone trying to boot you out and troll you. Now that you havae the password, the world (or at least the next level) is your oyster.

Thursday, May 29, 2014

Bandit - overthewire.org 10-14

I really enjoyed bandit, as there were many commands that I just don't get to use with any kind of day to day regularity. Most of my training has been self directed as they don't teach Linux in physics or computer science; you are expected to know it or learn it yourself.

For example, the level 11 the password was encrypted using rot13. Fortunately I had heard of that protocol years ago and all that remained really was to write a one liner to decode the file, which for fun I turned that into a script called rot13.sh that takes a file as argument 1 and generates a new file given by argument 2. Careful, you can clobber things because it doesn't really check to make sure of anything at all.


#!/bin/bash
# ultimate secret encryption protocol rot13
set -e
if [ -z "$2" ]; then
    cat $1 | tr 'A-Za-z' 'N-ZA-Mn-za-m'
else
    cat "$1" | tr 'A-Za-z' 'N-ZA-Mn-za-m' > "$2"
fi



Learning things on your own is fun and rewarding, but sometimes it is nice to have direction. To that end becoming involved with an organization dedicated to providing IT has been extremely helpful for me. I have taken advantage of as much of their training program as possible. But even then, sometimes basic things get skipped over, like the command: file.

File target

will tell you what kind of file the target is: a bin(ary), ASCII text, gzip or what have you because you can't necessarily tell by the extension. The extensions are meant to be helpful indicators but they are by no means enforced. This was a fairly important command for level 12. Because the file had been compressed multiple times you needed to use the file command to determine how which compression tool to use next, and when you were done compressing. The file command looks at various properties of the file itself in an attempt to determine the information. You can consult the man pages (of course!) for more information on the specifics there, as I recall there are magic cookies waiting if you do.

Lastly, level 13 gives you someone's private key. Ouch! If you have that it is probably better than the password itself assuming that the other person uses ssh to move around. You just have to copy the key into your .ssh directory, chmod 700, then ssh -i ~/.ssh/privatekey user@destination.org.

Keys are a great thing, and if you haven't set your own private key up, try it just for fun. It's just a file so it doesn't take up any room really, but you want to keep it protected if you are ever going to use it. There are lots of good instructions out there about how to:

ssh-keygen -b 4096 

what it does, and so on. Some of my favorite additional commands once you are up and running are

ssh-agent bash 

and

ssh-add -t 3600

to add an hour of no password prompting, particularly if I am running ssh for-loops for things. Probably at some point there will be something more robust than this, but by setting your bit level nice and high you are presumably making it hard for people to eavesdrop. And yes, the encryption offered by RSA keys rivals my super secret encryption protocol rot13 even.



Wednesday, May 7, 2014

Bandit - overthewire.org 1-9

"Bandit" at http://overthewire.org/wargames/ is a great introductory war game if you haven't tried this kind of thing before. You use basic linux/unix skills to get the password to the next level, and every level the challenge evolves and gets a little harder or different. All of this takes place from the command line.

I won't go over the first few levels, if you are interested in this sort of thing and know what ssh and a terminal are, you can get through them with no difficulty. But don't get get put off by how simple they are because there are still some fun things ahead.

Starting at level 5, we are using find to find the password for the next level on the server. Find is a really fun command - I might use it as follows if I don't really have a clue where to start looking for something:

find / target 2> /dev/null | grep target > results.txt

which says "look everywhere for the target, be quiet about it, just give me what I am looking for without all the other things and put it in result.txt please". Of course there are less intense search methods like locate and which as well.

For the levels 5 and 6, I got to use some specific flags that I don't normally use: -readable, -group, -size, and -user. They are all fairly straightforward with -size having a few additional options, which you can of course look up. In particular, I solved them with the following commands, respectively:

find / * -readable -size 1033c 2> /dev/null
find -user bandit7 -size 33c -group bandit6 2> /devl/null

Levels 7, 8, 9 were a little different thematically in that you didn't actually need to find the file, but rather find that data within the file using strings and grep. Grep is common enough: cat foo | grep bar is a basic use where foo is the file and bar is the word you want to find. Strings is perhaps a little more on the reversing side of the house; a good preview of looking at a binary to see if anything in there looks promising - sometimes there is some low hanging fruit to be had with it. 

However I thought the most interesting challenge of the three was level 8. The idea was that they had hidden a needle in a stack of needles. The file is some 1,000 line (or more text file) where there are 100 or so different and unique strings, and the rest of the lines are duplicates of those 100 or so patterns. Except for one line which is the target - the needle hidden in the stack of needles.

To solve it I used: 

cat data.txt | sort -n | uniq -u 

I had an idea that those two would be what was required, in fact I have a one liner that I use to get the number of different logins on a computer: 

who | cut -d' ' -f1 | sort -u | wc -l

Which brings me to a point about these kind of games. Even if you aren't interested in reversing, CTF or pwning your own, you can really learn a lot from these exercises. For starters just getting more and different problems to solve using tools you are familiar with already will help you attain mastery with those tools because you will be using them in a different manner than you are accustomed to, which may perhaps lead to learning to use different flags than you normally would.

And for those of you who are beginners, you can vastly expand your knowledge of the tools. Just by playing the game you will be learning new things, thinking creatively about how to solve a problem, and gaining a better understand of the vulnerabilities you have to consider when working as a system administrator.