Comment un administrateur peut-il se protéger contre un jour 0 avant que les correctifs soient disponibles?
Je travaille sur une thèse sur la communauté des hackers de sécurité.
Lorsqu'un 0day est publié, comment un administrateur peut-il sécuriser son application/site Web entre le moment où le 0day est publié et le correctif est développé?
De plus, la plupart du temps, ce même 0day est utilisé pendant des mois par les blackhats, les blackhats sont-ils donc en avance sur les whitehats?
La personne qui découvre un problème de sécurité le signale souvent d'abord au fournisseur ou au développeur du logiciel. Cela donne au fournisseur de logiciels le temps de résoudre le problème avant la publication. Ensuite, une fois corrigé, le bogue est rendu public. Ce processus est appelé divulgation responsable .
Parfois, quelqu'un ne divulgue pas le jour zéro au fournisseur de logiciels mais l'utilise pour pirater d'autres systèmes. Cela peut faire basculer les sociétés de sécurité et révéler le bogue, brûler le jour zéro .
Je ne pense pas que votre déclaration "la plupart du temps, ce même 0day soit utilisé pendant des mois par les chapeaux noirs" soit vraie. Cela est vrai pour certains problèmes de sécurité, mais de nombreux bugs zero-day sont détectés pour la première fois par des pirates informatiques. Je ne dirais pas que les pirates du chapeau noir sont en avance sur les pirates du chapeau blanc. Ils trouvent tous deux des problèmes de sécurité et certains d'entre eux se chevauchent. Cependant, l'attaque a plus de facilité que la défense en ce sens que l'attaque n'a besoin que de trouver un bug et que la défense doit corriger tous les bugs.
Lorsqu'un 0day est publié, comment un administrateur peut-il sécuriser son application/site web entre le moment où le 0day est publié et le patch est développé?
Ils utilisent des solutions temporaires jusqu'à ce qu'un patch soit déployé.
Lorsque des nouvelles d'un 0day sortent, il existe souvent diverses solutions de contournement publiées qui rompent l'exploit en éliminant certaines conditions préalables pour abuser de la vulnérabilité. Il existe de nombreuses possibilités:
La modification d'un paramètre de configuration peut désactiver une fonctionnalité vulnérable.
La désactivation des services vulnérables, lorsque cela est possible, peut empêcher l'exploitation.
L'activation de mesures de sécurité autres que celles par défaut peut interrompre l'exploit.
Chaque bogue est différent et chaque atténuation est différente. Un administrateur ayant une bonne compréhension de la sécurité peut trouver lui-même des solutions de contournement si suffisamment de détails sur la vulnérabilité sont publiés. Cependant, la plupart des administrateurs se tourneront vers les avis de sécurité publiés par le fournisseur de logiciels.
Parfois, un administrateur n'a rien à faire . Cela peut être le cas si la vulnérabilité affecte uniquement une configuration non par défaut ou une configuration qui n'est pas définie sur leurs systèmes. Par exemple, une vulnérabilité dans le sous-système vidéo DRM pour Linux n'a pas à inquiéter un administrateur système avec une pile LAMP, car ses serveurs n'utiliseront pas de toute façon DRM. Une vulnérabilité dans Apache, en revanche, pourrait être quelque chose dont ils devraient s'inquiéter. Un bon administrateur système sait ce qui est et n'est pas un facteur de risque.
De plus, la plupart du temps, ce même 0day est utilisé pendant des mois par les blackhats, les blackhats sont-ils donc en avance sur les whitehats?
Les whitehats sont plus sophistiqués, mais les blackhats sont plus efficaces.
Que les blackhats soient ou non en avance sur les whitehats est une question très subjective. Blackhats utilisera tout ce qui fonctionne. Cela signifie que leurs exploits sont efficaces, mais sales et, parfois, peu sophistiqués. Par exemple, bien qu'il soit possible de découvrir la disposition ASLR d'un navigateur via des attaques par canal latéral, cela n'est pas vraiment utilisé dans la nature car des contournements ASLR omniprésents et non sophistiqués existent déjà. Les Whitehats, d'autre part, doivent trouver des correctifs et obliger le fournisseur de logiciels à prendre le rapport au sérieux. Cela n'a pas d'impact sur les blackhats dans la même mesure, car ils peuvent souvent commencer à bénéficier de leur découverte au moment où ils la font. Ils n'ont pas besoin d'attendre un tiers.
D'après ma propre expérience, les blackhats ont souvent un avantage significatif. Cela est principalement dû au fait que la culture actuelle des whitehats consiste à chasser et à écraser les insectes individuels. L'accent est moins mis sur l'écrasement de classes entières de bogues et quand c'est le cas, des atténuations inférieures à la normale et sur-hypées sont ce qui est créé (comme KASLR). Cela signifie que les blackhats peuvent pomper 0 jours plus rapidement qu'ils ne peuvent être corrigés, car si peu d'attention est accordée à la surface d'attaque et aux vecteurs d'exploitation qui continuent d'être utilisés et réutilisés.
Lorsqu'un jour zéro est publié ou publié, il vient avec plus qu'un simple nom et une icône de fantaisie. Il y a des détails sur la façon dont le jour zéro est utilisé pour exploiter le système. Ces détails constituent la base de la réponse du défenseur, y compris la façon dont le patch doit être conçu.
Par exemple, avec WannaCry/ EternalBlue , la vulnérabilité a été trouvée par le NSA et ils ont gardé les connaissances pour eux (la même chose se produit dans la communauté criminelle où les vulnérabilités peuvent être Les détails ont été divulgués, ce qui a informé Microsoft comment créer le correctif et a également informé les administrateurs comment se défendre contre lui: désactiver SMBv1 ou au moins bloquer le port SMB de l'Internet.
Voilà comment les administrateurs se protègent. Les correctifs ne sont qu'une partie de la "gestion des vulnérabilités". Il y a beaucoup de choses qu'un administrateur peut faire pour gérer les vulnérabilités même s'il ne peut pas ou ne veut pas pièce.
Dans l'affaire WannaCry, le NHS n'a pas corrigé, mais il n'a pas non plus utilisé les autres défenses qui se seraient protégées.
Une grande partie de mon travail consiste à concevoir des atténuations de vulnérabilité pour des systèmes qui ne peuvent pas être corrigés pour diverses raisons commerciales. Le patch est la meilleure solution, en général, mais parfois ce n'est tout simplement pas possible au moment du patch.
... les blackhats sont-ils en avance sur les whitehats?
Cela pose un problème intéressant. Si un blackhat trouve un problème et ne le partage qu'avec d'autres blackhats (ou d'autres membres de la communauté du renseignement), cela signifie-t-il que les blackhats, dans l'ensemble, sont en avance sur les whitehats? Oui. Une fois qu'un jour zéro est exposé, il perd son pouvoir (c'est tout l'intérêt de le divulguer). Donc, le garder secret lui donne du pouvoir.
Les blackhats sont-ils mieux qualifiés ou utilisent-ils de meilleures techniques que les whitehats? Non. Mais les secrets partagés donnent plus de pouvoir aux blackhats, dans l'ensemble.
Lorsqu'un 0day est publié, comment un whitehat peut-il sécuriser son application/site web entre le moment où le 0day est publié et le patch est développé?
Il existe parfois des solutions de contournement qui résolvent ou atténuent le problème.
- Parfois, vous pouvez désactiver certaines fonctionnalités ou modifier certains paramètres dans le logiciel, ce qui empêche l'exploit de fonctionner. Par exemple, une infection par Morris Worm de 1988 pourrait être évitée en créant un répertoire
/usr/tmp/sh. Cela a confondu le ver et l'a empêché de fonctionner. - Parfois, l'exploit nécessite une sorte d'interaction avec l'utilisateur. Dans ce cas, vous pouvez avertir les utilisateurs de ne pas le faire. (" Ne pas ouvrir les e-mails avec la ligne d'objet ILOVEYO "). Mais parce que les humains sont des humains, ce n'est généralement pas une solution de contournement très fiable.
- Parfois, l'attaque est facile à identifier sur le réseau, vous pouvez donc la bloquer avec une règle de pare-feu plus ou moins compliquée. Le virus Conficker , par exemple, ciblait une vulnérabilité dans le service d'appel de procédure distante Windows. Il n'y a généralement aucune raison pour que cette fonctionnalité soit accessible de l'extérieur du réseau local, il était donc possible de protéger un réseau entier en bloquant simplement les demandes externes sur le port 445 TCP.
- Parfois, il est viable de remplacer le logiciel vulnérable par une alternative. Par exemple, notre organisation installe deux navigateurs Web différents sur tous les clients Windows. Lorsque l'un d'eux a une vulnérabilité connue, les administrateurs peuvent la désactiver via la stratégie de groupe et dire aux utilisateurs d'utiliser l'autre jusqu'à la publication du correctif.
- En dernier recours, vous pouvez simplement débrancher la prise sur les systèmes vulnérables. Que les systèmes indisponibles causent plus ou moins de dommages qu’ils soient en ligne et ouverts aux exploits est une considération commerciale que vous devez évaluer dans chaque cas individuel.
Mais parfois, rien de tout cela n'est une option viable. Dans ce cas, vous ne pouvez qu'espérer qu'il y aura bientôt un patch.
De plus, la plupart du temps, ce même 0day est utilisé pendant des mois par les blackhats, les blackhats sont-ils donc en avance sur les whitehats?
Il arrive assez fréquemment que les développeurs/whitehats découvrent une vulnérabilité de sécurité possible dans leur logiciel et le corrigent avant qu'il ne soit exploité. La première étape d'une divulgation responsable consiste à informer les développeurs afin qu'ils puissent corriger la vulnérabilité avant de la publier.
Mais vous n'en entendez généralement pas parler dans les médias. Lorsque le point 59 des notes de mise à jour de SomeTool 1.3.9.53 indique "Correction d'un débordement de tampon possible lors du traitement de fichiers foobar malformés", cela n'est généralement pas particulièrement digne d'intérêt.
Une autre défense clé est la surveillance et la connaissance de votre système.
Où sont vos précieux secrets et qui y a accès.
Si quelqu'un essaie de se connecter à votre serveur de messagerie sur le port 80, drapeau rouge.
Pourquoi le serveur de messagerie envoie-t-il soudainement du trafic vers une adresse IP inhabituelle?.
Le serveur de messagerie a maintenant 10 fois plus de trafic pourquoi?
Surveillez les personnes se connectant aux adresses IP externes. Supprimez et/ou bloquez tous les ports et protocoles externes qui ne sont pas utilisés.
Aucun utilisateur légitime ne se connectera à votre serveur Web sur autre chose que 80 ou 443. Sauf si vous avez ajouté des services supplémentaires. Vous pourriez envisager de bloquer ces IP pendant un certain temps. Parfois, l'IP fait partie de pools dynamiques, et vous ne pouvez pas toujours résoudre un problème avec une liste noire, alors vous déposez simplement les paquets.
Si votre entreprise ne fait des affaires que dans un seul pays, vous devriez peut-être simplement bloquer tous les autres pays.
Vous pouvez utiliser whois pour trouver le propriétaire global de la plage d'adresses IP et, s'il est présent, utiliser les informations de contact de l'administrateur pour en informer le propriétaire. Ils peuvent le retrouver de leur côté. (Ça vaut la peine d'essayer)
Vous devez être averti lorsqu'un système est contacté par un autre système de manière inattendue. Après avoir d'abord reçu une tonne de notifications, mais si le ou les ordinateurs sont sur votre réseau, vous pouvez enquêter sur les deux côtés. Ensuite, supprimez-le ou mettez-le en liste blanche en tant que trafic attendu.
Ces outils de surveillance vous informeront également des analyses de port, à moins que vous n'ayez une équipe de sécurité autorisée, personne d'autre ne devrait effectuer l'analyse de port.
Surveillez les événements réguliers et s'ils s'arrêtent mystérieusement, pourquoi?
Vérifiez la machine pour les infections. Si les services sont désactivés, vous devez être averti à l'avance afin que les changements soient attendus et non mystérieux.
Bloquer autant que possible et surveiller le reste.
Maintenant, une fois que vous avez une attaque, vous devez y faire quelque chose.
Parfois, éteindre temporairement le système est la seule option. Vous devrez peut-être bloquer leur adresse IP pendant un certain temps.
Vous devez toujours protéger et surveiller tous vos services légitimes.
En plus de surveiller la communauté pour les annonces de vulnérabilité. Vous devriez avoir des testeurs de pénétration pour trouver les bogues à l'avance avant les pirates. Ensuite, vous avez une chance d'atténuer l'attaque selon vos conditions. Aviser le responsable du système d'effets afin qu'il puisse le patcher. Si c'est open source, vous pouvez demander à quelqu'un de le patcher.
Les systèmes de détection d'intrusion et Snort peuvent également examiner et potentiellement bloquer les hacks entrants en détectant des modèles suspects.
Vous devrez peut-être trouver un autre produit pour remplacer le produit vulnérable en fonction de la gravité du problème.
Comme toujours, la mise à jour de votre logiciel contribue à vous protéger.
De cette façon, vous pouvez bloquer une activité suspecte, jusqu'à ce que vous déterminiez sa légitimité.
La plupart des exploits potentiels nécessitent une chaîne de vulnérabilités pour être exécutés. En lisant le jour zéro encore non corrigé, vous pouvez toujours identifier d'autres vulnérabilités ou conditions préalables que le jour zéro nécessiterait.
Pour se défendre contre la menace (disons) d'une attaque RDP de l'extérieur du réseau (échec d'authentification RDP à jour zéro publié), n'autorisez pas RDP hors site. Si vous n'avez pas vraiment besoin de RDP de l'extérieur, c'est l'occasion de corriger une erreur. Ou, si vous devez disposer de RDP hors site, vous pouvez peut-être identifier une liste blanche d'adresses IP à partir desquelles autoriser ces connexions et restreindre l'ouverture dans le pare-feu.
De même, pour se défendre contre une menace RDP intérieure (et dans une certaine mesure extérieure), limiter la capacité des utilisateurs A) à exécuter des machines RDP, B) à exécuter RDP, C) le réseau à passer RDP, D) des machines à accepter RDP, E) les utilisateurs autorisent RDP. Quels VLAN devraient avoir la capacité de générer un RDP sortant? Quelles machines devraient pouvoir faire cela? Et ainsi de suite.
Chacune de ces étapes, dans les scénarios extérieur et intérieur, fonctionne pour durcir votre réseau contre un exploit d'authentification RDP même sans correctif.
Une mentalité de défense en profondeur vous permet de briser la chaîne de vulnérabilités/conditions nécessaires pour contrer même un jour zéro non corrigé. Quelquefois.
J'ai intentionnellement choisi un problème assez facile ici juste pour illustrer le point.
Source - je l'ai déjà fait.
Relativement peu de hacks permettent à l'attaquant de s'introduire dans un système. La plupart sont des bogues d '"élévation de privilèges" qui permettent à un attaquant d'avoir un plus grand contrôle sur le système après y avoir accès. Il y a tellement de façons d'obtenir le contrôle administratif d'une machine une fois qu'un pirate y a accès, c'est plus ou moins une perte de temps pour essayer de sécuriser une machine contre l'escalade de privilèges. Votre meilleure politique consiste à vous concentrer sur la prévention des intrusions des pirates et à surveiller votre réseau pour détecter toute intrusion.
Presque toutes les intrusions proviennent de seulement trois méthodes. Vous voulez dépenser toutes vos ressources de cyberdéfense disponibles pour vous défendre contre celles-ci. Elles sont:
(1) Courriels de phishing contenant des fichiers PDF ou PPT empoisonnés. Il y a des tonnes de jours zéro ciblant les PDF et PPT, et la nature de ces deux formats d'application est telle qu'il n'y a plus ou moins aucun moyen de se protéger contre un cheval de Troie contemporain dans l'un ou l'autre. Par conséquent, vous avez essentiellement deux options: exiger que toutes les pièces jointes PDF/PPT passent par un processus de vérification, ce qui n'est pas pratique pour la plupart des organisations, ou pour former vos employés à vérifier eux-mêmes les e-mails, ce qui est la meilleure option dans la plupart des cas. Une troisième option consiste à tester tous les PDF et PPT envoyés à l'organisation dans un environnement en bac à sable après coup, mais cela n'est possible que pour les organisations avancées, comme l'armée, pas l'entreprise moyenne. L'option 3 n'empêche bien sûr pas l'intrusion, elle vous avertit juste immédiatement si une se produit.
(2) Vulnérabilités du navigateur. La grande majorité des exploits par navigateur ciblent Internet Explorer, vous pouvez donc en défendre probablement 95% simplement en empêchant les utilisateurs d'utiliser IE et en les obligeant à utiliser Chrome ou Firefox. Vous pouvez empêcher 99% des exploits basés sur un navigateur en obligeant les utilisateurs à utiliser NoScript et en les formant à son utilisation, ce qui n'est malheureusement pas pratique pour la plupart des organisations.
(3) Vulnérabilités du serveur. Un exemple serait le bogue NTP d'il y a quelques années. Vous pouvez largement vous défendre contre ces derniers en vous assurant que tous les serveurs de l'entreprise fonctionnent sur des réseaux isolés (une "zone démilitarisée") et que ces serveurs sont serrés et n'exécutent pas de services inutiles. Vous voulez surtout vous assurer que tous les serveurs Web d'entreprise fonctionnent seuls dans des environnements isolés et que rien ne peut entrer ou sortir de ces environnements sans qu'un humain fasse explicitement la copie de manière contrôlée.
Bien sûr, de nombreux exploits ne relèvent pas de ces catégories, mais il est préférable de consacrer votre temps à résoudre les trois classes de vulnérabilités répertoriées ci-dessus.
Eh bien, c'est ok d'avoir 0 jours d'un attaquant, le problème est combien de jours zéro ils ont et combien cela leur coûte de graver tous les 0 jours dans votre réseau.
Si vous n'avez pas de correctifs à jour, cela réduit le coût pour un attaquant de développer une chaîne de destruction.
Quand vous y pensez, comment enverriez-vous commencer à attaquer un réseau? Supposons que vous commenciez par une attaque de phishing/attaque par trou d'eau.
S'il s'agit d'une attaque par trou d'eau, vous devrez peut-être trouver un jour 0 en flash qui vous permettra d'exécuter du code dans le navigateur, puis vous devrez peut-être d'abord sortir du sandbox du navigateur, ce qui nécessite un autre jour. Et ensuite, vous pourriez rencontrer appcontainer, qui nécessite un autre exploit pour atteindre le privilège de niveau OS. Et il existe des mécanismes de protection tels que SIP dans macOS, cela signifie que même si vous avez un accès root, vous ne pouvez pas accéder à la mémoire importante. Cela signifie que vous avez besoin d'un autre exploit du noyau 0day. S'il exécute Windows 10 avec cred guard et vous ciblez Lsass.exe, alors vous pourriez avoir besoin d'un autre jour pour attaquer l'hyperviseur.
Il s'avère donc que l'attaque est très coûteuse et nécessite beaucoup d'efforts de recherche, et en attendant que vous les exploitiez, vous pourriez déclencher une alerte de sécurité.
Donc, en tant que défenseur, assurez-vous de bien connaître votre réseau, d'avoir des contrôles de défense dans chaque couche et vous devriez pouvoir vous défendre contre une attaque de 0 jour.
Le problème ne concerne pas seulement les jours zéro. Il existe de nombreuses entreprises qui traînent encore sur les correctifs de 200 jours pour une multitude de raisons (certaines bonnes, d'autres mauvaises).
Vous avez une grande liste de solutions, une autre consiste à utiliser patch virtuel . Cela crée généralement une atténuation du problème avant qu'il ne touche le service (je l'ai appris il y a des années par le biais d'un produit Trend Micro - aucun lien avec eux, mais je l'ai testé et cela a fonctionné principalement).