Hacker News Reader

Comment by kurokikaze | Hacker News Reader

Aaaand here it is: http://blog.erratasec.com/2015/02/extracting-superfish-certi...

Why did he expect to find the password in the clear in the memory dump? He indeed found it there, but why would one expect to?

the nature of writing a blog post ex post facto?

So, just a hunch that it would be a company name or something else that might be in the dump? There's no technical reason for the actual password itself to somehow end up there? A serious security flaw or something?

What I mean is, we are reading about it because it worked.

It's the lowest hanging fruit. I doubt he expected to find the password just sitting there, but since he did, here we are :)

But yes, keeping sensitive information hidden in plain text considered a security flaw.

Because it is needed to decrypt the key and as the program uses it, it must be in memory (at least at some time).

Ahh. That makes sense. So the malware itself is decrypting the certificate using the password.

He didn't find the password in the clear, he found the private key in the clear. He brute-forced the password.

I assume his reasoning for looking for the private key was similar to: this program creates a new certificate authority and installs it on this computer. In order to do this, it must have all necessary tools for doing so, including the private key it uses to create those certificates, in memory somewhere. Even if that private key is stored encrypted somewhere, it has to exist unencrypted in memory at some point to be used.

Read it again, he found the password in cleartext in the memory dump. From the blogpost:

> I tried the small dictionary john.dict that comes with John-the-Ripper, and it didn't find anything. But of course, I don't need a real dictionary. The password is probably also in the clear in the memory dump. I could just use the file super.txt as my dictionary! I tried this, but it was taking a long time, with 150k unique lines of text. It'd take many hours to complete. To speed things up, I filtered the list for just lower-case words

Yup, good catch.

The password to the key must be in the binary - either in clear or encoded form and at some point it needs to be in memory in decoded form. Otherwise the binary could not decode the key itself. You could drop the passphrase immediately after decoding the key to make it harder for the attacker, but fundamentally all info to decode the key must be somewhere on the machine itself.

Trying all strings from the binary if any of them matches is a cheap and easy operation, so try it first, if it doesn't work use a more elaborate approach.

Reply on news.ycombinator.com