Flame: First Impressions (Free Prose)
Following the report from Crysis over the recently discovered Flame threat, one might wonder how it was that the virus went undiscovered for several years.
The suggested ‘age’ of the malware activity is based on the Webroot community reports that indicate when and where the first samples were reported. The samples in those firstly reported cases happened to share the same filenames as Flame’s own components, and could either have belonged to the Flame family (or not) and could have been detected under different threat names and by different products (or not). The fact that those previously seen samples did not raise an alarm from Webroot does not mean those samples were not detected by other antivirus vendors.
Therefore, the anecdotal evidence about the earlier reported samples does not say anything about the effectiveness of current malware detection.
Another reason why it may have stayed undetected for so long is in the whole purpose of building a covert communication channel - to avoid detection.
Flame communicates with its command and control server via SSL (port 443) in a way that is similar to how your browser communicates with an Internet banking server or with your online Hotmail account.
These secure communications are reliably protected against prying eyes in such a way that even if the traffic is intercepted, it will be practically impossible to decrypt it for the purpose of inspection. The traffic over port 443 looks like gibberish not only to prying eyes, but also to network analysis and forensic tools. They are simply unable to decrypt the secure communications, and because of that, they apply the presumption of innocence principle to them and so let them happen.
This forms a double-edge sword – on one hand, secure communications protects our transactions and our privacy, while on the other, an inability to inspect the traffic creates an opportunity for the malware to use the same channels to communicate with their remote operators without raising the alarm from the very same security products.
Without knowing what algorithm the traffic is encrypted with and what keys were used to encrypt it, no security solution would be able to classify such traffic as malicious, without increasing the risk of ‘False Positive’ detections that may potentially block legitimate traffic.
One might also wonder if Flame is easier/harder to detect due to its rather large size. Well, a larger size does not always mean it is easier to detect.
The larger size of the malware components normally means either a ‘careless’ mindset of the malware authors (novice authors, or those who prefer using higher level languages) or the fact that the project has recently attracted programmers with a professional development background.
Professional developers prefer utilising third-party components and libraries that have evolved over time into highly reliable time-tested tools. Think of it as being an owner builder of your own house: just call reputable contractors and they’ll do the job quickly and professionally.
Flame utilises LUA scripting language that is widely used by the professional developers to build a high-level logic in their software, such as state machines (did you know that your beloved Angry Birds are built with LUA?).
Flame also uses SQLite database – any professional developer loves it for its simplicity, reliability and speed.
Old-school malware authors normally do not have a luxury of embedding such brilliant third-party tools – it is too costly for them as it blows up the size of the malware. Large malware is harder to deploy, harder to hide, it utilizes more CPU power, more memory, and therefore, it is easier to attract unnecessary attention from an average user ("Hey, my computer is slow!"). Therefore, they even tend to develop their own libraries to replace runtime libraries (so that the malware has no dependencies), often built in Assembler language.
Going with the house analogy, the old-school malware authors ‘build their houses’ by themselves – they do adopt techniques, but they do not rely on heavy and costly third-party solutions.
To keep the footprint minimal, the malware would rather use its own binary format to store all the reports with its own light-weight compression and its own encryption – just like ZeuS does. Going with SQLite to store the reports, Flame becomes a laughingstock in the malware community. Most likely, it simply indicates that it does not care as it has the luxury of uploading and running anything it wants and whenever it wants. These are the tell-tale signs of a targeted attack: it does not have to be slim to survive in the cruel world. On the other hand, this complacency might be explained with the fact the recently attracted professional developers simply work the way they used to work before – developing lower level components might sound like a nightmare idea to them.
Detection-wise, simplistic signature-based detection is obsolete these days. In order to spot malicious code, an antivirus product should emulate it in order to ‘unwind’ the covert (hidden) logic programmatically until the vicious chunks of it are revealed. A large code often means more code to emulate or the usage of higher-level languages that are much harder to emulate or their emulation is simply not supported. Without an ability to follow the execution logic programmatically, an antivirus product might not be able to detect a well-protected sample effectively.
Reverse Engineering is a slow process, but very soon we will most certainly understand the entire scope of its techniques. The tricks it uses are not new – its memory injection model is different from Duqu/Stuxnet, but is similar to ZeuS. There is nothing new in deployment via existing exploits either. Injection into the system process to bypass firewalls has also become a de-facto standard for advanced persistent threats.
Its ‘business level’ purpose and intent are interesting to know, but being a backdoor trojan, its fundamental purpose is to control and monitor the victim, and to steal information. A thief is a thief – its full purpose and intent of its actions is to steal… ‘why’ is a different question.
Should you be worried?
Well, when it comes to the malware, one should never be complacent about it. The malware threat landscape is an extremely dynamic scene, and Australian businesses should always stay agile, be aware about the trends and tendencies, and fully understand the capabilities of modern malware and the associated risks. Flame is probably not aimed at you, but don’t discount the chance of one that is aimed at you, turning up in future.
The suggested ‘age’ of the malware activity is based on the Webroot community reports that indicate when and where the first samples were reported. The samples in those firstly reported cases happened to share the same filenames as Flame’s own components, and could either have belonged to the Flame family (or not) and could have been detected under different threat names and by different products (or not). The fact that those previously seen samples did not raise an alarm from Webroot does not mean those samples were not detected by other antivirus vendors.
Therefore, the anecdotal evidence about the earlier reported samples does not say anything about the effectiveness of current malware detection.
Another reason why it may have stayed undetected for so long is in the whole purpose of building a covert communication channel - to avoid detection.
Flame communicates with its command and control server via SSL (port 443) in a way that is similar to how your browser communicates with an Internet banking server or with your online Hotmail account.
These secure communications are reliably protected against prying eyes in such a way that even if the traffic is intercepted, it will be practically impossible to decrypt it for the purpose of inspection. The traffic over port 443 looks like gibberish not only to prying eyes, but also to network analysis and forensic tools. They are simply unable to decrypt the secure communications, and because of that, they apply the presumption of innocence principle to them and so let them happen.
This forms a double-edge sword – on one hand, secure communications protects our transactions and our privacy, while on the other, an inability to inspect the traffic creates an opportunity for the malware to use the same channels to communicate with their remote operators without raising the alarm from the very same security products.
Without knowing what algorithm the traffic is encrypted with and what keys were used to encrypt it, no security solution would be able to classify such traffic as malicious, without increasing the risk of ‘False Positive’ detections that may potentially block legitimate traffic.
One might also wonder if Flame is easier/harder to detect due to its rather large size. Well, a larger size does not always mean it is easier to detect.
The larger size of the malware components normally means either a ‘careless’ mindset of the malware authors (novice authors, or those who prefer using higher level languages) or the fact that the project has recently attracted programmers with a professional development background.
Professional developers prefer utilising third-party components and libraries that have evolved over time into highly reliable time-tested tools. Think of it as being an owner builder of your own house: just call reputable contractors and they’ll do the job quickly and professionally.
Flame utilises LUA scripting language that is widely used by the professional developers to build a high-level logic in their software, such as state machines (did you know that your beloved Angry Birds are built with LUA?).
Flame also uses SQLite database – any professional developer loves it for its simplicity, reliability and speed.
Old-school malware authors normally do not have a luxury of embedding such brilliant third-party tools – it is too costly for them as it blows up the size of the malware. Large malware is harder to deploy, harder to hide, it utilizes more CPU power, more memory, and therefore, it is easier to attract unnecessary attention from an average user ("Hey, my computer is slow!"). Therefore, they even tend to develop their own libraries to replace runtime libraries (so that the malware has no dependencies), often built in Assembler language.
Going with the house analogy, the old-school malware authors ‘build their houses’ by themselves – they do adopt techniques, but they do not rely on heavy and costly third-party solutions.
To keep the footprint minimal, the malware would rather use its own binary format to store all the reports with its own light-weight compression and its own encryption – just like ZeuS does. Going with SQLite to store the reports, Flame becomes a laughingstock in the malware community. Most likely, it simply indicates that it does not care as it has the luxury of uploading and running anything it wants and whenever it wants. These are the tell-tale signs of a targeted attack: it does not have to be slim to survive in the cruel world. On the other hand, this complacency might be explained with the fact the recently attracted professional developers simply work the way they used to work before – developing lower level components might sound like a nightmare idea to them.
Detection-wise, simplistic signature-based detection is obsolete these days. In order to spot malicious code, an antivirus product should emulate it in order to ‘unwind’ the covert (hidden) logic programmatically until the vicious chunks of it are revealed. A large code often means more code to emulate or the usage of higher-level languages that are much harder to emulate or their emulation is simply not supported. Without an ability to follow the execution logic programmatically, an antivirus product might not be able to detect a well-protected sample effectively.
Reverse Engineering is a slow process, but very soon we will most certainly understand the entire scope of its techniques. The tricks it uses are not new – its memory injection model is different from Duqu/Stuxnet, but is similar to ZeuS. There is nothing new in deployment via existing exploits either. Injection into the system process to bypass firewalls has also become a de-facto standard for advanced persistent threats.
Its ‘business level’ purpose and intent are interesting to know, but being a backdoor trojan, its fundamental purpose is to control and monitor the victim, and to steal information. A thief is a thief – its full purpose and intent of its actions is to steal… ‘why’ is a different question.
Should you be worried?
Well, when it comes to the malware, one should never be complacent about it. The malware threat landscape is an extremely dynamic scene, and Australian businesses should always stay agile, be aware about the trends and tendencies, and fully understand the capabilities of modern malware and the associated risks. Flame is probably not aimed at you, but don’t discount the chance of one that is aimed at you, turning up in future.
2 Comments:
This comment has been removed by the author.
This LUA scripting language is really high level logic in their software and its features really informative. Your article is amazing I got an effective knowledge from you article.
onenote training
Post a Comment
Subscribe to Post Comments [Atom]
<< Home