Vulnerabilities that aren’t. ETag headers

This time we’re looking at the ETag (Entity Tag) header. I take some of the blame for this one as I first added a dissector of the header to Nikto’s headers plugin back in 2008, then other scanners added it.

What Is It?

The header is a simplistic method of helping the user-agent identify whether it can cache a file. It is used for comparing multiple entities from the same resource. It was first defined in RFC 2068 (which defines HTTP/1.1) back in 1997.

The ETag header defines the strength of  a resource if “they are equivalent by octet equality” i.e. they contain the same bytes. Resources are deemed weak if “the entities are equivalent and could be substituted for each other with no significant change in semantics”.

The header defines this entity identifier, but its implementation is left up to the web server. Here’s some examples:

• ETag: “bob”
• ETag: “7f9bccd1ef8761”
• ETag: W/”xyzzy”
• ETag: 456-ab-adc1789

ETags have had a bit of a bad rap in the past as they have been used to enable cookie-less tracking, where the server sends unique ETag for one resource for each source IP address. See tracking without cookies for more information.

Why could this be a vulnerability?

As the implementation of the contents is implementation only, web servers implement it in different ways. Some servers, such as Apache httpd, use the metadata for the file to create the ETag header. An example of an Apache httpd ETag, showing all fields can be seen below:

There are three hex fields in the ETag:

• 904b0 – the inode of the file
• 65 – the size of the file
• 5d4e7f6f9b6c7 – the mtime (the time the file was last modified) as a 32-bit or 64-bit integer

Let’s convert those hex digits to numbers:

• inode:    591024
• Size:       101 bytes
• mtime:  Thu Jan 06 2022 11:13:49

Checking those numbers against the file shows they match:

The inode (Index Node), is where this information could cause a security vulnerability.

An inode is the internal number of the file within the file system. Mostly this is not very useful to know, but some systems have been known to use the inode as a reference to a file (an inode is unique, but multiple filenames may point to the same inode). Where this gets interesting is that older versions of NFS, before NFS 3 use the inode as part of the NFS file handle.

NFS is a file sharing protocol commonly used on Unix and Linux hosts. It was very popular in the 90s and 00s when support for Windows shares was harder to implement. It is a very old protocol, which accesses resources with a token, known as a file handle.

The file handle is 32 bytes (64 bytes for NFS version 4) of data. If the file handle can be guessed or discovered than it can be used to access a resource, bypassing most of the authorisation routes. Yes, NFS had IDORs!

The handle on many Unixes, including AIX, HP-UX and Linux used to contain the major and minor numbers of the device for the file system and the inode of the resource being accessed. The major and minor numbers can be guessed or brute forced.

Therefore, if the web server gives you an inode for a file, you can create an NFS file handle to access that file through NFS with no authorisation required.

Why is this not a vulnerability?

…simply because it’s incredibly unlikely to ever be in a situation where it is exploitable.

For  this to be exploited the following things must be in place:

1. ETags need to be exported which include inodes
2. An NFS service needs to be accessible to the attacker
3. The NFS server and HTTP server that point to the same file system (e.g. they’re on the same host)
4. The version of the NFS service needs to be less than version 4

I suppose this could be possible in an internal network where legacy Unix is in use. It is extremely unlikely to be exploitable from the Internet. Allowing Internet NFS connections is much more of a concern.

Historical exploits

Having a look through the CVEs for ETags doesn’t produce many hits:

• CVE-2003-0105 – identified that ServerMask allows ETags through unchanged, but IIS ETags don’t contain inodes so, for this purpose it is a moot point
• CVE-2003-1418 – is the original CVE which identifies that ETags on Apache httpd could reveal the inode via the ETag header if FileETag is configured. It has a CVSS 1.0 score of 3.5.

There are no exploits on exploit DB which use the ETag header.

Reports from tools

This is where it gets silly. We’ve looked back at possible exploits for the vulnerability and its history, with an original base CVSS score of 3.5. This makes it a low risk. Let’s look at how some tools score it:

Nikto
First Nikto, that original test which I added nearly 15 years ago. It will only report it if the Etag returns an inode. Nikto deliberately doesn’t score findings, so that’s up to the user.

+ Server may leak inodes via ETags, header found with file /, inode: 591024, size: 101, mtime: Thu Jan  6 11:13:49 2022. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418

Nessus
Nessus returns this if the ETag header contains an inode:

The remote web server is affected by an information disclosure vulnerability due to the ETag header providing sensitive information that could aid an attacker, such as the inode number of requested files.

But then it converts the original CVSS score of 3.5 into a raw CVSS 3.0 vector, which ends up with a frankly ridiculous score of 4.6 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N/E:U/RL:O/RC:C).

Conclusion

This is a vulnerability that can reveal what could be deemed to be confidential information in very rare circumstances but is mostly “meh”.

This isn’t to say you shouldn’t worry about it, but this is where the rest of the environment comes into consideration.

If it is on an Internet facing web server then there is no real risk. However, if the web server is internal and has other legacy services (such as NFS running) then maybe think about altering that FileETag directive so the header doesn’t export ETags.