| Detailed description |
|
|
Visual representation of keys in WinPT 1.2.0 is susceptible to a user ID spoofing attack using keys with large amount of data in the user IDs. In several instances the key user IDs are displayed in a fixed size window and any excessive user ID data are simply visually truncated. This allows an attacker to trick a target into using a key with additional user IDs that are hidden during certain operations, including key importing, key signing, key editing, and signature listing. This can in turn lead to unintentional encryption of sensitive information with the attacker's key instead of the legitimate key.
Attack Scenario:
The attacker creates a key with one or more user IDs that the target is willing to import and sign, e.g. "Attacker <attacker@foo.org>". If the objective is to obtain data normally encrypted for victim@bar.com then the attacker adds a user ID that looks like:
Attacker <attacker@foo.org>"SSSSMMMMSSSS<victim@bar.com>
where SSSS represents a large number of spaces (0x20) and MMMM is a bogus message described later. See file exhibit 1: attacker.asc.
During import the target user is not aware of the unusual key ID (see file exhibit 2: import.png). The target then proceeds to sign the key, again oblivious of the spoofing (see file exhibit 3: keysigning.png). Note that the message "Are you really sure that you want to sign this key with YOUR key?" in fact comes from the doctored user ID, not from WinPT itself.
Listing the key signatures or inspecting the key editing window does not reveal the presence of the additional data either (see file exhibits 4, 5, and 6: signaturetree.png, signaturelist.png, and keyedit.png).
Encrypting sensitive plaintext for victim@bar.com with GnuPG will use the attacker's key as long as it has been loaded into the keyring before the legitimate key:
C:\>echo This is a secret | gpg -r victim@bar.com -e | gpg
gpg: encrypted with 1024-bit ELG-E key, ID 7F378BF7, created 2007-03-09
"Attacker <attacker@foo.com>"
gpg: decryption failed: secret key not available
Workaround:
Do not rely on WinPT to inspect and/or import keys; use GnuPG instead.
|
|
