We've recently been testing Umbraco to check for potential vulnerabilities, with the intention of hardening our installations. As part of this process, we found that the handling of files uploaded to the Media tab to be a bit too permissive for our liking.
Basically, in the umbracoSettings.config file, you're able to provide a list of "banned" file extensions. By default, these are:
This seems to cover the possible file types that cause server-side execution of ASP.NET code.
However, what happens if you've (even inadvertently) got an Umbraco installation running on a server where other server-side scripting handlers are in use? For example - perhaps Classic ASP or PHP. In particular, for Umbraco installations running on a shared hosting account, having Classic ASP or PHP enabled is more likely to be the default.
We identified that a compromised back-office account (even one with fairly limited access, only needing to be able to use the Media tab), could be used to upload an ASP or PHP script, which can then be executed server-side simply by accessing the Url. E.g.:
http://www.mysiteurl.com/media/1234/hack.php
As a proof of concept, I wrote and uploaded a simple Classic ASP script that outputs the contents of the site's web.config file - thus revealing database connection strings and other possibly sensitive information. Once you have the database connection string, there's a good chance you can then access (perhaps via a second uploaded ASP script), the back-end database for the site. Or you could use your ASP script to modify the template files, inject JavaScript nasties and so on.
So what I'm trying to say is that it could potentially be a big deal - especially if your site has certain content that is only available to logged in members (or using some kind of package for eCommerce, where the hacker might even be able to breach the database and retrieve customer data).
To mitigate the risk, there are two solutions. The first is to be aware of what server-side scripting handlers are installed on your server, and make sure all possible extensions are added to the disallowedUploadFiles list in umbracoSettings.config. However, this is still too permissive for us - did you know for example that the Classic ASP handler is also mapped to .cer files? Yes it is bonkers isn't it?
For the second solution (which we've adopted), we thought about the problem more logically - we realised that there was simply no legitimate need for any of the files found in the /media/ folder on the server to have script execution rights. After all, you're talking about PDF files, JPEGs and PNGs etc.
On Googling, I found this web.config file:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<clear />
<add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
</configuration>
Note: this isn't to replace the main web.config file for the site - you simply create a second web.config file that sits inside the /media/ folder (so /media/web.config).
So what does this do?
It clears the list of handlers for content within the /media/ folder, and adds just one back - intended for static files.
Basically, this means that if you attempt to access any Url that uses a script handler (.aspx, .php, .asp etc.), you will see a 404.3 error - "The page you are requesting cannot be served because of the extension configuration".
Other legitimate files (such as .pdf, .jpg, .png, .docx etc.) are unaffected and work as normal.
I'd recommend that if you run an Umbraco site, you might want to have a look at this issue and see whether the above web.config configuration works for you? If it doesn't break anything, then it would seem there is no harm in using it.
I'm blogging about this issue now, because I've first made the Umbraco team aware - who have created an issue for it - http://issues.umbraco.org/issue/U4-8472
Basically, in the umbracoSettings.config file, you're able to provide a list of "banned" file extensions. By default, these are:
- ashx
- aspx
- ascx
- config
- cshtml
- vbhtml
- asmx
- air
- axd
This seems to cover the possible file types that cause server-side execution of ASP.NET code.
However, what happens if you've (even inadvertently) got an Umbraco installation running on a server where other server-side scripting handlers are in use? For example - perhaps Classic ASP or PHP. In particular, for Umbraco installations running on a shared hosting account, having Classic ASP or PHP enabled is more likely to be the default.
We identified that a compromised back-office account (even one with fairly limited access, only needing to be able to use the Media tab), could be used to upload an ASP or PHP script, which can then be executed server-side simply by accessing the Url. E.g.:
http://www.mysiteurl.com/media/1234/hack.php
As a proof of concept, I wrote and uploaded a simple Classic ASP script that outputs the contents of the site's web.config file - thus revealing database connection strings and other possibly sensitive information. Once you have the database connection string, there's a good chance you can then access (perhaps via a second uploaded ASP script), the back-end database for the site. Or you could use your ASP script to modify the template files, inject JavaScript nasties and so on.
So what I'm trying to say is that it could potentially be a big deal - especially if your site has certain content that is only available to logged in members (or using some kind of package for eCommerce, where the hacker might even be able to breach the database and retrieve customer data).
To mitigate the risk, there are two solutions. The first is to be aware of what server-side scripting handlers are installed on your server, and make sure all possible extensions are added to the disallowedUploadFiles list in umbracoSettings.config. However, this is still too permissive for us - did you know for example that the Classic ASP handler is also mapped to .cer files? Yes it is bonkers isn't it?
For the second solution (which we've adopted), we thought about the problem more logically - we realised that there was simply no legitimate need for any of the files found in the /media/ folder on the server to have script execution rights. After all, you're talking about PDF files, JPEGs and PNGs etc.
On Googling, I found this web.config file:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<clear />
<add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
</configuration>
So what does this do?
It clears the list of handlers for content within the /media/ folder, and adds just one back - intended for static files.
Basically, this means that if you attempt to access any Url that uses a script handler (.aspx, .php, .asp etc.), you will see a 404.3 error - "The page you are requesting cannot be served because of the extension configuration".
Other legitimate files (such as .pdf, .jpg, .png, .docx etc.) are unaffected and work as normal.
I'd recommend that if you run an Umbraco site, you might want to have a look at this issue and see whether the above web.config configuration works for you? If it doesn't break anything, then it would seem there is no harm in using it.
I'm blogging about this issue now, because I've first made the Umbraco team aware - who have created an issue for it - http://issues.umbraco.org/issue/U4-8472
Comments
Post a Comment