Wednesday, April 9, 2014

Heartbleed

This bug will probably be taught in Comp Sci classes in years to come and the poor student Robin Seggelmann from T-Systems International who wrote this buffer bounds beauty, earned instant infamy.

It is a terrible, terrible bug - you send a request to a supposedly secure server and it returns up to 64KB of data, which on a busy mail service like Yahoo, could contain multiple user names, passwords and keys in each and every request.

The bad thing is that the heartbeat feature was not necessary.

A thing should be as simple as possible, but no simpler.
-- A. Einstein

T-Systems violated that principle and we are all paying the price.

Keepass

Give the good IT folks a few days to fix things and then change ALL your passwords everywhere and to preserve your sanity, do install Keepass (Windows), KeepassX (Linux, Mac) or KeepassDroid (Android).

Broken windows

The problem is actually not as widespread as feared.  According to Netcraft, while a good 70% of all servers use OpenSSL, about a quarter use Heartbeat, meaning that the total percentage of servers affected by Heartbleed, is under 20%, but for the next few days, you cannot trust anything.

Nevertheless, the broken windows fallacy means that some IT businesses will profit handsomely, especially the certificate vendors, at the expense of everyone else.

Now that many people are starting to look critically at OpenSSL, they are bound to find many other issues.  The OpenBSD contributors already started to scratch at it.  So expect to see a slew of updates over the next few weeks as large numbers of bugs get fixed.  Thanks to the heartbeat bug, OpenSSL should end up being much more secure than it ever was.

Who Knew?

The big question is who knew? 

In these matters the only certainty is that there is nothing certain. 
 -- Pliny the Elder

Did the NSA, GCHQ, CSE and others know about this bug for the past two years and happily collected logins and keys and does this explain why they could perform Man In The Middle attacks with such apparent ease?



Thursday, April 3, 2014

Fedora Linux eth0

Sometimes a change is not as good as a holiday.

I like the ethernet port zero to be named eth0 and not p2p1 or em1 or whatever the blazes the system decided to call it this time.  One of the problems with the new system is that if you don't use DHCP and want to set a static address, then there is no way to tell what the name of the interface is!

To get the standard behaviour back, you need to roll a few things back to the way they were on Fedora 17 and before.

Remove the annoying biosdevname package:
# yum remove biosdevname

Add net.ifnames=0 to GRUB_CMDLINE_LINUX in /etc/default/grub immediately before the last quote.

Reconfigure: 
# grub2-mkconfig -o /boot/grub2/grub.cfg

Rename /etc/sysconfig/network-scripts/ifcfg-whatever to ifcfg-eth0
Change to NAME=eth0 inside ifcfg-eth0

Run ifconfig and note the MAC ADDRESS, or get it from a sticker on the bottom of the machine:
# ifconfig 

Create file /etc/udev/rules.d/75-persistent-network-rules:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="<THE MAC ADDRESS>", NAME="eth0"

Now you can reboot:
# reboot

And check things with ifconfig once the machine is up again.

La voila!

Saturday, March 29, 2014

#3: Kali Linux on the Beaglebone Black

Ethernet and USB Problems

I tried Fedora on the BBB, but it is slightly behind the curve (strange for Fedora, which is usually bleeding edge), the ethernet and USB ports do not work yet since it needs a newer kernel.  The Debian distributions are better on the BBB.

So, one can blow against the wind, or try Debian...

Penetration Tests

I am working on a networked project which is an island system - it is not connected to anything else at the moment.  I say at the moment - since I know that sooner or later, the bosses will demand that it be connected to the something else, at which point the lack of attention to security will come to bite everyone.

There is a small security and penetration test oriented Debian based distribution called Kali Linux that you can get here http://docs.kali.org/armel-armhf/install-kali-arm-on-a-beaglebone-black

Kali installs on a SD card, so your original Angstrom Linux on the BBB will remain unaltered, which makes it worth a try.

An interesting feature of Kali, is the website, which was nicely translated into 13 languages.

With this version, you should be able to do various nefarious things to your fellow developers using the Metasploit package...

Get it and Prepare an SD Card

You can download the ARM HF image here http://www.kali.org/downloads/

Specifically:

Uncompress it with xzcat:
(For a Mac, get the xz utilities here: http://macpkg.sourceforge.net/)


xzcat kali-linux-1.0.6-armhf.img.xz > kali-linux-1.0.6-armhf.img


and copy it to the SD card with Data Definition like this: 
$ su -
password
# dd if=kali-linux-1.0.6-armhf.img of=/dev/sdb bs=512k

Using Data Definition on a Mac

Stop the automounter called diskarbitrationd temporarily, otherwise the SD card will be mounted and 'busy': 
$ sudo launchctl list | grep diskarbitrationd
16 - com.apple.diskarbitrationd 

$ sudo kill -SIGSTOP 16

Only now, stick the SD card into the Mac SD slot.

Open a terminal and type
$ ls /dev/disk*
/dev/disk0    /dev/disk0s2    /dev/disk1
/dev/disk0s1    /dev/disk0s3    /dev/disk1s1
 

The disk0 is your SSD and you don't want to mess with that!
The disk1 is the SD card.

Now, with the SD card unmounted, you can use dd to copy the BBB image to disk1:
$ sudo dd if=kali-linux-1.0.6-armhf.img of=/dev/disk1 bs=512k

On a Mac, Ctrl-T will show the dd progress.

Note that if you accidentally dd to /dev/disk0, then you will destroy your Mac system.
So, don't do that!

Finally, re-enable the automounter:
$ sudo kill -SIGCONT 16

Accessing the SD card from a Virtual Machine

I run Fedora 20 on my Macbook Pro and getting Virtualbox to see the SD card is somewhat painful.

First of all make sure that the Fedora virtual machine is NOT running.

Stop the automounter as above to ensure that the SD card is not mounted, then access it using a raw disk image.

Make a raw disk image file for Virtualbox:
$ VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk -rawdisk /dev/disk1


Attach the raw disk to a guest VM within the VirtualBox UI:
  1. Ensure the guest VM is not running.
  2. Open the settings area for the guest VM
  3. Click on "Storage" in the toolbar
  4. Next to the controller click on the icon to "Add Hard Disk"
  5. Select "Choose existing disk"
  6. Navigate to the /path/to/file.vmdk you used in step 3 and select it
  7. You should now be returned to the Storage tab and see your file.vmdk in the list.
  8. Start the VM
  9. The SD card will then be available as /dev/sdb 
Now you can use the Fedora VM to access the SD card normally and finally, when done, you can re-enable the automounter using kill -SIGCONT.

Boot Kali

Unplug the USB power cable, install the serial cable (Black wire at the little dot), plug in both USBs and run screen:
$ screen /dev/ttyUSB0 115200
or on a Mac:
$ ls /dev/tty.usb*
/dev/tty.usbserial-AH0142BF
$ screen /dev/tty.usbserial-AH0142BF 115200
Now plug in the USB power cable again and watch her boot.
There is also a little reset button on the corner at the 4 LEDs.

Bugs

Finally, I managed to boot the SD card and got this:
Hit any key to stop autoboot:  0
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
micro SD card found
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
** File not found uEnv.txt **
gpio: pin 55 (gpio 55) value is 1
** Invalid partition 2 **
U-Boot#


Hmm... now I'm wondering whether the mods on the Fedora BBB page are required here too:
$ cd /media
$ cp __/usr/share/uboot-beaglebone/* uboot/ 
$ cp uboot/uEnv.txt.beaglebone uboot/uEnv.txt
$ nano uboot/uEnv.txt 
abcboard=am335x-bone > abcboard=am335x-boneblack 
Some more sleuthing is required to sort this out.

Soooo, remove the USB power cable, remove the SD card and stick it into the Mac.
Aaaargh! Stupid automounter and stupid Mac that doesn't support the file system...

Boot a Linux machine and stick it in again.

An error occurred while accessing DEBIAN_LIVE...

Bah, humbug!  No wonder it won't boot either.

It really looks like it is time to find another distro again, or to build the darn thing myself.

Build It Yourself

If you are more adventurous, the Kali build scripts are on github here https://github.com/offensive-security/kali-arm-build-scripts

Get bbb.sh and README.md for the details.

I think I'll rather install QEMU on my Mac and build my own version of Fedora ARM, since that is the distribution I like the most.   More on this later.

Eish...

Sunday, March 23, 2014

#2: Doing Something with the Beaglebone Black

Something Useful: Retroshare

I actually want to run Streamtuner and Retroshare on the BBB.   More about Retroshare here: http://www.aeronetworks.ca/2013/07/your-own-darknet.html

The BBB will make a nice static DHT reference for my small circle of friends and devices on Retroshare, to ensure that all can always connect no matter how much anyone or anything moves around.

Expand the SD Linux File System

If you followed my first BBB post, then you have probably seen this already:
grep: write error: No space left on device

It looks like the first thing to do, is expand the root partition to fill the SD card, otherwise there is no room to do anything :(

On you computer, use screen to connect to the serial console over a FTDI USB serial cable:
$ screen /dev/ttyUSB0 115200

On a Mac, screen works the same, but the device is something like /dev/tty.usbserial-AH0142BF

So, what was that about Macs having sensible device names? Sigh...

Then power the BBB up using the USB cable, or a 5V PSU.

Login and set user to root:
Login: username
password
$ su -
password

See what is there:
# fdisk /dev/mmcblk0
Disk /dev/mmcblk0: 7.5 GiB, 8010072064 bytes, 15644672 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00036e16

Device         Boot     Start       End  Blocks  Id System
/dev/mmcblk0p1 *         1953     41015   19531+  c W95 FAT32 (LBA)
/dev/mmcblk0p2          41016    291015  125000   c W95 FAT32 (LBA)
/dev/mmcblk0p3         291016  15644671 7676828  83 Linux
 

The above tells me that the SD card is 8GB and there are 3 partitions.  The 3rd one is the Linux partition that we got to fix.  Note that the Linux partition fills the whole device, meaning that the partition is OK, but the file system doesn't fill the whole partition.  So it is only a file system problem, not a partition problem.

Grow the File System

Grow the filesystem over the rest of the partition:
$ su -
password
# resize2fs /dev/mmcblk0p3

La voila!

Well, assuming that it still works, otherwise you are back at square one and need to rewrite the SD card again, as per my other BBB post...

Make a SD Backup

At this point, it may be a smart idea to make a backup of the whole SD card, so that next time you have to rewrite the stupid thing, you don't need to do the setup steps again.  So shutdown now, power off and plug the SD card into a laptop computer then use dd or cat with gzip to make a copy of the SD card:
# cat /dev/mmcblk0 | gzip -9 > bbb-f20-1.gz 

or on a Mac, which will likely do a partial automount, you got to unmount it first:
$ sudo umount /dev/disk1s1
$ sudo cat /dev/disk1 | gzip -9 > bbb-f20-1.gz

Why does Macs have sensible device names while Linux is such a mess lately?

Since at this time the SD image is still mostly zeroes, the compressed image will be manageable, but it will take a looong taaaime to do, so go and get a tall, cold one...

Accessing the BBB Hardware

The serial ports are available in /dev/ttyox (that 'o' really is a letter, not a zero), while the GPIO ports are available in /sys/class/gpio:
$ ls /dev/ttyo* 
$ ls /sys/class
ata_device  graphics     mem            ptp          scsi_generic  vc
ata_link    hidraw       misc           pwm          scsi_host     vtconsole
ata_port    hwmon        mmc_host       raw          sound         watchdog
bdi         i2c-adapter  net            regulator    spi_master
block       ieee80211    pci_bus        rfkill       thermal
bsg         input        pcmcia_socket  rtc          tty
dma         leds         power_supply   scsi_device  udc
gpio        mdio_bus     pps            scsi_disk    usbmon


$ ls -al /sys/class/gpio
total 0
drwxr-xr-x.  2 root root    0 Jan  1  2000 .
drwxr-xr-x. 45 root root    0 Jan  1  2000 ..
--w-------.  1 root root 4096 Jan  1  2000 export
lrwxrwxrwx.  1 root root    0 Jan  1  2000 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx.  1 root root    0 Jan  1  2000 gpiochip32 -> ../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx.  1 root root    0 Jan  1  2000 gpiochip64 -> ../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx.  1 root root    0 Jan  1  2000 gpiochip96 -> ../../devices/virtual/gpio/gpiochip96
--w-------.  1 root root 4096 Jan  1  2000 unexport


Feel free to poke around, don't be shy...

Hardware Information:
Using GPIOs on Linux:
It is relatively straight forward to access a GPIO from a script, using simple echo statements, but one has to configure them before one can use them.

See table 10 on page 70 for the P8 header and table 11 on page 72 for the P9 header in the reference manual https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true

For example, P9 pin 15 is gpio[16] and is on gpiochip32, which has an offset of 32, so pin 15 is 16+32 = gpio48.

Two P9 header GPIO pin number mapping to kernel names:
  • pin 15 = gpio48
  • pin 16 = gpio51
To enable both pins:
# echo 48 > /sys/class/gpio/export
# echo 51 > /sys/class/gpio/export 

Now, there should be two new subdirectories in /sys/class/gpio representing these two pins and one can set the direction and a value for pin 15 and watch it toggle with an oscilloscope:
# echo out > /sys/class/gpio/gpio48/direction
# echo 0 > /sys/class/gpio/gpio48/value
# echo 1 > /sys/class/gpio/gpio48/value

Note that the BBB uses 3.3V logic and a pin can drive up to 5mA, so be careful with what you connect to it so you don't blow the pin drivers up.

You could use something like this opto-coupled solid state relay to control things with only 0.5mA per pin:
http://www.vishay.com/docs/81646/vo14642a.pdf 

A 3.3V supply minus 1.5V forward diode voltage, divide by 0.5mA, means using either a 270 or 330 Ohm series resistor on this type of opto-coupler.

La voila!


Saturday, March 22, 2014

#1: Beaglebone Black (BBB) with Fedora Linux

I bought a Beaglebone Black open embedded processor board about 6 months ago and it has been lying on the dining room table ever since.  Now that the missus went on a holiday to Poland and Slovakia, I finally got around to firing it up to see if it works.


Where to get it

The BBB project is here: http://beagleboard.org/Products/BeagleBone+Black

In the mean time, the Fedora project has released an ARM distribution that includes rudimentary support for the BBB: https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation

First of all, to see if the hardware is OK, I just connected a USB cable to it and started it up with the default Linux version residing on the device and it worked fine.  After installing a USB network driver on my Mac and restarting it, I could SSH to address 192.168.7.2 and poke around in Angstrom Linux.

Unfortunately, Angstrom Linux http://beagleboard.org/latest-images is not well supported - the project is very small with maybe just one or two not very active developers.

Anyhoo, the little board booted up fine, lights flashing merrily and I even got the ethernet port to work with SSH after a few minutes of futzing around with it and then I got the inevitable 'success depression': It works, now what do I do with it?  I cannot use Angstrom, since it is just too limited: No NFS, no SMB, no whatever I could think of.  What can I do with it?

Fedora to the Rescue

When dealing with these little boards, there is always the danger that one can do an update and render the board unbootable.  Therefore, I prefer leaving the original Angstrom system intact and experimenting with the micro SD card instead.

The Fedora project page states:
Support for the BeagleBone Black has been added in Fedora 20. The GA release includes basic support which will be extended to include HDMI and USB with the release of the 3.12 kernel. A remix is planned when support is available. In the interim, the minimal image is recommended. 

So there is hopeLet's get it and try it.  I was out of luck on my Mac, since I don't have zcat on it, so I switched to an older Linux machine with KDE and quickly got everything:
$ cd
$ mkdir BBB
$ cd BBB

Micro SD

Hmm, now I needed a small SD card and Carrefour had a special with two cards in one package - a small 8GB plus a 32GB.  So 30 minutes later and a few Dirhams poorer - well, nothing is free and few things are cheap - I stuck the SD card into the laptop and copied the image to the base of the SD device:
$ dmesg
$ ls /dev mmcb*
/dev/mmcblk0 /dev/mmcblk0p1

If you see multiple partitions, then this is probably a used SD card, so it may be best to zap it first:
$ su -
password
# dd if=/dev/zero of=/dev/mmcblk0
and go and get some coffee, or a non-alcoholic beer...

On a Mac, you first have to install xz from here:
http://macpkg.sourceforge.net/

Xz, xzcat and the rest of the zoo will install itself into /usr/local/bin by default.

Now you can write the image:
$ xzcat Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz > /dev/mmcblk0
(or $ /usr/local/bin/xzcat ... on a Mac)

Popping the SD card out and sticking it back in again, caused an automount in /media with two visible directories called "__" and "uboot".

According to the Fedora page a few little mods are required:
$ cd /media
$ cp __/usr/share/uboot-beaglebone/* uboot/ 
$ cp uboot/uEnv.txt.beaglebone uboot/uEnv.txt
$ nano uboot/uEnv.txt 
abcboard=am335x-bone > abcboard=am335x-boneblack 

Now, we are in business!

Boot Her Up

Stick the little card into the BBB, insert the USB cable to power it and watch the lights.  When the flashing stops after a couple minutes, Fedora is running, but now I need a serial cable to be able to connect to it...

Rummaging through my radio control junk box, I found a Sparkfun 3.3V FTDI USB serial cable https://www.sparkfun.com/products/9717, which is exactly what is needed.


So, unplug the USB power cable, install the serial cable (Black wire at the little dot), plug in both USBs and run screen:
$ screen /dev/ttyUSB0 115200

La voila! 

Fedora on the BBB works and after a few minutes it gets a menu where one can configure the root password, configure a user account and set the time zone.

So, now what can I do with it?
:)

US Navy Overreach

The US Navy was outed for collecting Pawnshop and Parking Ticket data on all and sundry in their LinX database - sigh...

What makes it even more silly, is that this data is already in a FBI database too.  If we ignore the fact that trivial data really should not be stored, the FBI is where it should be.

A few years ago, the US Air Force had a program called TALON that was also doing domestic spying, but it was shut down after a public outcry.  It appears that nobody learned anything.

There is an ancient proverb, dating back to the age of the dinosaurs that says:
Garbage In, Garbage Out (GIGO).

The gigantic GCHQ, CSE, NSA, Navy, Airforce, Army(?) server farms are not databases.  They are digital garbage bins.

Storing nonsense data at great cost is a total waste of money and resources and will not help catch any criminals - let alone supposed terrorists.  Spying on hundreds of millions of honest citizens is a total waste of time.  Reducing crime requires old fashioned police work - gumshoes pounding the pavement.  The online spying money can be much better spent on hiring and putting more Bobbies on the Beat.

It seems that nowadays public outcries don't help anymore and insanity is prevailing.

Wednesday, March 19, 2014

International Covenant on Civil and Political Rights

"Would the delegation recognize that the United States’ position on extraterritorial activities allowed the United States to commit violations everywhere except in their own territory?  The non-applicability of the Covenant to extraterritorial activities led to impunity and rights violations.  If all States were to share that interpretation, there would be no protection of rights at all.  Was the Government ready to review its position concerning the extraterritorial application of the Covenant?"

http://www.ohchr.org/EN/NewsEvents/Pages/DisplayNews.aspx?NewsID=14383&LangID=E

The US NSA and the UK GCHQ are so obtuse that it doesn't warrant further comment.