AdSense

Monday, April 2, 2018

Capturing HTTP Basic Authentication credentials with Wireshark


 CAPTURING HTTP BASIC AUTHENTICATION CREDENTIALS WITH WIRESHARK

- Layout for this exercise:





- This exercise is based in the previous post Setting up HTTP Basic Authentication.

- Launching the sniffer Wireshark, the Kali Linux machine is able to capture all packets crossing its interface eth0:







- Whe the user from Kali tries to access the web page "/basicauth/index.html" the Apache web server responds with the challenge for Authentication requirement. I
ntroducing the credentials:

username = admin
password = ababa





- As expected the access is successful:




- Setting up a filter that limits packets only to those exchanged between Kali (192.168.1.13) and Ubuntu Apache server (192.168.1.15), we can look into the packets captured by Wireshark.

- Once Kali has sent the correct credentials the server responds with a 200 OK message:




- However, opening the first packet it is clear that Basic authentication has been used, also displaying the string corresponding to the credentials.


- The credentials have been sent without encryption, but encoded with Base64, and the correspondig string can be copied for further study:




- Now, a Python script can be used to decode the Base64 string and reveal the correct credentials: 'admin:ababa'






- Also, Wireshark captures the HTML text response from the server, corresponding to the web page resource:









Tampering HTTP methods to bypass HTTP Basic Authentication


TAMPERING HTTP METHODS TO BYPASS BASIC AUTHENTICATION

- Layout for this exercise:





- HTTP method tampering is a vulnerability suffered by some misconfigured web servers, what can be used to bypass authentication of a directory.

- HTTP method vulnerabities happen if:

   i) it is possible to list the HTTP methods allowed by an application.
   ii) the security controls fail to block not allowed methods.
   iii) the method GET is executed by default.

- In the example used to illustrate this case it is applied HTTP Basic Authentication on the "test" folder, while the hidden file .htpasswd stores usernames and passwords:





- It is important to notice that the "valid-user" requirement for authentication is limited just to the POST method. 




This is a clear misconfiguration, because it means that any other method different to POST would be allowed to access the web page without any authentication.

- After configurating the former authentication schema for /test, let's restart the web server:




- The Linux tool curl (transfers data from or to a server), used in combination with the HTTP request method OPTIONS (lists the methods supported by the URLhelps to check what are the methods enabled for the directory /test:




- POST responds with the 401 Unauthorized standard answer because for this method it is required authentication (Require valid-user):





- However, the HEAD method responses with the standard 200 OK successful answer:





- Also, the GET method responses with the standard answer 200 OK for successful authentication. In comparison to HEAD, the GET method supplies the whole content of the web resource:




 -  Now, just writing the URL and clicking on the browser simulates the GET method. The consequence is that the authentication defined in the Virtual Host configuration is tampered (GET method does not require "valid-user" authentication), and the resource is available for every user:



- This type of vulnerability is not very usual nowadays. However, some legacy servers in large organizations might be vulnerable in case they are misconfigured according to the described way in this post.




Setting up HTTP Basic Authentication


SETTING UP HTTP BASIC AUTHENTICATION

- Layout for this exercise:







- Web applications may provide their own access control methods, but a web server can also restrict access by using two types of authentications that are part of the HTTP standard: Basic and Digest authentication.

- HTTP Basic Authentication (BA) is the simplest way to enforce access control to web resources. When making a request, the user agent  provides credentials (username and password) to the web server.

- BA uses standard fields in the HTTP header, not providing confidentiality because the credentials are sent just encoded with Base64, but not encrypted or hashed at all. 

- For further information about HTTP Basic Authentication:

https://en.wikipedia.org/wiki/Basic_access_authentication


- To implement Basic Authentication on an Apache web server, first of all a password file must be created, so that Apache can read it whenever the web page is requested.

- The utility htpasswd (part of the apache2-utils package) manages user files for basic authentication. As an example, let's take:

username: admin (very common as default username in many devices)
password: ababa (simple, for the purpose of ease in this exercise)




- The hidden file .htpasswd has been created and stored encrypted on the server side:




- The default encryption format to store the credentials is "$apr1$" + the result of an Apache-specific algorithm using an iterated (1,000 times) MD5 digest of various combinations of a random 32-bit salt and the password. 

https://httpd.apache.org/docs/2.4/misc/password_encryptions.html


See source file apr_md5.c for the details of the algorithm:

http://svn.apache.org/viewvc/apr/apr/trunk/crypto/apr_md5.c?view=markup


- Editing the Ubuntu default virtual host file (000-default.conf):




- Adding the HTTP BA restriction for the directory called "basicauth", where the web page is contained. The <Directory> block specifies that the type of authentication is Basic, the name of the realm (the realm name defines a protection space for a web resource in combination with the canonical root URL of the server being accessed), the path to the .htpasswd file, and the requirement of "valid-user" credentials:






- In this way, we have established a per-directory basis HTTP BA specific for the directory "basicauth" that we are interested in. 


- After editing the virtual host file, let's restart the web server:




- Configtest command checks that the syntax of the configuration file is correct:







- Reviewing the status of the web server:





- Now, a user is prompted to enter credentials when trying to access the web resources contained in the directory "basicauth".

- In case of introducing bad credentials, the server answers with the default "Unauthorized" message:








- Introducing the correct credentials, the web resources are finally available:







Thursday, March 8, 2018

Pentest via cellular network (V): Nmap port scanner with SMS message


PENTEST VIA CELLULAR NETWORK (V): NMAP PORT SCANNER WITH SMS MESSAGE

- Layout for this exercise (Smartphone and Raspberry Pi / SIM card / Modem):




- This exercise is based on the four previous exercises:

http://www.whitelist1.com/2018/03/pentest-via-cellular-network-i-global.html
http://www.whitelist1.com/2018/03/pentest-via-cellular-network-ii.html
http://www.whitelist1.com/2018/03/pentest-via-cellular-network-iii-sms.html
http://www.whitelist1.com/2018/03/pentest-via-cellular-network-iv-port.html


1 - Writing the Python script

- The Python script used in this exercise uses libraries and scripts from previous exercises:






- Some libraries are imported:




- A function is defined  to process the SMS message requests:





- External stored data is invoked:




- The script waits until an SMS message arrives, then processing it, and finally giving back an answer:





2 - Testing the script

- First, from the smartphone an SMS message is launched asking about the port 22 of the localhost:





- Running the Python script at the Raspberry Pi, it detects the request from the smartphone and finally gives back an answer:












- Before launching another test to the host 192.168.1.6, let's perform an Nmap scan in the usual way:




- Now,  from the smartphone an SMS message is launched inquiring about the port 135 of the host 192.168.1.6:





- The Raspberry Pi gives an answer back to the smartphone via an SMS message, and the result is equal to the usual Nmap port scanning: port 135 is open.