Tag: physical security

HST Rockville: eBay to DA

Posted onLeave a comment

Below are a bunch of links related to my talk Wednesday at https://HardwareSecurity.Training in Rockville, MD. Please pardon any typos, this post has not been reviewed.

The single more important part: https://ebay.com
Concierge “toolkit”, Exploits for door controllers: https://github.com/lixmk/Concierge
eMMC Reader Device: https://smile.amazon.com/dp/B071R2STNQ/
Skype for Business Timing Attack: https://www.trustedsec.com/2017/08/attacking-self-hosted-skype-businessmicrosoft-lync-installations/
Kerberoasting pt1: https://room362.com/post/2016/kerberoast-pt1/
Kerberoasting pt2: https://room362.com/post/2016/kerberoast-pt2/
Kerberoasting pt3: https://room362.com/post/2016/kerberoast-pt3/

I “deleted” a few slides, mostly due to time, that covered interesting hardware attacks that have had (or will have) a large impact on commercial grade/corporate/enterprise security. Links from the deleted slides are included below with little-to-no description.

HID iClass Key Dump: https://www.openpcd.org/dl/HID-iCLASS-security.pdf
Direct Memory Access Attacks 1: https://github.com/ufrisk/pcileech
Direct Memory Access Attacks 2: https://github.com/carmaa/inception
A whole bunch of talks on Intel DCI and ME:

CVE-2017-16241: AMAG Edge Network Door Controllers

Posted onLeave a comment

At HushCon Seattle 2017, I had the opportunity to publicly disclose CVE-2017-16241, a vulnerability in AMAG’s Edge Network (EN) series of door controllers. Exploitation of this vulnerability gives an attacker to ability to remotely unlock doors and implant access card values into the door controller’s internal database, effectively creating a physical access backdoor. Vulnerable devices include: AMAG’s EN-1DBC, EN-1DBC+, and EN-2DBC. All current firmware versions (as 12/10/2017) are vulnerable out of the box. Other AMAG devices may also be vulnerable but were not tested.

For some background: A door controller acts as the middle man between a Physical Access Control Software (PACS) server and an authentication mechanism (usually an RFID reader). The door controller is connected directly to the RFID reader and other associated door hardware (locking mechanism, alarms, push-to-exit, REX, etc) and is, in most modern cases, connected to the PACS server via the local IP network. In the past, door controllers were usually daisy-chained with one directly connected to PACS.

In normal operation, a new employee’s credentials are added into the PACS, then specific access is granted to those credentials (ie: You can go to the accounting area, but not the datacenter). The PACS then sends a message to all door controllers to which the new credential has access. The door controller stores that information locally.

Once the employee present their credentials to the RFID reader (or other auth mechanism), the reader blindly passes that information to the door controller. The door controller checks it’s local database and makes the go/no-go decision itself, without asking the PACS (usually. Other non-default options exist). Based on the door controller’s decision, it will tell the reader to change it’s LED color, and either trigger the locking mechanism to unlock, or keep it locked.

In the case of CVE-2017-16241, the vulnerable devices do not enforce authentication for some command messages received via TCP port 3001, which should normally only be accepted from the PACS. Authentication exists and appears to be enforced for some commands, but not for others. This lack of authentication means that an attacker can send command messages from an unauthenticated system with network connectivity to the door controller and the controller will execute the commands. Unauthenticated commands include:

  • Unlock / Lock (Ud/Ld)
  • Version Query (Vf)
  • Card Add / Delete (Ca/Cd)
  • Reader Enable / Disable (Re/Rd)

Other commands may also be vulnerable but were not tested.

Additionally, these messages are encoded but not encrypted and are static across all EN Series controllers with no per-device change in messaging. Therefore, all that is required for an attacker to craft an exploit is MitM access to one EN series controller and PACS pair. By viewing a packet capture of their interactions, the specific command messages can be rebuilt and sent to other EN controllers regardless of their associated PACS.

In my case, I purchased an EN-1DBC and the demo version of AMAG’s Symmetry Security Management Software (SMS), both on eBay. I was able to get everything set up and capture events from adding a card, sending the direct unlock command, and more. I recreated the command messages in python and tested them in the field during a red team engagement for a client. That exploit code (and code for other physical access control stuff) is available at https://github.com/lixmk/Concierge.

Currently, no patch is available for CVE-2017-16241 and no timeline for a patch is known. That said, there are some non-default options that can be enabled that should protect against this attack. I say “should” because this is based on claims from the vendor and I have no ability to test or confirm. The biggest option is to enable encryption between the door controller and physical access control software (PACS). Additionally, according to the vendor, the latest version of their PACS has be ability to compare access card counts on the door controllers and alarm if the count is higher or lower than expected.

Wiegotcha – RFID Thief

Posted on1 Comment

Update: Wiegotcha will also work on the newer HID R90 SE, but in order to silence the speaker, you’ll need to dremel it from the sealed plastic inner casing.

As with most things I do, this is a work in progress. If you notice any bugs, run into any problems, or have any questions at all, ping me on twitter: @lixmk. Or you can submit an issue or a pull request on github, apparently that’s what they are there for: https://github.com/lixmk/Wiegotcha.

Wiegotcha is a long range RFID reader inspired by the Tastic RFID Thief originally released by Fran Brown and Bishop Fox. Wiegotcha is designed be a simple and reliable method of discreetly capturing RFID credentials from unsuspecting targets. Before I go any further, there are a lot of people who unknowingly helped out on this project. Check the README.md on github for a full list.

Wiegotcha improves upon the Tastic RFID Thief in few key areas:

  • Includes a wireless AP with a simple auto-refreshing web page to display captured credentials. No more need to open the reader and remove the sd card.
  • Uses a hardware clock for accurate timestamps. Useful for identifying when (and with a little note taking, where) credentials were captured.
  • Reduces or potentially eliminates (depending on choice of Level Shifter) the need to solder components.
  • Utilizes an external rechargeable battery. No more carrying a 30 pack of AA batteries or opening the reader to replace them.

Source is available at: https://github.com/lixmk/Wiegotcha

Working w/ Wiegotcha:

I won’t tell you how to steal badges, that part you can figure out yourself. But there are a few things to know about how Wiegotcha works. When powered on, Wiegotcha takes a couple minutes to completely boot and fire up it’s access point. Once that’s complete, you’re good to go.

Once connected to the AP, just browse to http://192.168.150.1 to get a (mostly) live view of badges as they arrive. The site refreshes every 5 seconds.

All captured badges are stored in /var/www/html/data.csv, which is parsed by the web site. At each boot, the previous data.csv is backed up with a timestamp to /var/www/html/backup/<TIMESTAMP>.data.csv. Directory indexing is enabled for easy browsing of backed-up badges (http://192.168.150.1/backup/).

If you are using a new hardware clock, or need to replace it, give the RPi an ethernet connection and run /root/Wiegotcha/fixclock.sh.

If you install manually, you’ll have the ability to change passwords for each of the users and the option to enable SSH for the root user (SSH is enabled for the pi user by default). If you used the downloadable image, SSH is enabled for root by default. CHANGE THE DEFAULT PASSWORDS. To change the passphrase for the wireless AP, just modify /etc/hostapd/hostapd.conf.

Defaults are as follows (Seriously though, change the defaults):

Default Passwords (Image only):
root:Wiegotcha
pi:Wiegotcha

IP Addressing:
eth0 = DHCP
wlan0 = 192.168.150.1

Access Point:
ESSID: Wiegotcha
Passphrase: Wiegotcha

I probably forgot some stuff. If you notice any problems or have any questions, reach out on twitter @lixmk.

Hardware Installation:

Installation is extremely straight forward. The tl;dr of which is: power pi, hookup GPIOs and RFID reader (with a level shifter as a middle man (wiegand output is 5v, RPi GPIOs are 3.3v), plug in battery.

In this build example, I’m using an HID MaxiProx 5375 (125kHz), but you can follow the same steps for an HID R90 (13.56mHz iClass) or Indala ASR-620. Start with a small bit of prep work. If your level shifter did not come pre-populated you can either: Solder pins to the through holes or solder the jumper wires directly. Soldering the jumper wires will make things a bit more sturdy, but it’s not necessary. If you choose to solder the wires, skip down a bit to check the wiring diagram.

Take the Y-cable from the battery and cut one of the tails off. Strip the outer wrapping to expose the red and black wires. Then strip roughly 1/8″ to 1/4″ off both the internal wires. Give each one them a twist to tighten up the copper. If you have a soldering iron handy, you can get a bit of solder on the twisted copper to keep it from fraying.

String the newly created power cable, and a short USB micro cable, through the conveniently located hole in the back the of the reader (micro side in). Connect the two power cable leads:

  • Battery Ground (Black) to Reader TB1-3
  • Battery 12v (Red) Reader TB1-1

Next, wire up the GPIO’s, level shifter, and reader. Refer to the mastery of MS Paint that is the following diagram:

(Good huh?)

Now wire the rest of the bits. Set the RPi with GPIO pins on the right and the level shifter’s low volt (LV) side facing left.

  1. Hardware RTC on pins 1,3,5,7,9 (First 5 pins on the left side)
  2. RPi pin 4 to Level Shifter HV in
  3. RPi pin 6 to Level Shifter LV gnd
  4. RPi pin 11 to Level Shifter LV 1
  5. RPi pin 12 to Level Shifter LV 4
  6. RPi pin 17 to Level Shifter LV in
  7. Reader TB2-1 to Level Shifter HV 1
  8. Reader TB2-2 to Level Shifter HV 4
  9. Reader TB1-2 to Level Shifter HV gnd

Next, you need to address the Reader’s speaker. Obviously, a loud beep every time you read a badge isn’t very stealthy. To address this, you can do 1 of 2 3 things.

**UPDATE**: I completed testing on replacing the speaker with a small haptic motor and it worked perfectly.

  1. You can desolder (or snip) the speaker to completely disable all audio output (including power-up auto-tune tones).
  2. You can adjust the dip switches on the top of the reader PCB to disable card read tones. If you choose to this option, push switch 4 of SW1 (right most set of switches) to the off position as pictured below:

3. You can replace the speaker with a small haptic motor causing a cell-phone like vibrate feeling and sound every time a badge is read. Desolder (preferred) or snip off the speaker and solder the on the motor. No in-line resistance is required. Red wire to + and blue wire to -. If you choose this option, leave SW1 switch 4 in the default “on” position.

Last step: since we’re using a 12v power supply to the reader, we need to move the P2 jumper. By default, the jumper is installed over pins 2 and 3. Move this jumper to pins 1 and 2. Like below:

Hardware installation is complete. I suggest getting some stick-on velcro to hold the RPi in place, and running the group of wires through the small slit towards the top of the reader. Also, some duct-tape helps holds wires in place. Your final product should look something like this:

Software Installation:

  1. Download the RPi image: https://drive.google.com/file/d/0B1KiYGoUoNwGem8tZlRxeEVwRHM/ *Updated 5-22-17*
  2. Check md5 sum of .gz: 7f8b0507e0b58cbc301b39550c59e33d
  3. gunzip and check .img md5 sum: b68d21f1c0e6b200985a29869491fbf0
  4. Push image to SD card (8GB or larger) (just like any other RPi image)
  5. Install the SD card in the RPi.
  6. Boot the RPi.
  7. If this is a fresh install with a brand new hardware clock. Plug the RPi into a wired ethernet connection and execute the fixclock.sh script: /root/Wiegotcha/fixclock.sh

For installation from source, see the github README.md: https://github.com/lixmk/Wiegotcha/blob/master/README.md

Bill of Material (BOM):