From: H D Moore (sflist@digitaloffense.net)
Date: Wed Mar 24 2004 - 23:36:08 EST
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
----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:51 EDT