Auditing USB Question

Auditing USB Question

[Josh]

I'd like to audit the insertion and removal of all USB devices but I'm 
not sure where to start.

Do I need to be auditing a specific syscall, should it be a udev 
configuration?

Any tips would be greatly appreciated.

Thanks,
-josh

Re: Auditing USB Question

[Josh]

[-- Attachment #1.1: Type: text/plain, Size: 911 bytes --]

On Jul 31, 2013, at 5:47 PM, zhu xiuming <xiumingzhu@gmail.com> wrote:

> my guess is 
> -a always,exit -F arch=ARCH -S mount -F auid>=500 -F auid!=4294967295 -k export
> 
> refer to http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
> 
> 
> On Wed, Jul 31, 2013 at 8:41 AM, Josh <jokajak@gmail.com> wrote:
> I'd like to audit the insertion and removal of all USB devices but I'm not sure where to start.
> 
> Do I need to be auditing a specific syscall, should it be a udev configuration?
> 
> Any tips would be greatly appreciated.
> 
> Thanks,
> -josh
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
> 

That appears to only cover the mounting of filesystems, not any usb device insertion.  Specifically I'd like to capture the insertion of a USB keyboard, USB mouse, or USB thumb-drive.

Thanks,
-josh


[-- Attachment #1.2: Type: text/html, Size: 1880 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Auditing USB Question

[lists_todd]

On Jul 31, 2013, at 8:41 AM, Josh <jokajak@gmail.com> wrote:

> I'd like to audit the insertion and removal of all USB devices but I'm not sure where to start.
> 
> Do I need to be auditing a specific syscall, should it be a udev configuration?
> 
> Any tips would be greatly appreciated.

On my Mac (and BSM) I use syslog data to identify USB inserts, which includes the USB's manufacturer, model number, and serial number. Then I look at the mount command in the BSM data to see where it was mounted in the file system. Since I monitor all file reads and writes in BSM, I can also tell what files were read from or written to that USB thumb drive.

See if the Linux syslog messages contain the USB insert information.

Todd

Re: Auditing USB Question

[Steve Grubb]

On Wednesday, July 31, 2013 08:15:21 PM Josh wrote:
> That appears to only cover the mounting of filesystems, not any usb device
> insertion.  Specifically I'd like to capture the insertion of a USB
> keyboard, USB mouse, or USB thumb-drive.

There is no support for that. Auditing is mostly shaped by common criteria 
requirements. CC takes the point of view that data import and export is of 
interest. In order to do that, you have to mount a file system. So, the 
solution is to watch for mounts. The act of inserting a device has not been 
considered security relevant because it also says that there is physical 
security of the data center and random people can't stick random devices into 
the computer

That said...there is the real world. I could see this being interesting for 
very paranoid setups where a random device could be inserted and start fuzzing 
the kernel to inject code. But if we consider this, there is also bluetooth 
and firewire and who knows what other interface to worry about.

It might be possible to find the udev code that gets executed and place a watch 
on that. Or perhaps modify udev code to send a AUDIT_TRUSTED_APP event which 
ausearch/report will not impose and control over.

-Steve

Re: Auditing USB Question

[Trevor Vaughan]

[-- Attachment #1.1: Type: text/plain, Size: 1801 bytes --]

You don't have to mount media to pull off the data.

dd + one of any number of user space utils can extract data.

But, UDEV is probably the correct subsystem for this.

Trevor


On Thu, Aug 1, 2013 at 12:35 PM, Steve Grubb <sgrubb@redhat.com> wrote:

> On Wednesday, July 31, 2013 08:15:21 PM Josh wrote:
> > That appears to only cover the mounting of filesystems, not any usb
> device
> > insertion.  Specifically I'd like to capture the insertion of a USB
> > keyboard, USB mouse, or USB thumb-drive.
>
> There is no support for that. Auditing is mostly shaped by common criteria
> requirements. CC takes the point of view that data import and export is of
> interest. In order to do that, you have to mount a file system. So, the
> solution is to watch for mounts. The act of inserting a device has not been
> considered security relevant because it also says that there is physical
> security of the data center and random people can't stick random devices
> into
> the computer
>
> That said...there is the real world. I could see this being interesting for
> very paranoid setups where a random device could be inserted and start
> fuzzing
> the kernel to inject code. But if we consider this, there is also bluetooth
> and firewire and who knows what other interface to worry about.
>
> It might be possible to find the udev code that gets executed and place a
> watch
> on that. Or perhaps modify udev code to send a AUDIT_TRUSTED_APP event
> which
> ausearch/report will not impose and control over.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[-- Attachment #1.2: Type: text/html, Size: 2459 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Auditing USB Question

[Josh]

[-- Attachment #1.1: Type: text/plain, Size: 2610 bytes --]

On 08/01/2013 02:04 PM, Trevor Vaughan wrote:
> You don't have to mount media to pull off the data.
>
> dd + one of any number of user space utils can extract data.
>
> But, UDEV is probably the correct subsystem for this.
>
> Trevor
>
>
> On Thu, Aug 1, 2013 at 12:35 PM, Steve Grubb <sgrubb@redhat.com 
> <mailto:sgrubb@redhat.com>> wrote:
>
>     On Wednesday, July 31, 2013 08:15:21 PM Josh wrote:
>     > That appears to only cover the mounting of filesystems, not any
>     usb device
>     > insertion.  Specifically I'd like to capture the insertion of a USB
>     > keyboard, USB mouse, or USB thumb-drive.
>
>     There is no support for that. Auditing is mostly shaped by common
>     criteria
>     requirements. CC takes the point of view that data import and
>     export is of
>     interest. In order to do that, you have to mount a file system.
>     So, the
>     solution is to watch for mounts. The act of inserting a device has
>     not been
>     considered security relevant because it also says that there is
>     physical
>     security of the data center and random people can't stick random
>     devices into
>     the computer
>
>     That said...there is the real world. I could see this being
>     interesting for
>     very paranoid setups where a random device could be inserted and
>     start fuzzing
>     the kernel to inject code. But if we consider this, there is also
>     bluetooth
>     and firewire and who knows what other interface to worry about.
>
>     It might be possible to find the udev code that gets executed and
>     place a watch
>     on that. Or perhaps modify udev code to send a AUDIT_TRUSTED_APP
>     event which
>     ausearch/report will not impose and control over.
>
>     -Steve
>
>     --
>     Linux-audit mailing list
>     Linux-audit@redhat.com <mailto:Linux-audit@redhat.com>
>     https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
>
> -- 
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
> tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>
>
> -- This account not approved for unencrypted proprietary information --
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

I decided to write a simple udev rule that is triggered when a USB 
device is added.  From here I can use environment variables to choose 
which data gets sent to the audit system as a USER message. This will be 
enough for our purposes.

For reverence, here is the udev rule:

ACTION=="add", SUBSYSTEM=="usb", RUN+="/usr/local/sbin/usb_device_add.sh"

Thanks!
-josh

[-- Attachment #1.2: Type: text/html, Size: 4656 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]