According to the README, this is not the Stuxnet source code. Rather it's authored by people mentioned in the license by reverse engineers from the binaries. The real source code would probably have lots of juicy interesting things revealing how it was developed.
Honestly, it would be irresponsible and surprising if Israel _didn't_ try to sabotage Iran's nuclear program, especially given some of the things that the Iranians were saying publicly at the time.
What negative stereotype? That Israel has excellent cyber capacity?
Sure, there wasn't any official attribution, but the US aren't the only player in town either.
EDIT: As an aside, an ex-director of the DGSE[1] (french CIA basically) complained that there tend to be a general misunderstanding between the communication modes of western countries and middle-east countries, the former prefers to proverbially "Speak softly and carry a big stick" while the latter prefer a good incendiary speech as a form of catharsis. As a result western audiences tend to take some speeches too literally, as if they were a plan of action while the discourse wasn't made with them in mind.
I remember first hearing about this while working at a US firewall company. The scale and precision of the attack kept this virus in the minds of everyone who appreciated what it proved capable of and the scale of social engineering employed to effect it. It kind of ushered in state-on-state cyber warfare, or at least, brought the reality of weaponized viruses to the public conscience.
Indeed. It's incredible how important software and networking has become for humanity. Alot of people still don't realise how risky having mobile devices that can sense (GPS/audio/video) on our person and the invisible combination of the zero-day is to our liberty and security.
Imagine if the same strategy were applied to biological warfare. Novel viruses tailored to be symptomatic and cause harm to just one specific world leader. If the technology exists, it could be the most formidable assassination tool available; a self-delivering, non-nuclear ace-in-the-hole for winning a war.
This concept is featured in The Dark Forest, the second book in the Three Body Problem trilogy. It was something where you could genetically tag someone and then if they woke up 50 years later from a chrono sleep, various systems were preprogrammed to have "accidents" around them, like self driving cars, etc.
I was about to comment “hey, spoiler alert”, but then I realised that you’re talking about a game released a quarter of a century ago. More time has passed since MGS came out than passed between the Ramones’ first gig and MGS’s release. Mad.
Unlikely this could ever be done. We share too much of the same firmware for something like to be possible. The average human genome has about 4-5 M single nucleotide polymorphisms (SNPs) - rate in the order of 1 SNP / 1000 bases. The rate is much lower in functionally important parts of the genome because those tend to be under evolutionary constraint / conservation.
It's probably not that imaginary. There was much hand ringing during COVID that Russia's testing protocol for meeting Putin would allow them to collect DNA from world leaders.
And conversely, the article also mentions Putin’s social distancing, which could be a rational defensive measure against biological warfare that he believes might exist, rumors of an undisclosed serious health issue notwithstanding.
If you want the story of Stuxnet, Countdown to Zero Day by Kim Zetter is a great book. I have it on Audible and I've probably listened to it three times now.
Nitpick but it was even harder, they wanted to keep the PLCs intact, report back normal operation, and change the control output specifically to destroy/damage uranium centrifuges
You'd be insane to develop something of the complexity of Stuxnet and not include a full end to end test in the QA process. It would be incredibly embarrassing for this to fail.
You don't really need the centrifuge, just the inverter.
I was working in industrial control and automation at the time, there were sweeping changes to what could and could not be done and by whom at every level.
Old drives of all manufacturers that sat unused were audited and had to be brought up-to-date before any sale or change of hands could occur, serials were noted etc etc.
Never felt like a manufacturer decision since it occurred in unison almost globally.
I guess to be more exact, Stuxnet didn't break anything, but the PLC payload it delivered was designed to damage centrifuges, and that would have been the module under test in that QA environment
Wasn't it actually about spoiling the whole stock of Iranian's Uranium by applying damaging amounts of centrifugal force to it? I'm probably wrong about that, just asking.
one was to spin it far faster than it should, then stop abruptly in an attempt to damage the centrifuge
one was to run it at the wrong RPM to spoil the product of the centrifuge
in either mode, it would replay 'good' data to make the centrifuge look functional to an administrator
the way I understood, a 'bonus goal' was to keep the Iranians unable to diagnose what was going wrong, both with their production process (producing bad stock) and the failures (promoting distrust in their engineers) - i can't find an article right now, but I remember reading they were churning through site engineers at the time - presumably firing them for the on-site failures of centrifuges or their inability to stop them
What always impressed me about Stuxnet wasn't the technical complexity, but the amount of spycraft that must have gone into identifying exactly what to program it to do, and what they could get away with.
You don’t need to be a genius nor invest very deeply to figure out the technical details of introducing vibration into a high-speed centrifuge using SCADA (industrial automation protocol) in a barely noticeable way. As you suggest, tradecraft is the primary skill, jumping the air gap required an asset inside.
I don't know about French nukes, but French-affiliated aerospace has a general rep as being leakier than most. Eh, "leakier" is a negative way of putting it . . how about "loose-lipped"? One tools selection from a French-based vendor - a cloud option for uncontrolled data - was turned down by uniformed dudes from the program office, based on this prejudice. But a similar cloud offering from "Ze Germans"? Oh, that was A-OK. Both products seemed built from compressed pellets of Turkish dander - of course they did, this is DoD shopping - but one of them did have that snappy Aryan zing.
I remember reading a very well written article on stuxnet, detailing the entire way it worked. It was written in a very story-like way that built slowly until it revealed what the actual payload and impact was. Does anyone have a link to this article?
The book about it is a great read although I think it could have used a lot more editing. Chapters approach the timeline from different angles and as a result it does feel like later chapters are going over the same material too many times. Anyhow, you can read part of it here: https://www.wired.com/2014/11/countdown-to-zero-day-stuxnet/
This Quora answer isn't article length but follows a similar story-like narrative and is well written imo. I remember reading this before I was working in tech and was amazed at how somebody(ies) came up with this
(Can't link direct URL as work filter doesn't allow Quora!)
It already is quite difficult to recover to this level, even for a relatively small malware codebase this probably took hundreds of man-hours to decompile into a meaningful state.
To protect it beyond a basic level - You can try but it's a cat-and-mouse game. A sufficiently skilled reverser will drop a debugger on your program, execute the code until it's past any decryption and then dump it from memory. So better schemes to obfuscate applications have been developed, like VMProtect, which makes a simple virtual machine with a custom instruction set and uses it to obfuscate your application. It's of course possible to break that as well, but it takes more time and requires more skill.
When writing in a higher language such as e.g. C, you can use code obfuscators to make your C code extremely hard to read.
If you want to make decompiling even impossible, you could modify the machine code generated by the C compiler. Even slight moderations are already enough.
If you want to make it (virtually) impossible to even disassemble the machine code, you could encrypt your binary itself except for a small bootstrap that will unencrypt the remainder of the binary when it runs.
> When writing in a higher language such as e.g. C, you can use code obfuscators to make your C code extremely hard to read.
Obfuscating C code shouldn't have any bearing on the decompilability of the output.
> If you want to make it (virtually) impossible to even disassemble the machine code, you could encrypt your binary itself except for a small bootstrap that will unencrypt the remainder of the binary when it runs.
Unencrypting the binary at startup is somewhat easy to hook into. It's harder to decrypt each individual function when that function is called and then re-encrypt it after the function ends. Bonus points if you re-encrypt after each `CALL`.
This is stuff which was available back in 2003 -- that's when I first used techniques.
> Obfuscating C code shouldn't have any bearing on the decompilability of the output.
This is the entire point of obfuscation and it absolutely does affect how easy the code is to reverse engineer. If it didn’t, there wouldn’t be a market for obfuscators.
In Iran the copyrights of foreign works are not well protected. This lead to a lot of copying: western software and books are/were available for little more than the price of the writable CD-ROM or paper+ink you got it on. Translations of works were slightly more expensive, that the translator did have to get paid.
Since Windows (etc.) was free, and the university thought curriculum based largely on US uni-books, Windows is/was everywhere, even in sensitive environments. Window has the worst track record privacy and security (remember NSA_KEY?), and Iran got bitten by this very hard.
I'm not a fan of Windows but Stuxnet didn't happen because of Windows. Iran decided to spin up a nuclear program and Israel and the US had concerns and wanted to stop it. They had the resources to develop something tailored for this unique situation, which included windows, Siemens PLCs (IIRC), Centrifuges etc. and developed the malware based on their target. Even if their target used a different stack, they'd find a way to achieve the same result.
It's all about price. Attacking Linux will be harder, thus more expensive.
You make it sound easy, if that was the case they'd launch one attack every few months or so. This stuff is expensive, and making it 100x harder means 100x less attacks before the budget runs out.
Beyond Windows security issues, if you (an organization mainly) are enough motivated you can attack other OSes as well. There is anwjole industry about exploiting bugs for more secure platforms.
I don't think there was a PR drive from the US/Israeli government, more like despite the US/Israeli government.
Remembering that the only reason we even know about stuxnet is because it was so aggressive that practically every PC on the planet caught it at one point. Also "stuxnet" is the name we gave it, it seems similar to another US Govt project that we know very little about codenamed "Olympic Games".
If it had not been so aggressive it would have gone completely unnoticed. Likely this is the case for a lot of state-sponsored malware. (especially coming out of FIVE-EYES).
It was said that it would not have been discovered had it not been modified half way through its life to spread faster. This led to it spreading beyond the Natanz facility that it targeted.
SetFastIoDispatch(): This function sets up the Fast I/O dispatch table for the driver. Fast I/O operations are a more efficient way to handle certain I/O operations in the Windows kernel.
HookingFileSystems(): Hooks into the file systems (NTFS, FastFAT, CDFS) to intercept file system operations. It modifies system behavior by redirecting calls to these file systems.
HookOne(): Hooks a single file system. It references a file system object by name and then attaches to it.
DriverNotificationRoutine(): A notification routine called when the driver's status changes, such as when a device is attached or detached.
AttachDevice(): Attaches the rootkit's device object to a target device in the system, allowing the rootkit to intercept calls to this device.
IsAllreadyAttached(): Checks if the rootkit is already attached to a target device.
CreateDevice(): Creates a device object for the rootkit, enabling it to interact with the system as a device driver.
IsMyDevice(): Checks if a given device object belongs to the rootkit.
SettingFlags(): Sets various flags for a device object to define its characteristics and behavior.
AttachToStack(): Attaches the rootkit's device object to the device stack of the target device.
OnFileSystemControl() and OnDirectoryControl(): These functions handle specific file system control and directory control operations, respectively. They are likely points where the rootkit intercepts and manipulates file system requests.
SetCompletionFileControl() and SetCompletionDirControl(): Set up completion routines for file and directory control operations, allowing the rootkit to execute additional code when these operations complete.
FileControlCompletionRoutine() and DirectoryCompletionRoutine(): Completion routines for file and directory control operations. They are invoked when file system and directory operations are completed, allowing the rootkit to intervene at this stage.
FreeMdl(), AllocateMdl(), CreateWorkRoutine(), WorkerRoutine(): These functions manage memory descriptors (MDLs) and work items, which are kernel objects used for deferred or asynchronous work.
GetOffsets(), FileCheck(), StrCheck(), TMPCheck(): These functions are involved in analyzing and potentially modifying file information during directory listings. They seem to be designed to hide or manipulate certain files or directories from being listed or accessed in a specific way.
CallDriver(), IRPDispatchRoutine(), SetZero(): Helper functions for handling IRP (I/O Request Packet) processing and manipulating device extension structures.
DriverEntry(): The entry point for the driver, setting up the rootkit when it is loaded into the system.
I just love that not only they copyrighted it, they even give excuses for it.
You can't copyright someone else's work, regardless of how long you took to reverse-engineer it from disassembled binaries. Obviously the "rights owners" are not going to take those two guys to court (pity though, that would've been hilarious), but since the only reason those two could license this is that this is a computer virus and no one will claim authority, their claims to ownership of the code have no merit.
I would love it if someone would publish or use it and not give them credit or "violate" the terms of the license in some manner, as I'd love to see those two try to claim their case.
They DO have copyright on the reverse engineering work. But that doesn't mean that they don't have full copyright over the code which looking at the LICENSE file alone it looks they are claiming. There should at least be a copyright line mentioning the original authors, even if just "Unknown Authors". They also obviously don't have permission to redistribute their derivative or to create it in the first place.
Its also ironic that they expect others to follow their license when they are fine with ignoring the copyright of the original hackers.
Ultimately though, copyright as we have it today is extremely silly and all they are asking for is attribution which IMO should be the default.
This. They don't give you the same as the original virus code, they give you different code (namely readable one), than apparently compiles to the virus assembly.
It's plausible this took effort, so I think it's only fair if they license it - it seems also ethically fair, since their licence is permissive.
I am sure big software companies wouldn't agree on this: decompile Excel or Photoshop and copyright the resulting code, and you shall get a nice lawsuit within days, if not hours. However, I guess there would have a bit of ToS breach, a pinch of DMCA and a lot of copyright infringement for reverse-engineering the software, maybe not that much for copyrighting the decompiled code.
They won’t agree and would file suit but legally this isn’t a highly tested area. The closest we get is Sony Computer Entertainment, Inc. v. Connectix Corp. as far as I’m aware and that can be seen as more of a win for the reverse engineering than Sony. The particulars are but different to be sure though.
Realistically it unlikely that anyone would attempt to decompile and fully reverse engineer excel and attempt to package it as a product that they own. It just doesn’t make sense practically. But throwing something in Jira isn’t the same thing as actually putting in the work to reverse engineer it and make it effectively a perfect replication. You don’t unbake the cake, you can’t. You just figure out a process to end up with the same cake.
As for TOS goes, that’s its own other legal issue that has a mixed history erring on the side of TOS not actually being enforceable.
The people who did this work I think are fine to ask people to respect their license. They don’t have to worry about the US/Israel knocking at the door to tell them they can’t claim ownership anyways.
>but both of us spent hundreds, if not thousands, of hours between ASM code trying to figure out what was behind those binaries and we are providing the product of our hard work (i.e. readable C code) to you for free
also
> It is not a simple job and it is not a short job, both our licenses are extremely permissive
>I'd like to ask you is that our job get recognized...show us your support by giving us credit for what we did
I do not know much about other jurisdictions, but in Germany a derived work has its individual copyright. For example, if one is translating a copyrighted work and publishes the translation without authorization, the translation is still prodected. The orginal copyright owner may sue the publisher of the translation, but the translator may sue anyone who publishes the translation without authorization.
Technical wonder aside, the argument for using nuclear power over fossil fuels really hits a faultline in situations like this. I wonder how the majority of folk rationalise their viewpoint surrounding this situation without being seen as massively hypocritical?
Nuclear power is vastly better in terms of emissions, so I'd argue that blowing up a plant or two is worth stopping global warming. But why target plants when a dirty bomb attack would be way easier and more effective?
Additionally, most countries don't have the resources to pull off something like Stuxnet, and the ones that do have much more to gain through corporate and government espionage.
The exploited software is conveniently developed and controlled by Iran’s adversaries. In another episode of the geopolitical sabotage show,
“In January 1982, President Ronald Reagan approved a CIA plan to sabotage the economy of the Soviet Union through covert transfers of technology that contained hidden malfunctions, including software that later triggered a huge explosion in a Siberian natural gas pipeline, according to a memoir by a Reagan White House official.”
True or not, the risk of software Trojan horses in the big energy game was recognized pretty early. The lesson here is, potentially dangerous technology ought to be matched by a comprehensive security protocol.
Yep, don't run your centrifuges on windows 98 is probably sound advice.
>In January 1982, President Ronald Reagan approved a CIA plan to sabotage the economy of the Soviet Union through covert transfers of technology that contained hidden malfunctions..
Is it? The nuclear fallout of a plant may linger for longer than any destruction done by the water of a large dam I would say or do you mean something else?
A modern nuclear powerplant is incapable of exploding, at worst it can meltdown and leak radiation in the vicinity. This can of course have very bad results, but check Fukushima - more people died from the evacuation, and from a fire caused by a fuel tank in another city due to the natural disasters that caused the meltdown, than did from radiation. A radiation leak is easy to detect (and all areas near nuclear power plants in semi-developed countries have automated collection of radiation), and isn't an immediate death sentence.
Meanwhile when a dam breaks, immediately everyone and everything in its path will be obliterated. Vastly more people have died from dam failures than even the worst of the worst of nuclear power plant incidents, Chernobyl, where staggering incompetence met horrific design flaws and bugs. Something like that is impossible to happen today.
A dam failure was caused by the nationalistic Chinese government fighting against Japanese forces in the 30s. It killed hundreds of thousands of people.
Do you have an example of nuclear energy plant being weaponized to the tune of hundreds of thousands of deaths?
This is fearmongering disguised as "just asking questions" and critical thinking. If your concerns were genuine, the answers about the effectiveness of nuclear would be easy to find.
Technically, Stuxnet was and is an absolute masterpiece.
Infiltration (dropper/1. Main.c):
Stuxnet infiltrated systems by exploiting vulnerabilities in Windows. It often spread through infected USB drives. When a user plugged the USB into a computer, Stuxnet would use these vulnerabilities to install itself. In the dropper/1. Main.c file, the DllMain function is where this initial infiltration mechanism is initiated. This function sets up the malware in the system after it's been triggered, typically by the insertion of the infected USB.
Staying Hidden (dropper/2. STUBHandler.c):
Once installed, Stuxnet used rootkit techniques to hide its files and processes from antivirus software and the system’s administrators.
In dropper/2. STUBHandler.c, the code manages the hiding of Stuxnet's activities, including concealing its files and processes, making the malware invisible to regular detection methods.
Verifying the target (dropper/3. OS.c):
Stuxnet was designed to act under specific conditions. It checked the infected system to determine if it matched its target - typically industrial control systems, particularly those using Siemens software and PLCs. In dropper/3. OS.c, functions like CheckSystemVersion ensure the system is compatible, and potentially, if it matches the target specifications, before proceeding further.
Delivering Payload through PLCs (dropper/6. MemorySections.c and beyond):
real damage was done by manipulating the PLCs controlling the centrifuges. Stuxnet altered the commands sent to these PLCs, causing the centrifuges to spin erratically and eventually fail. In dropper/6. MemorySections.c file likely includes functions for loading the malware's payload into memory, but the specific code targeting PLCs might be in other parts of the codebase that aren't as clearly identified.
Looks like most of this reply is ChatGPT generated...
"but the specific code targeting PLCs might be in other parts of the codebase that aren't as clearly identified" is something I've seen it generate when I asked details about a codebase as well, but it didn't have all the details.
The grammar is poor in places suggesting human editing, but I'll bet 10 bucks this is mostly ChatGPT too. OP testing a new GitHub code walkthrough tool? 1 day ago OP professed being quite familiar with ChatGPT's capabilities. OP, next time just give us a link to your tool's beta analysis of the repo.
Also, it is mostly wrong. The whole /dropper part is the initial loader, which has nothing to do with either hiding the presence or the actual PLC payload. Effectively it is an somewhat obfuscated stub for obfuscated self-extracting archive that is an dll and not executable.
Did it also spread in the West? How did they prevent it from affecting also friendly countries nuclear programs, is Iran the only country working at that stage of the technology?
> a very specific environment (iran nuclear plant)
Stuxnet was a full stack of plugins (which lends huge weight toward the early "big team" design and build theories of first observers).
There was a payload intended for very specific centrifuges ... and there was replication toward target logic ( Farsi language | locale seeking targets for copying ) IIRC.
The "work" of Stuxnet wasn't limited to screwing up the centrifuges, it also had seeking and limited comms.
To add onto that, the public infection was meant as a smoke screen to provide cover for the CIA setting up a fake business to enter the nuclear facility and installing it via USB. I’m not sure what kind of value the smoke screen created. Maybe created some confusion in Iranian intelligence services as to how stuxnet invaded? But ultimately knowledge of infection was counter productive as stuxnet was design to subtly change the control parameters so that the system would get damaged in a hard to detect way (spinning centrifuges slightly faster than they should have if I recall correctly)
