RE: Circumventing quarantine control in Windows 2003 and ISA 2004
This is something that has been reported to Microsoft many, many times
for nearly two years (at least the NAQC) issue (including by me), and
yes, their response is the same as you have reported. The real answer is
not to use it if it doesn't meet your needs. There is no better vote
than with dollars.
Another solution is to build a better authentication/authorization
mechanism than a simple string, say something along a challenge-response
solution with a timestamp. It can be done, it's only unfortunate that it
takes much additional programming on both the client-side checks and the
authentication/authorization response.
Personally, I think it is one of the most unfriendly NAC/NAP products
out there. Hard to configure, requires RRAS (although not IAS as most
people think), requires non-legacy Windows clients, and has many
security gaps. The next version will be better, but I find it hard to
believe it will be better than all the other solutions I can plug in and
get running in under an hour across a wide spectrum of clients (e.g.
Verniers EdgeWall, StillSecure, etc.).
I've covered many network access control solutions for InfoWorld, and we
are doing some more product reviews soon. I encourage anyone interested
in network access control solutions to search on a few of these products
on www.infoworld.com, to see the good and the bad of each, before buying
one. None are perfect, but there are certainly a few solutions that are
far ahead of the game in terms of ease-of-use, platform support,
protocol support, and security.
To Microsoft's credit, NAQC is free (currently...there may be an
additional license fee in the future) with Server 2003, so it's a free
option for many administrators, who only need what it has. If anyone is
interested in how to configure NAQC, just send me an email and I'll send
you step-by-step slides.
Roger
*****************************************************************
*Roger A. Grimes, InfoWorld, Security Columnist
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: roger_grimes@xxxxxxxxxxxxx or roger@xxxxxxxxxxxxxx
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************
-----Original Message-----
From: Memet Anwar [mailto:mmta.gm@xxxxxxxxx]
Sent: Thursday, May 18, 2006 5:50 AM
To: bugtraq@xxxxxxxxxxxxxxxxx
Subject: Circumventing quarantine control in Windows 2003 and ISA 2004
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/essa
ys/vulnrbl.mspx