2

Since the vulnerability was specifically targeting FTP passwords in Windows machines there were used with things like Filezilla, can a server which SFTP credentials were kept in a windows machine using Firefox be considered already compromised? If so, what can be done to remedy that?

Sergio Pascarelli
  • 23
  • 2

2 Answers2

1

First, I edited your question following your comment to @FiascoLabs answer regarding the fact you are talking about SFTP instead of FTP.

Coming back to your question properly:

can a server which SFTP credentials were kept in a windows machine using Firefox be considered already compromised?

I prefer to discuss this question from different sides.

For the already problem, the answer is Yes and No. I mean it depends if you visited a website (server) that hosted the malicious script then you may have been a victim already. But this scenario has unlikely happened to you because the malicious script has been hosted on two main domains 93.115.38.136 and 185.86.77.48 which have been inactive since August 8th, 2015 after the intervention of the Ukrainian government.

The second side that you seem to be interested in through your question is related to SFTP: if you look to the list of files of which the malware is interested you can see:

enter image description here

But as the linked stated, this occurs during the first stage of the attack only, we do not know how much deep the file scanning is done by this script. Also, I may mention that exploit does not care if you are running your protocols over TLS/SSL or not.

If so, what can be done to remedy that?

Is it so or not, you seriously need to upgrade your Firefox version to Firefox 39.0.3 in which the bug is fixed so that, even if you have not been trapped by the moment, you avoid being targeted by this malicious script (that could be modified to extend for instance the list of files to probe) in the case it would have been hosted elsewhere and you visit the site by accident or in purpose.

Community
  • 1
0

Are you waiting to find out? Change passwords and regenerate any certificates you use to connect. Especially if any program you use appears in that list. Clock's ticking.

And pretty much accept that if you use FTP, you compromise your credentials every time you connect, FTP sends passwords and login names in cleartext.

And .ppk files are plaintext certificate store files for things like the Putty SSH client as is .ssh/authorized_keys

The basic take-away is that none of these clients store credentials securely, so never store your login credentials in them. And we have no way of securely storing certificates in general use either, that's gotta change.

Fiasco Labs
  • 1,557
  • 10
  • 12
  • I guess I should've specified but it isn't plain FTP, is FTP over TLS. – Sergio Pascarelli Aug 12 '15 at 02:25
  • Good, secure transport cures a lot of ills. The vulnerability had free rein to read or write files so any computer running Firefox could have been compromised during the period it was run unpatched with only a possible message warning that the js pdf reader might not display correctly and to open in an external reader. And then depending on their target, Ukrainian cyberwar against Russia, Ukrainian separatist cyberwarefare against Ukrain or Ukrainian Cybercriminals? We don't know yet whose servers were being targetted at first, but I'd presume everyone now as it's escaped. – Fiasco Labs Aug 12 '15 at 02:36
  • I haven't thought about targets, but what's bugging me is that now every web site that were in those servers might be entirely compromised, there might be malicious code infecting the visitors, is there any way this can be diagnosed? I'm thinking about weird request on the page and so on, but the code could potentially be inside or own .js. – Sergio Pascarelli Aug 12 '15 at 02:49
  • That's a harsh assumption. Are you sure that Putty does not store and transmit credentials securely? If yes, why and how? – Freedo Aug 12 '15 at 12:09
  • @freedom Harsh fact, the transmission is secure, the storage isn't. Open a `.ppk` file in notepad, on Linux, open `authorized_keys` and `authorized_keys2` in nano. Guess what I was doing this weekend, long before the question was asked? – Fiasco Labs Aug 13 '15 at 03:59
  • authorized_keys stores public keys. It's not intended to be a secret in SSH security model. Your id_rsa should be encrypted, and if you have a strong password, having the encrypted file stolen shouldn't be a cause for immediate alarm (replace the key in time, but do not need to panic). – Lie Ryan Aug 13 '15 at 12:05
  • Still, you should audit your .authorized_keys file. While having authorized_keys stolen isn't a security issue, having an entry there that you don't recognize is a security issue. – Lie Ryan Aug 13 '15 at 12:07
  • In SSH, the public key resides on the server. You distribute the private keys to each person who will be accessing that server. They are stored in authorized_keys. A technical detail maybe, but somebody stealing this key can access your server SSH account, if you generated it without a passphrase or a weak one, bad dog, they have access now that they have the key. – Fiasco Labs Aug 14 '15 at 00:58