Tenable Blog

Attacks Happen

There are many reasons why attackers may target your organization: they could be after your intellectual property, they may have political reasons or there may be financial motivations (if you have credit card data stored on your network). I've often heard people say, "Why would someone want to attack us?" The question should really be phrased, "Why would someone need to attack us?" Often you are targeted not because of who you are, but what you have. Google hosts email accounts that are interesting to certain parties. You may be a university with plenty of bandwidth or a business partner with a company who makes electronics that the attacker is after. The point is that you can't limit the reasons why you are going to be attacked. You have to secure your network with the mindset that someone will eventually come after you.

This brings us to this month's "Patch Tuesday". Two bulletins have been released by Microsoft, and I've included some examples of how they can be used for targeted attacks:

Embedded devices are often connected to a network with no regard given to security. The market has been saturated with devices such as web cameras, wireless routers, VoIP phones and more. Manufacturers are in a race to see who can produce the cheapest and most user-friendly device. Of course, when you make something cheap and easy to use, security is often one of the last considerations. We are left with consumer devices that come with default credentials, common web application vulnerabilities, and no encryption support on management protocols (HTTP vs. HTTPS, and Telnet vs. SSH).

The insecurity of embedded systems may not seem to be a big deal; what could someone possibly do if they compromised such a device? If the device is a router, the potential for traffic sniffing and DNS cache poisoning attacks are high. Other devices such as web cameras can be used to gather intelligence, used as jumping off points (such as printers as depicted in the book "Stealing the Network: How to Own a Continent") or even used as part of a botnet. There is one report of a botnet being built solely on embedded systems including wireless routers in particular. Vulnerable embedded systems are plentiful on the Internet, as uncovered by Columbia University researchers in October 2009 when they released vulnerability scanning data of 130 million IP addresses. Nearly 300,000 devices presented a management interface, with 21,000 of those devices using default passwords. I believe this poses a significant threat to our infrastructure and plan to talk in more detail about this topic at SOURCE Boston in April of this year. As I research embedded systems I regularly feed the Tenable research team information about my findings.

Ease and Security Don't Mix

In the eternal quest to create easy ways for systems to communicate with people and other systems, embedded device manufacturers have created new protocols. One of the first was UPnP, or Universal Plug and Play, which has had its share of security problems. The latest protocol to emerge is called HNAP, or Home Network Administration Protocol. Its goal is to "allow advanced programmatic configuration and management by remote entities." The protocols primary purpose is to aid device manufacturers in supporting remote devices such as printers and wireless routers. HNAP allows remote configurations to be both viewed and changed remotely using an HTTP SOAP-based protocol. While this sounds wonderful, someone decided to push the "easy" button:

"HNAP was designed to be a simple, light weight protocol that is easy to implement inside of small cost-constrained hardware such as network routers, cameras and other small devices. Because the protocol is based on existing HTTP-SOAP standards, it is very flexible and easily extensible."

The first phrase that raises a red flag for security-minded people is "simple, light weight". This almost always means that in order to simplify the design to make it "light weight", the first thing to go is security. Further reading of the Cisco Systems whitepaper on HNAP reveals an entire section dedicated to "Protocol Security", which states:

Recent investigations into the Google "Aurora" incident uncovered evidence that Chinese attackers used a 0-day exploit for Internet Explorer to gain access to Google employees’ computer systems. This event has sparked the release of Microsoft Security Bulletin MS10-002 - Critical , and a public exploit for the vulnerability. To mitigate this vulnerability, Microsoft originally recommended that customers upgrade to Internet Explorer 8, and enable DEP (Data Execution Prevention). On January 21, 2010 Microsoft released an "out-of-band" patch for the vulnerability, which fixes the problem on Internet Explorer version 6, 7 and 8. Methods exist to reliably exploit Internet Explorer versions 6 & 7, and there are several people who have working exploits for IE version 8, including Dino Dai Zovi, a well-respected vulnerability researcher. (A concise list of the details surrounding this issue can be found in this article).

Being Proactive

Many organizations are likely to implement the patch released by Microsoft since the issue has been receiving a lot of media attention. Patching because of a media event is an all-too-common mistake made by many organizations that cannot be convinced to implement new security measures until exploits make the news. Patching systems needs to be part of an organization’s overall strategy – not just a reaction to a media event. When new technologies become available as upgrades to your existing systems, put a plan in place to test and migrate to them, especially if they offer increased security. The organizations doing this today are looking at the latest exploit and implementing their patch strategy as part of the standard operating procedure.

Stinky, Aged Operating System?

It’s that time of the month again - Microsoft patch Tuesday of course! This month I expected to research several different vulnerabilities, how they work, methods to detect them, etc. However, Microsoft is only patching one vulnerability this month. I can’t believe there is only one vulnerability this month! In any case, this month's vulnerability occurs in the way applications handle Embedded OpenType fonts. I was a bit puzzled as to why so much effort was going into font rendering until I discovered that it is common for web sites to implement different languages and have them display correctly to the end user (primarily for “non-English” languages). The vulnerability is triggered when a user renders fonts on a web page or by opening a Microsoft Office document that contains embedded fonts. An interesting fact about this bulletin (which only covers one CVE entry, CVE-2010-0018) is:

"This security update is rated Critical for Microsoft Windows 2000, and is rated Low for Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2."

Another Tuesday, another round of security bulletins from Microsoft. Are you patched? Nessus contains credentialed local checks for all Microsoft security bulletins.

"Specially Crafted"

I have always wondered what the term "specially crafted" really means. What is "special"? Merriam-Webster defines it as "distinguished by some unusual quality". "Unusual" is relative, and means that someone has defined what "usual" means. This is where we start to enter a grey area. How do we determine what is "special" if the "usual" is not clearly defined? In this case, I'm talking about RFCs, the documents used to define what "usual" means with respect to Internet protocols. One of the vulnerabilities this month has to do with IPSec and specifically ISAKMP, the key management protocol. Apparently a "specially crafted" packet will cause this service to eat up CPU cycles and cause a DoS condition. These flaws are common, but my concern is that this condition may not always be caused by a malicious attacker using a tool such as Scapy. For example, a VPN client might send "specially crafted" packets because the programmer, who wrote the client software, misinterpreted the RFC. I wish that Microsoft would be a little more forthcoming regarding the details of the flaw, particularly how difficult it is to exploit.

"Could Allow"

I am also somewhat puzzled by the term "could allow". When using it in the context of remote exploits, it’s even more confusing. A vulnerability either allows or does not allow remote code to be executed. Sure, there are mitigating factors, but if the vulnerability does allow for remote code execution, then Microsoft should just come out and say it. When you are reading security bulletins from Microsoft, keep in mind that "could allow" really means "allows under certain circumstances".

Another Milestone, Nessus 4.2

Long-time users of Nessus have probably noticed that significant improvements have been made over the past several years. For example, Nessus version 3 introduced many performance enhancements due to an overhaul of the NASL interpreter. Nessus version 4 introduced several more improvements, including multi-threading and 64-bit support, in addition to unifying the code base across multiple platforms (Windows, Linux, and Mac OS X). Tenable is proud to introduce the next evolution to the Nessus vulnerability scanner with version 4.2, which includes several enhancements including an all-new Flash-based interface. With the new Nessus 4.2 interface, scan results and policies are stored on the server instead of in a client. Multiple users can log into the web-based interface concurrently and can use a “compare” function to show differences against a previous scan. It is now possible to log out of the interface and log back in without disrupting scans that are in progress,and an administrative user now has the ability to pause or stop the scan of another user. I strongly recommend that everyone view the video preview below to see the new Nessus interface in action:

Another Tuesday, another round of security bulletins from Microsoft. Are you patched? Nessus contains credentialed local checks for all security bulletins, and a network-based uncredentialed check for MS09-064.

Severity is a Matter of Perspective

What struck me as interesting this month are the severity ratings. Microsoft publishes these ratings as a guide to help customers evaluate the vulnerability risk. In many cases, they seem to be doing their customers a disservice. For example, a remotely exploitable vulnerability in Microsoft Word or Excel could be leveraged by attackers to compromise desktop systems. These types of vulnerabilities are frequently exploited by attackers and penetration testers alike to gain access to sensitive information. The advice I always give to organizations is to evaluate each vulnerability with respect to how it affects your business, not what has been published by the vendor.

In addition, if the evaluation of severity is coming from a vendor, it should adhere to some industry accepted standard calculation, such as the CVSS score. Nessus plugins use this scale (1-10, with 10 being the most severe) as a rating for the severity of the vulnerability. While Microsoft rates MS09-067 (a vulnerability in which arbitrary code can be executed as a result of opening an Excel file) as important, Nessus gives it a CVSS score of 9.3. Use these ratings as a guide to develop your patching strategy. For example, if you heavily use Excel, you will need to patch right away. If you do not use Excel, then it is not as critical to patch. You could employ a temporary solution for mitigation by blocking incoming Excel file attachments while you focus on vulnerabilities that pose a bigger risk.

Scanning web applications that require credentials can be a bit tricky as different applications may handle the authentication process in different ways. Nessus has configuration options that will allow you to define the authentication parameters for each application. Nessus also allows users to define pages that are not to be accessed during the web mirroring process, such as "logout.php", which prevents Nessus from being logged out of the application.

Defeating Zombies

Attackers have a number of avenues leading directly into your network, and more importantly, into your data. Each week I read about new data losses, phishing scams and the release of hundreds of new vulnerabilities and exploits. Organizations are employing a rear guard action that is not necessarily tuned to today's attack techniques.

Tried and true defensive measures such as firewalls, anti-virus software, Intrusion Detection Systems provide "operational security", but even if this is running flawlessly, it is typically not enough. Security programs need to evolve with the latest attack trends and Internet technologies. A great blog post by Tim Mugherini titled, "Don't be the Smelly Kid" sums this up nicely. This defines a shift from attackers targeting network services, and moving towards attacking web application and client software. These new methods require updated education for management and the implemention of new and different security projects to protect your infrastructure.

Considering Halloween is around the corner, your security strategy can be compared to the situations in typical horror movies. When the defenseless victims are under attack from whatever threat is posed (zombies, Jason, Freddy, Michael Meyers, etc.), they often make common mistakes such as taking all of the furniture in the room and piling it in front of the door and leaving the windows unsecured. Shooting zombies in any other location other than the head is another good example (those who have read "The Zombie Survival Guide: Complete Protection from the Living Dead" know that the only way to destroy a zombie is to destroy the brain!).