Breaking DKIM | TechSNAP 81

Breaking DKIM | TechSNAP 81

How an aviation blogger unlocked the secrets of the TSA’s barcode, if you’re a Barnes and Noble shopper we’ve got a story you need to hear, and a serious bug in the Linux Kernel.

Plus a batch of your questions, and our answers.

All that and so much more, in this week’s TechSNAP.

Thanks to:

Use our codes TechSNAP10 to save 10% at checkout, or TechSNAP20 to save 20% on hosting!


Get your .COMs just $5.99 per year up to 3 domains! Additional .COMs just $7.99 per year!
CODE: 599tech

Expires 10/31/12

SPECIAL OFFER! Save 20% off your order!
Code: go20off5

Pick your code and save:
techsnap7: $7.49 .com
techsnap10: 10% off
techsnap11: $1.99 hosting for the first 3 months
techsnap20: 20% off 1, 2, 3 year hosting plans
techsnap40: $10 off $40
techsnap25: 25% off new Virtual DataCenter plans
techsnapx: 20% off .xxx domains


Direct Download:

HD Video | Mobile Video | MP3 Audio | Ogg Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feeds | Torrent Feed


Support the Show:


Show Notes:

Get TechSNAP on your Android:

Browser Affiliate Extension:

  • Jupiter Broadcasting Affiliate Extensions for Chrome and Firefox
  • Barnes and Noble POS Terminals compromised, debit card pin numbers stolen

    • Barnes and Noble discovered on Sept 14th that a number of the PIN Pads for its Point of Sales system had been compromised
    • Barnes and Noble did not go public with the information until this week at the request of investigators
    • Tampered PIN Pads were found in 63 stores all over the country, including California, Connecticut, Florida, Illinois, Massachusetts, New Jersey, New York, Pennsylvania, and Rhode Island
    • The retailer reported that only about 1% of their PIN pads had been tampered with, but when the compromise was discovered on Sept 14th, they disconnected all PIN pads at their 700 stores
    • It appears that a coordinated criminal enterprise infected PIN pads with malware that would record credit/debit card numbers and PIN numbers
    • B&N recommends that you change your debit card PIN number and watch your debit and credit accounts for unauthorized transactions
    • Online purchases were not affected
    • Official Announcement from Barnes and Noble

    Avaition Blogger finds that he can determine what security screening he will get from this boarding pass

    • Frequent Flyer John Butler wrote a blog post this week, after he was able to determine what level of security screening he was going to be subjected to at the airport by reading the unencrypted barcode on his boarding pass
    • This raises the possibility that terrorist or smuggling groups could buy multiple tickets, then check each and use the ones that subjects them to the less intense screening process
    • The barcodes also appear to lack any form of MAC (Message Authentication Code), to protect them from unauthorized modification
    • It is unclear if a modified barcode would work, or if it is checked against a central database
    • It is illegal under US law to tamper or alter a boarding pass
    • The vulnerability appears to be confirmed by reading the specifications for the system published by the IATA (International Air Transport Association)
    • Every airport I’ve been through (YYZ, YHM, YYC, CDG, WAW, AMS) has not had any way to avoid the screening process, it appears that only the TSA allows you to pass through security without the basic screening. I have been randomly selected for additional screening (chemical residue test) twice

    Serious bug in Linux kernel results in EXT4 data corruption

    • A bug was accidently introduced in Linux Kernel version 3.6.2, and then backported into 3.4 and 3.5
    • The bug has to do with the way the superblock and journal are updated, and can result in extensive data corruption, especially if a filesystem is unmounted shorted after it was mounted
    • A patch was posted, but was found to not fully solve the problem, so a second patch was posted later
    • Kernel 3.4.x is reaching end of life, and may not get an official patch

    Dreamhost decides to change its SSH keys without notifying customers

    • DreamHost, a large shared web hosting provider, generated new SSH keys for all of its servers on Wednesday
    • DreamHost claims it is the “result of a security maintenance which we are performing to prevent exploitation of weak or outdated keys”
    • It seems like an excessive step, unless one or more of the SSH host private keys were compromised, in which case that is huge security news
    • If the keys were compromised, this means that someone could impersonate the DH server and log the login attempts, capturing valid username and password combinations
    • DreamHost made a number of mistakes:
    • Not giving users a heads up about the change before it happened, no email was sent, just a blog post that users were directed two when they contacted support about the error message
    • The blog post encourages users to just delete the old SSH key from their known_hosts and accept the new one, without verifying its authenticity
    • DreamHost did not publish a list of the fingerprints of the new keys, so that customers could verify the authenticity of the new keys they are presented with when they connect
    • The purpose of SSH fingerprints is to verify the identity of the remote host, they work in much the same way as SSL certificates except that there is no central certificate authority, it is up to the user to verify the identity of the key the first time. The main goal is to notify the user if the key suddenly changes, suggesting that you are not infact connecting to the intended server, but to some other server that may be trying to get your credentials or perform a man-in-the-middle attack on you
    • An attacker that is able to perform a man-in-the-middle attack during a time when a user is willing to just ignore the security warning (or even, take the additional steps OpenSSH requires before allowing you to accept a new key), could be very successful

    Mathematician finds that Google and others were using weak keys for DKIM

    • Mathematician Zachary Harris got an email from a Google headhunter for a job as a Site Reliability Engineer
    • Seeing as he is not an expert in that field, he assumed that the email was a phishing scam
    • He examined the headers, and determined that it was signed with the proper DKIM keys, appearing to actually be from Google
    • DKIM (DomainKeys Identified Mail), is a process where all outbound email is cryptographically signed with a private key, that can then be verified against a public key published in DNS, such that only emails that are actually from the domain can be signed with the key, it is a common anti-spam and anti-phishing mechanism
    • He noticed that Google was only using 512bit keys for DKIM,
    • Harris explored other sites and found the same problem with the keys used by Amazon, Apple, Dell, eBay, HP, HSBC, LinkedIn,, PayPal, SBCGlobal, Twitter, US Bank and Yahoo
    • He found keys in 384, 512 and 768 bits, despite the fact that the DKIM standard calls for a minimum of 1024 bit keys
    • A 384-bit key can factor on a laptop in 24 hours, while a 512-bit keys can be factored in about 72 hours using Amazon EC2 for around $75
    • In 1998 it was an academic breakthrough of great concerted effort to crack a 512 bit key. Today anyone can do it by myself in 72 hours on AWS


    While having lunch at EuroBSDCon, a FreeBSD developer recognized me from the Linux Action Show. He just so happened to be one of the main USB developers, and proceeded to correct (yell at) me. He recently expended a great deal of effort to improve support for webcams and other USB devices under FreeBSD 9.1 (and therefore PC-BSD as well). As further evidence of this, once we were done talking, someone walked up and handed him a USB ethernet adapter that was not supported, a hardware donation to drive development.


Question? Comments? Contact us here!