Search the Site

My Social
Meta
Powered by Squarespace
« Weird 802.1x EAP-TLS Behavior with Windows XP SP3 | Main | Geotagging Nikon P7000 RAW files (NRW) »
Thursday
Jan202011

802.1x: Machine Access Restriction 'Vulnerability'

Today we ran into a feature of the Machine Access Restrictions (MAR) option in the Cisco Secure ACS Radius server. It seems that when you're using the ACS for 802.1x authentication, you have the option of demanding that the authenticating users can only be authenticated when the computer is already authenticated. This way, you make sure that no user can access the network without a legitimate PC.

The 'feature' works as follows; The computer authenticates itself by using PEAP (or EAP-TLS for that matter). The ACS needs to keep a track of computers that have successfully authenticated, so it can link a user logon to an earlier computer logon.
The ACS uses the RADIUS attribute Calling-Station-id for this. This attribute contains the MAC address of the network interface used in the authentication, and as most of you know, the MAC address isn't the most secure variable on a PC.

So the computer authenticates correctly, and the MAC address is stored on the ACS for future reference. Next, the user tries to authenticate, and during the RADIUS/802.1x communication the Calling-station-id is transmitted. This id is compared to the (cached) list of known Calling-station-id's, and if a match is found, the user is granted access. The user is denied access if the MAC address can't be found.

So gaining access to a network which 'demands' both machine and user authentication can be by-passed by spoofing the MAC address on another computer. Something that can be done quite easily. All you need is the MAC address of a computer that successfully authenticated, and a valid username and password to authenticate the user. The result is; an 'insecure' device on the corporate network with a valid username and password.

Note that you do need a valid username/password combination as well, so the 'intruder' is most likely an employee. It's not that your average hacker can log in just by sniffing a MAC address from across the street.

This phenomenon is not a bug. It's just a way to use the designed authentication method (for v5.2) in a different way. Every piece of documentation regarding the Cisco Secure ACS (v4.x and v5.x) describes the MAR mechanism, and leaves room for creative minds to explore the possibilities. There are some timers that can be altered, but these basically make the window of opportunity smaller. By default the Calling-station-id / MAC address cache is cleared every 12 (v4.x) or 6 (v5.x) hours. Setting it to e.g. 1 hour tightens the window of opportunity a bit, but it won't deter the employee who really wants his personal home laptop to access the corporate network.

Are there ways to protect yourself (as the corporate IT department)? Sure. For starters, if you're using EAP-TLS with both non-exportable user and computer certificates you can't use the credentials (the certificates) on another computer. The non-exportable option (which is a certificate template setting with the Microsoft PKI Services)) makes sure the key-paires can't leave the intended computer, or user profile, and that disables the possibility of authenticating from another device with those credentials. The downside it that the exploitation of an (internal) PKI environment has its own challenges.

Another possibility might be to use a RADIUS server that uses a different MAR technique, but I haven't found one yet. For as far as I could find, both the Microsoft IAS/NPS server, and Juniper Steel-Belted RADIUS server doesn't offer the MAR functionality.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>