Quotidien suisseSamedi 17 octobre 2026Édition de 13h, technologie
Prochaine publication le 17 octobre 2026 à 17h
Une · Cloud · Microsoft 365 · Chaîne d’approvisionnement
ConnectWise : l’identité de son service de sauvegarde Microsoft 365 détournée, plus de 160 tenants visités
Un secret d’application appartenant à ConnectWise Cloud Backup (ex-SkyKick), le service de sauvegarde Microsoft 365 utilisé par de nombreux prestataires informatiques (MSP), est entre des mains hostiles. Huntress a confirmé des connexions non autorisées dans 162 tenants au 16 octobre au soir. ConnectWise a coupé l’accès de l’application samedi matin, ce qui interrompt les sauvegardes « jusqu’à nouvel ordre ».
Selon Huntress, l’identité de l’application (ID 506e08f9-6e9a-4da4-942b-a099a03644ae) s’est connectée le 15 octobre, entre 8 h 13 et 10 h 34 (heure suisse), à des tenants clients depuis l’adresse 144.172.64.128, chez un hébergeur, et y a obtenu des jetons Microsoft Graph. Le trafic légitime du service sort normalement d’adresses IPv6 privées d’Azure. L’acteur a parcouru les tenants dans l’ordre trié de leurs GUID, à quelques secondes d’intervalle, signe d’un script travaillant sur une liste. Le type de credential, une client assertion, réside dans le tenant de l’éditeur : aucune action d’un client n’aurait pu le produire. La même adresse avait mené les 13 et 14 octobre une pulvérisation de mots de passe contre quatre tenants de cabinets d’avocats, sans connexion réussie observée.
Le risque tient aux permissions : pour sauvegarder et restaurer, l’application a un accès large en lecture et en écriture aux boîtes mail, à OneDrive, SharePoint, Teams et à l’annuaire, dans chaque tenant où elle est consentie. Ces accès « app-only » ne passent ni par un utilisateur ni par la MFA, et certaines lectures d’annuaire via Graph ne laissent aucune trace d’audit. Dans un tenant partenaire, Huntress a aussi vu une seconde application, ConnectWise Cloud Management - MS Teams, s’attribuer le rôle d’administrateur global puis ajouter de nouveaux secrets clients (valables jusqu’en 2028) à deux autres applications, dont celle de Huntress elle-même. Huntress n’a pas établi que ces deux phases relèvent du même opérateur.
Dans son avis mis à jour le 17 octobre, ConnectWise confirme un « accès non autorisé à des identités d’application », dit n’avoir à ce stade aucun indice de compromission des données sauvegardées et publie l’adresse IP et les User-Agents observés. The Hacker News fait état de 173 tenants touchés. Huntress recommande de désactiver (sans les supprimer) les applications ConnectWise et SkyKick dans Entra, de vérifier les secrets et certificats ajoutés depuis le 13 octobre sur toutes les applications, et de ne rien réactiver avant que l’éditeur ait confirmé la rotation de tous ses credentials : désactiver une application ne retire pas les secrets déjà plantés ailleurs.
AOMEI Backupper : des mises à jour piégées cinq à dix minutes seulement, la Suisse parmi les pays touchés
Mandiant et Google Threat Intelligence Group (GTIG) ont décrit le 15 octobre une compromission de la chaîne de mise à jour d’AOMEI (Backupper, AnyViewer) d’un genre nouveau. Entre avril et juillet 2026, le groupe UNC7017 a modifié à plusieurs reprises les fichiers de configuration servis par les serveurs de l’éditeur, down_html.ini et Notifycfg.ini, pendant de brèves fenêtres (10 minutes le 28 mai, 6 le 16 juillet, 5 le 20 juillet), avant de remettre les versions authentiques. Seuls les clients qui interrogeaient le serveur pendant ces minutes recevaient l’URL d’une archive piégée, avec un numéro de version incrémenté et le MD5 correspondant ; une analyse faite après coup ne voyait que des fichiers propres.
L’archive contenait le téléchargeur CROSSROAD, qui installe par tâche planifiée la porte dérobée SHINYROAD, chargée par détournement de DLL dans un binaire Radmin signé et exécutant du bytecode Python dans un interpréteur PocketPy embarqué. Une variante forçait aussi, par une fenêtre invisible de 1×1 pixel pointant vers un chemin WebDAV, l’envoi de hachés NetNTLMv2. GTIG cite la Suisse parmi onze pays où des organisations ont été touchées (services informatiques, télécoms, hautes écoles). AOMEI dit avoir sécurisé ses serveurs fin juillet, mais les postes infectés restent compromis : Google demande une recherche rétroactive sur toute la période avril–juillet et rappelle qu’un client de mise à jour doit vérifier une signature, pas un MD5 servi par le même canal.
Noyau Linux : une faille de métadonnées de checksum vieille de 18 ans corrigée dans sept branches stables
Greg Kroah-Hartman a publié le 15 octobre les noyaux stables 7.2.11, 6.18.57, 6.12.113, 6.6.159, 6.1.190, 5.15.223 et 5.10.272, qui corrigent notamment CVE-2026-99999, qualifiée de critique par LWN. Selon le correctif de Michael S. Tsirkin (Red Hat), un paquet IPv4 portant des métadonnées de checksum incohérentes peut amener skb_checksum_help() à « corrompre l’en-tête réseau et causer toutes sortes de dégâts ». Le défaut remonte au noyau 2.6.27 (2008), quand tun puis les sockets packet ont accepté qu’un émetteur fournisse lui-même, via l’en-tête virtio_net_hdr, l’offset où commence le calcul du checksum.
Le correctif ajoute un contrôle ip_check_csum_start(), qui rejette tout paquet dont la zone de checksum commencerait à l’intérieur de l’en-tête IPv4, aux endroits où le noyau termine lui-même le calcul : fragmentation IP, conntrack du pont, nfqueue, cible iptables CHECKSUM et sortie IPsec. Tsirkin le présente comme une défense en profondeur, « légèrement testée » ; une validation plus complète à l’entrée doit suivre. La faille a été signalée par Paulos Yibelo. Le correctif porte la mention Assisted-by: LLM. La branche principale est corrigée depuis 7.3-rc7.
Checksum offload : comment Linux délègue le calcul d’un checksum, et pourquoi deux offsets suffisent à corrompre un paquet
La faille CVE-2026-99999 tient en une ligne de comparaison. Pour la comprendre, il faut voir comment le noyau confie le calcul des checksums TCP et UDP à la carte réseau, et ce qui se passe quand c’est l’émetteur, et non le noyau, qui décrit où ce calcul doit se faire.
1. Quatre états pour un paquet. Chaque sk_buff porte un champ ip_summed qui dit où en est son checksum. En réception, CHECKSUM_UNNECESSARY signifie que la carte l’a déjà vérifié, CHECKSUM_COMPLETE qu’elle fournit la somme brute du paquet, CHECKSUM_NONE que rien n’a été fait. En émission, CHECKSUM_PARTIAL signifie : « le calcul reste à faire, par le matériel ou par le logiciel ». Le checksum TCP/UDP est une somme en complément à un sur 16 bits ; la pile écrit d’avance dans le champ la somme du pseudo-en-tête (adresses, protocole, longueur), et il ne reste qu’à additionner la charge utile.
2. Deux nombres décrivent le travail. Avec CHECKSUM_PARTIAL, le paquet transporte csum_start, l’offset où commence la somme (le début de l’en-tête TCP ou UDP), et csum_offset, la position, relative à ce début, où écrire le résultat (16 pour TCP, 6 pour UDP). La carte, ou à défaut skb_checksum_help(), additionne tout depuis csum_start jusqu’à la fin et écrit 16 bits à csum_start + csum_offset. Le noyau doit retomber sur ce calcul logiciel chaque fois qu’un paquet ne peut pas partir tel quel vers le matériel : avant de le fragmenter, de le chiffrer en IPsec, de le remettre à nfqueue ou quand une règle iptables l’impose.
3. Quand l’émetteur fournit les offsets. Pour la virtualisation et les réseaux en espace utilisateur, l’interface tun et les sockets packet acceptent un en-tête virtio_net_hdr devant le paquet : avec le drapeau VIRTIO_NET_HDR_F_NEEDS_CSUM, l’émetteur indique lui-même csum_start et csum_offset, et le noyau marque le paquet CHECKSUM_PARTIAL. Ces deux nombres sont donc une entrée externe. Si csum_start désigne l’intérieur de l’en-tête IPv4, la somme couvre alors une partie de l’en-tête IPv4, et l’écriture de 16 bits peut y tomber, ce qui produit la corruption de l’en-tête réseau décrite par le correctif. Le correctif impose l’invariant csum_start ≥ network_header + ihl × 4 juste avant chaque appel à skb_checksum_help() sur les chemins IPv4 concernés.
4. La leçon de conception. Une métadonnée qui accompagne un buffer (« calcule ici, écris là ») a la même valeur qu’un pointeur : si elle vient d’un tiers, elle doit être bornée par rapport à la structure réelle du paquet, de préférence à l’entrée, et revérifiée là où elle sert à écrire. Les deux contrôles ne font pas double emploi : le premier protège le cas général, le second protège les chemins rares (fragmentation, IPsec, files netfilter) où l’on oublie que le paquet peut encore porter des offsets décidés à l’extérieur. Pour tester son propre code, chercher toute écriture dont l’adresse se calcule à partir d’un offset reçu, et vérifier qu’une borne inférieure et une borne supérieure sont contrôlées avant.
NetScaler CVE-2026-88771 : l’attaque passe par les journaux de l’appliance (suite)
Suite de notre brève du 28 septembre sur le bulletin Citrix CTX697096. Le CERT-EU et Zscaler ThreatLabz ont détaillé le mécanisme de CVE-2026-88771, exploitée sans authentification. L’attaquant envoie un identifiant de connexion qui imite un message d’erreur interne (« pitboss PPE … NSPPE ») suivi de commandes shell ; il est écrit tel quel dans /var/log/ns.log. Le script de diagnostic ns_monuploadd_err.pl relit ce journal et interpole la valeur dans une commande shell. Zscaler a vu des charges encodées en Base64 placées au préalable dans le User-Agent des journaux HTTP, des tentatives de pose de webshells et la livraison d’un implant FreeBSD. Le CERT-EU conseille de chercher « PPE missed too many heartbeats » dans les journaux d’authentification et du Base64 dans les User-Agents, et de vérifier httpd.conf.
Exchange Server : les mises à jour Windows d’octobre font tomber les bases après une journée
Microsoft a confirmé le 15 octobre que les mises à jour cumulatives Windows Server d’octobre (KB5126646 pour 2025, KB5126655 pour 2022, KB5126651 pour 2019, KB5126868 pour 2016) peuvent rendre Exchange instable, même sans la mise à jour de sécurité Exchange. Après environ 22 à 30 heures, OWA renvoie MapiExceptionMdbOffline (ec=1142), les files de messages grossissent et les copies de bases en DAG ne se répliquent plus. Un redémarrage ne règle le problème que pour une journée environ. Aucun correctif ni contournement officiel au 16 octobre. Le spécialiste suisse Rafael Pfister conseille de différer ces mises à jour Windows sur les serveurs Exchange pas encore touchés, tout en installant le correctif de sécurité Exchange, qui ferme une faille critique.
