FOO MEGA HOST

PENETRATION TEST REPORT

Contents
1
1 INTRODUCTION...........................................................................................3
1.1 SCOPE.....................................................................................................3
2 EXECUTIVE SUMMARY..................................................................................3
3 VULNERABILITY & REMEDATION REPORT........................................................4
3.1 SQL INJECTION........................................................................................4
3.2 CROSS-SITE SCRIPTING (XSS).................................................................11
3.3 UNRESTRICTED UPLOAD OF FILE..............................................................21
3.4 SECURITY MISCONFIGURATION................................................................28
3.5 USING COMPONENTS WITH KNOWN VULNERABILITIES................................32

1 INTRODUCTION
Subject of this document is summary of penetration test performed against web
applications owned by Foo Mega Host company. Test was conducted according to rules
2
of engagement defined and approved at the beginning by both parties – customer and
contractor. Black-box pentesting assignment was requested.

Black-box penetration test clasification means that penetration tester has no internal
knowlegde about target system architecture. He/she can use information commonly
available on the Internet. More data can be collected during reconnaissance phase
based on observation of target system behaviour. Black-box penetration test results
gives overview of vulnerabilities exploitable from outside the company network. It
shows how unathenticated actor can take advantage of weaknesses existing in tested
web application.

Time frame defined:

• penetration test start: xxxxxxx,

• penetration test end: xxxxxxxx.

1.1 SCOPE
Following subdomains were found during information gathering phase:

• m.foomegahost.com,

• me.foomegahost.com,

• fmh-intranetarea.foomegahost.com,

• www.foomegahost.com (alias of foomegahost.com)

2 EXECUTIVE SUMMARY
Conducted penetration test uncovered several security weaknesses present in web
applications owned by Foo Mega Host company.

Please create two-three charts😊

3
 3 VULNERABILITY & REMEDATION REPORT
Penetration test finding classification, description and recommendations mentioned in
the report are taken mostly from OWASP TOP 10 project documentation available on
site: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.

The OWASPT TOP 10 is list of definitions of web application vulnerabilities they pose
the most significante security risks to organization when exploited.

3.1 SQL INJECTION

Injection weaknesses occur when application sent untrusted input data to an
interpreter as part of a command or query. These flaws are usually a result of
insufficient input validation. The attacker’s hostile data can trick the interpreter into
executing unintended commands or accessing data without proper authorization.

Penetration test of Foo Mega Host web application uncovered existing of SQL injection
vulnerability. It makes possible for an attacker to execute malicious SQL statement. In
result intruder can bypass authentication and access control mechanism to get access
to entired database content, including users credentails (password hashes) and
sensitive data like personal identifiable information, intelectual property, company
secrets, etc.

Impact: High.

Affected targets:

• m.foomegahost.com,

• me.foomegahost.com,

• fmh-intranetarea.foomegahost.com,

• foomegahost.com.

4
3.1.1 EXPLOITATION

3.1.1.1 WSDL getTicketInfo operation m.foomegahost.com

First SQL injection is possible with parameter ticketID used by getTicketInfo
function available on m.foomegahost.com site. Test using always true condition
gives result of SQL syntax error message.

Input:

Output:

Request to be used during exploitation:

5
Command for sqlmap tool prepared to capture current database and user name:

Output with information useful to perform next steps. Current database name is
foomegahost. Unfortunately current user is not database administrator.

6
Collecting list of all tables in foomegahost database:

Database table user looks very interesting. Command useful to dump content of
user table:

7
There are user names and password hashes stored. Password of user test retrieved
by sqlmap:

Credentials work – successful logon on me.foomegahost.com:

Access to user's data:

SQL injection types detected by sqlmap:

8
3.1.1.2 User-Agent parameter on /include/get_visitor.php
Second SQL injection point is User-Agent parameter in header of GET request to
/include/get_visitor.php site. Two different results depends on true or false
question prove that User-Agent parameter is injectable. The same weakness exist on
foomegahost.com and all subdomains where get_visitor.php is used expect from
m.foomegahost.com (mobile version).

Request with true condition returns <!-- taken --> comment in response:

Request with false condition returns <!-- new one --> comment in response:

9
Exploitation with sqlmap tool:

Information about backend database version captured together with list of tables:

10
3.1.2 RECOMMENDATION

SQL injection flaws can be avoided by keeping user input seperate from backend
commands and queries. Develepers should follow general rules:

• stop writing dynamic queries;

• prevent user supplied input which contains malicious SQL from affecting the

logic of the executed query.

The preferred option is to use a safe API, which avoids the use of the interpreter
entirely or provides a parameterized interface, or migrate to use Object Relational
Mapping Tools (ORMs). Useful option is to add positive or "whitelist" server-side input
validation. For any residual dynamic queries, special characters should be escaped
with the specific escape syntax for that interpreter. SQL controls like LIMIT statement
can help to prevent mass disclosure of records in case of successful SQL injection.

3.2 CROSS-SITE SCRIPTING (XSS)

XSS is client-side code injection attack. XSS flaws occur whenever an application
includes untrusted data in a new web page without proper validation or escaping, or

11
updates an existing web page with user-supplied data using a browser API that can
create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s
browser which can hijack user sessions, deface or replace web sites, redirect the user
to malicious sites.

There are three types of cross-site scripting weakness:

• Stored XSS which allows to store unsanitaze user input – HTML or Java
Script code on web server. This input is displayed and executed by each web
site visitor or legitimate user. Stored XSS is the most dangerous form of
XSS, because malicious code is run when unaware user opens infected page.

• Reflected XSS can allow the attacker to execute arbitrary HTML and
JavaScript in the victim’s browser. Typically the user will need to interact
with some malicious link that points to an attacker-controlled page.

• DOM XSS affects JavaScript frameworks, single-page applications, and APIs

that dynamically include attacker-controllable data to a page.

Penetration test of Foo Mega Host uncovered that web application is vulnerable to
stored XSS and reflected XSS attacks.

Affected targets:

• me.foomegahost.com,

• fmh-intranetarea.foomegahost.com.
3.2.1 EXPLOITATION

3.2.1.1 Parameter message on /wall/savemessage.php

First XSS injection point vulnerable to stored XSS atack is message parameter sent
via POST /wall/savemessage.php request. Content of the message is saved on
me.foomegahost.com/wall.php site and then displayed or executed on daily wall.

Test news added with simple Java Script code:

12
Code executed after page reload – alert displayed in browser:

Adding rogue image via daily wall:

13
Code desinged to send out current session cookie is included into source code of
wall.php. It makes possible session hijacking.

The daily wall exists also on fmh-intranetarea.foomegahost.com page. For test

purposes another Java Script alert is displayed:

14
3.2.1.2 Parameter mcomment on /wall/savecomment.php

Second XSS injection point vulnerable to stored XSS atack is mcomment parameter
sent via POST /wall/savecomment.php request. Content of the comment is saved
as part of me.foomegahost.com/wall.php and displayed or executed by
/wall/viewajax.php.

15
Similar like in previous point, the same daily wall exists on intranet area and the same
vulnerability affects fmh-intranetarea.foomegahost.com.

HTML and Java Script code added as new comment is just displayed on wall.php page:

When visitor click on “View all X comment”, then /wall/viewajax.php runs:

This triggers execution of injected code:

16
17
 3.2.1.3 Form on me.foomegahost.com/support.php

Another XSS injection point is located in form used by Foo Mega Host customers to
report issues. Three from four form fields on me.foomegahost.com/support.php
page can be filled in with plain text. Fourth parameter category can be selected from
drop down list and is vulnerable to SQL injection. Data collected via form fields are
added to me.foomegahost.com/ticket.php site.

Simple test request in Burp Suite and result visible in web browser:

In result of test with another input new ticket is created successfully:

18
Injected code changes source of me.foomegahost/ticket.php:

19
3.2.1.4 Parameter e on me.foomegahost.com/error.php

Another XSS injection point is located on me.foomegahost.com/error.php page. It

is displayed in case of failed logon attempt to an admin account. Parameter e sent as
part of GET request is vulnerable to reflected XSS attack. URL encoded payload:

Human readable payload in URL and result of code execution:

20
3.2.2 RECOMMENDATION

Web application can avoid XSS attack when untrusted data coming from users is
separated from active browser content. This can be implemented with:

• frameworks that automatically escape XSS by desing;

• escaping untrusted HTTP request data based on the context in the HTML output
(body, attribute, JavaScript, CSS, or URL). This can prevent XSS stored and
reflected attacks;

• applying context-sensitive encoding when modifying the browser document on

the client side acts against DOM XSS. When this cannot be avoided, similar
context sensitive escaping techniques can be applied to browser APIs;

• enabling a Content Security Policy (CSP) is a defense-in-depth mitigating

control against XSS. It is effective if no other vulnerabilities exist that would
allow placing malicious code via local file includes.

3.3 UNRESTRICTED UPLOAD OF FILE

Unrestricted upload of file with dangerous type is weakness which allows any web
application user to upload file of potencially dangerous type. Due to unsufficient
restrictions the file can be not only saved on a server, but also processed by the
application. Arbitrary code execution is possible if an uploaded file is interpreted and
executed as code by the recipient. This is especially true for .asp and .php extensions
uploaded to web servers because these file types are often treated as automatically

21
executable, even when file system permissions do not specify execution. The
consequences of unrestricted file upload can vary, including complete system
takeover, an overloaded file system or database, forwarding attacks to back-end
systems, client-side attacks, or simple defacement. It depends on what the application
does with the uploaded file and especially where it is stored.

Penetration test of Foo Mega Host uncovered that there is a possibility to bypass file
extension verification and upload file which is not image, but *.php file.

Affected targets:

me.foomegahost.com.

3.3.1 EXPLOITATION

3.3.1.1 File upload on me.foomegahost.com/support.php

Foo Mega Host company shares posibility to register tickets and report issues via form
on me.foomegahost.com/support.php page. There image file can be uploaded and
attached to the ticket. Then ticket details with link to attached file are saved and
displayed on ticket.php page and in intranet are. Implemented client-side validation
based on white list is not sufficient to avoid uploading executable files. Web browser
checks extension of uploaded file only. Attacker can replace it using intercept proxy.

Webshell from Kali Linux used to prove it:

File copy with another name and extension changed temporarily:

22
File error.jpg selected from Support Form:

Request intercepted by Burp Suite – file extenstion change back to .php:

23
New ticket was created successufully. Link to uploaded file is also there:

After click into the link simple GUI of webshell is available:

24
Webshell helps to upload other files to dedicated directory on web application server:

Looking for information useful to extend attack surface using phpinfo():

25
Listing C:\inetpub\sitesdata\foomegahost.com\SESSIONS\USERS\INNER:

Names of sess_* file seems to include session ID.

Next step of the test checks this – current PHPSESSID in cookie is replaced by ID from
name of the file containing details of Administrator session. It works – after page
refresh there is authenticated session established:

26
Avatar on me.foomegahost.com/wall.php shows that current session belongs to
Delacruz Alec which has an admin role:

27
3.3.2 RECOMMENDATION

Risk rised by unrestricted file upload vulnerability can be mitigated or avoided.

Whitelisting or blacklisting solutions, Content-Type header validation, file type
detectors are usefull, but not sufficient. Especially if they are implemented only on
client-side. They have to be duplicated on the server-side.

Generic rules:

• All files should be thoroughly scanned and validated before being made

available to other users. If in doubt, the file should be discarded.

• Web server should be configured according to least privileged approach and

patched in timely manner.

• Uploaded files should be stored in directory without execute priviledge granted

and outside the web server root. Using an isolated server with a different
domain to serve the uploaded files can be considered.

• The file types allowed should be restricted to only those that are necessary for

business functionality.

• Minimum and maximum file sizes should be defined.

• Original user-supplied file name should be replaced buy random one.

• Files with double extension should not be accepted.

3.4 SECURITY MISCONFIGURATION

Security misconfiguration vulnerability occurs in case of:

• unnecesarry features enabled or installed;

• improper error handling (e.g. verbose error messages);

• security headers or directives not set up with recommended, secure values;

• uprotected files and directories.

Penetration test of Foo Mega Host uncovered following weaknesses:

28
 • users enumeration possibility due to overly informative error page;

• publicly available configuration file;

• HttpOnly cookie flag not set.

Impact: Low.

Affected targets:

• me.foomegahost.com,

• fmh-intranetarea.foomegahost.com,

• m.foomegahost.com.

3.4.1 EXPLOITATION

3.4.1.1 User enumeration possible on error.php

Different behaviour of web application can be observed after failed logon attempt to
me.foomegahost.com page. When ordinary user tries to logon with wrong
password, he/she is moved to home page. When user with administrator rights gives
incorrect password, then error.php page is displayed with information, that admin
area can be found in another place. This output makes possible to enumerate users
with administrator role.

29
3.4.1.2 Accessible service.wsdl file

WSDL is XML format describing network services. It contains definition of web service
operations and parameters used. Information included can be used by attacker to
perform operations which are not available from web application front-end or carry out
various attacks. m.foomegahost.com/ws/service.wsdl file is easly discovered.

30
3.4.1.3 Cookie flag HttpOnly not set

Flag HttpOnly set to true prevents from accessing to cookie values from Java Script
level. It is especially important in case of session cookies, because session ID value
cannot be read and send to intruder using scripts. This flag is not set on
me.foomegahost.com and fmh-intranetarea.foomegahost.com. In result session
cookie is accessible via Java Script and can be stolen.

31
3.4.2 RECOMMENDATION

Secure installation processes should be implemented:

▪ repeatable hardening process;

▪ final application platform without unnecessary components, features and

frameworks;

▪ sending security directives to clients (security headers, flags, etc.);

▪ protecting any log messages against beeing displayed to users; ▪

file access control rules.

3.5 USING COMPONENTS WITH KNOWN VULNERABILITIES

This occurs when application uses vulnerable, unsupported or out of date software. It
includes the OS, web/application server, database management system (DBMS),
applications, APIs and all components, runtime environments, and libraries. When
exist risk of exploitation of any component, there the same risk affects web
application.

32
Penetration test of Foo Mega Host uncovered that old version of operating system,
database management system and web server software is installed.

Impact: Medium.

Affected targets:

• foomegahost.com,

• m.foomegahost.com,

• fmh-intranetarea.foomegahost.com,

• me.foomegahost.com.

3.5.1 EXPLOITATION

3.5.2 RECOMMENDATION

Installing the latest versions of all software components being used by web application
helps to avoid attacks using known exploits accessible on the Internet. Also security
patches have to be installed regularly.

33