Flame: Massive cyber-attack discovered, researchers say

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.

The Lua [0] functions are an interesting read.

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.

There is plenty more in there.

[0] "What's in a name?" http://www.lua.org/about.html#name

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.

Give them some credit. Duqu was written using a nonstandard C extension for OO and it was pretty heavily obfuscated iirc.

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.

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.

He's pointing out that the explanation for the size given in the article isn't adequate because the facts don't bear it out.

Would opening a pdf via Chrome for example provide any extra protection? From what I understand most of the exploits are because of embedded media, no?

It depends: will you render it using Adobe's software?

Note that while the exploit is in the PDF, the vulnerability is in the PDF reader. In practice, Adobe's software is the only attack surface anyone ever exploits, so you can read exploit-laden PDFs worry-free by using a less popular alternative. The same is true with Word/Excel files, etc.

You should still have some kind of comprehensive security solution in place, particularly for a business environment, but use of non-standard software is an effective fail-safe for when your "real" security craps out on you (as it inevitably will).

For what it's worth if you're using OSX Lion Preview is sandboxed.

Use chrome! It's probably more secure than downloading the PDF and opening it with Adobe software.

Except the last time when 20MB was "large" was in the early 1990s. Today, even if someone goes to clean out their harddrive, a 20MB file is unlikely to even appear on the radar.

I think hobbyist development of exploits of the kind that lead to Sub7 has mostly fallen out of fashion, to be honest. Most of the stuff out there these days seems to be commercially-driven scamware and phishing and its developers don't have the same incentive to make their code as 1337 as possible. So 90s-style exploit kits and RATs are quite unusual in 2012.

At 20MB I would be suprised if it didn't patch itself with new exploits.

Haha! yeah I just finished reading the kinda-more-informative analysis (http://www.securelist.com/en/blog/208193522/The_Flame_Questi...). Seems very interesting. I wish that they would share the samples so other hobbyists could also see what it is like