RE: C# Exceptions

["Steven Scheffler" <steven () forwardslash com>]

In a (web)service orientated architecture, the message integrity is
crucial. I would suggest to encrypt the data sent through the network
and also digitally sign it. The desktop application validates the
signature and if its not valid it will reject the incoming data. If the
signature is valid then the app can decrypt the response and process it.

It's also recommended not to catch general exception like: 
catch (Exception ex) {}, but catch and handle different kind of
exceptions as in : catch (NullReferenceException  nullex) {} or catch
OverflowException, etc.

Many ppl forget about .NET Configuration in the Control Panel, where you
can set permissions and security of your assemblies on enterprise,
computer, user level. Running 'Full trust' means that your assembly is
allowed to execeute anything. Eg. Why have File IO enabled for an
assembly if your app is not using it?
Load your assembly in the global assembly cache (GAC) and give it a
strong name to avoid name spoofing.
Is your config file encrypted? We all know it's just a simple xml file,
a Trojan can easily post it to a server and get your database
connections, etc.

Another issue is that through reflection, ildasm you can re-construct
the source code of a managed app (see .NET Reflector). It's also
possible to patch system assemblies. It is possible to bring the
Framework to its knees with fuzzed data. You cant really trust anything,
but do your best to detect it and do some defensive coding.

You should also keep in mind that the .NET framework is mainly a wrapper
over WIN32 API. Which means that if there is a buffer overrun in a win32
dll, it can be invoked and exploited from managed code as well. Like the
WMF file handling vulnerability in gdi32 going around few months ago.


-----Original Message-----
From: Patrick [mailto:patrick () curioustechnology com] 
Sent: Monday, August 28, 2006 2:21 AM
To: '3 shool'
Cc: pen-test () securityfocus com
Subject: RE: C# Exceptions

To my knowledge, no one has successfully executed code using a buffer
overrun in .Net.  The .NET CLR is not a good target for executing shell
code.  If you do manage to do this, pat yourself on the back, post on
bugtrack and be prepared to have made a significant impact on the
software
industry.  Please site me as your first detractor ;)

Crashing .net itself ain't hard.  I'm an example of the type of dev
who's
done it regularly!  As I mentioned before, I'm unaware of anyone having
successfully used a .net overrun to execute code.  It may be possible,
but
it's been 6 years since .NET came on the scene and so far MS has been
very
successful on delivering on the promised enhanced security that the
marketing folks have always referenced.

I alluded before to the [unsafe] keyword.  Read more on [unsafe] here:
http://www.codersource.net/csharp_unsafe_code.html.  The only known way
to
do code execution via the stack would be if the target app used
[unsafe].
Just a caveat- I don't believe that [unsafe] is provided in vb, so be
double
sure your app is built with the environment that you think it is if
you're
going to cross your fingers and go after an [unsafe] opportunity.

As far as your best opportunity for penetration, go back to targeting
the
environment rather than the application.  On the other hand, perhaps you
have dependencies on other applications that may lead you to an
executable/command line environment via the web services interfaces
they've
created.  I'm sure you've seen SQL injection attacks that reverse shell
out
a command line with xp_cmdshell.  I assume you've already exhausted this
end
of things though and if you're still struggling, I'd say it's time to
spend
time with your Nessus dumps and start thinking about service
configurations
or old versions of IIS.

Good luck!



-----Original Message-----
From: 3 shool [mailto:3shool () gmail com] 
Sent: Saturday, August 26, 2006 10:36 PM
To: Patrick
Cc: pen-test () securityfocus com
Subject: Re: C# Exceptions

Patrick, thanx for the detailed email.

We are able to crash the application over the network by intercepting
the traffic that goes in  to the target application from the
legitimate web serivces. We got these three different exceptions for
different type of fuzzed data. Now before we move forward we were
planning to see what would be our best option out of these three
exceptions or memory dump that could give us remote code execution or
at least best chance of penetration.

Since buffer overruns are not possible in a .Net applicaiton what if
we target a bufferoverrun in .Net itself? We got a couple of crashes
that crashed .Net instead of generating any exceptions.

If we were to pursue our best possibility of penetration what would it
be?


------------------------------------------------------------------------
This List Sponsored by: Cenzic

Need to secure your web apps?
Cenzic Hailstorm finds vulnerabilities fast.
Click the link to buy it, try it or download Hailstorm for FREE.
http://www.cenzic.com/products_services/download_hailstorm.php
------------------------------------------------------------------------

This e-mail message is confidential and intended solely for the person to whom or the entity to which it is addressed. 
All the contents and any attachments remain the property of VR Services (Pty) Ltd unless so stated by contract.
If you are not the intended recipient, you are prohibited from reading, copying, using or disclosing this message to 
others. 
If you received this message in error, please notify the sender immediately by replying to this e-mail or by 
telephoning +27 21 528 9300 and thereafter delete the message. VR Services (Pty) Ltd does not accept liability for any 
personal views expressed in this message.

------------------------------------------------------------------------
This List Sponsored by: Cenzic

Need to secure your web apps?
Cenzic Hailstorm finds vulnerabilities fast.
Click the link to buy it, try it or download Hailstorm for FREE.
http://www.cenzic.com/products_services/download_hailstorm.php
------------------------------------------------------------------------