My wife is a freshly minted doctor, and part of her residency involves working one day per week at a clinic that’s in a health system other than where she “normally” works. The day of the week changes every week.
Recently, the health system added a new security control — they lock out all accounts that haven’t been used in the past seven days. This means that approximately every-other-week she is locked out and needs to contact the helpdesk before she can see her first patient of the day.
Frustrated by the situation, my wife asked the local IT helpdesk for help. The helpdesk offered her a solution: give one of the nurses her password so the nurse can log in a few times a week so her computer doesn’t get locked out. The nurse, who was physically present during this interchange, objected strongly. Not for security reasons, but because she had better things to do.
My wife’s plan is to call the helpdesk every time she’s driving to the clinic to request that her computer be unlocked whether it’s locked or not.
Aye aye aye.
I think we all know those seemingly arbitrary numbers for password length, complexity, and expiration have consequences… but pick those numbers carefully, lest we waste countless hours of time — or lest people work around the system.
One of my professional roles is to perform security reviews of medical devices. When I’m performing a security review, I usually have about two days to look for low-hanging fruit. Let me be clear: I’m not a penetration tester, nor am I a true security researcher, but I do kick the tires of new devices before we send them out for a third party pentest.
When I first started doing this, I remember being frustrated that my backpack always seemed to be lacking critical items to properly test a given device. In more recent years, I’ve found that the gap is not my equipment, but my knowledge. To that end, I thought I’d share a list of the gadgets that do — and do not — generally get a spot in my backpack.
Equipment that’s always packed
- Laptop, times two. I’ve occasionally had issues getting USB devices to pass through properly into virtual machines. After one particularly frustrating incident I decided to always carry a second laptop. One is a corporate MacBook, the other dual boots Kali and Windows.
- A Netgear ProSafe GS105E. It’s a tiny managed switch that can be configured to have a mirroring port.
- Ethernet cables, x4.
- USB to Ethernet, x2. By picking disparate brands that use different drivers, it increases the odds that the driver you need will be pre-installed on the device under test.
- Micro SD cards, x4, paired with a USB SD/MicroSD card reader
- SD card with bootable Kali
- SD card with bootable Ubuntu. Note that the signing key for Ubuntu is generally pre-installed on most devices, so this can be helpful when secure boot is enabled in the BIOS.
- SD card filled with random portable windows apps and tools that have proven helpful
- SD card for generic exchange of files
- A USB rubber ducky. These can be very helpful in auditing keystroke combinations, automating kiosk escapes, automating user-interface based injection attacks, or for demonstrating buffer overflows in user interface components.
- A harbor freight screwdriver with assorted tips. Not used often, but it’s occasionally indispensable. A word of caution: If you’re buying one, make sure it’s shorter than 7 inches so you can pack it in a carry-on.
- Non-cellular LAN turtle. This acts as a third option for USB to ethernet, and also provides an easy way to do a man-in-the-middle if ettercap (or just physically connecting cables) is proving too annoying. The cellular variety is not needed to demonstrate POCs, and I view that as a needless expense. I don’t use this often, but it’s small and has high show-and-tell value so I carry it.
- A tiny USB keyboard/mouse. I previously tried a rubberized roll-up keyboard, but the RiiX1 proved more reliable. Carrying a keyboard and mouse can be surprisingly important when testing devices that don’t have one built-in.
- Power stuff (besides the inherently necessary plugs)
- A six-plug power strip with a 6-foot-long cord.
- A three-pin to two pin adapter. These are always saving my rear; not only on international business trips, but also when I find myself in coffee shops that have outlets with no ground pin.
- Assorted USB cables and adapters. The assortment that might make sense for you is different from me.
- A four-port USB hub.
- An alfa network “N” USB wifi adapter. I am declining to provide a link, because the “Alfa N” adapters are not all created equal. Research carefully before you buy one.
- For convenience: An emergency battery to recharge the phone, analog headphones, a blueparrott headset, and caffeine tablets.
- A yubikey, a PIV key C910, assorted unprogrammed java cards, and a USB smart card reader. These are not carried for testing purposes, but rather because I need to explain the underlying concepts with a surprising degree of frequency, and because I sometimes need to use one for my own purposes.
- A very low-end RFID duplicator. I’ve seen a surprising number of devices that are subject to duplicators like this one.
- An RTL SDR dongle. Mine is a little different than the one linked. For the purposes of a short test two day test, it’s not likely that you’d go much further in the radio arena than a replay attack — and this would at least let you figure out if there’s anything to replay.
Equipment that’s selectively packed
- I’m very enthusiastic about my Hack RF, but there are a few reasons this doesn’t usually get packed — the first being that a decreasing number of modern medical devices are implementing a custom protocol. The second reason is time: I usually conduct 2 day tests, and as a radio novice I’m not likely to make much progress in a short period of time, and the sort of thing that I can do in two days can be detected with a capture on my RTL dongle. The final, and potentially most convincing reason, is that unless testing is done within a Farady cage or on amateur bands, transmitting would likely be in violation of FCC rules. A similar rationale applies to a yardstick one and an ubertooth.
- A USB DVD drive, paired with bootable Kali and Ubuntu DVDs. Every once in a while a BIOS will also automatically inject a DVD drive into the boot order before the hard drive.
- I briefly carried a Raspberry Pi loaded with Kali, but didn’t find many cases where my normal laptop didn’t make more sense. I can picture a few cases where GPIO manipulation might come into play where this would once again be packed.
- External hard drives. They seem to have a lot of reliability problems when jostled around in the backpack. I only pack one if I anticipate making hard drive images.
- A USB to Serial Adapter. Doesn’t come up often, but occasionally very useful.
- A wifi pineapple is a really cool device and has pre-packaged attacks that are both easy to use and fairly sophisticated. I’ve found some use for this in testing, but the tetra version (which is the only one that operates on 5ghz) is a bit on the clunky side, and really doesn’t do much that you can’t already do with an Alfa.
For show-and-tell only
Since my goal is testing — not to actually hack anyone, I have a number of items in my possession that generally take up residency in my closet. These items do come out occasionally for show and tell, but I don’t consider them particularly relevant to the type of testing that I do.
- Lock picks, bump keys, etc. I don’t do physical testing, and as a result have relatively little business carrying these in my backpack. I’d hate to travel to a state where they are illegal and forget to remove them from my bag.
- Directional antennas. Although a high gain antenna might be highly relevant in a real-world attack, I’ve never found them particularly relevant to testing.
- Magnetic strip readers. I purchased a few different varieties, but don’t consider them very relevant to medical device testing. The only reason to keep them around is to explain just how insecure magnetic stripes really are.
- Drones have an almost magical ability to bypass a lot of physical security. Although I usually fly my drone for personal pleasure, I could picture using a drone to explain why a range-limited attack might be more viable than it could appear at first glance.
- An Infrared camera. Showing people the ability to recover PIN entry via an infrared camera can produce an interesting shock effect. I’m not sure if I’d purchase one of these again, because they’re kind of expensive and have really low resolution.
Over the past few months I’ve found myself thinking about change control a surprising amount. It’s not an exaggeration to say that change control is the only reason we can drive a reliable car, get to space, or take a commercial flight.
After prototypes have been tested and confirmed to work, change control is about building exactly the same thing, again and again. Any changes, including the tiniest tweaks, are carefully analyzed and tested. This approach has proven extremely successful and has become enshrined as one of the key tools in Engineering. Our society has even produced regulatory frameworks that rely on change control.
This was great in the past, but enter the current software environment. Software stacks are changing at a dizzying rate, with dozens of security issues being discovered and fixed every day. Security fixes in off-the-shelf software often prioritize security over other characteristics, such as performance and usability.
This leaves engineers who care about change control in a very difficult spot. They can’t simply ignore change control processes — nor can they ignore the security issues. The natural result is triaging by CVSS score to help rapidly sorting through the dozens of new CVEs that arrive every day.
I think it’s safe to say that the only long term answer to this problem is entirely automated testing, but saying that is too little too late for devices whose original design team didn’t have the insight to invest in automated testing.
My conclusions — though underwhelming — are this: (1) Automated testing is insanely important (2) As an industry, we need to improve CPEs. Without better CPEs, triaging criteria is likely to begin with ignoring any CVE with a CVSS score less than 7.0. (3) Better data from OS vendors on the performance impacts of patches — via a standardized method — would be amazingly helpful for device manufacturers.
Although I avidly maintained a website in 1999, I’ve been lazy about doing so in the 21st century. Here’s to hoping that I fix that trend.