AntiXSS is an open source .NET assembly available for download from Microsoft (source here).  This library provides much more flexible XSS protection in .NET applications than the built-in Server.HTMLEncode() approach, as it adds support for XML and LDAP filter encoding in addition to HTML encoding.  By allowing flexible and secure encoding and decoding of strings for these types of data, application developers can breathe a little easier when accepting data across trust boundaries.

Libraries such as AntiXSS that perform string processing are incredibly useful for developers, for several reasons.  First, they are maintained separately from your code base, so any updates to the string processing functions for emerging threats can be applied without much hassle.  Second, by using a code library with a wide user base and is regularly maintained with updates from the developers, the risk of a security hole from a bad implementation is much lower.  Finally, it’s free – and your time developing custom string processing code is not!

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.

MD5 is a hashing algorithm created in 1991 and still used by many applications for certain features. But MD5 is no longer recommended for many cases due to weaknesses discovered in the last few years, opening up some scary possibilities. At the end of this year, NIST standards for cryptography used by the federal government will no longer permit 160-bit SHA1 hashes or 1024-bit RSA signature keys, since concerns over the long-term security of these technologies are rising.

With cryptographers constantly working on new algorithms and breaking old algorithms, one may get nervous about whether the foundations of today’s secure transactions are really that secure. But despite the occasional ominous forecast of a cryptographic meltdown, you can remain fairly confident in encryption technology.

Just as we’re constantly finding new weaknesses in various approaches, we’re constantly finding new approaches that overcome various weaknesses. For instance, scientists are working to develop “quantum computers” that perform calculations in a completely different way than today’s electronics. These new machines would be powerful enough to crack several of the strongest algorithms currently in wide use. But just this week, several researchers demonstrated that a 30-year-old algorithm, using a different type of mathematical basis, would foil any known quantum attack. This approach has not been widely used due to large key sizes that would hinder performance, but computers are getting faster every year.

Cryptographers also work to maintain a gap between theoretical attacks and practical compromises. NIST does not wait for programs that can crack any key within seconds before deprecating an algorithm. Researchers are constantly working to build stronger systems, and often start recommending replacements when only the slightest cracks begin to show for a particular approach. Also, one type of weakness does not necessarily ruin every possible use of a given encryption method.

But while the mathematics behind today’s systems may be sound for the near future, strong encryption alone does not guarantee you security. In fact, most security problems come through either insecure implementations of a given approach or bad security practices built on top of strong algorithms. Keeping current with effective cryptography is important, but it’s only one part of an effective security strategy.

Risk assessment gets a bad rap these days, thanks in large part to a checkered past colored by qualitative analyses. Historically, risk assessments have been fuzzy, at best, and down-right inaccurate and misleading at worst. You know the ones I’m talking about: some hot shot consultant comes in, pokes around, maybe runs a couple scans, and then churns out a report with a bunch of High, Medium, and Low findings. However, as you dig into the results – particularly the so-called “High Risk” findings – you start finding extreme squishiness with no connection to reality, rational thought, or logic. And this is what we’re supposed to use to “better manage” security? Don’t think so…

Enter Factor Analysis of Information Risk (FAIR), a different sort of beast altogether, created by Jack Jones of Risk Management Insight (RMI). FAIR is a decision support tool that provides a means for performing a quantitative risk analysis around a given scenario. It allows you to conduct deep analysis into given asset+threat scenarios, digging into the business to arrive at accurate estimates (via ranges) for probabilities and expected losses. Loss events are divided between primary and secondary, wherein primary losses are often fairly well known (e.g. how much it costs to replace a server), whereas secondary losses can vary widely.

For an excellent introduction to FAIR, the RMI white paper “An Introduction to Factor Analysis of Information Risk (FAIR)” is highly recommended. In it, you’ll start to see the breakdown of FAIR into its component pieces. Overall, within the context of FAIR we define risk as a derived value measuring “the probable frequency and probable magnitude of future loss.” There is much that can be said about this definition and overall approach, but I’ll leave that for another day. In the meantime, I encourage anybody with an interest in risk analysis to take a deeper look at FAIR.

Every year during the Black Hat conference, something crazy happens that makes me paranoid about things I use during my everyday life without really thinking too much about it.  Last year, it was the MD5 Collision Attack that allowed the attackers to create a rogue Certification Authority. This year, it’s ATMs.  A researcher by the name of Barnaby Jack developed his own custom rootkit for ATM machines that could be installed by dialing into the devices and exploiting the remote management software.  This rootkit allowed him to make the machines dispense money on command, which, I’m reasonably sure, is not how they are intended to function.  Lest you think this only allows the attacker to steal from the device and not from your account, he also developed custom firmware for the machines that can record account information from its users.

These types of inventive techniques are discussed at Black Hat every year; there seems to be no end to the ways technology can be exploited for less than noble intentions.  As security professionals, it makes our job a constant uphill battle.  But, it also serves as a reminder that all of us – not just those of us that work in this field – need to be mindful of how technology fits into our lives.  There’s an off chance that the ATM hack may wind up hitting you at some point – there’s not much you can do about that.  But, you can take the time to check your account balances to look for irregularities as often as you’d like.  It’s not a perfect solution, but short of putting all of your money in a mattress, it’s at least a step in the right direction.

For authentication, newer versions of Oracle (11g+) use a session agreement and key exchange scheme known as O5Logon. It has some of the same weaknesses of authentication as the O3Logon used in previous versions of Oracle.

An example transcript of the default auth process:
1) Client connects to Server:
2) Client sends Username to Server
3) Server generates a ServerSessionID and encrypts it with AES. The key is the PasswordHash. It sends this encrypted ServerSessionID and the PasswordSalt to the Client
4) Client tries to generate a password hash using the PasswordSalt and the provided password. It decrypts the ServerSessionID using this ClientPasswordHash
5) Client generates a ClientSessionID and encrypts it with AES. The key is the ClientPasswordHash. It combines ServerSessionID and ClientSessionID to make another key which it uses to directly encrypt the provided password. It sends this encrypted password and encrypted ClientSessionID to the Server.

A more in-depth breakdown of the steps involved can be found here.

So, although there is a lot going on, the password itself is never really sent in clear text. This scheme also prevents against replay attacks, since the session IDs are different each time. The drawback is the fact that capturing all of the transmissions can allow an attacker to brute force the password in an offline environment. This is possible because guessing the hash will allow an attacker to simply decrypt the password sent from the client by sniffing the transmissions and comparing them later.

I think it’s possible to gain the same reply protection without exposing the password like that, but it would almost certainly take more steps. This scheme was probably designed to be very fast while providing protection against the most common attack scenarios. In comparison, TLS-based authentication is an alternative to O5Logon for Oracle, and does all sorts of cert. exchanging and flippidy floppidy. It provides better protection, but at the potential expense of being overkill if you just want decently secure authentication, and I think that’s one reason it’s an option instead of the default. In general, O5Logon is fine if the user chooses a strong password. As usual, the most critical link in the security chain is the individual.

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

There’s no need to go and reinvent the wheel when coding. Many good developers will have a plethora of custom or public libraries of code to do all the functions they need. One area where this type of stockpiling code really shines is in security APIs. For the longest time I’d followed Microsoft’s Enterprise Library, specifically for its security namespace. Being a .NET developer primarily this was all good.

But lately I’ve been branching out my coding endeavors, as well as watching the Microsoft Enterprise Library continue to grow; A little too large for my taste as of lately. This is where the OWASP ESAPI (Enterprise Security API) comes into play.

It’s fairly lightweight, supports many languages, and is a set of foundational security controls that developers don’t have to keep remaking over and over.

Allowing for language-specific differences, all OWASP ESAPI versions have the same basic design:

• There is a set of security control interfaces. They define for example types of parameters that are passed to types of security controls.

• There is a reference implementation for each security control. The logic is not organization‐specific and the logic is not application‐specific. An example: string‐based input validation.

• There are optionally your own implementations for each security control. There may be application logic contained in these classes which may be developed by or for your organization. An example: enterprise authentication.

I’ve just recently started using the ESAPI, but do have a history with some of OWASP’s other projects. I’d advise anyone looking to lock down some of their controls and ensure they have the proper guidelines in place to take a look at the ESAPI from OWASP.

A few months ago, I described how the Firefox add-on HttpFox could be used for basic traffic monitoring. Another helpful add-on that complements nicely with HttpFox is called HackBar.

HackBar adds a toolbar underneath the main address bar that can be toggled on or off with the F9 key. When enabled, the toolbar provides a miniature console of sorts for various testing tasks. A resizable textbox gives you plenty of room for editing URIs, and you can also issue POST requests or spoof the referrer. Menus across the top of the bar provide common functions for working with different types of data, such as hash algorithms or encoding and decoding in Base64, URI format, and even hexadecimal.

Using HackBar has its limits, and for comprehensive penetration testing you’ll probably need better tools. But if you just want to poke around a web application or send a quick POST request, HackBar is pretty handy to have around. Combined with HttpFox, you may be surprised at how much testing you can accomplish right in your browser.

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

I recently had a project to help spec out a DLP project for a customer from a high-level perspective. Having never done anything with DLP previously I embarked on a research mission. What I found was interesting. There’s not much out there on the intarwebs. As such, I thought I’d offer a few quick suggestions, just in case you want to go research solutions, too.

1. Start with Securosis! Their reports are freely available, comprehensive, and more informative than anything else I found.
2. Search for Gartner and Forrester reports. While these analyst firms charge for their reports, vendors will often post them for free. Specifically, try these search strings:
   • “forrester wave content security suites”
   • “gartner magic quadrant data loss prevention”
3. Beware DLP (as in Digital Light Processing) from Texas Instruments. You might need to use advanced search functions to -television -TI and so on.

Happy hunting!