Sensitive Data Exposure over *.unesco.org, thanks to OptionsBleed for low-hanging fruit
Date reported — 02–07–2019
# Vulnerable Software — Apache
# CVE: CVE-2017–9798 / USN-3425–1 “OptionsBleed”
# Type — P1:Sensitive Data Exposure + P5:Fingerprinting/Banner Grabbing
# Domain Affected — *.unesco.org
# Tested — https://en.unesco.org (184.108.40.206)
Options Bleed is a use after free error in Apache HTTP that causes a corrupted Allow header to be constructed in response to HTTP OPTIONS requests which helped in seeking the direct leak of sensitive data through a misconfigured server-status module,
mod_status which Apache web server exposes for displaying metrics.
Due to its nature the bug doesn’t appear deterministically. It only seemed to appear on busy servers. Sometimes appeared after multiple requests.
Anyone can set a worker and can extract & enumerate all the sensitive file paths regularly. The files exposed can be accessed directly.
Proof of concept
$ curl -s https://—REDACTED—.unesco.org/server-status/
Full sensitive paths disclosure. You can have a look at an offline mirror which I took at the time of testing. I also enumerated the server's web config — have a look-see.
Chaining the chain
The leak address ( — REDACTED — .unesco.org/server-status/) leaked exact version of OS running with other critical fingerprint data such as leaking
Server Version: Apache/2.4.18 (Ubuntu) mod_auth_kerb/5.4
Server MPM: prefork
Server Built: 2019–04–03T13:34:47
Knowing the version and finding that it runs
prefork, it also becomes vulnerable to CVE-2019–0211. This specific Apache version suffers from a local root privilege escalation vulnerability due to an out-of-bounds array access leading to an arbitrary function call. The vulnerability is triggered when Apache restarts graceful —
apache2ctl graceful. In standard Linux configurations, the
logrotate utility runs this command once a day, at 6:25AM, in order to reset log file handles. Not tested this last one as I was not authorized to upload files as a guest user.
Lastly, by looking at https://en.unesco.org/user/login?destination=user/password/core/includes/bootstrap.inc — it seemed like drupal bug also existed, just behind some WAFs.