Difference between revisions of "Vuvuzela"
| Line 9: | Line 9: | ||
* Centralized management of groups and access rights | * Centralized management of groups and access rights | ||
* Platform for easily programming actions not limited to sounds on RFID swipe | * Platform for easily programming actions not limited to sounds on RFID swipe | ||
* Secure access control nodes | * "Secure" access control nodes | ||
=== System Overview === | === System Overview === | ||
| Line 15: | Line 15: | ||
So far, we've assembled a prototype system that works like this: | So far, we've assembled a prototype system that works like this: | ||
* The central server MySQL database puts our members into groups, like IT-Staff or Members | * The central server [https://www.mysql.com MySQL] database puts our members into groups, like IT-Staff or Members | ||
* A central server daemon generates access control lists (ACLs) from tables in a MySQL database | * A central server daemon generates access control lists (ACLs) from tables in a MySQL database | ||
* These ACLs are pulled from the central server by each node, using rsync | * These ACLs are pulled from the central server by each node, using [http://linux.die.net/man/1/rsync rsync] | ||
* Each ACL is specific to a node and relay pair, and is just a table in a SQLite file | * Each ACL is specific to a node and relay pair, and is just a table in a [https://www.sqlite.org SQLite] file | ||
* A node is a [http://www.raspberrypi.org Raspberry Pi], with an RFID reader fed into its GPIO, and a relay shield to operate up to four locks | * A node is a [http://www.raspberrypi.org Raspberry Pi], with an RFID reader fed into its GPIO, and a relay shield to operate up to four locks | ||
* Logging is sent back to the server via the SQLite file, and aggregated | * Logging is sent back to the server via the SQLite file, and aggregated | ||
| Line 34: | Line 34: | ||
* [http://raspberrypi.stackexchange.com/questions/4637/cannot-read-input-to-sda-scl-gpio-pins Stack Exchange Raspberry Pi Q&A - Cannot Read Input to SDA/SCL GPIO Pins] | * [http://raspberrypi.stackexchange.com/questions/4637/cannot-read-input-to-sda-scl-gpio-pins Stack Exchange Raspberry Pi Q&A - Cannot Read Input to SDA/SCL GPIO Pins] | ||
=== Hacking === | |||
There are some possible ways to hack this system, and some counter-hacks. | |||
One way is to swap out the SD card on the Raspi. Our plan was to put the node into an enclosure, like the kind used to lock up a thermostat. Even if the SD card is replaced, the attacker needs the right software installed plus the location of the SQLite file. Plus, we'll be putting the nodes behind the secured door. | |||
Another attack would be to perform [https://en.wikipedia.org/wiki/Man-in-the-middle_attack man-in-the-middle] on rsync. We'll take a couple of measures to mitigate that, including putting the nodes on their own dedicated subnet, with firewall and routing tables that drive traffic and communication only to the centralized server. So, the attacker would have to get onto our protected members-only LAN, and then bypass the firewall and routing tables to initiate MITM. Of course, by passing StrictHostKeyChecking=yes as an argument to rsync, then the transfer isn't initiated. | |||
Failure to sync just means that any new users won't be allowed to open a lock, so anyone in the existing group can still get in. | |||
The next obvious point of attack is the central server. A user that obtains root on our central server could reset the MySQL root password and then alter the MySQL tables to include the attacker's RFID token ID into the target ACL. Physical access to the central server is restricted by the server room door. | |||
A service exposed to the internet or the public LAN at the space could be exploited on the central server. However, the server would be on a dedicated subnet for administration machines, and traffic limited to it. There would be no reason for the central server to be exposed to the internet. An attacker would have to VPN into the Freeside members-only subnet as an administrator in order to be allowed to ssh into machines in the administration subnet. | |||
Because the node will be on battery backup, the next most viable attack is to cut-off the power and wait for the battery to die. We would likely broadcast a power failure to IT, so we'd know to come down and wait for the power to come back up. That means the attacker would have to cut off the internet access as well. Probably a polling script could notify IT of an internet outage, so it would be 1-2 hours maximum that we wouldn't know both services were down. Since the Raspi is a low-power device, it would remain operational and keep the doors locked for several hours, at least 12+ hours. | |||
The most viable attack would be either robbery of a member RFID card or [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis rubber hose cryptanalysis] - so keep your RFID cards safe, and [[IT| let IT know]] the minute you lose any of them! | |||
=== Future Work === | === Future Work === | ||
Latest revision as of 04:21, 29 January 2013
Open Source Access Control
The Vuvuzela project was originally meant to recreate our member welcome noise: whenever a member would strike their RFID badge, a sound of their choice would play.
It then grew into a larger effort to create an access control solution for Freeside that would have the following characteristics:
- Centralized management of groups and access rights
- Platform for easily programming actions not limited to sounds on RFID swipe
- "Secure" access control nodes
System Overview
So far, we've assembled a prototype system that works like this:
- The central server MySQL database puts our members into groups, like IT-Staff or Members
- A central server daemon generates access control lists (ACLs) from tables in a MySQL database
- These ACLs are pulled from the central server by each node, using rsync
- Each ACL is specific to a node and relay pair, and is just a table in a SQLite file
- A node is a Raspberry Pi, with an RFID reader fed into its GPIO, and a relay shield to operate up to four locks
- Logging is sent back to the server via the SQLite file, and aggregated
For example, we could attach two door locks to one node: the server room door on relay 0, and the front door on relay 1. The node named "joker" would pull down the ACLs for joker-0.db and joker-1.db from the server's /srv directory. joker-0.db has a table called "access" which is just a list of acceptable 8-character token IDs, which correspond to the RFID token IDs that are assigned to each member in the "IT-Staff" group. Likewise, joker-1.db just has the token IDs for each member of "Members" group. So, any Freeside member can get in the front door, but only IT staff can get into the server room.
In addition, we could send notification emails to the head of IT every time the server room was accessed.
If you're interested in helping out with this project, contact Alan about participating, or follow the project at:
Some other related material:
Hacking
There are some possible ways to hack this system, and some counter-hacks.
One way is to swap out the SD card on the Raspi. Our plan was to put the node into an enclosure, like the kind used to lock up a thermostat. Even if the SD card is replaced, the attacker needs the right software installed plus the location of the SQLite file. Plus, we'll be putting the nodes behind the secured door.
Another attack would be to perform man-in-the-middle on rsync. We'll take a couple of measures to mitigate that, including putting the nodes on their own dedicated subnet, with firewall and routing tables that drive traffic and communication only to the centralized server. So, the attacker would have to get onto our protected members-only LAN, and then bypass the firewall and routing tables to initiate MITM. Of course, by passing StrictHostKeyChecking=yes as an argument to rsync, then the transfer isn't initiated.
Failure to sync just means that any new users won't be allowed to open a lock, so anyone in the existing group can still get in.
The next obvious point of attack is the central server. A user that obtains root on our central server could reset the MySQL root password and then alter the MySQL tables to include the attacker's RFID token ID into the target ACL. Physical access to the central server is restricted by the server room door.
A service exposed to the internet or the public LAN at the space could be exploited on the central server. However, the server would be on a dedicated subnet for administration machines, and traffic limited to it. There would be no reason for the central server to be exposed to the internet. An attacker would have to VPN into the Freeside members-only subnet as an administrator in order to be allowed to ssh into machines in the administration subnet.
Because the node will be on battery backup, the next most viable attack is to cut-off the power and wait for the battery to die. We would likely broadcast a power failure to IT, so we'd know to come down and wait for the power to come back up. That means the attacker would have to cut off the internet access as well. Probably a polling script could notify IT of an internet outage, so it would be 1-2 hours maximum that we wouldn't know both services were down. Since the Raspi is a low-power device, it would remain operational and keep the doors locked for several hours, at least 12+ hours.
The most viable attack would be either robbery of a member RFID card or rubber hose cryptanalysis - so keep your RFID cards safe, and let IT know the minute you lose any of them!
Future Work
- Group management via LDAP and not MySQL tables
- Implement web API for managing user information
- Design plug-in system for playing sounds, email, etc.
- Manufacture integrated RFID reader and relay shield for Raspberry Pi