Wednesday, August 27, 2014
 Now reading ...
Sep
17
Fri
Posted By Subodh on Friday, September 17, 2010
3939 Views


Is your DNN Pwned?

If you’re worried about the ekotalk ASP.NET vulnerability or the automated padding oracle attacks with padbuster, worry no-more the fix is pretty simple. DotNetNuke is affected simply because it is an ASP.NET application too although I doubt that the dire predictions made by the so called hack are really that bad.

So what is the Oracle padding attack?

Most cryptographic ciphers require that all messages be of some exact block size.  Most of the times, padding is used to ensure a consistent block size so that an encrypted plain text message can be broken into an exact number of blocks. In cases that this doesn’t happen, a well built application normally throws an exception specifying what the error was. The problem is, in case of the Microsoft Cryptographic APIs, there’s wee bit of too much detail about what went wrong and somehow people figured a way for this error to percolate up from an ASP.NET application.

Presumably, this behavior is serious enough that some attackers can send multiple ciphers to your ASP.NET application and depending on whether it receives a 500 Internal Server Error or a 200 OK (valid cipher), multiple such automated oracle (test whether something passed or failed) padding attacks for a known plaintext phrase can allow an attacker to compromise your site. How? Because the behavior of your DNN installation can be used to whether the supplied encrypted value is properly padded or not.

Sure, sounds harmless enough to me except that … there are a few already known plaintext values that can be used in an oracle attack and the exploit can soon be discovered.

How to mitigate the attack?

At present I didn’t spend much time on this, but since this is dependent on the gory details of what went wrong, lets just patch that part first

In your web.config, ensure that custom errors are redirected to a common page irrespective of the error which gives no clue as to what the real error is and debug mode is set to false.

<system.web>
.
.
.
<customErrors mode="On" defaultRedirect="/customerror.htm" />
...
<compilation debug="false" strict="true">
...
</system.web>

 


Update

Scott Guthrie has confirmed that this indeed is a possible exploit, along-with a much more detailed fix.

  
 You may also be interested in
  
Locations of visitors to this page Clicky Web Analytics 

Subodh's Blog Rating

 

DISCLAIMER

The opinion expressed
on this page 
is strictly that
of the page author
who has a
habit of animating
day-dreaming
and
fictionalizing
out of thin air.
 

The contents of this page
have not been
reviewed 
nor
approved
by 
Yahoo!

 Follow this blog
  
 Tag Cloud
  
Archives
 

Top 5 Posts of Last year
Copyright © 1995-2009 Subodh Shakya. All rights reserved.