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 […]The postShow 7: Stuxnet the Story of Digital Sabotage appeared first onLock Me Down.
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.
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 implemen...
