Posts tagged #802.1x

Cisco ISE MAC Addresss Database Clean Up

Imagine having 15.000+ MAC addresses in a Cisco ISE database. All these MAC addresses are used to gain access to wireless networks protected with WPA2-PSK and MAC-filtering. But how to make sure that they are all (still) valid?

Remove MAC Addresses After Change In Authentication

Finally, the time has come to implement 802.1x on the wireless network for a substantial amount of these devices. These devices are consist mainly of Windows machines or Thin Clients. Both of those are managed through either the Microsoft Active Directory or a Thin Client Management Suite. So, applying setting related to 802.1x are pretty straight forward to distribute. There are however some Windows / Thin client devices that will remain on the MAC-filtering wifi networks for numerous reasons.

After a few tests the migration of the new 802.1x devices has started, but is leaving us with a MAC Address database filled with addresses that can be removed, since they are no longer used…. But how to do that? Cisco ISE has a lot of features, and is capable of generating rich reports about almost everything. However it has no way of reporting on dot1x devices that might still remain in the MAC address database as well. That is where I had to become creative.

First I explored the Cisco ISE Monitoring API, but that only gives active connections. There’s no way of exploring past (successful) authentications/authorizations. I needed a way to get current and past successful dot1x authentications and compare the MAC addresses associated with those entries to the MAC address database, and remove those from that database.

Eventually, I found two paths to accomplish this; First through the reporting module. There you can export all RADIUS authentications to CSV. Filtering these results in Excel, or through Python scripting, you are able to extract the MAC Addresses that successfully authenticated with dot1x. Feed these MAC addresses to a script and remove them through the Cisco ISE ERS API. Or if you’ve got nothing else to do; do it by hand.

The other path is by following the syslog output and parsing that feed. The downside to this is that you have to have syslog file access or add an additional syslog server to Cisco ISE that you may access (e.g. your scripting machine). The syslog version makes a a bit more tricky, since the (syslog)log lines are very long and you have to combine the correct lines to get the full message. Parsing CSV is much easier, so I followed that path first.

Dormant/Obsolete MAC Addresses

Another issue with static MAC addresses (and even local accounts) is that they tend to remain indefinitely in the MAC database. Lang after devices have been decommissioned, the MAC address remains. Which leaves a security hole to be exploited.

By using the generated ‘RADIUS Authentications’ reports over a longer time (e.g. 90 days) you can do a cross reference with MAC addresses in the database and recent successful authentications of that MAC address.
There are some caveats though;

  1. you need a session-timeout on the network (either statically defined on the network device) or by RADIUS return attribute, so that devices have to re-authenticate periodically. Otherwise you might not see a valid device in the logging and removed it by mistake.

  2. RADIUS Reporting goes only 30 days back, so you have to combine several (scheduled) reports to achieve a longer time span. There used to be a custom time frame option, but seems to have disappeared in version 2.6

Cisco ISE v2.6 and Google ChromeOS

While playing around with the new Cisco Identity Service Engine (ISE) v2.6 (patch2) I stumbled upon a security feature while testing Wireless 802.1x access with an Acer Chromebook (ChromeOS v75.0.3770.144). When connecting to the 802.1x enabled SSID the connection failed, while other devices (Windows 10, Apple iOS and MacOS) connected just fine.

The problem is the client EAP handshake and usually this relates to untrusted server certificates. This happens to me a lot since I use different RADIUS services for my testing SSID’s.
So after clearing the SSID settings (forget) on the Chromebook it should work, but it didn’t.

The logging showed that the EAP handshake failed because the client didn’t offer a suitable cipher to the ISE server.

Turns out that Cisco ISE v2.6 has SHA1 disabled by default, and you need to enable it in:

Administration -> System -> Settings -> Security Settings

With the setting ‘Allow SHA1 Ciphers’, and ‘Allow only TLS_RSA_WITH_AES_128_CBC_SHA’ the Chromebook was able to connect to the 802.1x enabled SSID using old/depricated ciphers.

Now I wonder why the Chromebook still uses SHA1 based ciphers for secure communications, since Google Chrome started to abandon SHA1 as one of the first browsers….

Even installing the ‘Powerwash for added security’ feature in ChromeOS didn’t enable or add stronger ciphers on the Chromebook.

Posted on July 31, 2019 and filed under Tips'n Tricks, Security.

Create An 802.1x Evil Access Point

The last couple of weeks, I've been playing with Kali Linux to explore exploits on networks (wireless and switched networks). One of the exploits I'd liked to explore was that of an 'Evil Access Point' which can be done with Kali Linux and a suitable wireless LAN adapter.

An Evil Access Point creates an wireless network SSID to lure unsuspecting users/computers in to connecting to it. This network is pretending to use 802.1x for security (which is mainly used in corporate network environments), and those networks require typically a username and password (or certificate) to connect.

When the user/computer tries to connect, it (the evil AP) collects the user-name and a hash of the password. The password can be recovered by using dictionary files, rainbow tables, or by using brute-force. After the password has been found it can be used with the captured user-name to connect to the corporate network.

Posted on April 12, 2015 and filed under Security, Tips'n Tricks.

Weird 802.1x EAP-TLS Behavior with Windows XP SP3

I'm currently busy with several 802.1x implementations in corporate networks, and in one of those environment I get the strangest behavior in regards to the authentication process.

In this particular case I use a Microsoft 2008 Active Directory. Mandatory for distributing the wired network adapter settings in regards to 802.1x. The clients are a mix of Windows XP (SP1 and SP3) clients and some newer and/or exotic operating systems. The authentication mechanism of choice is EAP-TLS with dynamic VLAN assignment. The RADIUS server used is the Cisco Secure ACS v5.x appliance.

During the authentication process of the XP SP3 PC's I saw that the first authentication attempt was made with the PEAP mechanism. Since PEAP isn't allowed, the authentication mechanism failed. About a minute and twenty seconds later the PC started another dot1x authentication sequence. This time using EAP-TLS, and the PC got access to the network.

Posted on January 29, 2011 and filed under Annoying, Operating Systems, Security.

802.1x: Machine Access Restriction 'Vulnerability'

Today we ran into a feature of the Machine Authentication 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.

Posted on January 20, 2011 and filed under Security, Software, Tips'n Tricks.