Pentester's Mindset!

Get out of the limited OWASP TOP-10/SANS TOP-25/Bug Bounty mindset

by Ravikumar Paghdal - ravi at net-square.com, @_RaviRamesh
November 2019

TL;DR:

"Get out of the limited OWASP TOP-10/SANS TOP-25/Bug Bounty mindset". This paper discusses multiple case studies to convey the message that if you think limited, you will be limited. Bug bounty approach has degraded the quality of penetration testing, for both the customers as well as the practitioners. It is hard for the customer to differentiate between a good penetration testing and a quick and dirty top-10 or top-25 approach.
This paper will help those who have newly entered the infosec field and the bug bounty hunters.

Caution: This article can and will change the mindset and habit of typical pentester. Proceed with caution. This may give serious heartache to your feelings.

1. Introduction

કેમ છો? મજામાં. I'm Ravikumar Paghdal, currently working as a senior manager at Net Square Solutions Pvt. Ltd. In my past experience, I have reviewed hundreds of web/mobile application vulnerability assessment and penetration testing reports of multiple organizations and there is one thing that is always common in all the reports, guess what?

"The most common thing is the well-known vulnerabilities."

Yes, I’m talking about SQL injection, XSS, CSRF, IDOR, missing security headers, etc.

The shocking part is according to a survey conducted by HackerOne in 2019 "The survey and statistic of the ethical hacker community" ( page 39), more than 50% of BugBounty hunters are focusing on XSS and SQLi only.

MORE AND MORE HACKERS NAME XSS THEIR FAVORITE ATTACK VECTOR

When asked about their favorite attack vector, technique or method, over 38% of hackers surveyed said they prefer searching for cross-site scripting (XSS) vulnerabilities. That’s up from just 28% last year, and puts XSS significantly ahead of all other attack vector preferences. SQL injection placed second at 13.5%, while fuzzing, business logic, and information gathering rounded out the top five. In 2017, neither business logic nor information gathering placed in the top 10 last year.- "The survey and statistic of the ethical hacker community" ( page 38)

After giving sufficient time thinking about why these findings are most common in every security report. I finally concluded the answer and it is so simple.

"Because a security analyst or a penetration tester only focuses on well-known vulnerabilities."

From my experience, I can tell that this is the habitual behaviors or patterns of practice. This is what I have observed based on most of the analyst's testing mechanism or mindset towards testing, the basic strategy is to intercept HTTP request and inject single quotes ('), double quotes ("), greater than sign (>) and less than sign (<) to identify vulnerabilities.
While injecting those special characters, the mind of an analyst has a thought process that eventually leads to finding such as XSS and SQLi only ;)

I have always wondered about this strategy, why they do not inject characters like backtick (`), pipe (|), Null character (%00), Zalgo text (N̯̱̣͇̖̦̦̣ͥͮͩͪ̐͑͂̈̅ͦ͋̆̔͆̀̆̀̚̚̕ ), multibyte character (﷽, 𒐫), Carriage Return (ASCII 13, \r), Line Feed (ASCII 10, \n) or different characters, why??

Let’s understand the concept of pattern of practice in the most simple way.

Recall those days when you have started with your first ever web application testing or you can say your initial learning phase, during that time you had the practice to find common bugs like SQL Injection, XSS, CSRF, etc. But now we have grown and there are many new bugs in the market (according to Common Weakness Enumeration (CWE List version 3.4) the total number of software weaknesses is 808), so why do we focus only on common vulnerability?

I strongly believe that after reviewing the following case studies, you will be able to figure out what is wrong with the current mindset of pentester.

Let's take one HTTP request which contains two parameters 'uid' and 'pass'.

Now, if you know how to find vulnerabilities in a web application then provide an answer to few simple questions of mine.

Which part of the request is vulnerable?
Which vulnerability will affect the application and on which part?

The most common answer would be two parameters 'uid' and 'pass' or further someone will answer including cookie parameters '_a', '_b' and '_c' also. Right ??!!

Let's continue with following case studies to change your point of view about web app security testing.

2. Case Studies

In the below first five case studies, B is banking and financial services company. They use web server W, app server A, SQL database S, NoSQL database N, file server F, log servers L1(Oracle based DB) and L2 (linux machine) and domain controller server AD for authentication.

Keep one thing in your mind, in all following case studies; you only have a single login page on the client side for testing, the architecture is given for your understanding only, about possible server side operations. We have not covered Business logic vulnerability in the below case studies because it varies with different applications. So we will focus on technical vulnerabilities only.

2.1 A case study with typical web application architecture

We have been provided with a single page to perform blackbox testing on a banking application B, once we enter the userid and password then this two parameters 'uid' and 'pass' will traverse to the web server W and W will build dynamic SQL queries to retrieve user details from MySQL database S.

Steps involved:

Browser will send two parameters 'uid' and 'pass' to the web server W.
Web server W will receives parameter and build dynamic SQL query.
SQL Query will triger on database server S and provide desired output to web server W.

Our first request with 'uid' and 'pass' traverse the same way and it will build a dynamic SQL query. So our login page is affected by which vulnerability? SQL Injection right?!!

2.2 A case study with WebDAV enabled file server

Same as earlier, we have a single login page for testing but the database server is not implemented on server side. All the data is stored in file formate on the file server F. Once the parameters are received by the web server W, the web server will connect to the file server using WebDAV methods (PUT, PATCH, etc.) and those methods will update the user data. So in this case study; parameters are the same 'uid' and 'pass' but the vulnerability will differ.

Steps involved:

Browser will send two parameters 'uid' and 'pass' to the web server W.
Web server W will connect to the file server F using WebDAV methods.
File server F will perform file operation based on received WebDAV method.

In case study 2.2, you don’t have any control over server to server calls or methods so don’t think about PUT method exploit. You will only have control on two parameters 'uid' and 'pass' so think carefully, what can you do with this two parameters and which kind of vulnerability can you discover?

Here we have observed that user file name is created based on the user name and when the user will try to access the file then the file server will respond with user data from the file system, so what if you insert the following payload in 'uid' parameter.

uid=../../../../../../../../../../../../../../etc/passwd&pass=xyz

Yes, you are on the right path... there is a possibility of file path traversal vulnerability.

2.3 A case study with NoSQL database and XML processing

We have the same login page but the server architecture is changed this time, in this architecture web server's responsibility is to only receive parameters and convert them into XML formate and forward them to app server A.

App server A can only understand XML or JSON request. If app server A receives any request from the web server W then it will parse it into XML request and if the request is received from Android app AN then it will parse the request in JSON.

In-short all the business logic coded on app server A and DB server N is based on mongoDB . Once the app server receives an login request then it will process it and build dynamic queries and pass it on the DB server N. If app server receives a valid response from the DB server N, then it will pass the response to the web server W which will then build a HTML page.

Steps involved:

Browser will send two parameters 'uid' and 'pass' to the web server W and if you are using mobile application AN then it will send JSON request {uid:"<userid>",pass:"<password>"} to the app server A.
Web server W will receives parameter; convert them into XML formate and forward them to the app server A.
App server A will parse the request and make a login call to the Mongo DB server N.

In this case, our parameter value will be converted into XML request. Therefore, you can inject XML payloads in 'uid' and 'pass' parameters and then it will be parsed on the app server A. So the attacker can perform all the possible XML attacks like XML Injection, XXE, XInclude attack , XSLT injection and XPATH injection [if XPath queries are involved in this process.]

Another observation is that mongoDB does not accept any SQL statements. So you have to inject NoSQL statements and 'uid' is vulnerable to NoSQL Injection.

2.4 A case study with log server based vulnerabilities and exploitation

Again, we have the same login page with two parameters 'uid' and 'pass' also we have the same architecture as case study 2.3 but in addition to the above case study we have two log servers.

One log server L1 is based on ORACLE DB and the second log server L2 is based on linux command line process. Every single request received by the app server A will be copied and send to both log servers L1,L2 and then app server A will process the request.

Steps involved:

Browser will send two parameters 'uid' and 'pass' to the web server W and if you are using mobile application AN then it will send JSON request {uid:"<userid>",pass:"<password>"} to the app server A.
Web server W will receives parameter; convert them into XML formate and forward them to the app server A.
Every request received by the app server A will be copied and send to both log servers L1,L2. If app server A receives JSON request i.e. {uid:"ravi",pass:"P@ssw0rd"} then the app server will send this JSON to log server L1 and log server L2.

In log server L1, the request will be generated as following SQL query

INSERT INTO LOG_2019 VALUES('{uid:"ravi",pass:"P@ssw0rd"}');
INSERT INTO LOG_2019 VALUES('{uid:"ravi",pass:"Wr0ng_P@55w0rd"}');
INSERT INTO LOG_2019 VALUES('{uid:"admin",pass:"admin"}');
INSERT INTO LOG_2019 VALUES('{uid:"test",pass:"test@123"}');

In log server L2, the request will be generated as following command to append the request into the log file.

echo '{uid:"ravi",pass:"P@ssw0rd"}' >> LOG_2019.log
echo '{uid:"ravi",pass:"Wr0ng_P@55w0rd"}' >> LOG_2019.log
echo '{uid:"admin",pass:"admin"}' >> LOG_2019.log
echo '{uid:"test",pass:"test@123"}' >> LOG_2019.log

App server A will parse the request and make a login call to the Mongo DB server N.

In this case, all possible vulnerabilities are similar to case study 2.3, in addition our parameter's values are directly invoked in log servers request so the attacker can inject their payload in log process. So log server L1 is vulnerable to SQL Injection and Log server L2 is vulnerable to OS command injection.

Funny part is you can inject your payload anywhere in the JSON request which is not limited to parameter value only, because the whole JSON request will be logged into the log server. ☺

One more thing, if you observe the architecture deeply, all server-to-server communication is bi-directional but only the log server L1/L2 calls are in one/single direction. So if you want to identify this blind injection you need to know out-of-band techniques, how it works and you need to learn about BURP collaborator to detect this kind of hidden vulnerabilities [hidden because you can’t observe any errors or time delay in the response, you have to exploit this kind of vulnerabilities using OOB techniques].

2.5 A case study with LDAP protocol and JSON Web Token

Again we have the same login page with two parameters 'uid' and 'pass' and we have the same architecture as case study 2.4 but in addition to the above case study we have one authentication process to validate a user using LDAP protocol.

Once the app server A receives the login request, it will forward the request to active directory or domain controller AD to validate the user; based on windows authentication and this process is implemented using dynamic LDAP strings. If the user and password in the request is valid then the server AD will issue JSON Web Token (JWT) and further all authentication will take place using verifying JWT token.

Steps involved:

Browser will send two parameters 'uid' and 'pass' to the web server W and if you are using mobile application AN then it will send JSON request {uid:"<userid>",pass:"<password>"} to the app server A.
Web server W will receives parameter.
Web server W will convert them into XML formate and forward them to the app server A.
Every request received by the app server A will be copied and send to both log servers L1,L2.
App server A will build a dynamic LDAP query to validating a user id and password and forward request to active directory or domain controller AD to validate the user.
If user is valid then the AD server will issue JSON Web Token (JWT).
If user request have JWT token then app server A will parse the request and start data processing on the Mongo DB server N.

All possible attacks for this case study are similar as case study 2.4, in addition to LDAP Injection and possibility to JWT misconfiguration related issues.

2.6 Do not trust on HTTP headers - A case study with CVE-2019-5418

In this sceanrio, we will review some of the vulnerability discovered in HTTP headers.

CVE-2019-5418 : File Content Disclosure on Rails found by John Hawthorn

In this case, Accept HTTP header is vulnerable to file content disclosure.

The images below displays Referer HTTP header is vulnerable to SQL Injection.

So, my question for all the testers is, "how frequently do you check different vulnerabilities in such HTTP headers?".

2.7 Out of the Box testing or weird testing - a case study with CVE-2018-4124

CVE-2018-4124 జ్ఞా This Telugu Character Makes Apple iPhones Crash (Update: Bug Fixed with iOS 11.2.6)

Someone noticed that displaying a string written in India’s Telugu language (జ్ఞా) caused many apps on iOS and macOS to crash.

Apple became aware of the issue after news of the bug started to spread on social media networks and trolls and pranksters started exploiting it. One individual apparently showed how he could crash the Uber app on drivers’ phones by setting his name to the problematic string and then requesting a ride.

While initially only a certain Telugu string appeared use to work, some later noticed that a specific string using characters of India’s Bengali language also caused apps on iOS and macOS to crash. There are several theories on what may be causing the crash, including from Mozilla research engineer Manish Goregaokar and Philippe Verdy of the Unicode Consortium.

The company patched the flaw with the release of macOS High Sierra 10.13.3 Supplemental Update, iOS 11.2.6, watchOS 4.2.3 and tvOS 11.2.6.

Another case is Breaking Parser Logic - Take Your Path Normalization Off and Pop 0days Out by @orange_8361

	CVE
Spring Framework	CVE-2018-1271
Spark Framework	CVE-2018-9159
Jenkins	CVE-2018-1999002
Mojarra	CVE-2018-14371
Ruby on Rails	CVE-2018-3760
Sinatra	CVE-2018-7212
Next.js	CVE-2018-6184
resolve-path	CVE-2018-3732

So after one long and one short story !!

What do we learn as a pentester based on case study 2.7 Out of the Box testing or weird testing ?

Do not believe on any single unicode characters, you need to check your web server with all possible unicode. Right ??
You don't know which unicode will crash your server. ;)

To play more with unicode, you need to check Unraveling Unicode: A Bag of Tricks for Bug Hunting and Exploiting Unicode-enabled Software by Chris Weber.

It will always be a debate topic, Why Johnny Can’t Pentest: An Analysis of Black-box Web Vulnerability Scanners and automated vs manual testing. Scanner will do the same thing, set all injection points and schedule and fuzz with predefined payloads. Based on server response scanner will decide, there are vulnerabilities or not.

In many test cases, the automated scanner will fail, the following are a few examples.

We have sent one request for automated scanning and during scan the session is terminating.
During scan server respond slowly and rest of testing response will be delayed, scanner detect time based vulnerability ( false positive findings ).
Server throws error message which don’t have in scanner's signature DB.
Web pages contain those words which are listed in signature DB.
During scan - Server renews the session token.
New released vulnerability is not part of the scanner !!
Application URLs created in runtime are based on DOM or JS ...

Conclusion

In above all 5 case studies have one thing in common, it is the same login page with uid and pass parameter.

As Black Box Tester, we do not know about server side architecture and configuration. So you have to follow two statements during testing.

Each user controllable part of HTTP request is vulnerable to every possible vulnerability.
So think like an attacker and test like an attacker.

Attackers don't follow compliance standards and certifications. - Saumil Shah

Based on all the above 5 case studies, we have concluded that you can not judge vulnerabilities based on parameter's name, we have seen single flaw with two parameters uid and pass having possibility to exploit multiple vulnerabilities (SQLi, RCE, LDAPi, NoSQLi, XML attacks etc.) in the same application/request.

In case study 2.6, clearly mentioned that do not ignore HTTP headers either, it is as important as parameters.

You never know, in which request and in which process developer is involving HTTP header during coding of the application. So do not judge the headers blindly and conduct a proper pentesting.

In case study 2.7, we have learned that always do out of the box testing during pentest to discover more abnormal bugs (maybe even a 0 days).

Now, you have same HTTP request.

and you have same question.

Which part of the request is vulnerable?
Which vulnerability will affect the application and on which part?

You have your answer. Right?

Each corner of the request includes HTTP methods, Message Headers and all parameters are vulnerable to every possible vulnerability.

Even, we have reviewed few test cases when the automated scanner will fail. So you have to create such testing process or methodology to involve human mind in automated process, kind of mixed approach to reach a satisfactory level of your testing process.

"The biggest drawback for the pentester is a constant fear of ‘missing the vulnerability’ and lacks the enthusiasm of finding a zero day or performing weird testing due to deadline. We can always do smart work but if we miss out on zero day then that would be our biggest regret."

Ohh Yes!!. Last but not least, I have one last case study for you and you have to do it yourself.

Black Box - do it yourself.

Appendix A: Bibliography

Special Thanks

Saumil Shah
Hiren Shah
Jigar Soni
Aditya Modha

Pentester's Mindset!

Get out of the limited OWASP TOP-10/SANS TOP-25/Bug Bounty mindset

TL;DR:

1. Introduction

2. Case Studies

2.1 A case study with typical web application architecture

2.2 A case study with WebDAV enabled file server

2.3 A case study with NoSQL database and XML processing

2.4 A case study with log server based vulnerabilities and exploitation

2.5 A case study with LDAP protocol and JSON Web Token

2.6 Do not trust on HTTP headers - A case study with CVE-2019-5418

2.7 Out of the Box testing or weird testing - a case study with CVE-2018-4124

Conclusion

Black Box - do it yourself.

Appendix A: Bibliography

Tools/Code:

Articles/Blog posts:

Reference Documentation:

Exploits:

Conference Presentations:

Personal Mentions:

Special Thanks

EOF