Opinion: Flamer/sKyWIper – Facts & Myths in 5 Minutes

Opinion: Flamer/sKyWIper

Facts & Myths in 5 Minutes

Stefan Friedli
von Stefan Friedli
Lesezeit: 9 Minuten

Dear reader, I’d like to point out that everything you will read below is purely based on the available information and my interpretation of those alleged facts. This is a writeup that was written on the very day the existence of Flame became public, so certain information may be subject to change and revised over the course of time. Check the bottom of the page for edits and errata.

Introduction

Discovered 2010, Stuxnet caused a lot of turbulence throughout the infosec landscape and beyond. The assumption, that this piece of malware could have been used to target and effectively, physically sabotage specific nuclear facilities in Iran, along with its complexity, caused strong interest within the technical crowd and quickened the interest of the mainstream media. Almost two years later, we know far more about Stuxnet than we did initially. A lot of research was done to figure out how it worked, what it targeted and – probably the most adventurous question – who was behind it. Felix ‘FX’ Lindner presented a great talk at last years hashdays, which I’d recommend in case you haven’t seen it yet. (https://www.youtube.com/watch?v=GVi_ZW-1bNg)

While the flame (no pun intended) of fascination sparked by Stuxnet is still alive, this article is in fact not about Stuxnet at all. Flamer, which we will talk about here, is a piece of malware that was recently discovered by the Iran National CERT (MAHER) and that, while apparently fairly complex, has almost nothing to do with Stuxnet or its alleged cousin Duqu. This is an important fact for many reasons. One of them being that people will try to fit Flamer in their fantasy-driven picture of cyber warfare and secret agents, while I think it’s important to keep the FUD low and analyze Flamer for what it is: A sophisticated piece of malware that provides a versatile framework of attack vectors and could, theoretically, be used by and against anyone.

What Flamer is

As far as we currently know, Flamer is an attack framework and as such not really easy to categorize clearly. We know that it infects a host persistently and works in combination with multiple C&C servers, so we could call it a backdoor. We could also go for the label ‘worm’, since there is strong evidence provided by CrySyS (the Laboratory of Cryptography and System Security at the Budapest University of Technology and Economics) that MS10-061 and MS10-046 are used among other techniques to attempt propagation, once an initial compromise was accomplished.

Once installed, Flamer seems to be multi-purpose by design. In fact, the whole malware package is 20 times bigger than Stuxnet in size and features a plugin-based infrastructure. It even provides easy extensibility using LUA scripting. Therefore, trying to tie Flamer down to a single category of malware is really not the smartest thing to do. Even as we speak and beyond, new functionality might be added, so we might never know what Flamer did and did not do originally.

From the information available at this point, Flamer was built to compromise systems and steal information, whereas information is a really generic term for whatever the attacker might be interested in. Some common functionality that seems to be in modules available out of the box includes network sniffing, recording audio using local devices, keylogging, taking screenshots – really nothing you wouldn’t expect from any trojan nowadays. However, Flamer seems to do all of these things exceptionally well (even including cryptography), even though there is a lack of publicly available information on what ‘exceptionally well’ means in this specific case.

What Flamer is not

Currently, I have no trouble whatsoever to explain what I know about Flamer in less than three minutes. This is partially because I am no malware researcher and do honestly believe that I’m partly ignorant on the technical specifications and more interested in the implications, as well as partly blatantly less well-informed than some of my friends working for big AV corporations.

What takes a lot of time at this point is to deduce what Flamer is most probably not. And there is a lot of things that Flamer is not. Starting with the assumption already stated above that Flamer is, to the best of our knowledge, not in any way related to Stuxnet/Duqu or any other product based on the so-called ‘Tilded’ platform.

There are a couple of other arguments that try to tie Flamer to Stuxnet/Duqu or similar cyberwar-related malware products. One of these arguments is the usage of MS10-061 and MS10-046 exploits. However, these techniques became common knowledge up to some degree after Stuxnet was discovered, so to assume a connection based upon this is adventurous at best, since these modules were not necessarily part of Flamer from the get-go, but might have been added later on during the development process.

The most popular argument however is that Flamer is mainly active in the Middle East. Kaspersky Labs published information earlier, stating that the top 7 countries are Iran (189 known infections), Israel/Palestine (98), Sudan (32), Syria (30), Lebanon (18), Saudi Arabia (10) and Egypt (5). While this is an interesting piece of data, it collides with the fact that the initial discovery and analysis of the malware took place in Iran. Apart from that: Even when we assume that these initial numbers are correct and there are no other infections (which is unprobable), a congregation of this size would not be a clear indicator for a targeted attack without any specialized payload that would indicate a specific target region. The current statement, linking the existent infections to possible cyberwar operations, is comparable to linking a series of bicycle thefts in Manhattan to possible terrorist activity. Further, the visibility of this type of threats is very limited based upon CERT activity in affected nations and/or availability of samples to AV vendors.

Of course, I cannot rule out that Flamer is in any way related to the goals that the masterminds behind Stuxnet pursued. Not only because we still don’t know what those goals were for Stuxnet, let alone Flamer. However, there is currently no solid evidence that supports those theories. The geographical spread is not significant enough, the usage of similar exploits is likely to occur since it would be ignorant to leave working, partly weaponized exploits unutilized, especially in a modular malware where activating/deactivating certain pieces of functionality is very easy. Also, while Stuxnet targeted industrial systems, there seem to be no specific target definitions for Flamer: It can infect private systems just as well as corporate ones and is designed to collect information without any hardcoded specification about the content, but with keywords supplied by the attacker.

Still, the reports of Flamer being some sort of crazy cyber warfare superweapon keep coming. With the right mindset, everything about it becomes an indicator to support that claim. Even the size: Flamer is over 20MB when extracted. This makes it, as mentioned earlier, 20 times bigger than Stuxnet. Does that mean that Flamer is 20 times better, faster, more complex and dangerous than Stuxnet? Of course not, at least not necessarily. Where Stuxnet was (supposedly) used in a very targeted attack against PLCs, Flamer features a variety of functionality along with several libraries (compression, database manipulation, .). When you start to pack zlib, sqlite3 and a full LUA virtual machine with your backdoor, it is bound to get a little bit softer around the edges. People I know and trust who know a lot more about malware than I do tell me, that while Flamer is more advanced than your everyday trojan, the level of complexity is not way off the charts. Even online banking trojans display a pretty astonishing amount of functionality these days.

Then there is the assumption that the possibility of ruling out other scenarios will leave no other options than to assume that Flamer is a state-sponsored malware. The common approach is to state that Flamer obviously is not used by crimimals since no bank information is being stolen and that, referring to its complexity, it is obviously not used by hacktivists. While I do not dispute these assumptions, I think that breaking down the threat landscape to criminals, hacktivists and warmongering nation-states is a little bit over-simplyfing our current situation.

Conclusion

No, I do not know who created Flamer. Nor do I know what the intended usage is. I am aware of those facts and I do not claim to know anything that is not publicly available up to this point is time. However, I’m writing this both for future reference and in advanced response to countless media inquiries our press office will undoubtedly receive during the next couple of hours and days.

We are living in a world where information is an asset. For corporations just as much as for individuals. Flamer is a piece of software that, no matter who is using it, targets this information with the purpose of disclosing it to whoever controls it. Therefore, our primary goal should not be the ‘who’, but the ‘how’. How Flamer works, how it exploits systems, how it remained undetected by all our security products for over nearly two years, how it gathers information and communicates with the C&C systems is essential to learn how we can defend against it, and its successors.

Über den Autor

Stefan Friedli

Stefan Friedli gehört zu den bekannten Gesichtern der Infosec Community. Als Referent an internationalen Konferenzen, Mitbegründer des Penetration Testing Execution Standard (PTES) und Vorstandsmitglied des Schweizer DEFCON Group Chapters trägt er aktiv zum Fortschritt des Segmentes bei.

Links

Sie wollen Ihr Log und Monitoring auf das nächste Level bringen?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSSv4

Konkrete Kritik an CVSSv4

Marc Ruef

Das neue NIST Cybersecurity Framework

Das neue NIST Cybersecurity Framework

Tomaso Vasella

Angriffsmöglichkeiten gegen Generative AI

Angriffsmöglichkeiten gegen Generative AI

Andrea Hauser

iOS Mobile Application Testing

iOS Mobile Application Testing

Ian Boschung

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv