3 ms·

Aaaand here it is: http://blog.erratasec.com/2015/02/extracting-superfish-certificate.html#.VOYGlfmsV-4 http://blog.erratasec.com/2015/02/extracting-superfish-c

Aaaand here it is: http://blog.erratasec.com/2015/02/extracting-superfish-certificate.html#.VOYGlfmsV-4 http://blog.erratasec.com/2015/02/extracting-superfish-certi...

nsxwolf 12y ago
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?
- betenoire 12y ago
  the nature of writing a blog post ex post facto?
  - nsxwolf 12y ago
    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?
    - betenoire 12y ago
      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.
- geococcyxc 12y ago
  Because it is needed to decrypt the key and as the program uses it, it must be in memory (at least at some time).
  - nsxwolf 12y ago
    Ahh. That makes sense. So the malware itself is decrypting the certificate using the password.
- scott_s 12y ago
  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.
  - theflagbug 12y ago
    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
    - scott_s 12y ago
      Yup, good catch.
- Xylakant 12y ago
  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.

Aaaand here it is: http://blog.erratasec.com/2015/02/extracting-superfish-certificate.html#.VOYGlfmsV-4 http://blog.erratasec.com/2015/02/extracting-superfish-certi...

nsxwolf 12y ago

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?

betenoire 12y ago
the nature of writing a blog post ex post facto?
- nsxwolf 12y ago
  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?
  - betenoire 12y ago
    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.
geococcyxc 12y ago
Because it is needed to decrypt the key and as the program uses it, it must be in memory (at least at some time).
- nsxwolf 12y ago
  Ahh. That makes sense. So the malware itself is decrypting the certificate using the password.
scott_s 12y ago
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.
- theflagbug 12y ago
  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
  - scott_s 12y ago
    Yup, good catch.
Xylakant 12y ago
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.