ETag leaking inodes false positive

[Synchro]

Not the same as #101 or #48!

Nikto always reports ETags as leaking inodes, even when they do not. Nginx doesn't include inodes in ETags, only file size and mod time, and Apache can be configured to do the same with a FileETag MTime Size directive, yet Nikto still reports it as leaking inodes. Looking at the code - if there is an Etag header and it contains a -, Nikto reports it as leaking inodes without checking whether it really does.

[sullo]

Do you have some samples handy of nginx or an apache with just the -?

And we should report the mtime I would think, just a different message...

[tautology0]

I'm not too fussed about reporting some false positives (have you seen Nessus's score on this risk), as part of the job of the pen tester is to assess what is returned and analyse whether it's relevant.

That said, we can try for better accuracy, when I wrote that check I had a sample size of three different web servers, so having some real world examples would be useful.

[Synchro]

Here's one from nginx 1.11:

ETag: "53c97bc6-203"

This is a file of 515 bytes (0x203), last modified on Fri 18 July 2014 19:55:50 UTC (0x53c97bc6 -> 1405713350). Nginx provides no control over ETag format, only the ability to turn them on or off.

It turns out that Apache switched its default ETag format to be the same as nginx in version 2.4 (released Jan 2012). You can see this in the docs for 2.2 vs 2.4. Here's an example apache 3-element ETag I found using inode, size, mtime (though that mtime looks wrong)?:

ETag: "cc038c-86b7-89ce1880"

While it's hard to say whether a particular number is an inode (they may be in the same numeric ranges as sizes and timestamps), it is very likely that a three-element ETag does indeed include an inode value, and also that the server is running an outdated version of apache.

The problem with Nikto reporting this is that the result is often misinterpreted, for example this article suggests "solving" the report by turning off ETags altogether, without mentioning the potential performance impact - this is a very common response. Furthermore, the tag that it's complaining about is not revealing the inode at all, which is what this report is about.

Of course it would be better if ETags used hashes rather than real values - OpenBSD's apache patch for this from 2003 simply does an SHA1 on the whole lot.

[drwetter]

find -inum?

[wireghoul]

I guess you can mark #477 as a dupe of this

[acaetano]

Shouldn't this issue be closed?

[sullo]

@acaetano the other issue was closed as duplicate.

however, in thinking more about this I started with the notion of "who cares about this issue?" As far as I recall, even in 2003 it was a minor concern. Worst case scenario would be leaking an inode or a mime boundary (which may contain a PID or child PID).

In the case of an inode, it may aid in further exploit via NFS per the openbsd patch note[1] which states "This could lead, for example, to NFS exploitation because it uses inode numbers as part of the file handle."

I think the use of a PID is fairly self-evident, but still require something else (typically a vulnerability) to be terribly useful.

Since we are 15 years past disclosure and 6 years past Apache's final change on the matter.

So, do we care any more or should be just deprecate this etag checking business entirely?

1. http://www.openbsd.org/errata32.html

[acaetano]

I think it should be kept, the Apache Foundation still updates the 2.2 branch (the one that has this issue in the default config), even after labeling it as "Legacy release".

This flaw is difficult to state in a report, as only a peek into the server (configuration file or application server software) will actually confirm or deny it. In my reports, i always change the vulnerability title to something like "Possible inode exposure", as there is no way we can say for sure that there was an inode involved in the token generation, even if we see a different server software name, as it may be used as just some kind of reverse proxy.

So, maybe a change in the vulnerability title that is produced by the tool would settle this argument once and for all?

[Synchro]

I understand that it's possible for it to still be a problem. My main arguments against it are that it's nearly always a false positive, and the suggested remedy may have a performance impact that is not mentioned. Revealing that you're running apache 2.2 is probably a much bigger red flag than the ETags anyway, and the old-style ETag might be useful for fingerprinting it if the version is not shown. I think it would be fair to not mention it at all if the server identifies as nginx.

[acaetano]

But what if the tag was not inserted by the nginx and it is being used just as a proxy?

[Synchro]

I don't know - the main thing is to stop recommending removing ETags completely, as it probably does more harm than good.

[acaetano]

But i'm not arguing we should tell them to remove the ETag header, i'm arguing that we should recommend them to make sure and produce evidence that shows that the inode is not used in the ETag generation, or shows that they are not using Apache as the application server.

A screen capture of the configuration file containing the lines that set the ETag calculation parameters, or a screen capture of the application software serving the web app are sufficient for that.

I reiterate: We should NOT tell anyone to remove the ETag header, just as much removing the lock from the door should not be recommended as the mitigation for a house break-in where the burglar used a lockpick.

This is a case where it is not possible to tell if the flaw has been fixed just based on a new analysis, we need the people responsible for the application to show what is behind the curtain. I know that this way we are susceptible to being cheated, but that is as far as is humanly possible without a full audit.

[Synchro]

That's what I said - it currently does tell users to remove it.

[acaetano]

Well, we should just change it then.

Is there any problem with changing the recommendation to what i said above?

[Sjord]

So, do we care any more or should be just deprecate this etag checking business entirely?

I don't think exposing inode numbers is really a security issue. It seems that this message is always a false positive in modern environments, and it would be impossible to verify remotely if a number is an inode number. I think removing this inode check altogether would be the right choice.

[acaetano]

To state that this is "always" a false positive is a false statement, as we just checked that it is the default configuration in a product branch that is still current. Or do we only care about "modern environments" now? As much as this might be thought to be unlikely to actually happen, i think that the job of Nikto is to report and make people raise eyebrows over this, forcing them to make sure.

We should never forget, security is a game of trust. Putting your trust that something is not ok when it actually is, is way better than getting a false sense of security. If we cannot say something for sure, it is better to relay the concern to the user instead of blindfold them telling "Everything is gonna be alright".

I say, just change the recommendation to something that tells them to make sure and produce evidence that shows that the inode is not used in the ETag generation, or shows that they are not using Apache as the application server.

And the world will go on its merry way.

[Synchro]

Absolutely - it would be helpful if Nikto could combat at source the unhelpful but almost universal "turn off ETags" response that nearly all mentions of this notice provoke.

[drwetter]

I would phrase it as a potential information leakage . It can be of use later for an attacker if it is not a FP.

Why just drop information if it can be of use? IMO it just needs to be phrased in a way that doesn't lead to misunderstandings.

[tautology0]

Well, this one is controversial! My thoughts.

1. People shouldn't just try and fix what is reported by tools - that's the whole damn point of risk management. The risk level for a single i-node is not high. (Unless you use CVSSv2, which is due to CVSS's really bad way of managing risk levels.)
2. It can be of use: iff the http server is also running NFS it may allow the brute forcing of file handles. Just today I was looking at a client's server which was running NFS and a HTTP server.
3. It's information; information is useful.
4. The wording should be tuned up to be less "is" and more "may"

I've pushed in a wording change to update it slightly.

[wireghoul]

I think the ideal scenario updates the etag code to check if it’s seeing two values (no inode) or three values (inode) and only report on the latter.

[wireghoul]

Pull request submitted

[acaetano]

But having two values instead of three is no guarantee that the inode is not present. Nothing we can measure will be affirmative to that. We will fall in the same hole time and time again.

[wireghoul]

AFAIK there are no web server that sends inode in a two value ETag, but if you can point me to one which does I'm sure we can adjust the code.

As it currently stand, if a server did send the inode in a different order to apache it would parse the inode as either the file size or the time stamp so the existing code would get that wrong anyway, my patch does not impact such theoretical false negatives either.

[tautology0]

I'm happy to accept this as a compromise otherwise we'd be here for ever!

I've tested it and it works fine. I think I'm going to close this now to stop it going 'round in circles.

[acaetano]

Theoretical software? If you just take a look into the official documentation, you'll see that you can even have the tag generation based in the inode only, just by disabling "MTime" and "Size".

http://httpd.apache.org/docs/2.2/mod/core.html#fileetag

[acaetano]

I even found you an example of Inode-only use. According to this blog post, this is what it actually looks like in that case.

Etag = "9c334" (Inode only) Etag = "9933" (Size only) Etag = "74b9cec0" (MTime only)

Pattern matching won't provide a reliable answer in any case you think about it. Changing the recommendation (and maybe the title like someone said above) is the safe way to go with this.

Safe for the user, safe for the community, and like @Synchro mentioned, showing others vendors how to deal with flaw's peculiarities.