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!

Many people have used OpenVPN for a simple and effective VPN solution, but did you know that you can use it for real two-factor VPN authentication? How you do that depends on the two-factor solution you are using. There is support for PKCS11 token stores, and Windows CAPI, with patches submitted for OS X’s Keychain. In order to get the OS X patch into the testing/stable branch of OpenVPN, it needs more testers though (please help!). So, if your token supports one of the above, and most do, you can use OpenVPN as a (relatively) inexpensive two-factor VPN. The tokens are still rather expensive however

To use the CAPI functionality, add cryptoapicert “thumbprint” to the client’s command line or configuration file.

To use the KeyChain functionality, add keychaincert “thumbprint” to your configuration file or command line.

In both cases, thumbprint needs to be in quotes and is the MD5 or SHA1 hash of the certificate to use.
ex. “MD5: f8 72 98….”

To use the PKCS11 functionality, you use two options:
pkcs11-providers /usr/lib/pkcs11/ (or other path to the pkcs11 library)
and
pkcs11-id ‘serialized id‘
Where serialized id is a unique serial number that you can find by using the “openvpn –show-pkcs11-ids /usr/lib/pkcs11/” command

You’re now all set up to use two-factor authentication with OpenVPN on multiple operating systems. OpenVPN has more detailed information on the PKCS11 functionality at the HOWTO.

For a while now, CAPICOM has been declared deprecated by Microsoft, as it is only implemented in 32-bit, with no plans to roll out a 64-bit version. Microsoft’s Official Recommendation for replacing CAPICOM is to “use the .NET Framework to implement security features”. This is a fine solution for desktop applications, server-side code, web services, and a whole host of other applications. However, there doesn’t seem to be any equivalent support for the functionality the CAPICOM ActiveX control enables within a browser.

The client platform Microsoft wants you to use to run client code in the Browser is Silverlight, a browser add-on similar to Flash or ActiveX. Silverlight uses many of the .NET APIs; however, the support for the System.Security.Cryptography.X509Certificates namespace does not include support for the X509Store class (i.e., how you would enumerate the user’s digital certificates). Nor is there any support for the System.Security.Cryptography.Pkcs namespace, which would allow PKCS7 signatures and encryption to be executed within the browser. Both of these functions are available in the full .NET libraries, just not within Silverlight.

ActiveX as a technology is still alive and kicking, so it seems like the only way around this deprecation (and the corresponding corporate aversion to using CAPICOM) is to roll your own ActiveX control that replicates the functionality you need, using CryptoAPI calls. While not particularly difficult to do, it’s far more likely to introduce bugs and security holes in your application via home grown code than by using something as tried and tested as CAPICOM.

Now, there’s a possibility that I’ve missed something here, and there is still a way to enumerate certificate stores and perform signatures within the browser while not using CAPICOM. If so, please tell me what it is.

With the release of OpenDLP, more and more people are hearing about DLP. What is it and how does it work?

Fundamentally, security is about protecting important data – whatever that data happens to be – a formula, a trade secret, social security numbers, etc. We have all kinds of tools and techniques to help us encrypt and protect our data from someone outside of the company, but what about from people inside the company, people who go against company policy and use gmail, rapidshare, or other convenient tools to let them work at home or on the road? While seemingly innocent, these users are the ones that can cause the most problems.

(more…)