Slashdot Mirror

As i said, the government said that weren't them.... probably. But could had been, after all, reporters or press in general are the ones that receive leaks to announce them.

But odds are high that is just another windows intrusion as there are many, i.e. running a trojan or any new worm, or be a new version of something on the lines of Red October that could take years on be detected.

Bingo!

The Australian Communications and Media Authority's statistics breakdown shows of about 16,500 infected devices online at any one time, 20 Windows viruses make up more than 16,400 of the active IPs. Rarer Windows viruses, and Mac, iOS, Linux and Android infections all total less than 100 infections.

http://www.acma.gov.au/WEB/STANDARD..PC/pc=PC_600121

Kasperky says:

Over a 3-day observation period using Kaspersky Security Network data, Obad.a installation attempts made up no more than 0.15% of all attempts to infect mobile devices with various malware.

http://www.securelist.com/en/blog/8106/The_most_sophisticated_Android_Trojan

So to put this all in perspective, this new super-virus made up less than 0.15% of the attempts to join the 0.1% of infections that aren't Windows viruses.

If you read the Kaspersky analysis of the "super-malware", you'll see why. It ASKS for permission to install and to elevate privileges. If the user says "No", it doesn't happen.

How was the rootkit installed? Can you please elaborate on what security failures were involved?

Not sure if you are looking for how he did it, or indirectly doubting the story, but in case this is in doubt - there are plenty of Linux rootkits.

http://blog.sucuri.net/2013/02/linux-based-sshd-rootkit-floating-the-interwebs.html
http://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections
http://arstechnica.com/security/2012/11/new-linux-rootkit-exploits-web-servers-to-attack-visitors/
http://packetstormsecurity.com/UNIX/penetration/rootkits/
http://www.slideshare.net/AndrewCase/omfw-2012-analyzing-linux-kernel-rootkits-with-volatlity

list could go on for quite a while..

Key passwords (maybe mail, the password managers ones, places where you must type your password frequently) should be easy to remember, and hard to crack (hint), the rest (there are always a lot of them) should be in one or more password managers (i.e. your browser, with a master password, but also more portable ones like KeePassX) where as are not meant to be remembered are easier to change, to put hardest complexity, and of course, to have all different. And try to avoid automated password trying, specially at fast speed, like using fail2ban or similar when possible or having a keyphrase in your private ssh certficate with PKCS #8 to slow down cracking,

But passwords are just a part of the equation, what run as your user usually have access as the same resources as you (i.e. could read your files, your clipboard, your keyboard input, so could capture passwords, no matter how complex they are), access sites to where you are identified on (i.e. single sign-on systems that enables the IP you are on means that a trojan running in your PC have your privileges, same for vpns, or internal systems not safe from xss attacks). And antivirus aren't as good as protection as they claim to be (Red October was active 5 years before being detected, they can be forced to contain backdoors). Using more secure OSs and browsers (at least, ones with no such overabundance of malware), and security practices (only install from official repositories, stop at mail server level things that don't come from where they claim to come, etc).

And of course, educate people. In real life you know things that are risky and dangerous (i.e. don't walk alone at night in high criminality rate neighbourhoods, drink and drive, touch electric wires, etc ), people should be able to understand what is dangerous or risky in internet too, including their private use at home (even if privacy is a lost cause, there are far more risks)

The ads pay for the "free" email, and also help pay for Google's research into autonomous vehicles, improved search technology, etc.

In an ideal world, perhaps. The truth is, most ad-servers end up compromised and serving up malware or iframe redirectors which serve up malware.

Furthermore, I fail to see how maturity equates to putting blind faith into a Corporation to do no evil. Especially when you consider it's Microsoft - the same people who brought us UEFI as well as funded most of the SCO legal debacle.

There are easier approachs. And if well that approach could work now even for government agencies, the user side is also open to intrusion (like Red October) and of course, is in Mega side to do things right too. All of that before even trying to break SSL.

Lost in the operator game.. The original article talks about *drives* D through I on a Windows machine. Some idiot (appears to be Michael Mimoso) decided that "partition" is a more pro-sounding synonym for "drive" and started using both interchangeably in the article from OP. So we are all left scratching our heads. The point I think is that the thing tries to destroy data on network and attached storage devices, rather than wiping C drive which would give itself away much more quickly..

Check out the page he linked to, it has a good analysis of the current state of malware in the world. In some countries, 90% of the computers are infected with something. In the US it's closer to 30% That's a huge number!

Also lists the top 10 vulnerabilities for the year. Java, Adobe, and Microsoft all make the list.

Architecturally, the operating system is constructed in such a way that even a break-in into any of the components or applications loaded onto it won’t allow an intruder to gain control over it or to run malicious code.

Could you expound on this? Are you writing this code or still in the design phase? Or better yet, could you compare it to something like, say, CentOS or Debian and tell us how your architecture is going to be more secure? I understand you're scoping down the requirements of your OS to be more easily manageable but the skeptic in me feels like it just can't be done. The cat and mouse game must be played in some form or fashion.

http://www.securelist.com/en/analysis/204792250/IT_Threat_Evolution_Q3_2012

Obviously, you haven't read the original article here.

Just embedding a binary blob doesn't help. Having a complex routine to decrypt it, verify the extracted data, and run it if verification succeeds is another story.

Though, arguably, you CAN put such a loader and throw in random data just for trolling.

Really. How about this:

http://www.securelist.com/en/weblog?calendar=2007-04%5D

What private keys of note have been hacked?... Dell, Microsoft, the big players, they all work very hard to make sure their private keys are secure.

That I can remember right now:

* ASUS secure boot key
* JMicron and Realtek Windows driver keys
* RSA's SecurID seeds
* Yahoo's private key for signing plugins
* Motorola's bootloader key
* HTC various engineering bootloaders (not an actual key, but signed bootloaders that allowed chainloading of non-signed code, which is just as good as a key in this case)

Funnily enough, I used to have legitimate access to a private key that could be used to load firmware onto a certain brand of credit card payment terminals. So did hundreds of other developers over the years - the key was required to do any form of development, but once you had it, you could reprogram any device in the field to grab card details, pin numbers, modify transactions etc. It was only the goodwill and honesty of the developers that prevented the key from being leaked. I'm sure there are some companies that work hard to protect their private keys and hold those with access accountable, but there are also those who handout private keys to internal staff and contractors alike.

I just picked up the C&C server list that's known so far for the "FLAME" malware here:

http://www.securelist.com/en/blog/208193540/The_Roof_Is_on_Fire_Tackling_Flames_C_C_Servers

I integrated it into my hosts file - also for my roommate who uses Windows Server 2003 32-bit...

You mean the servers, which had been operating for years, that went offline immediately after Kaspersky Lab disclosed the discovery of the malware’s existence last week ? http://www.kaspersky.com/about/news/virus/2012/Kaspersky_Lab_Experts_Provide_In_Depth_Analysis_of_Flames_Infrastructure

You mean the servers active for the past 4 years changing name more than 80 (known !) times (+ all the unknown ones) ?

So you were not protected (granted nobody was) while they were online and you're now protected when they are all offline ?

"This sarcasm was brought to you by the AAA".

Debateable/Possibly: I wouldn't use hosts for INTERNAL networks unless I used it for "failover" purposes actually. I'd rely more on ActiveDirectory Services (which is, of course, DNS dependent). I'd keep it around as a 'failsafe' then only.

Hosts are good/better, for other things... mainly online "layered security"/"defense-in-depth", better speed/bandwidth + faster resolutions of IP addresses to host-domain names.

(I've posted it here many times before, but I wouldn't rely on them solely (though they're EASY to 'migrate' to end user rigs via logon scripts for example)).

APK

P.S.=> SORT of IMPORTANT, on that note (Since you mentioned hosts):

I just picked up the C&C server list that's known so far for the "FLAME" malware here:

http://www.securelist.com/en/blog/208193540/The_Roof_Is_on_Fire_Tackling_Flames_C_C_Servers

I integrated it into my hosts file - also for my roommate who uses Windows Server 2003 32-bit...

(However/Again: I am "impervious" so far @ least, via Windows 7 64-bit as I noted here in the reply you responded to, plus the patch for this issue -> http://www.start64.com/index.php?option=com_content&view=article&id=5779:update-for-windows-7-for-x64-based-systems-kb2718704&catid=38:64bit-update&Itemid=98 )

I built a new custom hosts file using that 1st url - just for "layered-security"/"defense-in-depth" purposes (what you can't touch can't hurt you) as well as firewall rules tables for the IP addressed servers it communicates with also...

I can't "proof myself" any better than that @ this point, since my systems are always "security-hardened" anyhow... apk

Stuxnet was signed by stolen certificates: http://www.securelist.com/en/analysis/204792208/Stuxnet_Duqu_The_Evolution_of_Drivers?print_mode=1 . it's possible that Flamer was signed by compromised certificates, but if we believe that Stuxnet and Duqu were the products of a nation state level actor then we could conclude that Flamer is in the same category.

http://www.securelist.com/en/descriptions/old23854

ADM wrote a worm that spread through bind. I recall a few others, but I don't remember their names so I can't google them.

There's several for MacOS Classic.

Several Trojans, Worms, etc for OSX. Virus in the classic form? Some proof-of-concepts here and there.

For a blast from the past:
http://ftp.cerias.purdue.edu/pub/tools/mac/mac-virus-list.txt (speaking about Mac viruses from the 1980's)

Interesting read on creation of malicious software targeting OSX:
https://www.securelist.com/en/analysis/204791948/Mac_OS_X

A list of baddies for MacOS Classic and OSX:
http://www.iantivirus.com/threats/

Also interesting:
http://lscr.berkeley.edu/archive/mail/magnet/2004/0418.html

And then there's this:
http://www.forbes.com/2006/02/16/apple-osx-virus-cx_po_0216autofacescan09.html

This was amusing:
https://www.youtube.com/watch?v=Sf6_sPkMupA

I'm sure there's lots more if I care to dig.

As elsewhere, is it now slashdot policy to only mention '`computer` malware ..
"After seizing all necessary privileges on the victim computer, the exploit does not install malware on the hard drive using Java. Instead, it uses its payload to inject an encrypted dll from the web directly into the memory of the" javaw.exe process

They did open the lines up for suggestions, and some community members suggested that it looked like OO C. How did they know? They probably had experience using and debugging OO C, if I had to guess. There were also plenty of people who said that it definitely wasn't compiler X or language Y from their own experiences. The article links to this discussion: http://www.securelist.com/en/blog/677/The_mystery_of_Duqu_Framework_solved

But about discovering the specifics of the truth? It's probably like you alluded to in your comment - fingerprinting the machine code. It would take a while, but you could come up with fingerprints for a great many various compilers and features. You could do that for Common Lisp, too. (In fact, someone DID suggest for them to look at various LISP dialects.) It has taken long enough that such a scenario - having a good library of fingerprints - is believable. Given a scanner with a dictionary of fingerprints, one could reasonably say that you either have hand-assembled machine code made to mimic another language, or that you have code generated by a very specific language and compiler. If nothing in your library of fingerprints matched, assuming you had a good handle on hand-assembling machine code, you could look and see if it smells like such a beast. It would be tremendously laborious to hand-assemble code to make it look like a specific compiler generated it, and why would you do that in the first place? I fail to see the benefit when you could just use that compiler. If you were trying to throw off the analysts with a false positive match, there would still be a ton of mysterious data that still needs examination.

Think about DNA analysis. We can look at our DNA and determine some chunks of it came from virus, and that some of it is "junk" that serves no purpose.

Also think about image analysis like OCR or various captcha-breaking software. You can map images to characters with a program, and detect anomalies and known signatures.

Then there is heuristic antivirus scanning. It knows enough to find some previously unthought-of malicious code, even if it does sometimes generate false positives.

So why not apply those techniques to machine code, and see what you get? If multiple methods give you similar results, you would be onto something, I imagine.

There are certain characteristics to the way C++ behaves (the manner in which you pass parameters, etc). Mainly, through having looked at lots and lots of code samples, they can say what they expect the compiled code to look like. If they know C++ compiled code looks like x, regular C looks like y, and this looked like z, it can't be C. Essentially, the code did things you simply can't do in C++ or C (even Objective C) by itself. The problem is, that method only allows you to compare to known languages. More details here.

It's basically like identifying an animal by footprint. Once you know a deer leaves a certain kind of footprint, you can identify more deer by examining footprints. But you can't identify an unknown animal that way: if you haven't seen a given footprint before, you won't know what animal it is, only what general characteristics it has (weight, etc.)

It seems they recognized a sequence of instructions that are typical of a class constructor, just not like any class constructor they were familiar with.

Here you go: http://www.securelist.com/en/blog/667/The_Mystery_of_the_Duqu_Framework

"It is impossible to neutralize a botnet by taking control over the controller machines .. It is still possible to push an update tool on infected machines to neutralize the botnet" Securelist.com

How to neutralize the botnet, use Ubuntu on the desktop ...

Researchers knew that it would only be a matter of time before its controller used the botnet's complex infrastructure of proxy servers and communication nodes to regain control.

The linked story says they fully expected this, and that the method they used (sink-holing) was never expected to be a permanent solution. One has only to hope that stating they have no "recourse" is merely baffle-gab to embolden the controllers. It might also mean "lets make believe we haven't compromised some of the bots and planted a few or our own".

They also suggest that the suspected Russian controller couldn't be extradited, but conveniently neglect to mention that Kaspersky Lab is a Russian company that could influence internal Russian enforcement actions.

Kaspersky Lab Expert Maria Garnaeva Posts in her Blog some of the difference between the new and old control mechanisms: http://www.securelist.com/en/blog/655/Kelihos_Hlux_botnet_returns_with_new_techniques
She also mentions it is not as bleak as the original article, because:

It is still possible to neutralize the botnet with sinkholing but using slightly different techniques as was used before, and it is still possible to push an update tool on infected machines to neutralize the botnet. In this case the botmasters need to infect machines again to build another botnet.

From the original blog article:
"Due to privacy reasons and protection of the identity of the victim, we cannot share the source .DOC file with other parties."

Symantec and Microsoft still haven’t made the actual dropper file available to other antivirus companies yet, nor have they provided information about which Windows component contains the vulnerability that results in privilege escalation. However, indirect evidence suggests that the vulnerability is in win32k.sys.

We discovered a similar vulnerability (see MS10-073) a year ago when analyzing the Stuxnet worm. Another interesting problem in win32k.sys (MS11-077) was fixed by Microsoft on 11 October this year – a code execution vulnerability than can be exploited through font files.

Zaphod-AVA essentially summed it up @ http://it.slashdot.org/comments.pl?sid=2282088&cid=36618244 on June 30.

And Ram Herkanaidu, a Kaspersky Lab Expert confirmed it @ http://www.securelist.com/en/blog/516/TDL_4_Indestructible_or_not on July 4 that they do not believe the botnet is indestructible. Ram tried to downplay the sensationalist headline of it being indestructible by pointing out that they had used inverted comas around the word.

But almost anybody even remotely interested in computing can probably guess and those who are into encryption can state for a fact that nothing in this "virtual world" is indestructible --- things only get a little difficult.

So this is pretty much a lot of noise over the intended wit of an analyst.

A Windows system can be set up to have the same security model as a Unix system, and this has been recommended by Microsoft for years. However, so many legacy applications expect "administrator" privileges in Windows that this is not the easiest thing to do.

OS X's Mandatory Access Controls are a port of TrustedBSD. They are used to sandbox selected services in OS X to improve security, but not widely deployed yet for userspace software. You can configure them yourself using the CLI or using a third party application like "Sandbox".

MS can not be secured to the same degree -- a simple .reg file can disable UAC without warning, disable 64bit driver signing, and install a root Certificate Authority. This Java Applet exploit (A variant of which I've found on US machines attacking US bank accounts) shows windows security for what it is -- an after thought, easily disabled.

Both OSX and Linux security are far superior IMO than Windows, but I do have working "root" level proof of concept exploits for all 3 -- reported, and unpatched (except Linux, it was patched less than 3 weeks after I notified the devs...)

Sometimes security is about diligence, not just forethought.

Forgive the reply to myself, I found an article about a variant of this exploit you may read it yourself.

The linked article says it targets Brazilian banks, but the variant I took apart targeted US banks, and was discovered on a machine belonging to a Texan. The exploit article shows clearly how easy it would be to use a hex editor to change the certs & payload and re-purpose the malware easily, or possibly add it to an attack toolkit.

Also note to the one who downmodded my original comment: "overrated" does not mean "uncomfortably true".

Really? How big do you think the team that created Stuxnet is then? Or do you really think that one guy found 4 new zero days, wrote a P2P control mechanism, a custom kernel mode rootkit, a bunch of PLC code in an obscure form of assembly language and a shim DLL to hide the PLC infection from the operator?

Don't forget the fake kernel drivers signed with a stolen certificate. Stealing or breaking the digital certificate used by JMicron to sign Windows kernel drivers should be out of range for even a skilled single hacker.

Oh and apparently there was a second certificate stolen/broken, this time from Realtek.

This thing is really scary. Even when you follow best practice for security in every detail, you would have no protection against something like Stuxnet.

Here's some more info. Still no link/name/source of the app. They could have paid someone to write a proof of concept/hypothetical app that did that, so they could do a press release and plug in their upcoming product.

No, I didn't read the article you linked to. I'm already well versed on what the bystander effect is so I don't have a particular need for an about.com re-hash of the wikipedia article on it.

I linked to other articles in my original post, one of which had numbers showing that open source, even core stuff that SOMEONE should have hardened, was just as vulnerable and in some cases more, some cases less) as closed source. You obviously didn't read it, even though you posted a reply to it.

There are other articles to be found, such as this Kaspersky Security Bulletin which had this to say:

As for Linux users, a number of serious vulnerabilities were reported in 2006, most of them related directly to the Linux kernel. Some of these allow DoS attacks against a vulnerable system, while the others allow elevation of privileges.

Obviously the Linux kernel is an open source effort that a LOT of eyeballs stare at and it still has vulnerabilities. I'm not saying that Linux is bad, just that open source is not immune to security problems by the very virtue of being open.