ASP.NET padding oracle, check your logs!

Microsoft has now released a patch for the padding oracle attack, but most system owners will still need some time to test the new patch before going live with it. Until the patch is applied we need to keep an eye on our logs in order to detect potential attacks.

In ScottGu's FAQ post he informs that an attack attempt would generate a large amount of entries in the application event log. In the subsequent update he presents a revised workaround to block requests with an aspxerrorpath parameter. To detect attacks involving this parameter, we also need to look at the IIS logs.

Fortunately, Microsoft offers the LogParser tool — the swiss army knife for parsing large amounts of data from IIS logs, event logs, or even the registry or AD (!). Check it out!

I'll give some examples here on how LogParser can be helpful in detecting whether someone has been talking to the oracle in your ASP.NET enabled webserver. Note that LogParser is a command line utility and will open in a command prompt. Note also that some of the logparser commands included below have been broken over several lines to increase readability. If you experience problems, try running the command on ONE line in your command prompt.

Check the event log
In ScottGu's FAQ post on the vulnerability he informs that an attack attempt would generate a large amount of entries in the application event log:

Event code: 3005 
Event message: An unhandled exception has occurred. 
Event time: 11/11/1111 11:11:11 AM 
Application information: 
    Application domain: c1db5830-1-129291000036654651 
    Application Virtual Path: / 
Exception information: 
    Exception type: CryptographicException 
    Exception message: Padding is invalid and cannot be removed.

You can search for these events in the eventlog:

logparser "select count(*) from *.evt where Message like '%Padding is invalid%'"

This should give you something like this:

COUNT(ALL *)
------------
0

Statistics:
-----------
Elements processed: 402859
Elements output:    1
Execution time:     40.75 seconds

If the count is larger than 0, then there were entries in the log that needs to be inspected.

In that case, the matches can be dumped to a file called e.g. dump.csv by logparser:

logparser "select * into dump.csv from *.evt
where Message like '%Padding is invalid%'" -o:csv

This will output a file where the data fields are comma separated.

Check the IIS log
To further check what's going on in your webserver, use LogParser to search for requests containing the aspxerrorpath= parameter:

logparser "select count(*) from mybusywebserver.log
where cs-uri-query like '%aspxerrorpath%'" 

Which should yield something like this:

COUNT(ALL *)
------------
551

Statistics:
-----------
Elements processed: 2147336
Elements output: 1
Execution time: 13.81 seconds

The above query was run on  a logfile from a server lacking the customerrors configuration trick suggested by ScottGu. Running it on a file from a server with the recommended customerrors tweak (with the responseRewrite) applied should yield (unless someone is attacking you):

COUNT(ALL *)
------------
0

Statistics:
-----------
Elements processed: 1008100
Elements output:    1
Execution time:     8.61 seconds

If your logfile contains entries with the aspxerrorpath parameter, run the query again, but this time dumping the results to a csv file for closer inspection:

logparser "select * into dump.csv from mybusywebserver.log
where cs-uri-query like '%aspxerrorpath%'" -o:csv

More on LogParser
LogParser can handle several files simultaneously, just use a wildcard like I did, e.g. *.evt. LogParser will also handle logfiles from several servers. Very handy if you have clustered webservers — you can analyze logs across your cluster!

Check out the Logparser forum for more details on the magic bits.

LogParser rocks!