Nous avons couvert la saga du droit à la réparation, et l’une des entreprises qui sont devenues assez notoires est John Deere. L’autre côté du désordre interconnecté mal géré concerne les problèmes de sécurité. Il y a une certaine ironie dans la façon dont cette histoire a commencé : quelqu’un a remarqué que l’équipement John Deere n’avait aucun CVE. Une personne normale pourrait penser que cela doit signifier que ses produits sont super sécurisés, mais un chercheur en sécurité sait que quelque chose de plus intéressant se prépare. Nos vieux amis [Sick Codes], [John Jackson], et une foule d’autres ont vu cela comme un signe certain qu’il y avait beaucoup de vulnérabilités à trouver, et il semble qu’elles étaient correctes.

Accès à distance et code à partir de 2014…

Les vulnérabilités comprenaient une poignée d’attaques de scripts intersites, un contournement d’authentification via la contrebande de demandes, une sécurité mal configurée, des injections SQL, des RCE et plus encore. Ensemble, ces vulnérabilités ont permis un contrôle total du système John Deere, y compris la possibilité de manipuler tous les équipements connectés au système.

Lors de la présentation de Defcon, liée ci-dessous, [Sick Codes] rappelé le moment où ils ont réalisé qu’ils travaillaient sur un problème important. Plutôt que de se plaindre de ne pas être payé pour les vulnérabilités découvertes, un contributeur a simplement noté qu’il appréciait d’avoir de la nourriture à manger. Une attaque coordonnée contre l’équipement JD pourrait causer de gros problèmes à un tas de fermes à travers le pays.

Ils ont fini par contacter CISA, faute de réponse sérieuse des vendeurs. CISA a pris la menace au sérieux et les problèmes ont commencé à être résolus. Ce n’est pas un problème limité à une seule entreprise. Case avait des problèmes similaires qui ont également été résolus, et il était implicite que d’autres fournisseurs ont des problèmes similaires qui sont toujours en cours de résolution.

Les adresses IP octales frappent à nouveau

Pendant que nous parlons de [Sick Codes] et sa joyeuse bande de chercheurs, il y a quelques autres cas d’analyse incorrecte d’adresses IP au format octal annoncées. Il s’agit des bibliothèques Rust std::net et Golang net, qui suppriment toutes les deux les zéros non significatifs des adresses IP. Dans les deux cas, le correctif consiste simplement à traiter cela comme une adresse invalide. Pourquoi est-ce un problème ? Parce que vous pouvez utiliser des adresses IP sournoises, comme 0127.0.0.1. Une bibliothèque octal-aware considère cela comme 87.0.0.1, alors qu’une bibliothèque avec cette vulnérabilité la considère comme localhost. Le vrai problème survient lorsque les différentes parties d’un service Web utilisent les deux approches. Si vous pouvez contrôler ou usurper l’une de ces adresses magiques, vous pouvez vous connecter au service et avoir des privilèges comme si vous utilisiez une adresse IP interne. Pour plus d’informations, consultez la conférence DEF CON sur ce problème.

RCE d’échange

Vous vous souvenez de ProxyLogon ? C’est l’attaque de Microsoft Exchange que nous combattons collectivement depuis le début de cette année. C’est enfin l’heure de la suite de l’histoire. Poursuivant notre couverture de la conférence, [Orange Tsai] a détaillé cette vulnérabilité et a annoncé une paire de nouvelles vulnérabilités Exchange chez Black Hat, y compris une autre chaîne qui mène à RCE sur le port 443. Si cela ne suffisait pas, il existe déjà des attaques actives tirant parti de cette nouvelle faille.

Cette nouvelle recherche découle d’un changement d’architecture dans Exchange 2013, où le service Web a été divisé en un front-end et un back-end. Il y a toutes sortes de ramifications bizarres à cela, comme le fait que le back-end écoute toutes les interfaces par défaut. Un autre? Le front-end ne vérifie pas l’hôte sur les requêtes entrantes, donc un attaquant peut y insérer n’importe quel texte arbitraire. Cela inclut un nom d’hôte et un port totalement différents, ainsi que des caractères inattendus. Les assembler correctement aboutit à un SSRF arbitraire – l’attaquant peut spécifier n’importe quel point de terminaison, soit sur l’Internet public, soit sur le back-end lui-même. Une fois que le flux normal du front-end au back-end est compromis, il est assez facile d’abuser d’un point de terminaison interne pour obtenir des privilèges d’écriture arbitraires et RCE. C’est l’attaque ProxyLogon en un mot.

Le nouveau RCE est connu sous le nom de ProxyShell. Il abuse du point de terminaison de découverte automatique de pré-authentification, destiné à permettre la configuration automatique pour les clients. L’ajout du point de terminaison souhaité à une demande de découverte automatique valide sert d’outil SSRF. L’attaque consiste à utiliser ce SSRF pour faire une demande au point de terminaison /powershell. Combiné à une charge utile Webshell téléchargée en tant que brouillon, cela donne lieu à un autre RCE de pré-authentification. Heureusement, ces attaques ont déjà été corrigées, mais il y a encore trop de systèmes non encore mis à jour.

Pulse Secure vaincu par le goudron

Cette histoire commence avec CVE-2020-8260, une vulnérabilité d’écriture de fichier arbitraire dans les appareils Pulse Connect Secure, où une configuration téléchargée n’a pas été vérifiée pour le chemin transversal lors de l’extraction. Un fichier tar malveillant pourrait placer des fichiers n’importe où via ./../ chemins. Cela a été corrigé en 2020, mais quelques versions plus tard, CVE-2021-22900 a été divulgué et corrigé. C’était un problème étrangement similaire, et [Rich Warren] du Groupe NCC a décidé d’enquêter. Le correctif d’origine a ajouté un validateTarFile fonction, ce qui semble être un travail très bien fait. Il vérifie ../ des modèles, des liens symboliques ou des liens physiques. En plus de cela, il a une liste blanche de fichiers autorisés. Ce serait la solution parfaite, si seulement elle était utilisée chaque fois qu’une archive était téléchargée. Malheureusement, cette solution robuste n’a été utilisée que lorsqu’un fichier de configuration a été téléchargé. La deuxième solution consistait à ajouter l’appel à validateTarFile à toutes les autres fonctions de téléchargement.

Fort de cette compréhension, la question naturelle à se poser était de savoir si chaque circonstance de téléchargement de fichier était correctement nettoyée. Puisque nous en discutons, vous avez probablement deviné que quelque chose a été manqué. Lorsqu’un fichier de configuration est téléchargé, les paramètres du message POST définissent le type de téléchargement. Une base de données de profileur est gérée différemment et ce chemin de code n’inclut pas la fonction de validation, ce qui conduit à CVE-2021-22937. Il semble que ce chemin de code soit inaccessible en utilisation normale, mais la modification des paramètres de la requête est triviale. Cette série de vulnérabilités est limitée à un attaquant disposant d’un accès administrateur à l’appareil, ce qui atténue considérablement leur gravité. Cela dit, l’accès au système de fichiers sous-jacent ouvre un tout nouveau monde de menaces persistantes. Selon la façon dont il est implémenté, un tel rootkit pourrait survivre à une réinitialisation d’usine.

Test API 101

Les bonnes personnes de Detectify ont publié une introduction amusante au test des API Web. La première moitié de l’article est consacrée à l’utilisation de Postman pour cette recherche. Cela ressemble à un outil utile, mais semble être de source fermée, malheureusement. La seconde moitié de l’article couvre certains problèmes courants dans les API Web et des réflexions sur l’atténuation. Il y a quelques défauts évidents discutés, comme les API privées accidentellement exposées au public. En revanche, il existe quelques bons conseils pour rechercher des failles plus obscures, comme l’injection XXE (XML External Entity). Tout compte fait, cela vaut la peine d’être lu rapidement, en particulier si vous n’êtes pas opposé à l’exécution d’un outil à source fermée dans le cadre de votre boîte à outils.

Série de tubes pneumatiques

Vous êtes peut-être plus familier avec un système de tube pneumatique (PTS) d’une banque ou d’une pharmacie (ou en regardant Futurama), mais ils sont également largement utilisés dans les hôpitaux, entre autres. Les chercheurs d’Armis viennent d’annoncer PwnedPiper, un ensemble de problèmes avec l’implémentation du PTS de Swisslog Healthcare. L’un des pires problèmes ? Leurs panneaux de contrôle sont des systèmes Linux, exécutant un noyau 2.6.35. C’est un noyau vieux de 10 ans. Vous vous souvenez de ce blog cinglant sur la sécurité de Google de la semaine dernière ? C’est le genre de bêtises qu’ils avaient en tête.

Le reste du système est à peu près aussi mauvais, avec un service telnet ouvert à l’écoute des connexions et un mot de passe codé en dur commun à tous les appareils. Plusieurs bogues de corruption de mémoire permettent tous RCE, et le protocole de communication principal est non crypté et non authentifié, sans parler de l’UDP. Et enfin, le processus de mise à niveau du micrologiciel est basé sur ce même protocole, sans aucune fonction de signature de micrologiciel. Pour faire simple, si vous pouvez accéder au réseau Ethernet exécutant ce PTS, vous pouvez trivialement posséder l’ensemble du système.

À quel point cela pourrait-il être grave, s’il était réellement exploité ? Il suffit de considérer que non seulement les échantillons biologiques sont envoyés via ce système, tout comme les médicaments. On ne peut qu’imaginer combien de problèmes pourraient être causés par le brouillage des destinations. Un attaquant plus malveillant pourrait utiliser une telle attaque pour voler ou remplacer des médicaments. Cela ressemble à une intrigue d’un épisode de Mission Impossible, mais la vérité est parfois beaucoup plus étrange que la fiction.

Titres de dernière minute

Le lecteur Foxit PDF a récemment publié 11.0.1, corrigeant une multitude de problèmes, y compris 8 CVE distincts qui pourraient conduire à RCE. Si vous êtes l’un des utilisateurs de cette alternative populaire à Adobe, assurez-vous d’avoir mis à jour !

Comme si nous avions besoin de quelque chose d’autre pour interrompre la chaîne d’approvisionnement électronique, Gigabyte a été touché par un ransomware, avec la menace supplémentaire de fuite de 112 Go de données. Pour aggraver cette menace, une grande partie des données seraient sous NDA, ce qui pourrait entraîner des conséquences supplémentaires pour Gigabyte si elles étaient rendues publiques. Jusqu’à présent, il n’y a aucun mot sur le montant de la rançon.

Une autre histoire que nous pensions morte est ressuscitée. Il existe encore un autre spouleur d’impression 0 jour. Il s’agit d’une autre vulnérabilité liée au point-and-print, mais cette fois, c’est contre la machine qui essaie d’utiliser une imprimante distante malveillante. La précédente vulnérabilité de ce type était inaccessible tant que le point-and-print était désactivé, ce qui était le paramètre par défaut. L’avis de Microsoft ne répertorie pas cela comme solution de contournement pour celui-ci. Il semble que cela fonctionne sur une configuration standard. Pour ajouter l’insulte à la blessure, le chercheur rapporteur a révélé cette faille en décembre 2020.