ASP.NET POET Vulnerability - What Else Can I Do?

For the past week (really, longer) there has been so much chatter about this recent exposed POET attacks. As soon as the ekoparty Security Conference was over...more specifically...when Juliano Rizzo was finished with his talk - the amazing folks at Microsoft were scrambling to understand if there was an actualy vulnerability, how it happens, what to do to detect a vulnerability, and how to prevent it. They were working around the clock, as evident by the Twitter activity and the slew of emails I received on the matter).

What is this attack?

ASP.NET uses encryption to protect data - preventing a client from tampering with it. The POET attack is a malicious client sending specific cipher text to a site. By analyzing the results, the attacker can learn about how the data was decrypted. This gives the attacker information on how to alter their plan and re-attack. This is described more fully on Scott Guthrie's post.

I've patched my site. Is there more I can do? Step aside, X-Files...we're talking "The web.config Files" now...

Absolutely! Let's go over some current best practices for web.config settings and what data you might store in that file.

  1. Generating New Encryption Keys (<machineKey> element) - If you are using these in your local web.config, considering that there has been a level of exposure due to the POET exploit, now would be a great time to consider updating these. This is typically used on a server with shared websites or ones that participate in a load balanced environment.
  2. Use trusted database connections when possible - If you can possibly use a trusted connection to your database, do it! If you are currently not using that, please consider doing so. Additionally, make sure that your database access provides your application with the "least privilege" possible. This would tend to be the most secure configuration (hint: there is always more secure!)
  3. Encrypt sensitive sections of your web.config - Scott Guthie has a post on this matter that should be considered. Especially if you must have usernames/passwords in your file. Ideally, anything that is sensitive that could help an attacker learn about your environment (server names, ip addresses, file paths, etc would fall in this category). This goes for data that your application may have stored in the <appSettings> element.
  4. Application isolation with dedicated AppPools - To ensure you isolate your applications, consider unique AppPools for each of your sites. This minimized the surface area of your application. It can also aid in using a trusted database conenction.
  5. Use "Release" builds of your assemblies - this is the best compilation scenario that your application can use.
  6. The <customErrors> element - Normally the advice here is to have it set to <customErrors mode="RemoteOnly" /> or <customErrors mode="On" /> so that your application doesn't expose internal information to nefarious clients.
  7. The <compilation> element - Make sure that you deploy your configuration in release mode - ala debug=false! Example: <compilation defaultLanguage="c#" debug="false" />
  8. The <trace> element - Tracing! Disable it! Example: <trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
  9. The <deployment> element - If you can set this in your machine.config, you should. Example: <deployment retail="true" />
  10. The <identity> element - If you use this, you are providing a userName/password. Consider not using it, or encrypt this section as described above. Example: <identity impersonate="true" userName="domain\user" password="thePassword" />
  11. The <processModel> element - This can potentially have a userName/passowrd. Consider not using it, or encrypt this section as described above. Example: <processModel userName="domain\user" password="thePassword" />
  12. The <sessionState> element - This can potentially have a SQL Server connection string configured. Consider not using it. But, if that is not an option, ensure you have a trusted connection for your SQL Server. Regardless of those options, please encrypt this section as described above. Example: <sessionState sqlConnectionString="..." />
  13. The <trust> element - This signifies the level of code access security that the application has. Use the least amount of access as possible. Example: <trust level="n" />

I would not call this an full exhaustive list of items that could be a problem, but these are the areas that strike me as very sensitive areas in your machine.config/web.config file. Please, consider these items with your current sites and your future deployments.



  1. Spongman Says:

    Your customErrors recommendation still leaves a site vulnerable to attack. You should follow the ScottGu's advice here...

  2. David L. Penton Says:


    I think you may be missing the point. I am not advocating ignoring ScottGu's advice. I am advocating FOLLOWING his advice, but also reviewing the rest of your web.config files for these additional items to be more proactive. As in the line "I've patched my site. Is there more I can do?".



  3. KristoferA Says:

    Great advise, the more layers of security the better if something goes wrong. (Not only against the current 'POET' exploit but for whatever will be the next 0-day vulnerability).

    FYI - to add another layer of protection against POET, I wrote a small (experimental) windows service that keeps an eye on the windows event log. If a remote IP generates a lot of cryptographicexception errors in a short period of time, the service can generate an alert email to a sys admin, and can add that remote IP to the windows firewall as a blocking rule. Feel free to take a look at it:

Leave a Reply