Hackers may directly access the URLs to various on-disk files due to lack of protection for IIS users that is built in for Apache users.
Such files include the raw source code of pages, raw templates, and raw language files.
This is a low-to-medium risk vulnerability. The majority of users are not hiding privileged content with guessable page names in Comcode pages, but for those that are, this is a concern. Access to raw templates and language files would rarely be a concern.
All Composr (and ocPortal) versions are affected.
Only IIS users are affected. Few Composr users are running on the IIS web server (IIS is not officially supported with active testing, only sponsored for bug fixes).
Version 10.0.29 has been released and fixes the security hole.
Upload the latest web.config
Checking for exploit attempts
Check your web server logs for unexpected access to URLs for .txt
Various data and code files are stored on disk. Access to these files is protected for Apache users via .htaccess
files, but not for IIS users. The reason for this disparity is that it is harder to control access on IIS in a modular way, IIS has never been fully supported, and at some point an assumption was made that IIS users would hand-configure their URL access permissions.
How the fix works
Usually URL access is configured manually in the IIS user interface. It may be configured in web.config
, but either only in a clunky poorly-targeted way, or by a method that requires changes to IIS Delegation settings. The new web.config
file prohibits access with a workaround – redirecting access from certain URLs to a black-hole.
IIS support was added informally a long time ago, before we had a feature tracker. If it was added now we would have made a proper issue about the lack of permission parity and the knowledge would not have become lost in time.
This issue was found by the developers while performing a wider review around XSS via mime sniffing on .dat files