-
Notifications
You must be signed in to change notification settings - Fork 1
/
question1.tex
131 lines (116 loc) · 7.1 KB
/
question1.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
\chapter{Question 1 - Web Application Pentest}
\section{Preparation}
In order to prepare for the web application pentest we sought out and installed
a number of intentionally vulnerable web applications, including BadStore
\cite{BadStore}, Damn Vulnerable Web App \cite{DamnVulnerableWebApp} and
HackThisSite \cite{HackThisSite}. A number of web application pentest tools are
available as part of the Kali distribution we elected to use, however a large
focus of our preparation was on SQL injection and hence we worked mainly with
sqlmap. For network sniffing and vulnerable path discovery both Nessus and nmap
were explored and utilised.
In order to better understand how SQL injection worked, we also researched
common SQL injection attacks and how to perform them manually (including blind
attacks and program version discovery methods). Additionally, most members of
our team had some working knowledge of how to use the web page inspection tools
offered by Chrome and Firefox, allowing us to easily inspect web pages to better
understand their inner workings and what requests are related to page requests.
\section{Given Information}
Pentest the web server that is hosted in the environment at www.synergise.cysca
\section{Question 1.1}
\textbf{Find the flag hidden in a secret document}
\subsection{Approach}
Although the question was (presumably intentionally) ambiguous in it's wording,
we guessed that it would be some sort of incorrect web server configuration,
allowing directory level browsing and hence detection of 'hidden' files. In
order to easily discover vulnerable ports and paths we ran a scan of the web
server with Nessus while we went and grabbed some lunch.
The scan took approximately 45 minutes to complete, and showed us that our
assumption was correct in that the web server allowed traversing through
directories. A quick manual search through available directories found a file
called secret.txt which contained the flag.
\subsection{Retrospective Approach}
We're confident that our approach was the optimal way to go about finding this
vulnerability. We could have instead acted on our assumption and begun looking
for directory paths manually or just scanned for them and nothing else but the
information from the Nessus scan was useful for many aspects of the competition
and if our assumption was wrong we could have wasted a lot of time better spent
elsewhere.
\section{Mitigation Question 1.1.1}
\textbf{What advice would you recommend to best mitigate information leakage?}
\subsection{Approach}
Our mitigation suggestion for this vulnerability was twofold; firstly, we pointed
out the Apache configuration parameter that was making directory listings
available (namely "Options + Indexes") as well as indicating the correct
setting, and secondly we suggested that they don't store secret files in a
publically accessible area such as a public-facing website.
\section{Question 1.2}
\textbf{Determine how to activate a new user without the web administrator's
verification. Log into the website with this user and retrieve the flag}
\subsection{Approach}
We began by reviewing the Nessus scan and manually snooping around the website
to find forms and HTTP endpoints that could possibly be vulnerable to SQL
injection. After compiling a list of endpoints, we ran scans using sqlmap and
sqlninja to try and find whether certain parameters were susceptible to
injection. We speculated that the user registration form was where the
vulnerability was most likely to be, but were unable to get sqlmap or sqlninja
to properly analyse this endpoint as it kept referring to the url as 'unstable'
because the page changed after sending requests to it.
An hour of trying various different combinations of parameters later, we
reverted to manual injection attempts, trying to extract some information from
the server in a blind attack fashion. After still failing to discover any
vulnerabilities we decided to move onto other flags, periodically returning to
this one. With less than one hour to go in the competition we returned to this
flag and found that submitting the registration form with an existing email
address stabilised the page.
Almost immediately after this we managed to get the server to output some
unescaped database errors and it was trivial to go from there to the actual SQL
injection which involved fake string completion and a premature query
terminator, saving a value of 1 instead of 0 into the authenticated field for
the user.
\subsection{Retrospective Approach}
This flag took far longer to retrieve than it should have, and most definitely
prevented us from completing the rest of the Web Application Pentesting
questions. Realistically, we should have tried to find a stable version of the
registration page for sqlmap much earlier than we did. Once we had some database
errors outputting onto the web page it was almost trivial to convert into a
successful injection.
Our problem lied in the fact that sqlmap was not sending a
valid value to the injectable parameter (phoneNumber) before any injection text.
This seemed to be a prerequisite for successful form submission and hence for
allowing our injection text to actually reach the database at all. Doing it
again, we would definitely put a real focus on trying to find a stable version
of any page that sqlmap reports as unstable. In most cases these pages are
requested via POST and are probably the most susceptible to injection.
\section{Mitigation Question 1.2.1}
\textbf{What advice would you recommend to best mitigate SQL Injection?}
\subsection{Approach}
The first and foremost way to prevent SQL injection is to perform server-side
sanitation of user input. The website provided had client-side sanitation of the
injectable field, but clearly performed no server-side sanitation to strip out
potentially malicious text from SQL queries. Most web frameworks provide some
family of SQL sanitation methods to simplify this process.
\section{Question 1.3}
\textbf{Retrieve the flag from the administrator's page}
\subsection{Approach}
As we completed question 1.2 at such a late stage in the competition, we did not
have very much time to complete question 1.3 (at most 15 minutes). There was a
web page requiring authentication (that we now had from Q1.2) that was used to
post news articles to the front page of the website.
This, combined with the information on the front page showing recent activity of
employees indicated to us that it was probably some form of Cross Site Request
Forgery (CSRF) attack, but unfortunately we did not have enough time to properly
explore this hypothesis. It was until we were given a list of the questions by
the other UQ team for the compilation of this report that our hypothesis was
validated.
\section{Mitigation Question 1.3.1}
\textbf{What advice would you recommend to best mitigate cross site request
forgery?}
\subsection{Approach}
Flag was never captured so we were not able to see or attempt this mitigation
question.
\section{Question 1.4}
\textbf{Retrieve the CEO's password hash}
\subsection{Approach}
As with question 1.3, this flag seemed to have all other questions in this
section as a prerequisite and consequently we were unable to attempt it before
the competition ended.