Lab Report CIS 542
Week 6
Toolwire Lab 8: Performing an IT and Web Application Security Assessment
CIS/542
Instructor: Dr. Osama Morad
Lab Report file
Executive Summary
Well-informed organizations understand that their websites and applications are more than just an information service; they also represent the corporate image to their customers and the public. If a website or application has to be taken offline due to a security breach, this can result in loss of information, reputation, trust, and revenue. Ensuring the website or web application can dissuade most internet threats therefore, the organization can continue serving customers and not spend time and money reacting to a data loss or availability issues.
Overview
Internet-facing web applications, in particular, can create numerous opportunities for malicious individuals who may wish to compromise your organization’s data. To ensure a balanced level of preparedness and effective programming requires an understanding of risks Thoroughness is the key, as the undetected vulnerabilities could leave the organization most at risk.
Damn Vulnerable Web Application (DVWA) is a vulnerable web application used to be an aid for security professionals to test their skills and tools, and better understand the processes of securing web applications in a controlled environment.
This Web Application Security Assessment analyzes vulnerabilities found in the Damn Vulnerable Web Application (DVWA) as determined by the reports provided, and were assessed according to the OWASP guidelines. Recommendations outlined by the OWASP and Open SAMM models are provided to improve secure testing and coding of Web applications to prevent similar vulnerabilities such as these from happening in the future.
All security issues that are discovered must be mitigated based upon the following risk levels. which are based on the OWASP Risk Rating Methodology. Mitigation strategies will be required to fix any discovered issues of medium risk level or greater.
· High-Any high risk issue must be fixed immediately or other mitigation strategies must be put in place to limit exposure.
· Medium- Medium risk issues should be reviewed to determine what is required to
mitigate based on the number of issues or increase the risk to an unacceptable level. Issues should be fixed with mitigation strategies that will limit exposure.
· Low – Issue should be reviewed to determine what is required to correct the issue and scheduled accordingly.
Tools Used for Analysis
Dynamic analysis tools Skipfish, an active web application security reconnaissance tool and RATS, a rough auditing tool scan were used to identify vulnerabilities within the application.
Skipfish prepares an interactive sitemap for the targeted site by carrying out a recursive crawl and dictionary-based probes. The resulting map is then annotated with the output from a number of active security checks.
RATS, provides a security analyst with a list of potential trouble spots on which to focus, along with describing the problem, and potentially suggest remedies. This tool also performs a basic analysis to try to rule out conditions that are visibly not problems. The relative assessment makes available a reasonable starting point in which an auditor can prioritize the severity of each problem in order to perform manual security audits.
Items of Top Concern
The following lists below display vulnerabilities that were found on the Skipfish and RATS reports in the DVWA application. Vulnerabilities categorized in the below lists are in the application itself, and represent the risk to the organization. Information for each vulnerability will be identified as follows:
· Name of the issue, as described in the Skipfish or RATS reports
· Description of the issue
· Most likely causes of the vulnerability
· Possible remediation or prevention methods
Skipfish Report
High Risk Issue
Name – Shell injection vector
Description of the issue – Shell injection is generally considered one of the most dangerous vulnerabilities because it can be used to gain complete control over a target server. These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL (i.e., SQL injection). Any time a web application uses an interpreter of any type there is a danger of an injection attack. The most common places to find shell injection vulnerabilities is during loading of files and in the running of non-local web code.
Likely Causes of the vulnerability – Poor input validation. Injection flaws allow attackers to relay malicious code through a web application to another system. Whole scripts written in perl, python, and other languages can be injected into poorly designed web applications and executed. Any application that builds command strings using non-sanitized data is vulnerable to this bug.
Recommendation for mitigation – Avoid accessing external interpreters wherever possible. For many shell commands and some system calls, there are language specific libraries that perform the same functions. Using such libraries does not involve the operating system shell interpreter, therefore avoids a large number of problems with shell commands.
Applications defend against command injection bugs by doing proper input validation and sanitization. look for all instances where the application invokes a shell-like system function such as exec or system and avoid executing them unless the parameters have been properly validated and sanitized. There are two possible ways to validate these parameters: using black lists or using white lists.
Although server and OS hardening can help to limit the impact and make it harder for an attacker to escalate privileges, there is still significant risk.
Medium Risk Issues
Name – Directory traversal / file inclusion possible
Description of the issue – Directory traversal, also known as path traversal, ranks #13 on the CWE/SANS Top 25 Most Dangerous Software Errors. This type of exploit is when a server allows an attacker to read a file or directories outside of the normal web server directory. Local file inclusion allows an attacker the ability to include an arbitrary local file (from the web server) in the web server’s response.
The local file inclusion vulnerability is a process of including the local files available on the server. This vulnerability occurs when a user input contains the path to the file that has to be included. When such an input is not properly sanitized, the attacker may give some default file names and access unauthorized files, or an attacker may also make use of directory traversal characters and retrieve sensitive files available in other directories.
Both of these bugs can be used to read arbitrary files from the server. File inclusion possible comprises in misusing lacking security acceptance or disinfection of client supplied data document names, with the goal that characters speaking to “navigate to parent index” are gone through to the record APIs. The objective of this assault is to arrange an application to get to a PC record that is not planned to be available. This assault abuses an absence of security (the product is acting precisely as it should) instead of misusing a bug in the code (DuPaul, N., 2012).
Likely Causes of the vulnerability – the main cause for such vulnerabilities is improper filtering and validation of browser input from users.
Recommendation for mitigation – Input validation ensures that attackers cannot use commands that leave the root directory or violate other access privileges. Filters can be used to block URLs containing commands and escape codes that are commonly used by attackers. Additionally, any software that is used should be kept up-to-date with current patches. Regularly patching software is a critical practice for reducing security risk, as software patches typically contain security fixes.
Name – XSS vector via arbitrary URLS
Description of the issue – Cross-Site Scripting (XSS) vulnerability are amongst the most widespread exploited web application vulnerabilities on the Internet. A reflected assault is ordinarily conveyed by means of email or an impartial site. The draw is a pure looking URL, indicating a trusted site yet containing the XSS vector. On the off chance that the trusted site is helpless against the vector, tapping the connection can bring about the casualty’s program to execute the infused script.
Likely Causes of the vulnerability – Cross-Site Scripting (XSS) attacks are caused when data enters a Web application through an untrusted source, most frequently a web request. The data is included in dynamic content that is sent to a web user without being validated for malicious content.
Recommendation for mitigation – The primary defenses against XSS include using rigid permissions when developing and deploying web applications. Use chroot jails and code access security policies to restrict and control the location and type of file operations even if the system is misconfigured. Remove all “Everyone:Full Control” ACLs on Windows, and all mode 777 (world writeable directories) or mode 666 files (world writeable files) on Unix systems. Remove “Guest”, “everyone,” and world readable permissions wherever possible (OWASP, 2013).
Low Risk Issues
Name – External content embedded on a page
Description of the issue – External content embedded on a page means something isn’t right with the site – wrong – yet some way or another we appear to continue building sites that do. This can prompt issues, for example identity theft. You acknowledge that all the HTTP segments of the correspondence stay powerless hence you have to ensure against the SSL hostile to designs
Likely Causes of the vulnerability – Infected email
Recommendation for mitigation – Embed external content explicitly via the HTTPS scheme. If you’re only serving the page over HTTPS anyway then it ensures no problems. Using a protocol relative URL, means when the page is loaded over HTTP then the resource will be requested over HTTP. Load the page over HTTPS and the resource embeds over HTTPS.
The web view tag enables the ability to embed external web content in the web page. It replaces iframes that point to remote URLs. Unlike iframes, the web view tag runs in a separate process. This means that an exploit inside of it will still be isolated and won’t be able to gain elevated privileges. Further, since its storage (cookies, etc.) is isolated from the app, there is no way for the web content to access any of the app’s data.
Name – Incorrect or missing MIME type
Description of the issue – MIME Types tell programs what kind of record they are accepting from the site. A web page would normally tell programs they were getting http (MIME type content/html) while a PDF archive ought to have a PDF MIME type (application/pdf). Now and then, an application will send an inaccurate MIME type (like determining content rather than picture) or will send none by any means.
Likely Causes of the vulnerability –
Recommendation for Mitigation –Weigh the pages recorded in an output of your site for MIME Type strings. Guarantee they are serving the correct sort. You can likewise incorporate a neighborhood Apache setup document in every index to naturally set MIME type.
RATS Report
High Risk Issue
Name – Fopen()
Description of the issue – The fopen() function is a file open command used to open a file or URL and binds a named resource, specified by filename, to a stream. This function takes two arguments which are first argument is a pointer to a string containing name of the file to be opened while the second argument is the mode in which the file is to be opened.
It is in the programing language. If some problem in the core file of the Fopen command, then this command is not work properly. Problem like URL change or corrupted the core file. For prevention, we need to reconfigure or reinstall the core file.
Likely Causes of the vulnerability – A null pointer value indicates an error. Search permission is denied on a component of the path prefix, or the file exists and the permissions specified by mode are denied, or the file does not exist and write permission is denied for the parent directory of the file to be created. The named file is a directory and mode requires write access. A component of filename does not name an existing file or filename is an empty string.
Recommendation for mitigation – If settings are stored in an array, it can serialize() them and write to a text file.
Name – Eval
Description of the issue – The eval language build is exceptionally unsafe in light of the fact that it permits execution of discretionary PHP code. Its utilization in this manner is demoralized. On the off chance that you have painstakingly checked that there is no other choice than to utilize this develop, give careful consideration not to pass any client gave information into it without appropriately approving it already. For prevention, we need to reconfigure or reinstall the core file.
Likely Causes of the vulnerability – eval() returns NULL unless return is called in the evaluated code, in which case the value passed to return is returned. As of PHP 7, if there is a parse error in the evaluated code, eval() throws a ParseError exception. It is not possible to catch a parse error in eval() using set_error_handler().(PHP Group, 2016)
Medium Risk Issue
Name – is_writable
Description of the issue – This function checks the given file is writable or not. PHP has issues with Windows ACL’s for figure out whether a catalog is writable or not, this works around them by checking the capacity to open documents as opposed to depending upon PHP to interpreted the OS ACL. For prevention, we need to reconfigure or reinstall the core f.
Likely Causes of the vulnerability – The directory may not be writable if the directory is outside of the paths which PHP is able to write to because of open_basedir restrictions. The directory is on a drive which is mounted as read-only. The directory has immutable or appendonly attributes set. The filesystem is corrupt.
Recommendation for mitigation – Check the PHP error_log file to see if there are any more specific errors or warnings.
References
DuPaul, N. (2012). Directory Traversal. Retrieved from: http://www.veracode.com/security/directory-traversal
OWASP. (2013). Command Injection. Retrieved from: https://www.owasp.org/index.php/Command_Injection
Penn Computing. (2016). Injection Flaws (Shell Commands and SQL). Retrieved from: http://www.upenn.edu/computing/security/swat/SWAT_Top_Ten_A6.php
PHP Group. (2016). Eval. Retrieved from: http://php.net/manual/en/function.eval.php