Vulnerabilities

Mozilla Disables Insecure Microsoft Firefox Add-on

When I fired up my laptop the other day, I was greeted with this pop-up box:

If you’re running Firefox, you may have already seen it yourself. Recall that these add-ons were installed into Firefox without the user’s permission, causing quite an uproar in the Mozilla user community. Brian Krebs of The Washington Post wrote:

In May, I wrote about a Windows patch for the Microsoft .NET package that silently installed the Microsoft .NET Framework Assistant add-on into Firefox. The package also included an associated plug-in for Firefox called the Windows Presentation Foundation plug-in. The Mozilla user community was up arms over not just the fact that Microsoft was introducing unwanted components that could potentially weaken the security of Firefox, but that Redmond had made the thing almost impossible to remove.

Mike Shaver, Mozilla’s vice president of engineering, wrote Friday on the Mozilla Security Blog:

Because of the difficulties some users have had entirely removing the add-on, and because of the severity of the risk it represents if not disabled, we contacted Microsoft today to indicate that we were looking to disable the extension and plugin for all users via our blocklisting mechanism. Microsoft agreed with the plan, and we put the blocklist entry live immediately.

At least Microsoft agreed with Mozilla’s action to block the insecure add-on, but shame on them for blatantly compromising the security of a browser they don’t even own.

Conspiracy theorists: Do you have an opinion on this?

October 2009 Patch Tuesday Sets New Record

Microsoft Security Response Center’s October 2009 Bulletin Release Advance Notification:

For October we are releasing 13 bulletins (eight critical and five important), addressing 34 vulnerabilities, affecting Windows, Internet Explorer, Office, Silverlight, Forefront, Developer Tools, and SQL Server. Most of these updates require a restart so please factor that into your deployment planning.

Ten of the 13 bulletins–which include all eight critical vulnerabilities–involve patches for remote code execution vulnerabilities. All versions of Windows and Windows Server, including Windows 7 (scheduled for release on Oct. 22) are affected.

This sets a new record for Microsoft. The previous record was set in June when the company issued 31 updates. I’m not too sure how to take this. I’m certainly glad that Microsoft is addressing its security problems, but the trend is a bit disturbing: 28 patches in December, 2008; 31 patches in June, 2009; and, 34 patches this month. We still have the better part of 3months left in 2009. Will we see another record set before year end?

What do you think? Does this mean that Microsoft is being more security conscious or are there more bugs than ever?

Hit the comments and weigh in.

Hacking Skills Challenge-Level 3

My most recent post, Hacker Skills Help Save a Client’s PC, is a real-life practical example of how honing (or developing) your hacking skills can help you better serve your clients. So if you haven’t gotten around to it yet, mosey on over to HackThisSite.org, create an account and get started on the basic missions. They’re pretty simple, but if you don’t know a thing about hacking, you’ll be challenged.

Did you figure out level 3 of the HackThisSite.org Basic Missions? Here’s the mission:

This time Network Security Sam remembered to upload the password file, but there were deeper problems than that.

Recall that Sam forgot the password file the last time and so the script that checked for the file returned a <null> value—a blank password. This time, he remembered to upload the password file, which, if you look at the source code for the page, is password.php. In the last challenge, we were told that the password file was not encrypted. I wonder if we can open password.php? Let’s copy the URL of the challenge page and append “password.php” to it: http://www.hackthissite.org/missions/basic/3/password.php. Voila! The page opens, revealing 792debbc as the password.

Mission accomplished.

Patch Tuesday – Microsoft Fixes Eight Security Flaws

All of them are critical, but not a single one of them affects Windows 7, scheduled for release on October 22.

The most dangerous flaw covered by this month’s batch of patches is a remote code execution vulnerability in the way that the JScript scripting engine decodes script in Web pages (MS09-045). A remote attacker can exploit this vulnerability by convincing a user to visit a specially crafted Web page and this could result in execution of arbitrary code on the affected system. All versions of Windows—except Windows 7—are vulnerable. Here is the list of bulletins taken from the Microsoft Security Bulletin Summary for September 2009:

MS09-045 Vulnerability in JScript Scripting Engine Could Allow Remote Code Execution (971961)
MS09-049 Vulnerability in Wireless LAN AutoConfig Service Could Allow Remote Code Execution (970710)
MS09-047 Vulnerabilities in Windows Media Format Could Allow Remote Code Execution (973812)
MS09-048 Vulnerabilities in Windows TCP/IP Could Allow Remote Code Execution (967723)
MS09-046 Vulnerability in DHTML Editing Component ActiveX Control Could Allow Remote Code Execution (956844)

It remains to be seen how Windows 7 will fare once it’s released to retail, but so far, it appears to be more secure the previous versions of Windows. According to Wolfgang Kandek, chief technology officer at software security provider Qualys, "There are a number of additional security measures [in Windows 7] that seem to be working so far in its favor."

We can only hope.

Is Linux Security as Bad as Microsoft Windows “Security?”

Linux proponents often gloat over the seeming lack of security vulnerabilities in the Linux kernel when compared to Microsoft Windows; Windows proponents counter saying that Linux is just enjoying “security through obscurity.” Seems the Windows people may be justified to some degree as reports of a Linux vulnerability puts most versions of the Linux kernel built in the last eight years at risk of complete takeover.

According to The Register, “The bug involves the way kernel-level routines such as sock_sendpage react when they are left unimplemented. Instead of linking to a corresponding placeholder, (for example, sock_no_accept), the function pointer is left uninitialized. Sock_sendpage doesn’t always validate the pointer before dereferencing it, leaving the OS open to local privilege escalation that can completely compromise the underlying machine.” This means that it’s trivial for an attacker to put code in the first page and that code will get executed with kernel privileges. You can read a full rundown of the vulnerability at the CR0 Blog.

All Linux kernel 2.4 and 2.6 versions since May 2001 are affected. The vulnerability has been patched, but “this is the second time in less than a month that a serious security vulnerability has been reported in the Linux kernel. In mid July, a researcher alerted Linux developers to a separate "NULL pointer dereference" bug that put newer versions at risk of complete compromise,” according to The Register.

There’s no question that Microsoft has ongoing security issues; it’s no surprise that Linux is beginning to show the same. The only difference lies in the attack surface; Microsoft is still the biggest target. As Linux continues to gain market share, however, we’ll be seeing more researchers focusing their attention on the Open Source OS; as they do, they’ll find more and more vulnerabilities there, too.

There’s a technology called “secure coding” that still hasn’t been fully developed, much less implemented on a grand scale; until programmers fully get this concept, we’re saddled with insecure OS’s and applications.

Gmail Vulnerability Points Up the Need for Strong Password Policy

There’s a vulnerability affecting Gmail accounts that was recently announced by security researcher Vincente Aguilera Diaz. You can read the posting on the Full Disclosure security list which contains complete details on how a Gmail authentication attack is accomplished and how it can be automated.

Basically, if you have a Gmail account, you are permitted to guess another Gmail user’s password 100 times every two hours. That’s 1200 guesses per day. If a hacker controls 100 Gmail accounts (easy enough to do, since they’re free, and they probably have many more than this), that’s 120,000 guesses per day. Google has no intention of changing the 100 guesses/2 hrs. limit, saying it’s robust enough. Considering that the Conficker worm’s password table needed only 200 entries to compromise many systems, it’s conceivable that many Gmail accounts could be compromised easily within slightly more than 2 hours.

Gmail does require a password of 8 characters or more, but it does no further parsing, so extremely weak passwords such as aaaaaaaa,  12345678 and the like, are allowed as are dictionary words of sufficient length. What this means is that it’s up to you, the Gmail account holder, to protect your own account; Google isn’t going to enforce strong passwords (other than a length requirement) on the general public any time soon. So, it’s important that you have your own strong password policy.

Eight characters is sufficient length (though I consider it an absolute minimum) to create a very strong password using random upper- and lowercase letters, numbers and symbols. The trouble with those things is that they’re hard to remember. Better to come up with a phrase you can easily remember and use it as your password hint. Then, figure out a standard pattern you can apply to the hint to come up with a strong password. For example, choose the phrase My address is 555 Main St. Now, reverse the order of words and eliminate the spaces: St.Main555isaddressMy; eliminate all repeating letters and numbers: St.Main5drey; finally, make sure every other letter is shifted: St.MaIn5DrEy. That’s a very strong password.

If you want to play around with different scenarios to come up with your own strong password policy, test your passwords with The Password Meter. It’s a pretty cool app.

Patch Tuesday – 19 Windows Security Flaws Fixed

It’s that day of the month again and this time Microsoft has patched 19 security holes, 15 of which have a “critical” rating. The good news is that none of the vulnerabilities affect Windows 7. As usual, a bunch of the flaws stem from ActiveX controls, probably the worst thing Microsoft’s developers ever came up with (with the possible exception of Microsoft Bob).

At least one of the vulnerabilities, MS09-037 - Vulnerabilities in Microsoft Active Template Library (ATL) Could Allow Remote Code Execution (973908), is currently being actively exploited on the Internet; exploit code for MS09-043 - Vulnerabilities in Microsoft Office Web Components Could Allow Remote Code Execution (957638) has been posted publicly.

Get those patches installed ASAP!

Tsk, Tsk! Weak Passwords Allow Congressional Web Site Defacements

This is simply idiocy—or gross negligence—of the highest degree. In the last week, more than a dozen US Representatives’ websites were defaced by hackers who posted digital graffiti on the home pages. The graffiti read, “H4ck3d by 3n_byt3 @ Indonesia H4ck3rs” (see screen shot). There was not other damage to the sites.

The method used to break in? Password guessing. The hackers compromised the site administration passwords at Web design and hosting firm GovTrends of Alexandria, VA which provides Web hosting for about 100 House sites. Not all were affected.

According to GovTrends founder Ab Emam, passwords assigned to member offices were never changed. Now, it’s typical for a Web hosting company to assign default admin passwords, but those passwords should be strong. In this case, they weren’t. “Most of these passwords could be guessed, they were obvious,” Emam said. “That’s been changed, and each of these sites is now required to have strong passwords.”

Really? Should have been required all along. There’s simply no excuse for this. I have written numerous articles over the years about how to generate strong, un-guessable passwords and I’m not the only one: a Google search brings up 61,800 results for that term. Will they ever learn?

(In all fairness, I have to report that there is some question as to whether password guessing was actually the cause of the breach. This article by Brian Krebs has been updated to suggest that SQL injection may have been the method.)

No matter; there’s no excuse for that, either.

Shrink Your Attack Surface

I’ve heard this phrase bandied about in Linux forums and in the occasional blog post, but it’s something I never considered relative to the security of Windows boxes.  There’s an awful lot of research on the subject and it boils down to this: The larger the attack surface, the more insecure the system. Makes sense, but just what is an attack surface? Thanks to a research paper, Measuring a System’s Attack Surface, Pratusya Manadhata and Jeannette M. Wing, CMU Technical Report CMU-CS-04-102, January 2004, we have a concise definition:

A system’s attack surface is the set of ways in which an adversary can enter the system and potentially cause damage.

This means that any applet, any built-in feature, any module, any application, probably contains multiple attack vectors. Moreover, certain applications like Internet Explorer are attack vectors in and of themselves. When I started to look into this, I found that some folks over at the Microsoft Developer Network had put together a discussion along with a handy list of Windows attack vectors:

• Open sockets
• Open RPC endpoints
• Open named pipes
• Services
• Services running by default
• Services running as SYSTEM
• Active Web handlers (ASP files, HTR files, and so on)
• Active ISAPI Filters
• Dynamic Web pages (ASP and such)
• Executable virtual directories
• Enabled Accounts
• Enabled Accounts in admin group
• Null Sessions to pipes and shares
• Guest account enabled
• Weak ACLs in the file system
• Weak ACLs in Registry
• Weak ACLs on shares

Bear in mind that any of these can be subject to multiple vulnerabilities and many of them have been connected with specific vulnerabilities. However, the attack vector itself does not necessarily indicate a system vulnerability, per se. Think of  these as things an attacker would try to compromise; for example, attempting to logon to a system as Guest. If the Guest account is enabled, that’s a vulnerability; if the Guest account is disabled, it’s merely a vector for attack.

So, how can we use this information in our workaday world? First, realize that the OS itself is the basis of all of the above items. Next, realize that any program, web application, widget, gadget, what have you, is going to utilize one or more of them.  Finally, get the concept of “default unnecessary.”  Windows comes with many built-in (read default) features, services and applications—many of them completely unnecessary in the enterprise.

We shrink the desktop attack surface by building our desktop image in three stages:

• We clean up the OS by removing ALL unnecessary features, tools, and applications. A good place to start is all the stuff in the Accessories folder. And who ever uses Microsoft Backup, or Character Map, or Tour Windows XP? You get the idea.
• Given a stripped-down image, we next install ONLY those applications and tools that are absolutely necessary for the user to perform her job. Ideally, we avoid mainstream applications and utilities as much as possible and go with those that are not as widely used (security through obscurity) and therefore not as subject to attack. For example, if PDF isn’t used in the enterprise for purposes other than reading manuals, why use Adobe Reader? Foxit Reader or any of the Open Source apps will work.
• Finally, disable all services and uninstall all protocols that aren’t required by the OS or necessary applications. The first things that come to mind here are UPnP and the SSDP Discovery Service and the Net.tcp Port Sharing service.

That will give us a clean desktop setup with a significantly lower attack surface; come to think of it, you should probably go check the servers, too.

If I’ve missed anything, let me know.

I’ll Say it Again—Turn Off the Remote Web Management Interface!

I don’t know how many times I’ve told people that the embedded management interface on most devices is a security breach waiting to happen. I just got wind of some news, but can’t seem to find anything more than this mention. As soon as I dig up some details, I’ll let you know. This exchange is from Security Now! Episode 206 for July 23, 2009:

Steve…Stanford security lab….will also be showing some very distressing news this weekend at the Black Hat conference. They tested 21 different devices from 16 different manufacturers. These are web-enabled gizmos - webcams, printers, network switches, photo frames, VoIP phones, remote management tools, all of these things - and, like, consumer routers, all of these things that are web-enabled, meaning that like so many peripherals now, they’ve got an Internet connection and a web interface. They tested the vulnerability of 21 devices made by 16 different manufacturers. There was not one that was not vulnerable to serious web-oriented problems. For example, they were able to enter JavaScript commands into the logon prompts.

Leo: Oh, boy.

Steve: And the device logged the log-on attempts. So when the administrator brought up the log, the act of displaying the log replayed the JavaScript commands…And that allowed the commands to connect to a remote server and download malware. They said that among the worst devices were network attached storage devices. They enumerated five different classes of attacks, and they said that the NAS…were vulnerable to all five classes of attack. For example, you could rename files to JavaScript strings. There was no control over file naming in these. And of course we all have long filenames now in our state-of-the-art file systems. Well, long meaning JavaScript. And so anytime this device attempted to display the filenames on a web page, again, you were running JavaScript. So now there’s scripting running in your directory listing, which is displayed on a web page, causing your browser to do whatever the JavaScript has said. And it’s running in the local context. So even systems that have security saying don’t allow remote sites to execute script, but of course we trust our self, well, now we can’t trust our self.

Don’t tell me I didn’t say so. Turn that interface OFF!