Category Archives: Hacking

DockStat: Docker stats in a simple to use and easy to read Bash script

2 minutes, 38 seconds

Intro

At work I’ve been doing a lot of Docker based projects. I ended up writing a neat little Bash utility which I then recently extended into what I’m calling DockStat. It shows running containers and their related resources. You could use it if you’re repeatedly upping, downing and destroying docker containers over and over like I was. Or maybe you just want a nice little dashboard to see what’s running on your server?

DockStat at work

However, if you have more than say a dozen active containers, this script might not scale nicely (oh, perhaps a monitor in portrait mode might fix this? ;)

Being the good little open source nerd that I am, this is of course available for download with a permissive license in the hopes that some one will find it useful or possibly even offer a PR with some improvements to my nascent Bash coding skills.

Background

With countless primers on how to use Docker out there, I won’t get into what the commands all mean, but the impetus for this script was repeatedly running docker ps to show a list of the active containers. A bit later I remembered you could run endless Bash loops with a one-liner which made the process a bit nicer as it auto-refreshed:

while true; do clear;date;docker ps;sleep 5; done

A bit after that I stumbled upon the glorious watch command! Wow – just when you think that that you know and OS, they come and show you that there’s this awesome command they’ve been hiding from you all these years. Thanks Linux!

watch greatly improved on my Bash one-liner as it was an even short one-liner, could trivially be configured to refresh at what ever frequency you wanted and show a header or not. The icing on the cake was that prevents the flash of a redraw upon refresh:

watch -t -n 1 docker ps

About now I got more cozy with the --format feature built into most Docker command line calls. This was handy because I could reduce the number of fields shown in docker ps that I wasn’t interested in. Here’s maybe the simplest of them which shows JUST the container name and if how long the it has been running:

docker ps --format='{{.Names}} {{.Status}}'

Research continued on how to architect the helper script. I had need to show different data than docker ps had to offer. I branched out into docker inspect as well as finding other Dockeristas one-liners that I shamelessly co-opted (I’d be honored if anyone did the same of my work!!). This allowed me to joined ps and inspect like as seen with this fave that shows all the running containers’ and their internal IPs:

docker ps --format='{{.Names}}'|xargs docker inspect --format='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'

I was ready to assemble all the docker Data dukets I’d gathered into a nice CLI dashboard so our app developers could see the status of our containers booting. Finding a solution for this enabled both the the helper script to spring forth and simultaneously created the nascent DockStat. This was a Bash utility that was both easy to use, automates flash-less refreshes and introduced basic terminal layout functionality with a near zero learning curve (assuming you know Bash): Bash Simple Curses

Thanks

Thanks to James and Russ for reviewing my code and an early draft of this post. I’ve been trying to improve both my posts and code and this won’t happen without folks kind donation of their time and input!

Portable, headless Raspberry Pi development

2 minutes, 6 seconds

The Problem

Back when I was writing Cattrotar on a Raspberry Pi (or really, any other of the myriad times I was hacking on a small embedded device), I often faced some sort of problem or another:

  • I thought I set up the network for a device, but can no longer remotely access it over WiFi
  • I’ve just written a new OS to a microSD card, want to further configure the OS but it’s not yet reachable on the network
  • I want to take my set up to the hacker space to be social while I work on an issue
  • I’m waiting in the library for my kids to finish up a class and can’t easily get my Pi on the library WiFi to hack on it from my laptop
  • I don’t want to carry around, or even bother setting up, a keyboard and monitor to get access to my Pi

The Solution

As many of you lovely readers may know, I’m already a fan of small travel routers made by GL.iNet, like the fine GL-MT300N-V2. For a scant $20 dollars (shipped!) you get DHCP server you can not only bring with you, but will happily run off a battery. Better yet, because it has a USB port, you can actually power your Pi off the wee router. Daisy chain USB power for the win! The final icing on the cake is that you can make the two Ethernet ports on be both LAN (instead of LAN & WAN). While these are great devices, their WiFi stack is a bit flaky, so being able to hardwire your network devices is a great, if not slightly cumbersome, work around.

The net result is that your around town bag can have:

  • A USB Battery
  • Two very short Ethernet cables
  • A USB Ethernet dongle (w/ USBC adapter tah boot)
  • A travel router (GL-MT300N-V2 in this case)
  • Two micro USB cables
  • Pi (In the picture below I have an Orange Pi Zero with a temp sensor and a screen threaded through one side of a case)

When you put it all together, you get a nice tidy mess and it works just great, solving all of the above problems. Your laptop can be on two networks so it can have local access to the Pi and to the internet too. Further, if the WiFi your on isn’t too hostile with their captive portals and such, you can actually have the GL.iNet router act as a WiFi repeater and backhaul that bandwidth to your Pi. Run your apt update away!

This set up is not only small and lightweight, but lets me work un-tethered on my Pi setup and Python code. Now if this frickin pandemic would just be solved, I’d actually be able to take this out of the house instead of just co-working with my partner in our office in our house!

Happy Pi Hacking!

Replacing two iPods with a Bash script

3 minutes, 19 seconds

13 years ago we got an iPod to actually listen to music on the go. It was awesome! Some time later we had our first kid and some time after that smart phones became prevalent, so our iPod fell out of use. But it was about 9 years ago that we started to use the old iPod as an easy way to play the same a bedtime playlist for our kids (oh yeah, we had a 2nd kid at some point too ;). Soon, the kids split into their own bedrooms so we picked up a used iPod on eBay and loaded up the same bedtime playlist onto it. These two iPods dutifully played the same songs day in and day out every night for years. They’re even more utilitarian than designed, but worked well at their finite task (Photo by Nicnicoleleeolee):

However, over time things started to not work. First one of the fancy docks we used as a speaker stopped charging which ever iPod was in it. This meant every week or so we’d have to swap it over to the good dock to charge up. But then one started to lock up and had to be rebooted. We feared we’d have to replace them soon.

It was around this time that I starting using the Cast All The Things software (aka catt) in my quest to both (finally) learn Python and to easily control the volume on a chromecast. Checkout my cattmate and cattrotar projects! catt is a command line script and python library that allows you to easily control and play videos/music on Chromecasts. It was also around the time that Chomecast Audio’s were stopped being made so I’d stocked up them. We have about 4 or 5 plugged in here and there about the house, including one in each kids room. They work really well!

By now you can likely see how this post is going to resolve itself, but lets find out, shall we?

Yes, that’s right, I wrote a full featured web site that you could pull up and easily play music in which ever room needed to hear the play list. It was simple, yet fancy ;) On the front end there was a series of 2 buttons, one for each room. When you pressed a button, it sent an AJAX call to a to the single endpoint on the back end. The back end then made an exec call to a bash script. This in turn used catt to play a MP3 on the specified Chromecast.

This worked great for a day or so. But then a bug reared it’s ugley had. Let me tell you, the cost of a software bug in your web app which involves waking your child up at 10.30pm is EXTREMELY high. Like, unacceptably high. Sleeping children are gold. Parents get grown up time, the kids get much needed rest and we’re all better for it the next day. Don’t fuck with a kid’s sleep.

After some unfruitful debugging, I got lazy and realized I’d already installed the wonderful termux on my phone, along with a $2 add on to have a bash script launcher widget on my phone’s desktop. So, after a dozen or so minutes of coding and a little ssh-keygen -t ed25519 for good measure, I had this on my phone:

Here’s what happens when you press one of those four links:

  1. Call a local script on the phone with the same name shown above
  2. Each script has the same contents but just calls the remote server with a different argument: ssh napserver controlmusic.sh CHILD PLAY_STOP. So for the first one above, that’d be ssh napserver controlmusic.sh e play
  3. The remote server, (hardened of course to only allowing one command to be run for that SSH key,) inside controlmusic.sh runs a catt command: /usr/bin/catt -d DEVICE COMMAND OPTIONAL_COMMAND. Again for the first button that’d look like: /usr/bin/catt -d "E's Chromecast" cast songs.mp3

So, while not nearly has fancy as the web app I initially wrote, it works every time, has saved me the time of debugging the web app (aka let me be lazy ;) and most importantly, does not wake the kids up after they’ve gone to sleep! Icing on the cake is that continued my lazy streak and bought the app for my partner’s phone so they could activate the playlist while I’m out of town (instead of me VPNing in and activating it remotely on request ;).

Happy Hacker Halloween!

2 minutes, 12 seconds

Last year I wanted to be a “Hacker” and code up a solution to show near by access points and nearby phones. I failed. However, I did a good job of brushing up on what I needed to do over the past year and so this year I was a hacker for reals. Here I am in the final get up:

hacker.jones.jpg

Let’s break it down! Here’s the hardware list (affiliate links to Amazon):

My final build out looked like this:

IMG_20191031_160240.jpg

A quick write up of the software is:

  1. install latest Rasbpian on your MicrSD card
  2. Install latest YANPIWS in /var/www/html/YANPIWS
  3. Install howmanypeoplearearound as the pi user. Ensure it’s path is /home/pi/.local/bin/howmanypeoplearearound
  4. Ensure you have all the libs for YANPIWS python scripts installed so you can talk to the BME280
  5. Hook up the BME280 to the right 4 pins on the Pi using the jumper cables
  6. Hook up the monitor to the Pi’s HDMI and the External WiFi adapter a USB port
  7. Have the Pi boot into kiosk mode with a browser that points to http://127.0.0.1 by following this awesome guide on pimylife.com. Note that you’ll only use the one URL and have no while loop in the kiosk bash script.
  8. Install Apache and PHP with sudo apt install apache2 php
  9. In /var/www/html/ put all of the files I just published on this gist. Basically it’s a small web app to show the data we’re collecting as well as some bash scripts that get run in cron.
  10. Install a bunch of cron jobs that gather the data as the pi user. This will use wlan0 (built in) to look for nearby access points using the venerable iw command. It will use wlan1 (USB adapter) to look for phones and such in monitor mode using howmanypeoplearearound. Finally, it will get the temp and humidity using the python script from YANPIWS. You may need to make /var/www/html writable by pi user to make this work.

It’s not my finest code, but if everything worked correctly, the Pi will boot up every time and show something like this:

IMG_20191031_190702.jpg

As you can see it got cold tonight on our walk – by the time we got home at 8pm it was 45. Happy Hacker Halloween!

Installing VirtualBox on MacOS via VNC – just use a real mouse

1 minute, 53 seconds

At work the other day I was testing our Ansible instructions on how to get a development environment set up. Given that this was supposed to be platform agnostic and that I exclusively develop on Ubuntu and LXD, I found an old Mac Mini on Craigslist to run VirtualBox on. As it came with only 2GB of RAM, I was happy to discover you can actually upgrade to 16GB per the Everymac site:

Officially, this model supports 8 GB of RAM, but … it actually is capable of supporting 16 GB of RAM using two 8 GB modules.

– EM

Add an old 500GB SSD I had kicking around, and now the machine is pretty responsive for being 7 years old and costing me $190 all in!

Given I didn’t want to dedicate a keyboard, monitor and mouse to this, the very first thing I did was to enable Remote Desktop, specifically VNC, and stuffed it with my other mini servers in the “server room”:

I then went about zipping through installing Ansible, VirtualBox and Vagrant .

When I went to boot my first VM, I got weird error on the command line (I didn’t save it, sorry). After some trouble shooting, I decided to just re-install, and more slowly this time, and the GUI showed me this:

Baffled, I tried again and again, failing the same way every time. Researching the problem, I found a post on Medium suggesting I hadn’t allowed the correct permissions in the Security & Privacy settings. None of these suggestions helped. Finally, I read the comments at the bottom of the page, including the one from Elias Politakis which said,

Please note that if you are using a VNC connection (or similar remote access software) you won’t be able to click the [Allow] button because OSX requires that Process ID pressing the Allow button is zero (0) which is the system PID. You would need to physically visit the Mac and click the Allow button with the physical mouse.

– EP

Oh, OK! But…now I had to extract the Mini from the server room :( Then I remembered I had a spare wireless mouse! What I did was plug the mouse in to the mini, then back to my desktop worsktation where I connected to the Mini over VNC and the mouse was able to still work all the way back to the closet. Then I could click the button with a real mouse, but without using a real monitor or real keyboard, or even moving the mini:

So – if you happen to be like Elias or me, just use a real mouse! Happy computing.

Easy Pi-Hole and Stubby on Orange Pi Zero & Raspberry Pi 3

4 minutes, 8 seconds

Skip to the install guide if you just want to know how to set up your Pi easily ;) Otherwise, read on for a little background.

Introduction


I’ve been deep in DNS land of late. At work I’m working on DNS Stats and helping QA/release/document a packet capture tool for DNS stats. I even, just today, automated a complete Pi-Hole install to have a reliable dev environment for DNS stats. At the shop, I’ve set up the same encrypted DNS + Pi-Hole + LXD + Quad9 as I have at home. It’s all DNS all the time here is what I’m trying to say ;)

I’ve yet to find the magic sauce to compile Stubby on the Orange Pi Zero board though. It’s so cheap ($20 shipped), has a built in Ethernet, and is just so dang cute! So, I was looking around at stubby posts and Linux posts and Ubuntu posts and found this great write up on Ubuntu 18.04 and stubby and it said,

Stubby is in Ubuntu 18.04 repository

-linuxbabe.com

This was awesome! This means my previous trickery of having to compile stubby from source on Ubuntu wasn’t needed! However, the revelations about easy DNS set up and encryption were only just getting started.

The next one I found was that the 4.0 release of Pi-Hole from early August, had a new feature: custom ports can be used for upstream servers. Wham! This double awesome! Now, in the GUI of Pi-Hole, you could safely add a the IP of stubby and specify a random port to use! But we’re done yet, no sir, two more revelations to go.  Hold on.

The penultimate revelation was BOTH the Orange Pi Zero AND the Raspberry Pi 3 b had a release of Ubuntu 18.04 for them. This means that you not only don’t have to compile stubby for your x86 LXD environment, but you don’t have to do it for ARM SoC setups either! Yay!

The final revelation dates back to a long, LONG time ago, and I’m just late to the party.  I’m talking proto-internet long time ago.  The legend Jon Postel decided that not only would IPv4 have a reserved IP address of 127.0.0.1 for localhost, but in RFC 790 in 1981, he said it would actually be a /8, so you get just over 16 million localhost IPs just for your bad ass self. This means you don’t actually need the new port specifying feature of Pi-Hole – you can just set up Stubby on port 53 on 127.1.1.1 and Pi-Hole on port 53 on 127.0.0.1. Ugh – this makes it so much easier – if I only was more a network guy!

Now that my rambling background on my recent revelations is done, let’s get to the technical write up.  Though, honestly, this part will be pretty short and sweet.

Installation Guide

This guide assumes you’ve downloaded and installed Ubuntu 18.04 for either your Orange Pi Zero or Raspberry Pi 3 B. Note that both the official download page of both Orange Pi and Raspberry Pi Foundation, do not list 18.04 options. It also assumes you’re running everything as root. The instructions are identical for both boards:

  1. Ensure you’re up to date:
    apt-get update&&apt-get upgrade
  2. Install Stubby: apt-get install stubby
  3. Edit /etc/stubby/stubby.yml so that it’s listening on 127.1.1.1:
    listen_addresses:
     - 127.1.1.1
  4. Restart Stubby: systemctl restart stubby
  5. Install Pi-Hole. Use what ever upstream DNS server you want when prompted, we’re going to override it with Stubby:
    curl -sSL https://install.pi-hole.net | bash

    IMPORTANT
    – See Troubleshooting below if you get stuck on “Time until retry:” or “DNS resolution is not available” when installing Pi-Hole

Pi-Hole DNS settings
  1. Log into your new Pi-Hole at YOUR_PI_IP/admin and go to Settings -> DNS. Uncheck any DNS servers and enter a Custom 1 (IPv4) of 127.1.1.1:

Coming full circle, the Reddit thread I cited in my original write up, now has a comment that Ubuntu 18.04 has a Stubby package.

Quad9

If you want to use Quad9 (and I think you should ;), in step 3, while you’re in stubby.yml, comment out all the other servers in upstream_recursive_servers: and un-comment Quad9 so it looks like this::

upstream_recursive_servers:
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"
  - address_data: 2620:fe::fe
  tls_auth_name: "dns.quad9.net

Full disclosure, I work for PCH which sponsors Quad9.

Troubleshooting

A few things I found while researching this post that might help you:

  • The login on the Raspberry Pi is Ubuntu with password is Ubuntu. The login on the Orange Pi Zero is root and password is 1234. Check out my SSH Bootstrap trick as well.
  • The Orange Pi Zero didn’t get an IP via DHCP the first boot. A reboot solved that.
  • The Pi-Hole script gave me a headache when installing. Near the end of the install it said, “Starting DNS service” and then was waiting to retry. I found a post on the Pi-Hole boards that solved it perfectly. To work around this, edit /etc/init.d/pihole-FTL so that this line:

    su -s /bin/sh -c "/usr/bin/pihole-FTL" "$FTLUSER"

    is replaced by this line:

    /usr/bin/pihole-FTL


    After that, be sure to reload your init script with:

    systemctl daemon-reload

    Finally you should be able to complete your install just by restarting Pi-Hole:

    systemctl restart pihole-FTL
     

  • Even though I followed step 4, during one my tests stubby was still blocking port 53 on 127.0.0.1. If that happens, restart stubby:

    systemctl restart stubby
     

  • At any point you can test that stubby or pi-hole is working. These are good to intersperse with each install and configuration change:

    dig @127.1.1.1 plip.com +short # stubby
    dig @127.0.0.1 plip.com +short # pi-hole

Bootstrap SSH on Ubuntu Core with out Ubuntu SSO credentials

1 minute, 23 seconds

I was playing around with Snaps and I wanted to try out Ubuntu Core as well. I still had some of those  Orange Pi Zero boards laying around and when you go to the Core Download page – there’s an option for Orange Pi right there – sweet! I downloaded the .img file, wrote it to my microsd card with dd, slapped it in my Orange Pi Zero, found the new IP in my DHCP server and off I went to SSH in.

Then I saw this step on install docs:

you will be asked to enter your Ubuntu SSO credentials

– Core Install Docs

Whhhaaat? Oh, I see, Core’s whole shtick is that it’s secure by default. They say, “Secure by default – Automatic updates ensure that critical security issues are addressed in the field, even if a device is unattended.”.  Cool, I can get behind that. IoT needs some thought leaders in IoT security. However…I still just want to SSH in and poke around a bit – I don’t want to have to set up an account at Ubuntu. 

Then I thought, “What if I just create a .ssh directory in /root/ and put my public key in the authorized keys file?” Assuming you’re on an Ubuntu system, logged in as mrjones and just stuck in your microSD card with the core image on it, that’d look like this:

cd /media/mrjones/writable/system-data/root/
mkdir .ssh
chmod 700 .ssh/
vim .ssh/authorized_keys 
chmod 700 .ssh/authorized_keys

After unmounting the card, inserting it into and rebooting my Pi, I SSHed as root and it just worked – that’s awesome! Now you know how to do it as well!  In fact, this likely will work with the Raspbian, Armbian and Ubuntu images for all kinds of Pi boards as well.

Stay tuned for my next post where I’ll massively simplify my stubby and pi-hole how to!

Teaching Kids About Busy Signals with a PBX on LXD for $15

2 minutes, 40 seconds

Linksys RTP300 Circa 2005

The other day the kids and I were at our local, awesome Goodwill store. I guess they’re all awesome, eh? I was looking over the pile of small electronics while the kids picked out a shirt (“any shirt you want!!”), and stumbled across a device with Ethernet jacks (RJ45) and phone jacks (RJ11). It’s a router with two ATA ports – cool! It was only $5 bucks!! A quick internet search suggests that it may be locked to a provider like Vonage, but that there’s lots of folks unlocking it. Given this was Goodwill, there were was a plethora of POTs devices handy – two more phones at just $5/ea – no problem!

Now that I had the whole kit home, it was time to see what the ATA was up to. It’s a Linksys RTP300 – and the voice section was definitely locked down :( But that means it’s time to start hacking! I dug up the site I initially found before buying it – luckily all the downloads still work! The post is 8 years old, forever in ‘net time, so I was impressed.

I’m pretty pleased with myself because I fully understood everything and was able to improve the process because of this. Mainly:

Using inspector tool to make the ping input field longer
  • Being a web developer I already had a web server running. This is much easier to use instead of setting up a new TFTP server as they suggested.
  • Being a web developer (still) I was kinda in awe that I’d already forgotten how amazeballs Firebug was, and how I take for granted that modern browsers have such good developer tools built in.
  • Knowing all the linux commands used (wget, chmod, cd & dd) I was able to explore the device a bit
  • I figured out that the guide wanted you to download into /var/tmp which didn’t exist on my device, but /var worked
  • They have you download some *.img, but running it through strings and checking the size, it appeared to match the 3.1.24 version. Completing the install confirmed this. However, md5sum outputs don’t match.
That, sir, is an odd response to a ping ;)

After all this I had a generic, if not quite dated, ATA that was ready to talk to a VoIP provider. Time to install Asterisk! This is where LXD comes in. I already had my home server running Stubby and Pi Hole – time to add another. After spinning up an Ubuntu 16.04 box, hitting a snag, then spinning up an 18.04 box, a quick apt-get install asterisk and I was ready to go!

I created 4 extensions, one for each of us, by following some simple guides I’d found (edit /etc/asterisk/sip.conf, /etc/asterisk/extensions.conf and a reload). I plunked in the LXD Asterisk IP, extension and password and BAM! both lines registered easy peasy on the ATA.

With two hard phones set up (just plug ’em in to the ATA), I set up me and the wife using the built in client on our phones. Now we all had a phone and could call each other. See the gallery below for the visual story!

On a personal note, this was pleasing for a two reasons:

  1. I saved 3 small electronic devices from the landfill.  More and more I’m trying to be conscientious about buying less or buying used.
  2. My kids got to look up at me and say, “it’s making a weird sound!?” I explained to them that it was a “busy signal”.  See, cell phones, office phones and 99% of home phones don’t do this any more. They have either call waiting or voice mail, or both ; )

AppSec California 2017

4 minutes, 15 seconds

After attending both Defcon and HOPE, I thought I should open my mind to other, more traditional security conferences.  Since it was a short flight and of modest cost, I choose AppSec California, put on by OWASP.  It was great!

tl;dr

Good:

  • 11 of the 13 speakers/subjects I heard were great!
  • Santa Monica makes for a good venue: walkable, good coffee, good food and bike sharing program!
  • I fully grok CSP now
  • No big snafus by OWASP organizers: schedule, venue and food was well planned
  • Plenty of chance to meet and chat with folks
  • Two days was just long enough to pack in lots of good info, but not too long to be overwhelmed
  • Low cost registration

Just one here, but the Bad:

  • 2 of the 13 talks were bad.  One was a vendor pitch, the other was a possibly OK keynote, but speaker was a royal dick to the AV staff at the start of his talk

Santa Monica

This was my first time to Santa Monica (though maybe there was a trip when I was 18!?), and I liked it.  Biggest hits are it was highly walkable and had a bike share program. This meant I could walk to close by dinner and then the next morning take a ride along the beach to the conference:


As well, if you want to get your snooty 3rd wave coffee on, then you can bop over to Demitasse on 3rd street. Tasty! Another nice feature of the town is that they have a nice collection of trails along the beach.  The first night I was there I took a lovely 6 mile run on them well into the Pacific Palisades right from my hotel doorstep. Sunsets of the ocean are nice too (and I know I’m playing into OWASP’s desired PR For the location of the conference ;)

Conference highlights

Overall this was a great conference! I ended seeing 3 talks which heavily focused on Content Security Policy (CSP), which I’d only lightly heard about before.  When done right, and thoroughly, it removes the JavaScript attack vector including, but not limited to, click jacking and XSS.  Ilya Nesterov’s talk, “CSP: The Good, the Bad and the Ugly” really did a great job in describing how to implement it.  Specifically, he spoke about a lot of the pitfalls (no inline scripts vs inline scripts all having a nonce), browser adoption rate as compared to CSP Levels (eg full adoption of CSP 1) and interesting things about the CSP Level 3 draft.

I enjoyed Sun Hwan Kim and Julien Sobrier’s talk, “HSTS, TLS, HPKP, CSP: putting them all together to move to HTTPS” not only for the in the field experience of securing a large site, but for the audience questions as well.  While he didn’t have a talk at the conference, Scott Helmeott Helme had some great comments and questions.

Though her talk was a bit less organized than I’d hoped, I very much enjoyed hearing Yan’s talk, “Dissecting Browser Privacy“.  I’ve been following her blog for some years now so I it was nice to meet her in person.  Her talk wasn’t pitching Brave browser where she works, but Yan did reference it often in her talk.  I think it maybe the best browser for my laptop because it supports touch so well!

Not a highlight, but noteworthy, Gary McGraw did the opening keynote.  Before he could get started he choose to be demeaning in a very public way to the AV person.  It was 3-5 minutes of him being just shy of cursing out the staff about why the microphone wouldn’t work.  I later told the AV staff that she was awesome and I really appreciated being professional throughout the ordeal.  The other minor hiccup in the speakers was Jack Bicer’s talk, “Want to be secure? Eliminate passwords. If you don’t have a password, it can’t be stolen!”.  This ended up being 15 minutes of fear mongering about how your password can get hacked all while ignoring password managers. I left early, but heard later that, unsurprising, the “solution” to all these fears was to adopt Mr. Bicer’s product :(

Being a one man web dev shop, it was painfully obvious how important automation is. Static analysis of code, feature and regression checks, pentests and more can be run in an automated fashion even if you have to manually kick off the automated tests. This provides the equivalent of many man hours of manual tests all done at no time-cost. The conundrum is that it can take months to set this automation up and that’s time when you you’ll be releasing no new features and fixing no bugs.  Matt Tesauro’s talk, “AppSec Pipelines and Event-based Security: Moving beyond a traditional security test” was a good reminder about this.

Talks

These are the talks I attended with a few notes where applicable:

Weak Crypto in Star Trek Beyond (SPOILERS!!)

2 minutes, 20 seconds

Star-Trek-BeyondLet’s get this out of the way upfront: the most recent installation of the Star Trek reboot, “Beyond”, was exactly what I’d hoped it would be. It was an action packed, summer fun movie. It did not exceed, but definitely met my expectations.

The end however, was totally silly. It was the peak of the action and the sound effects and music (more on this in a second) were so loud I don’t think any one could hear my wife and I laughing. Like, laughing to the point of crying because what we were watching was so funny. But, for me at least, I kept on thinking, “wait – what?” There’s no way modern crypto would allow this scene! Let alone hyper futuristic crypto of 2263! Let me explain.

spock.bonesIn the end of the move (yes, like I said, spoilers) the Enterprise crew is rocking the 99 year old USS Franklin. They are fighting the boss of the movie, Krall (not to be confused with Khan), who has control of a massive swarm of space ships based on alien technology. The swam is all perfectly in sync, just as you’d expect your alien swarm army to be. This, by definition, means that they are communicating with each other in real time to coordinate complex movements in 3d space. And how did they figure out how to beat the boss? Well, simply by “corrupting their communication with radio waves”. Radio waves like Sabotage, by the Beastie Boys. That’s right, the Beasties are literally weaponized to literally blow up the enemy hordes. Here’s the Franklin “surfing” the enemy swarm with them blowing up in their wake (click through to see the the preview where the gif came from):

beasties.loop

So, aside from the fact that radio waves travel at the speed of of light and should be radiating out in all directions, not trailing behind them, how exactly was this supposed to be working? According to wikipedia, “they [Spock and Bones] learn that VHF transmissions can disrupt Krall’s communications and destroy his fleet.” But, like I said, this is the year 2263! Surely the alien technology powering this swarm has sufficient encryption to ensure that simple VHF radio waves won’t interfere with communication, right? Beyond things like TLS Handshakes, PKI (or even hash-chains if you wanna get tricky), basic header checksums, like in IPv4 would prevent this type of interference.

MD5But, maybe not? Maybe the aliens implementing the swarm networking were just lazy? For example, the MD5 hashing algorithm was released in 1991. By the late 90’s and early 2000’s it was the de facto way to store passwords in databases. However, as early as 2005 collisions had been proven to be a reality. In 2008 at the 25th Chaos Communication Congress, researchers categorically proved that no one should trust MD5. Later that same year CERT issued a CVE agreeing. Fast forward 4 years to 2012, and what do we find? 43 million hacked passwords in unsalted MD5 is what we find. Well, we found out today (Sep 1, 2016), but the coders responsible for securing tens of millions of accounts back in ’12 should have known better. So yeah, maybe the aliens were more focused on meeting deadlines than they were in defending against VHF interference?