It's been in the wild for several years, and was discovered just 6 weeks ago.

[GreyGeek]

It's a Windows worm called "Flame", and it is twenty times more complex than Stuxnet.

http://threatpost.com/en_us/blogs/wh...malware-061512

During the analysis of the Flame malware, researchers discovered that one of the unique features of the worm was its use of a forged Microsoft certificate. The attackers used that certificate to set up a seemingly valid Windows Update server inside an infected organization and then have clients connect to the server, ostensibly for Microsoft updates, and then install the Flame malware on those machines.
...
But things changed rather quickly when word leaked out via a David Sanger piece in The New York Times that the U.S. and Israel actually did build Stuxnet. Then researchers said that some of the same components found in Stuxnet also are present in Flame, and that the same attackers likely built both tools. Flame is actually the oldest of the three pieces of malware and has been in circulation for at least five years, meaning that the team behind them has been operating for a long time.

Here is a step-by-step analysis of Flame, and the computing power necessary to generate a certificate using collision.
https://speakerdeck.com/u/asotirov/p...ision-in-flame

[capt-zero]

Just another good reason to stay away from Windows

[Snowhog]

The only Windows I use, are the ones in the walls of my house!

[woodsmoke]

as to the cert....I imagine that only GG is old enough to have heard of a collection from Fr. called OPSYS.

woodsmoke

[SteveRiley]

Attacks against availability are annoying.
Attacks against confidentiality are harmful.
Attacks against integrity are dangerous.

http://blogs.technet.com/b/steriley/...integrity.aspx

[GreyGeek]

....
Attacks against integrity are dangerous.
...

Probably the MOST dangerous.

While I am not worried about attacks on my ports, email payloads or drive-by java applets compromising my Kubuntu box, I do think about the integrity of the repositories and PPAs. They have been hacked before, and if developers think like mechanices, whose own cars are always in need of repair, they'll be hacked again:

http://www.theregister.co.uk/2011/08...curity_breach/

Multiple servers used to maintain and distribute the Linux operating system were infected with malware that gained root access, modified system software, and logged passwords and transactions of the people who used them, the official Linux Kernel Organization has confirmed.


The infection occurred no later than August 12 and wasn't detected for another 17 days, according to an email John "'Warthog9" Hawley, the chief administrator of kernel.org, sent to developers on Monday. It said a trojan was found on the personal machine of kernel developer H Peter Anvin and later on the kernel.org servers known as Hera and Odin1. A secure shell client used to remotely access servers was modified, and passwords and user interactions were logged during the compromise.

...

“For each of the nearly 40,000 files in the Linux kernel, a cryptographically secure SHA-1 hash is calculated to uniquely define the exact contents of that file,” the statement explained. “Once it is published, it is not possible to change the old versions without it being noticed.”


Each hash is stored on thousands of different systems all over the world, making it easy for users to check the validity of Linux files before running them on their machines.
Linux kernel maintainers didn't respond to an email seeking comment for this story, but two security researchers who were briefed on the breach said the infected systems were hit by a self-injecting rootkit known as Phalanx, variant of which has attacked sensitive Linux systems before.

Four years ago a flaw in the Debian random number generator caused SSL keys generated for more than a year to be so predictable that they could be guessed in a matter of hours. Debian fixed the flaw. Once the SSL keys for one server are broken they can lead to easily breaking into other servers using SSL. Phalanx2 is a self-injecting kernel rootkit designed for the Linux 2.6 branch that hides files, processes and sockets and includes tools for sniffing a tty program and connecting to it with a backdoor. It is been updated to systematically steal SSH keys. Phalanx2 can be detected by typing "ls" at a command prompt and seeing if it fails to show a directory "/etc/khubd.p2/". IF that directory is there then it can be accessed using the "cd" command. However, that directory is not on Kubuntu systems by default. Also, the "/dev/shm/" directory may contain files used in the attack.

Then there was the Gentoo embarrassment from two years ago, which "ebuilt" a compromised Unreal3.2.8.1.tar.gz into Gentoo systems for two years before it was discovered. Ed Bott had a field day gloating over that one.

Also, two years ago, an SQL injection attack compromised the FSF gnu.org server.

The repository holds the pages for the organization's Gnu.org website, which the attackers altered last weekend. They also downloaded all the user names and encrypted passwords. None of the Gnu software projects on the server have been compromised as part of the attack, said Matt Lee, FSF's campaign manager.


[ Learn how to greatly reduce the threat of malicious attacks with InfoWorld's Insider Threat Deep Dive PDF special report. ]
As a precaution, the Savannah server's administrators eliminated any changes to the server contents since Nov. 23, a day before the first attack. Developers using the repositories can upload changes from their local copies, and as they are signed onto the system, they will be required to change their password.


According to the FSF, attackers breached the FSF server Nov. 24 by using SQL injection attacks against the Savane bug tracking application.

Two years ago was a busy time. The Apache project server was hacked.


When arrogance and hubris replace common sense security a fiasco can result. A couple of months ago a Russian hacker used a weakness in Ruby On Rails to gain complete control of a git hub repository. He had posted a vulnerability report to the Rails bug but the developers who replied claimed that the vulnerability was well known and it was up to those who used the language to protect themselves, which just reeks of the UAC debacle on Windows: blame the user. He posted several more bug reports and a heated discussion took place. What followed is a classic case of shooting the messenger.

http://www.zdnet.com/blog/security/h...g-hacked/10473

It all started when Homakov opened an issue in the rails repository on GitHub titled "Mass assignment vulnerability - how to force dev. define attr_accesible?" The majority of Rails applications are likely vulnerable, but Homakov's issue was closed multiple times and he reopened it again and again to try to get his point across.


The discussion got pretty heated and it appeared as if Homakov wasn't getting anywhere because Rails maintainers simply said this was not a Rails problem. Their argument was that it's up to the developer to secure his or her code, not Rails.


You should know, if you don't already, that GitHub is written using Ruby on Rails and Erlang. Homakov was also talking to GitHub privately on how to exploit this vulnerability. He responsibly disclosed it on Friday and GitHub fixed it. On Sunday though, Homakov exploited the public key form update vulnerability, which is based on the former, without responsible disclosure (meaning he did so publicly instead of contacting GitHub). GitHub then suspended his account.


Based on the issue thread, it appeared as if GitHub was ignoring Homakov and had banned him instead of paying attention to what he had to say. GitHub's first explanation of the issue was very poor. GitHub's first blog post made it look like Homakov was being malicious, as if the company had detected his "attack" and blocked it, instead of admitting that Homakov did not do any actual damage and simply tried to get his point across.


The overall handling of the situation caused many GitHub users to become angry with the company. Thankfully, GitHub reinstated his account and followed up with a better explanation. They also rolled out quick fixes, which deserves some praise.

Which just goes to show that when egos get involved civility and common sense disappears.

What we also see is that when developers and admins with sever access who are poorly trained in their craft, or become lazy or careless, we all suffer.

What should follow Integrity is Auditing, which is a practice that those who get burned quickly pick up.