CRYPTOGRAPHY & AUTHENTICATION — THE HEADLINES

 2002/1/24 

PGP 7.0 Outlook plug-in flaw

 2001/11/13 

Bank hack 'a death blow' for security

 2001/11/08 

Microsoft Passport to Trouble

 2001/10/01 

OpenSSH IP restriction bypass

 2001/9/05 

PGP multiple user ID attack

CRYPTOGRAPHY & AUTHENTICATION — THE LINKS

• VeriSign's free online Guide "Securing Your Web Site for Business"

  Disclaimer: These hyper-links to external content may be submitted by visitors of this site. Their contents do not represent the opinion of this publication. The links will be reviewed by an editor and may be modified, rejected or deleted at any time.

CRYPTOGRAPHY & AUTHENTICATION — THE NEWS

2002/1/24

15:32 +0100

PGP 7.0 Outlook plug-in flaw

[Cryptography & Authentication] There appears to be a bug that causes PGP 7.0 up to version 7.1.1 (not including) Outlook Plug-in running on Microsoft Outlook 98 connected to a Microsoft Exchange Server to automatically save decrypted messages as decrypted when the recipient chooses to reply to a PGP encrypted message. This occurs only when the user has the PGP Mail option to "Automatically decrypt/verify when opening messages" checked, and "Always use Secure Viewer when decrypting" is not checked, reports Mark Wiater.

Since the Secure Viewer option is supposed to prevent storage of decrypted items, it seems clear that the problem is in the "Automatically decrypt/verify when opening messages" option. The documentation states "You can save the message in its decrypted state, or you can save the original encrypted version so that it remains secure.", and this has always been my experience prior to this configuration/scenario.

If a PGP encrypted message is received, and the recipient opens and decrypts it, and then closes it, the original message is left encrypted in the recipient's mailbox. This is as one would expect.

If a PGP encrypted message is received, and the recipient opens, decrypts and replies, or decrypts and replies to it, the original message is silently saved to disk decrypted... the user is not prompted as to whether this action should happen or not.

In the case of the above tests, the message was sent from one user on an Exchange Server to another user on the same Exchange Server. The Sender sends from a PST, not the server, and the Recipient stores on the Exchange Server. The reply is being sent to the originating user. Whether Exchange is contributing to the problem in this is unknown.

Clearly, this irreversible action, saving the decrypted message just because it has been replied to, should not be happening. This problem is not remotely exploitable; instead recipients who reply to PGP encrypted messages should be aware that their saved copy of the original message is decrypted.

Users are advised to upgrade to the immune version 7.1.1. // c.f. SecuriTeam :: [dre].

Comments (0)

2001/11/13

12:42 +0100

Bank hack 'a death blow' for security

[Cryptography & Authentication] Two Cambridge PhD students have designed a computer programme that can hack into banks' security codes, potentially giving access to hundreds of thousands of PIN numbers. The two showed it is theoretically possible to download confidential financial information, allowing a potential thief access to vast amounts of cash.

Michael Bond and Richard Clayton said: "Banks' approach to security is too closed, they are relying on outdated concepts such as security through obscurity." He said the breach could only be performed by bank staff with access to bank computers. The system involved is based on IBM's 4758 computer used by banks, the military and governments to protect networks—previously thought to be impregnable, but Bond and Clayton out-gunned it with equipment costing less than pounds 750 to download the data.

IBM said: "This academic study is based on specific laboratory conditions. In the real world, there are too many physical safeguards and authority protections for such an attack to be successful," but security experts said that the hack of the IBM 4758 cryptographic co-processor is a death blow for single Data Encryption Standard (DES) encryption.

"What the hack did point out is that we need to take a more holistic view of security," Phil Huggins, manager of security architecture for @stake, said. "The vulnerability has been known about since February when Ross Anderson of Cambridge University published a document detailing the flaw," Huggins added. "But it has only caused problems since Bond and Clayton published the hack. The exposure may well get the problem sorted." // c.f. Cybercrime-Alerts, SecuritySpace :: [dre].

Comments (0)

2001/11/08

12:39 +0100

Microsoft Passport to Trouble

[Cryptography & Authentication] ...is the title of Marc Slemko's extensive security review of Microsoft's new key component. Microsoft is attempting to position their Passport single sign on authentication service as the one single identity that an Internet user should need to perform all their online activities. Currently, Passport isn't very widely deployed outside of Microsoft sites (in particular, most Passport accounts currently are actually Hotmail accounts). With their .NET "my services" push, Microsoft is trying to change this.

The current implementation of Passport, ignoring the new Windows XP specific functionality for the moment, is wholly inadequate to this task. It does not allow for sufficient control over the use of authentication information by a user and, where current technologies fall short of the ideal, it trades off security in favor of convenience in a way that leaves users vulnerable, Slemko blames.

It is possible to use these design flaws and implementation holes to effectively steal a user's Passport in certain situations. There are many variations on this attack possible, limited only by the number of sites using Passport and the features they offer.

Windows XP attempts to integrate Passport accounts more transparently with a user's XP login account. This integration, while offering the potential for decreased security risks if implemented properly, appears to, in it's current implementation, possibly increases the risk by allowing the user to be automatically authenticated in situations where they did not expect to be or explicitly allow it. Further investigation is necessary to fully understand the security implications of this poorly documented (and apparently still changing on the Passport servers) integration.

Slemko's site demonstrates a few holes that, combined, let you access a Passport user's information in ways that you shouldn't be able to. The Hotmail HTML filtering hole and a particular cross site scripting issue on passport.com will quickly be fixed, making this particular exploit stop working. But unless the deeper issues are addressed, it is still fairly trivial to come up with a new exploit using slightly different techniques. The key problems here are that the cookies go to all .passport.com servers, broadening the attack space, and that when the user uses a password to authenticate for one purpose, the resulting token can be used for other purposes. // c.f. VulnWatch :: [dre].

Comments (0)

2001/10/01

10:46 +0100

OpenSSH IP restriction bypass

[Cryptography & Authentication] (adv.option, patch available)
OpenSSH alerts, that depending on the order of the user keys in ~/.ssh/authorized_keys2, SSHd might fail to apply the source IP based access control restriction (e.g. from="10.0.0.1") to the correct key: If a source IP restricted key (e.g. DSA key) is immediately followed by a key of a different type (e.g. RSA key), then key options for the second key are applied to both keys, which includes 'from='.

Attackers can so circumvent the system policy and login from disallowed source IP addresses.

Vulnerable are versions of OpenSSH between 2.5.x and 2.9.x using the 'from=' key file option in combination with both RSA and DSA keys in ~/.ssh/authorized_keys2. OpenSSH version 2.9.9 is immune.

Users are recommended to upgrade to the immune version or apply the released patch. // c.f. SecuriTeam :: [dre].

Comments (0)

2001/9/05

15:32 +0100

PGP multiple user ID attack

[Cryptography & Authentication] This vulnerability, discovered by Sieuwert van Otterloo, is a practical attack on PGP. The flaw allows an attacker to make a public key appear under an invalid name in the PGP keyring. The attacker can use this to forge signatures, and in the right circumstances to read messages sent to that name. The attack is not a 'life-threatening danger', but can compromise the web of trust system. One should check all keys one imports for unusual extra names.

If a key has two user ID's, there is a problem with determining its validity. One cannot speak about the validity of the key anymore: Both names on the key can be valid independently of another. One should speak about the validity of the two key-name combinations separately, not about the validity of the key. For instance: Suppose a key has two names on it: "Alice " and "Alice ". One could say that the key is valid if the Alice that created the key is the owner of both email addresses. If on the other hand the creator of the key owns neither email address, and is not even called "Alice", then the key is clearly invalid.

Things get interesting if the owner of the key owns one of the email addresses, but not the other, and sometimes calls herself Alice. One of the key-userID links is valid, and the other key-userID link is invalid. If this is the case, the key is not completely invalid and not completely valid.

PGP does not use the concept of key validity internally, and the openPGP standard also does not assume it. All signatures are valid for just one user ID. But the user interface tries to make things simpler than they are: There is a green/gray light indicating the 'key validity', and there is a slider in the key properties window giving the key validity. They use different heuristics to communicate validity to the user.

It turns out the PGP mixes these strategies in a very unlucky way, and one can confuse users with this property. To exploit the confusion, a key with two user ID's is needed. It works with any new PGP version: 5,6 and 7. This issue has been corrected by Network Associates such that all key validity displays in PGP will properly mark the unsigned user ID as invalid. Hotfixes are now available for a choice of versions; hotfixes and upgrades can be found at pgp.com/naicommon. // c.f. VulnWatch :: [dre].

Comments (0)