SUNBURST (faille SolarWinds) : FireEye, Godaddy et Microsoft proposent un « kill switch »
Le 18 décembre 2020 à 08h28
1 min
Internet
Internet
Le pot aux roses a été découvert en début de semaine. SolarWinds se serait méchamment fait pirater pour diffuser des mises à jour vérolées à ses clients : organisations gouvernementales, armée et services de renseignement…
Comme le rapporte BleepingComputer en se basant sur une déclaration de FireEye, un kill switch a été trouvé – en collaboration avec Godaddy et Microsoft – pour stopper l’attaque et empêcher SUNBURST de fonctionner.
La faiblesse du cheval de Troie est la suivante : « En fonction de l'adresse IP renvoyée lorsque le cheval de Troie résout avsvmcloud[.]com et sous certaines conditions, il s'arrêterait et empêcherait toute exécution ultérieure ». Cela fonctionne pour les anciennes comme les nouvelles contaminations. De plus amples détails sont disponibles ici.
Le 18 décembre 2020 à 08h28
Commentaires (5)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 18/12/2020 à 09h32
Mais pourquoi en 2020 un centre de commande dont le nom est figé??? Un centre de commande maintenant ça a un nom dynamique selon la date voyons!
Et pourquoi ne pas utiliser un DNS-over-HTTPS pour masquer leurs requêtes de domaines à l’antivirus local?
Et ce kill switch: si la boite utilise un proxy tunnel HTTP/HTTPS en local vers l’internet et il croira que tous les sites sont locaux.
Bref, soit cette menace est importante mais encore imparfaite - soit ce n’est que le sommet de l’iceberg: une menace parmi celles qui sont “triviales” à déjouer…
Le 18/12/2020 à 09h52
Ce bouton d’arrêt d’urgence doit certainement permettre au développeur du cheval de Troie de désactiver sa charge utile lorsqu’il est situé dans son environnement propre, c’est-à-dire qu’il n’est pas sur une cible d’attaque.
Le 18/12/2020 à 14h43
Tu reportes le problème : DoH ou pas le trojan devra de toutes façons soit s’appuyer sur le résolveur système, soit décider de lui même quel résolveur il utilise en précisant son adresse, et c’est le serveur à cet adresse qui deviendra le kill-switch.
Le 18/12/2020 à 14h14
C’est à double tranchant : Plus ta liste de domaines est longue, moins il sera possible d’en garantir une fausse categorisation pour passer les filtrages d’URLs. La plupart ont un taux de succès plutôt faible si à minima le groupe “non catégorisé” est bloqué ou exige une action manuelle.
Globalement, je n’ai vu quasiment aucun AV capable de grand chose sur la détection des C2. Et tu gardes alors une capacité à infiltrer des réseaux dont le DNS est strictement interne (souvent la seule porte de sortie est un proxy explicite dans ce cas). A l’inverse, les services de sécurité lié au DNS sont plutôt doués pour la détection/blocage des DoH. Donc peut être un choix pragmatique (ou une option activable dans le futur) ?
Le 18/12/2020 à 17h00
Effectivement j’ai un peu perdu l’habitude: actuellement je suis derrière une passerelle avec dpi - donc les DNS et le DNS over HTTPS renvoient les adresses “normales”. Et pas de filtrage sur nom de domaine (enfin pas beaucoup)