We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

USB borne attacks and usable defense mechanisms

00:00

Formal Metadata

Title
USB borne attacks and usable defense mechanisms
Subtitle
Hardening built into the operating system without compromising on usability
Title of Series
Number of Parts
561
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The attack surface of USB is quite large and while disabling USB altogether solves the problem, it creates many other. As do existing protection mechanisms. They suffer from poor usability and missing integration into the operating system. We present our approach to defending against rogue USB devices for a GNOME-based operating system. USB is arguably to most exposed interface of a user's machine. It allows an attacker to interact with pretty much any driver, many of which are of questionable quality. We try to be smart about when to allow new USB devices. First, we try to detect when the user is present, arguing that if the user is not then new USB devices should not work. But it is not that simple, because you might very well want to attach a new keyboard in case yours breaks. Keyboards, however, pose another risk as several attacks have shown. But not all keyboards are equally bad and we propose to promote a harmless keyboard to become dangerous after getting the user's consent. It is not entirely clear yet how to that best, so your feedback and a discussion is certainly welcome!
UsabilityMechanism designPhysical systemOperations researchComputer animation
Projective planeSurfacePerfect groupComputer virus
NeuroinformatikTerm (mathematics)ExistenceExterior algebraPhysical systemSurfaceComputer animation
Function (mathematics)InformationInformationUsabilityNeuroinformatikPosition operatorVirtual machineFunctional (mathematics)LengthMereologyProjective planeTask (computing)Multiplication signComputer animation
Information securityPermanentDecision theoryPublic key certificateIdentity managementVoltmeterSoftware repositoryObservational studyDecision theoryMultiplication signPermanentConnected spaceSoftwareOnline chatDependent and independent variablesGreatest elementCartesian coordinate systemLengthInteractive televisionProjective planeInformation securityExpert systemField (computer science)Inheritance (object-oriented programming)Right angleNeuroinformatikEmailTraffic reportingStress (mechanics)Internet service providerSoftware bugSoftware repositoryBookmark (World Wide Web)Software developerComputer animation
Information securitySingle-precision floating-point formatComputer animation
FingerprintNumberKey (cryptography)Sign (mathematics)
Right angleInformation securityPosition operatorSign (mathematics)Computer animation
ThumbnailComputerMaxima and minimaMenu (computing)Multiplication signKeyboard shortcutElectronic mailing listPosition operatorNeuroinformatikComputer animation
Gastropod shellKernel (computing)RootMIDIDevice driverPhysical systemKeyboard shortcutCodeSurfaceCASE <Informatik>CloningMultiplication signRevision controlSoftware bugNeuroinformatikDistribution (mathematics)Source codeComputer animation
SimulationNP-hardLipschitz-StetigkeitInstallation artPhysical systemShooting methodTouchscreenPersonal identification numberNeuroinformatikState of matterCASE <Informatik>Keyboard shortcutNumberPhysical systemTouchscreenWindowMultiplication signLaptopRight angleSocial class2 (number)Default (computer science)Group actionSet (mathematics)Web pageArithmetic progressionInternetworkingCategory of beingCellular automatonCloningRule of inferenceTheory of relativityBootingSerial portComputer animation
MathematicsDirected graphCodeDisintegrationData typeAuthenticationArithmetic progressionTouchscreenKeyboard shortcutCodePhysical systemNeuroinformatikBlock (periodic table)Slide ruleService (economics)Configuration spaceRight angleComputer iconLevel (video gaming)BitKey (cryptography)Process (computing)Inheritance (object-oriented programming)QuicksortFront and back endsInformation securityMenu (computing)UsabilityFunctional (mathematics)Information privacyAxiom of choiceProduct (business)Arithmetic meanCASE <Informatik>Control flowoutputHorizonGame controllerRow (database)Moment (mathematics)1 (number)AuthorizationComputer animationProgram flowchart
Data typeAuthenticationHorizonAuthenticationKeyboard shortcutPublic-key cryptographyVector spaceInterface (computing)BitInternetworkingQuicksortLattice (order)Standard deviationTouch typingProduct (business)Optical disc driveAuthorizationPublic key certificateMetropolitan area networkBootingHypermediaMobile appKernel (computing)Computer animation
Computer animation
Transcript: English(auto-generated)
Hello, everyone. Welcome to our next talk from Tobias Miller and Ludvico Dennitz about USB-born attacks.
Right, perfect. Hello, hello. Maybe, is this on? Ah, perfect, okay. So, if there's trouble with the microphone, let me know. So, I'm Toby. Hello, don't know if you know me. I'm in the GNOME project and so is Ludvico.
I'm Ludvico, hi. And I'm very happy to be here and to be talking to you about, well, the attack surface of USB. How many of you have a device that's capable of having a USB device attached?
Quite a few. There's some who haven't raised their hand. I'm surprised. Like, do you have a computer? So, we're working on protecting against rogue USB devices. That is, Ludvico is doing all the work and I'm telling him how good he is. And I congratulate him to his achievements. And we will present what we think or how we think we should introduce these capabilities of protecting against USB devices
such that they actually work in terms of they unfold their protection capabilities. And what that means, well, you will hopefully see once we have the examples of why we think it doesn't right now.
But first, let me tell you really quickly why I believe that GNOME is in a very good spot of providing these protection capabilities. So, this whole reason of GNOME's existence, as you all know because we're in Fazdom, is freedom.
So, GNOME was well created as a free alternative to, back in the day, proprietary systems. And there's many definitions of freedom, including those, you know, for your free computing. We also believe that you should be free from concerns of your computing being compromised. And we ought to achieve this, well, as well as possible without compromising on your way of using the machine or your usability.
Why do I think that we're in a good position? Because it turns out that filtering out extraneous information is the basic function of consciousness. So, your brain does nothing else but filtering out all the unnecessary stuff. And I think that with GNOME we found workflows and ways of interacting with the user that prevents, well, unnecessary things
and allows the user to concentrate on what, well, they want to do. Because we firmly believe that the user does not sit in front of the computer because they like to sit in front of the computer. I'm sure many of us do. But most people I believe or most people we believe in the GNOME project are sitting in front of their computer because they need to perform a task.
And if you interrupt them performing the task then users go to great lengths of getting back to their work. So, I believe that once you make the user part of your security system you're going to have a bad time. You must not, you know, make the user make decisions that they will regret. And in fact there have been studies, academic studies, which show that, well, you better throw a coin rather than letting the user decide.
You end up with better decisions. So, what is the problem about interrupting the user? Well, as I've said, once you distract the user from what they want to achieve they will want to go back to that. And they click on that button on the lower right because they know that this click makes this annoying dialogue disappear.
So, prompts are dubious in first place. Security prompts are just wrong. I claim that you must not prompt the user or interrupt the user doing their work with a security relevant prompt asking the user something.
Worse, if you're making this decision that the user took under stress, permanent, I claim that this is plain evil. You must not do that under any circumstances. If you take one thing away then it's this. Do not have interactive or user interaction in a way that distracts the user from whatever they're doing and make this decision permanent such you prevent the user from learning how to undo this decision.
So, don't do this. What do I mean? So, I've brought a few examples. It's GNOME projects. It's GNOME software. So, you know, I'm blaming and shaming but it's all lost anyway. You all know this. This connection is untrusted. Do you want to continue anyway? This happens or happened when you opened your chat application.
Imagine the user. They want to chat. They open the chat application and they're being asked. You've opened this chat application. Do you really want to open or rather not? Have you decided that within this 20 milliseconds that I took to load this dialogue, do you now not want to open the chat application?
I sympathize with the developers of using this user interaction because it's a relatively cheap way of alerting the user and pushing off responsibility. Well, I can talk about this at great length but we don't have time for that. So, there's another one which I liked. This software is just a package install, like some software installation thingy.
It tells you that the software you've just downloaded isn't signed and is not trusted by a provider and so on. We can make sense out of that because we're in the security dev room. We're the experts in the field. But I have parents and they want to use the computer to send me an email, preferably encryptedly and so on. But this is gibberish.
This doesn't make any sense. How would they know whether the software is trusted or not? They don't have any clue. And this is my absolute favorite. You get this prompt and it says, Albert found a new update which fixes your problem. Please run before submitting the bug. PKCon update dash dash repo dash dash enable. And then, yes.
What? So, it's terrible, right? I think we can generalize this into if you have a security system and you require the user to do anything with it, that's fine. But be ready to lose half of the audience, half of your user base, with every single click or keystroke.
And because we're past them, I thought it'd be funny to show you this. Does anybody remember or know what this is? Key signing. Yeah, what do these people do? Like, what do they actually do? Yes, they do key signing, but what do they do? Yeah, they walk along each other and they mumble fingerprints
like these hexadecimal numbers and it takes ages and it's awful because it's cold because it's February. In the middle of Europe, it's cold. And then you get home and you're not sure what you actually read and so on. So, it's terrible. Well, we've also fixed that, I think. So, there's no key sign, but we're not here to talk about no key sign. But that's the mindset, right?
We're trying to reduce all these things that security people came up with by something that will hopefully be able to be used by normal people. So, that's the general mindset of why I think, or we think, we're in a good position.
And now I'm very excited to hear Ludovico talk about the actual USB stuff. So, as Tobi said, USB devices are everywhere. And the users maybe most of the time don't think that USB is a threat to their computer.
And maybe even the most common scenario is when a user locks his computer, it goes to the bathroom, and it leaves the computer unattended. In this scenario, the USB ports are still running, so someone can pass by and plug a malicious USB device to the computer.
And most of the time, users are not aware of this. And so, USB devices can be really dangerous. For example, just the recent screenshot of the CV list related to USB,
it has more than 200 entries. And the most famous attack to using USB devices is the bad USB,
where a malicious device, it was just a pen drive, but it also advertised itself as a keyboard. So, when you plug this device in, it can act as a keyboard and enter keystrokes automatically.
So, this is a CV that we tried to demo. And this is a VM of Ubuntu 14.04, because the CV is two years old. And just using a specially crafted USB device like this,
it's an Arduino Leonardo clone. It advertises itself as a MIDI keyboard that has a bug in this particular kernel version.
And just plugging this device in this computer, it will create a kernel panic. This can also be exploited to gain a root shell in this computer. So, in this case, it's just a kernel panic, but it can be even worse.
From a MIDI keyboard. When's the last time you've attached a MIDI keyboard? So, any USB device has the privilege of loading any kernel driver that you've installed on your system. Turns out that if you have a general purpose distribution, well, then you have all the drivers that have ever been written for Linux. Ever. And it turns out that this is quite a large code base.
Your text surface is very large in this case. Yep, that's right. And what other people already did to mitigate this USB problem? Well, for example, in Windows, there is Kaspersky that lets you enable USB protection.
And every time you plug a new device, you'll get this prompt with a pin that you need to enter with the newly plugged device. And it's confirmation that you are willingly plugging a keyboard or a mouse in your computer.
This is USBGuard. This is the UI of USBGuard. It lists all the currently plugged-in USB devices. And it says if they are allowed or blocked in the current state.
And this is the related setting page of USBGuard where you can set the default action for new USB devices and the timeout and other stuff.
In practice, when you plug a new device, you get this pop-up right here. It has a bunch of numbers and letters. It says the serial number, the name of the device.
This is the USB class. And you have 23 seconds to decide if you want to allow it or block. And if you don't act in this 23 seconds, this pop-up will go away and you have this USB device that will not work.
This is USBGuard GNOME. It's a better attempt to manage USB protection. It still lists all the USB devices that you have. And when you plug a new device, you'll get a notification better integrated in the system with the allow or block button.
But still, in this case, the user needs to decide what to do. And also, if you don't press any of these two buttons in maybe 5, 10 seconds, this notification will go away and you will not be able to see these buttons anymore.
Yeah? You can select allow or block with the keyboard. If I plug in a USB device, you lose a keyboard driver, which already does allow for you.
The new plug-in device is blocked until you press allow. So if I plug in a keyboard, runtime, I cannot allow it because the keyboard doesn't work. If you don't have any other mouse or keyboard already connected, you cannot.
If they are authorized at boot time, yes. So for the internet, there have been many comments around whether this dialog now could be used from this malicious keyboard that you've just plugged in. The answer is we get back to that in a few slides. The thing is that you can clone a USB device.
So if there is any rule that allows some kind of USB device with a specific serial number, you just clone it and it is allowed by default. You don't see this pop-up and you can play with it. Yeah, these are just numbers advertised by the device itself so you can clone them. And if you know that a particular device is already authorized, you can clone this device with yours.
So then we go here where even just installing USB guard with its UI, a bunch of users completely blocked theirself from the system.
It's very secure. Yeah, in this case they are completely protected from malicious USB devices. So our attempt here is we have a few takeaways here.
And the first one is that we don't want to lock users out from their system. And we tried an approach where is that we incrementally build the protection. So we started from simple cases and then we grew it up.
For example, the first step was a switch on-off where you can disable all new USB devices. And this was related to a simple use case where the user maybe they want to go for a travel
and so they bring their laptop with them. They want to be secure against USB devices that some user may plug in their laptop. So they just turn on the protection and no USB devices will be allowed.
Then a more smarter protection, it's why lock screen is on. In this case, if the lock screen of your computer is on, then no USB devices will be allowed. If the lock screen is off, then you can plug new USB devices.
And this is because if your lock screen is on, maybe it's because you're not in front of your computer so you don't want to plug new devices. And the first step that is still a work in progress is to treat differently the keyboards because they are one of the category more dangerous for USB
because you can plug a keyboard that ultimately inputs some keystrokes on your belief. So this is how we present our functionality. This was a concept where in the control center in the privacy tab
we added this Disallow New USB Devices row and it had a simple on-off switch.
The second attempt for the scenario, we had this drop-down menu where you can select the protection level that you want. This is like always protect or only when the lock screen is locked. And this is how it currently works.
We have this on-off switch and then you can select the protection level that you want for your USB devices. And it also checks because in the back end we use USB guard
so it checks if USB guard is currently available in your system and if it's not then you cannot turn on the protection.
We also show an icon in the top bar letting the user know that the USB protection is currently active. And also in this case if USB guard is not available or the protection is not active we don't show the icon.
And this is a recap, I don't know if you can see this, of what happens when you plug a new device in your computer. If the USB protection is disabled then the device will be authorized.
For example if you have USB guard installed and manually configured or use a third party UI for USB guard then from the GNOME standpoint we don't block this device. We let the user do what they configured in their system.
If the USB protection is on then we as GNOME are the ones that manage the USB guard configuration. So if the protection is never blocked then we manually authorize the devices, new devices that are plugged in the system.
If you have a block with lock screen then we check if the lock screen is active if the lock screen is not active then we authorize the device. If the lock screen is active we add this extra check about the keyboards and we check if the plugged device is a keyboard
because if for example your main keyboard breaks and you have the protection enabled then you are unable to plug a new keyboard in your system and you are basically locked out of your system.
So in this check we control if the keyboard that you are trying to plug is the only available keyboard in your system. If it is then we authorize the keyboard even if the protection was active.
This is mainly a choice. We choose that because we are willing to compromise a bit of security in favor of a more usable system.
So notice how we've tried very hard to not ask the user about whether they want to have this device attached. We try to infer the intent of the user by other means that we have available as the session, for example the lock screen.
We hope that this provides better protection overall knowing that users will know the security solution without maybe even knowing that it exists because it just works. We haven't finished. This is all a work in progress, right? So if you have comments or ideas then now is the perfect moment
because we are just right now in the process of letting all bits and pieces fall in place so that this works. So if you have ideas as to what else needs to be done or should be done then we are all ears for taking comments regarding what to do. I think the most prominent attack that we've seen this bad USB stuff
we are trying to be clever about this and try to swallow the keys that are not or that we consider to be dangerous. So a keyboard can press all sorts of keys, right? And we somehow need to deal with a keyboard
pressing say Alt-F2 and then R or something because we wouldn't want a malicious keyboard to steal our mind super high score or whatever. So we are in the progress of writing this code and getting the infrastructure in place to detect whether keystrokes have come from a keyboard
that we are not fully trusting yet maybe. This is all being developed right now as we speak. So again if you have comments around this please approach us. And let me just finish up this last slide. We have other things that we have on the horizon.
The most important one probably being the USB Type-C authentication. So in the standard is a way for USB devices to be authenticated. So in the future USB devices will have private keys and certificates and then you can ask the device whether it really is that device that you think it is.
For better or worse. I don't see how it currently would work in Linux. So we will have to deal with this situation eventually. Well, sort of. Like there is Thunderbolt as well. You could argue that it is very similar in what it does and how it works.
So we might sort of touch base with the Thunderbolt stuff and reuse things and bits and pieces from there. Another bigger problem is that if we wanted to eventually ramp up protection capabilities. As we've mentioned we want to start slowly and then incrementally build up our protection capabilities.
And one thing we don't know yet how to do properly is the early boot phase. Like before our stuff even runs. That's a bit unknown how to do that. Yeah, with that I think we are ready to close and take questions. And first we'd like to thank you for your attention and then we are happy to discuss. Now or later of course.
So that being a few hands. Maybe let's use the microphone for the internet. So what do you authorize? Devices or interfaces? So us using USB guard there is only devices for now.
Okay, because kernel now supports also interface authorization and I think it is way better. Because the typical attack vector for that to still exploit the same CVE. Would be just to provide the man in the middle device that will introduce with the same vendor ID, product ID etc.
As keyboard and app interface with the media.