Monthly Archives: September 2014

DHCP Client Proof of Concept Bash Exploit

I had heard talk about how the Bash vulnerability might affect DHCP clients.  I guess this is what they meant:


XWindows on EC2

Launch Xming server on local desktop (Windows)
Turn on X11 forwarding in putty.
(I did not have to set any local DISPLAY environment variables)

sudo yum install xorg-x11-xauth.x86_64 xorg-x11-server-utils.x86_64 xterm

I think I logged out and then ssh’d back in at this point (with X11 forwarding on).

Then I just did an “xterm”. That should open a new terminal window. From that you should be able to run commands that need to open new windows without having to set additional environment variables. The window took a bit to open. If it doesn’t pop up, look at your task bar to make sure it didn’t start minimized. I think that may be an Xming thing…

For a really slow browsing experience (or to run an installer that needs a web browser):

sudo yum install firefox

Then run firefox from the xterm….

Bash Vulnerability Disscussion

AWS Linux EC2 Instance Creation Checklist

This is intended to be an ongoing check list of tasks (with implementation notes) to perform when creating a new Linux instances on AWS

  1. Choose OS (I am trying to use Ubuntu for instances that don’t specifically require RHEL )
  2. Create the instance with desired root volume size.  RHEL seems to create a volume with the specified size, but then allocates a 6GB root partition.
  3. Choose appropriate VPC, subnet (considerations: public, private, AZ, what RDS or other instances need to communicate with it)
  4. Select the appropriate Key (will create additional accounts and assign keys as needed)
  5. Select or Configure Initial security rules
  6. Start instance
  7. Resize root partition if necessary (currently only necessary for RHEL 7 instances)
    1. Stop the instance
    2. If you have done any configuration already, take a snapshot of the volume to protect your work (only if restoring the snapshot would be worthwhile should something go wrong)
    3. Note the mount point and volume name of the root volume
    4. detach the volume and attach it to another instance (preferable running the same OS – spin a temporary one up if needed).  You do not need (nor want) to mount it.
    5. See:  (read this to verify the next steps still hold – and to see example output)
    6. make sure that the filesystem is OK BEFORE you resize it.  (the URL above skips this step):   xfs_repair /dev/xvdf1  (for xfs used by RHEL 7) OR for ext4: sudo e2fsck -f /dev/xvdf1  (or whatever device you attached the volume as)
    7. parted /dev/xvdf (or whatever device you attached it as)
    8. (parted) unit s
    9. (parted) print
    10. (parted) rm 1
    11. (parted) mkpart primary 2048s 100% OR (for gpt partitions) (parted) mkpart Linux 4096s 100%
    12. (parted) print
    13. (parted) set 1 boot on
    14. (parted) quit
    15. xfs_repair /dev/xvdf1  (for xfs used by RHEL 7OR for ext4: e2fsck -f /dev/xvdf1  (or whatever device you attached the volume as)
    16. detach the volume and reattach it in the proper place on the new instance
    17. start the instance
  8. Allocate desired swap space as a swap file
    1. This example will assume an 8 GB swap file (/var/swap.1)
    2. sudo  /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=8000
    3. chmod 600 /var/swap.1
    4. sudo /sbin/mkswap /var/swap.1
    5. sudo /sbin/swapon /var/swap.1
    6. To enable it by default after reboot, add this line to /etc/fstab: /var/swap.1 swap swap defaults 0 0
  9. Configure hostname
    1. hostnamectl set-hostname <hostname.FQDN>
    2. add hostname and FQHN to /etc/hosts
    3. modify /etc/cloud/cloud.cfg and comment out the set_hostname, update-hostname, and update_etc_hosts lines
  10. Set timezone
    1. (RHEL 7)  timedatectl set-timezone America/Chicago
    2. ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime    (verify that timedatectl did this for RHEL 7 – if not, do it!)
  11. Create additional accounts
    1. groups ubuntu (or ec2-user)
    2. useradd -s /bin/bash -m -d /home/newuser -G adm,cdrom,floppy,sudo,audio,dip,video,plugdev,netdev newuser
    3. edit /etc/sudoers:
      newuser ALL=(ALL) NOPASSWD:ALLOR change%sudo ALL=(ALL:ALL) NOPASSWD:ALL  (put NOPASSWD: into existing line – for some reason this works for ubuntu but not for the second user without spec’ing this)
    4. mkdir ~newuser/.ssh
    5. vi ~newuser/.ssh/authorized_keys
    6. add in the contents of the file from the my repository
    7. chmod 700 ~newuser/.ssh
    8. chmod 600 ~newuser/.ssh/authorized_keys
    9. chown -R newuser:newuser ~newuser/.ssh
    10. test logging into the account from another machine and verify that “sudo bash” works.
  12. Allow passwords for SSH (ONLY if required/desired)
    1. edit /etc/ssh/sshd_config and set PasswordAuthentication yes
    2. restart sshd
  13. Create and mount additional volumes
  14. Configure automatic backups
    1. set the Autosnapshot tag to True for all volumes that you want backed up automatically
  15. Install additional software
  16. Do initial software update
    1. apt-get update && apt-get dist-upgrade
    2. yum update
  17. Configure automatic updates
    1. RHEL: yum install yum-cron
      1. for RHEL < 7, edit /etc/sysconfig/yum-cron
      2. /etc/init.d/yum-cron start
      3. chkconfig yum-cron on
      4. For RHEL >= 7, edit /etc/yum/yum-cron.conf
      5. if you only want security updates => update_cmd = security
      6. apply_updates = yes (also download_updates)
    2. Ubuntu:
      1. apt-get install unattended-upgrades
      2. dpkg-reconfigure -plow unattended-upgrades
      3. verify /etc/apt/apt.conf.d/20auto-upgrades
      4. verify /etc/apt/apt.conf.d/50unattended-upgrades (verify reboot time and that automatic reboot is true)
  18. Tag volumes for automatic backup
    1. set the Autosnap tag to True
  19. Configure and test additional security rules
  20. Create a restore AMI!  (Since this creates a snapshot, I don’t <think> this will take up a lot of extra space for instances that we plan to backup anyway.)  This is a REALLY good idea since restoring a snapshot relies on you to first create a new instance based off the same AMI as the original and then replace or attach the volume on that instance.  We can’t guarentee that the original instance will still be available.

Test bash vulnerability for new remote expoit

env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

This should give an error if the system is patched.  Otherwise, it will echo vulnerable\n this is a test

Virt-Manager and Autostart

virsh autostart instancename
virsh autostart instancename –disable

Magic Qemu USB 3.0 with Windows Guest Recipe

I now have a working USB 3.0 drive on my Windows 7 guest using QEMU 2.1. Here is what I think is the working “Recipe” for this on Ubuntu 14.04:

Get the newest (at the time of this writing) Seabios: from
sudo dpkg -i seabios_1.7.5-1_all.deb
sudo add-apt-repository ppa:jacob/virtualisation
sudo apt-get update
sudo apt-get dist-upgrade

I then got my Windows 7 driver from I chose the driver for the older card listed on that page: “Plugable PCI-e cards purchased before 10/16/2012 are µPD720200 based and require the driver package.” The direct link for the download is

After installing the driver, everything worked!

Other notes:

I am not using passthrough (although I will probably test this later to see if there is any performance difference).
I am using Virt-Manager from the ppa above (THANK YOU Jacob Zimmermann!)
I have the usb controller set to usb 3.0 in the VM configuration.

There was much rejoicing — but I will spare the world any and all images of my happy dance… NO ONE wants to see that..!

Chrome DNS Troubleshooting

Learned a couple things about Chrome that I didn’t know.

chrome://flags (disable async DNS)

Seabios 1.7.5 and Qemu 2.1

So apparently I may need a new version of Seabios (1.7.5) to use the new version of qemu from the ppa I was tryng…

I can’t find a Trusty port, so I’m going to use a .deb package from “Jessie” which is (I think) the version Ubunutu 14.04 is based off of.

sudo dpkg -i seabios_1.7.5-1_all.deb
sudo add-apt-repository ppa:jacob/virtualisation
sudo apt-get update
sudo apt-get dist-upgrade

Well, it doesn’t crash…

It recognizes the USB controller, but I can’t see the either USB memory stick or my external drive…

Properly add, then hopefully remove ppa…

Note that the problems I’m having with this ppa are more likely something I’ve done wrong. I’m hoping properly add, then remove the ppa with ppa-purge. That should, in theory downgrade me back to the original versions of qemu. Otherwise, I may just remove them, and force reinstall the parts I think I need to get back to the old Windows VM working. Then I might try the PPA again.

Proper way to add:

sudo add-apt-repository ppa:jacob/virtualisation
sudo apt-get update
sudo apt-get dist-upgrade
ppa-purge ppa:jacob/virtualisation

apt-get remove –purge qemu*
apt-get remove –purge virt-manager virt-viewer sudo apt-get install libvirt-bin
apt-get remove –purge spice-vdagent virt-viewer libspice-client-gtk-3.0-4 virt-manager qemu-system spice-client spice-client-gtk python-spice-client-gtk
apt-get autoremove
apt-get update
apt-get dist-upgrade

sudo add-apt-repository ppa:jacob/virtualisation
sudo apt-get update
sudo apt-get dist-upgrade
apt-get install spice-vdagent virt-viewer libspice-client-gtk-3.0-4 virt-manager qemu-system spice-client spice-client-gtk python-spice-client-gtk libvirt-bin qemu
ppa-purge ppa:jacob/virtualisation

AT THIS POINT THINGS WORKED — I was apparently back the state I was in before adding the ppa. Now, glutton for punishment that I am, I’m trying again:

sudo add-apt-repository ppa:jacob/virtualisation
sudo apt-get update
sudo apt-get dist-upgrade
No joy…

sudo ppa-purge ppa:jacob/virtualisation
sudo apt-get update
sudo apt-get dist-upgrade

And back to working… Still no usb 3… Maybe if I syspreped the windows image or installed fresh from this version of qemu????