Giving a Blackwidow it’s “Teensy” Fangs

Giving a Blackwidow it’s “Teensy” Fangs: How to Install Hardware Backdoors within Modern Keyboards

TLDR; It is very possible to place a Teensy within modern keyboards and mice as a hardware backdoors in order to implant a Trojan on a targets computer.

Warning #1: Please understand that working with electrical equipment and components is inherently dangerous. Burns, shocks, and electrical fires are fairly common when attempting to manipulate commercial/consumer grade electronics.

Warning #2: The author of this article claims no responsibility for personal harm or damage to personal property. This information is provided as is and without merit or warranty.

Problem

Some of our tougher targets have gotten very good at detecting and shutting down our normal social engineering attack vectors. In fact several are now able to systematically detect and shutdown our classic, emails, phone calls, and media drops Trojans. Once a client has established a strong defense against our standard attack vectors we are at somewhat of a loss as to how to approach social engineering. This has forced our team to come up with new and innovative ways to get in and get access.

Solution

My innovative idea is a new twist on an older poly idea, the hardware backdoor. Where one actually solders malicious hardware into another hardware system to gain access. This is normally done to subvert security controls such as drive encryption or to maintain access to a computing system.

However I’m not the NSA, nor am I am electrical engineering, so instead of attempting to compromise an entire computing system, I set out to simply place a hardware device within a keyboard. The idea being that I could purchase a few higher end keyboards, backdoor them, and send them out as gifts to targeted individuals. I quickly discovered a cheap Arduino based keyboard controller called Teensy and set out on my quest.

After conducting some further research, I quickly realized why we don’t see this attack vector being used in the wild. I won’t go into complete detail on every discovered issue, but a brief list is as follows.

  • Most keyboards are now soft-key using two sheets of conductive plastic and a rubber boot to trigger a key-press.
  • Space is normally very limited and many keyboard types such as soft-key don’t handle added pressure well.
  • Creating a custom keyboard or even a DYI 60% (uses a modern PCB with built in controller), is very time consuming and expensive.
  • Keyboards now use proprietary layouts and controllers which make tampering with them difficult.
  • Almost all mechanical and soft-touch keyboards are now made with a dual or triple layer PCB, adding literally layers of complexity.
  • Simply splicing a device in the middle of the USB connection creates added complexity by requiring the handling of serial timing, errors, and interrupters.

Needless to say, I had to simplify my plan even further. So I narrowed my focus to Cherry MX mechanical keyboards with built in USB hub ports. Since the Cherry MX keys are extremely sought after and conveniently take up quite a bit of space, it should be fairly easy to tuck the quarter sized Teensy into some free space. Additionally, if there is already a USB hub built into the keyboard controller, I can simply add the device inside by soldering the Teensy directly to the internal leads.

Note: Using this method is quick and dirty. It will take over said USB ports communication path and power channel. If another USB is plugged into the target port, best case scenario one of the two devices doesn’t power up, worst case you have yourself a nice little electrical fire. As such I would recommend clipping the pins or putting a plastic cover over the original USB hole.

The last step is simply programing the Teensy, which is somewhat out of the scope of this article, due to complexity and lack of one size fits all payload. However the Social Engineering Toolkit (SET) contains a great of code to use as a starting point (linked bellow in references).

Note: Creating payloads requires the Arduino IDE with the Teensy library’s, modules, and extensions installed. You also require direct access to the Teensy via a micro-USB cable. Meaning VMware and the aforementioned hub setup should be avoided when compiling and uploading your payload.

Blackwidow Photos

Unfortunately the project for which I backdoored the Razer Blackwidow Ultimate had a fairly tight time table and did not allow for me to get very good photos. Nonetheless, I’ve included two of the better photos I have of the Blackwidow, to show that the same techniques can be successfully applied to modern keyboards as well.

Showing the completed build out of the Blackwidow with the Micro-USB attached to the single set of USB leads on the builtin controller.
Teensy within Blackwidow

This photo shows the limited space within the Blackwidow shell. In fact the cable as to be flush with the PCB corner in order to get the case to close. Then the Teensy itself  has to be firmly placed in an angle between the row of F-keys and the back wall of the lower plastic frame. In future builds I’ll likely just shave/grind down the plastic frame and or PCB to make things fit more precisely.
Teensy tucked within Blackwidow

About the Teensy

The Teensy is a quarter sized fully programmable keyboard controller based on the open Arduino hardware standards. The Teensy allows for complete control over the keyboard, mouse, and touch screen via pseudo C code. It allows for roughly 30,000 lines of compiled code and roughly 60MB of on board storage, so we can accomplish quite a bit. It also is designed and built in such a way to allow for it to be easily extensible by offering 54 leads/pins for project flexibility. The Teensy also operates at as low as 3.3 volts with .25 amps and as high as 6 volts with 1 amp, making it robust enough to be connected directly to a powered or unpowered USB hub/port within a keyboard or mouse.
Offical Teensy Pin Layout

A Simplified How To Guide

The photos below are of a generic HP console keyboard being backdoored. This is simply because I happened to have it laying around and it awarded me the time and error tolerance required to provide detailed photos and guidance. As stated, they same steps can generally be followed on a Blackwidow, however the components are quite a bit smaller and space is more limited, making it much harder to work with and display.

The first step is fairly simple, just take all the screws out of the back of the keyboard and pop the back cover off. Just be very careful to not damage any of the components or parts, including the tiny plastic tabs that normally seal the edges.
Opening a Modern keyboard
Next identify the USB port to target by considering surrounding space and ease of access. Here I’ve chosen to use the forward set of pins since there is more space and avoids the lower screw hole/ground.
Viewing Configuration of onboard USB Hub
Next review the orientation and contacts of the female USB port to identify each lead against the USB standard. In this case the leads were on the lower portion of separator within the female USB port.These leads are just copper or aluminum that normally just have a 90 degree bend and connects straight down on the bottom of the board. In my case the leads simply passed straight through to the bottom USB port and were arranged in order from 1 to 4.
Viewing Pin-out of onboard USB Hub
Next cut a micro USB cable to the needed length, remove the shielding, remove the netting, untwist the wires, and strip the ends of each of the four wires. Then be sure to cut away all of the excess shielding and netting, so it doesn’t get in the way going forward.
Preparing USB wires for Teensy
In my case, each of the striped wires had dozens of tiny aluminum wires within them, instead of a single copper core. This can make keeping these wires together while soldering really annoying, but can also be used to your advantage by soldering the smaller wires together into a nice single bundle. The bundle makes soldering easier and the excess solder soaked up by the wires, normal removed to need to add additional solder when connecting the wires.
Combining Aluminum Wires Together
Once all the bundles are complete, they should all be soldered together and have a small ball on the ends. The ball on the end is used to quickly heat up each joint with the soldering iron and to quickly set the wire on the lead by holding it in place for a few seconds. If you are sensitive to heat, you may want to use some metal clips or helping hands.
Preparing Aluminum Wires
Be sure to double and triple check your solders against the USB wiring standard before testing, to avoid electrical fires.
USB Standards

Note: For those who may not know how to solder or need a refresher, I’ve included a info-graphic bellow that I think provides enough information to hit the group running.

Solder Guidance
Once all the wires are soldered into place, simply make sure none of the surrounding leads are jumped or damaged and then run some tests to verify the system works as intended. In my case I had an issue with the ground initially and the Teensy was not receiving power, so always test thoroughly.
Connecting Teensy to USB Hub
Once everything tests okay, find the best placement for the Teensy and secure the cable, Teensy, and solders with hot glue and/or electrical tape. In my case I had originally wanted to place my Teensy on the left side of the USB but the cable was too large for the sharp corner. Instead I carefully adjusted the cable over to the right under the USB hub cable.
Cleaning up Teensy Cable Connections
Once the Teensy and cable are secured in place, run some additional tests, to ensure nothing was damage then button everything up. Just note as stated earlier, you will need to remove the Teensy in order to properly connect it directly for development of your payload.
Hiding Teensy under USB Cable
The next image shows the Teensy hidden away under the USB hub cable. Just be careful about placing the Teensy on its face, as seen here, due to the payload launch button on the face. If its compressed it will continuously fire the payload until power is removed or all of the Teensy’s resources are locked up.

Teensy Under USB Hub Cable

References

As always I want to include references as a massive thank you to the community at large. I couldn’t have done this without their help, support, and knowledge.

PJRC makers of the Teensy: https://www.pjrc.com/store/teensy32.html

USB Standard Pin-outs: http://pinouts.ws/usb-pinout.html

Teensy Payloads by TrustedSec: https://github.com/trustedsec/social-engineer-toolkit/tree/master/src/teensy

Arduino References: https://www.arduino.cc/en/Reference/HomePage

Blackwidow Disassembly video: https://www.youtube.com/watch?v=2UwAgsLNa1Q

How to Solder: https://learn.sparkfun.com/tutorials/how-to-solder—through-hole-soldering

mRemoteNG: Just Loaded with “Features”

TL;DR: mRemoteNG uses insecure methods for password storage and can provide droves of valid credentials during an assessment or competition.

Level Set

mRemoteNG (mremote) is an open source project (https://github.com/rmcardle/mRemoteNG) that provides a full-featured, multi-tab remote connections manager. It currently supports RDP, SSH, Telnet, VNC, ICA, HTTP/S,  rlogin, and raw socket connections. Additionally, It also provides the means to save connection settings such as hostnames, IP addresses, protocol, port, and user credentials, in a password protected and encrypted connections file.

Problem

During a recent pentest, I was struggling to gain additional administrative access to key systems ,even with standard user authentication.  However, during some share pillaging I found a backup of an old mRemote connections file. The connections file houses all the information needed to gain remote access to a given system (IP/Hostname, Protocol, Port, Username, and Password). However, the credentials are encrypted, by default, and the connections file was protected by a master password.

Solution

It turns out, the master password is just used by the program to determine whether or not to load in the selected connections file. The stored credentials are actually encrypted with a static string, not the master password. This creates a scenario wherein the master password hash can simply be replaced with a blank password hash, to bypass the master password prompt. Once the connections file is loaded, the program even has the ability to add additional “External tools”, which allow for access to the programs variables and memory space. This allows for simple echo commands to be added to reveal hidden details about each connection, such as the clear text password.

How to Access The Clear Text Credentials

Method 1: Using the Program itself

To start ensure that mRemoteNG is closed or download the portable version of the application.

mRemoteNG Password Prompt

Second navigate to the default mRemoteNG data folder (C:\Users\\AppData\Roaming\mRemoteNG) or acquire the connections configuration file. Alternatively, enter the  path %appdata%/mRemoteNG into Start/Run, to go directly to the default installation location. Or use the portable version of the application, for any backup files you may have discovered while pillaging.

Third open the connections configuration file (by default called confCons.xml) in your favorite text editor.
mRemoteNG Connections file
Then, on the second line, locate the Protected=”a bunch of numbers/letters” string and replace it with the value below.
Protected=”GiUis20DIbnYzWPcdaQKfjE2H5jh//L5v4RGrJMGNXuIq2CttB/d/BxaBP2LwRhY”
Note: This is just a master password hash of blank, to allow for the connections file to be loaded.

mRemoteNG blank master password hash

Next, just re-open mRemoteNG and load the connections file, by simply submitting a blank password to the master password prompt.

mRemoteNG Connection file loaded via blank hash

To see the clear text of a given password, go to “Tools” > “External Tools”. Then right-click in the white space and choose “New External Tool”. Next, in the External Tools Properties, fill in a “Display Name”, “Filename” and some “arguments”, with “Password lookup”, CMD and “/k echo %password%” respectively.

mRemoteNG external tool

Finally, go to the connection where you would like to reveal the connection and right-click on it and choose “External tools” > “Password lookup”.

mRemoteNG external tool shows password

Method 2: Using an Offline Decoder

A modified version of the Metasploit module Ruby code, can be used to get the clear text passwords from within a protected connections file.

The file can be downloaded from packetstorm (https://packetstormsecurity.com/files/126309/mRemoteOffPwdsDecrypt.rb.txt) and run on Kali systems as such:
ruby mRemoteOffPwdsDecrypt.rb confCons.xml

Method 3: Using the Metasploit Post Module

Once you have a meterpreter shell on an administrators system that has mRemoteNG installed, simply run the post module with the following command and enjoy clear text.
run post/windows/gather/credentials/mremote

Note: mRemoteNG is a platform agnostic program, however the post module only works on Windows and will only parse the default connections file (confCons.xml) and location (%appdata%/mRemoteNG).

As always,
w7nDgMKow73CuCU7XsOkScuGXsKrw51Rwq4=

My Top Three user account design Pet Peeves

In this internet infused world we live in today, it’s not uncommon for user to have to remember several username and password permutations (please note order of characters does matter and thus it’s a permutation not a combination). That being said there are three aspects of the user account design process that really grind my gears.

User Responsibility

This aspect of user account design doesn’t seem to be talked about very often, but it is extremely important. Individuals need to take responsibility for the protection of their usernames and passwords. In fact most web based services clearly indicate as such in their User Level Agreement. That is to say, if someone gains access to your account by means of your username and password permutation, you are responsible for any and all damages. Users need to understand that they are already being held legally responsible for their login information and should take it upon themselves to protect it as if it were any other valuable piece of information.

Secret Username

I grew up online and have watched large web based service provides change their user account design practices over time. Although, most of these changes have greatly increased the general security of user accounts online, I’ve always wondered why changes were never made to user names. In fact usernames have remained almost constant in the online landscape for years. For some reason, early adopters of this authentication model decided that the username should be shared to represent a person online. I personally believe that it is important to have an online identity and that it’s your choice weather to divulge your physical identity alongside a virtual one. This should not require me to log into a web service with such an identity or handle. My username, that I use to log in, should not be public information. In fact I’m a firm believer that it should be treated as if it were a second password. After all, two things you known might not be 2 factors of authenticate, but it is two facts. Web based service provides need to allow users to create usernames that are just as advanced as their passwords. These usernames should not be made public and another method of virtual identity handling should be used. If nothing else, please please stop using email addresses for account login. Email addresses are used everywhere online and are widely known pieces of information and one need only go to the password recovery prompt to see if an email is indeed in use.

Password Complexity

Password complexity is a double edged sword and I hope to make a far more technical and detailed posting about it in the near future. However password complexity, in my mind, has only come about as a method to force users into take more reasonability for their passwords. In a perfect world, a password of all lower case letters or all numbers would be just as difficult to decipher as a password that uses a range of characters. That is to say, if users were truly random in their character selections, the user who chose a password of 33784091 would be just as secure as the user who choose L(k&6hlY, because the available character space did not change. However users are not random and in fact are rather predictable. So our solution is to create a list of rules that a user must follow in order to use a service. This forces a user to create a password that is hopefully harder to guess and crack, but in my experience neither case really holds true. These rules restrict the user by reducing the useable character space and realm of possible passwords. These restrictions alongside the added pressure of maintain a secure posture, all but forces users to reuse old passwords and create ones from common phrases. This undo stress adds predictability to the equation and is at the root of the username and password problem. My solution is a simple one, use the same methodology that is commonplace for usernames. When a user sets or changes a password don’t let them use a password that someone else is already using. In the background, just add what every passwords your organization has deemed weak to the already in use list, just as many already do for usernames deemed inappropriate.