NACATTACK presented at BlackHatDC 2007

by Michael Thumann, Dror-john Roecher,

URL : https://www.blackhat.com/presentations/bh-usa-07/Roecher_and_Thumann/Presentation/bh-usa-07-roecher_and_thumann.pdf

Summary : Part I: IntroductionMarketing Buzz:
The last two years have seen a big new marketing-buzz named "Admission Control" or "Endpoint Compliance Enforcement" and most major network and security players have developed a product-suite to secure their share of the cake. As the market is still evolving and one framework has been quite successful on the market: "Cisco Network Admission Control". NAC is a pivotal part of Ciscos "Self Defending Network" strategy and supported on the complete range of Cisco network- and security-products. From a security point of view NAC is a very interesting emerging technology which deservers some scrutiny. We are able to hack the Cisco NAC-solution by exploiting a fundamental design flaw.
Part II: NAC TechnologyHow it works:
The basic idea behind Cisco NAC is quite simple: Before allowing a client admittance to the network the client is tested against a predefined set of policies. These tests are performed by a backend system (a Cisco ACS) which processes .credentials supplied by the client against one or more administrator-defined policies. Based on the result of these tests a client is categorized and a well-defined access-level to the network is granted. While the client is connected to the network it is repeatedly rechecked and the state of the client is reassessed. On a somewhat more technical layer the communication takes place using EAP over UDP with undisclosed Cisco-proprietary EAP messages and the UDP connection itself is secured using SSL. The connection-point to the network (e.g. the switch, wireless AP, Firewall, Router, etc.) acts sort of as a "translating proxy" between the client talking EAPoU and the Cisco Secure ACS server talking RADIUS [Client <-EAPoU-> Switch <-RADIUS-> ACS). Besides this "proxy"-functionality the connection-point also acts as an enforcing element of the security policy. Three somewhat different deployment flavours of Cisco NAC exist but the underlying concept admittance-level based on the result of a test is always the same.
For every .NAC-enabled application on the client a client-side agent provides so called credentials to the ACS server where they are compared against the defined tests to derive a posture token per application. From all application posture tokens an overall system posture token is inferred which determines the access-level granted to the client. The client-side agent of the framework responsible for the communication is the Cisco Trust Agent (CTA) which also includes the capability to report a few basic credentials (e.g. OS Version, Hostname, etc) without an additional NAC-enabled application. The CTA contains an API enabling third-party vendors to hook their applications into the NAC framework. Anti-Virus Vendors have been among the first to join the NAC-Alliance formed by Cisco.
Part III: The ProblemNAC is not secure by design:
The Cisco NAC solution contains at least one major design-flaw which enables us to hack (at least) two of the three different variants: The server authenticates itself to the client using a server-certificate and client and server establish a secure tunnel (something like SSL over UDP), but the client does not authenticate itself to the server, so we have a situation in which a component (the client) is authorized without prior authentication. After realizing this fundamental design-error, the idea of a posture spoofing attack was born and research started with evaluating different attack-vectors for their feasibility. In the end we decided to analyse the protocols used within the framework and code our own NAC-client which provides the ACS with attacker-supplied-credentials in order to get illegitimate access to NAC-secured networks.
Part IV: The Hackhow we did it
NAC is a complex system involving different protocols which are used in an odd combination. Especially the usage of SSL over UDP/EAP-FAST over UDP made the usage of SSL-Proxies for man-in-the-middle attacks or clear-text-traffic-analysis with standard methods impossible. So instead of focusing on the network-traffic (which was our first approachstare at the packets until you understand them), we decided to focus on the client first. Analysing the CTA client in different versions and on different operating systems revealed some of the inner workings of the protocols. Besides Client analysis we built a NAC test-lab and developed a NAC-test-suite to implement different admission-scenarios. While running theses tests we hooked into the interesting functions of the client in order to understand the functions used and their (inter)dependencies. As a next step we started coding our own NAC client to get a better insight into the communication process. The first goal was to get a clear text dump of the communication by establishing the secure tunnel. The next goal was to provide our own credentials to the ACS in order to get access to the NAC protected network. We will release our "NAC-Credential-Spoofing"-tool at the conference alongside with our insight into the operating of NAC.
Part V: Our proposed talk
We do not wish to simply release a tool; we want the audience to understand how Cisco NAC works, why it is not as secure as Cisco wants us to believe and which mitigations exist, if NAC is implemented (there actually exist mitigations and secure setup-approaches). We will present our approach, disclose technical details yet unpublished and release our tool. As an add-on-benefit we will explain how to tackle a complex system like NAC when doing security research.
Dror-John Roecher has enjoyed working with Cisco stuff for more than eight years and is usually busy assessing the security of enterprise networks and data-centers. He works as a senior security consultant for germany-based ERNW GmbH all over Europe and has published multiple whitepapers on security-related topics. He is a seasoned speaker and enjoys sharing his experience with his audience.
The last two years have seen him develop additional points of interests, as e.g. Mobile Security [he simply loves to play around with all the newest funky gadgets] and Endpoint Securitybut at the heart he still is a networker.