Back to Home

Countdown: book about Stuxnet, malware researchers and critical critical infrastructure / Kaspersky Lab Blog

stuxnet · duqu · flame · zero-day

Countdown: book about Stuxnet, malware researchers, and critical critical infrastructure

    Well, it's time to try yourself in the genre of book review. The book Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon by journalist Kim Zetter, best known for her articles in Wired magazine , was published quite a while ago, in November 2014, but has not been translated into Russian since then (available in English, for example, in Amazon electronically ). However, it’s not a matter of translation: the history of Stuxnet can be studied from open publications and research by security experts, but in this case you will receive an assortment of technical facts about malicious code, from which it is not so easy to put together the puzzle of the whole story.

    “Countdown” is a successful attempt to rise above the lines of code, to bring together everything that is known about the first and to this day the largest large-scale specialized attack on industrial systems. However, the book does not replace the facts with drama and is as far from fiction as possible. Its value is also in the fact that it shows the process of researching malicious code in a little more detail than usual: about half of the text is devoted to just this: from code detection and attack identification, to analysis of zero-day vulnerabilities and, finally, analysis of modules that modify industrial controllers.

    Six years have passed since the discovery of Stuxnet, seven from the moment the attack began, more than ten, presumably from the beginning of development. This is not the only cyber attack aimed at sabotage in industrial systems, but it still has no equal in complexity. This is partly good news, but the reason is not the increased security of industrial systems, but rather a change of orientation among customers. The “Countdown” is a book about an attack called the information security “blockbuster” in its time, but it’s also a book about the work of researchers - those who analyze malicious code and design protection against it, regardless of the source of the attack and intentions.

    Format


    Kim Zetter almost immediately goes from describing the events at the Iranian uranium enrichment plant, based on data from the International Atomic Energy Agency , to the detection of malware by experts from the Belarusian company VirusBlokAda, and here Kim Zetter had to determine the format of the story. It is impossible to tell the story of Stuxnet without resorting to technical terms, but if you go deep into technology, there is a chance to lose a reader who is not related to the information security industry (that is, almost all readers). At least at the beginning of the book, you still have to make a sacrifice to the imaginary deity of cyberpunk, and it looks something like this:

    Stuxnet used the zero-day vulnerability in Microsoft Windows, so it could spread to USB-carriers. And the zero-day vulnerability is ...



    To hide infected files on a USB flash drive, a rootkit was installed on the system, and a rootkit was ...



    The malicious code was signed with legitimate digital certificates at that time, so that the installation went as seamless as possible for the user. And digital certificates, it's ...



    Etc. Since the book is based on numerous interviews with researchers, Kim Zetter ultimately transfers a significant part of the facts to footnotes, they sometimes take up as much space as the chapter relating to them. In the future, in the book, almost all of the furious factology is there: you are given the choice to read the whole or skip clarifications. In the latter case, the perception of the plot does not suffer, and thanks to footnotes with a huge number of references to sources, the book is equally attractive to techies, and, ahem, humanities.

    Zero-dei


    For infection, Stuxnet used a zero-day vulnerability in Windows operating systems - at the time of detection (July 2010, a bulletin on Technet), all current versions from XP to 7, 32-bit and 64-bit were affected by it (Stuxnet attacked only 32-bit OS ) The vulnerability allowed malicious code to be launched using the prepared .LNK or .PIF file - if it was placed on a USB flash drive, the vulnerability was automatically activated. It is this type of vulnerability that allowed attacking an industrial system of critical importance, which is usually (but not necessarily) isolated from the network. Subsequently, our experts published an analysisthe first Stuxnet victims through whom successful attempts were made to reach the main target. The analysis became possible due to the storage of information about previously attacked systems inside the malicious code.



    The vulnerability was discovered only through the discovery and investigation of Stuxnet. The exploitation of zero-day vulnerabilities has become a feature of complex attacks. But over the past time, the situation has changed - not every successful targeted attack uses zero-days. Effective reconnaissance and investigation of a potential victim makes the use of such, very expensive and quickly disclosed tools optional. Actually, in the Stuxnet investigation, the fact of using the zero-day vulnerability was established first of all, much more time and effort was needed to analyze the "payload".

    In addition to the LNK vulnerability, Stuxnet exploited the MS08-067 vulnerability and another zerodeur, a hole in the Print Spool Service system ( MS10-061) It is noteworthy that the first vulnerability was also used by the Conficker worm , which caused a serious epidemic in 2008. The incomprehensible purpose of this malicious program in the light of Stuxnet even led to the assumption that it was a kind of test drive of technologies in real conditions, but in fact the connection between these two attacks looks dubious.

    Attribution


    Who stood on the Stuxnet attack is not known for certain. A significant part of Kim Zetter’s book is devoted to attribution in two senses: when communication with some people, events or other attacks is deduced from malicious code, and when the authors of the attack are confirmed by “the persons involved in the event”. The second is actually not very good: despite the mass of statements and arguments of various parties, it is impossible to reliably prove involvement in the development of Stuxnet in any country, and most likely the situation will not change for many years to come. Here, the narrative of the Countdown loses its rhythm somewhat, despite the painstaking work of collecting data from various sources by the author.

    But attribution in the process of code analysis is an interesting thing. One of the first examples is a line from the Stuxnet code:

    b:\myrtus\src\objfre_w2k_x86\i386\guava.pdb

    If for a while we distract from reverse engineering and study (for a change) the Old Testament, you can see in this line a reference to the Jewish holiday of Purim, which means it may be some kind of transparent allusion to the authorship of the code. What researchers do not have to do. In fact, the presence in the code of a line with the original path to one of the files on the developer's machine could be left intentionally in order to confuse the tracks. Another version that “myrtus” is not at all “myrtle” and a hint, but just an abbreviation for “my remote terminal units”.

    Followers


    But there is plenty of evidence of a connection between Stuxnet and the later Duqu and Flame attacks. In the case of Duqu , the same platform was clearly used as for Stuxnet. Flame is not related to the Stuxnet / Duqu codebase, but used the same vulnerabilities, including a hole in the Print Spool Service. Both attacks were analyzed as thoroughly as possible by the Laboratory’s specialists, and the book in the corresponding chapters uses information from interviews with our experts. It is curious that Duqu and Flame did not have destructive functions and were used mainly for cyber espionage. Given the focus of almost all complex attacks since the discovery of Stuxnet, information is valued above sabotage. However, this does not mean at all that industrial facilities are now safe.

    The imaginary complexity of critical infrastructure


    It was not easy to understand what exactly is the main goal of Stuxnet - the researchers simply did not have experience with SCADA systems. The book describes in detail how this part of the code was analyzed: Stuxnet, in the event of a system infection with certain software, could control the controllers of a strictly specified model, and thus change the speed of rotation of the centrifuges (presumably) at the facility in Iran so that they would fail from excessive load. In detail, the logic of Stuxnet's work in this direction was investigated by Symantec specialists (report in PDF) Interestingly, in order to detect attacks and protect computers, even in the absence (for several weeks) of a patch for Microsoft vulnerabilities, it was not necessary to know what exactly Stuxnet was doing. Such information is important only in the context of preparing to repel future attacks of this type.

    Kim Zetter devotes a separate chapter to the security of industrial IT systems in general. Examples are given, although incomparable in scale with Stuxnet, of sabotaging such objects using malicious code or by intercepting control systems. It has been known for a long time that the industrial infrastructure is already computerized enough to be vulnerable, but still not sufficiently protected. Alas, it cannot be said that Stuxnet has radically and irrevocably changed the situation for the better: very often the operators of critical facilities rely on the isolation of control systems and on the complexity of proprietary protocols. There are objective difficulties: a long cycle of equipment operation, specific requirements for hardware and software, industrial IT systems and traditional computer infrastructure belonging to different teams within the same company, and inevitable problems at the joints. However, Stuxnet clearly attracted the attention of researchers in the field of cybersecurity to the problem: since 2012, according toof our report , the number of detected and closed vulnerabilities in specialized software has grown significantly. On the other hand, the same report shows how a search through Shodan this year allows you to discover more than 180 thousand hosts with elements of SCADA systems that are directly accessible through the network.

    conclusions


    In my opinion, the Stuxnet story, described in the most versatile way in the book “Countdown to Zero Day”, allows us to make several important conclusions that are relevant for today's attacks (and to protect against them):

    - Authors of even the most advanced cyber attacks make mistakes. Most likely, as a result of the erroneous action at a certain stage, a massive infection of thousands of systems in different countries occurred, which allowed us to detect and analyze malicious code (however, there is a version that this was done intentionally). Moreover, for the first time, the Stuxnet sample was detected due to a complaint about a computer that constantly rebooted - something went wrong during the infection process. Here lies the danger of developing a dangerous cyber weapon: attack methods sooner or later become widely known, and tools can fall into the wrong hands.

    “You cannot rely on the complexity of systems and protocols.” The concept of security through obscurity was finally recognized as ineffective thanks to Stuxnet. Yes, it took a lot of effort and resources to develop this attack (according to some estimates, from 5 to 30 developers and at least 6 months of work), and yes, at first, the researchers faced difficulties in analyzing the specialized code for the process control system. Parallel experience analyzing attacks on financial systems since last year shows that even the most complex systems can be hacked, and control over them is used to cause damage.

    - The information security industry is most effective in combating complex attacks only when working together. The Stuxnet research, as well as Duqu and Flame, was attended by many security solution vendors and independent researchers. Analysis of someone else’s code is a complex and lengthy task, even for high-class specialists. Stuxnet was one of the first examples where collaboration and public sharing of results accelerated research and development of defense. Fortunately, this is not the last example, but there is still work to be done on the interaction of “security guards around the world”.

    - The history of complex and most destructive cyber attacks with the detection of Stuxnet did not end, but only began. Our advanced attack mapis a clear proof of this. Although the theft of information is a priority for attackers, it is impossible to forget about protecting industrial systems and critical infrastructure - if only because even a single successful operation at such facilities can cause enormous damage. Despite the complexity of industrial systems, resources are needed for their research in terms of safety and adequate methods of protection.

    “And finally, being a cyber threat researcher is cool.” The book by Kim Zetter is a rare case when, in addition to lines of code and conclusions, the work of security experts is illustrated in an accessible form using an example of a very real attack. It is very difficult to describe such an activity in a popular manner, but given the number of threats and their complexity, the maximum penetration of digital systems into our daily lives, we need to do this more and more often.

    Disclaimer: This column is based on real events, but still reflects only the private opinion of its author. It may coincide with the position of Kaspersky Lab, or it may not coincide. That's how lucky.

    Read Next