Information Security News
The Stuxnet computer worm that destroyed centrifuges inside Iran's Natanz uranium enrichment site was only one element of a much larger US-prepared cyberattack plan that targeted Iran's air defenses, communications systems, and key parts of its power grid, according to articles published Tuesday.
The contingency plan, known internally as Nitro Zeus, was intended to be carried out in the event that diplomatic efforts to curb Iran's nuclear development program failed and the US was pulled into a war between Iran and Israel, according to an article published by The New York Times. At its height, planning for the program involved thousands of US military and intelligence personnel, tens of millions of dollars in expenditures, and the placing of electronic implants in Iranian computer networks to ensure the operation targeting critical infrastructure would work at a moment's notice.
Another piece of the plan involved using a computer worm to destroy computer systems at the Fordo nuclear enrichment site, which was built deep inside a mountain near the Iranian city of Qom. It had long been considered one of the hardest Iranian targets to disable and was intended to be a follow-up to "Olympic Games," the code name of the plan Stuxnet fell under.
Researchers have discovered a potentially catastrophic flaw in one of the Internet's core building blocks that leaves hundreds or thousands of apps and hardware devices vulnerable to attacks that can take complete control over them.
The vulnerability was introduced in 2008 in GNU C Library, a collection of open source code that powers thousands of standalone applications and most distributions of Linux, including those distributed with routers and other types of hardware. A function known as getaddrinfo() that performs domain-name lookups contains a buffer overflow bug that allows attackers to remotely execute malicious code. It can be exploited when vulnerable devices or apps make queries to attacker-controlled domain names or domain name servers or when they're exposed to man-in-the-middle attacks where the adversary has the ability to monitor and manipulate data passing between a vulnerable device and the open Internet. All versions of glibc after 2.9 are vulnerable.
Maintainers of glibc, as the open source library is called, released an update that patches the vulnerability. Anyone responsible for Linux-based software or hardware that performs domain name lookups should install it as soon as possible. For many people running servers, patching will be a simple matter of downloading the update and installing it. But for other types of users, a fix may not be so easy. Some apps that were compiled with a vulnerable version of glibc will have to be recompiled with an updated version of the library, a process that will take time as users wait for fixes to become available from hardware manufacturers and app developers.
Surviving infosec's perfect storm
Enterprise security is very complex and constantly changing. Gigamon's CEO Paul Hooper says “Security is one of the most interesting attributes of enterprise infrastructure”. Reflecting back over the past decade, Hooper says security is evolving faster ...
Google researchers Fermin J. Serna and Kevin Stadmeyer today released a blog post stating that they found a stack-based buffer overflow vulnerability in the getaddrinfo function in glibc. This is significant for a number of reasons:
The exploit will likely trigger a DNS lookup from a vulnerable system. DNS lookups can be triggered in many ways: An image embedded in a web page, an email sent that is processed by a spam filter (which involves DNS lookups) are just two of many options.
The exploit response will exceed 2048 bytes in size. Not all responses 2048 are exploits. The response may arrive via TCP or UDP.
Many modern systems support a feature called EDNS0. This feature can be used by a client to signal to a server that it is willing to receive UDP responses that are larger than the traditional 512 bytes in size. Features like DNSSEC require EDNS0 to be enabled. Blocking large DNS responses will likely break EDNS0. DNS resolution may fail or will be significantly delayed.
What can you do?
- make sure all systems on your network use a specific resolver and block outbound DNS unless it originates from this resolver (this is a good idea anyway!). This will limit exposure to the resolver
- the advisory has a number of different options available (note that while the bug appears to be related to IPv6 AAAA queries, disabling IPv6 will not mitigate the issue. The exploit payload may still include malicious content).
All versions of glibc after 2.9 are vulnerable. Version 2.9 was introduced in May 2008.
Affected / Not Affected Major Linux Distributions (work in progress)
|Distribution||Vulnerable (glibc">||Debian wheezy">||Debianjessie||yes (2.19)|
When security meets sarcasm: Taylor Swift brings infosec to the masses
Infosec Taylor Swift -- who goes by @SwiftOnSecurity on Twitter -- inspires thousands of people each day talking about security. The account's real name (and gender) isn't known, but, "she" -- for the sake of argument -- makes an important contribution ...