Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

irssi-otr does not verify trust before automatic resend #23

Open
weinholt opened this issue Jan 14, 2013 · 2 comments
Open

irssi-otr does not verify trust before automatic resend #23

weinholt opened this issue Jan 14, 2013 · 2 comments

Comments

@weinholt
Copy link

Under some circumstances irssi-otr will automatically resend the last written message. Before resending the message it does not verify that the recipient is the one that the message was intended for. This means that if a third party can do MITM on the wire traffic then he can trick irssi-otr into resending a message, thus revealing the plaintext of that message. It does require some cooperation from the user, but that might be easy to get using irssi-otr issue 22 and the "?OTR Error:" mechanism.

You may verify the problem using an IRC bot that I've made:

  1. Connect to irc.freenode.net.
  2. Start a private conversation with the bot called OTRResend and start an OTR session.
  3. Trust the bot using /otr trust. (Not strictly necessary).
  4. Note that the bot echoes back your messages.
  5. Send a message that contains the word "swap" and some secret. (Be careful to not make the message too long, or you'll trigger irssi-otr issue 21. Just try again). The word "swap" makes the bot swap out its keys and send an "?OTR Error:" message..
  6. Note that irssi-otr has printed an error message. This message was sent by the bot, but may also be sent by a MITM attacker. It can contain any text message and there is no digital signature.
  7. Type ?OTR? to restart OTR.
  8. The bot will now start an OTR version 2 session. (I'm not sure if it's strictly necessary to use version 2 here, but this works).
  9. Observe that you get a message indicating that the peer is not authenticated.
  10. Observe that your client has just sent the message from step 5 to an unknown party.

To reset the bot type "/notice OTRResend forget".

Note the manual intervention required by the user at step 7. The attack is not automatic, so it is possible to protect yourself if you have some idea about what might be going on. But I've typed ?OTR? myself on some occasion, when a friend started a second Jabber client that got things confused.

Here is an example session:

06:36 <weinholt_> ?OTR?
06:36 OTR: Gone secure
06:36 OTR: Your peer is not authenticated. To make sure you're talking to the right guy you can either agree on a secret and use the authentication command /otr auth or /otr authq [QUESTION] SECRET. You can also use the traditional way and compare fingerprints (e.g. telephone or GPG-signed mail) and subsequently enter /otr trust.
06:36 OTR: Your fingerprint is: 6E0C4D30 2222E47B 9F1C4A84 884DB3C1 050EAE10
06:36 OTR: OTRResend's fingerprint is: 0DA17A5B 7316AFD4 03E5EF76 53DBDDFB CFF8CC3B
06:36 <OTRResend> Hello there... I am 0DA17A5B 7316AFD4 03E5EF76 53DBDDFB CFF8CC3B. Trust me.
06:36 OTR: Fingerprint 0DA17A5B 7316AFD4 03E5EF76 53DBDDFB CFF8CC3B trusted!
06:37 <weinholt_> echo
06:37 <OTRResend> [0DA17A5B] From you via OTR: 'echo'
06:37 <weinholt_> swap (attack at dawn)
06:37 OTR: General Error: Please type ?OTR? now..
06:37 <weinholt_> ?OTR?
06:37 OTR: Gone secure
06:37 OTR: Your peer is not authenticated. To make sure you're talking to the right guy you can either agree on a secret and use the authentication command /otr auth or /otr authq [QUESTION] SECRET. You can also use the traditional way and compare fingerprints (e.g. telephone or GPG-signed mail) and subsequently enter /otr trust.
06:37 OTR: Your fingerprint is: 6E0C4D30 2222E47B 9F1C4A84 884DB3C1 050EAE10
06:37 OTR: OTRResend's fingerprint is: CF42149C EBB6EFDC 99F8DF5D 8E3DCE57 F2E9B612
06:37 OTR: The last message to OTRResend was resent: 
06:37 <OTRResend> Hello there... I am CF42149C EBB6EFDC 99F8DF5D 8E3DCE57 F2E9B612. Do not trust me.
06:37 <OTRResend> [CF42149C] From you via OTR: '[resent] swap (attack at dawn)'

Verified with irssi 0.8.15-5 and ibotr5 4.0.0-2 on Debian wheezy amd64 with irssi-otr v1.0.0-alpha1-5-g5f685aa from git.

@DrWhax
Copy link
Member

DrWhax commented Jan 16, 2013

Thank you for opening this ticket. This is a serious bug, we hope to resolve this soon!

@anarcat anarcat mentioned this issue May 9, 2013
@dgoulet
Copy link
Member

dgoulet commented Nov 9, 2013

FYI: http://lists.cypherpunks.ca/pipermail/otr-dev/2013-November/001997.html

This is most probably a libotr issue. It can also be reproduce with pidgin-otr.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants