Challenge: Cracking the Password

It is late at night and it has been a very tough day. You discovered early in the morning that one of your main critical systems was compromised. You found that someone accessed it with a privileged user, using a service or application that requires authentication. You wondered if there was a new 0-day vulnerability, or if someone got the password for this user? It seems the logs gave you the response, because they registered the IP address (an internal machine) from where the connection to the critical system was established. You had time to investigate that internal box, and found a file called "password" containing the following string:

VOhRrmhZvX7lEG9KvuF/6FVA

Questions:

1. What is the system or application that use this kind of password string and for what purpose?
2. What is the format and crypto algorithm(s) used on this password string?
   
3. What is the clear-text password of your critical system? Please, detail the process you followed and the tools you used to obtain the password.
   

Please, submit your answers to radajo@gmail.com by June 29, 2007. The official answers and the winner (most accurate and elegant answer) will be published by the beggining of July. The winner will receive an autographed copy of Ed Skoudis' "Counter Hack" book (the classic best-seller first edition), also signed by the whole RaDaJo crew.

NOTE: Look in the comments section of this post for tips to solve this challenge. They will be published only if no successful responses are received by June 29, 2007.

GDB hints for dancing in the stack

If, as an incident handler, you want to understand how systems are attacked, sooner or later, you will have to confront the stack. Also there is an age for script kiddies to become real hackers and the first step in that way, right after their first words in assembly language, is to understand how the stack works.

The stack is the Rosetta Stone for understanding the hidden secrets of buffer overflows and format string attacks. And it is a prerequisite for understanding heap overflows.

Fortunately for those of you that have to take that path, some really helpful documents, like the deservedly famous "Smashing The Stack For Fun And Profit", will take you by the hand through that hostile way.

However, if you want to go through some additional examples or fight against your first buffer overflow exploit with GDB, you start feeling clumsy. Running individual processor instructions and then printing the esp, ebp, and eip registers, show the contents of the top of the stack, and displaying the next instruction to be executed while singing the GDB song is, to say the least, tedious. But GDB has been designed with those tasks in mind and it includes some functionality to make our lives easier. Namely the user defined commands (a.k.a. canned sequences of commands).

The purpose of this post was to make your life easier with a couple of user defined commands that I use within GDB, but let me please remind you first that if you want to dance in the stack in recent versions of Linux there is something you need to do first. One of the countermeasures applied to reduce the effectiveness of memory attacks (buffer overflows, format strings, and heap overflows) is to introduce some amount of randomization in the virtual addresses every time a program is run, so it becomes harder to predict the right address to jump to.

To disable this feature you just have to (as root):
echo 0 > /proc/sys/kernel/randomize_va_space
Having done that, you have your stack ready to dance, so let's go back to the GDB user defined commands.

The first thing you need to know about the GDB user defined commands is that they should be stored in your .gdbinit file that can be either in your home directory (if you want GDB to process it before the command line options) or in the current working directory (allowing you to have different .gdbinit files for different projects).

In order to avoid the tedious routine that I mentioned before, the most useful thing that a defined command can do is show you the contents of the stack. This can be achieved with the following command:
define stack
info reg ebp esp eip
echo * -- Stack -- *\n
if $argc == 0
x/16w $esp-16
end
if $argc == 1
x/$arg0w $esp-16
end
echo * -- Stack -- *\n
echo Next instruction:\
x/i $eip
end

This newly defined stack command does all these tasks:

• Print the registers ebp (base or frame pointer), esp (stack pointer), and eip (instruction pointer).
• Print a string to show the beginning of the stack information.
  
• If it is invoked with no arguments it prints twelve words of the top stack (32 bits each) preceded by 4 words that aren't part of the stack. If an argument is provided it is used as the number of total words. Notice that in any case, the top of the stack will be located at the beginning of your 2 line of stack information.
  
• Print a string to show the end of the stack information.
• Show the next processor instruction in assembly language.

Since this is usually done after having run one processor instruction with si or ni, it would also be interesting to have a modified version of those instructions that run the instruction and print the desired information. I will call these commands sis (step instruction and stack) and nis (next instruction and stack) and they are defined with this code:
define sis
si
stack 20
end
define nis
ni
stack 20
end

I hope that with these three new commands for GDB it will be easier for you to play with the stack. Enjoy!