Communication Synology - Synolocker

[Einsteinium]

Bon

J'ai réussi a lire mes DD en RAID depuis un Live CD linux !

Je recupère ce qui n'est pas cryptés.

Mais pas de dossier system disponible pour récupérer le dossier /etc/synolock !

Il se trouve ou ? Je ne vois que les données pas le système.

Comment outre passer la redirection de l'interface web sur le NAS pour accéder a l'interface ?

Sinon pour ce qui sont dans la même misère, je vous confirme que payer est bien l'unique solution pour le moment. Un de nous a payé pour récupérer ses données qui sont actuellement en cours de décryptage.

Alors liste les partitions que tu vois, et monte celle du système alors =)

La tu as juste monté le volume1

[Foxdream94]

Quand j'ouvre Gparted je vois bien ma partition de 2,5To ou son mes données.

Si je regarde un DD en particulier je vois ça (disque de 1To) :

Partition File Sytem Label Size Used Unused Flags

- /dev/sda1 EXT3 1.41.3-0965 2.37Gib 577.01Mb 1.81Gib RAID

- /dev/sda2 linux-swap 2.00Gib 68.00kib 2.00Gib RAID

- unalocated 128.00Mib

- /dev/sda3 linux-raid 927.01Gib RAID

- unalocated 2.49Mib

Ou est la partition system et comment la montée ?

Modifié le 10 août 2014 par Foxdream94

[Fravadona]

Ca a l'air d'être la partirion de DSM

[Foxdream94]

Ca a l'air d'être la partirion de DSM

Laquelle ? et je la monte comment sur depuis le live-CD sans casser le raid biensur

[Einsteinium]

Laquelle ? et je la monte comment sur depuis le live-CD sans casser le raid biensur

sudo mount -t ext3 /dev/sda1 /media/sda1

[Foxdream94]

sudo mount -t ext3 /dev/sda1 /media/sda1

Toujours pas de risque sur le RAID ?

[Einsteinium]

Non tu monte la partition et quand tu stop la bécane, cela démonte les volumes, donc inutile de faire des umount ensuite.

[Foxdream94]

Non tu monte la partition et quand tu stop la bécane, cela démonte les volumes, donc inutile de faire des umount ensuite.

error mount point /media/sda1 does not exit ?

[Einsteinium]

error mount point /media/sda1 does not exit ?

Créé le dossier (mkdir)

[Foxdream94]

Non tu monte la partition et quand tu stop la bécane, cela démonte les volumes, donc inutile de faire des umount ensuite.

Bon j'ai réussi a dumper le fameux Dossier /etc/Synolock.

Comment le partager maintenant ?

Mail en pv ?

[Einsteinium]

Je tenvois mon mail en pv, je m'occupe de le mettre après sur le net =)

[catimimi]

Quand j'ouvre Gparted je vois bien ma partition de 2,5To ou son mes données.

Si je regarde un DD en particulier je vois ça (disque de 1To) :

Partition File Sytem Label Size Used Unused Flags

- /dev/sda1 EXT3 1.41.3-0965 2.37Gib 577.01Mb 1.81Gib RAID

- /dev/sda2 linux-swap 2.00Gib 68.00kib 2.00Gib RAID

- unalocated 128.00Mib

- /dev/sda3 linux-raid 927.01Gib RAID

- unalocated 2.49Mib

Ou est la partition system et comment la montée ?

Bonjour,

Dans ton cas, c'est la première partition /dev/sda1. Elle se monte comme une partition linux standard :

mount -t ext3 /dev/sda1 /mnt

Cordialement.

Michel.

[Foxdream94]

Bonjour,

Dans ton cas, c'est la première partition /dev/sda1. Elle se monte comme une partition linux standard :

mount -t ext3 /dev/sda1 /mnt

Cordialement.

Michel.

Merci

J'ai réussi a monter la partition System et dumper le dossier /etc/synolock. Avec Einsteinium nous sommes entrain de l'analyser et voir comment ca marche.

Pour le décryptage c'est pas gagné mais on y croit !

[Seb@stien]

Malheureusement, la seule solution serait de retrouver la clef AES privée qui a été généré sur le NAS (et effacer avant qu'elle soit transmise sur les serveurs du/des pirates)

Sans ça, il est quasi impossible de décrypter quoi que ce soit

C'est ce que j'ai pu comprendre du fonctionnement de ce virus : une fois installé, il génère une clef AES privée (unique à chaque NAS à un instant T) qu'il envoie cryptée à l'aide d'une clef RSA Publique sur le/les serveurs du/des pirates,il crypte les données puis efface la clef AES privée.

Celle ci est alors uniquement disponible sur les serveurs du pirate et demande une rançon pour pouvoir décrypter les données (avec envoie de la clef AES Privée)

Seb@stien

[Einsteinium]

Tu as tout bon, il crypte puis supprime la clef, tant que le cryptage n'est pas terminé celle ci est présente, sachant qu'elle était au moins en clair une fois, du moins lors de sa création.

On fait joujou un peu, je sais comment opère le blocage du ssh et telnet, ainsi que l'interface du DSM, aussi la liste des fichiers malicieux.

On peux viré les restrictions simplement en supprimant 4 fichiers, tout en gardant le logiciel inactif, ou alors en passant celui ci en mode décryptage (renommer un fichier et en supprimé un autre), je sais que le fait de mettre la clef privé correcte active ce mode décryptage, mais je me demande si celle ci intervient vraiment dans le cryptage/décryptage, a voir si foxdream veut faire le cobaye.

J'en viens a cette déduction simple, car celle ci est pour le moment absente d'un système qui n'est pas totalement crypté, hors la logique voudrait qu'elle le soit pour le cryptage non terminé justement.

Modifié le 11 août 2014 par Einsteinium

[Fravadona]

Synolocker ne fonctionne pas comme cela. Chaque fichier possede sa propre clé AES générée à la volée (différente d'un fichier a l'autre). Cette clé n'est pas stockée sur le serveur pirate mais directement dans le fichier. Le problème est quelle est cryptée avec la clé publique associée au NAS et qu'il faut la clé privée pour la déchiffrer.

[mlelorra]

Tu as tout bon, il crypte puis supprime la clef, tant que le cryptage n'est pas terminé celle ci est présente, sachant qu'elle était au moins en clair une fois, du moins lors de sa création.

On fait joujou un peu, je sais comment opère le blocage du ssh et telnet, ainsi que l'interface du DSM, aussi la liste des fichiers malicieux.

On peux viré les restrictions simplement en supprimant 4 fichiers, tout en gardant le logiciel inactif, ou alors en passant celui ci en mode décryptage (renommer un fichier et en supprimé un autre), je sais que le fait de mettre la clef privé correcte active ce mode décryptage, mais je me demande si celle ci intervient vraiment dans le cryptage/décryptage, a voir si foxdream veut faire le cobaye.

J'en viens a cette déduction simple, car celle ci est pour le moment absente d'un système qui n'est pas totalement crypté, hors la logique voudrait qu'elle le soit pour le cryptage non terminé justement.

quelle ténacité ! en tout cas, je t'encourage encore pour toutes tes recherches !

En espérant que tu puisses aider la communauté à avancer dans la lutte contre ce fléau

[Einsteinium]

Synolocker ne fonctionne pas comme cela. Chaque fichier possede sa propre clé AES générée à la volée (différente d'un fichier a l'autre). Cette clé n'est pas stockée sur le serveur pirate mais directement dans le fichier. Le problème est quelle est cryptée avec la clé publique associée au NAS et qu'il faut la clé privée pour la déchiffrer.

Non la clef n'est pas différente pour chaque fichier, si ce qu'il annonce est bien le cas, c'est un cryptage asymétrique, la clef publique sert au cryptage, la clé privée au décryptage, dans le cas de synolocker elle est envoyer directement sur les serveurs des maîtres chanteur après génération, j'ai pas encore fait mumuse avec les fichiers cryptés encore, juste avec le programme, et je sais que actuellement si l'on rentre une clef privée correcte (il y a un test vis a vis de la clef publique), cela renomme juste un fichier, qui libère l'interface du dsm, et lance le processus de "décryptage", de mon point de vue, cela donne l'impression que la clef privée est le mot de passe de l'application.

Si j'ai le temps demain je regarderais un fichier crypter/décrypter, voir si elle joue un rôle réel dans celui ci. (mais de ce que j'ai vue sur le forum, cela semble être aussi le cas)

Reste à trouvais les serveurs des clefs privées.

[Fravadona]

Technical details about the encryption process :

- A unique RSA-2048 keypair is generated on a remote server and linked to this system.

- The RSA-2048 public key is sent to this system while the private key stays in the remote server database.

- A random 256-bit key is generated on this system when a new file needs to be encrypted.

- This 256-bit key is then used to encrypt the file with AES-256 CBC symmetric cipher.

- The 256-bit key is then encrypted with the RSA-2048 public key.

- The resulting encrypted 256-bit key is then stored in the encrypted file and purged from system memory.

- The original unencrypted file is then overwrited with random bits before being deleted from the hard drive.

- The encrypted file is renamed to the original filename.

- To decrypt the file, the software needs the RSA-2048 private key attributed to this system from the remote server.

- Once a valid decryption key is provided, the software search each files for a specific string stored in all encrypted files.

- When the string is found, the software extracts and decrypts the unique 256-bit AES key needed to restore that file.

Donc au final : meme si découvrir la valeur de la clé AES utilisée pendant le chiffrement d'un fichier est faisable, ca ne permettra pas de déchiffrer les autres fichiers ...

Reste à trouvais les serveurs des clefs privées.

Pourquoi pas hacker leur serveur ? Ca pourrait fonctionner s'ils gardent leurs clés privées sur un support connecté au réseau

Modifié le 13 août 2014 par Fravadona

[azeus]

Pour les débutants, il faut voir le mécanisme de cryptage à clé publique comme un cadenas pouvant être ouvert avec une seul clé. Ici le cadenas c'est la clé publique et la clé permettant de déverrouillage du cadenas est la clé privée.

- Une personne voulant recevoir des colis fermés (cryptés) va donc mettre à disposition publiquement plusieurs copies de son cadenas (la clés publique est dispo sur des serveurs publics de clés).

- La personne voulant lui envoyer un colis (data), récupère donc le cadenas (la clé publique de la personne) et s'en sert pour verrouiller le colis.

- Une fois le colis verrouillé avec le cadenas (crypté avec la clé publique), plus personne même celui qui possède la clé publique ne peux le déverrouiller.

- Seul le destinataire peut donc ouvrir le cadenas avec la clé (privée) qu'elle n'a jamais été communiquée.

Résumé, sur les syno infectés vous ne trouverez pas de clé de déverrouillage (privée), ni même la clé de verrouillage (publique) et même si par chance vous tomber sur la clés publique elle ne vous servira absolument à rien (mise à part crypter des données que seul le hacker peut décrypter).

L'executable peut donner des informations sur la nature du cryptage mais ça aide pas beaucoup.

Les seules solutions sont soit trouver une faille dans l'algorithme utilisé permettant de décrypter, soit utiliser du bruteforce en croisant les doigts et priant que les CPU des années à venir soient plus rapides. Ou sinon récupérer les clés privées par un autre moyen (hacker leur serveur par exemple, à supposer que les clés y sont).

[Seb@stien]

C'est juste, mis à part que la clef privée a été générée sur le NAS, envoyée cryptée (avec la clef publique) sur le serveur du hackeur et détruite du NAS

Seb@stien

[azeus]

C'est juste, mis à part que la clef privée a été générée sur le NAS, envoyée cryptée (avec la clef publique) sur le serveur du hackeur et détruite du NAS

Seb@stien

Normalement l'algo ne devait pas fonctionner de la sorte, c'est con pour les pirates ^^ (Quoique ca leur permet d'éviter quelques emerdes). Croisons les doigts pour les victimes.

[Fravadona]

C'est juste, mis à part que la clef privée a été générée sur le NAS, envoyée cryptée (avec la clef publique) sur le serveur du hackeur et détruite du NAS

D'où sors-tu ca ? Seules les clés AES sont supposées etre générées sur le NAS.

[Seb@stien]

Oui, la clef privée (cf ce que j'avais dit plus haut : )

Et pour le "fonctionnement" je sors ça du fonctionnement de CryptoLocker, dont SynoLocker est un clone

Modifié le 13 août 2014 par Seb@stien

[Fravadona]

Moi aussi j'ai posté plus haut ce que les hackeurs disent faire. C'est vrai qu'on ne peut pas leur faire confiance mais s'ils disent faire comme cela je ne vois pas de raison "technique" qui les en empècheraient, surtout que generer puis envoyer la clé est plus difficile a implémenter que juste aller chercher la clé sur le serveur (et moins sûr)

Modifié le 13 août 2014 par Fravadona