Arp cache poisoning

Today, I will talk about the ARP cache poisoning.

Table of contents:

  1. Introduction
  2. Topology
  3. How does ARP protocol works ?
  4. Technical attack
  5. Network flow explanation
  6. Remediation
  7. Conclusion

Introduction

The Address Resolution Protocol (ARP) is a communication protocol used for discovering the link layer address, such as a MAC address, associated with a given network layer address, typically an IPv4 address. This mapping is a critical function in the Internet protocol suite. ARP was defined in 1982 by RFC 826,[1] which is Internet Standard STD 37.

ARP has been implemented with many combinations of network and data link layer technologies, such as IPv4, Chaosnet, DECnet and Xerox PARC Universal Packet (PUP) using IEEE 802 standards, FDDI, X.25, Frame Relay and Asynchronous Transfer Mode (ATM). IPv4 over IEEE 802.3 and IEEE 802.11 is the most common usage.

In Internet Protocol Version 6 (IPv6) networks, the functionality of ARP is provided by the Neighbor Discovery Protocol (NDP).

Here I will illustrate vulnerability in ARP protocol named ARP spoofing.

Image1.png

From the OSI model above, the ARP protocol is between layer 2 and 3 as it links a MAC address to an IP address.

Topology

Image1.png

How does ARP protocol works ?

The employee wants to configure the router. There is no entry in its ARP table:

Image1.png

So he has to know if the router he wants to manage is up or down. A ping is launched:

Image1.png

He discovers that its ARP table has been updated:

Image1.png

So how does it work in background exactly ?

There is no entry in ARP table of the Windows7 related to IP 192.168.0.254, so an ARP message is broadcasted, telling :

“Source:08:00:27:85:c5:cd
Destination: ff:ff:ff:ff:ff:ff
Who has IP 192.168.0.254 ? Respond to 192.168.0.2 !”

Image1.png

Then the concerned party, the router, responds by an ARP reply message telling:

“Source: c2:01:2b:d4:00:00
Destination: 08:00:27:85:c5:cd
192.168.0.254 is at c2:01:2b:d4:00:00”

Image1.png

The ping is send to router because the employee computer knows the MAC address related to the IP on the LAN:

“Source: 192.168.0.2
Destination: 192.168.0.254
Echo request (ping)”

Image1.png

Finally the router responds to the pings with a ICMP reply. So the router is up on the LAN:

“Source: 192.168.0.254
Destination: 192.168.0.2
Echo reply (ping)”

Image1.png

Here is a network tape using Wireshark that summarize the network exchange:

Image1.png

So what is the vulnerability related to this simple protocol ?

Technical attack

The hacker will attack the employee Win7 computer to inspect all the communications.

First I have to turn on the IP forwarding. IP forwarding also known as IP routing or Internet routing is a process used to determine which path a packet or datagram can be sent.The process uses routing information to make decisions and is designed to send a packet over multiple networks.
It will be used to forward the packet from the victim to the router after being intercepted by the hacker:

tmp.png

Now I will poisoned the ARP cache table of both the victim and the router. So I will two commands in parallel:

tmp.png

1) I will poison the ARP table of 192.168.0.2 by telling him that 192.168.0.254 is at 192.168.0.1’s MAC address. To do so, I forward to him my MAC address like the MAC address corresponding to 192.168.0.254
2) I will poison the ARP table of 192.168.0.254 by telling him that 192.168.0.2 is at 192.168.0.1’s MAC address. To do so, I forward to him my MAC address like the MAC address corresponding to 192.168.0.2

I launch the attack!

tmp.png

On Wireshark we can see the ARP bombing:

tmp.png

Now, the hacker opens up a Wireshark console to inspect all traffic outgoing from the LAN:

tmp.png

All the unciphered traffic can be analyzed and usernames:passwords can be retrieved for identity usurpation !

Network flow explanation

Here how the attack works. First I resume the ARP tables on the LAN originally:

Victim Hacker Router
08:00:27:85:C5:CD 08:00:27:27:06:D4 C2:01:2C:30:00:00

ARP table of the devices before the attack:

Router

tmp.png

Windows 7 client

tmp.png

ARP table of the devices after the attack:

Router

tmp.png

Windows 7 client

tmp.png

Here is the ARP flow in background with still the same topology:

tmp.png

The hacker knows the IP of a host on the LAN due to a previous recon scan but he don’t have a clue about its MAC address.
“Source:08:00:27:27:06:d4
Destination: ff:ff:ff:ff:ff:ff
Who has IP 192.168.0.2 ? Respond to 192.168.0.1 !”

Sans titre.png

The concerned party responds to the hacker giving its MAC address:
“Source: 08:00:27:85:c5:cd
Destination: 08:00:27:27:06:d4
192.168.0.2 is at 08:00:27:85:c5:cd”

Sans titre.png

The hacker knows the IP of its gateway due to its network configuration but he wants the MAC address associated:
“Source:08:00:27:27:06:d4
Destination: ff:ff:ff:ff:ff:ff
Who has IP 192.168.0.254 ? Respond to 192.168.0.1 !”

Sans titre.png

The network interface of the router connected on the user LAN responds:
“Source: c2:01:2b:d4:00:00
Destination: 08:00:27:27:06:d4
IP 192.168.0.254 is at c2:01:2b:d4:00:00”

Sans titre.png

Now the hacker will send false ARP declaration to spoof ARP table and set the MiTM. First the W7 client is poisoned:
“Source: 08:00:27:27:06:d4
Destination: 08:00:27:85:c5:cd
192.168.0.254 is at 08:00:27:27:06:d4 !”

Sans titre.png

Then, the router ARP table is poisoned with a false ARP message from the hacker:
“Source: 08:00:27:27:06:d4
Destination: c2:01:2b:d4:00:00
IP 192.168.0.2 is at 08:00:27:27:06:d4”

Sans titre.png

Now if the client wants to reach the webserver, the request will be forward first to the hacker and then to the webserver:
“Source: 192.168.0.2
Destination: 192.168.1.1
HTTP GET /WebServerDirectory”

Image1.png

Then, the hacker route the packet toward the network exit node:
“Source: 192.168.0.2
Destination: 192.168.1.1
HTTP GET /WebServerDirectory”

Image1.png

The Wireshark tape is alike:

Image1.png

The HTTP interception flow is alike:

Sans titre.png

Remediation

The best solution is to monitor traffic by configuring VLAN.
In the topology above, I have done port-based VLAN.

Sans titre.png

You can also:

-Configure a rule to raise an alert if too many ARP message are spread on the network in a short period of time  [SOC]

-Only trusted secure protocols such as HTTPS, SSH… [in-depth defense]

Conclusion

ARP spoofing is a long time attack but still efficient.
Because it is on the layer 2, the remediation is not evident. But some hardening functions could be applied on the switch or on the network monitoring to detect ARP spoofing.

If you have any question, I will be glad to answer you back ????

Also have my twitter account, gr3g0v1tch !

 

HTTP versus HTTPS during MiTM

Today I will talk about the difference between the HTTP and HTTPS network flow and how HTTPS works in background, introducing cryptography concepts.

Table of contents:

  1. Introduction
  2. Topology
  3. Attack, HTTP inspection
  4. Remediation
  5. HTTPS inspection
  6. TLS explanation
  7. Conclusion

Introduction

The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, and hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web.

The most popular way of establishing an encrypted HTTP connection is HTTPS.[27] Two other methods for establishing an encrypted HTTP connection also exist: Secure Hypertext Transfer Protocol, and using the HTTP/1.1 Upgrade header to specify an upgrade to TLS. Browser support for these two is, however, nearly non-existent.

The purpose is to analyze of flow in HTTP and another one in HTTPS and compare difference.

Topology

 

Sans titre.png

Attack, HTTP inspection

The hacker has compromised the employee computer ( with ARP poisoning, LAN MiTM).

All the traffic to/from the employee (192.168.0.2) is intercepted by the hacker (192.168.0.1), modified or not, and then forward to the router/the employee.

Sans titre.png

The legitimate employee authenticates on web page without encryption:

Image2.png

Here is what the hacker see on its network analyzer when the hacker is tapping the network for HTTP protocol:

Sans titre.png

The credentials are forwarding to the server in clear on the network and the hacker can use the login:password retrieved : identity usurpation !

To remind with the OSI model, a compromise on the network layer compromised all the layers above:

Sans titre.png

So how to have the communication safe even if the computer is compromised and a MiTM occurred ?

Remediation

I will implement TLS on the server.

I create a special virtualhost file dedicated to my DVWA web application from the 000-default.conf:

osboxes@osboxes:/etc/apache2/sites-available$ ls
000-default.conf default-ssl.conf dvwa.com.conf

Here is dvwa.com.conf content:

<VirtualHost *:80>
 ServerName dvwa.com
 ServerAlias www.dvwa.com
 ServerAdmin webmaster@localhost DocumentRoot /var/www/html/
 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

I activate the new configuration:

osboxes@osboxes:/etc/apache2/sites-available$ sudo a2ensite dvwa.com.conf
Enabling site dvwa.com.
To activate the new configuration, you need to run:
service apache2 reload
osboxes@osboxes:/etc/apache2/sites-available$ sudo service apache2 reload
* Reloading web server apache2

My virtualhost dedicated to my web application is activated.
Now I activate the SSL mod :

osboxes@osboxes:~$ sudo a2enmod ssl
[sudo] password for osboxes:
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Module socache_shmcb already enabled
Module ssl already enabled

I restart the web service:

osboxes@osboxes:/etc/apache2/sites-available$ sudo service apache2 restart
* Restarting web server apache2 [ OK ]

Let’s start off by creating a subdirectory within Apache’s configuration hierarchy to place the certificate files that we will be making:

osboxes@osboxes:/etc/apache2/sites-available$ sudo mkdir /etc/apache2/ssl

Now that we have a location to place our key and certificate, we can create them both in one step by typing:

osboxes@osboxes:/etc/apache2/sites-available$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
Generating a 2048 bit RSA private key
.............+++
................+++
writing new private key to '/etc/apache2/ssl/apache.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Ille-et-Vilaine
Locality Name (eg, city) []:Rennes
Organization Name (eg, company) [Internet Widgits Pty Ltd]:DVWA
Organizational Unit Name (eg, section) []:security
Common Name (e.g. server FQDN or YOUR name) []:dvwa.com
Email Address []:

Sans titre.png

The private key looks like this:

osboxes@osboxes:/etc/apache2/sites-available$ cat /etc/apache2/ssl/apache.key
Sans titre.png

The certificate:

osboxes@osboxes:/etc/apache2/sites-available$ cat /etc/apache2/ssl/apache.crt
Sans titre.png

Instead of basing our configuration file off of the 000-default.conf file in the sites-available subdirectory, we’re going to base this configuration on the default-ssl.conf file that contains some default SSL configuration:

osboxes@osboxes:/etc/apache2/sites-available$ cat default-ssl.conf
<IfModule mod_ssl.c>
 <VirtualHost _default_:443>
  ServerAdmin webmaster@localhost
  ServerName dvwa.com
  ServerAlias www.dvwa.com
  DocumentRoot /var/www/html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
  SSLEngine on
  SSLCertificateFile /etc/apache2/ssl/apache.crt
  SSLCertificateKeyFile /etc/apache2/ssl/apache.key
  <FilesMatch "\.(cgi|shtml|phtml|php)$">
   SSLOptions +StdEnvVars
  </FilesMatch>
  <Directory /usr/lib/cgi-bin>
   SSLOptions +StdEnvVars
  </Directory>
  BrowserMatch "MSIE [2-6]" \
  nokeepalive ssl-unclean-shutdown \
  downgrade-1.0 force-response-1.0
  # MSIE 7 and newer should be able to use keepalive
  BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
 </VirtualHost>
</IfModule>

I enable the SSL-virtual host:

osboxes@osboxes:/etc/apache2/sites-available$ sudo a2ensite default-ssl.conf
[sudo] password for osboxes:
Enabling site default-ssl.
To activate the new configuration, you need to run:
service apache2 reload
osboxes@osboxes:/etc/apache2/sites-available$ sudo service apache2 reload
* Reloading web server apache2

When I reach my website over the 443 port, I get a warning message :

Sans titre.png

Indeed, because the certificate is self-signed, it is not trusted. I accept it.
If I want to have details about the certificate:

Sans titre.png

HTTPS inspection

The legitimate employee authenticates on the same web page with encryption this time:

Image1.png

The hacker is still in MiTM:

Image3.png

He could suspect a web activity regarding the port reached, 443 (famous for HTTPS):

Image4.png

But he don’t have a clue about what the parameters (credentials) forwarded toward the server !

TLS explanation

Now I will explain each packet part in the TLS handshake and encryption. First, best to know is that the exchange above was tape during two main steps:

Client “Client Hello” packet

Client forwards the maximum TSL version it supports, as well as the cipher suites it can handle with, by top down preference, and a 32 bits random value.

tmp.png

The client will send a list of all the SSL/TLS protocol versions it supports, with the preferred one being first on the list. The preferred one is usually, and should be, the latest available version.

tmp.png

Cipher suites are combination of cryptographic algorithms which are used to define the overall security of the connection to be established. Typically, each cipher suite contains one cryptographic algorithm for each of the following: Key Exchange, Authentication, Bulk (data) Encryption and Message Authentication.

tmp.png

A 32-byte random data of which 4 bytes represent the client’s current datetime (in epoch format) and the remaining 28 bytes, a randomly generated number. The Client’s random and Server’s random will later be used to generate the key which the data will be encrypted with.

Server “Server Hello” packet

tmp.png

The packet is from the server and tells the client the TLS version they will use, the cipher suite and the random value. The server will (not blindly) select the Client’s preferred version of SSL/TLS protocol.

tmp.png

If supported, the server will agree on the Client’s preferred cipher suite.

tmp.png

32 bytes of random data, out of which 4 bytes represent the server’s current datetime (in epoch format), and the rest 28 bytes is a randomly generated number will be sent to the client. The Server’s random and Client’s random will later on be used to generate the key with which the data will be encrypted.

Server “Certificate” packet

From the server toward the client, consist in the server certificate:

tmp.png

Here only one certificate because I implement a self-signed. Otherwise, they would the one from the CA as well:

tmp.png

tmp.png

It also contains the server public key.

Server “Server key exchange” packet

tmp.png

Additional message from the server to the client to indicate it the public key the client will use to cipher information for the session key.

tmp.png

Server “Server Hello done” packet

The server indicates it sends all information to the client:

tmp.png

Client “Client key exchange” packet

tmp.png

The client generates a pre-master key. It is generated from a random number. The random nonce is then ciphered using the server public key from the server certificate which contains the public key:

tmp.png

This means that only the server can decrypt the message since asymmetric encryption is being used for the pre-master secret exchange.

preMasterSecret = random()

Client “Change cypher-spec” packet

The Change Cipher Spec protocol is used to change the encryption being used by the client and server. The client encrypted the pre-master key using the server public key.

tmp.png

encrypt(certicate.publicKey, preMasterSecret)

Client “Encrypted handshake message” packet

This is the first encrypted message sent from the client to the server. It is the pre-master secret key that has been encrypted using the server public key.

tmp.png

Server “Change cypher spec” packet

The server tells the client to change the ciphering mode, going the the symetric way.
Indeed, after the server receives the pre-master secret key, it uses its private key to decrypt it.
Now the server will compute the master-secret key based on the random values exchanged earlier (pre-master key, ClientRandom and ServerRandom).

tmp.png

Server “Encrypted handshake message” packet

The server responds to the client and confirms to it that the server can handle the TLS encrypted session.

tmp.png

Client application data

This is the first packet out of the handshake protocol.
Here we know that originally, it was an HTTP packet that has been ciphered using SSL (TSL) protocol.

And it goes on for each request, a new shared master key is generated from the concatenation of the two 32 bits randomly generated from the client and server.

Then ciphered using server public key.

tmp.png

Conclusion

The concept introduced here is the “in-depth-defense”.

Sans titre.png

It means that even if you got a layer compromised, by hardening a higher layer, you can protect the sensitive information that pass through the network.

Futhermore, pay attention to these additional security mesures:

-Always set “secure cookies” on the server for making them being transmitted only over encrypted HTTP connections (SSL/TLS) [Server]

-Be aware if your Certificate Authority has been compromised by having its private keys stealed [Security watch]

If you have any question, I will be glad to answer you back ????

Also have my twitter account, gr3g0v1tch !

 

 

 

Shell upload through MySQL statement

Today, I will talk about how import a shell through a MySQL syntax.

Introduction

MySQL is an open-source relational database management system (RDBMS). Its name is a combination of “My”, the name of co-founder Michael Widenius’s daughter, and “SQL”, the abbreviation for Structured Query Language.

So MySQL is a database service, like mariaDB (fork from MSQL) or SQL Server.

In the context, I was exploiting a vulnerable VM,  Stapler 1 from  vulnhub. I had access to the mySQL service and I was wondering how import a shell file on the server, in order to later be connected on.

Topology

topo.png

Exploitation

Therefore I have access on the mysql service remotely using password “plbkac”:

Capture.PNG

Then I list the databases available:

Capture.PNG

A lot DBs are stored on the server. I will upload a shell on the server. First I generate the payload using msfvenom , don’t forget to place as LHOST the computer the server will connect back (the attack machine).

Msfvenom is the combination of payload generation and encoding. It replaced msfpayload and msfencode on June 8th 2015.

Capture.PNG

To have a look at the file:

Capture.PNG

To resume: msfvenom has created a reverse TCP shell in PHP and encoded in base64. Once executed, the shell’s host will initiates a TCP connection toward the IP 192.168.0.5 on the port 4444.

Now I will upload the shell to the server using a SQL syntax:

Capture.PNG

To be sure the request operates, I check the website:

fire

Remote reverse TCP shell well upload through this PHP file !

Now I will use the multi handler. The multi handler just starts the payload receiver and waits for a connection or connects out.

Capture.PNG

I specify my IP and the port : 192.168.0.5:4444. These are the information I have set when configuring the original payload.

I will request the infected web page using -k making the connection as “insecure” by default, no certificate verification. I request…

Capture.PNG

… and I got a remote shell on the server :

Capture.PNG

Remediation

The statement “SELECT … INTO OUTFILE” should be block by default for non-privilege database users.

Conclusion

This is a way to gain a remote access to a server using a MySQL statement.

The msfvenom and multi/handler are just a way to get the reverse TCP shell.

Robots.txt entries checker

Today, I will talk about the vulnerability from the robots.txt file.

Introduction

From the Moz website, here the description of what is the purpose of the file robots.txt:

“Robots.txt is a text file webmasters create to instruct web robots (typically search engine robots) how to crawl pages on their website. The robots.txt file is part of the the robots exclusion protocol (REP), a group of web standards that regulate how robots crawl the web, access and index content, and serve that content up to users.

In practice, robots.txt files indicate whether certain user agents (web-crawling software) can or cannot crawl parts of a website. These crawl instructions are specified by “disallowing” or “allowing” the behavior of certain (or all) user agents.”

In the context, I was exploitating a vulnerable the SkyDog 1 VM from vulnhub . As I always do first, I check if a robots.txt file was on the webserver.

Hopefully, there was one, but there was thousands of entries. I can’t check them one by one, so I script.

Topology

topo - Copie.png

Exploitation

As I said, the robots.txt file had thousand of entries !

I download the file:

Capture.PNG

I will check the file, the beginning and the end:

Capture.PNG

I check how many entries there are:

Capture.PNG

Around three hundreds entries to check ! I have to script… I do using python language:

#################################################################
#Objective: 
# Check robots.txt
#Description: 
# Test each entries in robots.txt
#Date:
# 02/08/2018
#################################################################

import requests

#clean the robots.txt file
#delete Allow and Disallow directive
infile = "robots.txt"
outfile = "cleaned_file.txt"

delete_list = ["Disallow: /", "Allow: /"]
fin = open(infile)
fout = open(outfile, "w+")

print("cleaning file...")
for line in fin:
    for word in delete_list:
        line = line.replace(word, "")
    fout.write(line)
fin.close()
fout.close()

cleanfile = "cleaned_file.txt"
fclean = open(cleanfile)

match='404 Not Found'

for entries in fclean:
        entries = entries.rstrip("\n")
        url = "http://192.168.0.7/%s" % entries
        request = requests.get(url).text
        if match not in request:
                print("UP: "+url)

Then I execute the script:

Capture.PNG

Only the last URL drives to a great hint. The others are kind of false positives that display the webserver homepage.

setec

And finaly by looking at the source code, I go on the pentest to the directory Astronomy which had a directory listing available:

Sans titre.png

Remediation

Don’t include the most sensitive part of your website in your robots.txt file. The web crawlers are usefull when indexing the website marketing/commercial page, not the sensitive.

Conclusion

The robots.txt file consists sometimes the first hint to sensitive folder and document on a webserver. Looking for it may be the first step during a pentest on a web application exposed on Internet.

If you have any question, I will be glad to answer you back 🙂

Also have my twitter account, gr3g0v1tch !

HTTP PUT

Today, I will talk about the vulnerability HTTP PUT.

Table of contents:

  1. Introduction
  2. Topology
  3. Detection
  4. Attack
  5. Remediation
  6. Conclusion

Introduction

From the MDN webdocs, here the description of HTTP verb PUT : “The HTTP PUT request method creates a new resource or replaces a representation of the target resource with the request payload.”

In the context, I was exploitating a vulnerable the SickOS v1.2 VM from vulnhub . After discovering that a directory listing was available, I want to know more about the page.

Topology

topo.png

Detection

To find out which request methods a server supports, one can use curl and issue an OPTIONS request:

Capture.PNG

The HTTP PUT method is used sometimes in REST API. As I knew that HTTP PUT is permitted, I try upload a simple php file to the server. Here the content of the file:

Capture.PNG

Attack

I try sending it:

Capture.PNG

The command return seems, let’s inspect the web page:

Capture.PNG

And if I try executing it :

Capture.PNG

So the PHP is well executed on the server. Now I will upload a reverse TCP shell from pentestmonkey to have a remote connection on the server. I set my own IP and the port I want to be reach on. I choose 443 because I could be seen as a “trusted” port to be connected on from the target server firewall:

Capture.PNG

This time, I will upload the file using a nmap script instead of curl:

Capture

I wait for a connection on the target port:

Capture.PNG

If I hit the file just uploaded by making a http request…

Capture.PNG

… I gain a remote access with nc. The nc (or netcat) utility is used for just about anything under the sun involving TCP or UDP, -l for listening mode -p for port number and -n for numeric, no DNS.

Capture.PNG

Then post exploitation can be done in order to be root on the server but that was not the point here !

Remediation

On the developer side, implements a blacklist from the extension allowed to be upload or disallow HTTP PUT method to be used.

Conclusion

This is vulnerability that can easily be checked on a web page.

If you have any question, I will be glad to answer you back 🙂

Also have my twitter account, gr3g0v1tch !