What have we observed?
Badly configured web servers expose server-side status pages for debug and performance monitoring purposes. Those status pages include client requests, including the partial or full GET request. With badly designed web services, this will leak information that can be used by the attacker, to either gain access to the web service or gather valuable information about the back-end infrastructure.
An example can be found on the following link.
In the above example, we see that the attacker could gain access to dashboards of several clients. Furthermore, the attacker could deduce that some client devices are being provisioned remotely, including firmwares, having access to client dashboards as well as potentially allowing the attacker to push malicious payloads onto the client’s infrastructure.
Tools to automate the extraction of interesting data are very easy to implement and has already been partially done for the Apache status pages.
Root Cause
Web server administrators that enable mod_status on Apache for example, will expose server internals that should be kept secret. This is not restricted to Apache, but similar functionality exists in other popular web servers.
The above issues could also apply to web developers that enable debug capabilities in their projects. For example enabling the built-in debugger can lead to a Python shell, where an attacker could further explore and exploit the system. It is protected by a PIN but can easily be disabled with export WERKZEUG_DEBUG_PIN=off.
Ultimately, we have seen in the past that Cross-site scripting (XSS) vulnerabilities have come up in mod_status thus giving the attacker an additional attack vector to be used.
Fixing and mitigation
Disabling mod_status like modules on production servers is advised. To further mitigate the issue, having a restrictive .htaccess file denying access to /server-status pages can be implemented in case of future accidental enabling of mod_status.
To detect if mod_status is enabled, the following command can be issued:
$ sudo apache2ctl -M |grep status
status_module (shared)
Disabling on mod_status on Apache can be achieved with the following command:
$ sudo a2dismod status
Module status disabled.
To activate the new configuration, you need to run:
systemctl restart apache2
$ sudo systemctl restart apache2
The default config file for mod_status can be found here /etc/apache2/mods-available/status.conf on Ubuntu installs.
Reading web server log files to see if PII (Personal Identifiable Information) is disclosed should be performed regularly as well, to make sure to be in-line with governing data protection laws. An example of a privacy notice can be found on the CIRCL website, as we do logging on the web server and need to inform the users about data treatment. Whilst analysing the logs you might also find badly implemented URL-schemes that discloses credentials and other unwanted artifacts in you web applications.
A reflex might be to restrict using localhost as the only place to access the status pages, however, this is not necessarily a fix. Clients with tunnel capabilities, via SSH for example, could still access the status pages. Setting Host: localhost in headers might also circumvent such a limit.
One best practice should be to revise all the enabled modules by default on web server deployments and disable the modules that are not needed for production systems, thus reducing the attack surface considerably.
For more details on other web servers like nginx lighttpd, please see the references section.
Have you seen accessible servers in Luxembourg?
Yes.
References
- mod_status on lighttpd
- mod_status on Apache
- ngx_http_stub_status_module <v1.13.0
- ngx_http_api_module >=v1.13.3
- CVE-2007-6388
- Exploiting Misconfigured Apache server-status Instances with server-status_PWN
Classification of this document
TLP:WHITE information may be distributed without restriction, subject to copyright controls.
Revision
- Version 1.0 - TLP:WHITE - First version - 6 December 2021