Fuzzing is a fairly recent term for what pen testers (and testers in general) have been doing for years – feeding invalid data to a program/web page/etc and seeing what happens.

When you wrote your first C program that had to take command line arguments – did you ever mash on the keyboard and see what happens? You were fuzzing even if you didn’t know it at the time. The old Christmas tree packet in networking was a sort of fuzzing.

Fuzzing can get kinda boring though, so there are several tools that will help you with it. They work on various kinds of inputs – some are for networks, some are for web pages, some are for the HTTP protocol, etc. You can generally find a fuzzing tool that will help you out. It will (generally) randomly select text or numbers that fit a designated format. For example – you tell it that you want strings that have at least 1000 characters, and you want to send it to this particular URL. It’ll fire up, start making random selections and give you the results to look at. Some of the tools are also smart enough so that you can tell it what an acceptable response is, and when to notify you.

Fuzzers can take down systems – if only because of a DoS that you didn’t expect and anticipate – however, if the developers aren’t very good, it can segfault the target. Also be aware of the network bandwidth you may be consuming, it’s usually all text, but if you’re sending a lot of it, it can be a lot.

Source

In early October, Microsoft will be making the Microsoft Security Essentials suite free for small businesses (i.e., fewer than 10 computers) in addition to home users.  This is a good thing – MSSE is a good suite of security tools, and the price tag is just right for individual and small business users.

However, has anyone ever read the language in the EULA for the tool?  The installer itself only checks that you have a genuine copy of Microsoft Windows before allowing the installation to proceed;  there are no license keys or anything to deal with.  The source article indicates that the types of business that will now be allowed to use MSSE for free already were using it anyway.  This may be true, but the speculated reason in the article (“Businesses of this size don’t purchase software when they don’t have to”), implies a knowing disregard for the rules. Personally, I had no idea that businesses couldn’t use MSE.  I thought that any licensed copy of Windows was eligible.

Still, I’m unsure why the small business allowance is so limited…10 computers is really small for any business doing IT work, although I suppose it would be more than enough for something on the order of an auto mechanic or doctor’s office.

Please join Gemini Security Solutions at AppSecDC 2010 where we will be delivering a 2-day “Software Security Best Practices” course based on the materials we support from KRvW Associates. The course is $1,495 and will run November 8-9 here in Washington, D.C.

Course Description:

This tutorial starts with a description of the security problems faced by today’s software developer, as well as a detailed description of how defective software can be exploited. It goes on to provide a thorough description of the best practices available to prevent, detect, and remediate security problems in software. Next, the tutorial includes hands-on design review exercises to reinforce each of the concepts presented, together with dozens of examples of common coding errors (primarily in C/C++ and Java).

http://www.owasp.org/index.php/Software_Security_Best_Practices

A new problem has been uncovered that allows an attacker to obtain encrypted session cookies or other encrypted/protected data stored on any version of ASP.NET from Windows XP to Windows 7 and 2008 R2.  When properly exploited, the attacker gets full administrative rights to the application and gets access to files such as the web.config file which often stores sensitive information and passwords.  From ComputerWorld:

Hackers can exploit the vulnerability by force-feeding cipher text to an ASP.Net application and noting the error messages it returns. By repeating the process numerous times and analyzing the errors, criminals can learn enough to correctly guess the encryption key and thus decrypt the entire cipher text.

It will take some time for Microsoft to patch this problem across all platforms.  It is possible to update your application to be immune to this attack, and I recommend patching your application as soon as possible.  From Scott Guthrie of Microsoft:

A workaround you can use to prevent this vulnerability is to enable the <customErrors> feature of ASP.NET, and explicitly configure your applications to always return the same error page – regardless of the error encountered on the server…

Important: It is not enough to simply turn on CustomErrors or have it set to RemoteOnly. You also need to make sure that all errors are configured to return the same error page.  This requires you to explicitly set the “defaultRedirect” attribute on the <customErrors> section and ensure that no per-status codes are set.

This link has detailed instructions on how to protect against this attack in each platform. Happy patching.

The “big” news of the week (thus far), if you can call it that, is Google’s announcement of the availability of soft tokens for Google Apps as of today (read about in their post “Moving security beyond passwords“). From a security perspective I’m greatly underwhelmed. Maybe I’ve just become jaded in my old age, but this really strikes me as a big “so what?” announcement. AOL did this several years ago (unsuccessfully, I might add) using RSA hard tokens. The reason for their failure is myriad, ranging from a lack of promotion to requiring customers to pay for it, but ultimately it came down to one specific concern: usability.

I don’t for a minute accept TechCrunch’s take on this announcement (see: “Google Is Making Your Account Vastly More Secure With Two-Step Authentication“). Sure, having 2-factor authN as an option is great, and is certainly better than just using a password, but let’s be very honest about something here: due to the resulting decrease in usability, how many people will actually opt into this solution? Also, let’s not also discount the relatively limited geographical applicability to this approach. For example, I travel from the US to Mexico last week, which caused me to not have access to mobile networks and, most importantly, TXT messages (SMS) due to exorbitant roaming costs. On travel in Mexico is probably where I would need the additional security of 2-factor authN more than at home in the US. And yet, to use the service, I would not have been able to make use of the service.

We also know from experience that users typically do not like having additional login steps, nor do they like having to wait for things like second-factor tokens to arrive via TXT/SMS or email. I know I hate having to wait when I login to banking or credit card sites today. How will this go over with Google? I’m guessing it will be largely ignored.

Instead of promoting old, tired practices like passwords and various manually-entered factors, I would have been much more excited if Google had announced an entirely new class of authentication mechanisms. Unfortunately, no such luck; and, until that happens, we’re stuck here in the land of the living and perpetually compromised. Back to the old mantra of “strong” passwords (or at least suitably long ones – 12+ characters, and forget about complexity rules as they’re generally less relevant today… oh, and don’t reuse passwords across sites!).

HP announced this morning that it would buy ArcSight. This follows Intel’s acquisition of McAfee last month. This isn’t the first time a large computer maker/systems offering has purchased a security company, but what does it mean for our industry? Will it mean that McAfee will only run on Intel computers (not that there are many others..)? Or that ArcSight will only be available on HP systems? Or will the companies operate fairly independently and we won’t see much in the way of changes for consumers (and businesses)?

I’m really hoping that the industry stays fairly open, allowing cross-platform interoperability between systems and products. It allows customers to select the best non-security system for their needs, and then allow them to select the best security product/offering for their needs. Contrary to what some people think – this is important in business. The business folks barely consider security when they spec out systems. The security folks are generally brought in later to fix things. As much as this is not the ideal situation, it *is* the situation in most cases, and until business processes improve, that’s the way it’ll stay.

Or maybe this’ll make businesses reconsider that?

OAuth is a protocol that lets applications request data or privileges you have on a remote service without you having to provide your credentials for that service. A classic use case for this “valet key” system is contact import – you can let a site load your address book from Gmail without giving that site your actual Gmail password. Twitter recently required that any third-party applications using their API must authenticate using OAuth.

Twitter’s implementation is based on OAuth 1.0, which was finalized in April but has been in development for several years and is already widely supported. But work on a new version is now under way, and Facebook has already implemented one variety of the draft specification for applications that connect to their service. OAuth 2.0 currently defines specific flows, or client profiles, for handling authentication: Web Server, User-Agent, Native Application, and Autonomous. The first two are most commonly used for web applications, and implementations of the third may end up being quite similar.

The process for most clients involves three broad parts. (Note that “client” in this context refers to the application seeking access, not the person using the application.) The first involves user authentication. For a web-based service, this will often mean ensuring the identified user is currently logged in and then asking for their permission to enable access if they have not previously granted it. Second, the client has to authenticate. In other words, the client making the request has to prove it is the same application that the user granted permissions to in the first step. If both of these steps complete without error, the client is given means to access the protected resources, typically with a temporary code known as an access token.

The specific details of how these steps happen depend on the client profile used. Facebook’s standard Graph API authentication is an example of the Web Server flow. When first requiring access to private user data, a third-party application will forward the user’s browser to Facebook’s authorization server. The request includes a public code identifying the application and a URI under the application’s control. Facebook prompts the user for the permissions and (if they are granted) redirects the browser to the provided URI, along with an authorization code. The client then makes a request directly to Facebook which includes this authorization code and a secret code identifying the client. Facebook then sends back an access token, which is used to authenticate specific access requests for the duration of the session.

The User-Agent profile differs in that it relies on a user-agent’s same-origin policy rather than a client secret for authenticating the client. This process provides OAuth capabilities for JavaScript-based applications that do not have a server-side component and thus cannot ensure identifying codes are kept secret.

Simplicity was a major factor in creating OAuth 2.0, and thus several parts of OAuth 1.0, such as signatures and nonces, no longer apply. However, OAuth 2.0 requires transport-layer security of TLS 1.2 at minimum (as of draft 7) for the interface used to request and receive access tokens. The spec also recommends that secure channels be used for other parts of the process. In Facebook’s implementation, all server interfaces are accessed via HTTPS addresses.

From a security perspective, OAuth is a good step in that it discourages the anti-pattern of one application requesting a user password for another application. It can also protect users in other ways; for instance, if someone intercepted the authorization code for a Facebook application, they would not be able to use it for data access without also obtaining the application’s client secret. However, OAuth only addresses particular issues with third-party access and should not be considered a silver bullet for security. As an example, access by Facebook applications vulnerable to cross-site scripting may still be hijacked once the application has been authorized.

While OAuth 2.0 is still in draft status, Facebook’s deployment makes it in wide use already, and we’ll likely see many more implementations in the months to come. The description above should help you understand the basics of how OAuth 2.0 works, but if you’re interested in further details, check out the full spec and Facebook’s specific authentication guide.

Teensy is an interesting device.

Not much larger than a quarter, the technology behind it is comprised of a micro controller and other associated electronics (memory, I/O, etc). The result is a very functional, yet flexible, USB thingamabob that can let people program their own logic to run their own routines, commands, and instructions.

Teensy was recently used in a unique demonstration of some interesting security implications that arise from exploiting the USB-to-OS trust relationship. By programming Teensy to identify itself as a keyboard, someone could trigger it to send automated keystrokes at will (or set via timer).

But this has been possible for years. In fact, for this example in-particular, it’s probably desirable for users to not have to do any real configuring to get their keyboard or mouse to work. Perhaps the underlying issue is that many vulnerabilities are introduced when trying to balance convenience with security.

But the flip side might be that real change is coming from the other direction. As technology evolves, it gives attackers more tools with which to express their creativity. A few short years ago, programming logic into a USB device like this might have cost a few hundred dollars of equipment and a good amount of coding, just to do something simple.

Teensy is dirt cheap and there is a software library already written for it. This makes it easy to jump right in and start making stuff because the barrier to entry for this vector has been lowered by better technology. As a tool, a device like Teensy offers potential that is only limited to what the creative individual can fit into the on-board flash memory module. In a way, the bad guys get new toys, while the good guys just get more stuff to patch, secure, and protect against.

And that’s not… a teensy problem.