Securing HTTP TRACE

Support
,
1

NethServer Version: 7.8.2003
Module: base

Problem: Nessus reports HTTP TRACE / TRACK Methods Allowed, plugin #11213, as https://www.tenable.com/plugins/nessus/11213.
Installation is fresh with TLS policy supplied at 20200510. Track should be off to enhance security.

Solution: Add TraceEnable and set to off as detailed https://httpd.apache.org/docs/2.4/mod/core.html#traceenable.

Recommendation: add the traceEnable off text to the tls script that updates to remove <1.2 versions.

1 Like
2

The docs linked above says

Despite claims to the contrary, enabling the TRACE method does not expose any security vulnerability in Apache httpd. The TRACE method is defined by the HTTP/1.1 specification and implementations are expected to support it.

Who is right?

According to Tenable itself, historycal CVEs exist for other web servers. Apache not included.

3

Do no trust automatic security scanner :slight_smile:

I faced it a couple of them in last months, and 99% of reported issues are false positive.
I agree with Davide, this can be dismissed.

if you still want to disable HTTP TRACE just edit the configuration file using a template-custom.

2 Likes
4

They are only running their business :stuck_out_tongue_winking_eye:

1 Like
5

It’s telling that even this page doesn’t give a word of explanation of why they think this is a problem, or something that should be flagged on a security scan. You’d think they’d have something to justify the flag and its severity, but it’s nothing more than “it can be used to debug the connection. Take our word for it that it’s bad.”

2 Likes
6

Lower right on the page.

image
image369×768 42 KB

7

Update: A change was made (patch) and the Nessus scan revealed the same error. Which templates need to be updated to add the ‘traceenable off’ line for all ports with web servers?

8

I think no templates are needed in this case and other similar cases.

If setting TraceEnable off at the server level is enough you could just modify /etc/httpd/conf/httpd.conf or better drop a .conf file under /etc/httpd/conf.d/ and listing it in /etc/backup-config.d/custom.include.

Let me know if it works!

1 Like
9

The file /etc/httpd/admin-conf/httpd.conf specifically states not to edit it. /etc/httpd/conf/httpd.conf already has my modification, but that file is not configured for the server on port 980.

I created the new file, httpd.conf, in /etc/httpd/conf.d and added the filename to the (previously blank) custom.include file mentioned. Lastly, I issued systemctl restart httpd to the system before rescanning in Nessus. The scan failed to receive a positive result (trace still allowed) so I rebooted and re-ran the scan. Once again, it failed.

Scans of the other ports are clean.

10

It is the config file for the old administrative interface on port 980. You can drop a file into /etc/httpd/admin-conf.d as well.

It works here with

# echo 'TraceEnable off' > /etc/httpd/conf.d/trace.conf

I didn’t test virtualhosts.

More details here 
[root@vm7 ~]#  curl -v -X TRACE http://localhost
* About to connect() to localhost port 80 (#0)
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 80 (#0)
> TRACE / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 19 Jun 2020 16:59:21 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16
< Transfer-Encoding: chunked
< Content-Type: message/http
<
TRACE / HTTP/1.1
User-Agent: curl/7.29.0
Host: localhost
Accept: */*   

* Connection #0 to host localhost left intact
[root@vm7 ~]# systemctl reload httpd
[root@vm7 ~]#  curl -v -X TRACE http://localhost
* About to connect() to localhost port 80 (#0)
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 80 (#0)
> TRACE / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost
> Accept: */* 
>
< HTTP/1.1 405 Method Not Allowed
< Date: Fri, 19 Jun 2020 16:59:39 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16
< Allow:
< Content-Length: 223
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>  
<title>405 Method Not Allowed</title>
</head><body> 
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for the URL /.</p>
</body></html>
* Connection #0 to host localhost left intact
11

Hi all, recently I’ve stumbled upon the same issue in Securing HTTP TRACE/TRACK, the statement made by the apache team is true: It does not expose a vulnerability in Apache.

But that is not the point. It might be used to attack a any web application hosted on the apache.

See: https://www.owasp.org/index.php/Cross_Site_Tracing

Therefore most vulnerability assessment tools will flag the TRACE method as critical.

What’s the point in having a client see what is being received at the other end of the request chain and use that data for testing or diagnostic information in a production environment ?

And as confirmed in this years this could be used to grab session cookies and steal admin connections, reported from many CVEs.

My point is that there’s no benefit and only risks for customer sessions, so I ask to reconsider actual behaviour and disable “tracing” by default.

For your information:

Thanks in advance
Nick

12

Hello @Nick and welcome to NethServer Community!

Since the potential security risk is tightened to an application and not to Apache itself, there is no reason to change current default.
If a security risk is really proven, It’s up the application to change the configuration on its own.

As general rule, we do not change default configuration during minor releases. Also NS7 is in freeze mode, that means no new features will be added: this is an extra reason to not change a default right now.

If you still want to disable the TRACE for the whole Apache installation, please follow @davidep suggestion.

RedHat disabled tracing for oVirt 1764959 – Apache is configured to offer TRACE method (security)

Red Hat didn’t change Apache default in RHEL, but they changed it only on a specific installation witch is hosting just one application. Of course, this is not our case.

1 Like
13

Hello @giacomo (and everybody),
following your logic, we should change the setup of every application released from software center that could be prone to XST ?

(Sorry previous link was broken: Cross Site Tracing | OWASP Foundation )

Thanks in advance
Nick

14

Of course not, you should change only your application instance which the VA scanner is wrongly pointing out as insecure.

15

Well, indeed awareness is related to security but it’s not always true the opposite.

First: let’s agree on the fact that: if an application security is based on cookies and authentication credentials (let’s call it SESSION) and the session could be stolen on a level lower than the application (the web server level). The application is insecure, no matter what you do.

Second: following your statement seems that if there’s an application prone to XST but we don’t check it with VA there’s no need of securing it :wink: Just to say that if an app is insecure with this setup and the wide adopted solution is to disable tracing, why don’t do this by default (and by design) ? :wink:

Ciao
Nick