Home
My Page
Projects
Windows Privacy Tray

[#327] User ID spoofing attack on WinPT

Date:
2007-03-09 18:59
Priority:
3
State:
Closed
Submitted by:
NN Poster (nnposter)
Assigned to:
Timo Schulz (twoaday)
Hardware:
PC
Product:
None
Operating System:
Windows XP
Component:
None
Version:
None
Severity:
None
Resolution:
None
 
URL:
Summary:
User ID spoofing attack on WinPT

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.

Followup

Message
Date: 2008-07-20 17:47
Sender: Timo Schulz

I'm not sure why I did not respond to this one.

But the scenario has several problems. First, it assumes that the message is properly encoded according to the victims environment. This is manageable, I agree.

But WinPT/gpgme uses the recipients key ID for encryption, not the userid/email. Using the non-unique pattern for key selection is a security risk anyway.

So if you major concern is that sensitive text could be encrypted with the wrong key, WinPT was never vulnerable because the key IDs are used.

And I don't want to be pedantic, but isn't it already public when you post a security report to a tracker of a public website?
Date: 2007-06-05 13:54
Sender: NN Poster

Since I have not heard back I am planning to disclose the vulnerability to the public in the next few days. Please let me know if you would like to postpone the disclosure.
Date: 2007-05-18 14:32
Sender: NN Poster

Considering the "freeze" announcement from the beginning of April, do you still plan to resolve this issue in a near future?

I would like to publicly disclose the vulnerability but I have no problem waiting for an updated WinPT for a month or two. On the other hand, if your other commitments do not allow you to work on WinPT then the users should be warned about this issue even without WinPT getting fixed.
Date: 2007-03-10 10:22
Sender: Timo Schulz

In any case I need to change the display form for long user IDs but display the entire user ID when it is very long is no solution because it makes proper dialog handling impossible.

Thanks for your opinion, I might move this topic to a gnupg mailing list to discuss this more in detail.
Date: 2007-03-09 21:12
Sender: NN Poster

Re communication:
No problem, you can reach me as nnposter324 at users.sourceforge.net (remove 324).

Re two-email pattern:
Actually checking for the two-email pattern might not cover all the cases. As an example, I could just pad the second UID with spaces and add the victim as a properly formatted 3rd UID. This way I have avoided the pattern while the victim UID is still not visible during the import or key signing. It would of course show up during key edit or signature listing.

Alternatively I could make the 2nd UID as "AttackerSSSSSSSSS<victim@bar.com>", which would also avoid the pattern and it would appear to the target as a UID without any e-mail. The victim e-mail address would not get disclosed during the import, key signing, and even signature listing. It would still show up in the key edit window.

Probably one of the best approaches is to either (1) display the entire UID text, regardless of size, and scale all the windows accordingly or (2) show just the leading part, just like now, but add a strong indicator of truncation, such as:

Attacker <attacker@foo.org>...(352 hidden chars)
Date: 2007-03-09 19:57
Sender: Timo Schulz

Your attack is based on an user ID which contains more than
one email address and thus it would be easy to check for such
suspicious pattern, right?

Propably this could lead to problems with 'free form' user IDs
but IMHO they are seldom and they would only cause trouble if they contain 2 email addresses.
Date: 2007-03-09 19:44
Sender: Timo Schulz

I see some scenarios are possible but first,

please do not use the tracker directly to post security
issues which could be exploited by some bad guys. This way I've no chance to provide a fix and release a new version ASAP, without the fear that some 'script kiddies' use the attack to compromise systems with a vulnerable program version (!)

I don't say such things should be kept in secret, but as usual the vendors (in this case it's me via PM) should be contacted first.

I would prefer to continue this discussion via mail, ok?

Attached Files:

Attachments:
Exhibits.zip

Changes:

Field Old Value Date By
close_date2008-07-20 17:472008-07-20 17:47twoaday
status_idOpen2008-07-20 17:47twoaday
assigned_tonone2007-03-12 12:06twoaday
File Added179: Exhibits.zip2007-03-09 18:59nnposter

This site is hosted by Intevation GmbH