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.

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

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.

"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."

Exploit PotentialIt was possible to inject code into the Expect Header.

And:

RemediationAdd 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.

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.

This bug was also present in Apache around.. 3-5 years ago. They patched it (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.

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.