0

I'm doing a vulnerability assessment for a whole slew of web servers, and almost every single one of them (hundreds) are misconfigured like the following two examples:

Case 1: one or more hostnames resolve to the server's IP address (let's say, 199.0.2.42). The server routes all of them to a single default site.

Case 2: two or more hostnames resolve to the server's IP address (let's say, 199.0.2.69). The server is configured for name-based virtual hosting, but one of the "real" sites is the default.

Consequence:

  • Users can request https://199.0.2.42/something or https://199.0.2.69/whatever
  • The server returns a certificate that lists the official hostnames under SAN
  • Since the IP address obviously isn't in the SAN, the browser warns the user of the certificate mismatch.
  • Because STS policy can't be applied to raw IP addresses (in URLs), the user can swat the warning away.
  • The browser happily continues, makes the https request over a TLS connection that might be compromised, and the web server handles it like any other request to the server's default (real) site.

In the past, it's been reported as CWE-295... and generally ignored by everyone involved with their administration. I'm convinced that there's a better code for it, and suspect that part of the reason past admins got away with casually ignoring it is precisely because they skimmed a report, saw something about "invalid certificate", grunted that the certificate was fine, and tossed the report in the trash.

The fundamental problem isn't an invalid certificate (the certificate itself is fine), the problem is a misconfigured web server that's allowing requests that don't match an explicitly-mapped name-based virtual host to fall through and default to one of the "real" sites instead of landing on a "garbage" default that returns something like "400 (Invalid/Undefined Host)" for everything.

Can anyone suggest a better CWE that more accurately gets to the essence of the problem and describes it in a way likely to make fixing it seem more urgent (or at least, worthwhile) to the server admins?

1 Answer 1

1

You haven't really described a problem that could be fixed server-side. If the client ignores TLS warnings, then it's generally too late for the server to do anything, because an attacker could read or manipulate the traffic however they want. Even if the server would reject the unsafe requests if they actually arrived, that doesn't help when the attacker acts as a man-in-the-middle.

The only actual attack scenario I can think of is DNS Rebinding. This is particularly relevant for websites that are private or only accessible from specific IP addresses, because it gives an attacker access to a website they usually couldn't reach at all. In case of a public website, DNS Rebinding is only relevant if the attacker cannot perform a man-in-the-middle attack.

  1. The target site is at IP address 1.2.3.4 with some hostname.
  2. An attackers sets up a website malicious.com with TLS enabled but without HSTS. The DNS entry for malicious.com is made short-lived.
  3. Once a victim visits malicious.com, the DNS entry is changed to the IP address 1.2.3.4. Scripts loaded via malicious.com can now make requests to the target site without being restricted through the same-origin policy.
  4. There will be a certificate warning, but under your assumptions, the user just ignores it.
  5. Since the target server happily accepts malicious.com as a hostname, the request will be directed to the default site, allowing the attacker to do read or change anything the user has access to.

I haven't tested how well this works in current browsers, but DNS Rebinding is CAPEC-275.

4
  • The best solution I've seen is to enable name-based virtual hosts (if they aren't already), then create a "dummy" default that does nothing besides return "400 (Invalid/Undefined Host)" for any request that falls through to it. That way, if someone tries to load something like real.host.org/content, the server routes it to real.host.org's virtual host... but if they try to load 1.2.3.4/content, instead of falling through to real.host.org's web site (like it does now), it just falls through to the dummy default and gets a 400.
    – Bitbang3r
    Jun 15, 2023 at 19:02
  • There's still a real MITM risk that someone could intercept "https: //1.2.3.4/loginPage" & display a real-looking login form, but hopefully the user will be less likely to fall for it IF he hasn't been conditioned to think all the company's sites can be reached by IP-specified URLs. Right now, pretty much ALL the sites can be reached by IP-specified URLs.
    – Bitbang3r
    Jun 15, 2023 at 19:04
  • I understand why default sites are problematic, but according to your description in the original question, simply pointing out best practices and the need to discourage unsafe user behavior wasn't enough to convince sysadmins. That's why I mentioned DNS Rebinding as a demonstrable attack which is (among other factors) enabled by default sites.
    – Ja1024
    Jun 15, 2023 at 19:29
  • I don't think it's administrative malice or laziness. I think it's more like the forced rush to implement "SSL Everywhere" a few years ago (and the brittle unforgiving nature of its configuration) traumatized an entire generation of admins & left them with collective PTSD. They're literally afraid to change ANYTHING on mature servers that might cause TLS to break (even in situations where it SHOULD officially break). That's part of why I've been working on improving our message to them, to get them to agree it actually IS important to fix. DNS rebinding is a good example of a "real" threat. :)
    – Bitbang3r
    Jun 15, 2023 at 19:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .