According to an article published last week, it is apparently possible to construct a signed PDF that can have its underlying data changed such that the signature is still valid, but the presentation of the data is changed.  It’s a neat trick, but there are a few things that mitigate the risk inherent in the vulnerability:

1. The signature has to be applied to a carefully crafted PDF file.   A PDF file that you create and sign is unaffected by this attack;  if you examine the data within the file, the presentation data for both the “recommendation” and “order” documents is present in both.  Obviously, you will not be adding rogue data into your own PDFs before signing them.
2. As stated in the article, it’s not really clear that the PDFs used in the proof of concept are syntactically valid PDF files.  However, Acrobat does open and display them as the attack intends, so that may be irrelevant.  Although, an Acrobat security update could fix the issue if this is the case.
3. It appears as though, by looking at the proof of concept documents, that the special construction of the PDF requires precise byte positioning in the file for the various objects used in the attack.  It is not mentioned in the article, but it may not be true that such a document can be constructed with a blank signature field that can be signed in Acrobat and subsequently attacked using this method.

It will be interesting to see what, if any, response Adobe has to this publication.  I know my way around the PDF standard (as it pertains to digital signatures) fairly well, but I’m by no means an expert.  It seems to me, though, that this attack requires several things, including the execution of the initial digital signature, to be performed in a precise way, which may mitigate the risk of the attack working in a real-world scenario.

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.

Details of this month’s Patch Tuesday updates here:  http://www.microsoft.com/technet/security/bulletin/ms10-jul.mspx

This month, we get a fairly light load of patches for Windows and Office, but there are a few remote code execution vulnerabilities that are addressed.  So, if you run Windows and/or Office, apply these patches as soon as possible. If you’re running Windows XP or Windows Server 2003, you should address these patches post haste, as there is a code execution vulnerability affecting the Microsoft Help and Support Center that is currently being exploited in the wild. (http://www.microsoft.com/technet/security/bulletin/ms10-jul.mspx)

Also, don’t forget to restart your system when the updates are finished installing – don’t be lazy like me and hit “postpone” too much!

Applications, specifically web applications, often rely on e-mail to send out error reports to administrators and developers.  While e-mail can be somewhat unreliable in terms of delivering messages in a timely fashion, it is also insecure.  If your application’s error reports contain identifying information about users or sensitive details about your code and what made it break, you should be delivering these messages using encrypted S/MIME e-mail.

This tutorial will show how to send an encrypted message from a .NET application. Read the rest of this entry »

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.

This week, I registered for the next Document Interop Initiative (DII) workshop being held at Microsoft. (Details here)

The meet-up is centered around the new XML Advanced Electronic Signatures (XAdES) support in Office 2010. In my opinion, this is a great step forward for Office’s digital signature support, as XAdES provides the appropriate XML schemata to embed timestamps, revocation information and countersignatures within a digital signature on a document. Timestamp and embedded revocation support are two of the chief advantages that Acrobat digital signatures have held over Office for the past several years. Finally enabling this functionality will allow Office to compete with Acrobat on a more even playing field in terms of allowing robust, more auditable signature workflows.

I’m interested in seeing what updates, if any, have been made to the Office digital signature interface to support this new functionality. In current and previous versions of Office, digital signature validation, from a UI perspective, has been abysmal. There has simply been no way to determine *why* a signature is judged as invalid by Office when there are myriad possible causes for such a failure. For example, a signature may be invalid due to an altered document, which is far more of a concern than a signature being invalid due to revocation data being unavailable because the validation was performed offline. These circumstances can lead to different trust levels from the user.

It remains to be seen how well the XAdES support is implemented, but I’ll tentatively state, sight-unseen, that this is at least a step in the right direction.

Everyone has their browser of choice; mine is FireFox, because of its level of extensibility and huge collection of user-created add-ons. There are many useful add-ons that deal with security. Here are 4 that deal specifically with SSL and certificates, and two that are just useful in general.

Export All Certificates
This add-on allows you to export all of the trust roots from Firefox in one operation. I can’t really think of a situation where this would be extremely useful, but it may be convenient for testing purposes.
https://addons.mozilla.org/en-US/firefox/addon/141504

Conspiracy
This plug-in adds some UI next to the SSL icon that shows the country of origin for the root certificate that issued an SSL cert.
https://addons.mozilla.org/en-US/firefox/addon/107867

CipherFox
Displays the current cipher and key size in use for an SSL session, and allows you to disable RC4.
https://addons.mozilla.org/en-US/firefox/addon/8919

Expiry Canary
Adds a UI element to FireFox during SSL sessions that warns you if the site’s certificate is near expiration. I can see this being useful if you manage multiple web servers, and need to debug SSL certificate problems often.
https://addons.mozilla.org/en-US/firefox/addon/8717

Flashblock
Flash is somewhat notorious for being insecure, so it’s probably not a bad idea to kill it altogether, and whitelist the flash content you want to allow. Flashblock lets you do that.
https://addons.mozilla.org/en-US/firefox/addon/433

NoScript
JavaScript isn’t always bad – a lot of web sites require it in order to function correctly, including just about any site that uses AJAX or other dynamically presented content. However, it can be exploited in attacks such as cross-site scripts and clickjacking. Disabling scripts is one of the best ways to secure your browsing experience, and NoScript allows you to do so while whitelisting sites that you trust.
https://addons.mozilla.org/en-US/firefox/addon/722

Last week, Google labs released a new free web analyzer tool called Skipfish (project details here). I haven’t had a chance to play with it yet, although I hope to soon, since I have a new web application almost ready to go live.

Skipfish appears to support a ton of features, such as “Multiplexing single-thread, fully asynchronous network I/O and data processing model that eliminates memory management, scheduling, and IPC inefficiencies present in some multi-threaded clients.” Which, although I only barely can understand it, sounds very impressive. The vulnerabilities scanned for include:

High risk flaws (potentially leading to system compromise):
Server-side SQL injection (including blind vectors, numerical parameters).
Explicit SQL-like syntax in GET or POST parameters.
Server-side shell command injection (including blind vectors).
Server-side XML / XPath injection (including blind vectors).
Format string vulnerabilities.
Integer overflow vulnerabilities.
Locations accepting HTTP PUT.

Medium risk flaws (potentially leading to data compromise):
Stored and reflected XSS vectors in document body (minimal JS XSS support present).
Stored and reflected XSS vectors via HTTP redirects.
Stored and reflected XSS vectors via HTTP header splitting.
Directory traversal (including constrained vectors).
Assorted file POIs (server-side sources, configs, etc).
Attacker-supplied script and CSS inclusion vectors (stored and reflected).
External untrusted script and CSS inclusion vectors.
Mixed content problems on script and CSS resources (optional).
Incorrect or missing MIME types on renderables.
Generic MIME types on renderables.
Incorrect or missing charsets on renderables.
Conflicting MIME / charset info on renderables.
Bad caching directives on cookie setting responses.

Low risk issues (limited impact or low specificity):
Directory listing bypass vectors.
Redirection to attacker-supplied URLs (stored and reflected).
Attacker-supplied embedded content (stored and reflected).
External untrusted embedded content.
Mixed content on non-scriptable subresources (optional).
HTTP credentials in URLs.
Expired or not-yet-valid SSL certificates.
HTML forms with no XSRF protection.
Self-signed SSL certificates.
SSL certificate host name mismatches.
Bad caching directives on less sensitive content.

Scanning my new application with this tool will, I’m sure, turn up about a hundred bugs I haven’t even thought about yet. But, that’s better than sticking my head in the sand and pretending nothing’s wrong, or worse, having to deal with any vulnerabilities after they’ve been exploited.

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?

The internet is full of unsavory characters who want to steal your personal information and/or money. This has been widely accepted for quite some time. Recently, some good articles have appeared online regarding what to do if you think you’re being scammed, especially by pop-up ads that look like anti-virus software (http://www.fbi.gov/pressrel/pressrel09/popup121109.htm, http://voices.washingtonpost.com/securityfix/2009/09/what_to_do_when_rogue_anti-vir.html).

While these articles focus on what to do if you’re hit with such an attack, I’d like to present a few rules of thumb that I use whenever I see any type of message that looks suspicious, whether it is from a pop-up ad, e-mail or letter that purports to be from my bank, or even an unexpected phone call from someone claiming to be from a company where I hold an account.

1. Am I being asked for personal details?
   If an incoming message of any type, be it e-mail, pop-up, or phone call, is asking you for personal information or, especially, passwords, then there is a near 0 chance that it is legitimate. Disregard the message immediately.
2. Does the message sender look familiar?
   If you receive a virus notification pop-up that looks like it came from Norton Anti-Virus, and you do not have that product installed on your computer, it’s probably not legitimate. Similarly, if you receive an e-mail from PNC bank and do not have an account there, you can assume the same thing.
3. Is the message informing you of an unexpected change?
   For example, if you receive an e-mail from a financial institution that their web site URL has changed, this is immediately suspect. This is a very rare occurrence, and when it does occur, you will usually be informed by postal mail in a message that conveys the sender’s authenticity. For example, a bank may send you a notice of change that requires no action on your part, and lists your name, address and account number on the letter. If the sender already has information like this, then there would be no need to scam you in the first place.
4. Was I expecting this message, or is the message benign?
   If you receive a message containing expected or benign information, such as a notification that your statement is available, there’s likely no reason to worry. Generally this sort of notification doesn’t even ask for any action on your part.
5. Does the message make you afraid?
   Generally, any unsolicited message that tries to scare you into performing an action you otherwise wouldn’t, such as entering credit card information or revealing a password, by threatening financial loss (in case of phishing) or data loss (in the case of false virus pop-ups), should not be trusted.

   For virus pop-ups, if you are afraid that you have malware installed, disconnect from the internet, shut down and restart your computer, and run a virus scan using anti-virus software that you installed. If you do not have anti-virus software there are plenty of available free options, such as Microsoft Security Essentials. The information in the links above is also quite helpful for this situation.

   For phishing e-mails, do not click on any links in the message. Instead, manually open a browser and navigate to your bank’s web site manually to log in. Alternatively, look up your local branch’s phone number in a phone book and call them during business hours. (Don’t trust any phone numbers listed in the e-mail, either!)

   For suspicious phone calls, do not reveal any information to the caller. Hang up the phone, and call your bank or credit card company using their public phone number and ask to speak to a representative to confirm what you were told.

This is by no means an exhaustive list. These are the top items in my mental checklist for validating unexpected messages I receive through any medium. When in doubt, do not trust the messenger – hang up the phone/close your browser/shut down the computer and verify what you’ve been told in a way that doesn’t rely on the information you’ve just been given.

Feel free to leave some of your own rules in the comments!