Adrian Dimcev's Blog

VMware View Desktops and MS12-020 = Potential Troubles

Sat, 17 Mar 2012 13:07:00 +0200

Assuming you have created a VMware View Desktops Pool, the end result will be that RDP is enabled on the View Desktops. [1]

In the context of MS12-020 [2][3], this means potential trouble especially when PoC is already available. It does not matter they are no directly accessible from the Internet, a worm targeting MS12-020 downloaded by one user on its virtual desktop could impact all the View Desktops local to it.

Even if you take the measure described in [1], I did not test so I’m not sure, I think the exploit still works.

So if you did not do it so far, make sure you install the MS12-020 patch on all your View Desktops. If you use Linked-Clone Desktops, patch the parent virtual machine, take a snapshot and recompose the Linked-Clone Desktops.

Alternatively, if for some reasons you can't apply the patch yet and if you’ve deployed vShield App, you can filter (deny) inside the port group were virtual desktops are located; add a deny rule for the RDP application selecting as both source and destination the port group while direction being inside for both of them.

References

[1] Prevent Access to View Desktops Through RDP
http://pubs.vmware.com/view-50/index.jsp?topic=/com.vmware.view.administration.doc/GUID-E9B84CCB-F0D5-4198-B986-2B46AD589452.html

[2] Why We Rated the MS12-020 Issue with RDP "Patch Now"
http://isc.sans.org/diary/Why+We+Rated+the+MS12-020+Issue+with+RDP+Patch+Now+/12781

[3]MS12-020 RDP vulnerabilities: Patch, Mitigate, Detect
http://isc.sans.org/diary/MS12-020+RDP+vulnerabilities+Patch+Mitigate+Detect/12808

[4] Proof-of-Concept Code available for MS12-020
http://blogs.technet.com/b/msrc/archive/2012/03/16/proof-of-concept-code-available-for-ms12-020.aspx

Inside Google’s pushing revocation list approach

Wed, 08 Feb 2012 23:55:00 +0200

A couple of days ago Adam Langley from Google published a blog entry [1] where some interesting statements are made; the most eye candy one is “we're currently planning on disabling online revocation checks in a future version of Chrome”. This is done as Google’s Chrome will include an alternative to the current OCSP and CRL methods of verifying a certificate’s revocation status (so called “online revocation checks”) .

What this means to you?
It means that Google will decide if a certificate was revoked or not. Not that Google can revoke certificates, but for some functionality issues -*fine irony here*- will likely not maintain a list of all revoked certificates; I mean all from all CAs. So assuming one revokes a certificate for other reasons than private key loss/theft, very likely this certificate will not appear as revoked in Google’s list(perhaps it will, if it belongs to a major company or so). The end result will be that Google Chrome’s users will be indefinitely MITM-able till that certificate expires in case the private key will be stolen(the admin does not care anymore as he did revoke that certificate isn't it ?).

It’s up to Google’s strategy and implementation of this to decide what will be included on the revocation list; knowing that there are some many CAs, finger crossed.

Furthermore, if you run your own internal PKI and you use Google Chrome you need to figure it out how do you plan to revoke certificates.

OCSP and CRL don’t work
We know that, but neither does Google’s strategy. It’s still a soft-fail blacklist mechanism; in fact can be worst than CRL in some aspects related to security.

What OCSP offers better in terms of security is its dynamicity. Remember the Diginotar breach, they did not know what certificates they issued; OCSP can help in this case but CRL and Google’s approach don’t(unless the intermediate CA cert is revoked).

Google’s pushing revocation list approach
For example Opera can push some PKI updates(e.g. remove a CA trust) dynamically without releasing a new version of Opera; Google could not do so till now. Pushing a list of revoked certs on-the-fly is an aid to the current revocation status mechanisms but does not necessarily replace them.

Google’s pushing revocation list approach is a soft-fail blacklist mechanism because in case the update mechanism fails, e.g. connection issues -*fine irony here*- , I doubt Chrome will block access to *all* SSL sites; mega single point of failure-*fine irony here*-.

In case of a MITM attack, Chrome will very likely rely on an old and expired revocation list:

First because it’s a blacklist approach so one must known about the rogue certificate and revoke it; yawn.
Second, Google must retrieve the needed CRL and push a new revocation list; sigh.
Furthermore even when the above two are true, the end user’s Chrome must have received the updated revocation list; dreaming.

Similar with OCSP and CRL an attacker still has an opportunity window even after the rogue certificate was discovered. Is this smaller or not, only “practice” can tell.

Blacklist Push vs Pull: is there any difference ?
In the most important aspect, not really, as both require a connection initiated by the client. It’s an ask for push or pull.

OCSP and CRL are pull(with some differences); Google’s approach is push.

Blacklist pull works for what you know and for what you may not know(OCSP case) whereas blacklist push only works for what you specifically know.

It is assumed that the attacker has full MITM capabilities over client; as we have seen in the past, attacks using rogue certificates can be targeted. So very likely the attacker controls both the pull and push channels(precisely the ask channel). And both are soft-fail; here comes the opportunity window.

The captive portal dilemma
If all the browsers fail such sites I believe it’s trivial to imagine who really has to change. We want to blacklist major root CAs but we cannot “blacklist” some captive portals.

Comparing the three

None will currently work in case of a serious MITM attack.
The most secure is OCSP if implemented properly; e.g. not using time-based freshness, issue a failed response for an unknown cert and drop the SSL connection when the check fails. Note that “simple” OCSP stapling can aid the MITM when the attacker replays old good OCSP responses.
Google’s approach can provide better freshness compared to CRL, but uses a selective list.
OCSP can be improved; CRL and Google’s approach not, or at least I don’t see how.
Google’s approach can be a good add-on to OCSP till the later is improved.

References

[1] Revocation checking and Chrome's CRL
http://www.imperialviolet.org/2012/02/05/crlsets.html

Forefront TMG 2010, Schannel and the SSL Renegotiation DoS

Fri, 02 Dec 2011 21:58:00 +0200

As you may be aware some time ago a tool[1] to exploit a known SSL Renegotiation DoS issue[2] was released. More technical details about the DoS can be found on Vincent Bernat’s blog[3].

What has this to do with Forefront TMG 2010 ?
It has if you published a secure server with TMG using the web server publishing rules because:

SSL client side initiated renegotiation is enabled by default(even when you don’t needed); I’ve notified about this Microsoft Security Response Center on 25.10.2011.
during the DoS attack hundreds of SSL handshakes are triggered within the same TCP connection nullifying TMG’s flood mitigation features[4].
TMG makes use of the (limited) Schannel so you cannot disable the client side initiated renegotiation on TMG if you use client certificate authentication[5][6].
TMG’s NIS currently does not include a signature to mitigate against the SSL Renegotiation DoS.

Schannel behavior
By client side initiated renegotiation we understand that the client(e.g. browser) is allowed to initiate SSL renegotiation to the server(TMG). This is not needed for secure web server publishing rules even with client certificate authentication. What is needed is the server side initiated renegotiation(for client certificate authentication), meaning allow TMG to initiate SSL renegotiation to client.

From what I have seen, on TMG when you use client certificate authentication:

between the client and TMG a SSL connection is established without the server asking for a client cert.
the client issues its HTTP request.
TMG renegotiates asking for a client cert.
if the client presents the correct cert will get access; if not an error (HTTP) message will be presented by TMG.

With the DisableRenegoOnServer registry entry[7] on the TMG(server) we can control two separate functions:

client side initiated renegotiation –> what we want to disable as we don’t want the server to respond to renegotiation requests from the client due to the SSL Reneg DoS issue.
server side initiated renegotiation –> what we need enabled as we want the server(TMG) to be able to initiate renegotiation requests to clients in secure web server publishing scenarios using client certificate authentication.

The Windows Schannel currently(to my knowledge) does not provide separate registry entries for the above functions.

Bottom of the line:

TMG, in its default configuration, is vulnerable to the SSL DoS renegotiation attack.
TMG in secure web server publishing scenarios using client certificate authentication is vulnerable to the SSL DoS renegotiation attack; no current work around on TMG itself exist. If you have another device(e.g. IPS) in front of TMG you may create(if possible) a rule to mitigate against the SSL DoS renegotiation attack.
Setting the DisableRenegoOnServer registry entry to 1 on TMG mitigates against the SSL DoS renegotiation attack but TMG will not be able to handle the above mentioned scenario.

Note: TMG can also be configured to request a client certificate[8] but this does not seem to need SSL renegotiation. There are further implications regarding to SSL renegotiation and TMG not discussed here.
Extra note: Sites published with TMG can be potentially found using Google. Set the DisableRenegoOnServer registry entry to 1 on TMG if you do not need the SSL renegotiation feature.

References:

[1] THC-SSL-DOS tool to verify the performance of SSL
http://www.thc.org/thc-ssl-dos/

[2] IETF mailing lists [TLS] SSL Renegotiation DOS
http://www.ietf.org/mail-archive/web/tls/current/msg07553.html

[3] SSL computational DoS mitigation
http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html

[4] Overview of flood mitigation
http://technet.microsoft.com/en-us/library/cc995196.aspx

[5] Using client certificate authentication for publishing over HTTPS
http://technet.microsoft.com/en-us/library/cc995097.aspx

[6] About Kerberos constrained delegation
http://technet.microsoft.com/en-us/library/cc995228.aspx

[7] Microsoft Security Advisory: Vulnerability in TLS/SSL could allow spoofing
http://support.microsoft.com/kb/977377

[8] Web listener advanced authentication options
http://technet.microsoft.com/en-us/library/cc995192.aspx