Security risks associated with expansion cards

Creators & Developers
1

One of these devices is malicious.

image
image2985×1723 469 KB

It can steal your data and your screen picture, and send it to an attacker wirelessly, it can fingerprint and infect all of devices you connect to your ports. It can even impersonate you by clicking mouse and typing your keyboard right before your eyes. It can kill your laptop by sending 10 000 volts into the port.

Guess, which one is dangerous? Maybe none of them, maybe both. Maybe you already have one in your laptop. You don’t know? Me either.

The thing is, malicious device can look identical to a honest one right from the store. I realized that when I was writing my suggestion for a USB condom device. An attacker can buy an extension card, tweak it with custom hardware, and wait for a good moment.

What is even more concerning is that these expansion cards can be trivially swapped within seconds. Not by you. By someone else. Heck, we love our laptops exactly for this possibility! To swap cards fast.

Imagine going to a bathroom and leaving your laptop on a desk for a minute. Once you return it can already be infected by one of those evil cards and you would never know. This is a problem. And a security attack vector.

So my advice is: do not leave your laptop (or any hardware) unattended. Know your stuff. Ideally you should make all of your devices unique. Stickers everywhere may look dumb and childish, but they do make your stuff unique. Even a scratch can make a card unique and really hard to replicate.

On an OS level all devices should have readable serial numbers and be registered within a system. Still, it would not prevent from having a dumb expansion card not so dumb, but it will warn you if something else had changed. Dumb expansion cards like type-C and type-A should probably be deprecated by something with an ID. That way, if an attacker would remove a card, an OS would know that original one was removed. Also, breach detection button inside the slot is also a good idea.

Ideally we should have a way to lock the slots to make it hard (not impossible) to swap a card without prior authorization.

Stay safe.

P.S.: If I’m not mistaken, card eject buttons when pressed feel like they are not just a mechanical thing. I feel a real button there. If it’s processed by the same circuitry than the breach detection lever and is OS independent then it would be absolutely awesome and my fair in humanity (and Framework) would be restored a bit.

4 Likes
2

I think another (easier) solution would be to write a program/script that notifies you when an expansion card (or any device for that matter) is removed/inserted.

4 Likes
3

Notifications can be set up for USB connect/disconnect with udev rules on Gnu/Linux systems.

But if you’re this worried about physical attacks, you aren’t letting your laptop out of your sight. Ever.

11 Likes
4

I have to agree with @Anubis On this one and I disagree that any extra expansion card controls are necessary. If an attacker has already gotten that kind of physical access to your machine you’ve already lost. In the case of the Framework, they are not widely used right now. A bogus expansion card would be a pretty highly targeted attack, even more so with the wider variety of Operating Systems in use just for this laptop.

Anybody looking to do more general damage or theft would more likely carry a normal USB stick running as a rubber ducky, the voltage killer @Korvin mentions, or even just take the laptop. I don’t think any additional security measures outside of what is already known about physical hardware attacks are likely to do anything but cause extra headache for users. If you’ve left your laptop while you’re headed to the bathroom at the coffee shop, you’re taking on that same risk with any laptop, expansion cards or no.

I don’t think anyone needs to overly worry about seeing these kinds of things in the wild, though I think there may be valid concern for seeing these pop up on Framework’s official marketplace when independent sellers are allowed to sell cards they no longer use or custom cards that we’ve already seen pop up. Instead of any safeguards on the laptop though, halting distribution of these cards through some form of testing & verification program on Framworks part would prove way more effective.

TL:DR of this is that I don’t think the expansion card system carries any more risk than any other type of USB-based physical attack and that any implemented controls would end up being more of an inconvenience than a true safeguard. Be mindful of where you leave your machine and don’t plug in anything you don’t fully trust.

10 Likes
5

Yep… And All my modules are engraved with my logo so I know that it is mine. Labels help to make sure that you are using what you think you are.

2 Likes
6

This would not help if the laptop was powered off during the intercourse. Also this would not help in case of dummy cards like type-C or type-A that are essentially a 3cm piece of extension cable in a fancy case. Udev wouldn’t be able track such a device insertion/removal since there is no device there, only passive wires. But that does not prevent an attacker from creating one that would be in stealth mode most of the time waiting for a command. Also even more active USB devices an attacker can scan the original card and its IDs and write them to a malicious clone within seconds.

That’s why I was talking about an already existing breach detection circuit that is operated by an EC, is OS independent, and tracks if input cover was opened.

This is the button with the lever:
image

2 Likes
7

The major difference between classic laptops require prolonged exposure to an attacker to do really nasty things, whereas for Framework it’s a matter of seconds. You will notice something sticking out of your external USB port on a usual laptop but for Framework it’s not the case.

8

I get your concern, but I am afraid mitigating it by software or hardware is quite complicated. A similar attack vector would be an O.MG Cable i guess. Maybe the easiest defence to both is a human one: Know your hardware as well as possible, as mentioned by @ImaxinarDM and others above.

As we measly humans can be fooled quite easily of course, the alternative would be something like this: https://github.com/USBGuard/usbguard.

EDIT: removed the first sentence as USBGuard seems to be able to do what @Korvin intended: allow only specific USB devices and/or device types. Of course the question remains whether the passthrough cards have an ID to be allowed/blocked.

3 Likes
9

Hardware mitigation is trivial if card eject buttons would indeed contain electic switches and trigger hull breach event that’s handled by the EC. The cost is: two more pushbuttons on the mainboard, 1 cent each.

Sure, that’s why I wrote literally the same things in my original post. My intention is to raise awareness, not panic.

1 Like
10

My apologies, I did want to mention the person that recommended stickers by using “and others”, just forgot that was you.

I didn’t think you were trying to cause panic, just wanted to offer some immediate solutions/mitigations to the problem you mentioned (which I see as well). Heck, thanks to you I just discovered USBGuard and will probably use it once my Framework arrives, so kudos I’d say :wink:

1 Like
11

IMG_20211209_153036
IMG_20211209_1530363000×4000 2.31 MB

I don’t think this is much of a security risk at least until Framework gets a large portion of the laptop space. If you are afraid of risks, you can always personalize your cards.

3 Likes
13

all of this can be mitigated and not really a risk, by common sense and i think the target demographics of this laptop is engineers and enthusiasts anyways. and for the people who’s planning to use this laptop for thier company it takes 5 mins to discuss a lil about opsec and common sense.

1 Like
14

No, It’s really not. That button would just act as a trigger for a software action. For instance, You suggested registering every expansion card by serial number in the OS, that’s fine, but tying it to the button would only mitigate anything that actually reports as a Framework expansion card. The expansion card system is nothing but 4 USB-C ports with some fancy enclosures, which only gives fake cards the added benefit of extra stealth. However, any USB-C device could be plugged into that port without even touching the button, as could a modified enclosure that doesn’t lock in. Why would a malicious card need to?

This also becomes an inconvenience for users, setting up your laptop now includes registering all of your cards and peripherals. Not to mention having to register a new device anytime someone tries to give you a file with their USB or you have to hook up to a projector with a different dongle, etc.

If an APT is really that determined to complete a hardware-based attack and you don’t have complete control of your device, There is not much you can do. This proposed system mitigates very few USB attacks to begin with.

A USB Device can be programmed to look like anything, most commonly a USB Keyboard. This is because devices like that are inherently trusted by the OS, and an attacker can immediately dump their payload, run malicious code, etc.

This would require complete hardware verification of all devices connected to the Framework, including the built in peripherals. It would be trivial to have a USB device report as a Framework keyboard or even trackpad and gain inherent trust. Getting the serial number of a trusted card and passing it to the fake one would also be trivial through use of a raspberry pi or even a phone.

As for the USB Killer, that attack is entirely electrical, USB always provides power first. No USB device can initiate any kind of software without power. USBkiller collects that power, multiplies it and discharges it back into the port’s data lines. Supposedly newer USBkillers have rechargeable batteries so it can even do this with the device powered off.

Further still, any OS-based check does not protect against cold-boot attacks that take advantage of BIOS flaws or memory dumps on system startup.

Two of these above attacks are quick, drive-by attacks that do not take prolonged amounts of time unless long-term recon/exfil is the goal. Sure, you are more likely to notice a strange USB stick in your PC, but by the time you take it out the damage is already done. A USBKiller or a script that autoruns off a USB, dumps credentials/credit card info stored in a browser and brodcasts it to a remote server is only going to take seconds, if that.

An extra button and a software check would not mitigate these issues, and tying the functionality to the button alone eliminates any check beyond actual expansion cards. These security problems exist in the functionality of the USB protocol and Framework is unable to do much about it without overriding or changing the USB Controller on both the Motherboard firmware and the OS. This is a security issue that affects all forms of computers with USB and is beyond the scope of Framework’s abilities to fix or even mitigate.

@Korvin I appreciate your intentions to spread awareness of the issue and give less technical users a better sense of the importance of physical security of their device. Unfortunately, until USB itself adopts a better security posture I believe that’s about all any of us are able to do.

3 Likes
15

Would this system not invalidate the open concept of Framework’s design? The idea is that there are no systems preventing a user from opening their own device and changing their expansion cards. A system that checks for these breaches and prevent powering on without the approved chassis and expansion cards is exactly the kind of system that Framework is pushing to move away from. To maintain their current posture on the upgradable mainboards and custom expansion cards you would need to empower users to register whatever cards they want and remove the EC check for the chassis when they upgrade and want to use the MB in a different device. Implementing ways around that system would then in turn invalidate the security posture of the EC as well though.

2 Likes
16

As you seem to have a deeper knowledge of this kind of attack than I do, I’m curious to hear what you think about this, especially the “Reject devices with suspicious combination of interfaces” part: Rule Language | USBGuard
Would an attacker be able to bypass that easily?

18

They would probably not be able to bypass any denied device rules easily. The key is you have to deny those devices, which can cause all sorts of inconveniences for the user with little to no security benefit. A USB rubber ducky shows up as a keyboard and delivers it’s payload by injecting keystrokes. You can configure USBGuard to reject these types of devices, but then you will most likely run into issues should you ever need to use a USB keyboard.

Think of it like a Firewall for blocking certain USB devices. You should be intimately familiar with what kind of devices you would be using and blocking certain devices that you are sure wouldn’t be in use and ones that could potentially be suspicious. For instance, that page you linked mentions a rule for allowing flash disks and denying anything that shows up with additional keyboard or wireless functionality.

However, as stated USB devices can show up as many different types and you may have to leave certain devices open because you still need to use them. USBGuard is a tool that allows a user to limit their attack vector, but not eliminate all forms of risk. You could very well say that you can block the HID keyboards and eliminate the rubber duckey, but are you going to then block all USB Mass storage devices? You may have a use case for using your own and others devices to transfer files locally, and registering all of them would be a hassle. There are USB attacks based on mass storage devices as well though, so allowing any opens you up to that risk.

There are also plenty of generic devices out there that may not have much in the way of an individual identifier that USBGuard can block, so if you end up just blocking that generic device, you essentially block any device that reports as that generic type of device, malicious or no.

It’s also a daemon tied to the OS, so any attack that happens before that daemon is loaded or can even check the device like a cold-boot or USBkiller is still going to be a risk.

USBGuard comes default with an implicit deny rule, so any device you want to connect is going to have to be whitelisted.

All in all, if you have a limited amount of devices to connect, connecting new devices is something that’s rare, and you’re confident you can configure it properly it can prevent certain USB attacks from affecting you without a lot of inconvenience.

For me personally, I find myself in numerous occasions where someone hands me a drive to grab a file, I have use for an external network adapter (both ethernet and wireless), I dock my laptop and use external peripherals. Combined with the fact that I keep decent track of my hardware and don’t leave it unattended in the open, the overall risk of a physical attack is so little for me that and security benefit USBGuard would give me would be very little compared to the pain it would be to configure it properly for my use cases.

3 Likes
19

Or perhaps, just perhaps Your chosen OS can already inform you when a peripheral has been inserted/attached or ejected/removed. Although if you are paranoid to suspect tampering then perhaps you shouldn’t leave your framework in an area that can be easily accessed.

20

I believe there’s a common saying in the Linux/security world that applies here: ‘Physical access IS root access’.

If you can’t trust the environment the machine is physically located in, then all your software level security is moot. Don’t let it out of your sight, don’t allow people you don’t know/don’t trust to handle it, and definitely don’t plug in anything that you aren’t 100% sure of the origin of. With USB PD that goes for chargers and cables as well.

6 Likes
21

@Peter_Schofield is correct. The fact is that it is my laptop which means that it does not leave my person in insecure environments.

But I really want to second the USB PD charger comment. USB-PD requires some communication between the charger and the computer to deliver power efficiently. The issue is that chargers can be modified to introduce security risks via the USB process.

Make sure you have your untampered charger or power bank and do not accept charges from unknown cables or other people. ESPECIALLY in airports and malls or other high traffic areas.

As for the issue of the framework expansion cards, the concern is valid, but I would think the number of Frameworks in the wild limits the potential exposure. However, treat your expansion cards as you would your USB sticks and apply the same rules and should be fine.

22

Generally speaking, once an attacker has physical access to your device all security can be considered to be thrown out the window

6 Likes