False positive Wordpress identification when using wp-content url

Vulnerability Tests
1

I’ve discovered the VT “secpod_wordpress_detect_900182.nasl” generates a false positive (OID: 1.3.6.1.4.1.25623.1.0.805366) when wp-content is used on a page.

The wordpress detect script tries to determine if WordPress is used on a host and assigns “cpe:/a:wordpress:wordpress”.

I have a customer which uses N-Able. Running the VT will assign the WordPress CPE to this host, because of the following code on the webpage of N-Able:

<!DOCTYPE html public "-//w3c//dtd html 4.01//en" "http://www.w3.org/tr/html4/strict.dtd">
<html>

<head>
    <meta charset="UTF-8" />
    <script>
        window.location.replace("/login");
    </script>
    <title>N-central Login Redirect</title>
</head>

<body>
    <script>
        window.onload = function reloadLoginPage() {
            var loginPage = window.location.protocol + "/login";
            location.replace(loginPage);
        }
    </script>
    <img src='https://www.n-able.com/wp-content/themes/nable.2021/img/framework/nable.positive.svg' alt='N-able'>
    <div>Your web browser did not automatically redirect you to N-central's login page. To address this issue, please enable JavaScript in your web browser for N-central's URL and reload this page.
    </div>
    <div><a href='/login'>Alternatively, you can click here to log into N-central.</a>
    </div>
</body>

</html>

I suspect the following pagecode is triggering the following VT:

<img src='https://www.n-able.com/wp-content/themes/nable.2021/img/framework/nable.positive.svg' alt='N-able'>

if( res && res =~ "^HTTP/1\.[01] 200" &&
          ( '<meta name="generator" content="WordPress' >< res ||
            res =~ "/wp-content/(plugins|themes|uploads)/" ||
            res =~ "/wp-includes/(wlwmanifest|js/)"
          )
      ) {

      if( dir == "" ) rootInstalled = TRUE;
      version  = "unknown";
      conclUrl = http_report_vuln_url( port:port, url:url, url_only:TRUE );

While the N-Able pages uses a .svg image with “wp-content” in it’s URL, it doesn’t mean this host has WordPress installed. It’s not unreasonable other sites have an img src with “wp-content” in it’s url.

This check should be rewritten to prevent false positives. I am still looking into this and will try to edit the VT but any validation or help is welcome. Thank you.

2 Likes
2

Hi,
This is indeed a false positive and there has to be a check if the path is hosted on the server itself or on a 3rd party server.

Thanks a lot for the detailed report and your analysis. Much appreciated!

We will look into this but if you have a patch before feel free to post it here and we will review and put it in the feed.

4 Likes
3

Hi,

The WordPress detection got updated to check for 3rd party links and not reporting them anymore. This should arrive in one of the next feed updates.

Let us know if this solves the wrong detection.

3 Likes
4

Thank you for the update, I’ll verify and get back to you.

2 Likes
5

1.3.6.1.4.1.25623.1.0.900182 - WordPress Detection (HTTP) still occurs
1.3.6.1.4.1.25623.1.0.805366 - WordPress Business Intelligence Lite SQL Injection Vulnerability is gone

6

Thanks a lot for your additional feedback.

Seems some N-Able systems are different as the last update to the Detection VT prevented a WordPress detection against the N-Able systems we were able to get a hand on.

To better understand where the detection on your N-Able system is originating from the following VT:

1.3.6.1.4.1.25623.1.0.900182 - WordPress Detection (HTTP)

received an update to be more verbose where the detection is originating from. If would be great if you could re-do a scan and post the output of that VT (with sensitive data like URLs replaced) here.

2 Likes