UNESCO Sensitive Data Exposure via OptionsBleed

Sensitive Data Exposure over *.unesco.org, thanks to OptionsBleed for low-hanging fruit

Piyush Raj Piyush Raj

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 (193.242.192.49)

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.

Reproducibility

Due to its nature the bug doesn’t appear deterministically. It only seemed to appear on busy servers. Sometimes appeared after multiple requests.

Options Bleed on *.unesco.org
Options Bleed on *.unesco.org

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/
—REDACTED—
/system/files/private_documents/—REDACTED—
/system/files/—REDACTED—.pdf
[+] news/news.mbp
[+] /BingSiteAuth.xml
—REDACTED—
UNESCO misconfigured Apache server-status module
UNESCO misconfigured Apache server-status module
Misconfigured UNESCO Apache server-status module

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.

The leak address ( — REDACTED — .unesco.org/server-status/) leaked exact version of OS running with other critical fingerprint data such as leaking mod_auth_kerb/5.4 and mod_prefork.

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.