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.

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.

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.

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!

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.

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!

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!

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.

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.

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.

DLP or Data Loss Prevention is not one tool, but a set of tools that allows management to watch, prevent, and react to any “sensitive” data being where it should not be, or being transmitted in a non-permissible way (i.e. unencrypted). There are three main parts to DLP:

• Data in Motion – network traffic, anytime data is being transferred from one place to another.
• Data in Use – when users are actually *using* the data, such as in memory
• Data at Rest – when the data is being stored, such as on a hard drive or on removable media

A DLP solution has to consider all of these. Some companies may choose to only implement one type of DLP based on their threats and risks.

DLP solutions typically start with a definition of what is “sensitive” data. A social security number or a credit card number is pretty easy to pick out of “random” data. A trade secret – not so much. This is probably the most difficult part of the process, and continual refinement is necessary to a successful solution. Second, management must define what uses are acceptable and not acceptable for that data. Is it OK if that data is sent via encrypted e-mail, but not uploaded to a web page? These two pieces of information make up the policies or rules that the DLP solution must enforce.

Once sensitive data is defined, the solution must start looking at the data. Generally, for data in transit, this is done with proxies – web proxies, FTP proxies, e-mail gateways, etc. The software sniffs all traffic and flags those that are in violation of the “rules”. Data at rest DLP solutions tend to use agents that look through file servers and disks for the data and flag anywhere it finds the data that it shouldn’t be. Data in use is generally found on end-user systems as an agent that prevents you from copying files to a USB device, etc.

Finally, management has to decide what to do with offenses. Does the DLP system just flag the offense? Does it prevent the offense? Who does it report the offense to? What happens to the user who offended the system? These are all policy questions that must be addressed in parallel with implementing a DLP solution.

DLP is a hard problem to solve. There are many difficult choices and issues to be addressed that are more than just “what software do we use”. A full evaluation of your goals up front will help you select the “right” implementation for your organization.