The Mid-Atlantic Regional CCDC 2010 Event - Part II

Physical Access: RFID Badges

This year's competition debuted an RFID badge hacking system. The Red and Blue teams had separate rooms that were governed by badges and a badge reader. The Red team badges were allowed access only to the Red team room and vice versa for the Blue teams. I really wanted to hack the badge system right out of the gate. There were a couple of motivators involved (including the fact that my friend Larry put the system together), and if we bypassed the RFID reader the Red team would gain physical access to the systems after the Blue teams went home for the night.

Before the competition started I mapped out a plan of attack. Since all of the Red team members were in the same room and I had access to their badges, I planned to scan them and record all of the values. This would give me knowledge of the known values, making any other value a potential Blue team code. Before I could scan the badges, I needed to set up a reader. Larry had a reader for players to use, but I wanted to set up one of my own (besides, I did not trust Larry… what if he defected to a Blue team?). After about two hours of fighting with software library installations, failed dependencies and USB drivers, I finally had a working reader. I was using RFIDIOT to do the reading, which are Python scripts developed by Adam Laurie. While it is a great contribution to the security community, the documentation could have been more comprehensive (if you are looking to contribute to an open source project, here is your chance!). Having little to no experience with RFID, it was a challenge to figure out how to correctly configure my reader and set it up to read our badges, but persistence prevailed and just before the competition started I was reading Red team badges.

Once I had read all of the badges, I sorted all of the values. It appeared that the last three digits were in the range from 901-932. Thinking that they may have been all coded from the same batch and in sequential order, I added 10 to the last value and wrote it down. I was hoping that this value would land me in the range that was assigned to the Blue teams’ badges. Larry had the only reader/writer at the competition, so any team wishing to write, or re-write a badge could do so. When I walked up to the writing station, Larry was briefing the Blue teams on how the badges work and how they would be integrated into the competition. This gave me unmonitored access to the badge writing laptop and attached RFID reader/writer. I started to review what little documentation was available in the readme files and ran the commands that looked like they were set up to write new values to the tags. While poking around I noticed a shell script in the directory with all of the RFIDIOT scripts called "ccdc.sh". I reviewed the shell script contents and determined that this was the same system used to do the initial write to all the badges. A quick review of the command history revealed the exact commands used to write all the badges for the competition. I chose a command from the history that wrote a value not in the Red team range, and wrote it to my badge. I then walked up to the Blue teams’ door with the RFID reader and scanned it. After a few seconds of the reader "thinking" (it seemed like a lot longer to me), the reader flashed the green light. I had successfully cloned the badge before the competition had even started! (Yes, I did another happy dance, which I think was captured by one of the film crews).

Mission accomplished! Throughout the competition we wrote my Blue team RFID code to almost all Red team member badges. At one point, the Blue teams were on to us and obtained a mobile RFID badge reader. They read one of the Red team badges only to realize that they had cloned a clone of a Blue team badge. Later in the competition, a Red team member had swung his badge around to his back while in line for dinner. A Blue team member snuck up behind him and cloned his badge. It was a very exciting and fun aspect of the competition and I am looking forward to seeing it used in future exercises.

There were many lessons learned from the RFID component:

• You Are Only As Secure As Your Vendor - The vendor had left valuable information on the system that quickly led to the badges being hacked. In addition, the vendor was a bit lazy (to save time and money of course) and did not generate random numbers for the badges. Make sure you carefully choose your vendor and audit their procedures and security practices.
• Hacking Is Not Always High Tech - Using the badge values that I knew to determine the values that I did not know is nothing really new. In fact, it’s not even really that interesting or exciting! However, it was extremely effective. Many attacks are successful based on the principle of attacking the implementation, not the technology.
• Physical Security Matters - Using a wireless technology such as RFID to secure access to your facility is a recipe for disaster. While it can provide one layer of security, it must be coupled with other security measures such as monitoring cameras, end-user awareness training, keyed locks, alarm systems, and physical guards. Testing your RFID system is critical as well. Many vulnerability assessments and penetration tests will not include the physical layer, but it’s just as important to know just how broken or easily bypassed your physical security systems are as your computer and network systems.
• Integrate Physical Access Control With Existing Monitoring - If the RFID badge readers log to a server on the network, this information can be correlated against other log sources in your environment. For example events such as an employee “badging in” at 3:00AM, attempted logins on a workstation and USB devices being plugged into several systems happening in the same timeframe should set off a red flag.

You Don't Always Need Root

As I've stated before, passwords are easy to abuse. It turns out that the Blue teams had not yet changed one of the passwords on several Debian Linux systems. The username of "nagios" and password "nagios" were left unchanged, which gave the Red team non-root level access to the systems. While this access was used to "score" (run a program on the target system that updates the scoring server, causing the Blue teams to accumulate points), it did not provide us with root access.

I did some research after the competition and found a new way to become root. One of the startup scripts in the "/etc/init.d" directory started the Nagios process in /usr/local/nagios/bin/nrpe. This binary was owned by the nagios user. The startup scripts are executed as root when the system starts up. The nagios user could replace the contents of "/usr/local/nagios/nrpe" with a command such as the following:

Upon the next reboot you will be able to login with the user "myrootuser" using a blank password and have root privileges on the system. System configurations are just as important to secure as it is to apply patches. As an attacker, I'm always looking to exploit vulnerabilities that do not require a buffer overflow to exist in a software program. Misconfiguration is a much more reliable way to compromise a system and something that is not part of a regular patch cycle. Keeping track of your systems’ configurations is a difficult job and is almost more work than keeping them patched.

Another example of compromise without traditional exploits is a blank "sa" account password on the MSSQL servers. Nessus picked up on this during a scan:

This allowed the Red team to execute commands and gain access to Windows systems without relying on a software vulnerability. Executing commands through the database also reduced our fingerprint; since there were no command shells running or TCP/IP connections that looked suspicious, it helped the Red team maintain access to the database servers.

Conclusion

The 2010 CCDC competition taught me many things. I will be more aware of my configuration files and startup scripts as potential entry points by attackers. Physical access controls are not all that different from other systems in scope on an assessment, and applying similar logic goes a long way to uncovering the vulnerabilities and potential attack vectors. One of the best “take-aways” for the Blue teams, and anyone who is defending networks and systems on a daily basis, is to think more like an attacker. Not only does this give you a better understanding on how to defend, it can help to create more effective defenses. For example, if the Blue teams had done exactly what the Red team did with the RFID badges, they would have been in a better position to defend themselves by changing all of their badges to random numbers and re-coding the RFID reader. I can't wait for the next competition!