|
|
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)