\documentclass[a4paper]{article}

\usepackage{IEEEtrantools}
\usepackage{numberedblock}

\newenvironment{vardesc}[1]{\settowidth{\parindent}{#1:\ }
														\makebox[0pt][r]{#1:\ }}{}

\title{Network Security Assignment}
\author{Mircea-Radu-Serban Dobrau}
\date{24 Jan 2019}

\begin{document}

\begin{titlepage}
	\vspace*{\stretch{1}}
	\begin{center}
		{\huge Network Security Assignment}\\[6.5ex]
		{\large Mircea-Radu-\c{S}erban Dobr\u{a}u}\\
		{P147987}\\
		\vspace{2ex}
		{M7X00671}\\
		{Dr. Carlene Campbell}\\
		\vfill
	\end{center}
	\vspace{\stretch{2}}
\end{titlepage}

\newpage

\tableofcontents
\newpage

\listoffigures
\newpage

\begin{abstract}

	An essential skill of a Network Security professional is the ability and
	knowledge of dealing with penetration scenarios in real life. Some of the
	important skills a professional penetration tester involve: keeping
	up-to-date with trends in the Information Technology field through
	continuous learning and training; keeping up with OS and software
	vulnerabilities, as well as  the patches required towards fixing them;
	having a knowledge of the true costs of security breaches and the true cost 
	of fixing them. This report represents an attempt at adequate penetration 
	testing knowledge. It is written to the effect of meeting the requirements 
	of the M7X00671 module content and learning outcome.

\end{abstract}

\newpage

\section{Introduction}

	The assignment requirements start with the assumption that the writer of the
	report has been assigned to conduct a real penetration test on the 
	tevelcyber.com domain. As such, the tasks provided towards the 
	accomplishment of this objective are the following:

	\begin{itemize}

		\item First of all, to conduct a penetration test of the ``black box'' type 
		on the tevelcyber.com domain.

		\item Next, to use the OWASP Top 10 framework as a starting point of 
		reference for the penetration testing process, as well as to freely use 
		and/or research any other types of vulnerabilities and attacks that may 
		prove useful during the penetration testing process.

		\item Finally, a technical report is to be written. This report's scope 
		is to detail the findings of the penetration testing process. 

	\end{itemize}
	
	The report is to comprise of details of the vulnerabilities found, as well 
	as an exploit methodology, Proof of Concept (PoC) and information required 
	towards the reproductiion and validation of each.

	Furthermore, Tevel Cyber Corps Private Limited provides a set of rules and 
	guidelines, which are briefly outlined below:

	\begin{itemize}

		\item Do not use found vulnerabilities with the scope of pivoting (for 
		example, towards finding other vulnerabilities).

		\item Do not engage in any form of malicious behaviour that would either:
		
		\begin{itemize}
		
			\item degrade the operation of the service (for example, a Denial of 
			Service attack); 

			\item result in sending of unsolicited or duplicative messages; or
			
			\item result in access and/or tampering of highly confidential data.

		\end{itemize}
		
	\end{itemize}

\section{Contingency plan}

	Several risks \cite[p.~3]{tiller2016ciso} may arise during the testing 
	process, which may be caused by the testing process itself or through someone 
	else's behaviour: outages, system or application faults, and/or accidental 
	destruction of information.  Furthermore, information leaks through the use 
	of questionable resources or methods during the penetration test are also 
	possible.  For this reason, a couple of steps will be taken towards 
	minimizing the risk of tampering with the company's data and/or accidentally 
	dealing damage onto the system/s:

	\begin{itemize}

		\item Do not use any tools which claim to have a chance of leaving any form 
		of negative impact, for example data-loss and information leak.

		\item If privileged access is to be gained anywhere, do not attempt to view
		or tamper with any data.

		\item If capable exploits are to be found, do not use them to \emph{pivot}
		towards finding new vulnerabilities and/or any form of information.

	\end{itemize}

	On the other hand, on the administrator's side, it is recommended to perform 
	backups of all important data and configuration settings found on the web 
	server as well as any other location which could be compromised during the 
	penetration test.

\section{Choice of penetration testing framework}

	For this penetration test process, part of the ISSAF 
	\cite[pp.~76-82]{wilhelm2013professional} framework has been selected as it 
	provides a strong introduction to the penetration testing process. The ISSAF 
	framework is divided into 3 phases:
	
	\begin{description}
	
		\item[Phase I] -- Planning and Preparation
		
		\item[Phase II] -- Assessment
		
		\item[Phase III] -- Reporting, Clean-up, and Destroy Artifacts
	
	\end{description}

	Furthermore, the \emph{OWASP Top 10} \cite[pp.~382-414]{posadas2016mastering} 
	framework will be used towards finding web application vulnerabilities. 
	The OWASP Top 10 framework presents a sorted list of the most common web 
	application vulnerabilities: 
	\begin{description}

		\item[A1] -- Injection
		\item[A2] -- Broken Authentication and Session Management
		\item[A3] -- Cross-Site Scripting (XSS)
		\item[A4] -- Insecure Direct Object References
		\item[A5] -- Security Misconfiguration
		\item[A6] -- Sensitive Data Exposure
		\item[A7] -- Missing Function Level Access Control
		\item[A8] -- Cross Site Request Forgery (CSRF)
		\item[A9] -- Using Known Vulnerable Components
		\item[A10] -- Unvalidated Redirects and Forwards

	\end{description}

	Finally, the report structure, as provided by the assignment requirements, 
	will be used towards the analysis and discussion of found vulnerabilities. 
	
	The following chapters will detail and analyse the findings of the 
	penetration testing process.

\section{Choice of penetration testing tools}

	The OS used during the penetration testing process is a custom-built, 64 bit, 
	XFCE-based Kali Linux distribution image installed locally onto an SSD drive. 
	The Linux kernel version is 4.19.13.

	As regards to the tools used during the penetration testing process, the 
	following were used:

	\begin{description}

		\item[Info gathering] -- dig, dmitry, dnsmap, dnsrecon, fierce, smtp-enum, 
		google hacking, host, nmap, automater, theharvester, urlcrazy, p0f, 0trace, 
		intrace, tracert, smtp-user-enum, swaks, ssldump, sslscan, sslyze, tlssled, 
		whois

		\item[Vulnerability analysis] -- hydra, nikto

		\item[Web application analysis] -- blindelephant, plecost, wpscan, dirb, 
		hydra, wfuzz, metasploit, OWASP ZAP, skipfish, whatweb, xsser 

	\end{description}

	If further analysis of the tools' output is desired, the results are to be 
	found in the attachment provided with the report. It is recommended to use 
	``less -R'' in case an output file's contents seem garbled. 

\section{Reconnaissance}

	\begin{description}

		\item[Domain] -- tevelcyber.com

		\item[Registrant name] -- Tevel Cyber Corps

		\item[Registrant organization] -- Tevel Cyber Corps Private Limited

		\item[Registrant country] -- India

		\item[Registrant phone] -- +91.9841756250

		\item[Registrant email] -- harish@tevelcyber.com

		\item[URL] -- https://www.tevelcyber.com

		\item[Web platform] -- WordPress 4.9.9

		\item[IP address] -- 192.185.39.52

		\item[Name servers] -- ns8201.hostgator.com, ns8202.hostgator.com

		\item[E-mail addresses] -- padma.r@tevelcyber.com, ram@tevelcyber.com, 
		karthick.s@tevelcyber.com 

		\item[Mail servers] -- alt1.aspmx.l.google.com, alt4.aspmx.l.google.com, 
		aspmx.l.google.com, alt2.aspmx.l.google.com, alt3.aspmx.l.google.com

		\item[Open ports] -- ftp, rsftp, domain, http, pop3, imap, https, smtps, 
		submission, imaps, pop3s, EtherNetIP-1, mysql, http-proxy, https-alt

		\item[Filtered ports] -- ssh, smtp, msrpc, netbios-san, microsoft-ds, 
		h323q931

		\item[OS details] -- DD-WRT v23 (Linux 2.4.36), MikroTik RouterOS 5.25 
		(Linux 2.6.35), Netgear ReadyNAS Duo NAS device (RAIDiator 4.1.4). 
		
		A ``nmap'' OS scan suggests that the device type of the system is 
		``WAP|router|storage-misc''. 
		
		Furthermore, a scan with the ``-sV'' flag reveals a CPE which identifies 
		the system as running RedHat Enterprise Linux 6.

	\end{description}
		
\section{SQL injection}

	\begin{description}
	
		\item[Attack tools involved] -- OWASP ZAP
	
		\item[Protocols involved in the attack] -- SQL, HTTP
	
		\item[Description] -- SQL is the language used for an application to
		communicate with its database. It can be used to read, write, delete, or 
		edit database entries (SELECT, INSERT, DELETE, UPDATE). To this purpose
		users issue \emph{SQL statements}.
	
		However, flaws in either the SQL interpreter or the way user input is
		validated can give attackers a method of compromising the database 
		through what are called \emph{SQL injection} attacks.
	
		For example, if a malicious user enters crafted input into the login page
		of a website, he/she could virtually enter any SQL statement, thus having
		the ability to read, edit, or delete the entire database. 
		\cite[pp.~178-179]{gibson2015sscp}
	
		\item[How the attack was launched] --
	
		\item[Success or failure] --
	
		\item[Solution] -- Upon finding this vulnerability, the OWASP ZAP 
		vulnerability scanner reports as follows:
	
		\begin{itemize}

			\item Do not trust client side input, even if there is client side 
			validation in place.
	
			\item In general, type check all data on the server side.
	
			\item If the application uses JDBC, use PreparedStatement or 
			CallableStatement, with parameters passed by '?'
	
			\item If the application uses ASP, use ADO Command Objects with strong 
			type checking and parameterized queries.
	
			\item If database Stored Procedures can be used, use them.
	
			\item Do *not* concatenate strings into queries in the stored procedure, 
			or use 'exec', 'exec immediate', or equivalent functionality!
	
			\item Do not create dynamic SQL queries using simple string 
			concatenation.
	
			\item Escape all data received from the client.
	
			\item Apply a 'whitelist' of allowed characters, or a 'blacklist' of 
			disallowed characters in user input.
	
			\item Apply the principle of least privilege by using the least 
			privileged database user possible.
	
			\item In particular, avoid using the 'sa' or 'db-owner' database users. 
			This does not eliminate SQL injection, but minimizes its impact.
	
			\item Grant the minimum database access that is necessary for the 
			application.	

		\end{itemize}

	\end{description}

\section{Session hijacking: session cookie without the ``HTTPOnly'' flag}

	\begin{description}

		\item[Attack tools involved] -- nikto
	
		\item[Protocols involved in the attack] -- HTTPS, HTTP
	
		\item[Description] -- The \emph{HTTPOnly} flag prevents JavaScript code 
		from accessing cookie data, whilst still allowing browsers to 
		automatically attach cookies to requests. \cite[p.~35]{manico2014iron} As 
		such, it prevents a cookie from being accessed via non-HTTP calls such as 
		JavaScript methods from third-party or custom applications. 
		\cite[p.~114]{goodey2013salesforce} 
		
		Without the \emph{HTTPOnly} flag, important cookies such as session cookies 
		can be read and tampered with using JavaScript, such as for example during 
		an XSS and CSRF attack. 
	
		\item[How the attack was launched] --
	
		\item[Success or failure] --
	
		\item[Solution] -- Ensure that all cookies or all cookies with sensitive 
		information have the ``HTTPOnly'' flag set.

	\end{description}

\section{Session hijacking: Session cookie without the ``secure'' flag}
 
 	\begin{description}

		\item[Attack tools involved] -- nikto
	
		\item[Protocols involved in the attack] -- HTTPS, HTTP
	
		\item[Description] -- The ``secure'' flag on a cookie tells 
		browsers to not submit cookies anywhere as the result of un-encrypted HTTP 
		connections.  As a result, cookies without the ``secure'' flag on are much 
		more liable to session hijacking or man-in-the-middle attacks if the client 
		chooses to transmit sensitive information e.g. session cookies using the 
		encryption-less HTTP protocol. \cite[p.~31]{lepofsky2014manager}
	
		\item[How the attack was launched] --
	
		\item[Success or failure] --
	
		\item[Solution] -- Ensure that all cookies or all cookies with sensitive 
		information have the ``secure'' flag set.

	\end{description}

\section{Authenticated race condition in WordPress plugin}

	\begin{description}

		\item[Attack tools involved] -- wpscan
	
		\item[Protocols involved in the attack] -- HTTP, HTTPS
	
		\item[Description] -- The WordPress scanning tool has detected an older 
		version of the Yoast SEO plugin (7.8, with the latest being 9.3). As such, 
		versions lower than 9.2 have been reported as being vulnerable of an 
		authenticated race condition. This vulnerability allows a SEO Manager to 
		execute commands on the server's underlying OS via a .zip file import 
		action. %\cite{CVE}
	
		\item[How the attack was launched] -- A proof of concept of the 
		vulnerability can be found at the following link: 
		https://www.youtube.com/watch?v=nL141dcDGCY
	
		\item[Success or failure] -- None
	
		\item[Solution] -- Update the existing Yoast SEO plugin to versions 9.2 and 
		higher.

	\end{description}

\section{Click-jacking: X-Frame-Options header is not present}

	\begin{description}

		\item[Attack tools involved] -- nikto
	
		\item[Protocols involved in the attack] -- HTTP, HTTPS
	
		\item[Description] -- Clickjacking \cite[p.~141]{wu2015web} is defined as a 
		technique through which the user is malicously deceived towards clicking 
		invisible elements or links found on a web-page. This function is made 
		possible with the help of the \emph{iframe} HTML element, which inserts a 
		second HTML document inside an already existing HTML document, as well as 
		CSS styling so as to make the malicious HTML document invisible to the 
		end-user.
	
		A standard method of dealing with clickjacking is by the use of the HTTP
		header ``X-Frame-Options``, which explicitly instructs the client browser 
		on how to deal with iframe elements inside web-pages. This header has not 
		been found inside of Tevel Cyber HTTP responses, thus leaving users to a 
		risk of clickjacking if iframe embedding is possible. [p. 156]
	
		\item[How the attack was launched] --
	
		\item[Success or failure] --
		\item[Solution] -- Define the ``X-Frame-Options'' header 
		\cite[p.~156]{wu2015web}, with the optional value being set to \emph{DENY}. 
		The \emph{DENY} will instruct the browser to refuse to load any iframes 
		found in web-pages retrieved from tevelcyber.com.
	
		Alternatively, if the use of iframes is necessary or desired (e.g. towards
		embedding documents from the same domain) set the optional value to
		``SAMEORIGIN''.

	\end{description}

\section{XSS: X-XSS-Protection header is not defined}

	\begin{description}

		\item[Attack tools involved] -- nikto
	
		\item[Protocols involved in the attack] -- HTTP, HTTPS
	
		\item[Description] -- The ``X-XSS-Protection'' response header can be
		found in the IE, Chrome and Safari web browsers. This header, once set, 
		helps these browsers stop pages from loading once they have been detected 
		as containing reflected cross-site scripting (XSS) attacks. \cite{MDN} 
		
		A reflected cross-site scripting attack is defined 
		\cite[p.~128]{hope2008web} as a malicious attack that makes use of the fact 
		that vulnerable web software ``reflects'' or re-executes code inputted by 
		the user. Thus, pages with malicious parameters or JavaScript code can be 
		crafted with the purpose of fooling users into running malicious code on 
		their browser.  

		As the X-XSS-Protection header is not defined on the Tevel Cyber website, 
		a malicious user could craft special links with a malicious purpose (e.g. 
		collecting the user's session cookie) and use it in a phishing attack.
	
		\item[How the attack was launched] --
	
		\item[Success or failure] --
	
		\item[Solution] -- Define the ``X-XSS-Protection'' header 
		\cite[p.~256]{heiderich2010web} with either of the following values:
	
		\begin{description}
	
			\item[1] Enables the cross-site scripting filter.
	
			\item[1; mode = block] Blocks the loading of the web-page as a whole if
			a cross-site scripting attack is detected.
	
		\end{description}

	\end{description}

\section{???: X-Content-Type-Options header is not set}

	\begin{description}

		\item[Attack tools involved] -- ???
	
		\item[Protocols involved in the attack] -- HTTP, HTTPS
	
		\item[Description] -- The ``X-Content-Type-Options`` response header 
		\cite[p.~14]{alcorn2014browser} combined with its' ``nosniff'' directive 
		has as its' purpose of telling the client's browser to not try to guess the 
		type of content received, and, subsequently, to not perform any specific 
		action that is mapped to that specific file-type automatically. Instead, 
		the content is interpreted by the browser in accordance to the content's 
		``content-type'' header.
	
		Without the implementation of this header and directive, the browser may be
		tricked into wrongly interpreting and acting upon a content's file-type. 
		For example, a seemingly-safe malicious JPEG image could get interpreted as 
		malicious JavaScript code.
	
		\item[How the attack was launched] --
	
		\item[Success or failure] --
	
		\item[Solution] -- Define the ``X-Content-Type-Options'' with the 
		``nosniff''	directive.

	\end{description}

\section{Session hijacking/man-in-the-middle: no HSTS support}
	
	\begin{description}

		\item[Attack tools involved] -- ???
	
		\item[Protocols involved in the attack] -- HTTP, HTTPS
	
		\item[Description] -- \emph{HTTP Strict Transport Security} (HSTS)% 
		\cite[pp.~145-147]{ristic2013bulletproof}[p. 145-147] is a security 
		mechanism which enforces users accessing a web-page to transmit data 
		through the more secure HTTPS protocol.  With HSTS, standard requests to a 
		HTTP web-page are first redirected towards their HTTPS equivalent. A secure 
		connection is then established.  Finally, the client web browser now 
		receives the HTTP ``Strict-Transport-Security'' header, which instructs the 
		client that the web-server is an HSTS host, as well as for how long the 
		browser should regard it as such with the help of the ``max-age'' value.
		
		This mechanism is enabled by defining the ``Strict-Transport-Security'' 
		response header. Next, the ``max-age'' value  specifies for how long since 
		the client's browser has received the initial HSTS response header should 
		it regard the host as an HSTS host. Finally, the ``includeSubDomains`` 
		directive tells the browser that HSTS should be applied to all of the 
		host's subdomains. 
	
		\item[How the attack was launched] --
	
		\item[Success or failure] --
	
		\item[Solution] -- Enforce an HSTS policy across the domain and all 
		subdomains by defining a ``Strict-Transport-Security`` header. The 
		response header can be defined as follows: 
		``Strict-Transport-Security: max-age=10000000; IncludeSubDomains''. 
		The ``max-age'' directive value in this case is of 10000000 seconds, which 
		roughly corresponds to 4 months. The ``IncludeSubDomains'' directive 
		enforces that the HSTS policy be applied to all of the host's subdomains.

	\end{description}

\section{Information disclosure: file disclosure}

	\begin{description}

		\item[Attack tools involved] --
	
		\item[Protocols involved in the attack] --
	
		\item[Description] -- OWASP ZAP reports that numerous file backups were 
		disclosed by the web server, with the ``.old'' and ``.bak'' extension 
		suffixed to them. Some of those files include ``wp-admin'', ``robots.txt'', 
		``admin-ajax.php'' and ``sitemap''. The total number of instances reported 
		is a significant number of 35. This information can be very useful to a 
		potential malicious user who desires to break into the system and learn 
		more sensitive information about the web server.
	
		\item[Solution] -- OWASP ZAP recommends to ``not edit files in-site on the 
		web server, and ensure that un-necessary files (including hidden files) are 
		removed from the web server.'' 

	\end{description}

\section{Information disclosure: WordPress adminstrative account}

	\begin{description}

		\item[Attack tools involved] --
	
		\item[Protocols involved in the attack] --
	
		\item[Description] -- The ``ramwptest'' WordPress administrative account 
		has been found through the use of a crawler tool. This presents a 
		significant issue as this eases a malicious user's attempt to enumerate 
		valid WordPress administrative accounts, as well as towards the attempt of 
		brute-forcing administrative access to the web-page through the WordPress 
		adminstrative log-in page, ``wp-login.php''. 
		
		Furthermore, after further investigation, the username discloses its owner: 
		Ramkumar Ramachandran.  This could aid towards a social engineering attack 
		and/or towards more useful information which could help the malicious user 
		construct a more successfull password word-list for wordlist-based password 
		attacks.
	
		\item[Solution] -- It is recommended, first of all, to change the username 
		to one that does not reveal any sensitive information, such as its owner. 
		Furthermore, a very strong password is recommended.

	\end{description}

\section{Information disclosure: web-page full-path disclosure}

	\begin{description}

		\item[Attack tools involved] --
	
		\item[Protocols involved in the attack] --
	
		\item[Description] -- A visit to the ``tevelcyber.com/wp-settings.php'' 
		web-page outputs an error which discloses potentially useful information: 
		it reveals that the Tevel Cyber web-page is hosted inside a user's ``home'' 
		folder with the name of ``kalakkad''.  This information is useful to an 
		attacker who wishes to enumrate valid Linux user accounts for further 
		exploitation and/or brute-forcing attempts.
	
		\item[Solution] -- Finally, it is recommended to disable the output of any 
		sensitive information whenever a web-page visit is erroneous. As a general 
		practice it is highly recommended \cite{hoffman2007ajax} to disable any 
		sort of debugging-related or informational output from applications across 
		the entire webapplication stack once a web application is in production 
		status.

	\end{description}

\section{Cost of solution} 

10 p per hour

50 hr pen test

j
about 3 days to 1 week for fixing sql


\section{Timetable for execution of solution}

	\begin{tabular}[CC]
		Process & Time required\
		Penetration testing & 45 hours\
		SQL Injection & 8 hours to 24 hours\
		Secure flags, WordPress plugin update, header customization, HSTS,
		file disclosure and web-page full-path disclosure & 8 hours\
	\end{tabular}
	
\section{Conclusion}

\newpage

\newpage

\bibliographystyle{IEEEtran}
\bibliography{IEEEabrv,db}

\end{document}
