oss-sec mailing list archives

Re: CVE Request: TOTP Replay Attack in Ruby library "devise-two-factor"


From: cve-assign () mitre org
Date: Thu, 17 Sep 2015 10:25:30 -0400 (EDT)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Date: Sun, 6 Sep 2015 11:55:41 -0400

Given an attacker already knows a victim's credentials, they could
"shoulder surf" the victim's second factor device, obtaining the OTP,
and login with the known credentials & OTP within the current
time-step (a default 30 second window). This defeats two-factor
authentication for the duration of the time-step.

This 2015-09-06 message is directly related to a discussion of CVE
assignment here on 2015-06-22, but doesn't mention that that
discussion had occurred. Specifically:

  http://www.openwall.com/lists/oss-security/2015/06/22/2

  From: cve-assign () mitre org

  devise-two-factor can potentially have a CVE ID. As you mentioned, the
  attack surface is somewhat narrow, and it might make more sense to see
  how the devise-two-factor vendor announces the update. For example, if
  the vendor makes a code change to prevent multiple submissions and
  describes the code change as resolving a vulnerability, then there can
  be a CVE ID.

The vendor did all of that, so we're assigning CVE-2015-7225.

[ relevant parts include 'to protect against "shoulder-surfing" attacks' in
https://github.com/tinfoil/devise-two-factor/blob/master/UPGRADING.md and
'While a valid security issue, this is a very narrow vulnerability' in
https://github.com/tinfoil/devise-two-factor/issues/45#issuecomment-139335608 ]

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJV+sz+AAoJEL54rhJi8gl5FkUQAIUNoqnHZHkc6ZY5OXkG1Si+
UIiPAUEtxTXe067zoZjEzqlsjzexzh0ld96XzD0kmfrCR0O/4tddpyX6n5Q7ooqI
VrVp+UDJO36/qDW/ODlxjbJoWD02TdHlWd5gZVb4h7uBSKbj4PItDAMx5VGZbJgP
msCoSOVG48odcGdbOKXR+Bb0zQQURq0s9Qxqwi28MT3IAXlyz9jjSrgyd7W4J87m
+SrS+dL8gH22BA0rNI7UUNeCRpBOmUt9i1QPRRi9nmPjTmBtGZ1AxUXQj/VFTe1c
fcwyvTHBsAslavhVEwbN2IzO+8ycuP55NVW90e2v2k977kHSTjiEpdJ8b3Hl7BtR
2Tu+uZjHIUvNoLznhag/+f9LL3yhxdpgPXlmYQNFeKcsaIxiXxaNF6zg8soRQDMi
f0hMP8yfBkwzSVZY2xl1QeZyww00+RY45WvLPilH7fkoCZmsT3ftxfQkurNViFAU
zCDyKmQIaHXIpcOrC9qLuWmSE02NB8Qod+XkBGOd1/tRDxzMBYoVSDabFfS3npBZ
qDK13djTq8rZKhlXrzdeTrmW5RwDhZrZSrNcdAh140lIL9DwkD/6n/JAubfH68Gn
uFGwgRSCUbNUP8nLJ97Rv81NHNP+XYcd+X3mHumJpPf/R94/dEwkAoi6ytQsE5pr
s9eZT7jONl8mzpQL1Vzl
=aeha
-----END PGP SIGNATURE-----


Current thread: