Saturday, 7 November 2015

Penetration testing of Credential Data over Encrypted Channel

As part of user’s authentication penetration testing, it is must to pen test how credential data (sensitive data) is transported over an encrypted channel to avoid being intercepted by some malicious hackers via Man-in-the-Middle (MITM) type attacks. As we all know, just using https connection doesn’t mean that data transmission is completely safe. The security also depends of other parameters like encryption algorithm used and robustness of keys (public & private keys) used within.


If we are concerned about credential data penetration testing, then very first thing that comes in mind of every penetration tester is Login page of a website or web application. The very first thing a penetration tester has to ensure is, how data is being transmitted over network i.e. whether its using encrypted (https) or unencrypted (http) channel. Now lets consider the best case scenario, its using encrypted channel i.e. https connection. But before moving forward you must learn the basic difference between http and https connections. http protocol transfers data in a non-secure way, basically in clear text format while https encrypts data during transmission; hence encrypted data is transferred over channel.



We will learn penetration testing of credential data transfer over encrypted channel with help of multiple scenarios like sending data via post method through HTTP, sending data via post method through HTTPS, sending data via post method though HTTPS on a page which is also reachable by HTTP.

Note: We will be using WebScarab in this penetration testing tutorial.
Web Scarab

Scenario 1: Sending Data with Post Method over HTTP Channel

Consider an example, we have a login page which accepts fields like username and password and submit button to authenticate credentials in order to provide access to website or web application. If we explore this request with WebScarab, we will get something like below:

POST http://www.samplewebsite.com/AuthenticationPage HTTP/1.1
Host: www.samplewebsite.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14)
Accept: text/xml,application/xml,application/xhtml+xml
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.samplewebsite.com/login.php
Cookie: PHPSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!
Content-Type: application/x-www-form-urlencoded
Content-length: 64
delegated_service=1&User=test123&Pass=test123&Submit=SUBMIT


From above result, penetration tester can easily identify web application is sending data to Authentication page via Post method using HTTP channel. So the data is transmitting without any encryption and a hacker can easily capture it using simple sniffing tools like Wireshark over the network. Hence credentials are exposed in clear text format in case web application is sending data over HTTP channel.


Scenario 2: Sending data with Post method over HTTPS channel

Now suppose if above web application is using HTTPS protocol to encrypt the data we are sending over network. In this case, if we explore the header for login request using Webscarab tool, it will be something like below:


POST https://www.samplewebsite.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.samplewebsite.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14)
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.samplewebsite.com/cgi-bin/login.cgi
Cookie: language=English;
Content-Type: application/x-www-form-urlencoded
Content-length: 50
Command=Login&User=test123&Pass=test123


From above result from webscarab we can see that request is using HTTPS channel. This ensures that our credentials are sent using a encrypted channel and credentials cannot be read using sniffing. Again hacker will be able to get encrypted credentials but it will be hard to decrypt it and now everything depends upon encryption algorithm used to encrypt the credentials. So we have to ensure that we are using good encryption algorithm.

Scenario 3: Sending data with GET method via HTTPS

This method is always avoided as sensitive information is disclosed within the URL. So in this case hacker just needs to capture URL of victim which can be easily obtained via server logs, browser history, cookies etc. That’s the reason it’s always recommended to use a POST method for sensitive fields. But ironical thing is that, attacks like Man-in-the- Middle will be still hard to perform as data over channel is still encrypted. Beware!! Avoid using GET methods else you will end up getting hacked.

Scenario 4: Sending data with Post method via HTTPS but page is reachable by HTTP too

This is quite a bit wrong practice that most of webmasters are using, issue is that they have a website which is accessible using simple HTTP protocol but using HTTPS connection just for Login page. For example, a website which has some premium content which certain users can only see. If we inspect such website using webscarab, then it will look something like below:

POST http://www.samplewebsite.com/index.php
Host: http://www.samplewebsite.com/index.php
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.samplewebsite.com/index.php
Cookie: PHPSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F
Content-Type: application/x-www-form-urlencoded
Content-length: 45
User=test123&Pass=test123&portal=SampleWebsitePage


We can see that our request is www.samplewebsite.com:443/login.php using a HTTPS channel. But if we inspect at the referrer info, we can see that it’s coming from HTTP channel which is an insecure way. Although we are sending data via HTTPS, but it’s still vulnerable to SSL Strip attacks or Man-in-the-Middle attacks. We will learn more about SSL strip attacks in later articles.