Asp.Net.Vulnerability: Full Trust (current security problems and possible solutions)

Discussion in 'ASP .Net Security' started by Dinis Cruz, Oct 16, 2003.

  1. Dinis Cruz

    Dinis Cruz Guest

    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

    ..Net Security Consultant
    DDPlus (www.ddplus.net)
     
    Dinis Cruz, Oct 16, 2003
    #1
    1. Advertising

  2. Re: Asp.Net.Vulnerability: Full Trust (current security problemsand possible solutions)

    Dinis ..why not forward this as it should be to

    The Microsoft Security Response Center (MSRC) draws on the hundreds of
    security professionals at Microsoft to form virtual teams that respond
    to reports of security issues with Microsoft products or technologies.
    To report a suspected vulnerability, please send e-mail to
    .



    Dinis Cruz wrote:
    > 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
    >
    > .Net Security Consultant
    > DDPlus (www.ddplus.net)


    --
    "Don't lose sight of security. Security is a state of being,
    not a state of budget. He with the most firewalls still does
    not win. Put down that honeypot and keep up to date on your patches.
    Demand better security from vendors and hold them responsible.
    Use what you have, and make sure you know how to use it properly
    and effectively."
    ~Rain Forest Puppy
    http://www.wiretrip.net/rfp/txt/evolution.txt
     
    Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP], Oct 17, 2003
    #2
    1. Advertising

  3. Dinis Cruz

    Dinis Cruz Guest

    Dear Miss Bradley

    Thanks for your comment, to which you make 3 claims:

    1) we should have send this email to Microsoft, before we posted it
    in such a public forum
    2) that publishing details of such vulnerabilities in public is
    dangerous
    3) that I should act more responsible so that the whole industry
    gains

    I do agree that when a security consultant finds potential security
    problems with software as widely used as Asp.Net, it must act
    responsibly and provide details of the vulnerabilities discovered to
    the software manufacturer. With this in mind, I would like to tell you
    what happened on the last 6 months between us (DDPlus) and Microsoft:

    - Jan-May 2003 : We (DDPlus) worked on a couple of security
    projects that involved IIS and FPE2002 (FrontPage Extensions 2002) and
    we discovered that there where serious security problems with the way
    ACL permissions are managed and changed by FPE2002

    * During this period I participated in a couple of online
    discussions that where talking about the vulnerabilities that we
    discovered (some posts where from 2002, and nothing had been done
    since to fix the problem)

    - 16/May/2003 : Sent an email explaining the problems that we
    found to 22 Microsoft contacts (some I had meet in Microsoft
    briefings, some I found in security focused online newsgroups. This
    list included the UK's Microsoft Customer Services).

    - 90% of my emails where ignored or produced no relevant
    answers from those Microsoft staff (including the UK Microsoft
    Customer Services, which I never received a reply)

    - 11/June/2003 : Since the email exchange with the few
    Microsoft contacts that replied back was going nowhere, I sent an
    email to the ‘Microsoft Security Response Center'
    () detailing the problem and asking for
    Microsoft's solution for the IIS 5.0 FPE2002 vulnerability we
    discovered (although it affected all IIS 5.0 systems with FPE2002
    installed, it is a very serious problem for ISPs providing shared
    hosting environments). We mentioned on this email to Microsoft
    Security Response Center that we had just produced a Security guide
    for IIS 5.0 (sent attached) and wanted to include Microsoft's solution
    in the final version.)

    - 11/June/2003: posted on some newsgroups the fact that we had
    produced a security guide for IIS 5.0 and that we would send it on
    request. Please note that this guide contained a solution for the
    problem (i.e. vulnerability) that only the ‘unofficial' Microsoft
    contacts later confirmed its existence, but:

    - so far (20/Oct/2003), Microsoft never provided a Public
    solution for the vulnerability, which is probably caused by the fact
    that:
    - so far (20/Oct/2003), Microsoft never Publicly admitted
    that this was a security problem (at least for ISPs)

    - 13/June/2003 : Some of my original contacts finally started
    providing relevant information. They confirmed to me that it was a
    problem but that Microsoft had no plans to fix it.

    - In one email their words about this problem where:
    "...Yes, unfortunately I am saying that there is not solution for the
    problem in IIS5. It is acknowledged as an issue, and it *might* get
    fixed, but there is no firm plan to fix it...".

    - Regarding the fact that apparently windows 2003 had a
    solution (the use of Application Pools in IIS 6.0) they said
    "...Unfortunately, we don't currently have a plan to integrate this
    into IIS5. Actually there has been talk of it, but there are no firm
    plans and definitely not a timetable. If it's any consolation you are
    one of many who have requested this, so it might happen. The
    feasibility is being looked at right now..." and "...This was fixed on
    Windows Server 2003 as described in the article but the problem
    existed and was well known for previous versions. The solution for
    IIS 5 has been to disable things like the File System Object, Perl
    scripts and shared FTP access to sites in shared hosting boxes. It's
    not an issue on a dedicated box..."

    It is worth pointing out that our efforts are targeted to a Shared
    Hosting environment, a situation where dozens (or hundreds) of
    websites are hosted on the same server. This is clearly the situation
    of ISPs, but also affects companies that have dozens (or hundreds) of
    users editing their websites using FrontPage (for example:
    universities, major corporations, web developers)

    And I would challenge you to find an ISP that provided windows shared
    hosting services with FPE2002 and .ASP scripting enabled, that had
    disabled (in their servers) the File System Object or FTP.

    As you will see later on, this is a common response tactic by
    Microsoft, their answer to a problem is: "If you disable this
    ‘feature', the vulnerability will be resolved". The problem is that in
    the ‘real world' of (for example) ISPs, these ‘features' cannot be
    disabled, because normally they are the reason why the users are using
    the Microsoft development platform. This means that although
    Microsoft's response was technically correct, it didn't address my
    issue, since I was specifically talking about shared hosting scenarios
    such as ISPs.

    - 17/June/2003: I receive an email from the Microsoft Security
    Response team saying: "… We are having trouble identifying the
    specific vulnerability you are leveraging to exploit the system
    remotely. Right now it looks like you are gaining system access due
    to IIS configuration issues and insecure .asp pages ..."

    - Basically what Microsoft is saying ‘officially' is: "We
    (Microsoft Security Response Center) don't think that what you
    (DDPlus) found are vulnerabilities, since you are just creating
    ‘insecure' pages containing normal .asp code. So if you don't allow
    that ‘insecure' code to be uploaded to your server, you will be ok
    (i.e. secure)"
    - Which again, is technically correct, but they are
    assuming that I would be able to control the code uploaded to my
    server, which is something impossible to do by an ISP.

    - 20/June/2003 : Microsoft Security Response team sends me a
    link to a white paper that doesn't provide a solution to the
    vulnerabilities identified

    - 30/June/2003: I send a long email to Microsoft Security
    Response team explaining:

    - (again) what was the vulnerability that I was talking
    about and the fact that one of his colleagues at Microsoft had already
    confirmed that it was a problem
    - That I was specifically talking about shared hosting
    environments (such as ISPs) and not dedicated boxes
    - That I knew about that white paper and that it is was
    not relevant
    - What I thought should be Microsoft's next steps: 1)
    publicly acknowledge the problem and 2) work with the ISPs currently
    providing shared hosting services to fix the servers hosting hundreds
    of thousands of websites.

    - 01/Jul/2003: received an interesting email from one of my
    Microsoft contacts: "…I looked a bit more at your paper and while I
    can't comment in detail or officially endorse it in any way, I think
    it summarizes much of the common wisdom for securing IIS on Windows
    2000 based on what I've seen others do to secure the platform. I
    think you spent too much focus on the vulnerability and impact rather
    than showing how to secure the OS and webserver up front, but I think
    you may have been trying to get administrators attention on why they
    need to do this. If I wrote such a document, I'd probably come in
    with a different approach – indicating that IIS/Windows 2000 can be
    secure as long as you pay attention to the details, then providing the
    steps for making it secure. Still, I think it's always good to get
    out this information to customers no matter what the format if it
    helps them make their machines more secure. …"

    - This shows very well what is Microsoft's current
    position on security: "We will tell you how to make it secure, but we
    will not tell you how the system can be compromised (i.e. what are the
    vulnerabilities)", which create a couple on interesting scenarios

    1. If one doesn't know the risks, how can one know, when
    one is secure?
    2. How can one protect what one doesn't know?
    3. What happens when Microsoft knows the existence of an
    vulnerability but doesn't disclosed it to their users? Nor it advises
    those users of the potential problems?
    4. What happens when the vulnerability is also a feature?

    - What is interesting about this comment is that Microsoft
    does think that creating documents such as the one we created is a
    good way to raise awareness to the existent security vulnerabilities
    (note that our document contained a description of the problems, but
    is also provided a step-by-step guide to build a secure server)

    - 01/Jul/03: I sent to Microsoft our new security document
    "Security Vulnerabilities in Asp.Net" which contained an analysis of
    what we considered to be security problems when Asp.Net was used in
    shared hosting environments (such as ISPs).

    - The document contained detailed information about these
    security problems with Asp.Net: WSH and FSO, Authentication and
    impersonation, WMI – Windows Management Instrumentation, ADSI – WinNT
    accesses, ADSI – LDAP accesses, Internal Port Scan, W32 DLL calls,
    RevertToSelf()

    - 08/Jul/03: Microsoft Security Response Center finally responds
    to the issue raised in my 11th June email:

    "... In your initial E-mail to us you presented a whitepaper, that
    after clarification revealed one core issue--the Network+Interactive
    role that is shared in FPSE2002 and IIS5.0..."

    "... Currently, for FPSE2002 customers running Microsoft Windows 2000,
    an immediate mitigation is to disable FSO and WSH as presented in
    http://www.microsoft.com/technet/tr...et/prodtechnol/sharepnt/maintain/stssecur.asp...
    "

    "... Dinis, we take every security incident seriously, and our primary
    goal is to protect our customers. Here at the MSRC we work diligently
    to respond to vulnerabilities, and are dedicate to making sure that
    each one is resolved. While we normally do not review white papers,
    we've taken time to review each paper that you've presented to us and
    extrapolate vulnerabilities and respond to them in turn. Fortunately,
    not every report is actually a vulnerability. Often there are cases
    where a series of misconfigurations, or lack of best practices can
    lead to an suboptimal security situation for a customer. In that case
    we make every effort to provide detailed security guides and
    documentation to provide guidelines for successful employment of our
    products..."

    So basically Microsoft Security Response Center said "We know it is a
    problem and the solution is to disable FSO and WSH". This does solve
    most problems identified, BUT:

    1) as said before no ISP that I know provides shared hosting
    services with FSO (File System Object) disabled. And the main reason
    is because most .asp based websites would break if that object was
    disabled.

    2) the WSH (Windows Script Host) contains less side effects when
    its disabled. Actually it should had never been enabled by default in
    the first place! The WSH object allows the execution of commands on
    the server! This is one of the most serious vulnerabilities that we
    found. Now the problem here is that I have read most books that
    explain IIS 5.0 security and .asp security (I also have probably all
    ‘Hacking' books published today) and I never found the WSH identified
    as a serious vulnerability and the only times that I saw the
    recommendation about disabling is in 1 paragraph hidden in the middle
    of huge articles (which went completely unnoticed by the industry).
    The WSH is very dangerous for another reason:

    In IIS 5.0 (Windows 2000) If the WSH is not protected and the web
    server is configured to run in "Low process" application mode, then
    the commands will be executed under the rights of the system account,
    which means the script could easily create an administrator account,
    format the hard drive or access any website's data hosted in that
    server. And to bring this home, I have found several major ISPs that
    run their websites in "Low (IIS process) "application mode with WSH
    enabled!.

    3) but the main question is: "What do you do, if you can't disable
    FSO and WSH?" Well if you follow the guidelines from the security
    guide "Secure shared hosting with IIS 5.0", published by DDPlus (that
    is us) then you would still be safe! And this lead me to my next point
    which is:

    4) Microsoft Security Response Center, didn't review our white
    paper (as they claim), because our white paper contained much more
    information to which they never commented, namely:

    * What was their opinion on our solution? What is a viable
    and scalable one?
    * What could be done to make it more robust?
    * What really happens when FPE2002 using in conjunction with
    SharePoint team services, is upgraded with the Office XP service pack
    2? Did that really solve the problem?
    * What was their opinion of the 2 custom security templates
    we created (based on Microsoft's HiSecWeb.inf and NSA's
    W2k_server.inf) the ‘DDPlus_Mst_hisecweb.inf' and
    ‘DDPlus_NSA_w2k_server.inf'
    * What was their opinion on the proposed IPsec policy
    (‘DDPlus_ipsec_policy.ipsec') which aimed to close all unnecessary
    ports and communications?

    * And if the information contained in the security guide was
    accurate and would help ISPs to secure their servers, why didn't
    Microsoft publicly acknowledge the guide or released a similar one?

    At this moment in time (08/Jul/2003 , one month after I sent them the
    information) from the point of view of the Microsoft Security Response
    Center this case was closed. I haven't received any more information
    from them regarding this issue.

    Of course that meanwhile most ISPs where still vulnerable (except the
    ones that also found the solution or, the ones that read our security
    guide and used it to fix their security problems)

    - So now Microsoft's attention was focused on the document
    ‘Asp.Net Security Vulnerabilities' which we never published publicly
    (we only distributed it to known contacts or to who had requested the
    original guide). As I mentioned before this document advised Microsoft
    Security Response Center for the following security problems with
    Asp.Net when used in shared hosting environments:

    - WSH and FSO
    - Authentication and impersonation
    - WMI – Windows Management Instrumentation
    - ADSI – WinNT accesses
    - ADSI – LDAP accesses
    - Internal Port Scan
    - W32 DLL calls
    - RevertToSelf()

    - 17/Jul/2003 : I received Microsoft's response to the Asp.Net
    document:

    {Beginning of Microsoft's email}

    "…. We've taken a look at the issues you've presented in your
    whitepaper. Thank you for your patience, we did a deep analysis of
    each issue and that took some time. In the end, we've determined
    that, while you are showing interesting attack vectors, they all
    require full trust, and as a result are not new vulnerabilities. If
    you have full trust then you will be able to leverage that trust in a
    negative manner, as you have indicated. People that can execute
    arbitrary code can always try things like the attacks that you
    document; it's one of the costs of running arbitrary full trust code
    on someone else's behalf. …"

    "…The use of the V1.1 release of the .NET Framework and code access
    security will mitigate these threats that result from running code in
    full trust. Admins that choose to run applications in full trust can
    greatly mitigate what they can do by running them as an appropriately
    unprivileged account…."

    " …. In order to provide you with as much detail as possible, I've
    included a point-by-point analysis of each of the issues in your
    paper.

    " - WSH & FSO: This requires the use of COM interop, which
    also requires full trust"

    " - Authentication & Impersonation: this is basically someone
    running in a web process trying to guess passwords using whatever
    mechanism they might use (e.g. LogonUser or ADSI binds or WMI or
    whatever). All of these things require full trust today: LogonUser
    requires a platform invoke, System.DirectoryServices requires full
    trust, as does anything in native WMI or System.Management.dll (the
    managed WMI wrapper)"

    " - WMI: Use of unmanaged WMI through scripting or interop
    requires full trust."

    " - ADSI: Winnt Provider, requires full trust, whether via
    interop the activeds.dll or System.DirectoryServices"

    " - ADSI LDAP Provider: same as above"

    " - Port scans: Use of sockets in form from managed code is
    controlled via permissions. If desired, admins can grant no network
    access, HTTP access to selected URLs, or any set of socket access. "

    " - RevertToSelf: full trust code can always do this (as can
    COM objects in ASP or wherever else). As a side note note for the
    external, impersonation is not effective as an isolation mechanism
    even without RevertToSelf—merely switching threads will demonstrate
    this. Use of code access security or process/account isolation is
    required."

    " - Arbitrary native code in DLLs: requires full trust to do
    either interop or p/invoke..."

    {End of Microsoft's email}

    So the message is: If you don't allow your Asp.Net code to run with
    full trust, your applications will be safe, and none of the attack
    vectors that we (DDPlus) described would work.

    The problem (and now I will quote my last post which prompted you to
    criticize my public action) is that at the moment the only method
    available to disable direct Win32 calls (and the other issues
    mentioned) from Asp.Net pages is to reduce the website's trust level
    from 'Full trust' to 'High' or' Medium trust' (there is also the
    option to write a custom trust policy).

    Although in some scenarios this is a valid solution, for ISPs this is
    not acceptable because one the side effects of reducing the trust
    level are the disabling of functionality such as:

    - 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, again, Microsoft does have a solution that only works in servers
    dedicated to one client and hosting a couple of websites.

    I also find interesting their comment "...In the end, we've determined
    that, while you are showing interesting attack vectors, they all
    require full trust, and as a result are not new vulnerabilities …".
    Maybe these are not new vulnerabilities for Microsoft's Security
    Response Center, but I know that for the majority of the Asp.Net
    community and ISP industry, they are.

    Just do a research on the Net (Google, MSDN) for Asp.Net security
    issues in: WMI, IIS Metabase, ADSI WinNT provider, ADSI LDAP provider
    and the problem of having to run Asp.Net web applications with full
    trust; and you will find none or little information about these
    vulnerabilities.

    And as one can see from the title of the last email "RE: Document with
    ASP.NET security Vulnerabilities [MSRC1737mr] - Closed", from
    Microsoft's Security Response Center point of view this call was now
    closed. And indeed I didn't received any more communications from them
    since this date (17/Jul/2003)

    Although Microsoft didn't took this issues seriously, us (DDPlus) and
    a couple of (responsible and dedicated to security) ISPs that we are
    working with, continued to work on these problems, and without
    Microsoft help, arrived at the following conclusions:

    1) ‘Full trust' is not viable if it removes support for ODBC and
    OleDB, so there is no way an ISP will only host websites that run in
    ‘medium' or ‘high' trust in the current version of the .Net framework

    2) Assuming that the websites will have to run in ‘full trust' mode
    then what can be done to resolve the problems or reduce the risk:

    a) ' The FSO and WSH vulnerabilities can be resolved by
    applying custom ACLs on each website folder
    b) The IIS Metabase, ADSI WinNT and ADSI LDAP
    vulnerabilities can be eliminated by applying custom ACLs on the
    relevant Dlls
    c) The WMI vulnerability can be eliminated by using the
    WMI control MMC or applying custom ACLs on the WMI's dll

    From the original list provided to Microsoft Security Response
    Center the only one that we don't have a solution is the direct Win32
    calls which need more research and testing.

    But isn't something wrong with this picture? Why is this work being
    done by a couple of companies (us and some collaborating ISPs), and
    not Microsoft themselves? They have the resources and direct access to
    the .Net framework developers! Shouldn't they be the ones doing this
    research and publishing this results?

    Our overall objective is to be able to securely configure Asp.Net in
    windows 2000 and 2003 servers, which we as DDPlus will offer as part
    of our security consultancy services.

    - 08/Oct/2003 – We compiled most of all our knowledge and ‘proof of
    concept' code into a security tool called ANSA (Asp.Net Security
    Analyser) which runs as a web application in a server providing shared
    hosting services and tests that server for some of the identified
    vulnerabilities (we still haven't added all know vulnerabilities).

    NOTE that this tool was published with an OPEN SOURCE license,
    where we are providing for FREE our knowledge and experience. The idea
    is to leverage on the Asp.Net community in order to create short,
    medium and long term solutions for this problem.

    The tool was published on GotDotNet and we posted announcements on
    several newsgroups. I also sent an email to everybody that had
    requested our security guides in the past, AND to Microsoft Security
    Research Center ()

    - 20/Oct/2003 (Today) – I haven't received any response or feedback
    regarding this tool from Microsoft Security Research Center, or any
    Microsoft employee (somehow I thought that the Asp.Net developers
    would be interested in this), BUT I have received very good feedback
    and usage reports from several ISPs and IT managers.

    I can actually claim that ANSA (Asp.Net Security Analyser) has already
    helped several companies to improve their server's security (most
    where not aware that they servers where in such ‘insecure' state)

    Sorry about the long story, but I felt that only if I gave you the
    full picture you could understand my actions.

    --------------------------------------------------------------------------

    Now, coming back to your original comments:


    1) we should have send this email to Microsoft, before we posted it
    in such a public forum
    2) that publishing details of such vulnerabilities in public is
    dangerous
    3) that I should act more responsible so that the whole industry
    gains

    I think that I have answered point number 1). We did send this
    information to Microsoft, just to be told that it wasn't new
    vulnerabilities and that as long as the websites where executed in
    ‘high' or ‘medium' trust (which most ISP don't) these problems don't
    exist.

    On the second point: "publishing details of such vulnerabilities in
    public domain", I would call to your attention the following details

    - We sent this information to Microsoft on the 1st of July 2003,
    this is 3 ½ months ago. The common practice in the industry is to give
    the manufacturer 1 month (30 days) to solve the problem and publish a
    patch, before the vulnerability details are made public

    - From the Microsoft's point of view, these are not new
    vulnerabilities, so this information is already in the public domain

    - Our original security guide contained ‘proof of concept' code
    which we didn't publish publicly and only gave to security consultants
    or IT managers

    On the third point of "Should act more responsible so that the whole
    industry gains", taking into consideration that we have published a
    security guide for IIS 5.0 and an Security Analyser for Asp.Net I
    think that I can claim that our actions are benefiting the whole
    industry. But if you disagree I would be very interested in knowing
    your reasons.

    Let's also not forget the knowledge of a crowd is always bigger than
    the knowledge of an individual or small group. I am a firm believer in
    the Open Source model and in the free and unconditional exchange of
    information. I hope that in my posts this message is clear and that
    people will be motivated to participate because their contributions
    will help their community and themselves in the end.

    I hope that this (long) post explains the reasons behind our actions
    and also why we are having more a public debate about these Asp.Net
    vulnerabilities.

    I also hope that somebody at Microsoft will take this post seriously
    and convince the Microsoft's Asp.Net development team to start
    collaborating with us, and everybody that needs to provide secure
    Asp.Net shared hosting services.

    Thanks for your patience in reading all this,

    Looking forward to your comments

    Best regards

    Dinis Cruz
    ..Net Security Consultant
    DDPlus (www.ddplus.net)
     
    Dinis Cruz, Oct 20, 2003
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    1,061
  2. Dinis Cruz
    Replies:
    1
    Views:
    270
    Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
    Oct 17, 2003
  3. Dinis Cruz
    Replies:
    1
    Views:
    139
    Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
    Oct 17, 2003
  4. MOHR
    Replies:
    0
    Views:
    227
  5. Linda
    Replies:
    1
    Views:
    568
    Dominick Baier
    Aug 31, 2006
Loading...

Share This Page