Show 7: Stuxnet the Story of Digital Sabotage

Stuxnet Nuclear Explosion

Story: The Story of Stuxnet [01:40]

In June 2010, a infected computer was discovered with a unknown strain of malware would end up kicking off a year long investigation that redefined the term cyber warfare.   While many of the anti-virus and security communities opted for sidelining research on the newly discovered malware dubbed Stuxnet by Microsoft, there were a handful of small and enterprise groups that would relentlessly chase the answers to the malware’s unprecedented mysteries.  Mysteries that would include nuclear weapons, assassinations and nation-state endorsed military offensives before it was all said and done.
Natanz Annotated At the end of 2009, the International Atomic Energy Association (IAEA) would discover that the Iranian uranium enrichment facility at Natanz Iran was loosing an unprecedented amount of centrifuges with in a short number of months.  Centrifuges are a key component device in the the facilities ability to produce highly enriched uranium, now believed to be for the end goal of developing nuclear weapons.  Loosing an enormous amount of centrifuges would highly impact the country’s nuclear program and their ability to produce enriched uranium. After months of a steady increase in the facilities operational centrifuges and produced enriched uranium, was this sudden down turn a product of scientific malfunction or was it sabotage?

If it was sabotage, there was only one problem.  The facility at Natanz was disconnected from the outside world.

In military history, the sabotage of a strategic location would require ground forces at the target location.  This is the story about a new covert military operation never seen before.  A new cyber weapon, that once launched, could achieve the same physical sabotage and destruction without the intervention of a military force.

The Burning Question [56:20]

This episodes burning questions is about avoiding improper implementations of HTTP Strict Transport Security (HSTS).
I’ve talked extensively before about implementing HSTS in your web application.  But the problem that I see out in the wild when it comes to HSTS is implementation details that could make all the difference to the level of benefit it adds to your application.

Transparency can have a benefit where it applies, such as knowing what a non-profit organization does with your donation, or certain government processes can be.  But, transparency has no place when it comes implementing HSTS. However, it is quite common to find a web application announce its HSTS details over unsecured HTTP.

What does this mean and whats the big deal?  The whole benefit of HSTS is to reduce the surface area of a man-in-the-middle attack by possibly reducing the number of HTTP request to your web application.  It does this by allowing the browser to intercept insecure HTTP requests to your site and instead send the request over HTTPS.  But in order for the browser to do that, your site does have to notify the browser about its HSTS policy.

However, if you’re HSTS policy never makes it to the browser, then the typical redirect song and dance will commence with each insecure HTTP request being vulnerable to a man-in-the-middle attack for the user.   How would it not make it to the user?  Through a man-in-the-middle scenario.  Any attacker who sees the policy being issued can subsequently remove it.  Leaving your browser none-the-wiser.

Therefore, in this episode we talk about when to provide the browser with your  sites HSTS policy as well as what kind of redirect should be issued when it comes to HSTS.

Fabulous Failure [01:02:27]

It’s quite common place for hackers to ridicule a target for their poor security implementation after they have breached their target.  This is usually found in the form of a list of vulnerabilities discovered with the victims data online, or over social media. But in this fabulous failure the table has turned when security researchers are able to track a group of hacker’s because of the breadcrumbs left behind as a result of not following their own security advise.

About the author

Max McCarty

Max McCarty is a software developer with a passion for breathing life into big ideas. He is the founder and owner of LockMeDown.com and host of the popular Lock Me Down podcast.