The origin of Flame virus and the confusion surrounding its ownership
On May 28, Iran’s Community Emergency Response Team (CERT) MAHER released an advisory about Flame, a very sophisticated piece of malware along the lines of Stuxnet and Duqu viruses that targeted Supervisory Control And Data Acquisition (SCADA) process control systems in Natanz and Bushehr. However, unlike Stuxnet, which was targeted to sabotage specific systems, Flame focuses on collecting information from any machine that it infects, and then transmits the collected information back to Command and Control (C&C) servers that were spread out across many countries, making Flame primarily a tool of espionage.
In both cases, the attack on Iran has been classified as cyber-war by several observers, when in fact, Stuxnet and Flame seem to be tools of sabotage and espionage, respectively. Specifically, once Flame takes control of a Windows-based computer, it takes control of all devices and captures information from all of them, filtering the information obtained, encrypting a summary of gathered information to transmitted back to Flame’s C&C servers. Flame C&C servers periodically transmitted new commands tailored for different machines based on information gathered on the machine. Flame was also capable of stealing information from computers that were not networked by transmitting stolen data via infected USB pen drives- transmitting this stolen information to C&C servers when an infected pen drive is inserted into a Flame-infected, networked machine. All of these capabilities indicate that Flame’s primary intent is espionage, which does not translate to a cyber-war any more than real espionage amounts to war.
Before delving into the origins of Flame and the confusion surrounding authorship of the malware, it seems relevant to understand why Flame is considered on par with Stuxnet, even though it clearly does little other than collect information covertly, which is not out of the ordinary, for such tools are also created by cyber-criminals every day. Detailed reports by CrySys Labs and Kaspersky Labs, reports on the Securelist blog though they differ on the extent of similarity between Stuxnet and Flame. To avoid confusion, the key details of each report and their conclusions are independently outlined below.
CrySys Labs report indicates it received intimation on May 2012, without spelling the specific date when they started analysis on Flame. Nonetheless, CrySys lab found significant similarities by Flame but also significant differences. The points below are based on the contents of the CrySys lab report at the time of writing, which is relevant because CrySys lab continues to update their document of SkyWiper, another name for Flame. Once Flame takes control of a PC, it downloads other software modules, required to take control of all input and output devices attached to the PC. Specifically, Flame took control of the keyboard, screen, microphones, storage devices, network, Wi-Fi, USB ports, and system process, similar to Duqu/Stuxnet. Flame’s authors ensured that multiple copies of Flame on a PC did not interact badly with one another via programming constructs that allowed mutually exclusive access to the PC’s devices.
According to the CrySys Labs report, a PC running a version of Windows OS uses a LSA authentication module, which is software component that handles authentication of user log-on processes and also implementing various security processes. Flame’s first act on infecting a machine was to load itself as an LSA authentication package by fooling the OS into believing that the module was signed using a certificate that was backed by Microsoft root certificate. This simply means that the Flame malware was able to deceive Windows Operating System into accepting Flame modules as legitimate software updates from Microsoft, allowing Flame to load any number of modules using this mechanism.
Unlike CrySys Labs, which was notified about SkyWiper in May 2012, Kaspersky labs reports claim that it had access to flame back in March 2012 thanks to the UN’s Telecommunication arm- ITU, which reported the existence of this malware to Kaspersky labs. The elapsed time of two months between Kaspersky Labs receipt of Flame and MAHER’s report of developing an antidote on May 28Th makes MAHER’s claims of having detected Flame and creating an antidote on its own, less credible. Questions remain, such as, if MAHER was capable of analysing and neutralising Flame, what was the need for Iran to involve Kaspersky labs via the ITU in March 2012? However, various security firms and experts seem to be taking MAHER’s claims of detecting and creating an antidote for Flame at face value.
CrySys Labs tracked the dates of some components of Flame as far back as 2007, but Flame was designed to work on multiple versions of windows undetected. However, there also exist other components of Flame with timestamps as recent as Aug 31, 2011, well after Stuxnet was detected and reported in the public domain. This also allows the possibility that Flame developers had access to Stuxnet code while writing the malware, which further confuses the picture as to whether Flame and Stuxnet were created by the same entities, and whether Flame was actually deployed in 2007 as claimed, or whether it was deployed after Stuxnet was discovered. The former would point to the same entities developing both Flame and Stuxnet, and the latter leaves open the possibility of different nation states developing Stuxnet and Flame. Furthermore, CrySys Labs statements requesting for the release of the source code of Stuxnet to further study similarities between Flame and Stuxnet, indicates that they did not have access to all of Stuxnet source code, unlike Kaspersky labs which claims to have Stuxnet sources. In any case, authors of such malware are likely to deliberately falsify such dates to make it difficult to construct a timeline which can expose precise details on when the malware was created or deployed.
Kaspersky Labs reports also claimed to have found code common to Flame and Stuxnet to explain why Flame and Stuxnet did not interact badly with each other, even though they infected the same machines. This leads to questions as to how Kaspersky Labs acquired the sources to Stuxnet, which was never released in public, going by CrySys Labs requests for the same. One possibility is that Kaspersky labs acquired access to Stuxnet sources from infected systems in Iran, indicating access to Iranian governmental agencies. While there were many claims of Stuxnet sources available in public back in 2011 when it was the hot topic, attempts to download sources, from links posted on Twitter, were unsuccessful, as reported by many who tried to download Stuxnet sources.
Why is Flame considered the work of a team of developers working for a nation-state? The main reason is because the developers of Flame managed to compute a MD5 hash collision, which requires significant computing power not accessible to individuals or even most corporations. MD5 hashing works by creating a unique digital fingerprint for data in a given file, which provides the ability for comparing to different files of data by simply comparing the MD5 hash for the two files- identical MD5 hashes are taken to indicate that the contents of the two files are identical. However, it is well known in the world of Cryptography that MD5 is insecure and badly broken- this information has been publicly known since 2006 or earlier. The only barrier to breaking the MD5 hashes of encrypted data is lots of computing power, such as access to a supercomputer or a cluster of networked machines operating in tandem to parallelise such workloads. Rather belatedly, on June 3, Microsoft’s developer website revoked the certificates that had been compromised by Flame.
On June 1, the New York Times published excerpts from a recently published book quoting unnamed sources in the US government claiming that the US government was involved in cyber attacks on Iran, indicating that the Stuxnet virus was developed and deployed under the direction of President Obama. However, the US government has only publicly admitted to developing offensive cyber weapons, but not to the development of Stuxnet or Flame, which highlights the difficulty of pinning the blame on such cyber attacks to their original attackers. Soon after the existence of Flame was reported, on June 6, security firm Symantec reported that the Flame’s Command and Control Servers sent commands to various compromised computers around the world that wiped all traces of Flame from the infected machines. It was also reported that Stuxnet was coded to destroy itself on June 24, 2012.
After the discovery of Flame, various alleged Cyber-security experts started making grandiose claims of the cyber attack on Iran being equivalent to a nuclear attack, which is not supported by existing evidence. However, soon after this, various governments the world over, including the governments of China, India, and Japan. All these governments claimed they were creating teams to develop offensive cyber weapons. Given this, we can expect an increase in offensive cyber-weapons being deployed on the web in the coming years. This puts less developed and developing countries without capabilities in cyber security under the mercy of those that do, even if less developed countries are less likely to be seriously affected by an offensive cyber attack. However, such an attack is likely to cripple states that have automated public infrastructure SCADA systems, including power plants and water plants.
Shortly before Kaspersky labs revealed the Flame on May 28, the company’s CEO Eugene Kaspersky declared that countries collaborating on Cyber security matters under the aegis of the ITU was the right way forward. However, this seems to be a thinly-veiled attempt to censor the internet under a new ITU draft document that is supported by governments of India, China, Russia, and many other states that are intent on censoring content on the internet. While the narrative presented by ITU is one of collaboration between countries to collectively handle the threat of cyber weapons and cyber warfare, the intent of ITU’s document is to give governments all over the world to censor content on the internet. Vincent Cerf, of the founders of the world-wide web opined that involving the UN in cyberspace puts the open internet at risk.
It is not clear that such treaties pushed by the ITU are the solution to protect states from threats of offensive cyber weapons for a couple of reasons. First, states that are most vulnerable to a debilitating attack by a cyber weapon are also the states that possess the best offensive cyber attack capabilities. Secondly, given that any competent cyber attack will hide the origins of the attack, or worse, mislead observers into attributing the attack to the wrong entity, such an international treaty is unenforceable, and will not improve the security of states party to such a treaty. At this time, there is no good answer to how states can avoid offensive cyber attacks on competitors and rivals, thus motivating capable states to create their own offensive cyber weapons teams to be capable of counter attack, in case such capabilities are called for in the future.
From India’s perspective, while the state is currently not vulnerable to debilitating cyber attacks because most infrastructure is not automated unlike developing countries, it would be prudent to ensure that competitors and enemy nations do not acquire the capability to target Indian cell phone networks and infrastructure in the future. To mitigate this risk, the Indian Government needs to ensure that Indian networks are heterogeneous and do not depend on any one supplier- ensuring that vendors operate with one another reduces the risk of entire network being vulnerable to attacks on equipment of any single vendor.
Fatal error: Uncaught Error:  operator not supported for strings in /home/thinkpra/public_html/archives/wp-content/themes/layerswp/core/helpers/post.php:62 Stack trace: #0 /home/thinkpra/public_html/archives/wp-content/themes/layerswp/partials/content-single.php(81): layers_post_meta(3786) #1 /home/thinkpra/public_html/archives/wp-includes/template.php(724): require('/home/thinkpra/...') #2 /home/thinkpra/public_html/archives/wp-includes/template.php(671): load_template('/home/thinkpra/...', false) #3 /home/thinkpra/public_html/archives/wp-includes/general-template.php(168): locate_template(Array, true, false) #4 /home/thinkpra/public_html/archives/wp-content/themes/layerswp/single.php(20): get_template_part('partials/conten...', 'single') #5 /home/thinkpra/public_html/archives/wp-includes/template-loader.php(78): include('/home/thinkpra/...') #6 /home/thinkpra/public_html/archives/wp-blog-header.php(19): require_once('/home/thinkpra/...') #7 /home/thinkpra/public_html/archives/index.php(17): require('/home/thinkpra/... in /home/thinkpra/public_html/archives/wp-content/themes/layerswp/core/helpers/post.php on line 62