Image
 
linkedin_logo.png rss_logo.jpg
twitter_logo.png youtube_logo.jpg
Latest Additions
 
EH-Net Login
Welcome Guest.






Lost Password?
No account yet? Register
Who's Online
We have 39 guests and 1 member online
 
Advertisement

You are here: Home arrow Ethical Hacking Discussions and Related Certificationsarrow Network Pen Testingarrow Pen test for Cross-Site Scripting (Expect Header) question.
EH-Net
May 23, 2013, 04:40:04 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Go back to The Ethical Hacker Network Online Magazine Home Page
 
   Home   Help Calendar Login Register  
Pages: [1]   Go Down
  Print  
Author Topic: Pen test for Cross-Site Scripting (Expect Header) question.  (Read 5257 times)
0 Members and 1 Guest are viewing this topic.
ericrobinson
Newbie
*
Offline Offline

Posts: 4


View Profile
« on: June 28, 2012, 09:02:00 AM »

Hello,

We have hired a security company to perform a penetration test. One of the tests they performed reported a risk. Here is the test parameters:

The Pentest company executed:

ncat --ssl (our static IP) 443
GET / HTTP/1.1
HOST:(our static IP)
EXPECT:"><script>alert('XSS')</script>

The response given by our firewall was:
 
HTTP/1.1 417 Expectation Failed
Date: Tue, 15 May 2012 18:58:45 GMT
Server: FortiWeb-2.2.0
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
174
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>417 Expectation Failed</title>
</head><body>
<h1>Expectation Failed</h1>
The expectation given in the Expect request-header
field could not be met by this server.<p>
The client sent<pre>
Expect: "><script>alert('XSS')</script>
</pre>
but we only allow the 100-continue expectation.
</body></html>

What I am wondering is what I must do to change the response by our Firewall so that the security tester does not believe that we are vulnerable to cross site scripting.

Our firewall is:
Model: Fortigate-60

Running:
Firmware: Fortigate-60 2.50,build171,031215

Any suggestions would be appreciated. Thanks.
Logged
cd1zz
Hero Member
*****
Offline Offline

Posts: 561


View Profile WWW
« Reply #1 on: June 28, 2012, 09:19:09 AM »

They should have given you a vulnerability reference along with remediation advice, especially if its from a FW vendor. It's likely an OS upgrade or bug fix patch you need to apply. However, if this bug is previously undisclosed (now disclosed) then they need to report it to Fortinet.

What I'm trying to say is the pen test company should have given you a fix or direction on how to fix.
Logged

Dark_Knight
Sr. Member
****
Offline Offline

Posts: 292


View Profile WWW
« Reply #2 on: June 28, 2012, 09:39:38 AM »

Ok I am not sure if I am missing something but according to RFC 2616
isn't the 417 response normal? Is he saying your device should support this behavior?

Quote
The Expect request-header field is used to indicate that particular server behaviors are required by the client.

      Expect       =  "Expect" ":" 1#expectation
      expectation  =  "100-continue" | expectation-extension
      expectation-extension =  token [ "=" ( token | quoted-string )
                               *expect-params ]
      expect-params =  ";" token [ "=" ( token | quoted-string ) ]
A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request MUST respond with appropriate error status. The server MUST respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with the request, some other 4xx status.

This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing an Expect field that includes an expectation-extension that it does not support, it MUST respond with a 417 (Expectation Failed) status.

Comparison of expectation values is case-insensitive for unquoted tokens (including the 100-continue token), and is case-sensitive for quoted-string expectation-extensions.

The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST return a 417 (Expectation Failed) status if it receives a request with an expectation that it cannot meet. However, the Expect request-header itself is end-to-end; it MUST be forwarded if the request is forwarded.

Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.
Logged

CEH, OSCP, GPEN, GWAPT, GCIA
http://sector876.blogspot.com
cd1zz
Hero Member
*****
Offline Offline

Posts: 561


View Profile WWW
« Reply #3 on: June 28, 2012, 09:41:13 AM »

The real question is if the javascript is executed by the browser or just displayed as text

><script>alert('XSS')</script>
Logged

Dark_Knight
Sr. Member
****
Offline Offline

Posts: 292


View Profile WWW
« Reply #4 on: June 28, 2012, 09:46:25 AM »

The real question is if the javascript is executed by the browser or just displayed as text

><script>alert('XSS')</script>
Agreed.
Logged

CEH, OSCP, GPEN, GWAPT, GCIA
http://sector876.blogspot.com
unicityd
Full Member
***
Offline Offline

Posts: 156

Bored IT Manager, Crypto Nerd


View Profile WWW
« Reply #5 on: June 28, 2012, 05:08:32 PM »

It used to be that IE was vulnerable and Firefox was not:

http://blogs.securiteam.com/index.php/archives/628

From the post:

"my site is vulnerable to this form of XSS (if the victim uses IE). What can be done? Everything that normal XSS can do including phishing and… well… everything.
As for fixing this (and yes… I will get around to that), I’m not too sure yet. I know I could create a custom error page but there may be better solutions, I’m asking RSnake about that and I’ll either comment here or just update this post if/when I get that info.

The reason this doesn’t work in firefox is because it doesn’t allow or support the Request header, I’m not sure which."
Logged

BS in IT, CISSP, MS in IS Management (in progress)
ericrobinson
Newbie
*
Offline Offline

Posts: 4


View Profile
« Reply #6 on: June 29, 2012, 07:51:50 AM »

Thanks for the feedback so far.

Our pen tester comments that:

Exploit Potential
It was possible to inject code into the Expect Header.

And:

Remediation
Add the following configuration settings to your web.config or app.config.
<system.net>
<settings>
<servicePointManager expect100Continue="false">
</settings>
</system.net>

The only problem I have with the remediation is that it points to configurations being made on a server; however, the response from our firewall indicates to me that the firewall was the device that responded...not a server in the network behind the firewall. I am led to believe this by part of the response which is:

Server: FortiWeb-2.2.0

The confusing thing is that we dont have any FortiWeb software or appliances. The only thing we have is the Fotigate60, which would imply to me that the Fortigate60 is running FortiWeb and is responding to the ncat query.

This is new to me so I am on a large learning curve here. I have installed nmap though, so I am able to reproduce the pen test results.
Logged
cd1zz
Hero Member
*****
Offline Offline

Posts: 561


View Profile WWW
« Reply #7 on: June 29, 2012, 08:01:41 AM »

The problem you have with their remediation advice is likely spot on. If the vuln exists on the firewall itself and not on your webserver, there isnt going to be a web.config file. Web.config is for .net web apps that run on IIS.

I am dying to know who this PT company is. If they're recommending you change your web.config on your firewall, I'm going to fall out of my chair.
Logged

MaXe
Hero Member
*****
Offline Offline

Posts: 669


I've just upgraded myself to a cyborg muahahaa!!1


View Profile WWW
« Reply #8 on: July 02, 2012, 12:57:22 AM »

This bug was also present in Apache around.. 3-5 years ago. They patched it  Grin (Just letting you know that they actually deemed it exploitable and also a bug. FortiWeb should patch this as well.)

What you should do is encode all user input and output (or at least validate and reject input if it contains bad metacharacters).

It's rarely I see people using the Expect header, so why don't you just block it at the firewall if you have such a feature to do that?

Have you tested this vulnerability by making a direct request to the firewalls web interface, where you send a malformed Expect header too? Would be nice to check whether it exists on the firewall too, or just when data passes through.
Logged

I'm an InterN0T'er
ericrobinson
Newbie
*
Offline Offline

Posts: 4


View Profile
« Reply #9 on: July 02, 2012, 01:53:20 PM »

It turns out that this pen test failure is due to a direct response from the firewall itself. I'll be contacting Fortinet to see if they can provide us with a patch, but frankly this unit is so old I'm guessing they won't want to spend any time on it.
Logged
MaXe
Hero Member
*****
Offline Offline

Posts: 669


I've just upgraded myself to a cyborg muahahaa!!1


View Profile WWW
« Reply #10 on: July 03, 2012, 07:17:09 AM »

Well it's relatively easy to patch, and they would make the customer happy, so I hope they do so  Grin Otherwise, release this bug on Full Disclosure and they might reconsider fixing it  Smiley
Logged

I'm an InterN0T'er
ericrobinson
Newbie
*
Offline Offline

Posts: 4


View Profile
« Reply #11 on: July 03, 2012, 11:25:38 AM »

I was guessing that the service on the Fortinet which was responding was the remote administration https:// access, so I used the following CLI commands through telnet to turn off https access:

set system interface wan1 config denyaccess

Now I am getting no response from ncat. This is one way to solve the problem with a limited configurable interface.
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines
Joomla Bridge by JoomlaHacks.com
Valid XHTML 1.0! Valid CSS!
Page created in 0.065 seconds with 22 queries.
 
Exclusive Deal

sansfire13_245x90_cw90.jpg
SANSFIRE 2013
June 15 - 22

5% Off w/ Code: EHN_5

SANS Deals 4 EH-Netters
5% OFF Any SANS Course in Any Format!
Coupon Code: EHN_5 Including SANS Rocky Mountain 2013 & SANS Boston 2013
Polls
Compared to this year, 2013 will be:
 
Recent Forum Topics
EH-Net News Feeds
Latest Additions
 
         
Advertisement

© 2013 The Ethical Hacker Network
Joomla! is Free Software released under the GNU/GPL License.