Re: Pen-tester's analysis of .NET security?

[H D Moore <[EMAIL PROTECTED]>]

On Wednesday 24 March 2004 13:47, Lachniet, Mark wrote:
> Is anyone aware of a whitepaper or analysis of the security features
> (and weaknesses?) of Microsoft's .NET platform for web applications? 

Breaking ASP.Net - Cansecwest 2002
http://www.digitaldefense.net/labs/presentations/Breaking.ASP.NET/

Covers overflow in the state server (fixed in post-1.0 update), session 
fixation through cookieless sessions, various common misconfigurations.

DotNetAppScan - Random Tool Release (TM)
http://www.digitaloffense.net/dnascan.pl.gz

Use some somewhat outdated tricks to get more information about the remote 
application's ASP.Net configuration (web.config). Sometimes this yields 
fun results (missing ViewStateMac, CustomErrors off, or Trace enabled).

The built-in input validation is rarely used on production web sites of 
any complexity, the application will throw errors even when benign data 
is entered into a text field. The end result is that most web sites don't 
use it, so XSS is fairly trivial.

If Forms Authentication crypto has been disabled, it is trivial to brute 
force a cookie value that decodes to a valid session. This is a rare 
occurrence, but people have been known to do it for performance reasons.

The VIEWSTATE variable is a base64-encoded Triplet object with a 
cryptographic hash appended to the end. You can find freeware ViewState 
decoders by searching google, the format really isn't too complicated. 
Analyzing the ViewState at various states can give you some hints as to 
how the application works. If crypto validation is disabled on the 
ViewState, very bad things can happen, fortunately this is rare...

If sliding expirations are enabled for Forms Authentication, there is a 
real chance of a session collisions. I know of one site which ran into 
this issue, users kept landing in other users sessions during the session 
renewal. AFAIK (and the MS changelogs show) this has not been resolved. 
The magic sequence here is to create a session (login), sleep til right 
before expiration, then renew again, you have a decent change of landing 
in someone else's session. This could have been application-specific (due 
to the key used to create the session), but if it happened there, it can 
happen elsewhere. 

The FileSystem class accepts unicode sequences IIRC, you can use this to 
perform directory traversal attacks in some cases.

SQL insertion is still a big concern, however I ran across a similar issue 
with XML data. Many ASP.Net apps will create XML data from form input, it 
is very possible to close out one element and create another one. This 
allows you to spoof all elements past the one containing user data. If 
this XML data is then used in file system or SQL operations, bad things 
can happen there too...

Anyhow, just a quick dump off the top of my head, if anyone else has more 
info to add, I would definitely be interested.

-HD

---------------------------------------------------------------------------
You're a pen tester, but is google.com still your R&D team?
Now you can get trustworthy commercial-grade exploits and the latest
techniques from a world-class research group.
www.coresecurity.com/promos/sf_ept1
----------------------------------------------------------------------------