IAS Shared Secrets Aren’t So Secret

Though by night I practice in the dark arts of computer science and engineering, during the day I play the part of a mild mannered network administrator. Recently I was taking stock of our backups, and as I was looking through some items that needed to be included in the nightly routine, I checked out our IAS server. We run IAS as we have a number of RADIUS clients, such as switches and other devices, that we like to have authenticate against our Active Directory. RADIUS connected to AD via IAS is super sweet, as there are quite a number of devices out there that support RADIUS, and you can get pretty detailed with the authentication rules of what is and isn’t granted access.

In IAS, to establish trust between the server and the RADIUS client, an administrator sets up a shared secret – basically a password that both ends agree to use to prove they are who they say they are during communication. Normally, you would expect such a password to at least be encrypted, or at least obfuscated in some manner to add a level of protection to snooping eyes. Microsoft has however, to my surprise, decided not take this route.

Viewing Shared Secrets

IAS stores its settings in two files under C:\windows\system32\ias – ias.mdb and dnary.mdb. If you’re a database user, you’ll notice mdb being the file extension used by Jet/Access databases. For the heck of it, being a tinkerer, I decided to link to these files with MS Access and see what I could see. They are indeed standard Jet databases – which is pretty neat from an integration perspective – with a simple ODBC connection you can read/write your IAS settings. There is a table called “Objects” that contains an entry for each one of your RADIUS clients. What was a little surprising, however, is there is a field labeled “Shared Secret” that contains, in very clear text, the shared secret password for each RADIUS client.

Now while users shouldn’t have access to this file normally, having a big, easy to use database full of passwords always makes me a bit nervous. Understandably hashing might not have been an option due to the need to deduce the original cleartext – but where authentication is involved, a little encryption would be nice, to at least dissuade the average script kiddie.

Not the security hole of the century, but certainly something to be aware of.

5 Responses to IAS Shared Secrets Aren’t So Secret

That is very interesting. If only I could figure a way to use this to my advantage. I need to create 400 new RADIUS Clients, with only the friendly names and IP addresses changing…..all will be using the same shared secret. Would be awesome to be able to do a mass import, especially since I have the name and IP info in a spreadsheet!

It’s been a while since I took a long at those two files, but there is a good chance you’d be able to mass import your entries with little problem if you have MS Access.

I would back up your MDB files first, but then create a new Access DB, import the info from your excel spreadsheet into a table. Then link to the Objects table. Then create a new insert query that takes the contents of the imported data and inserts it into the Objects table (you may have to massage the query and/or your import data to get the fields correct). I think it could definitely be worth it to save you the time of going through the GUI interface 400 times. Let me know if you do end up going this route, I’d be curious to see how it goes!

I might give this a go, although I’m sure my boss would just prefer that I spend the hours entering data instead of spending them trying to actually learn something!

Might not be so difficult if I knew anything about Access at all! Unfortunately my experience is limited to relatively flat tables with a few “lookup” tables thrown in to make entry easier (think simple inventory db)

Exported the tables into excel to look at them. Looks like the data is in 2 different tables:
Friendly name is in the Objects table. IP and shared secret are in the Properties table.

Could be as simple as copy and paste into that spreadsheet and then import back to access, but that would take just as long as the copy and paste I’m doing into the GUI.