Team RADIX Research Report: RADIX1109200101

Date Published: 11-09-2001
Research Report ID: RADIX1109200101
Bugtraq ID: N/A
CVE CAN: N/A
Title: HTML/XML Validator Proxies
Class: Pseudo-anonymous Attacks
Remotely Exploitable: Yes
Locally Exploitable: Yes

Vulnerability Description:
Publicly accessible HTML and XML validation sites exist on the web to validate Internet-accessible HTML or XML documents. Some of the XML validation sites, such as the ones hosted by the web consortium, also perform HTML validation on Internet-accessible HTML documents. Many vulnerabilities are often present in markup validators.

Vulnerable Systems:
Most web-based HTML and XML validators

Solution/Vendor Information/Workaround:
Do not allow URLs to be submited for remote HTML/XML validation.

Vendor notified on: N/A

In keeping with the Camisade Research Report Policy, the information has been made public to best benefit the security community through full disclosure.

Credits:
Camisade - Team RADIX (researchcamisade.com) http://www.camisade.com This research report was drafted with the help of the SecurityFocus.com Vulnerability Help Team and OWASP. For more information or assistance drafting advisories please mail vulnhelpsecurityfocus.com.

Technical Description - Proof of Concept Code:
The XML and HTML validation web sites are, in effect, anonymous web proxies. Problems or difficulties are still often presented to an attacker to mitigate risk. For instance, often these or similar anonymous web proxies restrict access to only certain types of files like .html, .xml, etc. More often, the anonymous web proxies do not allow characters that are not typical to a URL that has no arguments, such as a "?". Some of the XML and HTML validation sites are affected by neither of these issues. Leaving no checks and bounds between use and abuse.

If the XML and HTML validation sites do not check filename extensions before validation, any document can be checked for "validation", such as /msadc/msadcs.dll or any other known vulnerable script. On some of the validation sites, if a given URL is not found, the XML or HTML validation site will display 404 not found. If, however, a given URL is found, the document will be "validated". Because the error for a page that is not found is different from that of an error due to the validated page not being .html, could be .asp for instance, then web vulnerability scanning becomes possible. The Netscape view directory bug, /?wp-cs-dump is successfully read as a valid URL by some XML and HTML validation sites. When a vulnerable site is found, the files and directories are displayed as invalid markup. In regards to /msadc/msadcs.dll as long as a 404 not found, or a similar such error, is not returned, the site contains the file.

Some of the XML and HTML validation sites blindly allow any IP address or Fully Qualified Domain Name (FQDN) to be entered for validation. This becomes an application security problem for many reasons. To start with the basics, an attacker could scan localhost or 127.0.0.1 for vulnerabilities. This becomes a bit more interesting when you realize certain web scripts require the user to be on localhost. With newer versions of Cold Fusion for example, a user would need to be on localhost to execute many of the privileged scripts such as /cfdocs/expeval/exprcalc.cfm or /cfdocs/expeval/openfile.cfm. Along the same lines, the IIS web admin service does not run on port 80 and requires the user to be on localhost. By using the validation site along with port specification, assuming the validation site supports port specification, the attacker can point or direct the validation site at the IIS web admin service.

Port specification does not end there; many of the validation sites return different errors depending on whether the port is open or not. This problem parallels the web vulnerability scanning issue. If the errors are different, port scanning becomes possible. The validation sites are also potentially behind firewalls. Potentially the web validation sites are configured with RFC-1918 IP addresses (10.0.0.0/8, 192.168.0.0/16, etc.). The validation sites can be used to determine if the host is on an RFC-1918 subnet, scan hosts behind the firewall, scan the firewall, scan localhost from behind the firewall, etc. Many opportunities now exist for the attacker due to the web-based code validation application.

Validation sites can also be chained together. Many of the validation sites use a GET request to input the URL to be validated. The GET request can be chained to another GET request and so on, to perform web vulnerability scanning or port scanning through many hosts.

URL based attacks, such as the IIS UNICODE vulnerability, may also be exploited using certain XML or HTML validation sites (or chains of sites).

Additionally, through port specification, i.e. requesting , some XML/HTML validators will return different errors if the port is open but not a web server (as opposed to the port being closed). This facilitates port scanning.

In addressing vulnerability risk, many problems arise if a given site suffers from this type of application security vulnerability. An attacker can perform information gathering, web vulnerability scanning, port scanning, and HTTP-based attacks against other sites on the Internet, which could lead to legal liability. The site with the validation service could also be attacked, along with any other hosts in the same cluster if a non-segmented architecture is present. The attacker could also use the vulnerable validation site as a proxy to other validation sites with the end goal of an attack. Due to the ability to perform attacks strictly via HTTP, as seen in the UNICODE vulnerability among other things, defacements, web shopping cart attacks, etc. are all possible.

Addressing the more global problem or underlying cause is more difficult. From a technical perspective, many applications that have an input field that reads a URL are vulnerable to this same problem. An input field that receives a URL should be assessed for these types of problems. This highly specific input validation test of an application is easy for an application security person to perform. However, not all application developers or systems integrators are familiar with security.

The security of any application that intended to be put into a production environment should always be assessed before it is put in the production environment.

Even if the application developers or systems integrators are familiar with security, how do you know?

Who is performing the checks and bounds on the application developers and systems integrators?

From a definition or linguistics perspective, many things that do not seem to be pseudo-anonymous proxies are indeed pseudo-anonymous proxies. Many input fields that read a URL as an input can be used to perform pseudo-anonymous information gatherings, scans, and attacks.

More importantly, security needs to be integrated into an application at every step of the development process to mitigate the likelihood of application security vulnerabilities from presenting themselves in a production environment.

Additional Information:
N/A

-- 
Team RADIX -- Camisade LLC
http://www.camisade.com
Application Security Innovations
Camisade Direct: 1.800.709.1241

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]