Web Management

Web Application Penetration Assessment

For

Texas Medical Center

December 13, 2010

Submitted to: Kevin LeonardTexas Medical Center

2450 Holcombe Boulevard, Suite 1Houston, Texas 77021-2040

Presented by: Baccam Consulting LLCTanya Baccam

PO Box 894Little Elm, TX 75068

Texas Medical Center – Web Application Penetration Assessment

Executive Summary ........................................................................................................................................ 3

Management Summary .................................................................................................................................. 5

Overview ...................................................................................................................................................... 5

Approach & Methodology .......................................................................................................................... 5 Phase I – Identification .......................................................................................................................... 5 Phase II – Vulnerability and Penetration Identification ......................................................................... 6 Phase III – Prioritization and Mitigation ................................................................................................ 9 Phase IV – Reporting ............................................................................................................................. 9

Observation Summary ............................................................................................................................... 10

Summary .................................................................................................................................................... 10

Detailed Results ............................................................................................................................................. 11

Detailed Observations ........................................................................................................................... 11 High Risk .......................................................................................................................................... 11

1) Persistent Cross Site Scripting Vulnerability .......................................................................... 11 2) Upload Capability should do Additional Filtering .................................................................. 17 3) Cross Site Request Forgery Vulnerabilities ............................................................................ 18 4) URLs Not Properly Restricted ................................................................................................ 23 5) Record Enumeration ................................................................................................................ 25

Medium Risk .................................................................................................................................... 31 1) Missing Secure Attribute in Encrypted Session (SSL) Cookie ............................................... 31 2) Password Reset Process should be Secured ............................................................................ 31

Low Risk .......................................................................................................................................... 33 1) HTTP Headers Reveal Unnecessary Information ................................................................... 33 2) Unnecessary Methods Supported ............................................................................................ 33

Baccam Consulting LLC Proprietary and Confidential Page 2


Executive SummaryBaccam Consulting was contracted during November and December 2010 to conduct a Web Application Penetration Assessment for the Contract Parking web application located at:

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/Login.as px

The engagement focused on identifying vulnerabilities related to the following categories:

• Authentication• Authorization• Session IDs• Element Manipulation vulnerabilities• Logical vulnerabilities• Sensitive information disclosure• Anti-automation and/or anti-spam controls• Encryption controls

Initially, a number of scans were conducted to identify vulnerabilities. It should be noted that the scans themselves, did not identify a large number of vulnerabilities. Instead, only potential items were identified, and low risk vulnerabilities enumerated. The high risk vulnerabilities identified throughout this report were found primarily by manually testing. This means, it will take a more skilled attacker to find and understand the vulnerabilities, versus an attacker that is simply using a tool. However, given this manually testing, a number of high risk vulnerabilities were identified. The following is a listing of the vulnerabilities at a high level. Each vulnerability identified is described in more detail throughout this report, including details on how the vulnerability was exploited.

• User input is not being properly filtering.• Users can be impersonated via vulnerabilities within the application. • Users can be manipulated into making requests they did not intend to make,

thereby manipulated account information.• Records can be enumerated by users who should not have access to the records.• URLs are not being properly restricted to the appropriate users.• Data is not being properly encrypted.• The password reset process is not secure.• Unnecessary information is being provided by the application.• Unnecessary functionality is being supported by the application which broadens

the attack surface.

While extensive steps were taken to identify all reasonably exploitable vulnerabilities, it should be noted that with additional manual testing, there is a possibility that more


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/Login.aspx



vulnerabilities do exist. However, given the fact that the web application firewall was in place throughout the engagement, this can make it very time consuming to identify additional vulnerabilities. Even without the web application firewall, vulnerabilities that are identified manually, can take a significant period of time to find. Of course, this also means it will be more difficult for a true attacker.

Overall, while there were a number of good security practices identified, there is also an overall weakness in the coding practices for the application. It was apparent that some of the security risks have not been addressed within the application. This may also mean that the risks are not understood. Therefore, it is also important that Texas Medical Center ensure that each developer is aware of and understands the types of vulnerabilities that can exist, as well as how to protect from the vulnerabilities.



Management Summary

OverviewBaccam Consulting was contracted during November and December 2010 to conduct a Web Application Penetration Assessment for the Contract Parking web application located at:


Throughout this report, additional details will be provided related to the vulnerabilities that were identified for the application.

Approach & Methodology Following is a summary of the methodology that is followed for penetration assessment engagements conducted by Baccam Consulting. In order to address each of the phases highlighted below, Baccam Consulting deployed the following approach and methodology. Our approach has been tailored to meet your specific needs while being built on a proven methodology. Our methodology is built in such a way that future engagements can also build on the information obtained in this assessment.

Phase I – Identification The identification phase focuses on gathering information about the systems in the environment, as well as how they are configured. In this case, the technical configuration of the systems was assessed. Using tools such as network mapping tools and port scanning tools, Baccam Consulting seeks to obtain a snapshot of the environment at the





current point in time. Some of the specific steps we will execute include:

• Using port scanning software to identify any open ports or services on devices or servers reachable via the Internet.

• Connecting to open ports using TCP or UDP network utilities to determine the operating systems, applications and network service versions in use.

• Search the web site to understand the business flow and possible vulnerabilities for the applications.

The following are examples of the types of technical tools that can be utilized to complete this process:

• Hping/Nemesis: network probing utilities which assemble and send custom ICMP/UDP/TCP packets.

• Netcat: an all purpose tools which is a simple utility that reads and writes data across network connections using either the TCP or UDP protocol.

• Nmap: a tool that allows you to identify the ports that are open on a remote machine, as well as the services running on those ports. Additional capabilities such as operating system identification and reconnaissance can also be conducted.

• Sam Spade: provides tools such as ping, nslookup, whois, dig, traceroute, finger, raw HTTP web browser, DNS zone transfer, SMTP relay check, website search, and more.

• Web browsers: tools used to identify the flow of a web application, as well as review the source code for the application.

Phase II – Vulnerability and Penetration Identification The purpose of this phase is to identify network services, operating systems, applications and functionality for the systems reviewed in ‘Phase I’, and target potential threats, vulnerabilities and exploitation avenues. As we identify information about the systems, we cross-reference the information with known vulnerabilities, current and past attacks. This phase includes executing multiple automated vulnerability scanning tools that check over 1000 potential vulnerabilities, utilizing proprietary scripts that identify potential weaknesses, and attempting exploitation as requested to verify vulnerabilities.

The following areas are reviewed for each of the web applications in scope:

• Authentication• Authorization• Session Analysis• Element Manipulation vulnerabilities• Logical vulnerabilities• Sensitive information disclosure • Anti-automation and/or anti-spam controls• Encryption controls



Baccam Consulting performs the following types of tasks:

• Identify points of exposure for the applications. • Scan systems identified in Phase I. • Perform a vulnerability and penetration analysis, evaluating the vulnerabilities

and risks associated with the discovered systems and services. Common web application vulnerabilities that are tested for include, but are not limited to:

o SQL Injectiono Blind SQL Injectiono Cross Site scriptingo Cross Site Request Forgeryo HTTP Response Splittingo LDAP Injectiono Log Injectiono RFI vulnerabilitieso Command injectiono Buffer overflowso XPath injectiono XML injectiono And more…

Baccam Consulting attempts to determine configuration details about identified devices and may attempt insertion attacks, transmission of unexpected data or man-in-the-middle attacks in order to determine system vulnerabilities. Baccam Consulting may use multiple creative methods to discover authentication data. In addition, Baccam Consulting will look for devices that may be misconfigured or supplied with vendor default settings that might provide access. Application specific vulnerabilities are also identified based on the specific web sites being assessed.

Baccam Consulting utilizes dozens of different security tools. The following categories of tools are often used by Baccam Consulting during an assessment. These tools may or may not be used during a given assessment depending on the scope and the state of the systems.

• Port Scanners: Tools that scans hosts or network components for open or active ports that could be used as avenues for unauthorized access. This includes multiple different types of scans including TCP Connect scans, SYN scans, FIN scans and other packet modification scans.

• Network Sniffers: Tools utilized to passively monitor networks and potentially gain confidential system data.

• Password Crackers: Tools that can be used to execute an attack against encrypted passwords and password files.

• Session Hijacking Utilities: Tools utilized to take control of current network connections.

• IP/MAC Spoofing Utilities: Tools utilized to spoof or “pretend” to be a legitimate



host in order to gain access to an unauthorized system. • Vulnerability Scanners: Tools that can identify system and network

vulnerabilities.• OS Diagnostic Tools: Tools that evaluate operating system security such as user

and group security, file access, password requirements, domain structure, startup files, system auditing and trust relationship.

• Proprietary Scripts: Scripts developed by Baccam Consulting to identify and potentially exploit vulnerabilities. Generally, these scripts are utilized to decrease time requirements for the engagement.

The following are samples of tools used during assessment engagements conducted by Baccam Consulting:

• Grendel-scan and W3AF: web assessment tools. They provide a way of reviewing a web application by looking for knows vulnerabilities, and mis-configurations that would allow unauthorized web application use. It targets the following types of vulnerabilities:

o SQL Injection o Hidden Field Manipulation o Parameter Tampering o Stealth Commanding o Forceful Browsing o Backdoors and Debug Options o Cookie Poisoning o 3rd Party Mis-configurations o Cross-Site Scripting o Cross Site Request Forgeryo Buffer Overflow o HTTP Attacks o Suspicious content o Known Vulnerabilities (associated with CVEs)

• Brutus/Hydra: utility for brute forcing multiple protocols. • Burp Proxy/Paros/WebScarab: web application security audit tool that sets up as a

proxy to decrypt SSL sessions into plain text looking for vulnerable hidden data and fields. Manipulation of HTTP communication can allow an attacker to leverage multiple attacks including hijacking sessions, manipulating pricing information and retrieving confidential information, as well as other possibilities.

• Cain and Abel/Dsniff/Ettercap: tools that allow you to sniff in a switchedenvironment, as well as providing other capabilities.

• Wire Shark/Tcpdump/Windump: sniffers that allow you to monitor network traffic.

• Fragroute/Fragrouter: tools that intercept, modify, and rewrite egress traffic in order to send fragmented communication.

• HTTrack/wget/Website Extractor/WebCopier: Web Mirroring software utilized to analysis an entire web site offline.

• John the Ripper/Crack/Cain: password cracking tools that allow you to discover



passwords based on password hashes for Windows or UNIX systems.• Nessus: a number of vulnerability scanners will be used to search for system and

network vulnerabilities. • Nikto/N-Stalker: a number of tools will be used to test for CGI based

vulnerabilities, if applicable. • Spike Proxy: HTTP proxy for finding security flaws in web sites. • Web Proxy: A web commercial grade web application assessment tool which uses

proxy techniques to capture, analyze and manipulate information passed between a browser and web server.

Baccam Consulting attempts to take the process of assessing vulnerabilities one-step further by verifying potential exploitation avenues, as well as identifying the root cause behind system vulnerabilities. Without verifying vulnerabilities, multiple false positives could be reported which makes the reporting results less valuable. By identifying the root cause, mitigating steps can be taken to address the vulnerabilities, as well as numerous other potential vulnerabilities.

Phase III – Prioritization and Mitigation Once the vulnerabilities are identified, the vulnerabilities must be prioritized. Without proper prioritization, Texas Medical Center may not spend dollars in the most cost productive manor. It is Baccam Consulting’s goal to highlight the vulnerabilities that will bring the most value and benefit to Texas Medical Center when they are addressed.

Multiple factors are considered for each system and the data it contains when prioritization occurs. Areas such as the role, criticality and sensitivity are considered. When considering the adverse impact of a security event, Baccam Consulting considers threats that impact the loss of integrity, loss of availability and loss of confidentiality.

It may not be practical to address all identified vulnerabilities and therefore priority must be given to the vulnerabilities that have the potential to cause the most significant harm to mission critical systems. The mitigating steps also provide the controls necessary to maintain a risk level that is acceptable to Texas Medical Center.

Phase IV – Reporting Baccam Consulting identified the vulnerabilities discovered and communicates them to you in a detailed report, which includes an executive summary. This provides upper management, as well as the individuals tasked with addressing the risks the information they need to implement mitigating controls. Texas Medical Center can also use the information provided in future assessments as a basis to build from. By continuing the security assessment cycle, Texas Medical Center can get a quick snapshot of the areas where the risk level may have increased at a later date therefore identifying risk quickly before it gets out of hand. The final report will be provided to Texas Medical Center within five business days of completing all information gathering and fieldwork.



Observation SummaryFollowing the methodology highlighted above, Baccam Consulting conducted testing, and the following vulnerabilities were identified. More information about each of these vulnerabilities, including information on how to remediate the vulnerabilities, can be obtained by going to the ‘Detailed Results’ section of this report.

• High Risko Persistent Cross Site Scripting Vulnerabilitieso Upload Capability should do Additional Filteringo Cross Site Request Forgery Vulnerabilitieso URLs Not Properly Restrictedo Record Enumeration

• Medium Risko Missing Secure Attribute in Encrypted Session (SSL) Cookieo Password Reset Process should be Secured

• Low Risko HTTP Headers Reveal Unnecessary Informationo Unnecessary Methods Supported

SummaryOverall, while there were a number of good security practices identified, there is also an overall weakness in the coding practices for the application. It was apparent that some of the security risks have not been addressed within the application. Therefore, it is also important that Texas Medical Center ensure that each developer is aware of and understands the types of vulnerabilities that can exist, as well as how to protect from the vulnerabilities.



Detailed Results

Detailed Observations

High Risk

1) Persistent Cross Site Scripting Vulnerability

Summary

A Cross-Site Scripting vulnerability was identified within the upload capability of the application.

Detailed Description

Cross-Site Scripting occurs when dynamically generated web pages display user input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site. In this instance, the web application was vulnerable to an automatic payload, meaning the user simply has to visit a page to make the malicious scripts execute. If successful, Cross-Site Scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. Recommendations include implementing secure programming techniques that ensure proper filtration of user-supplied data, and encoding all user supplied data to prevent inserted scripts being sent to end users in a format that can be executed.

XSS can generally be subdivided into two categories: stored and reflected attacks. The main difference between the two is in how the payload arrives at the server. Stored attacks are just that...in some form stored on the target server, such as in a database, or via a submission to a bulletin board or visitor log. The victim will retrieve and execute the attack code in his browser when a request is made for the stored information. Reflected attacks, on the other hand, come from somewhere else. This happens when user input from a web client is immediately included via server-side scripts in a dynamically generated web page. Via some social engineering, an attacker can trick a victim, such as through a malicious link or "rigged" form, to submit information which will be altered to include attack code and then sent to the legitimate server. The injected code is then reflected back to the user's browser which executes it because it came from a trusted server. The implication of each kind of attack is the same.

The main problems associated with successful Cross-Site Scripting attacks are:

• Account hijacking - An attacker can hijack the user's session before the session cookie expires and take actions with the privileges of the user who accessed the URL, such as issuing database queries and viewing the results.



• Malicious script execution - Users can unknowingly execute JavaScript, VBScript, ActiveX, HTML, or even Flash content that has been inserted into a dynamically generated page by an attacker.

• Worm propagation - With Ajax applications, XSS can propagate somewhat like a virus. The XSS payload can autonomously inject itself into pages, and easily re-inject the same host with more XSS, all of which can be done with no hard refresh. Thus, XSS can send multiple requests using complex HTTP methods to propagate itself invisibly to the user.

• Information theft - Via redirection and fake sites, attackers can connect users to a malicious server of the attacker's choice and capture any information entered by the user.

• Denial of Service - Often by utilizing malformed display requests on sites that contain a Cross-Site Scripting vulnerability, attackers can cause a denial of service condition to occur by causing the host site to query itself repeatedly .

• Browser Redirection - On certain types of sites that use frames, a user can be made to think that he is in fact on the original site when he has been redirected to a malicious one, since the URL in the browser's address bar will remains the same. This is because the entire page isn't being redirected, just the frame in which the JavaScript is being executed.

• Compromise end user system - An attacker can potentially take control of a user’s system.

• Manipulation of user settings - Attackers can change user settings for nefarious purposes.

Following is an example of exploiting this vulnerability by creating a script that created a “pop up” box. A script was passed to the application via an uploaded .csv file. Since the file was purposely created with errors, the file was not uploaded, and instead served back to the users of the application under the ‘Upload Failure list’.



It should be noted that in this case, the vulnerability was confirmed by executing a script that created a pop up box. The script that was added to a field in the .csv file was:

<SCRIPT>alert("Baccam Consulting Pen Test for XSS")</SCRIPT>

However, in a true attack situation, an attacker could upload any number of scripts for multiple reasons as noted above.

References

• SPI Dynamics Cross-Site Scripting Whitepaper - http://www.spidynamics.com/spilabs/education/whitepapers/CrossSiteScripting.html

• OWASP Cross-Site Scripting Information - http://www.owasp.org/documentation/topten/a4.html

• Microsoft - http://support.microsoft.com/default.aspx?scid=kb;EN-US;q252985• Microsoft Anti-Cross-Site Scripting Library V1.0 -

http://www.microsoft.com/downloads/details.aspx?familyid=9a2b9c9 2-7ad9-496c-9a89-af08de2e5982&displaylang=en

• CERT - http://www.cert.org/advisories/CA-2000-02.html • Apache - http://httpd.apache.org/info/css-security/apache_specific.html


http://httpd.apache.org/info/css-security/apache_specific.html

http://www.cert.org/advisories/CA-2000-02.html


• Netscape - http://channels.netscape.com/ns/browsers/security.jsp • SecurityFocus.com - http://www.securityfocus.com/infocus/1768

Solution

For Development:Cross-Site Scripting attacks can be avoided by carefully validating all input, and properly encoding all output. Validation can be done using standard ASP.NET Validation controls, or directly in your code. Always use as strict a pattern as you can possibly allow.

Encoding of output ensures that any scriptable content is properly encoded for HTML before being sent to the client. This is done with the function HttpUtility.HtmlEncode, as shown in the following Label control sample:

Label2.Text = HttpUtility.HtmlEncode(input)

Be sure to consider all paths that user input takes through your application. For instance, if data is entered by the user, stored in a database, and then redisplayed later, you must make sure it is properly encoded each time it is retrieved. If you must allow free-format text input, such as in a message board, and you wish to allow some HTML formatting to be used, you can handle this safely by explicitly allowing only a small list of safe tags. Here are examples of how to do this safely:

C# Example:

StringBuilder sb = new StringBuilder( HttpUtility.HtmlEncode(input)); sb.Replace("<b>", "<b>"); sb.Replace("</b>", "<b>"); sb.Replace("<i>", "<i>"); sb.Replace("</i>", "</i>"); Response.Write(sb.ToString());

VB.NET Example:

Dim sb As StringBuilder = New StringBuilder( _ HttpUtility.HtmlEncode(input)) sb.Replace("<b>", "<b>") sb.Replace("</b>", "<b>") sb.Replace("<i>", "<i>") sb.Replace("</i>", "</i>") Response.Write(sb.ToString())

Java Example:

public static String HTMLEncode(String aTagFragment){ final StringBuffer result = new StringBuffer();


http://www.securityfocus.com/infocus/1768

http://channels.netscape.com/ns/browsers/security.jsp


final StringCharacterIterator iterator = new StringCharacterIterator(aTagFragment); char character = iterator.current(); while (character != StringCharacterIterator.DONE ){ if (character = = '<') { result.append("<"); } else if (character = = '>') { result.append(">"); } else if (character = = '\"') { result.append("""); } else if (character = = '\") { result.append("'"); } else if (character = = '\\') { result.append("\"); } else if (character = = '&') { result.append("&"); } else { //the char is not a special one //add it to the result as is result.append(character); } character = iterator.next(); } return result.toString(); }

The following recommendations will help you build web applications capable of withstanding Cross-Site Scripting attacks.

• Define what is allowed. Ensure that the web application validates all input parameters (cookies, headers, query strings, forms, hidden fields, etc.) against a stringent definition of expected results.

• Check the responses from POST and GET requests to ensure what is being returned is what is expected, and is valid.

• Remove conflicting characters, brackets, and single and double quotes from user input by encoding user supplied data. This will prevent inserted scripts from being sent to end users in a form that can be executed.

• Whenever possible, limit all client-supplied data to alphanumeric data. Using this filtering scheme, if a user entered " <script>alertdocumentcookie( 'aaa') </script>", it would be reduced to "scriptalertdocumentcookiescript". If non-alphanumeric characters must be used, encode them as HTML entities before



using them in an HTTP response, so that they cannot be used to modify the structure of the HTML document.

• Use two-factor customer authentication mechanisms as opposed to single-factor authentication.

• Verify the origin of scripts before you modify or utilize them. • Do not implicitly trust any script given to you by others (whether downloaded

from the web, or given to you by an acquaintance) for use in your own code. • Most server side scripting languages provide built in methods to convert the value

of the input variable into correct, non-interpretable HTML. These should be used to sanitize all input before displayed to the client.

PHP: string htmlspecialchars (string string [, int quote_style])

ASP / ASP.NET: Server.HTMLEncode (strHTML String)

For Security Operations:

Server-side encoding, where all dynamic content is first sent through an encoding function where Scripting tags will be replaced with codes in the selected character set, can help to prevent Cross-Site Scripting attacks. The drawback to server-side encoding is that it can be resource intensive, and may have a negative performance impact on some web servers.

If site users must be allowed to use HTML tags, such as a bulletin board where the user would be allowed to use formatting tags, limit the ones that can be used. Create a list of acceptable tags, such as bold, italic or underline, and only allow those to be used. Any other tags should be rejected. Below are a few regular expressions that will help detect Cross-Site Scripting.

Regex for a simple CSS attack: /((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/ix

The above regular expression would be added into a new Snort rule as follows:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII Cross-Site Scripting attempt"; flow:to_server,established; pcre:"/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i"; classtype:Web-application-attack; sid:9000; rev:5;)

Paranoid regex for CSS attacks:/((\%3C)|<)[^\n]+((\%3E)|>)/I

This signature simply looks for the opening HTML tag, and its hex equivalent, followed by one or more characters other than the new line, and then followed by the closing tag or its hex equivalent. This may end up giving a few false positives depending upon how your Web application and Web server are structured, but it is guaranteed to catch anything that even remotely resembles a Cross-Site Scripting attack. From a public



perspective, you can also strengthen educational programs to help consumers avoid online scams, such as phishing, that can be utilized in account hijackings and other forms of identity theft.

For QA:

Fixes for Cross-Site Scripting defects will ultimately require code based fixes. The steps detailed in the Developer and Security Operations section will provide any developer with the information necessary to remediate these issues. The following steps outline how to manually test an application for Cross-Site Scripting.

• Step 1. Open any Web site in a browser, and look for places on the site that accept user input such as a search form or some kind of login page. Enter the word test in the search box and send this to the Web server.

• Step 2. Look for the Web server to respond back with a page similar to something like "Your search for 'test' did not find any items" or "Invalid login test." If the word "test" appears in the results page, you are in luck.

• Step 3. To test for Cross-Site Scripting, input the string "<script>alert('hello')</script>" without the quotes in the same search or login box you used before and send this to your Web server.

• Step 4. If the server responds back with a popup box that says "hello", then the site is vulnerable to Cross-Site Scripting.

• Step 5. If Step 4 fails and the Web site does not return this information, you still might be at risk. Click the 'View Source' option in your browser so you can see the actual HTML code of the Web page. Now find the <script> string that you sent the server. If you see the entire "<script>alert('hello')</script>" text in this source code, then the Web server is vulnerable to Cross-Site Scripting.

2) Upload Capability should do Additional Filtering

Summary

Uploaded content is not being properly filtered.


File upload is a special type of user input that can be very dangerous. It’s especially risky when content becomes part of the site. Allowing any content to be uploaded by an application is a significant risk. Whenever possible, such activity should not be allowed. However, there are times when it’s necessary for an application. When possible, the uploaded content – or any portion of the content – should not be returned to the user as this again, greatly increases the risk for the upload capability.

In this case, the files are not being properly filtered, which lead to additional risk. Properly filtering uploaded files can be difficult, but considered the following key risks can assist in managing the risk for the organization:

• Conduct a malware check for all uploaded content



• Check the file type when the file is uploaded• Be careful how uploaded content is read since libraries can have vulnerabilities

which can be exploited by reading the files• Limit and verify the size• Check file names and rename the extension for files• Upload files outside of web directories, when possible

References

• http://www.owasp.org/index.php/Unrestricted_File_Upload • http://www.owasp.org/index.php/File_System

Solution

Ensure that files are being properly filtered when uploaded. If possible, do not display back any content from the files once uploaded.

3) Cross Site Request Forgery Vulnerabilities

Summary

It is possible to steal or manipulate customer session and cookies, which can be used to impersonate a legitimate user, allowing an attacker to view or alter user records, and to perform transactions as that user.


Cross-Site Request Forgery (CSRF) is an attack that allows a hacker to perform an action on the vulnerable site on behalf of the victim. The attack is possible when the vulnerable site does not properly validate the origin of the request.

The severity of this vulnerability depends on the functionality of the affected application, for example, a CSRF attack on a search page is less severe than a CSRF attack on a money-transfer or profile-update pages.

The attack is performed by forcing the victim's browser to issue an HTTP request to the vulnerable site. If the user is currently logged-in to the victim site, the request will automatically use the user's credentials (like session cookies, user's IP address, and other browser authentication methods). Using this method, the attacker forges the victim's identity and submits actions on his or her behalf. In other words, the vulnerable site does not take the proper measures to validate that the user indeed wanted to perform the specific action.

Forcing the victim to send the unintended request can be done in numerous ways:

• Sending the victim a malicious link to the vulnerable application via e-mail.• Putting a hot-link (like an image or frame) to the vulnerable site on the hacker's

web page.• Posting a link to the vulnerable site in a public forum.


http://www.owasp.org/index.php/File_System

http://www.owasp.org/index.php/Unrestricted_File_Upload


• Using Cross-Site Scripting or Link Injection vulnerabilities in the site (or another site) and automatically redirecting the browser to the vulnerable site.

If the attacker uses a Link Injection vulnerability on the vulnerable site itself he or she increases the likelihood of the user being authenticated to the site, and by that increases the likelihood of the attack to succeed.

For example, using any of the above described options, an attacker can lure the victim to view a page containing:

<img src=http://bank/transfer?destination=John&money=1000 style='visibility:hidden'>

This will cause the victim's browser to automatically request the URL together with the current credentials of the browser.

If this banking site is vulnerable to CSRF, it will transfer 1000 dollars from the victim's account to John's bank account according to the application logic.

The Cross-Site Request Forgery attack is also known as CSRF, XSRF, Cross-Site Reference Forgery, One-Click Attack and Session Riding.

You can verify that your application is vulnerable to CSRF by:

• [1] Checking that the vulnerable link/request does not include a parameter that is hard for an attacker to guess

• [2] Checking that the vulnerable link/request performs an operation that should only be performed willingly

An application that contains a sensitive action, which can be accessed directly by a request that the user submitted unknowingly, is considered vulnerable to CSRF.

CSRF is also possible on login and logout pages. On logout pages CSRF can cause denial of service, since an attacker can forge consecutive logout requests from the victim. On login pages CSRF can allow an attacker to log the client into the attacker's account using a forged request containing the attacker's username and password. Login CSRF attacks can have serious consequences, depending on other site behavior. For example, if a site keeps a history of user actions (search history, for example) the attacker will be able to see the actions previously performed by the victim on the vulnerable site

In the case of this specific application, there appear to be multiple XSRF vulnerabilities. The vulnerability was proven for the resource https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ManageAccount.aspx as follows, to illustrate the possibilities.


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ManageAccount.aspx



• Step 1 – Created the exploitation code which included a web page with the following:

<iframe style="width: 0px; height: 0px; visibility: hidden" name="hidden"> </iframe>

<form name="csrf" action="https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ManageAccount.aspx" method="post" target="hidden">

<input type="hidden" name="ctl00$ContentPlaceHolder1$eEmail" id="ctl00_ContentPlaceHolder1_eEmail" value="[email protected]" />

<input type="hidden" name="ctl00$ContentPlaceHolder1$bSave" id="ctl00_ContentPlaceHolder1_bSave" value="Save changes" />

<script>alert("Executed")</script>

</form>

<script type="text/javascript">document.csrf.submit();</script>

• Step 2 – Logged in as the ‘bacamadm1’, which was the ‘victim’ account in this simulated attack

• Step 3 – Open the web page which contained the exploitation code• Result: The email account associated with the ‘bacamadm1’ user was

automatically changed to [email protected] by the user simply going to the page with the exploitation code, even though the user had not specifically made the request to change the email address. This means this attack could allow an attacker to change the associated email address with any user’s account that has access to the ‘ManageAccount.aspx’ script. For example, an attacker can changed the email address to their own address, and then request a password change which would be sent to the new email address provided. This proves that the ‘ManageAccount.aspx’ script is vulnerable to XSRF.



While all of the other forms were not tested in detail, based on the similarity of the other forms, and the lack of an apparent anti-CSRF token, the following forms are also assumed to be vulnerable.

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/CreateA ccount.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/EditCont ractPersonalInformation.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/GetAcco unt.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/GetPass word.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ImportF ailures.aspx


• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/NewCon tract2.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/NetCont ract3.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/Reports/ FormsExportReport.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/Reports/ ParkingReport.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/SearchC ontract.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ViewFor m.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/IPC/Multipl efilesupload.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/IPC/Queue.a spx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Syste mSettings.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Mana geLocations.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Institu tions.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/OrgCo des.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Acces sCodes.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/Parker/Link ToExistingContract.aspx

References


https://contractparking.texasmedicalcenter.org/TMCContractParking/Parker/LinkToExistingContract.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/AccessCodes.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/OrgCodes.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Institutions.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/ManageLocations.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/SystemSettings.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/IPC/Queue.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/IPC/Multiplefilesupload.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ViewForm.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/SearchContract.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/Reports/ParkingReport.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/Reports/FormsExportReport.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/NetContract3.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/NewContract2.aspx




https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ImportFailures.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/GetPassword.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/GetAccount.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/EditContractPersonalInformation.aspx


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/CreateAccount.aspx



• http://en.wikipedia.org/wiki/Cross-site_request_forgery • http://www.net-security.org/dl/articles/JavaScript_Hijacking.pdf • http://download.boulder.ibm.com/ibmdl/pub/software/dw/richmedia/rational/08/a

ppscan_demos/csrf-cbt/viewer.swf#recorded_advisory

Solution

In order to avoid CSRF attacks, every request should contain a unique identifier, which is a parameter that an attacker cannot guess. One suggested option is to add the session id taken from the session cookie and adding it as a parameter. The server must check that this parameter matches the session cookie, and if not discard the request. The reason an attacker cannot guess this parameter is the "same origin policy" that applies to cookies, so the attacker cannot forge a fake request that will seem real to the server. Any secret that is hard to guess and is not accessible to an attacker (i.e. not accessible from a different domain) can be used instead of the session id. This will prevent an attacker from crafting a seemingly valid request.

Add an additional parameter to protect against CSRF to the following forms:• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/CreateA

ccount.aspx • https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/EditCont

ractPersonalInformation.aspx• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/GetAcco

unt.aspx• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/GetPass

word.aspx• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ImportF

ailures.aspx• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/Login.as

px• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/NewCon

tract2.aspx• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/NetCont

ract3.aspx• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/Reports/

FormsExportReport.aspx• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/Reports/

ParkingReport.aspx• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/SearchC

ontract.aspx• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ViewFor

m.aspx• https://contractparking.texasmedicalcenter.org/TMCContractParking/IPC/Multipl

efilesupload.aspx• https://contractparking.texasmedicalcenter.org/TMCContractParking/IPC/Queue.a

spx






























http://download.boulder.ibm.com/ibmdl/pub/software/dw/richmedia/rational/08/appscan_demos/csrf-cbt/viewer.swf#recorded_advisory

http://download.boulder.ibm.com/ibmdl/pub/software/dw/richmedia/rational/08/appscan_demos/csrf-cbt/viewer.swf#recorded_advisory

http://www.net-security.org/dl/articles/JavaScript_Hijacking.pdf

http://en.wikipedia.org/wiki/Cross-site_request_forgery


• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Syste mSettings2.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Mana geLocations.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Institu tions.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/OrgCo des.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Acces sCodes.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Mana geAccounts.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/Parker/Link ToExistingContract.aspx

4) URLs Not Properly Restricted

Summary

Some URLs can be accessed by accounts that do not normally have access to specific functionality.


Some of the resources that are available for certain accounts can also be accessed by accounts that do not normally have the option to access such features. For example, the ‘adm’ account could access:

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ImportF ailures.aspx

• https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Messa ges.aspx

These resources are not normally accessible by the ‘adm’ user based on the options available when logged in as this account.

The following table summarizes many of the resources the application offered, as well as which users had access to each resource, based on testing for each account.

Sample URLs Available in the Application adm mgr ipc pkr csr none

contractparking.texasmedicalcenter.org/TMCContractParking/IPC/Queue.aspx D A U D A D

contractparking.texasmedicalcenter.org/TMCContractParking/TMC/SystemSettings.aspx D A U D D D

contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Users.aspx A A U D D D

contractparking.texasmedicalcenter.org/TMCContractParking/TMC/ManageLocations.aspx D A U D D D

contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Institutions.aspx D A D D D D

contractparking.texasmedicalcenter.org/TMCContractParking/TMC/OrgCodes.aspx D A D D D D

contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Messages.aspx U A U U U U


https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Messages.aspx




https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/Users.aspx









https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/ManageAccounts.aspx

https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/ManageAccounts.aspx









https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/SystemSettings2.aspx

https://contractparking.texasmedicalcenter.org/TMCContractParking/TMC/SystemSettings2.aspx


contractparking.texasmedicalcenter.org/TMCContractParking/TMC/AccessCodes.aspx D A D D D D

contractparking.texasmedicalcenter.org/TMCContractParking/CP/ManageAccount.aspx A A U A U D

contractparking.texasmedicalcenter.org/TMCContractParking/CP/ChangePassword.aspx A A A A U D

contractparking.texasmedicalcenter.org/TMCContractParking/CP/ImportFailures.aspx U U A D A D

contractparking.texasmedicalcenter.org/TMCContractParking/CP/CreateAccount.aspx A A A A A A

contractparking.texasmedicalcenter.org/TMCContractParking/CP/EditContractPersonalInformation.aspx U U A U U D

contractparking.texasmedicalcenter.org/TMCContractParking/CP/GetAccount.aspx A A A A A A

contractparking.texasmedicalcenter.org/TMCContractParking/CP/GetPassword.aspx A A A A A A

contractparking.texasmedicalcenter.org/TMCContractParking/CP/Primary.aspx A A A A A D

contractparking.texasmedicalcenter.org/TMCContractParking/CP/SearchContracts.aspx D U A D D D

contractparking.texasmedicalcenter.org/TMCContractParking/CP/SearchAccounts.aspx U A U U U D

contractparking.texasmedicalcenter.org/TMCContractParking/CP/ViewForm.aspx D D A D D D

contractparking.texasmedicalcenter.org/TMCContractParking/CP/Reports/FormsExportReport.aspx D D A D A D

contractparking.texasmedicalcenter.org/TMCContractParking/CP/Reports/ParkingReport.aspx D U A D A D

contractparking.texasmedicalcenter.org/TMCContractParking/CP/SelectInstitution.aspx U U U A U U

contractparking.texasmedicalcenter.org/TMCContractParking/Parker/LinkToExistingContract.aspx U U U A U D

contractparking.texasmedicalcenter.org/TMCContractParking/IPC/UploadContracts.aspx U U A U U U

The cells marked with ‘A’, ‘U’, and ‘D’ can be interpreted as follows:• A = Accessible and Authorized• U = Unauthorized• D = Denied

Each of the five types of accounts provided for testing were verified, as well as testing as a user who had no access. The ‘none’ column was tested by not logging in to the application to see what was available.

• adm• mgr• ipc• pkr• csr• none

Each of the cells noted as a ‘U’ are cells that appeared that the given accounts should not be able to access based on the links provided when logged in as that user. However, when typed in manually, the resources were available. Therefore, these resources should be limited if they are in fact unauthorized resources.

Solution

Ensure that all resources queried verify whether the user should have access to the resource before access is granted. Specifically, the resources marked in the table above with a ‘U’ for each account should be verified and access control enforce as appropriate.



https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/SelectInstitution.aspx




https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/SearchContracts.aspx

https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/Primary.aspx






https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ChangePassword.aspx




5) Record Enumeration

Summary

The ‘ID’ parameter is vulnerability to manipulation that allows the parking request records to be enumerated.


Currently, the application allows user to submit an ‘Application for New Parking Contract’. In order to make the request, the following request is sent to the application:

https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ViewForm.aspx?ID=0

Based on this request, Baccam Consulting attempted to manipulate the ID parameter to determine how the application responded. By changing the ID parameter to 1, the following was returned:

Note that the data being returned appears to be a current user’s contract, including data such as address and phone. Any application users that can make a request for a new





parking contract can enumerate this information. For example, the following requests were made as the ‘bacamipc2’ user:



The following request was made as the ‘bacampkr1’ user:



Similarly, the following request could also be used to enumerate records.

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/EditCont ractPersonalInformation.aspx?Form=9000


https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/EditContractPersonalInformation.aspx?Form=9000



Following is another example:


References

• http://www.owasp.org/index.php/Web_Parameter_Tampering

Solution

Ensure that users can not manipulate the ‘ID’ parameter to enumerate records. Users should only be able to make a request for a new contract with ‘ID=0’, instead of enumerating each of the individually parking contract records.

• https://contractparking.texasmedicalcenter.org/TMCContractParking/CP/ViewFor m.aspx?ID=0




http://www.owasp.org/index.php/Web_Parameter_Tampering




Similarly, ensure that users can not manipulate the ‘Form’ parameter to enumerate records.






Medium Risk

1) Missing Secure Attribute in Encrypted Session (SSL) Cookie

Summary

It is possible to steal user and session information (cookies) that was sent during an encrypted session.


The web application sends non-secure cookies over SSL. During the application test, it was detected that the tested web application set a cookie without the "secure" attribute, during an encrypted session. Since this cookie does not contain the "secure" attribute, it might also be sent to the site during an unencrypted session. Any information such as cookies, session tokens or user credentials that are sent to the server as clear text, may be stolen and used later for identity theft or user impersonation.

In addition, several privacy regulations state that sensitive information such as user credentials should always be sent encrypted to the web site. When the “secure” attribute is not set, as surf jacking attack can successfully steal a user’s cookie that is normally sent via SSL encryption.

References

• http://www.cgisecurity.com/owasp/html/ch07.html • http://www.owasp.org/index.php/OWASP_Application_Security_FAQ#What_are

_these_secure_cookies.3F

Solution

Basically the only required attribute for the cookie is the "name" field. Common optional attributes are: "comment", "domain", "path", etc. The "secure" attribute must be set accordingly in order to prevent to cookie from being sent unencrypted. RFC 2965 states: "The Secure attribute (with no value) directs the user agent to use only (unspecified) secure means to contact the origin server whenever it sends back this cookie, to protect the confidentially and authenticity of the information in the cookie." Ensure that the “secure” attribute is set for all cookies that should also be sent encrypted. For further reference please see the HTTP State Management Mechanism RFC 2965 at: http://www.ietf.org/rfc/rfc2965.txt and for "Best current practice" for use of HTTP State Management please see http://tools.ietf.org/html/rfc2964. The following cookies should have the “secure” attribute added:

• citrix_ns_id_.texasmedicalcenter.org_/_wat• citrix_ns_id• ASP.NET_SessionId• .ASPXAUTH

2) Password Reset Process should be Secured


http://tools.ietf.org/html/rfc2964

http://www.ietf.org/rfc/rfc2965.txt

http://www.owasp.org/index.php/OWASP_Application_Security_FAQ#What_are_these_secure_cookies.3F

http://www.owasp.org/index.php/OWASP_Application_Security_FAQ#What_are_these_secure_cookies.3F

http://www.cgisecurity.com/owasp/html/ch07.html


Summary

The password reset procedure is not secure since the new password is being sent cleartext via email, and the user is not being forced to change the password.


When a user requests their password be changed, an email similar to the following is received:

Your user account has been reset for the Contract Parking Application with the following user ID and password:

User ID:bacamipc3Password:P4)PXfa#(qY0u0

Please change your password when you log on for the first time, and never share your password with anyone. If you have any questions, please contact TMC customer support. Thanks!

Note that the password is sent cleartext. Additionally, after logging in with the new password, the user is not required to change the password, although it is encouraged. Since email is cleartext, and many users save emails, this can be an easy way to get access to another user’s account.

Solution

A more secure method for resetting passwords should be implemented, such as the following:

• Obtain the email address from the user when the account is created, as well as a number of security questions.

• Obtain the email address from the user when they wish to reset their password.

• Ask a user specific security question.• If the answer to the question is correct, send a “cut and paste” token or a

temporary URL, which can only be used to successfully reset the password for approximately 10 minutes.

• The user must change their password before the token or link expires.



Low Risk

1) HTTP Headers Reveal Unnecessary Information

Summary

HTTP headers are revealing unnecessary information including the server and ASP.NET information.


HTTP headers coming from the server often reveal information that is not necessary. In this case, the following headers were observed:

• Server: Microsoft-IIS/6.0• X-Powered-By: ASP.NET• X-AspNet-Version: 2.0.50727

By providing this information in the HTTP headers, it makes it easier for an attacker targeting the web application. While this information can still be obtained without the HTTP header data being revealed, it becomes more difficult for an attacker to accomplish. For some attackers, they may not have the knowledge or the skillset to obtain the information.

Solution

Preferably, modify the HTTP headers so unnecessary information is not sent to the client side. This can often be done with a web application firewall, or on the server itself.

2) Unnecessary Methods Supported

Summary

There were unnecessary methods supported by the web server.


An inventory was conducted of the methods supported by the application. The following methods were supported by the application:

• OPTIONS, TRACE, GET, HEAD, POST

The following methods are not needed by the application, and therefore should not be supported:

• OPTIONS, TRACE

References

• http://osvdb.org/877


http://osvdb.org/877


Solution

Ensure that unnecessary methods are not supported by the web server.


Documents

Web Management