Category Archives: Security

Future changes to the PCI DSS

The news last week was that the Payment Card Industry Data Security Standard (PCI DSS) will be changing soon. In particular, a director from MasterCard was quoted at a conference:

this encryption requirement is causing so much trouble for merchants that credit card companies are having trouble dealing with requests for alternative measures, he said. In response, changes to PCI will let companies replace encryption with other types of security technology, such as additional firewalls and access controls, Maxwell said. ‘There will be more-acceptable compensating and mitigating controls,’ he said.

This quote appears to suggest that there will be a significant alteration of the encryption requirement, section 3.4, which today reads:

Render sensitive cardholder data unreadable anywhere it is stored, (including data on portable media, in logs, and data received from or stored by wireless networks) by using any of the following approaches:
– One-way hashes (hashed indexes) such as SHA-1
– Truncation
– Index tokens and PADs, with the PADs being securely stored
– Strong cryptography, such as Triple-DES 128-bit or AES 256-bit with associated key management processes and procedures. The MINIMUM account information that needs to be rendered unreadable is the payment card account number.

However, Visa has communicated that they did not agree to change this requirement and has reiterated that there are already multiple ways that are acceptable to render cardholder data unreadable. Compensating controls for encryption of stored data will be included in an appendix in the next version of the PCI DSS, but it is important to note that compensating controls are only allowed for short-term and they must still sufficiently mitigate the risk associated with the PCI requirement with the same/better preventive force as the original requirement.

The planned changes to the PCI DSS are actually fairly minor, intended to clarify the existing requirements, and not less stringent.

Real compromise of RealVNC

So, you have a computer on the network and you want virtual terminal access. You install RealVNC and, blammo! Compromised by a bot trolling the net.

No, I’m not kidding. Bascially the RealVNC 4.1.1 server responds to a request for access without verifying valid options. In other words, if you send it a “let me in without a password” even if it never suggested that was available to you, it still lets you in without a password.

This is like a hotel clerk saying “Welcome to Chez VNC, we have a room for you on the 1st floor with a view of the parking lot” and you say “Thanks, I’d be happy to take that penthouse on floor 29 with a view of the bay” and that’s it, you’re in the penthouse without needing to know the manager or having some other special credentials.

Evil exploit bots love this sort of thing, for obvious reasons; they can just scan blocks of IPs and then take over any vulnerable service they find. The bottom line is you really should not run virtual terminal connections without using some other authentication system (beyond the password) and/or a secure tunnel/wrapper like SSH. This has always been a best practice, but now you have a critical vulnerability to add some spice.

And that’s not even the end of the story. James Evans wrote a rather blunt explanation of a related issue on the full-disclosure list:

RealVNC is distributed under the GNU General Public License. As such, the complete source code of RealVNC *must* be freely distributed. When RealVNC (the company) received notice of this flaw in their software, they were quite prompt in patching it. Such action is normally worthy of praise. Yet, in this case, RealVNC immediately took down the source code to their software. While this was probably done out of fear rather than malice, I believe it violates both the spirit and law of the GNU GPL. As we can see from the above, it is also not beneficial to security. I was able to rediscover this flaw using only binaries, and a little thought. Allowing for the benefit of doubt, I posted to the RealVNC mailing list, congratulating them on patching the bug so quickly and asking when the source code would be released. I received one reply from another user, agreeing that he would like to see the source, as it is under GPL. Upon returning the next day to check if there were any more replies, I was surprised to see the entire mailing list was deleted along with its archives. This is unfortunate, and it clearly neither prevents discussion nor promotes security.

Ouch. The source reportedly was back online by the next day…

More flyingpenguins

Whew. I just mowed through hundreds of spam comments.

I used to enjoy reading these crazy things as a sort of stream-of-conscious Kerouac-like review of our modern tendencies for consumption.

Call me crazy, but maybe someone should make this into performance art — read a spam filter to music and do an artistic interpretation of the messages:

stricken golf servicemen entrusting pads
oat sycophantic mortgages apprehensions
Teletext Jackie Seabrook contrition whacked pills
intoxicating geyser sandpaper Germania Amoco coriander treatise mortgages
home equity loan

Yeah, say it out loud man! Cool, daddy-o. Home equity loan…oh, home equity loan.

I admit it, I can sometimes really get into this stuff. I suppose I should dismiss everything but the sensible comments, yet there’s something oddly poetic and security-related in thinking about the hundreds of spam entries I get every day.

For example, remember the origins of public-key cryptography?

We know that secret communication still uses blind-drops and even steganography (someone posts a jpg on a free public site like flickr and then anyone else can download and decrypt), so there’s clearly intent out there. And we know that some serious time and money is spent listening to the noise from space. Wonder what would happen if we ran spam through some of the same analytics and filters. Would there be a hidden message? The meaning of life? Does it all add up to a magic number?

Maybe I’m just having too much fun thinking about it, when I could be out getting some sun like this little fellow:

Evil Penguineval

Ok, enough spam. I’m going to think about putting in some new controls.

Who invented public-key cryptography

I went to presentation yesterday where a speaker told the audience the tale of how the three guys from MIT invented public-key cryptography. You know, the RSA trio. I mentioned that they were not the sole inventors (hey, Diffie sits on the crypto panel at RSA for a reason) but was soundly shut-down.

After the presentation I did a little research to double-check and while I thought Diffie-Hellman and Merkle were important, I didn’t realize that another group actually pre-dated even their publication. It turns out that there is a paper from 1987 called The Story of Non-Secret Encryption written by James Ellis. This paper not only describes ground-breaking work done prior to Diffie-Hellman and Merkle, but it gives credit to Bell Labs in 1944 for helping instigate the modern public key cryptography concepts.

Source is available here: http://www.cesg.gov.uk/site/publications/media/ellis.pdf

A paper written by Clifford Cocks (November 20, 1973) called “A Note on Non-Secret Encryption” is also relevant.

Here’s a nice review of the actual history, as told by the Living Internet:

Ellis began thinking about the shared secret key problem in the late 1960’s when he discovered an old Bell Labs paper from October, 1944 titled “Final Report on Project C43”, describing a clever method of secure telephone conversation between two parties without any prearrangement. If John calls Mary, then Mary can add a random amount of noise to the phone line to drown out John’s message in case any eavesdroppers are listening. However, at the same time Mary can also record the telephone call, then later play it back and subtract the noise she had added, thereby leaving John’s original message for only her to hear. While there were practical disadvantages to this method, it suggested the intriguing logical possibility: there might be methods of establishing secure communications without first exchanging a shared secret key.

Ellis thought about this seemingly paradoxical idea for awhile, and while lying in bed one night developed an existence proof that the concept was possible with mathematical encryption, which he recorded in a secret CESG report titled The Possibility of Non-Secret Encryption in January, 1970. This showed logically that there could be an encryption method that could work without prior prearrangement, and the quest in GCHQ then turned to find a practical example.

The first workable mathematical formula for non-secret encryption was discovered by Clifford Cocks, which he recorded in 1973 in a secret CESG report titled A Note on Non-Secret Encryption. This work describes a special case of the RSA algorithm, differing in that the encryption and decryption algorithms are not equivalent, and without mention of the application to digital signatures. A few months later in 1974, Malcolm Williamson discovered a mathematical expression based on the commutativity of exponentiation that he recorded in a secret report titled Non-Secret Encryption Using A Finite Field, and which describes a key exchange method similar to that discovered by Diffie, Hellman, and Merkle. It is not known to what uses, if any, the GCHQ work was applied.

It just goes to show, don’t always believe what you hear in presentations…