Crack me

Don’t hate the hacker, hate the code.

These are some excerpts from a presentation I gave at a ladies who linux meetup in San Francisco. 

***************************

I have always really enjoyed puzzles and games. Building forts, making indestructible cars from k’nex, rock climbing, even backpacking and trying to figure out how to make a fire in the pouring rain with only one match. There are so many things in our daily lives that force us to think critically and break apart a bigger problem into a bunch of smaller, more manageable problems. My love for puzzles was one reason why I wanted to explore the tech world. What I assumed and what I have found to be true is that the tech world is really just a giant playground of puzzles. So since I have you all right here, I thought we could do a little puzzle here together.

If you recall, our topic for the evening is security. Less than two weeks ago I moved into a new place on Treasure Island. I share a house with a few others who I didn’t know previously. My sister happened to be in town for the weekend, so on Friday night I picked up the keys to the space, dropped off a handful of things and headed up to Napa to meet her and some friends for a few days. I didn’t think much of it. When I got back I started to move the rest of my things in. I got up to my room and quickly realized that a brand new pair of running shoes I had just purchased two days previous were missing, along with a few things I had purchased from IKEA. weird right? I didn’t want to assume the worst, so I checked my car for the shoes, but to no avail. Why am I telling you about my stolen shoes? I am supposed to be talking about security. I’m telling you this story because when I first thought about security, I dove right into the deep. I started researching the seven layers of OSI, about TCP vs UDP, network mapping and the list goes on. But I just told you all, I’m a beginner – I have no experience with any of those things – and the story of my shoes reminded me of some very basic fundamentals of security. When we think of security, we often go right for the hard stuff and forget about the basics. When I moved into my new space, It’s not that I should have been overly cautious or paranoid about the living situation – but I should have taken precautions to better set myself up for success. All I really needed was a simple lock on my door.

Security does not need to be complicated, you just have to make sure you cover your bases. Make sure to password protect your accounts, cell phone, and computer. Don’t use the same password for multiple things (although I’m pretty sure we are all guilty of this one).  Make sure to use two-step verification for important logins like work emails, online banking, etc. Before you worry about the deeper levels of security, make sure you have taken care of the basics.

So – on to our little puzzle.

The is a copy of this project on github under Holberton school – so you are all welcome to clone it and try it yourself at home. Check it out here.

Before we start, I am going to open up a VM. Since we don’t know what exactly these files could contain, we want to protect ourselves by doing all this little puzzle on a VM. Things are a little more contain on a VM.

vagrant up

vagrant ssh

First I am going to clone it from github – you can see that there are a few files in this repo, we are only going to be dealing with a.out tonight, but feel free to explore the others on your own time, each one increases in difficulty and not all are solvable.

Change directory to our newly cloned repo.

cd don_hate_the_hacker_hate_the_code 

Check to see what files are here

ls

README.md a.out     crackme   crackme2  crackme3

I am going to make a copy of a.out because I know from experience that if we try to execute the program with the wrong password the file will delete itself – that feature was built into the program.  So I am going to save us time and hassle .

cp a.out ladies.exe

Now we have ladies.exe

ls 

README.md  a.out      crackme    crackme2   crackme3   ladies.exe

Okay – we are all set up to start cracking. If you haven’t guessed it already, we are going to be attempting to crack the password to this file. Like I mentioned earlier, this first one is pretty easy and if you want a challenge you can try any of the others.

First thing we want to do is to gather some information about the file we are dealing with – it’s a simple command

file  ladies.exe

We can learn a lot about our puzzle at hand by learning about the file type.

ladies.exe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, not stripped

We can see that it is ELF which means it is in an executable and linkable format – and even that it’s not stripped.

If someone wanted to cover their tracks a little bit better, they could have stripped the file.

nm ladies.exe

You get somethig that looks like this.

0000000000601058 B __bss_start

0000000000601058 b completed.6973

0000000000601048 D __data_start

0000000000601048 W data_start

0000000000400550 t deregister_tm_clones

00000000004005c0 t __do_global_dtors_aux

0000000000600e18 t __do_global_dtors_aux_fini_array_entry

0000000000601050 D __dso_handle

0000000000600e28 d _DYNAMIC

0000000000601058 D _edata

0000000000601060 B _end

When you use nm, you are listing the symbols from object files. You can strip that infomration quite easiy though. Run these commands and see what happens.

strip ladies.exe

nm ladies.exe

file ladies.exe

Now if we wanted to know a little more about the file type, despite the fact that we are the ladies who linux, we all need a man in our lives. Just man file to find out a bit more about the file command.

man file

Okay, so we have gathered some information about our file. What’s next…? Run the file?

Maybe we can read the file and find out more.

emacs ladies.exe

Woof – that’s rough. That’s not going to be of  much help. Welp – I have a few other tricks up my sleeve. How about ltrace.

man ltrace

ltrace is a program that simply runs the  specified  command  until  it exits.   It  intercepts and records the dynamic library calls which are called by the executed process and the signals which  are  received  by that  process.   It  can also intercept and print the system calls executed by the program. – Basically it will show us what library functions are being used in this file. When you use trace,  make sure to use the executable format since it actually executes the program when you run it. 

ltrace ./ladies.exe

__libc_start_main(0x40060d, 1, 0x7fff775943a8, 0x400760

printf(“Usage: %s password\n”, “./ladies.exe”Usage: ./ladies.exe password

)   = 29

puts(“See you next time hacker!”See you next time hacker!

)                = 26

You can see it’s using printf  and puts. But it looks like printf was looking for the file along with a password, so lets try it with a password now.

ltrace ./ladies.exe password

__libc_start_main(0x40060d, 2, 0x7fff451bbfe8, 0x400760

strcmp(“password”, “#cisfun”)                    = 77

strcmp(“password”, “passw0rd”)                   = 63

puts(“Access denied :(“Access denied 😦

)                         = 17

puts(“See you next time hacker!”See you next time hacker!

)                = 26

Now we see that it’s using strcmp – lets checkout what strcmp does…

man strcmp

The strcmp() function compares the two strings s1 an s2. It returns an integer less than, equal to, or greater than zero if s1 is found, respectively, to be less than, to match, or the be greater than s2.

You can see the program comparing the password we put in with two other strings, #cisfun and passw0rd. That gives us a pretty good hint that maybe one of these strings is the password. You can try them both.

Since #cisfun starts with a special character, make sure to include quotation marks around the password when you type it in.

ltrace ./ladies.exe “#cisfun”

__libc_start_main(0x40060d, 2, 0x7fff98524a78, 0x400760

strcmp(“#cisfun”, “#cisfun”)                     = 0

puts(“YES it is fun isn’t is? :)”YES it is fun isn’t is? 🙂

)               = 27

puts(“But this is not the right passwo”…But this is not the right password.

)      = 36

puts(“See you next time hacker!”See you next time hacker!

)                = 26

We get something different that time, but it’s still not right. So go ahead and try the other possibility.

ltrace ./ladies.exe passw0rd

__libc_start_main(0x40060d, 2, 0x7fff70c8f778, 0x400760

strcmp(“passw0rd”, “#cisfun”)                    = 77

strcmp(“passw0rd”, “passw0rd”)                   = 0

puts(“Access granted \\o/”Access granted \o/

)                      = 19

+++ exited (status 0) +++

It looks like it worked!

Okay let’s try something else. In programing, there are always lots of ways of solving a problem. Strings is another tool we can use.

man strings

Okay, strings – print the strings of printable characters in files. That seems like it could be useful. If there is a password in this file, it may be contained in a string.

strings ladies.exe

It looks a little bit different from ltrace. Here you can see some of the strings used in the program.

Usage: %s password

See you next time hacker!

/bin/rm

#cisfun! :);

Try again later

#cisfun

YES it is fun isn’t is? 🙂

But this is not the right password.

passw0rd

Access granted \o/

Access denied 😦

;*3$”

Now – we could write a bash script to brute force the password. We are programmers after all, so why not? This is a short program written by a fellow student at Holberton School.

#!/bin/bash

for passwrd in $(strings ./ladies.exe)

do

 cp ladies.exe tmp2.exe

 ladies=$(./tmp2.exe $passwrd | grep -v “Access denied :(“)

 echo “Trying: $passwrd”

 if [ “$ladies” != ” ]

 then

   printf “\nThe password is: %s\n” “$passwrd”

   exit 0

 fi

done

 

Yet another way to go about this is with assembly code.

objdump -d -j.text -M intel ladies.exe

I am not going to go through the assembly code now for times sake. But essentially you just have to follow one clue to another.
That’s the basics of cracking a password. If you enjoyed this, head on over to Holberton school’s github and try the others.

Don’t trust. Verify.

Today marks the end of week one at back at school. It has felt strange and refreshing not being at work anymore – I feel challenged and leave exhausted at the end of the day. The type of exhausted that means I REALLY did something today. On the other hand, it’s terrifying. I got my last pay check today from my previous job. That means that it’s budget time. I have a very specific amount of money to ride out on for the next foreseeable future. At times that scares the shit out of me. I’ve cut as many corners as I can – but at the end of the day I am still living in the most expensive city in the country – and I still need to eat, and get from point A to point B – and that is far from cheap.

Today, we had a Nicolas Bacca, the CTO at Ledger an Btchip, come in to talk to us about security. His tag line was – don’t trust. Verify. He wanted to drive home the point that in the technology industry, we can’t just trust every program we run or every website we log into – you need to verify everything. Trust leads to holes in security. Trusting things, without verification, means hackers have the opportunity to swoop in and take advantage of your information. This is a crucial tag line to implement when you work in the technology industry. I got to thinking about it more – and I quickly realized that it may work for the technology industry, but it doesn’t work in most other parts of life. Or – at least it shouldn’t. Don’t trust, verify – it implies that we should assume all control. That just isn’t feasible in life, nor is it healthy. We are not in control.

A few months back when I was just starting to talk about the possibility of starting down the path of software engineering, I found myself standing in the kitchen of the Lewis family home. I was talking to Mary Lewis, a mentor and friend. The past few years, I have been helping out at the Lewis home with their five girls (ranging in age from 5 to 17). But long ago, before Mark and Mary were parents of these five girls, they were actors in New York. Originally from Arkansas, Mary found herself in love with New York. Between her work on soap operas, and stellar roles dancing on broadway – the Big Apple had captured her heart. While in New York, Mark was offered a job in the Communications department at Wheaton college (just west of Chicago). Seeking council, the two headed to their pastor – at that time it was Tim Keller. Tim Keller is a big supporter of Christians choosing to live in our cities (I put some links to some recent posts from Tim Keller on the subject). That being said – when Mary went to seek council, she was pretty sure Tim was going to tell them that they were needed in the City. You can guess where this is going – Tim told them to go to Wheaton. Shocker.

Mary didn’t want to go at first. But God had bigger plans – plans Mark and Mary couldn’t quite see yet. When I got accepted to Holberton School, I felt a similar way. I couldn’t make out a clearly defined path of what deciding to go into software engineering looked like. Making a big decision like that without knowing all the facts is scary – and very uncomfortable. But there I was, standing in the the kitchen talking to Mary about her decision to make uncomfortable decisions nearly two decades ago – not too different from mine. It wasn’t the decision to move across the country, leaving behind the city you love – but rather the decision to trust the doors that God opens for us, and to walk through them with grace.

Here is the take away. We try really hard as human beings to remain in control of our lives. We make plans, we save our money and tighten our belts if needed, we make safe decisions to ensure we live a comfortable happy life. But it doesn’t matter how much planning, or securing we d0 – disasters strike, stock markets fall, and our loved ones get sick. There is no verification in the world that could stave off the reality of this fallen world we live in. Control does not lead to happiness, it leads to a self-centered, stale, life. God gifs us times of trial – he places fog on the path right in front of us. Our job is not to wait for the fog to lift, or take out our map to check of the possible hazards that may lie ahead – our job is to trust that He has our best interest at heart.

I challenge you – the next time you see fog up a head, don’t wait for it to clear, but seek council and if God is leading you forward, walk with grace and trust that His plans are far greater than you could even imagine. Don’t verify – TRUST.

(My path is still foggy – I’ll let you know when it starts to clear)

 

The Difference Christianity Could Make in the City

The City, the Church, and the Future – Tim Keller