If you have done ASP.NET, you may have incorporated ELMAH, a great of a tool for logging information and providing a dashboard to view it. As you can see in the following information, you get a nicely presented dashboard to page through and review any errors in full detail. It is a few steps above a regular trace.axd.

However, such information is a treasure trove for black hats. At my current job, there are a few applications that use ELMAH but the problem I see is that none of them have the security configured for production.  For each application, I was able to typed elmah.axd after each sites’ URL root, hit Enter, and see every error the application logged. Also, I was able to see what IIS version, authentication type used, and, worst of all, the users’ usernames! Since my discovery, I notified my colleagues of what the public facing ELMAH dashboard and referred them to the security configuration page to help them disabled remote access. The ELMAH site has a page on how to secure ELMAH. The page’s information will tell you how to shut off remote access by simply setting the ELMAH configuration node security’s attribute allowRemoteAccess to “1”. You could incorporate this change in your web.release.config for so that it is only applied during a web.config transformation upon publishing your site’s release build. The ELMAH article gets into more secure ways such as applying security based upon role authorization.

This insecure ELMAH made me wonder if there were more public facing sites using ELMAH that are not securely hidden from prying eyes. So, I did a google search using the search expression “inurl:elmah.axd Details Form“. I was looking for sites configured with Forms Authentication that showed usernames within ELMAH’s Detail page. What I found was not surprising. There were 217,000 results. the results consisted of sites discussing ELMAH while others were the actual details of a site’s error. Below is a sample of an insecure site (details censored).

Noticed I even blurred out the username on this details page! What you can do with this information is run a process to extract all usernames found in the details page and then run a dictionary attack of common passwords.

The takeaway is that ELMAH like most third-party components should be added to the security checklist prior to production deployment. The configuration of ELMAH based upon the ELMAH’s “Secure Error Log Pages” is fairly clear and simple.