[148207] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] Cryptolocker

daemon@ATHENA.MIT.EDU (Jerry Leichter)
Thu Nov 21 22:21:18 2013

X-Original-To: cryptography@metzdowd.com
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <CAL=nDptSQkGFUCJdiKVbABtdfp7Y8T74mhO2OaH2mm2C=3gNtA@mail.gmail.com>
Date: Thu, 21 Nov 2013 22:16:13 -0500
To: Greg Broiles <gbroiles@gmail.com>
Cc: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com


--===============0633812882301056363==
Content-Type: multipart/alternative; boundary="Apple-Mail=_B6925DE0-AA05-4379-89E0-257072CFBB1D"


--Apple-Mail=_B6925DE0-AA05-4379-89E0-257072CFBB1D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On Nov 21, 2013, at 9:08 PM, Greg Broiles wrote:
> According to Steve Gibson at https://www.grc.com/sn/sn-427.txt, when =
CryptoLocker contacts the central server(s), the servers generate a =
unique (per victim) 2048-bit RSA keypair; the public key is sent from =
the server to the infected machine. The infected machine generates a =
random 256 bit AES key, which is then encrypted with the public key and =
sent to the server, and used locally to encrypt the ransomed files. The =
key stored in the infected machine's registry is the public half of the =
RSA key.=20
This does mean that if you manage to catch the program while it's =
running, you can (in principle; the practice may be quite difficult) =
extract the AES key, which is all you need - the RSA keypair is purely =
secondary.  There are reports that the program will encrypt =
newly-created files on an infected machine, at least sometimes.  If this =
is true, the program must have some way of asking for the AES key, even =
if the ransom hasn't been paid.  That would be a major vulnerability.

                                                        -- Jerry


--Apple-Mail=_B6925DE0-AA05-4379-89E0-257072CFBB1D
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Nov 21, 2013, at 9:08 PM, Greg Broiles wrote:</div><blockquote type="cite"><div dir="ltr">According to Steve Gibson at <a href="https://www.grc.com/sn/sn-427.txt">https://www.grc.com/sn/sn-427.txt</a>, when CryptoLocker contacts the central server(s), the servers generate a unique (per victim) 2048-bit RSA keypair; the public key is sent from the server to the infected machine. The infected machine generates a random 256 bit AES key, which is then encrypted with the public key and sent to the server, and used locally to encrypt the ransomed files. The key stored in the infected machine's registry is the public half of the RSA key. <br>
</div></blockquote></div>This does mean that if you manage to catch the program while it's running, you can (in principle; the practice may be quite difficult) extract the AES key, which is all you need - the RSA keypair is purely secondary. &nbsp;There are reports that the program will encrypt newly-created files on an infected machine, at least sometimes. &nbsp;If this is true, the program must have some way of asking for the AES key, even if the ransom hasn't been paid. &nbsp;That would be a major vulnerability.<div><br></div><div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -- Jerry</div></div><div><br></div></body></html>
--Apple-Mail=_B6925DE0-AA05-4379-89E0-257072CFBB1D--

--===============0633812882301056363==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============0633812882301056363==--

home help back first fref pref prev next nref lref last post