In general, Windows does a decent enough job with securing software keys in CAPI. Sure, you can open up Windows Explorer, browse to C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, and take a look at your private key files. These bare files, of course, are not exactly plain text. The RSA Machine Keys (which include private keys corresponding to software certificates), are encrypted using the Data Protection API (DPAPI).

The DPAPI encryption method is based on the use of a Master Key – a 512 bit random blob that is created using PKCS #5 Password-Based Key Derivation. This process takes the user’s account password, applies the SHA-1 hash algorithm, sends the hash plus a salt to the key derivation algorithm, and then iteratively calls another PKCS #5 function at least 4000 times to make brute-forcing the secret key even harder. Et Voila! Master Key.

The Master Key is then used to create session keys by generating 16 bits of random data, hashing that with the Master Key, optionally appending the result with entropy data and the user’s password, and passing that blob into a few CryptoAPI calls to derive a session key. This session key is used to encrypt the actual data.

Whew!

This process actually does a very good job of securing key files such that, if you got a copy of the key files as they exist on disk, you’d have a difficult time brute-forcing your way into the software key data. They’re basically useless unless you have an utterly stupefying amount of disposable processing power. However, for as strong as the key protection is, it’s just software.

A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever”, said the old lady. “But it’s turtles all the way down!”
-Stephen Hawking, A Brief History of Time

That’s essentially what software keys are protected by – software, all the way down. Well, that’s not completely accurate. It’s software all the way down except for the mythical final turtle, which is our old friend, the password!

Now, I’m not suggesting that I know how to crack DPAPI, even if I do know a user’s password…that is, unless I have physical access to the device. Then all I’d need to do is log in, and Windows conveniently will take care of the rest, and allow me to use the keys however I see fit. (Un)fortunately, I don’t actually even need that to unlock a software key. All I need is a way of impersonating the user’s logon session, whether through remote desktop, exploiting Windows vulnerabilities, installing a rogue ActiveX control, or any number of countless ways to get a user to run some code.

So, how are we supposed to protect our private keys, then? Well, the simple and pretty inexpensive answer to that question, is Hardware Tokens. You can get a good FIPS-140 validated cryptography token for about $50-100, which will generate keys on the device, and the keys will never, ever be available to software (all cryptography operations are executed on the token). The tokens are tamper resistent (all memory is destroyed if the token is tampered with), and brute forcing won’t work, either (after a set number of failed logins, the token is locked and, optionally, all data is wiped). Now, this isn’t necessary for some applications, but if your encrypted data is worth more than $50 to you, why would you want to protect it with something as flimsy as a password?

Message Authentication Codes (MACs) are special pieces of data used to prove the authenticity and integrity of a message– to show that the message originated from a certain source and that it has not been modified. Consider a scenario in which Alice wants to send Bob an email. Upon receiving the email, Bob would like to be fairly certain that Alice was indeed the author and that the letter hasn’t been changed. When creating her email, Alice needs to have some technique that satisfies Bob’s concerns.

• First, she appends a secret word to the very end of the message. This secret word is only known by Alice and Bob.
• Next, she creates a unique “footprint” of her email by running it through a hash function (along with the secret appended at the end).
• Finally, she sends the original message (sans the secret word) to Bob. She also sends him the digest/hash/footprint.

When Bob gets the message:

• First he adds the secret word to the very end of the message (just like Alice did).
• Then he runs the message + secret through the exact same hash function that Alice did.
• Finally, he compares the resulting “footprint” with the one Alice sent him. If they match, the he can be confident that Alice sent it (since she’s the only other one who knows their secret) and that the message hasn’t been tampered with (since any change in the message would result in a different footprint).

This is almost identical to the way digital signatures work. However, MACs rely on a shared secret and, therefore, aren’t inherently based on public key theory. In addition, digital signatures are able to establish non-repudiation, which is not the case with MACs. In the above example, Bob could create an email from Alice to himself and Alice would not be able to prove she didn’t send it using just the MAC.

For this reason, MACs are most commonly used for inter-system communication. Webservers, specifically, make use of MACs to protect against cross-site request forgery (CSRF) attacks.

However, a common misconception with creating MACs is that any strong hash function alone is sufficient when creating an effective MAC. In reality, MAC-specific algorithms are designed to address some weakness with recklessly using block-level iterative hash functions (MD5, SHA, etc) concatenated to some shared secret. Specifically, the use of a Hash(message || secret) approach is susceptible to attack since someone could use information on known message/hash combinations to construct a new, working message/hash. By using a MAC-specific algorithm, such as HMAC or CMAC, these weaknesses can be mitigated or avoided altogether. So if you’re ever in a situation where you could benefit from a hastily-implemented MAC, be sure to consider both its strengths and weaknesses.

Today Slashdot had a story about how a news story about an Australian transportation plan was broken early by a newspaper. The transport minister said the access of this information was akin to the newspaper trying to “pick the lock off a secure office and take highly confidential documents”.  What was the brilliant security plan that was supposed to be protecting this information?  The information was all stored on an unpublished URL with no security or authentication in place.

We in the security industry call this “security by obscurity“.  And it is not security at all. Read the rest of this entry »

FIPS stands for Federal Information Processing Standards, and is “run” by NIST. It is a set of standards that dictates how information is stored, processed, and managed in the federal government. It’s also leaked into the commercial sector through government contractors and the concept of “If it’s good enough for the government…”

Almost all of the FIPS standards are relevant to security. Ever hear of FIPS 197? It’s AES. A list of all FIPS documents is available through NIST, and if you’ve worked in information security, you’ve likely heard of at least 3-4 of them. The one I hear most often is FIPS 140-2. This is the standard for cryptographic implementation. An entire industry has grown up among independent testing laboratories that test a specific cryptographic implementation for compliance. And to feed that – the government won’t accept a cryptographic implementation unless it’s been certified. NIST issues a “certificate” and everything.

The FIPS 140-2 testing is quite rigorous, and until now was generally accepted as an “all clear to use” signal. There are some implementation problems that have just cropped up, and until someone knows what happened – bad testing, different implementation, etc., we won’t know if the FIPS testing program is broken or if it was just a bad apple.

An uproar was recently started in reference to some privacy concerns about the new release from Google, Google Buzz. One of the first to sound the alarm was a blogger who was quite explicit about disliking some of its default options (and by explicit I mean “NSFW language” explicit, the post is here) which prompted some quick changes from Google.  In order to start using Buzz, you have to create/modify your Google public profile which will appear next to all of your activity in the Buzz feed.  By default, the public profile would display all those you follow. Chances are you’ve followed everyone in your contact list, so you just made your whole contact list public.  Now in the new behavior:

A box titled “How do you want to appear to others” will now include a check-box that says “Show the list of people I’m following and the list of people following me on my public profile.” To hide your followers, click the box, or click the “View and edit the people you follow” to customize your account.

The interesting thing here to me is that Buzz is essentially a service like Facebook or Twitter, designed to let other folks know what you are up to.  The fact that there is a privacy uproar around it is somewhat amusing, because it is designed to provide the opposite of privacy – to provide your followers information about what you are doing.  If you don’t want to share this information, don’t use Google Buzz!

I’ll enlist a famous quote from Scott McNealy, then CEO of Sun Microsystems: “You have zero privacy anyway. Get over it.”

It is amusing to me what people – especially young people – are willing to post online.  As a child, my parents once told me that once you say something you can’t take it back.  In today’s Internet-connected age, this holds true and is even more significant: once you say something online, hundreds if not thousands of people will see it instantly, and potentially billions of people will be able to track it down in archives, Google searches, the wayback machine, or in countless other ways.  Be careful what you share online.  Be careful what you say.  It might–probably will–come back to haunt you.

When companies create security policies designed to keep their information secure, they are often most focused upon the threat of an outsider.  Certain measures, like using secure protocols such as SSL and TLS, or using S/MIME encrypted email can help keep your information from being viewed by third parties when it is sent over untrusted networks.  Other measures, like performing hard disk encryption on your laptops help keep your information secure when a laptop is lost or stolen, or a hard drive is sold on eBay.  None of these measures will help in the scenario of a trusted insider getting access to over 1300 documents that they have no business having.

According to the complaint, Jhaveri admitted being employed by Bristol-Myers-Squibb as a Technical Operations Associate from November of 2007 until his termination on February 2, 2010. The complaint further alleges that during his employment, Jhaveri stole numerous trade secrets as part of a plan to establish a pharmaceutical firm in his native India which would compete with Bristol-Myers-Squibb in various markets around the world.

How do you protect against the insider threat?  It is one of the more complicated issues of information security and there are a lot of opinions on how to deal with it.  Certainly it has to start with understanding what information you have which needs to be protected, how damaging that information could be if it were to be lost/stolen, and then making some cost/benefit analysis decisions on the best ways to protect it.  Everything from a rights management services type of solution to a strong security event and information management (SEIM) system could be useful in preventing and detecting insider threats.

The first night of ShmooCon is a wrap, at least for the presentations. First off, my shout-outs to all those that actually made it this year. The DC weather hasn’t been too kind to any of us, especially those traveling in specifically for this Con. But to those who made it, I salute you (even more so to those who had to walk a couple miles to get to their hotel because they didn’t make or take reservations at the Marriot).

Read the rest of this entry »

Nessus is a nice tool, but some people have complained and revolted against it because it went closed source in version 3.0. I’m sure there were good reasons for that, but if – for whatever reason – you don’t want to use Nessus, what can you use? Enter OpenVAS.

I’ve mentioned OpenVAS before, but version 3.0.0 came out in December, so I figured I’d give more details on it.

It’s a fork of Nessus 2.0, so if you used Nessus while it was still open source, it’ll be somewhat familiar to you. It still uses NASL for tests, so you can use some of those ancient vulnerability tests if you need to. It also has the same basic client/server architecture. You put the “server” on the network segment(s) you want to scan, and you can have the client pretty much anywhere that can talk to the server.

There is an “official” OpenVAS feed, but you can subscribe to any feed you want – including the Nessus feeds.

If you’re not used to working “under the hood”, then OpenVAS will seem like a huge change for you, but if you used nessus previously, you’ll just have to remember a few of the old things on the command line.

I haven’t used it on an assessment (yet), since we have a Nessus professional feed, but I’ve used it at home and have found it quite nice to use and might consider starting to use it for assessments.

We have recently taken a look at Internet Explorer 6 (IE6) to try and help convince a customer of ours to stop deploying it on workstations.IE6 still holds about 33% of the browser market share, but Microsoft stopped mainstream support for it in April of 2009.  IE6 runs ActiveX controls at the same privilege as the browser, which is the same privilege as the user – typically administrator level.  And according to Secunia there are 23 known unpatched vulnerabilities in IE6 – including one which has been around since 2003.

And in a timely post from Brian Krebs on his new site krebsonsecurity.com, there’s a very simple way to crash IE6.

If you’re curious and have IE6 lying around, type or cut and paste the following into the address bar (that last character is a zero):  ms-its:%F0:

So, what are we missing? Are there any other reasons I can throw at this customer to put IE6 out to pasture? Let me know in the comments.