full-disclosure - [FD] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.

Open Source and information security mailing list archives

Message-ID: <b0d1418772a9dda6196c447ab0ced8b4@national.shitposting.agency>
Date: Fri, 06 Apr 2018 21:56:04 +0200
From: ketamine@...ional.shitposting.agency
To: fulldisclosure@...lists.org
Subject: [FD] KETAMINE: Multiple vulnerabilities in SecureRandom(),
 numerous  cryptocurrency products affected.

A significant number of past and current cryptocurrency products
contain a JavaScript class named SecureRandom(), containing both
entropy collection and a PRNG. The entropy collection and the RNG
itself are both deficient to the degree that key material can be
recovered by a third party with medium complexity. There are a
substantial number of variations of this SecureRandom() class in
various pieces of software, some with bugs fixed, some with additional
bugs added. Products that aren't today vulnerable due to moving to
other libraries may be using old keys that have been previously
compromised by usage of SecureRandom().

The most common variations of the library attempts to collect entropy
from window.crypto's CSPRNG, but due to a type error in a comparison
this function is silently stepped over without failing. Entropy is
subsequently gathered from math.Random (a 48bit linear congruential
generator, seeded by the time in some browsers), and a single
execution of a medium resolution timer. In some known configurations
this system has substantially less than 48 bits of entropy.

The core of the RNG is an implementation of RC4 ("arcfour random"),
and the output is often directly used for the creation of private key
material as well as cryptographic nonces for ECDSA signatures. RC4 is
publicly known to have biases of several bits, which are likely
sufficient for a lattice solver to recover a ECDSA private key given a
number of signatures. One popular Bitcoin web wallet re-initialized
the RC4 state for every signature which makes the biases bit-aligned,
but in other cases the Special K would be manifest itself over
multiple transactions.

Necessary action:

   * identify and move all funds stored using SecureRandom()

   * rotate all key material generated by, or has come into contact
     with any piece of software using SecureRandom()

   * do not write cryptographic tools in non-type safe languages

   * don't take the output of a CSPRNG and pass it through RC4

-
3CJ99vSipFi9z11UdbdZWfNKjywJnY8sT8

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives