Flame: Massive cyber-attack discovered, researchers say(bbc.com)
bbc.com
Flame: Massive cyber-attack discovered, researchers say
http://www.bbc.com/news/technology-18238326#?utm_source=twitterfeed&utm_medium=twitter
83 comments
Kaspersky blog has more info:
http://www.securelist.com/en/blog/208193522/The_Flame_Questi...
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.
Give them some credit. Duqu was written using a nonstandard C extension for OO and it was pretty heavily obfuscated iirc.
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...
s/used to be done/is/
Also, the Linux kernel, and any other half decent large C program.
Also, the Linux kernel, and any other half decent large C program.
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.
> technology used in the Stuxnet project - such as use of the “autorun.inf” infection method
Can't tell if you are trolling or ...
Can't tell if you are trolling or ...
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 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.
The InfoSec industry unfortunately is 99% scaremongers and wannabe spies.
>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
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.
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.
The LUA makes me wonder if the creator could be identified by their coding style.
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.
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
"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
Thank you for doing ten-minutes of research. Your investigative style of journalism is apparently better than both Kaspersky and the BBC.
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.
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.
Yeah, I mean, sqlite3? In a 'virus'?
What's next? Shipping the JVM and MariaDB
What's next? Shipping the JVM and MariaDB
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.
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
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 reason why Flame is [20MB] is because it includes many different libraries, such as for compression (zlib, libbz2, ppmd) and database manipulation (sqlite3), together with a LUA virtual machine.
SQLite is 500kB, Lua is 150kb, zlib is 80kB, libbz2 is 60kB. Together this comes to less than 1MB, not 20MB. You would need an awful lot of libraries like this to get anywhere close to 20MB.
SQLite is 500kB, Lua is 150kb, zlib is 80kB, libbz2 is 60kB. Together this comes to less than 1MB, not 20MB. You would need an awful lot of libraries like this to get anywhere close to 20MB.
They're likely skipping over a ton of libraries for brevity's sake. It captures data from audio, video, bluetooth, and other sources. A full BT stack is going to be pretty sizable. If there's any compression being done on that audio or video, that could also add to the bulk.
I don't get the point of your comment. Are you saying you doubt it's 20MB? Or that it doesn't include a lot of libraries?
What point are you trying to make exactly?
What point are you trying to make exactly?
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.
Exactly. I particularly wanted to mention that it's entirely possible to ship software that uses libraries like this but isn't 20MB large. But maybe there are a lot more libraries included than are mentioned here (as another poster suggested).
More technical details (pdf) on:
http://www.crysys.hu/skywiper/skywiper.pdf
Although the naming differs it has been noted on several blogs that it is the same malware.
Although the naming differs it has been noted on several blogs that it is the same malware.
I always hesitate a little bit when I open a pdf, specially when it is one on malware
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).
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).
I've no idea why everyone only exploits Adobe's software though. For instance, pretty much all the open source PDF readers are based on a single PDF library called Poppler with a history of security vulnerabilities - exploit that and you should be able exploit all of them in one fell swoop.
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?
Extra protection as opposed to opening it in adobe reader, yes, much likely. Chrome has a sandbox for pdfs as far as I'm aware, they also provide a lot of big bug bounties to people who find any remote execution bugs in Chrome. So, in conclusion, yes, chrome provides relatively more security than other software when opening PDFs.
It depends: will you render it using Adobe's software?
IIRC, both Adobe Reader "Protected Mode"[1] and Chromium "sandbox"[2] are built on Windows user-mode sandbox framework[3]. Basically, things like principle of least privilege and disable writes etc.
[1]http://blogs.adobe.com/asset/2010/10/inside-adobe-reader-pro...
[2]http://dev.chromium.org/developers/design-documents/sandbox
[3]http://blogs.msdn.com/b/david_leblanc/archive/2007/07/27/pra...
[1]http://blogs.adobe.com/asset/2010/10/inside-adobe-reader-pro...
[2]http://dev.chromium.org/developers/design-documents/sandbox
[3]http://blogs.msdn.com/b/david_leblanc/archive/2007/07/27/pra...
Security is all about execution: Chrome has an enviable track record; Adobe has an embarrassing one. They could change that but it's unclear that they're motivated to build up serious security competency (if they were, the manager in charge of their update process would be fired for cause)
Use chrome! It's probably more secure than downloading the PDF and opening it with Adobe software.
Adobe Reader X actually has a decent sandbox ... but you're generally correct, I would trust chrome more.
Wow, I take back my statement. I have more respect for Adobe now.
For what it's worth if you're using OSX Lion Preview is sandboxed.
> sKyWIper may have been active for as long as five to eight years
spooky.
spooky.
"It’s easier to hide a small file than a larger module." my mind is blown. small files are not like small rocks. it's a computer!
Assuming fairly dense formats (no .wavs or .bmp images), large files necessarily mean more than small files, so they draw more attention to themselves. "Why is /foo/bar using 300MB of disk?" is a much more likely avenue of inquiry than "Why is /foo/bar using 50KB of disk?".
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.
Unless you're dealing with most corporate mail systems.
I don't quite understand what you mean - the 20MB file would stand out on a mail server? I find that unlikely, unless they're running OpenBSD. Is the 20MB file attached to mail messages? That also seems unlikely, if only because that's a really stupid way to design a virus.
The reason it's a stupid way to design a virus currently is because that was one of the primary attack vectors in the past. Yes, most decent mail systems will protect against this. But some might not -- might as well use what's worked in the past as well as other options.
Also, what if the mail component were used to hide/archive the virus? Hide a virus attachment from someone to themself, then have some bootstrap code (Outlook/email client exploit, perhaps) that loads the email archived virus back onto the comp.
Also, what if the mail component were used to hide/archive the virus? Hide a virus attachment from someone to themself, then have some bootstrap code (Outlook/email client exploit, perhaps) that loads the email archived virus back onto the comp.
>> Our estimation of development ‘cost’ in LUA is over 3000 lines of code, which for an average developer should take about a month to create and debug.
They should do project estimation instead of Security Analysis.
They should do project estimation instead of Security Analysis.
Didn't Sub7 do all of that back in the 90s?
BBC won't provide the technical details that we hackers would require to differentiate the two. If it shares the likes of Stuxnet then it would have some pretty clever 0-days inside to help with infection and spreading.
right. and it was NOT developed by state.
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.
I assume we are going to see a complicated and interesting dissection a la Stuxnet? The Stuxnet TED talk [0] was really interesting, I ended up giving a talk to my department at work afterwards.
[0] - http://www.youtube.com/watch?v=CS01Hmjv1pQ
[0] - http://www.youtube.com/watch?v=CS01Hmjv1pQ
Here's a much deeper and more technical presentation Ralph Langner gave on Stuxnet.
http://vimeopro.com/s42012/s4-2012/video/35806770
http://vimeopro.com/s42012/s4-2012/video/35806770
> "Currently there are three known classes of players who develop malware and spyware: hacktivists, cybercriminals and nation states."
Surely that can't be all-inclusive… is it?
Surely that can't be all-inclusive… is it?
How could it not be? That is a very broad group. Who else has the motivation to develop and maintain large scale malware/spyware? If you want to be pedantic about it cybercriminal is probably broad enough to be all inclusive.
I guess you could include companies like Sony but they were probably excluded for not having the same malicious intent.
I guess you could include companies like Sony but they were probably excluded for not having the same malicious intent.
I'd love to know more about the command and control servers. If any of them involve paid hosting that might help to out the guilty party.
Highly unlikely that that will happen, simply because even the smaller virus writers take precaution when buying servers, they usually do it using stolen credit cards that are not hard to acquire. In addition, the it also depends whether the hosting companies are willing to assist people with the investigation.
if I would invest that much time into writing software, I would add TOR or i2p connectivity and would connect to hidden service
I would love to see the binary, even if it means waiting until vulnerabilities are patched.
At 20MB I would be suprised if it didn't patch itself with new exploits.
Hopefully the infected would not only patch but perform quarantines.
I'm fed up by these technically lacking stories that don't give you the details but tell you that its "complex". While I realise that the BBC website is aimed towards the general public I think that it would be beneficial to include at least some technical details.
If you're fed up with that, avoid the mainstream media & delve into the blog post linked up above :)
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
Or links to sources - this is the web for god's sake!
The Wired ThreatLevel article is a good alternative summary to the BBC article. http://www.wired.com/threatlevel/2012/05/flame/
Those paragraphs are so short that it makes me angry.
Their conclusion that because it doesn't steal money it can't belong to cybercriminals is bogus and show how little they understand of the industry.
I've heard of researchers from one company dumpster diving the competition. A worm (as amateur as a 20mb one ) could easily be the work of those kind. But i think it gets less press than "evil country" "omg world cyber war" ...not that it may not be happening anyway.
I've heard of researchers from one company dumpster diving the competition. A worm (as amateur as a 20mb one ) could easily be the work of those kind. But i think it gets less press than "evil country" "omg world cyber war" ...not that it may not be happening anyway.
We should just convert the comments to a poll. Who is behind this?
How would we keep track of scores? would you keep editing your post to reflect changes in voting?
(this is besides the point if it is a good or bad idea. In any case, it is certainly seems novel to me)
(this is besides the point if it is a good or bad idea. In any case, it is certainly seems novel to me)
Weyland-Yutani
Isreal
non-state actor
North Korea
China
CotDC (only saying this because the list of features reminds me of an article I read years ago about MS Back Orifice)