Watch Dogs in real life, or serious vulnerabilities in access control systems

It seems to me that many guys, especially at a young age, wanted to be cool hackers. Hack sites, phones, access systems. So I still have a little boyish enthusiasm. Therefore, periodically poking around in various software and did not find anything worthwhile. But one day, I turned up luck, and even some! ACS, full of vulnerabilities that allow access to the management of the entire system (opening / closing doors, adding your own pass card, etc.).

Interesting? Then welcome under the cat!

Everything described below was carried out on a test stand. The article is written solely for informational purposes and in general this is all an invention of the author.

ACS - access control system

It so happened that at one time I worked at a road construction company, where I wrote a set of programs for issuing permits, issuing food for these permits and reporting. It took me to integrate all of this with one fairly popular access control system. The developers have long responded to requests for documentation, and the deadlines were burning. I had to understand their software myself.

Approximate scheme of work of SKUD

I started learning from the database. The access control server works with the firebird 2.5 database. The login and password to it turned out to be standard, which is already very alarming, but the password can be set in the program settings. Passwords in the database to the accounts are hashed, but without salt, which is bad, but again uncritical. It stores all zones of passage, users, numbers of their cards, accesses and addresses of controllers.

DB

Then we take some program for sniffing traffic (I took “SmatrSniff”, the first one that could see the localhost traffic) and see what the client sends to the server. All data is sent over TCP and part over UDP in unencrypted form. And here the most interesting begins. The server first sends in open form the password from the database, its location and only then checks the login and password!

Password from the base "masterkey"

It turns out that, without knowing the login and password, we can get full access to the database, which gives us almost unlimited possibilities. We can issue a card with access to any object. Register your card to another user and enter under his name. But in order for this data to be loaded onto the controllers, you need to give a command to the server from the client. Although we can take the password to the client from the database, use the open MD5 bases and try to pick up the password to the hash (I remind you that the passwords in the database are without salt), but if the password is complex, then most likely nothing will come of it. We'll have to wait for someone to click on the full unload button.

Then I looked, but does authorization affect anything at all? For this, I tried to repeat requests to the server using the “TCP / IP Builder”. And yes, subsequent requests to the server, without authorization, do not work (sends a response in response to a failure). Here I am a little sad because the integration will have to implement the repetition of the entire authorization chain and only then send the package to download data to the controller.

Finally, I decided to repeat the request to transfer the door to open mode. The server responded “ok”, and the door squealed. Without any authorization. I repeated this from another computer on the local network and it worked too.

Approximate package view

This means that we can open / close any door from any computer on the local network. Register your card and immediately download this data to the controllers. After that, calmly walk through the objects and delete all logs of our visit.

I killed a couple of hours to study the protocol of communication between the controller and the server in order to break it completely, but I didn’t manage to fully understand the data format. But I am sure that there is no protection here either. The packages exactly have the mac-addresses of the controller and server / gateway (binding to the server goes to the mac-address, there are no encryption keys and the like in the database, so you can most likely pretend to be a server for the controller if you know the mac server). Unfortunately, there are no dumps and access to the equipment, so I can’t show it.

As a result, we have a complete ACS vulnerabilities that give us unlimited access to the passage to the objects. Because of the cheapness of the components and free software, this access control system is very common. She stands in many schools in Moscow, and I saw her at other sites. The company is proud of prizes at various events. I do not specifically name the name of this organization, and I also did not write to them about it. Because I think that such vulnerabilities at the architecture level cannot be fixed without rewriting all the software from scratch and updating all the equipment of people who bought this system (there are some more serious holes at the architecture level, but their description would have tripled the article). Those who have learned from the access control screen and it is installed at you - I advise you to completely isolate the network (which seems to be considered “best practices”) in which all the components of the system are located, and access to the database to add employees only through VPN. Proper routing configuration can also help.