Microcorruption - Cusco

As before we should go on the assumption that we aren't going to get the password - and so we don't concern ourselves with what the actual password is but only with details about how the program processes the password that you give it.

The kind of things that we might want to consider are:
* how long of a password can we put in there?
   - does a long password blow out of the stack?
   - what is the starting address of the password relative to the code?
* how does the program handle special characters?
   - unicode?
   - special delimiters?
* what functions does the program use to deal with the input that you provide it?
* are there any data structures being used to store that data that we can exploit to our advantage?
* does register under/overflow have a use?

These are just a few of the kinds of things we can begin to think about. For this level we will really only need to consider the first couple involving length of the password - more on that in a minute.

We have to have a good understanding of the code to see where the weakness is. Since this level represents an incremental update from the previous version, it seems that a reasonable place to start looking is where we looked last time... in login:

4520:  b012 5244      call #0x4452 <test_password_valid>

4524:  0f93           tst r15

4526:  0524           jz #0x4532 <login+0x32>

4528:  b012 4644      call #0x4446 <unlock_door>

452c:  3f40 d144      mov #0x44d1 "Access granted.", r15

4530:  023c           jmp #0x4536 <login+0x36>

4532:  3f40 e144      mov #0x44e1 "That password is not correct.", r15

4536:  b012 a645      call #0x45a6 <puts>

453a:  3150 1000      add #0x10, sp

453e:  3041           ret

At line 4520 the program calls "test_password_valid". It might seem like looking in test_password_valid is a good idea - after all we have previously found the password or some variant of it there. No such luck this time, there is a hardware call to do that comparison and that hardware black box puts some value into memory and program flow eventually looks at that value.

That value ends up in R15 and is then examined and if the zero bit is set based on the results of the test in line 4524 (meaning the password was wrong) then we jump to 4532 where we get the address of a string and at 4536, we 'puts' that message to stdout add 10 to the stack pointer and get out.

It merits looking at program flow for a right password also.  If the zero bit is not set when we get to 4526 (meaning the password was right) we fall through to unlock_door get the address of a message and JMP to 4536 where we 'puts' that message to stdout, add 10 to the stack pointer and get out.

In both cases, success or fail, the stack pointer is incremented by 10 to 0x43FE whereupon the instruction pointer returns to that address and executes WHATEVER CODE IS THERE...

The idea is of course that the stack pointer is incremented beyond the user password to an address for program execution which in both cases is 0x443C which is stop_prog_execution.

But what if some other address was inserted into 0x43FE? Well, the instruction pointer would return to that address and start executing that code instead. What if someone put the starting address for unlock_door instead of stop_prog_execution into 0x43FE? Then, whether or not the password was right the door would be unlocked.

It is a simple matter to find the starting address of unlock_door and (remembering that we are little endian) fill the password with 16 characters of garbage and overwrite memory location 0x43FE with 4446. It is also convenient that 44 corresponds to ascii D and 46 to ascii F.

Our winning entry is then:

1234567890abcdefFD

Microcorruption - Hanoi

These next few levels, if you aren't familiar with delving into assembly code, are a great place to start stepping through the code to get an understanding of program flow.

From looking at the code we can see that there are some basic structures that we will see over and over again in the coming levels.

trap

The trap interrupt is a software call to a hardware interrupt that results in some action being taken based on the status of certain registers - in this case the contents of the status register are used. The action taken is either to unlock the lock or set some value in another register (like r15) indicating that the supplied password was correct.

We will use this trap interrupt whenever we can. Page 8 of the manual starts the listing of valid status register contents. While some of the beginning entries seem unusable, the last entry is clearly gold: "interface with deadbolt trigger to unlock door..."

If you can set sr to 0x7F and call the trap, you win.

low level init, do copy data, do clear bss

These are some housekeeping routines called at the start of the program that aren't useful for our purposes.

main

Mostly we can expect that this is where the action would begin. Throughout the various levels we will see a variety of program styles. Some will have main filled and very few function calls, whereas this particular level the only purpose of main is to call login and then drop through to:

stop_prog_exec

Terminal point for program execution. If you get here, you failed.

unlock_door

As you can see from the code the action of unlocking the door is exactly as described above: Get 0x7F into the sr and (eventually via INT) call the trap. This doesn't always occur - hardware implementations generally don't have this function in any meaningful fashion.  But if it exists and you can get the code to call it, you win.

INT

Putting this out of order because it goes with unlock door nicely, this performs some housekeeping of preserving register state and calling the trap.

**note** As I mentioned in another posting the game changes over time to prevent people from cutting and pasting entries. In the version I played, 0x7F isn't actually the status that needs to be in the sr. I needed 0xFF to be in the sr - even though the manual said 0x7F. Generally I will refer to 0x7F as being required, but my code will always change to 0xFF.

putchar, getchar, getsn, puts

assembly implementation of C standard io lib functions. Used for user i/o. We will take advantage of their weaknesses and the code that uses them unwisely. There will come a time when the program asks for a 16 character limit password, but will ultimately accept any length which allows us to overflow the buffer. The combination of that limited expectation without following through on i/o limitations allows this kind of buffer overflow exploit. This is how we will be getting our desired value into the sr.

test_password_valid

we can expect to have to endure this function every time, but nothing of any real note happens in here.

login

The start and end of the action generally speaking. There is some point usually in this function where a branch is taken or not the ultimately allows the weakness. It varies by level, but ultimately occurs here - not in test_password as one might expect.

Having an understanding of program flow and the parts each of these functions is important. Knowing that login generally contains the meat allows us to focus on that for our weakness. Let's look at the code:We see that the true comparison for whether or not the door will be unlocked happens at line 455a and has nothing to do with test_password_valid function. The true comparison checks for a hardcoded value (0x9B) at a fixed address (0x2410). If that value is at that address code execution falls through the jne branch to "access granted" followed by a call to the unlock_door function.

4544:  b012 5444      call #0x4454 <test_password_valid>

4548:  0f93           tst r15

454a:  0324           jz $+0x8

454c:  f240 6100 1024 mov.b #0x61, &0x2410

4552:  3f40 d344      mov #0x44d3 "Testing if password is valid.", r15

4556:  b012 de45      call #0x45de <puts>

455a:  f290 9b00 1024 cmp.b #0x9b, &0x2410

4560:  0720           jne #0x4570 <login+0x50>

4562:  3f40 f144      mov #0x44f1 "Access granted.", r15

4566:  b012 de45      call #0x45de <puts>

456a:  b012 4844      call #0x4448 <unlock_door>

We also know that the starting address of where our input string occurs is 2400. Because the code doesn't actually prevent us from entering more than 16 characters (despite using getsn which can take a limiting size) we can fill addresses 2400-240F with garbage and put 9b at 2410, which will result in unlock door being called.

Here is a sample winning string (don't forget to check the box 'hex encoded') which does exactly that.

414243444546474849505152535455569b

Microcorruption - Overview, level 1, level 2

Overview

This is a war game where you are tasked with defeating a lock - it's a computerized lock that sounds really forbidding but ultimately turns out to have more holes than a sieve. The game does a good job of staying playable for new people as it has several versions that are all pretty much the same but the minor differences prevent cut and paste jobs.

Additionally, the makers of the game do a nice job of leading the player down different paths to explore not only different attack vectors but also prevent the same one from working over and over again.

As a side note, I originally started this game with the intention that my son would learn a little about computing. He didn't make it much past the first few levels - apparently prying locks open to steal imaginary bearer bonds isn't exciting enough. I suppose that is a good thing on some levels. But he did learn about the binary, octal and hexadecimal number system - which is a solid start. You can view our (my, at this point) progress as "SamnDad" on the website.

Some notes about the environment:

<action src dest>

This is the format for the assembly language for the game. This style is generally considered the reverse of Intel x86 assembly language which  puts the destination before the source.

little endian

0x1234 goes into the registers as 3412

Despite not having intel style syntax for the language the processor is little endian like many Intel processors.

Thanks Texas Instruments for being weird.
 

cmp a b yields flags based on result of: b-a ...  Good to remember for flags.

Useful websites for delving into the particulars of the processor:

http://www.ti.com/sc/docs/products/micro/msp430/userguid/as_5.pdf

http://en.wikipedia.org/wiki/TI_MSP430

New Orleans – level 1

I set a breakpoint at main and again at create_password. Create_password seemed like a good place to start, and I thought it was odd that it ran before the getsn() was called and as I watched the memory it filled in a string of letters as a I stepped it through. Naturally I tried that string, and it worked.

Interestingly the game appears to be designed for there to be a preferred solution because when I tried to overflow the buffer and trample the code, it cut me off at 100 characters despite that I entered 300 characters. This overflow works in later levels but not earlier levels. And so the game appears to be designed to train you to look for certain things.

Key learning elements: how the interface works, stepping through code and using the tools and understanding the user interface.

Sydney – level 2

The program stores the incoming password and puts it at 43a0, above which starting at 4400 is the code itself.  

Sets SP to point at 43a0 (first letters of incoming _password) and preserves SP in r15 where the incoming pass starts.

Compares a literal (0x4624 - F$) to 0x00(r15) which means r15+0 offset. As it turns out that literal is part of the password.

Jumps to (44ac) if not zero.

Whereupon it clears r14 and puts r14 into r15 and returns...

r15 has 0.

r15 is tested for 0, and if not zero goes to unlock door.

R15 0 goes to fail.

This repeats 4 times basically, so the password is hard coded not in memory but in the code itself in the form of looking for things to test against.

So: 4624 6a70, 574c, 5554

or: F$jpWLUT

EXCEPT that endian-ness counts:

2446706a4c575455

$FpjLWTU

Key learning elements: endian-ness, identifying key components of the code and stepping through those parts, flags and comparison.

Notably, buffer overflow is prevented at these early levels.

PXE - Preboot eXecution Environment - Let's PXE! (Part 2)

LET'S PXE!

Now that DHCP is working, it's time to get to the PXE stuff. I got the image file striaght from Ubuntu for my server. I found the files here:
http://cdimage.ubuntu.com/netboot/12.04/

I used curl for single files and wget (poorly but somewhat effectively) for an AMD64 build. I figured one build to start and see if I could just get that working even. Curled the pxe version from ubuntu proper (above).

I used the basic format of curl, done as root (probably foolish). In retrospect it
would have been smarter to curl it as a user into a temporary dir and then move it as root or sudo. Anyhow:

curl url/file > file

or you can

curl -O url/file to keep the existing name.

wget -r -l 0 url/  (copies *everything*) but if you point it right at the stuff you
want, you can kill it halfway through, copy over the other things and delete the extra junk which is what I did.

It is probably easier to just curl the 20 or so small boot-screens files than to use wget.

To start with you can put the kernel, initrd and boot-screens directory in
/var/lib/tftpboot/ Go ahead, just dump it in for now.

Assuming you have curled initrd and linux from ubuntu, now edit
/var/lib/tftpboot/pxelinux.cfg/default to look like this:

$ sudo vim /var/lib/tftpboot/pxelinux.cfg/default

# D-I config version 2.0
# include ubuntu-installer/amd64/boot-screens/menu.cfg
# default ubuntu-installer/amd64/boot-screens/vesamenu.c32
include boot-screens/menu.cfg
default boot-screens/vesamenu.c32
prompt 0
timeout 0
label ubuntu distro xxxx
  menu default
  kernel linux
  append initrd=initrd.gz
so, now in /var/lib/tftpboot/ we should have the following, all of it from ubuntu:

$ ls -l

drwxr-xr-x 2 root root        4096 May 12 08:25 boot-screens
-rw-r--r-- 1 root root 21256771 May 12 02:21 initrd.gz
-rw-r--r-- 1 root root  5778968 May 12 02:22 linux
-rw-r--r-- 1 root root    26461 Apr 19 13:22 pxelinux.0
drwxr-xr-x 2 root root     4096 May 12 07:19 pxelinux.cfg

FOR NOW, just read the following - or come back to it later and skip down to:
*fire up your client!*

WHAT THINGS ARE - ubuntu boot-screens

# boot-screens - a directory of text files that show dialogue for OS selection
# vesamenu.c32 - an executable that gets the ball rolling: as far I can tell this is a glorified jpg, but you need it.
# f1.txt - f10.txt - text files mostly for errors during load
# *.cfg    - primarily text files that allow specific configuration beyond the default screen. You may choose to update the paths in these to accurately reflect where the kernels are. For instance, the path provided by most of these cfg files says something like:

menu default
kernel ubuntu-installer/amd64/blahblahblah/ubuntu64/linux

but you should change them to where the linux file really is. On my server that same line reads: 

menu default
kernel ubuntu64/linux


The following detail caused me a fair bit of grief: 

RECALL that the path to all files in PXE are considered to start at /var/lib/tftpboot/  REGARDLESS of whether the path begins with / or not....    / does not operate as an absolute path with tftp in this case.

WHAT THINGS ARE - pxelinux.cfg

pxelinux.0  -  a modified version of part of an open source project called syslinux. Although pxelinux.0 is primarily a Linux loader, it is capable of loading other operating systems. It operates by using configuration files located on a TFTP server to provide boot instructions.

pxelinux.cfg - the directory where those config files that say which operating system to use (based on the choice you select on your client).

/var/lib/tftpboot/pxelinux.cfg/default - where the magic happens. this is important. this is where you set up what the options for OS will be. Each entry choice has the form:
label <label name>
    menu <which menu to use>
    kernel <relative path to kernel for this choice from /var/lib/tftpboot/>
    append initrd=<relative path to initrd for this chioce from /var/lib/tftpboot>

So, using my example of how I configured my directories and where I put my OS choices as indicated previously in the directory structure sample, the menu choice for the 64 bit Ubuntu 14.04 OS looks like this:

label 64 bit ubuntu 14.04
  menu default
  kernel 14ubuntu64/linux
  append initrd=14ubuntu64/initrd.gz

as many as you want, just configure them here and put the corresponding files in the matching locations.

FIRE UP YOUR CLIENT!

Since you have enabled DHCP you should just be able to plug your client box into your network, hit f12, select your OS and follow the instructions. If it were that easy, the text would have ended by now

 

C L I E N T

You need a box that is pxe capable, I worked with a lot of ancient equipment and not all of it had that capability.  Anything 64 bit is probably a safe bet, but check the bios to ensure your client can do it.

A couple of different difficulties you may run into with your client:

 - is your client pxe capable?
 - is your client configured to pxe?
    * perhaps you have to hit f12?
    * have you adjusted the bios to try pxe first rather than look to the drives?
    * do you need to adjust the NIC settings in the bios?
 - can you tail the logs on the pxe server to verify that your client and server are talking?
      * on my server (batman): $ tail -f /var/log/syslogs    > May 12 07:33:48 batman dhcpd: DHCPDISCOVER from 00:1a:xx:xx:xx:xx via eth0
    > May 12 07:33:49 batman dhcpd: DHCPOFFER on 1xx.2xx.xxx.xxx to 00:1a:xx:xx:xx:xx via eth0
    > May 12 07:33:52 batman dhcpd: DHCPREQUEST for 1xx.2xx.xxx.xxx (1xx.2xx.xxx.xxx) from 00:1a:xx:xx:xx:xx via eth0
    > May 12 07:33:52 batman dhcpd: DHCPACK on 1xx.2xx.xxx.xxx to 00:1a:xx:xx:xx:xx via eth0 - if you don't see this sort of conversation between your client and the server, then perhaps:
      * your client isn't plugged into a swtich port that is on the same vlan as the server
      * other plug problems, bad cable
      * dhcp not configured correctly on the server
      * the switch is ancient and is S... L...O... W... . . . . . make sure the light has a chance to turn green. This happened to me, really.

SERVING MORE THAN ONE OS

If you want to have your server host multiple OS there are a variety of ways to go about this. I preferred putting all my different OS kernels and initrd files into their own directories - a little more work but ultimately nice and clean. Alternatively you could give each of them a unique identifier and dump it all into one directory. The reality is that how the client knows where they are and what to load is based in the config files.

that being said here is what my /var/lib/tftboot dir looks like

/var/lib/tftpboot$ ls -l
drwxr-xr-x 2 root root  4096 May  8 04:19 12ubuntu32
drwxr-xr-x 2 root root  4096 May  8 03:52 12ubuntu64
drwxr-xr-x 2 root root  4096 May 12 02:22 14ubuntu64
drwxr-xr-x 2 root root  4096 May 12 07:06 boot-screens
drwxr-xr-x 2 root root  4096 May  8 02:46 coreos
-rw-r--r-- 1 root root 26461 Apr 19 13:22 pxelinux.0
drwxr-xr-x 2 root root  4096 May 12 07:19 pxelinux.cfg
in each directory is its own initrd and kernel:

/var/lib/tftpboot/14ubuntu64$ ls -l
-rw-r--r-- 1 root root 21256771 May 12 02:21 initrd.gz
-rw-r--r-- 1 root root  5778968 May 12 02:22 linux

WHERE IS EVERYTHING AGAIN?

dhcp activity:   server        /var/log/syslog          dir
dhcp leases:     server        /var/lib/dhcp            dir
dhcp config:     server        /var/lib/dhcp/dhcpd.conf file
dhcp service:    server        isc-dhcp-server          service
hosts you know:  server/client /etc/hosts               file
pxe config:      server        /var/lib/tftpboot/pxelinux.cfg/default         file
OS options:      server        /var/lib/tftpboot/MY_OS/ (kernel and initrd)

TREMENDOUS THANKS!

blkperl - my primary mentor

https://help.ubuntu.com/community/PXEInstallServer
http://blog.alainodea.com/en/ipxe-smartos

Also good:
http://askubuntu.com/questions/412574/pxe-boot-server-installation-steps-in-ubuntu-server-vm
https://help.ubuntu.com/community/UbuntuLTSP/StaticIPsWithDHCP
https://help.ubuntu.com/community/isc-dhcp-server

tailing the logs can be helpful too: sudo tail -f /var/log/syslog

Additional hugely complicated reading:
http://www.openbsd.org/faq/faq6.html

PXE - Preboot eXecution Environment - Setting Up DHCP

PXE - Setting Up DHCP

For fun in one of the labs I set up my own PXE server and made notes about the problems that I encountered in doing so. If you aren't really sure what PXE is, a decent description exists at wikipedia. In a nutshell the client sends/ broadcasts a request for a Network Bootstrap Path. The server authenticates that the request comes from a legit source and, if so, sends the path to the client. The client then executes the path and installs the given OS.

I am running an older 64 bit Dell Poweredge with Ubunutu 12.04.

To get started you will want to do a little bit of reading if you haven't already. I found the following two posts to most informative:

https://help.ubuntu.com/community/PXEInstallServer
http://blog.alainodea.com/en/ipxe-smartos

So do a little bit of background reading if you haven't yet, but odds are you already looked at those which is why you are here. If you already have DHCP configured skip those parts.

Got DHCP?

After I read these through a few times, I noted that I had several constraints. I needed at least one box to be the client. Several desktops exist in the lab that will likely serve (they did not). Additionally when I started, DHCP in the lab was broken so I had to see if I could get that resolved too.

You'll need:

isc-dhcp-server which is the dhcp server and handles networking. You'll also need tftpd-hpa which is Trivial File Transfer Protocol and it handles the transfer of the OS from the server to the client.

$> sudo apt-get install isc-dhcp-server 
$> sudo apt-get install tftpd-hpa   

Create or edit  /etc/default/tftpd-hpa with the following content (may already exist):

    # /etc/default/tftpd-hpa
    TFTP_OPTIONS="--secure --verbose"
    TFTP_USERNAME="tftp"
    TFTP_DIRECTORY="/var/lib/tftpboot"
    TFTP_ADDRESS="0.0.0.0:69"

Most of it was already there, but I added verbose.
   
$> sudo service tftpd-hpa restart
     

Editing dhcpd.conf

Now create or edit /etc/dhcp/dhcpd.conf

with the following content (adjust the subnet, range and domain-name as required):

    server ip:     1xx.2xx.2xx.2xx  // this will be same as 'next-server'
    gateway:    1xx.2xx.2xx.1xx
    subnet:        1xx.2xx.2xx.1xx
    netmask:    255.255.255.xxx
    filename:    determined by OS we will be loading basically.

So you'll need the information about your gateway, subnet and netmask. I found that information by asking around. So the file will look something like:


#----------------------------------------------------
subnet 1xx.2xx.2xx.1xx netmask 255.255.255.xxx {
  pool {
    range 1xx.2xx.2xx.2xx 131.2xx.2xx.2xx;  
    next-server 1xx.2xx.2xx.2xx;
    filename="pxelinux.0"
  }
}
#-----------------------------------------------------

But since no one was going to be authoritative about Dynamic Host Configuration Protocol in the labs, I asked if I could and so got permission. Now the file looks like this:

#-----------------------------------------------------
 18 # If DHCP server is the official DHCP server for the local
 19 # network, the authoritative directive should be uncommented.
 20  authoritative;
 :
 :
 34 subnet 1xx.2xx.2xx.1xx netmask 255.255.255.2xx {
 35 # option definitions common to all supported networks...
 36 # subnet mask advises client to use that mask
 37 # broadcast-address: where all clients receive messages from
 38 # option routers tells the client that the gateway is there
 39 default-lease-time 600;
 40 max-lease-time 7200;
 41 option subnet-mask          255.255.255.2xx;    # /27 - cidr
 42 option broadcast-address    1xx.2xx.2xx.2xx;    # town crier
 43 option routers              1xx.2xx.2xx.1xx;    # the gateway
 44 option domain-name-servers  1xx.2xx.2xx.2xx;    # DNS server
 45 option domain-name          "foo.bar.org";      # our domain!
 46   pool {
 47     range 1xx.2xx.2xx.1xx 1xx.2xx.2xx.2xx;      # I control
 48     # range 2xx-2xx; if not authoritative so I can be less
 49     # controlling :)
 50     next-server 1xx.2xx.2xx.2xx;                # pxe server
 51     filename="/pxelinux.0";                     # pxe loader
 52   }
#----------------------------------------------------------------------------------
The pxe server is the next-server and is presumably your server that you control. The client is the one who (assuming you have a PXE enabled machine - check the bios) when you hit f12 gets an ip now from your dhcp server and then is provisioned by the server with the OS you select. You can test what you have so far by plugging in a box and seeing if you get assigned an IP address.

Next Up: LET'S PXE!

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!

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.