File Validation Case Study: Linux Mint

A news story broke this week about a hack against the download site of Linux Mint (the official blog post is available here).  Mint is a very popular, entry-level Linux operating system.  The attacker hacked Mint’s site and redirected the download link to a modified version of the .iso file.  The modified version had/has a backdoor installed via the Tsunami malware suite.  This hack affected Linux Mint version 17.3/Cinnamon, but the backdoored version appears to have only been available for a short time.  This is obviously bad news for anyone who downloaded and installed an affected version of this OS (17.3/Cinnamon), but there are some big-picture takeaways to be gleaned from this story.  This is not just a story about Mint; it is also a story about file validation and the lack thereof.

  1. People don’t verify file integrity.  Just a couple of weeks ago I posted about the importance of verifying file integrity, and I have written about file validation in my books. The attacks that would make one vulnerable to a tainted file may seem far-fetched, but this is a prolific, real-world example. Adding insult to injury, downloaded versions could have been clearly identified using a checksum or PGP signature.  It is doubtful that many downloaders took the time to perform this step.
  2. It is *almost* understandable that they don’t.  High-profile instances of attacks like these are incredibly rare.  It is almost forgivable that people don’t validate file downloads before executing them.  On the other hand the potential consequences of working on a compromised OS are grave.  It is also worth pointing out that we have no idea how prolific NON-publicized instances of attacks like these are.  Targeted, undiscovered, and hence un-publicized attacks of this nature are the ones that keep me up at night.
  3. The Mint team responded.  Kind of.  Sadly, the Linux Mint Blog responded officially to this incident by posting MD5 checksums (shown in the photo below).  I have written about this before and hate to beat a dead horse but MD5 is insecure and should not be trusted for file validation.  I’m glad they did something, but in the wake of an actual attack one would assume they would go to great lengths to verify file integrity in the future.  MD5 is NOT “great lengths”, but rather a mild, half-hearted response.  This is the most disappointing thing about this attack in my opinion.

LM MD5 ScreenshotMy checksums will be updated this week to include SHA-256 and SHA-512 checksums for the affected version of Linux Mint.

The Apple vs. FBI Debate: My Thoughts

This week has been awash in coverage of a federal court ordering Apple to unlock an iPhone 5c used in the San Bernardino shooting.  This story began for me when I awoke Tuesday at 5 a.m. EST to half a dozen text messages linking me to Tim Cook’s “A Message to Our Customers.” I have had almost a week to digest the letter, follow the story, and reach some conclusions.  My thoughts and observations on the “Apple vs. FBI” debate are listed below.

  1. The FBI has chosen to use this issue to paint encryption in an unfavorable light.  This single issue has advanced the government’s position that encryption is a tool for terrorists and criminals.  James Comey (the Director of the FBI) has long been an outspoken advocate for encryption “backdoors” and “front doors” but until now has had few concrete examples to sell the public on such mechanisms.  This is the chance they have been waiting for.
  2.  There is probably very little to find on the phone in the first place.  I talked about why I believe this a couple weeks ago on a podcast interview.  I talked about why I believe this which basically boils down to: there isn’t much to find on the phone that can’t be gotten elsewhere.  Jonathon Zdziarski posted an even more thoughtful list of reasons this device probably doesn’t contain anything of real intelligence value.
  3. This is an opportunity for the FBI to put Apple in the unenviable position of looking unreasonable and uncooperative.  It’s just one phone, and they were terrorists, after all.  The problem is, as Apple points out, is that it creates a dangerous precedent.  We have consistently seen mission creep with other laws and technologies that were designed for use in very isolated instances but have been used to pursue an increasing number of lesser crimes.
  4. The FBI is essentially conscripting Apple software engineers to write code for the government’s use.  This should be alarming to any business owner.  If the federal government can compel a company like Apple to write code (or do any work, really) without pay and against its objections, it can do so to anyone.  Apple, it should be pointed out, was only recently overtaken by Google as the world’s most valuable brand.
  5. Apple has its own set of motivations for defying the judge’s order to open the device.  This has been pointed out vociferously.  My own opinion is that regardless of why Apple is taking a pro-privacy stance, they are.  The market wants privacy, and Apple fills the void.  Apple is not a non-profit, not a humanitarian or philanthropic organization, and it is not the EFF.  Very few for-profit companies are filling this void, so my money will go to the one who is.
  6. An interesting article arose out of this controversy that backs up my call for longer, stronger passcodes on your iOS devices.
  7. Encryption works.

This has certainly been an interesting week, and there are certainly more to come.

Thirty-Day Security Challenge Details

With just two weeks remaining before the start of the Thirty-Day Security Challenge, I am going to address a few questions I have been asked in the past week.  If you have additional questions or comments feel free to post them in the comments or contact me directly.

What will the Challenge cover?  I have been somewhat (and intentionally) vague on this, but several of you have emailed in asking what the Challenge will tackle.  I’m still going to be a little vague, but this should give you an idea:

  • Week 1 will focus on local security and some basic best practices for your computer.
  • Week 2 will begin dealing with online account, web browser security, and protecting your internet traffic.
  • Week 3 will continue with online account security and deal with some intermediate topics like encryption and system cleaning.
  • Week 4 and on will deal with some mobile device security and encryption, and some personal privacy issues.

Though each week has a sort of theme, the challenge is cumulative, and being engaged from the beginning is important.  If you can’t, don’t worry, and if something is not applicable to you feel free to skip it.

How can I follow the Challenge?  A few of you have asked for alternate ways to follow this month’s challenge.  Here are three:

  • Blog:  The easiest way is to come to blog each day from March 1st through March 30th.
  • Mailing List: Several of you have asked for a mailing list.  I initially wasn’t comfortable with this because I am hestitant to become a repository of email addresses that I risk losing, but you guys have talked me into it.  I won’ t email you for anything else, and this mailing list will be turned off when the Challenge is over.  The mailing list is coordinated through MailChip whose complete privacy policy states,  “Your subscriber lists are stored on a secure MailChimp server. We don’t, under any circumstances, sell your lists, contact people on your lists, market to people on your lists, steal your lists, or share your lists with any other party, unless it’s required by law.”  Thanks to those who reached out and requested this – you know who you are! To get on the mailing list contact me through the contact form.  Supply the email address at which you would like to receive daily updates.  Put “Thirty Day List” in the subject line and you will be added.
  • RSS Feed:  If you have an RSS reader you can follow the blog and the Security Challenge at

What happens when the Challenge is Over?  Most importantly, you will be much more secure than when you started!  On my end, when the Thirty-Day Security Challenge is over I would love to hear your feedback.  Feel free to let me know what I did well and what could have been better.  Tell me your successes and failures.  Was there something you didn’t like?  Was there something I didn’t include but should have?  Within two weeks of the end of the Challenge I will post an after-action review based on your feedback.  I am very interested to hear how you all did, so please, don’t hesitate to chime in.

See you all in two weeks!

Book Review: Future Crimes, Marc Goodman

In an age of almost weekly hacks on various multinational corporations, banks, Hollywood movie studios, and government agencies—each more brazen or damaging than the last—it’s no surprise that a spate of books on the subject has hit the market in recent months. After all, those hacks, along with the countless others that go unrecorded every day around the world, affect us all in one way or another.

Future Crimes: Everything is Connected, Everyone is Vulnerable, and What We Can Do About It, by Marc Goodman is one of those books that addresses the growing chasm between our Internet-woven lives and the security necessary to protect us from the people who would exploit our reliance on it.

And it’s an eye-opener. Goodman, a former police officer, current cyber security expert and founder of the Future Crimes Institute, makes his living studying cyber threats and the people and organizations who perpetuate them. He’s one of the leading experts in the field, having worked with the FBI and Interpol, among others. Given his credentials, Future Crimes is exactly what you might expect it to be: a well-researched tome of extremely detailed case studies covering everything from hacks and cyber attacks committed against private individuals and organizations to the methods used to gain access to some of the most protected security systems in the world.

As it turns out, according to Goodman, hacking is no longer solely relegated to the realm of lone teenagers working out of their parents’ basements. Instead, hacking has become a multi-billion dollar industry, with operations as sophisticated and well-funded as some of their targets. Singletons, terrorists, organized crime syndicates, state sponsored hackers, and “hacktivists” (groups of hackers who do what they do for what they perceive to be good causes) all have staked a claim in the digital gold mine that is the Internet. They work full-time, attempting—and usually succeeding—to access and steal data that can be used to turn a profit or, in some cases, wreak unimaginable havoc.Future Crimes

In one of his more eye-opening chapters, Goodman discusses how terrorist groups have upped their game when it comes to harnessing technology to achieve their goals. Describing in minute detail how the terrorists in the 2008 Mumbai attacks used Google Earth, BlackBerrys, and real-time social media updates to plan and conduct their attacks (the same technology we use to plan a date), Goodman lays bare the terrorists’ tactics, techniques and procedures. The actual operatives on the ground, he writes, had constant, direct communications with an operations center in Pakistan staffed by commanders who were watching events unfold on major news networks, allowing them to monitor their operatives’ progress and the Indian government’s response.

Goodman also discusses the darker side of the internet, or the Dark Net, a digital underworld built specifically for illicit use that most of us don’t know even exists. He tells the story of Silk Road, the “eBay of drugs and vice,” where, if you’re savvy enough to gain access and speak the language, you can hire assassins, buy or sell child pornography freely and without fear of law enforcement interference, and even trade in human organs.

Setting aside the more nefarious aspects of the cyber world to discuss the legitimate, day-to-day aspects of the Internet doesn’t do the reader’s nerves any good. Future Crimes also details the easy and legitimate access we all either freely give away or inadvertently leak to data brokers every time we use our computers or smart phones.  The staggering net worth of this raw data—ages, genders, browsing habits, sexual preferences, medical conditions, personal networks and the like—collected about tens of millions of people around the world, every day, climbs into tens of billions of dollars each year. This information is not only attractive to criminals, but to legitimate companies “across all industries, whether retail, transportation, or pharmaceuticals” as well. The World Economic Forum regards our personal data as “the new oil” when it comes to overall value.

Despite being well-written, Future Crimes is a veritable train wreck of a book, brutal in its detail, with case studies piling on top of each other like so many derailed freight cars. The never-ending string of crimes related in the book becomes so mind-numbingly messy that it eventually exhausts the reader. This, unfortunately, begins around the halfway point and dilutes the overall effectiveness of the message Goodman is trying to impart. He knows the ultimate effect his book will have on the reader, though, stating in the prologue that “if you proceed in reading the pages that follow, you will never look at your car, smart phone, or vacuum cleaner the same way again.”

While heavy on the “crimes” portion of the world in which we now live, Future Crimes unfortunately offers very little in the way of solutions for the current state of affairs. The few fixes under our control are consigned to a short appendix at the end of the book that Goodman promises, if followed, can help the reader avoid 85 percent of current threats. Beyond that, though, it’s apparent that our inexorable link to all things digital now and forever makes being hacked just a matter of time.

If you’re interested in security, cyber security, or how the details of your life can be probed, stolen or affected by accessing the Internet, this book is a must-read. If you’d rather not know, exactly, how almost every pixel of your online existence is accessed, mined, and sold or stolen over and over again, take a pass.

FUTURE CRIMES: Everything Is Connected, Everyone Is Vulnerable and What We Can Do About It

By Marc Goodman

Anchor Books, 512 pp.

Thom Nezbeda is a journalist focusing on global conflict, crisis, and security issues. He writes about Middle Eastern and European affairs, military affairs, counterterrorism, national security the growing refugee crisis, and religious persecution. A former on-air radio personality and general assignment reporter after college, Thom put his journalism career on hold to join the military, where he spent nine and-a-half years as a Marine Corps Infantry Squad Leader and team leader in the Army, with combat tours to Iraq and Afghanistan. He is a graduate of the Defense Language Institute’s Arabic Basic Course, speaks French, and has extensive experience in Europe and the Middle East. Thom has written for The Georgia Guardian, Blue Force Tracker, The CP Journal, and The Soufan Group among others.  For more information or to follow Thom visit

How to Verify File Integrity using Checksums

Verifying file integrity is an important step when downloading and installing applications, especially when these applications are relied upon to perform a security function.  An application that is not downloaded completely or correctly may be weakened and fail to provide the necessary security.  Worse, users may be the victims of a watering hole attack where the download site is infected with malware, or some targeted individuals are redirected to look-alike sites.  In this instance the software in question would be modified to suit the attacker’s aims and its security could be bypassed entirely.  The easiest way to have some assurance that your downloaded applications are intact and legitimate is to verify their integrity using checksums and a checksum calculator.

There are also some other reasons that a checksum calculator may be handy.  For example, if you wish to transmit an attachment to another person through email, a cloud storage account, or other digital medium, a checksum could be used to verify the file had not been tampered with in transit.  Checksums can also be used to ensure that two files are are identical.  For example, if you backup a large folder to a USB flash drive you can compare the checksums of the two folders to ensure they are the same.

I constantly push this technique in my live classes and never cease to be amazed at the minuscule number of participants who every take any steps at all to verify the integrity of applications before executing them.  It appears to me that this skill is applied only by the smallest handful of users. The other major problem I run into when teaching (and when downloading software myself) this is the lack of a single, independent checksum repository from which to pull known-good checksums for comparative purposes.  This is perhaps at least part of the problem inherent in verifying file integrity.

As a result I have slowed down on the blog in the past couple of weeks to expand and update the checksums page. Though many do not, some security applications post checksums on their download pages.  Even so I still believe it is important to verify checksums from an alternate source; if you are redirected to a forged download page and download a corrupted file, it would be a simple matter for the forger to post his or her own checksum.  If you acquired both a corrupt file and its corresponding checksum from a forged site, the result would be worse than not verifying the file at all: you would receive a false positive, causing you to misplace trust in the application.

This is the primary motivating factor in my recent expansion of my checksums page.  There seems to be no comprehensive, third-party repository of checksums for security software.  The checksums posted there are SHA-256 and SHA-512. MD5 is insecure and there are credible reports of vulnerabilities in SHA-1 dating back several years.

Methodology: Before calculating checksums I download the application in question.  If a GPG signature is available I will use the signature to verify the integrity of the application, and then use a checksum utility to calculate a hash.  If a signature file is not available for a given application, I will compare it against a checksum found on a third-party site.

Windows:  The CHK Checksum Utility is the simplest and most user friendly checksum calculator I have found for Windows operating systems.  CHK runs in portable mode so there is no need to install it.  Simply download and open the executable.  Drag the file or files to be verified into the interface.  The checksums will automatically be calculated in SHA-1; to change this open the Options menu and select the desired algorithm.


Next, right click on the file to be verified and select Verify…CHK 2

In the pop-up that appears, paste a known-good checksum and click Verify.


A green checkmark will appear next to the application if the checksums match; if not a red “X” will appear beside the application name.

Checksums for the CHK Checksum Utility itself are available on my checksums page.

OS X:  Mac users have checksum verifying ability built-into their operating systems, though it requires a trip to the Terminal.  Open Launchpad and select Terminal.  Enter the command “shasum” into the terminal.  Next, drag the file itself into the terminal window and press Enter; by default this will calculate SHA-1 hashes.  If you wish to verify the file using a SHA-256 or SHA-512 checksum use one of the following commands (disregarding the file path which is represented in italics):

  • SHA-1:         shasum /user/macbook/desktop/filename.dmg
  • SHA-256:    shasum -a 256 /user/macbook/desktop/filename.dmg
  • SHA-512:    shasum -a 512 /user/macbook/desktop/filename.dmg

This method merely displays the calculated hash for the selected file.  To verify its authenticity requires a visual check.  This is tedious and can be mistake-prone but is not impossible.  I recommend copying both versions of the checksum (the output of the terminal calculation and the checksum collected from the internet) and pasting them into a word processing document, one on top of the other, in the same pitch and font.  This makes differences much more easily identified visually.

Mac shasum

There are also several GUI-driven checksum calculators available for OS X but I confess I have not yet tried one.  There are very few that have been either recommended by a reputable source or well-reviewed.

Linux:  Given Linux’s proclivity for eschewing graphic user interfaces (GUIs) over the terminal it is somewhat surprising that an excellent GUI-driven checksum calculator exists for Linux.  It is called GtkHash, and will not be covered here.

3DSC: The Thirty-Day Security Challenge

Over the past several months I have fielded quite a few complaints from friends, some from strangers, and many from family.  All these complaints were about how “hard” security is.  One close friend in particular says he wants to be more secure but is daunted by its complexity, and he can’t decide where to start.  To address these complaints and make security seem more approachable to the average individual, I have devised what I like to call the Thirty-Day Security Challenge.  This one-month security challenge will attempt to break security down one day at a time. Continue reading “3DSC: The Thirty-Day Security Challenge”