It's not the Network! Ok, maybe it's the network...

Jason Rahm

Subscribe to Jason Rahm: eMailAlertsEmail Alerts
Get Jason Rahm: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Oracle Journal, Microsoft Developer, CIO/CTO Update

Blog Feed Post

Let iRules Work Around that ASP.NET Padding Oracle Attack

The attack itself preys on a bug in ASP.NET’s AES implementation

Microsoft released advisory 2416728 on Friday after researchers Thai Duong and Juliano Rizzo demonstrated the attack on ASP.NET with their Padding Oracle Exploit Tool.  The attack itself preys on a bug in ASP.NET’s AES implementation, which you can read about over here at threatpost.  So what’s the reward for a successful attack?  It’s not going to allow the attacker to execute code or elevate rights, but it does all the attacker to read potentially sensitive data that could then be further used to compromise the system.

The mitigation for this attack is to obfuscate the server errors by ensuring that no matter what the error, the same error page is returned.  This can be done manually in your configurations by addressing the <customErrors> section of the web.config file, or, you can mitigate centrally at your web farm’s front door with (of course!) an iRule.

 

   1: when HTTP_RESPONSE {
   2:   switch -glob [HTTP::status] {
   3:     "4[0-9][023456789]" -
   4:     "5*" {
   5:         HTTP::redirect "http://my.site.com/defaulterrorpage.html"
   6:     }
   7:   }
   8: }

UPDATE – New details below

Thanks to Bertrand Le Roy for providing a few extra details.  For versions 3.5 RTM and below, the randomizing code is not necessary.  For 3.5SP1 and greater, the randomizing code should be in place, and if a redirect to an error page is used instead of an in-place rewrite, it should come after the random timeframe has passed.  I kept the random times to within 500ms and 1999ms for testing, but these are easily adjustable.  This is trivial in BIG-IP version 10+.  For testing, I’ve set some variables to track clock times before and after and redirect to ESPN, but obviously, the rule can be much shorter as shown immediately after.

   1: # TEST RULE #
   2: when HTTP_RESPONSE {
   3:   switch -glob [HTTP::status] {
   4:     "4[0-9][023456789]" -
   5:     "5*" {
   6:       set pre_t [clock clicks -milliseconds]
   7:       set delay [expr [expr { int(1499 * rand()) }] + 500]
   8:       after $delay
   9:       set post_t [clock clicks -milliseconds]
  10:       log local0. "[expr {$post_t - $pre_t}] ~ $delay"  
  11:       HTTP::redirect "http://www.espn.com"
  12:     }
  13:   }
  14: }
  15:  
  16: # CLEAN RULE #
  17: when HTTP_RESPONSE {
  18:   switch -glob [HTTP::status] {
  19:     "4[0-9][023456789]" -
  20:     "5*" {
  21:       after [expr [expr { int(1499 * rand()) }] + 500]
  22:       HTTP::redirect "http://my.site.com/defaulterrorpage.html"
  23:     }
  24:   }
  25: }
  26:  
  27:  

Also note that if you want to do the in-place rewrite instead of a redirect, there are plenty of examples in the codeshare, one of which I highlight in this blog post.

 

Read the original blog entry...

More Stories By Jason Rahm

Experienced predominantly in the networking realm over the last dozen or so years, Jason is expanding his horizons towards systems management and even trying his hand at python.

Jason assists in the maintenance duties for http://devcentral.f5.com, contributes frequently in the forums, and writes weekly on some cool geekery in the F5 product lines. When not working, Jason enjoys spending time with his beautiful wife Michelle and his four children. He is active and volunteers network administration duties at his church and if there are any remaining minutes in the week, he enjoys Wii & XBOX, tennis, racquetball, softball, etc. He does not enjoy running, but does (scratch that, thinks about doing) it anyway to recover his youthful appearance.