Asp.Net.Vulnerability: Full Trust (current security problems and possible solutions)
From: Dinis Cruz (dinis_at_ddplus.net)
Date: 10/16/03
- Next message: Dinis Cruz: "Asp.Net.Vulnerability: Win32 API calls (potential security problems)"
- Previous message: Tom Kaminski [MVP]: "Re: content password"
- Next in thread: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]: "Re: Asp.Net.Vulnerability: Full Trust (current security problems and possible solutions)"
- Reply: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]: "Re: Asp.Net.Vulnerability: Full Trust (current security problems and possible solutions)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 16 Oct 2003 12:05:26 -0700
At the moment the only method available to disable direct Win32 calls
from Asp.Net pages (using for example: " Declare Function WinExec Lib
"kernel32" Alias "WinExec" (ByVal lpCmdLine As String, ByVal nCmdShow
As Long) As Long") is to reduce the website's trust level from 'Full
trust' to 'Medium trust'.
Although in some scenarios this is a valid solution, for ISPs this is
not acceptable because in the current (V1.1) release of the .Net
Framework the following objects don't support partially trusted code
(i.e. only work with 'Full trust')
- UI
- OleDb
- EventLog
- ODBC
- Oracle
- MessageQueue
- ServiceController
- DirectoryService
- Performance Counter
- Win32 calls required for User Impersonation
Although some of this restrictions would even be welcomed (for example
MessageQueue or EventLog), today it is unthinkable to offer .Net web
hosting services without support for ODBC or OleDB . Most database
accesses are programmed using ODBC calls and one of the main reasons
for the use the .Net (and previously the .asp) platform was the ease
of use and rapid development features of Access and SQL server
databases.
So, until Microsoft releases the next version of .Net (V2.0) or a
patch for this problem, the ISPs and anybody responsible for .Net
shared hosting environments, will have to execute their client's
website code with 'Full trust'.
Given the dangers and risks created by situation (remote command
execution, disclosure of usernames and system information, etc... ),
the only solution is prevention and detection.
After some online research we couldn't find any relevant discussions
about this issues, so we would like to propose the following ideas and
see if one of them does produce a valid and acceptable solution for
this problem:
1) Code Validation -
a) Create a tool that executes after all compilation is done (i.e.
when IL code is created) but before the IL code is converted to
machine code and executed by the OS. This toll would validate the DLLs
/ EXEs and approve or disapprove its execution based on the calls that
are made. For example if a DLL contains a call to the Win32's
"winExec" function then (unless the DLL has a special permission) its
execution will be denied.
b) This tool could be used on 'live' websites or could be used
offline (some of this might have to be developed by Microsoft). The
offline mode could be part of an 'Approval Mechanism'
c) This concept is the same as the one applied by the Anti-Virus
software that check for 'dangerous code' (i.e. virus signatures) on
files (downloaded from the web, attached to an email or copied to
disk) before they are executed by the system. The AV companies should
develop such products because they already have the core system, the
automatic updates, the report engine, the 24/7 security response teams
and the brands.
2) Improved security infrastructure:
a) Full daily backups on all data stores
b) Monthly re-Builds of all servers (automated procedure)
c) ability to rebuild a server in 1h:
i) Install OS and applications
ii) Install security policies and settings
iii) Import databases from backup (or live servers)
iv) Add users (if required)
v) Assign IPs
vi) decommission old server (if still live) and publish rebuilt
server without any loss of service
d) the ideal situation would be to have the servers in a cluster
environment where when one server is rebuilt (due to normal rebuild
practices or it was compromised), it can be removed from the network
without any loss of service
3) Have one website per virtual server (both running in a main server)
a) the idea would be to have the equivalent of VMware where a server
would host each website in its own 'virtual' server (like mainframes).
This would require a much lighter version of windows 2003 which would
have to be designed for such scenario. Another possibility would be to
use Linux which will be possible once the porting of the .Net platform
is fully completed.
4) Audit Website Folders and Files:
a) monitor and audit at OS level (using NTFS) all files that belong
to each user by analysing the logs stored in the Event Viewer
b) create custom reports per site / per user with details of whom
(from the inside) accessed those files
5) Only execute signed and approved code -
a) Two server scenario:
i) Development server (insecure)
ii) Live server (secure)
6) Reduce customer anonymousity -
a) Require authorized IPs to edit site
b) Require IPSec key to edit site
c) Validate identity using Credit Card system and other identity
schemes
7) Improve protection of important information (Such as usernames,
passwords, database connection strings, database data, etc...)
a) Never strore these information in clear text (always stored them
encrypted)
b) Etc....
Although Asp.Net is a giant leap forward on the technological
frameworks required to build more robust and secure web services,
unless these applications can be securely hosted, they will never gain
public acceptance and wide usage.
And unless a solution is found for this 'Full Trust' issue, nobody
will be able to provide secure hosting of Asp.Net code.
We believe in shared knowledge and the power of peer-review, that is
why we published our Asp.Net Security Analyser (see
http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=36ae9a2c-8740-4b52-924e-320edf64fba5)
as an open source web application, and why we are posting this
information online and asking for your ideas and suggestions.
Best regards
Dinis Cruz
dinis@ddplus.net
.Net Security Consultant
DDPlus (www.ddplus.net)
- Next message: Dinis Cruz: "Asp.Net.Vulnerability: Win32 API calls (potential security problems)"
- Previous message: Tom Kaminski [MVP]: "Re: content password"
- Next in thread: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]: "Re: Asp.Net.Vulnerability: Full Trust (current security problems and possible solutions)"
- Reply: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]: "Re: Asp.Net.Vulnerability: Full Trust (current security problems and possible solutions)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|