• Art Coviello (RSA) believes that the emergence of cloud computing will be our opportunity as an industry to turn the way security is delivered inside out.
• Paul Maritz (VMWare) thinks the formula for embracing cloud computing is simple: improve efficiency, improve agility, improve security.
• Mark Benioff (salesforce.com) stated Lotus Notes was conceived before Mark Zuckerberg was; enterprise software needs to change, and become more like Facebook.
• As evidenced by having Brian Snow, NSA on the Cryptographers Panel: the commercial and academic communities still have a lot of distrust and suspicion of the NSA.

Other items I’ll be writing about: a lunch I had with F-Secure’s Mikko Hypponen where he discussed cyber crime, and a session I attended called “Winnovation- Security Zen through Disruptive Innovation and Cloud Computing”.  Stay tuned!

I would love to provide you a great tutorial on how to avoid many of the hardships that developers face, especially in security these days, but I don’t think I could do it better than the people over at the OWASP WebGoat project. It’s a web application that purposefully has many vulnerabilities right out in the open. The site is laid out with exercises for you to complete. It will offer hints, and even a full solution for when you get stuck. It even tracks your progress through a report-card like page showing how many times you’ve attempted an exercise, how many times you got help, and whether it was completed or not. You can grab WebGoat from OWASP.org directly and install it on your own tomcat server, or grab it in a fully enclosed environment through Dojo or OWASP Broken Web App VM. Either way you choose, I’d highly recommend either one. The VM’s provide much more on top of WebGoat but I feel the way the site is laid out and structured, it provides a very good tutorial-based approach to learning what not to do or at least learn what to avoid in your own applications.

You would think this would be an easily decided scenario; the digital signature is a superior and more trustworthy technology, right?  Well, not when you change the rules a bit. Basically they made the strength of process the inverse of the strength of the technology.  Here are the key points from today’s trial, and I’d like your suggestions on which one you’d pick.

• Will 1: Ink Signature: happened a long time ago, seems to be in order but there are no surviving attesters to the signature. Gives the entire estate to his wife, and if she predeceases him, his son.  As of today, the wife did predecease him, and his son has become estranged, will #2 being part of the reason.
• Will 2: Electronic Signature: signature is just a hash of the user name and the document being signed.  Gives 1/2 the estate to Stanford University, and the other 1/2 to his son.  The signature was not attested to by any other individuals.  There are no security controls over the log files and no way to prevent modification. However, everything seems to be in order with the signature.
• Will 3: Digital Signature: signature uses the internal PKI of a legal firm which stores private keys on USB memory sticks (not cryptographic devices). A paralegal of the firm who helped create the PKI process is the sole beneficiary.  The signature was counter-signed by two other individuals.  The paralegal (“Bubbles”) administers the PKI system and theoretically could have recreated signatures or digital IDs.

So, if you had to vote for one of these as a juror, which one would you choose?  Personally? I think all 3 are terrible and I fear the entire estate may need to go to probate.  Let us know what you would choose as a juror in the comments.

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?

• 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.

We in the security industry call this “security by obscurity“.  And it is not security at all. Security by obscurity is basically counter to Kerckhoffs’ principle which basically states “secrets do not remain secret, so the design–not the secret–must provide the security”. While arguments can be made in certain situations for withholding or obscuring information or processes, it cannot be the only thing protecting your private information.  I have seen security by obscurity practiced wrongly in these situations:

• The implementer does not have confidence in their security protections and controls.  Therefore, they protect the knowledge of whatever these controls are, hoping that they won’t be revealed. Ultimately these efforts usually fail, the weak countermeasures are discovered and exploited.
• The implementer believes that they have done something “new and improved” or “groundbreaking” when it comes to security.  Whether this is a brand new way to do encryption over wireless networks or a different way of authenticating users, it often would benefit of having a couple–or a few thousand–extra eyes look at it and check their work.
• The implementer or user feels a sense of safety because of their use of obscure or proprietary systems or protocols. For example, “nobody can crack my system because they would never expect someone to develop something in MUMPS that authenticated using the gopher protocol.”
• The implementer or user feels that the secret renders them invisible. The case above, an unpublished URL was no protection. Similarly, telling your wireless network not to broadcast an SSID, or using a username that isn’t related to your real name are attempts to hide information which generally won’t be successful.

And yet, there are some situations where security by obscurity is a useful thing–but only when combined with other efforts.

• Changing well-known usernames and network ports.  Why not stop automated attacks and script kiddies if you can?  I see countless failed login attempts on systems which expose the ssh port. Moving ssh to a non-standard port won’t stop a determined attacker from finding it, but it will stop the constant failed login attempts.
• Use non-default usernames for privileged accounts.  In a similar way, it is easy to try an exhaustive password attack against Administrator (Windows) or root (*nix), but may be harder for the attacker to realize that the Administrator account is actually disabled and the username used for administration is “gocrazy”.
• Do not expose information about system use and value. Naming your accounting server “accountingserver” and the system you keep your confidential information on “topsecretstorage” only helps your attacker.
• Change installation defaults. If you are installing a piece of software which might be an attack vector, try changing some of the installation defaults – change the directory structure, the name of configuration files, use non-standard environment variables, etc.

The above bits can help obscure key parts to help protect you, but those alone won’t protect you–whether your adversary is a newspaper seeking a scoop, or some other advanced persistent threat.  You still need to have a strong security policy, and concentrate on security at every phase of your development lifecycle. And/or <shameless plug>involve some others who can help</shameless plug>.

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.

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.

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.

Bruce Potter opened up with the event schedule and went on into his own little opening that had a common theme of “common sense”. He used the recent hiccups in the TSA as the base analogy. Basically the metric that we’re using to try and fix today’s security problems is solely based on the amount of money that we throw at it. Simply – the future looks grim if we continue the way we’ve been going.

Collin Brack kicked off the actual presentations with one titled: GPU vs. CPU Supercomputing Security Shootout. I was actually looking forward to this talk. Sadly, I was a little disappointed. I guess I was looking for some more in-depth technical slides or live demonstrations on how GPU vs. CPU compare. It was basically a link-filled slide hyping GPU. Nothing against Collin here, I’m sure it was a great presentation for those who had no clue that GPUs could be used for computation calculations, just didn’t have my vote. Key points: GPUs are great for many small calculations.

Larry Pesce, Mick Douglas followed up with “Information disclosure via P2P networks: Why stealing an identity via Gnutella is like clubbing baby seals”. This was a pretty good presentation. They showed what types of personal information they were able to find simply by parsing the P2P networks with a bit of command line scripting and mutella. It was entertaining and informative. Key point: careful with what you share on P2P, don’t share your entire C drive.

At this point I needed to stretch and take a small break, so I used this time to make my donation for my ShmooCon t-shirt. Also, I’m not entirely sure who or what the presentation was at this time. I thought I remembered Bruce mentioning one of the speakers not making it. And all the others were on the schedule, so this block was a blank to me.

I did return for Dan Crowley’s talk about “Windows File Pseudonyms”. It was a good presentation about the many different ways you could reference files without actually using a ‘C:\file.txt’ notation. Most involved some sort of ‘//’ notation or localhost network traversal. Some of this information I knew, but it was good to see it put to actual usage. He demonstrated with a php file upload attack exploiting file name safeties in the code. Key point: watch out for string comparisons for file checks, actually do a file/directory check for paths and files.

Doug Wilson’s “Learning by Breaking: A New Project for Insecure Web Applications” was probably the quickest presentation in ShmooCon history. I say this because as I stepped out for about 8-10 minutes figuring I’d come back just in time for the good stuff, the presentation was already over and he was taking questions. I was really kinda ticked at myself for this one as this was exactly something I was looking forward to seeing as I’ve attempted to set up my own WebApp test environments in the past. I’ll definitely be looking back over the recorded presentation for this one and checking out the site. Key points: Don’t be late for the presentations you WANT TO SEE!

“Guest Stealing…The VMware Way” by Justin Morehouse and Tony Flick brought to the surface an old attack involving a directory traversal vulnerability in VMware Server. They basically explained how they came across it, along with a live demonstration. It’s something that’s long been patched, but it was good to see it in action anyways. Key points: Patch!

The final keynote “Closing the TLS Authentication Gap” presented by Steve Dispensa and Marsh Ray was a very good look into the actual process of discovering a real (and major) vulnerability, and the process it takes to disclose this information in a timely and yet safe manner without simply dropping it as a 0-day for the world to engulf. They discovered many of the issues weren’t technical at all, simply getting vendors and companies to cooperate with what needed to be done. It was a great view into the process and something I think all of us should look into. It gives a good showing at how hard it is to be an actual White Hat.

So, the fun continues tomorrow at 10am EST – I’m beat from a long day and not looking forward to trudging back through the snow, but hey, it’s ShmooCon!