Re: USB DOS attack (was Blocking new devices with UDEV?)

[Nathan Sweaney <NSweaney () tulsacash com>]

Adrian,
Can't help you there, but have you thought about the potential for DOS attacks using these techniques?  What if an 
attacker completely disables USB access to windows?  How many systems today still have PS2 ports?

It might not be very stealthy, but if you managed to gain access to a mission-critical server and could disable all USB 
access and other remote-access functionality, you'd probably have a little time before the admins decided to pull the 
plug.  If you blanked the screen as well it'd probably buy you even more.

> From the administrator's perspective, they've got a server that isn't giving a video signal, isn't responding to the 
> keyboard or mouse, and isn't allowing remote-control connections.  It very well could be an attacker, or just hardware 
> that's starting to fail.  As long as it's still performing its business function, they may have a hard time convincing 
> their superiors to bring it down during business hours.

To take it a step further, once you've got a backdoor in the system, create a script that re-enables the USB, video, & 
remote access.  Then set the script to run on boot so that it appears a reboot fixed the problems.  How many admins 
would classify that as a security incident when a simple reboot fixed the problem?

- Nathan


From: pauldotcom-bounces () mail pauldotcom com [mailto:pauldotcom-bounces () mail pauldotcom com] On Behalf Of Adrian 
Crenshaw
Sent: Saturday, October 02, 2010 1:23 PM
To: PaulDotCom Security Weekly Mailing List
Subject: [Pauldotcom] Blocking new devices with UDEV?

Hi all,
   I'm trying to figure out how to block the install of new USB hardware in Linux, sort of like how I can do it in 
Windows:

http://www.irongeek.com/i.php?page=security/locking-down-windows-vista-and-windows-7-against-malicious-usb-devices

I'm using blacklisting Dell stuff by vendor ID as an example, though it's not my end goal I'm just trying to figure out 
how things work.

I do a "cat /proc/bus/input/devices" to figure out which keyboard is which, then a "udevadm info -a -p 
/class/input/input10" to probe it for strings I can use in a udev rule. My rule looks like this (I tried two different 
ones, and commented things out):

ATTRS{idVendor}=="413c", MODE="0000", RUN+="/opt/kde3/bin/kate"

#ATTR{modalias}=="input:b0003v413Cp2106e0110-e0,1,4,11,14,k71,72,73,74,75,77,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8C,8E,96,98,9E,9F,A1,A3,A4,A5,A6,AD,B0,B1,B2,B3,B4,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,F0,ram4,l0,1,2,sfw",
 MODE="0000", RUN+="/opt/kde3/bin/kate"





Neather seems to do anything. Any ideas? I'm also not sure how to make some rules override others. Yes, I've seen 
http://www.reactivated.net/writing_udev_rules.html#external-run but it's not really helping me.

Thanks,
Adrian

_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com