Aren't these the guys who wigged out because they thought Duqu was written in an entirely new custom virus language? And it was actually Visual C++? The second most common compiler on the planet? (after GCC) I would take their analysis with a big pinch of salt.
Not really; they just did OO with C structs and function pointers, this is actually how it used to be done in high- performance code like computer graphics before C++ got fast enough. And the " obfuscation" was passing the -O flag to the compiler...
Any group of reverse engineers who notice C calling conventions and conclude the function parameters are so uniform that it must absolutely be a deadly new HACKER LANGUAGE need to be taken out back and shot, but I doubt any actual engineers were responsible for that announcement.
From the official blog post:
>There are however some links which could indicate that the creators of Flame had access to technology used in the Stuxnet project - such as use of the “autorun.inf” infection method
If I'm not mistaken, you can find youtube videos on how to exploit autorun.inf to make a prank virus. I'm with you on these guys missing easy stuff.
That was actually my first thought as well. To be fair, it was C with Simple Object Orientation so not quite as terrible as misidentifying C++ straight up though it was still a bit of a fiasco.
From their perspective, I'm sure (over)hyping everything new they analyze as the next 'big deal' helps business even if they are wrong about the details on occasion.
>At the moment, we haven’t seen use of any 0-days; however, the worm is known to have infected fully-patched Windows 7 systems through the network, which might indicate the presence of a high risk 0-day.
I really want to know what that 0day is, I can't comprehend how hard it would be to find a 0day remote execution on a Windows system
The exploit might not be part of the package. It could be that the exploit installs flame and then uninstalls or removes traces of itself. 0days are very valuable, it makes sense to remove it if it has served its purpose.
Some exploits like those delivered via browsers attempt to execute code in privileged contexts without any file i/o. There might never have been anything to remove.
From the Kaspersky article, Flame ships with a Lua VM, sqlite3, zlib, libbz2, and an SSL library (probably OpenSSL?), and these and more apparently result in its unusually large size (almost 20 MB).
Sounds almost like "lean malware" written by a relatively small team using easily available tools and libraries.
FLAME isn't a virus, it is software from Brazil, just like LUA is from Brazil.
"Tool prototyping in the FLAME platform is based on the Lua scripting language. Lua is adopted in FLAME as an extension language: its interpreter is embedded as a library into the measurement agents. On the one hand, the Lua interpreter gives to the scripts running in the agents access to active measurement primitives through a high-level, minimalist API. On the other hand, the measurement agents and the measurement API are implemented in C, preventing significant overheads in the measurement results due to the execution of Lua scripts."
http://martin.lncc.br/main-software-flame
Looks like that link's since been updated to make it clear that this is a completely unrelated piece of software called Flame that just happened to use LUA too, with it being very unlikely that any code could be shared between the two. Basically, the name's just a coincidence.
Yes, this almost looks like they've created a sort of malware toolkit which has all the hard parts and exploits in C, but can be scripted quickly for purpose.
Even better if the scripts can then be updated remotely as well.
All things considered, this is the kind of thing you'd do if you were going to do this long term.
The original virus may have only been a few hundred KB, which then bootstrapped the rest of the program. Just because you're writing malware doesn't mean you have to sacrifice good tools.
CamelCase is mingled with upper and lower case VERBOSE_DEFINITIONS separated_by_underscores. This lack of a clear coding style may be visually annoying, but can be added during a final obfuscation step. The unstyled code may not be present in the unobfuscated repo, and does not necessarily indicate the presence of conflicting coding styles on the malware team.
The properties table called flame_props is created and populated inside of a deeply nested if-statement. Are all other branches of this function forced to operate without a valid properties table? This is not an obvious design choice for any programmer who values harmony in a team working on a shared codebase. Perhaps the Lua coder worked alone. Also, this kind of wtf_logic is difficult to insert later as obfuscation.
On lines 2 and 4 of the example, the Flame Lua supervisor appears to be loading text from an external source and eval'ing it as code. Lua distributions have long offered an entire API for managing and loading modules. Breaking a large project into modules is a standard practice. Reinventing a module loading tool, then, is probably not a path to reliability. The module loading code in Lua is a time-tested grab bag of platform-specific heuristics and yet is still a frequent topic of discussion on the mailing list. Given the multi-platform operating requirements of the program, reinventing it doesn't seem like the most robust design decision.
Similarly, the flame_props table is initialized with strings that looks like the names of entries in property tables of other modules. Why is there not a central way to create and populate these tables? Requiring conversion of "string dot string" into a clean table reference before use seems to unnecessarily add danger to the setup code.
Although I keep referring to a possible obfuscation step, I don't see strong evidence for one. The code uses variable names like SUCCESSFUL_INTERNET_TIMES_CONFIG next to l_1_0 and l_1_1. The short names are quite likely to cause new bugs due to typos, yet the long is very descriptive, almost self-documenting. I have seen code like this before -- it came from neglect bordering on malice, not from deliberate obfuscation.
