Opinions about information security from a risk management perspective
Security alert: New Trojan Horse apps said to attack the Mac.
Some security mavens have long theorized that as the Mac becomes more popular, we’d start to see malware that would start targeting the platform. Sure enough, this morning’s crop of email blasts from PR firms included a few notices of trojans that are affecting Mac users.
Two Mac oriented security companies SecureMac and Intego are reporting attacks targeting Mac users. They both seem to be legitimate.
SpyEye v. ZeuS Rivalry Ends in Quiet Merger — Krebs on Security.
Brian Krebs today is providing an update on banking Trojan activity. While ZeuS has been in the public eye, another banking Trojan SpyEye seems to be ascending.
In the last several years, it is estimated that the ZeuS Trojan enabled the theft of more than $70 million from nearly 400 organizations.
Microsoft: ‘Unprecedented Wave of Java Exploitation’ — Krebs on Security.
Microsoft is confirming a huge increase in attacks against Java vulnerabilities. Why is this important? Java is installed on the majority of the world’s desktop computers. In fact, the attack volume on Java dwarfs that of Adobe, which is saying something. Java may not be quite as ubiquitous as Adobe, but it’s close. For example, Java is required for Webex and GoToMeeting, the two most popular web meeting applications. To get an idea of the Java to Adobe proportion, see the graph below, courtesy of Microsoft via Krebs on Security.
According to Microsoft, the spike in the third quarter of 2010 is primarily driven by attacks on three Java vulnerabilities that have already been patched for some time now. Even so, attacks against these flaws have “gone from hundreds of thousands per quarter to millions.
Krebs claims the reason for this spike is the inclusion of Java exploits in the commercial crimeware kits sold in the hacker underground.
Java surely falls into that set of PC applications which must be kept up-to-date.
Palo Alto Networks Stuxnet – SCADA malware blog post describes all four Stuxnet vulnerabilities and how to defend against them.
The answer is a combination of policies which:
This week Palo Alto Networks is releasing two new signatures which protect against the last of the four vulnerabilities, CVE-2010-2772. Microsoft does not have a patch for this one yet.
Rethinking Stuxnet | threatpost.
What the sophistication of Stuxnet shows is a level of professionalism and seriousness that normally is attributed to governments and their intelligence agencies. They have the motive, the means and the opportunity to create a piece of malware of the magnitude of Stuxnet and pinning this on the government of Israel is perhaps a logical conclusion, given some of the evidence. There’s a hidden reference in the worm’s code to a date on which an Iranian Jew was executed, as well as some vague Biblical connections. Iran and Israel have a hostile, complicated history, and Israel also is thought to have elite offensive information security capabilities. And Iran had a huge number of Stuxnet infections, including at its Bushehr nuclear plant, which Israel presumably has a vested interest in damaging. Add that all together and you get a seemingly solid case for Israel having unleashed Stuxnet on Iran.
However:
There are no clear benefits that would accrue to Stuxnet’s creators if they made it easy for people to identify them. In fact, there are some major deterrents, including possible retaliation from the target.
In other words, if the Israelis were smart enough to build Stuxnet, why would they be so stupid as to leave clues that lead directly back to them?
Going forward I am going to avoid any posts tied to politics.
Stolen Digital Certificates Becoming Standard Malware Components | threatpost.
One of the lesser known facts about Stuxnet is that it used two stolen digital certificates to bypass anti-malware systems.
“…many antimalware products and other security applications will whitelist binaries and files that are digitally signed. These components are simply trusted and passed along in most cases. The creators of Stuxnet obviously knew this and used it to their advantage. In the wake of the Stuxnet attack, security experts said that they expected other malware authors to follow the lead of Stuxnet and begin using digial signatures to evade security software, and that prediction is already being fulfilled.“
Now that there is a new version of Zeus that’s digitally signed, it’s clear that digitally signed binaries can no longer be trusted. Will digital certificate black lists be added to anti-malware products?
Steve Belllovin has posted a comprehensive analysis of Stuxnet in a post entitled, Stuxnet: The First Weaponized Software? His post also summarizes what is publicly known so far about Stuxnet. Well worth reading in its entirety.
Who’s Behind Stuxnet? The Americans? The Israelis? – Security Watch.
The security research community continues to marvel at the sophistication of Stuxnet. In fact, there is a growing body of opinion that Stuxnet must have been developed with government sponsorship. Since 58% of identified infections seem to have occurred in Iran, the two obvious countries attracting speculation are the United States and Israel.
Previously, I’ve written about Stuxnet on August 14, September 15, and September 17.
Aside from the extremely precise targeted nature of Stuxnet, what is striking is that it took advantage of four different 0-day or unknown vulnerabilities.
If this is not a wake-up call for the need for specialized 0-day malware defenses, I don’t know what is.
Errata Security: Adobe misses low hanging fruit in Reader.
It appears that one of the reasons that Adobe has so many vulnerabilities is lack of a secure software development practices.
One of the most common features of “secure development” is the ability to avoid functions that are known to be dangerous, functions which have caused major vulnerabilities (such as Internet worms) in the past. These are functions developed in the 1970s, before their risks were understood. Now that we have suffered from these functions and understand the risks, we have come up with safer alternatives. Using these alternatives are cheap and easy, and they can save a development house endless embarrassment and remediation time. More importantly, while verifying that your code is “secure” is an essentially impossible task, verifying that your code contains no banned functions is easy. We call this the “low hanging fruit” of secure development.
The Errata article found a high-risk function, strcat, still being used in Adobe Reader and is possibly related to a recent vulnerability, SING Table Parsing Vulnerability (CVE-2010-2883).
In addition, Brian Krebs is reporting that Adobe published yet another security advisory earlier this week about a previously unknown vulnerability in Flash being actively exploited.
