Message-ID: <70f230c70605230924s6573140fwecdeaea2b6941e2d@mail.gmail.com>
Date: Tue, 23 May 2006 10:24:54 -0600
From: "Mark Senior" <senatorfrog@...il.com>
To: "Memet Anwar" <mmta.gm@...il.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: Circumventing quarantine control in Windows 2003 and ISA 2004


Any such quarantine control can be circumvented.

the Checkpoint VPN has a similar feature, which can be enabled if you
pay a pound of flesh per annum.  It can be circumvented in a similar
way - you have to replace a Checkpoint DLL with a custom compiled one,
such that the local checks will always return true.  I think the
specifics were posted either here or to FD a while ago.

There is just no way of verifying these things reliably.

You can raise the bar somewhat by doing the grading at the server end,
rather than telling the client the passing answers, but an attacker
who can figure out a reasonable set of answers will always win.

Cheers
Mark



On 5/18/06, Memet Anwar wrote:
> For those unfamiliar with MS quarantine control, you can read Jon Hassel's
> tutorial on Windows 2003 Network Access Quarantine Control (NAQC)
> [http://www.securityfocus.com/infocus/1794], and the ISA 2004 VPN Quarantine
> (ISAQ) feature [http://www.securityfocus.com/infocus/1799].
>
> A simplistic mechanism used in both NAQC and ISAQ enable users to bypass the
> requirement set by administrators (such as XP must run SP2, should have
> latest virus-def, etc.). The problem is due to how the requirements are
> validated, it is trivial for users to trick RRAS/ISA into believing that the
> client's system are always aligned with the requirements, regardless the
> actual condition.
>
> To illustrate my point, I will use Jon's article part-1 mentioned above,
> because it is much the same with Microsoft description on the subject that I
> see on MOC-2824B training material. Please refer to 'A Step-by-Step Overview
> of NAQC'-part of the article.
>
> There, step 1-7 will put the client connection into quarantine mode, which
> is fine. Step 8-9 shows that the CMAK profile will execute a client-side
> script to validate client's configuration based on the preconfigured
> baseline. If the client meets the requirement, the script should call
> rqc.exe with appropriate parameter. In Step 10-14, rqc.exe in the client
> send its result status to rqs.exe (the listener) on the server, along with
> its script version string. The listener then compare the script version
> string with its reference, before reconfiguring the session to a normal
> access.
>
> Now I see two weaknesses there.
>
> First, it is trivial for users to ensure that rqc.exe will always report
> success back to rqs.exe, regardless the actual condition of his/her system.
> The script (or any executables used) can be modified or replaced, and it
> will always work as long as the replacement knows what parameter must be
> obtained from CMAK, and what should be passed to rqc.exe.
>
> Second, in step 12, rqs.exe only performs string comparison of the script
> version to verify wether the correct script is in use by client.
>
> For example, if the admin-supplied script is a .cmd file, a user can replace
> the content with something like the following. Note that .vbs or .exe files
> can also be replaced, as long the same functionality is provided.
>
>  @echo off
>  @rem Use %ServiceDir% to locate rqc.exe.
>  SET RQCLOC=%1\rqc.exe
>  SET REMOVAL=get_this_from_the_orig_script
>  %RQCLOC% %2 %3 7250 %4 %5 %REMOVAL%
>
> I've reported this issue to MSRC as a design flaw that could allow what they
> call 'ungranted trust' [1]. Part of their response was:
>
> ==========
> 1) Regardless of whether the Quarantine Control returns success or not, the
> actual "authentication and authorization" is handled correctly.  You are
> correct, the Quarantine Control could be circumvented, however it is not a
> "security" feature. It is merely a tool to help administrators ensure the
> vast majority of their users will be held to a standard.  In the worst case
> scenario, a user with an "infected" or "unpatched" machine could be allowed
> access.  A malicious user would still be able to connect to the network with
> a "clean" machine and subsequently do something malicious.
>
> 2) <From ISA.chm::/FW_VPNSecurity.htm:>
> Security recommendations for a VPN
> * Use the ISA Server Quarantine Control feature, to provide phased network
> access for remote VPN clients. With Quarantine Control, clients are
> restricted to a quarantine mode before allowed access to the network.
> Although Quarantine Control does not protect against attackers, computer
> configurations for authorized users can be verified and, if necessary,
> corrected before they can access the network. For more information, see VPN
> and Quarantine
> <MS-ITS:ISA.chm::/FW_QuarantineOver.htm> .
> * The quarantine feature does not protect against malicious users on the VPN
> Clients network.
> ==========
>
> MSRC repeatedly stressed that according to ISA 2004 online help, the
> quarantine control 'is not a security feature'. And since this is not
> vulnerability, they may not provide a fix or advice against the use of
> rqs.exe and rqc.exe on Windows 2003 RRAS or ISA 2004 VPN quarantine.
>
> Security feature or not, it certainly not working as many admins would
> expect. What's the purpose of having a quarantine control, if by-design, it
> can be circumvented ? ;)
>
> Regards,
> Memet
>
> [1] Definition of a Security Vulnerability,
> http://www.microsoft.com/technet/archive/community/columns/security/essays/vulnrbl.mspx
>
>
>
>

Powered by blists - more mailing lists