La personne qui découvre un problème de sécurité le signale souvent d'abord à l'éditeur ou au développeur du logiciel. Cela donne au fournisseur du logiciel le temps de résoudre le problème avant la publication. Ensuite, une fois corrigé, le bogue est divulgué publiquement. 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 prévenir les sociétés de sécurité et révéler le bogue, brûlant le zero-day.

Je ne pense pas que votre déclaration "la plupart du temps, c'est la même chose 0day est utilisé pendant des mois par les chapeaux noirs " est vrai. Cela est vrai pour certains problèmes de sécurité, mais de nombreux bogues zero-day sont détectés pour la première fois par des pirates informatiques. Je ne dirais pas que les hackers black hat sont en avance sur les hackers white hat. Ils trouvent tous deux des problèmes de sécurité et certains de ces problèmes se chevauchent. Cependant, l'attaque est plus facile que la défense dans la mesure où l'attaque n'a besoin que de trouver un bogue, et la défense doit corriger tous les bogues.

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 développement du correctif?

Ils utilisent des solutions de contournement temporaires jusqu'à ce qu'un correctif soit déployé.

Quand la nouvelle d'un 0day sort, il y a souvent diverses solutions de contournement publiées qui brisent l'exploit en éliminant certains prérequis pour abuser de la vulnérabilité. Il existe de nombreuses possibilités:

• La modification d'un paramètre de configuration peut désactiver les fonctionnalités vulnérables.

• La désactivation des services vulnérables, lorsque cela est pratique, peut empêcher l'exploitation.

• L'activation de mesures de sécurité autres que celles par défaut peut casser l'exploit.

Chaque bogue est différent, et chaque l'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. La plupart des administrateurs, cependant, se tourneront vers les avis de sécurité publiés par l'éditeur du logiciel.

Parfois, un administrateur n'a pas à faire quoi que ce soit . Cela peut être le cas si la vulnérabilité affecte uniquement une configuration autre que celle 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, puisque leurs serveurs n'utiliseront pas DRM de toute façon. Une vulnérabilité dans Apache, en revanche, pourrait être quelque chose dont ils devraient s'inquiéter. Un bon sysadmin 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 avant les whitehats?

Les whitehats sont plus sophistiqués, mais les blackhats sont plus efficaces.

La question de savoir si les blackhats sont 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, s'il est 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 non sophistiqués omniprésents existent déjà. Les Whitehats, d'un autre côté, doivent trouver des correctifs et amener le fournisseur de logiciels à prendre le rapport au sérieux. Cela n'affecte pas les Blackhats dans la même mesure, car ils peuvent souvent commencer à profiter de leur découverte dès qu'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. C'est principalement parce que la culture actuelle chez les whitehats est de chasser et d'écraser les insectes individuels. Moins d'accent est mis sur l'écrasement de classes de bogues entières et quand c'est le cas, des atténuations sous-normales et surexcitées sont créées (comme KASLR). Cela signifie que les blackhats peuvent pomper 0 jours plus vite 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 zero-day est publié ou publié, il est livré avec plus qu'un simple nom et icône. Il y a des détails sur la façon dont le zero-day est utilisé pour exploiter le système. Ces détails constituent la base de la réponse du défenseur, y compris la manière dont le patch doit être conçu.

Par exemple, avec WannaCry / EternalBlue, la vulnérabilité a été trouvée par la NSA et ils ont gardé la connaissance pour eux (la même chose se produit dans la communauté criminelle où les vulnérabilités peuvent être échangées le marché noir). Les détails ont été divulgués, ce qui a informé Microsoft comment créer le correctif et il a également informé les administrateurs comment se défendre contre cela: désactiver SMBv1 ou au moins bloquer le port SMB d'Internet.

C'est ainsi que les administrateurs se protègent. La mise à jour des correctifs n'est qu'une partie de la "gestion des vulnérabilités". Un administrateur peut faire de nombreuses choses pour gérer les vulnérabilités, même s'il ne peut pas ou ne veut pas appliquer de correctifs.

Dans le cas de WannaCry, le NHS n'a pas fait de correctif, 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 mesures d'atténuation des vulnérabilités pour les 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 plus 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 blanc qui sécurise son application / site Web entre le moment où le 0day est publié et le développement du correctif?

Parfois, il existe des solutions de contournement qui corrige ou atténue le problème.

• Parfois, vous pouvez désactiver certaines fonctionnalités ou modifier certains paramètres du logiciel qui empêchent l'exploit de fonctionner. Par exemple, une infection par le ver Morris 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 de l'utilisateur. Dans ce cas, vous pouvez avertir les utilisateurs de ne pas le faire. (" N'ouvrez pas les e-mails avec la ligne d'objet ILOVEYOU"). Mais comme 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 à distance 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 tout un réseau en bloquant simplement les requêtes extérieures 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'à ce que le correctif soit publié.
• En dernier recours, vous pouvez simplement retirer la fiche sur les systèmes vulnérables. Le fait que les systèmes ne soient pas disponibles cause plus ou moins de dommages qu'ils ne soient en ligne et qu'ils soient ouverts aux exploits est une considération commerciale que vous devez évaluer dans chaque cas individuel.

Mais parfois, aucune de ces options n'est 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, alors les blackhats sont-ils en avance sur les whitehats?

Il arrive assez fréquemment que les développeurs / whitehats découvrent une éventuelle faille de sécurité dans leur logiciel et la corrigent avant qu'elle ne soit exploitée. La première étape de la 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 pour SomeTool 1.3.9.53 lit "correction d'un dépassement de tampon possible lors du traitement de fichiers foobar malformés", ce qui n'est généralement pas particulièrement intéressant.

Une autre défense clé consiste à surveiller et à connaître 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 tout d'un coup du trafic vers une adresse IP inhabituelle.

Le serveur de messagerie a maintenant 10 fois plus de trafic pourquoi?

Surveillez les personnes qui se connectent à vos 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 adresses IP pendant un certain temps. Parfois, les adresses IP font 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 affaire que dans 1 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 le cas échéant utiliser les informations de contact de l'administrateur pour avertir le propriétaire. Ils peuvent le retrouver de leur côté. (Cela vaut la peine d'essayer)

Vous devriez être averti lorsqu'un système est contacté par un autre système d'une manière inattendue. Après la première, vous pouvez avoir une tonne de notifications, mais si le ou les ordinateurs sont sur votre réseau, vous pouvez enquêter des deux côtés. Ensuite, supprimez-le ou mettez-le en liste blanche comme 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 analyser les ports.

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.

Bloquez autant que possible et surveillez le reste.

Maintenant, une fois que vous avez une attaque, vous devez faire quelque chose.

Parfois, la seule option est d'éteindre temporairement le système. Vous devez 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 à vos conditions. Aviser le mainteneur du système d'effets afin qu'il puisse le corriger. Si c'est open source, vous pouvez demander à quelqu'un de le corriger pour vous.

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 pourriez avoir pour trouver un autre produit pour remplacer le plus vulnérable en fonction de la gravité du problème.

Comme toujours garder votre logiciel à jour permet de vous protéger.

De cette façon, vous pouvez bloquer 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 zero-day non encore corrigé, vous pouvez toujours identifier d'autres vulnérabilités ou pré-conditions que le zero-day exigerait.

Pour vous défendre contre la menace d'une (par exemple) attaque RDP de l'extérieur du réseau (échec d'authentification RDP zero-day 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 un oubli. Ou, si vous devez avoir RDP hors site, vous pouvez peut-être identifier une liste blanche d'adresses IP à partir de laquelle autoriser ces connexions et réduire l'ouverture dans le pare-feu.

De même, pour se défendre contre une menace RDP interne (et dans une certaine mesure externe), limiter la capacité des utilisateurs A) à exécuter RDP, B) les machines à exécuter RDP, C) le réseau à passer RDP, D) les machines acceptent 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 externes et internes, vise à renforcer votre réseau contre un exploit d'authentification RDP même sans patch.

Une mentalité de défense en profondeur vous permet de briser la chaîne de vulnérabilités / conditions requises pour contrer même un zero-day non patché. Parfois.

J'ai volontairement choisi un problème assez simple ici juste pour illustrer ce point.

Source - J'ai déjà fait cela.

Relativement peu de hacks permettent à l'attaquant de s'introduire dans un système. La plupart sont des bogues «d'escalade 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, que c'est plus ou moins une perte de temps d'essayer de sécuriser une machine contre l'élévation de privilèges. Votre meilleure politique est de vous concentrer sur la prévention des pirates informatiques en premier lieu et sur la surveillance de votre réseau pour les intrusions.

Presque toutes les intrusions proviennent de trois méthodes seulement. Vous voulez dépenser toutes vos ressources de cyberdéfense disponibles pour vous défendre contre ces derniers. Ce sont:

(1) Les e-mails de phishing contenant des PDF ou PPT empoisonnés. Il y a des tonnes de jours zéro ciblant les PDF et les 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 former vos employés à contrôler 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 sandbox 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 elle se produit.

(2) Vulnérabilités du navigateur. La grande majorité des exploits basés sur le navigateur ciblent Internet Explorer, vous pouvez donc défendre probablement 95% d'entre eux simplement en empêchant les utilisateurs d'utiliser IE et en leur demandant d'utiliser Chrome ou Firefox. Vous pouvez empêcher 99% des exploits basés sur le 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 en grande partie 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 étroits et n'exécutent pas de services inutiles. Vous voulez en particulier vous assurer que tous les serveurs Web de l'entreprise fonctionnent par eux-mêmes 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, il y a beaucoup d'exploits qui n'entrent pas dans ces catégories, mais il vaut mieux passer votre temps à traiter les trois classes de vulnérabilités énumérées ci-dessus.

Eh bien, c'est normal d'avoir 0 jours d'un attaquant, le problème est de combien de jours zéro ils ont et combien ça leur coûte pour brûler 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 réfléchissez, comment enverriez-vous commencer à attaquer un réseau? Supposons que vous commenciez par une attaque de phishing / attaque de point d'eau.

S'il s'agit d'une attaque de point d'eau, vous devrez peut-être trouver un jour 0 en flash qui vous permet d'exécuter du code dans le navigateur, puis vous devrez peut-être d'abord sortir du bac à sable du navigateur, ce qui nécessite un autre 0jour. Et ensuite, vous pourriez faire face à appcontainer, qui nécessite un autre exploit pour atteindre le privilège au niveau du système d'exploitation. 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 que vous ciblez Lsass.exe, vous aurez peut-être 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, pendant que vous les exploitez, vous pouvez 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 être en mesure de vous défendre contre une attaque à 0 jour.

Le problème ne vient pas seulement du zéro jour. Il existe de nombreuses entreprises qui traînent encore sur des correctifs de 200 jours pour une multitude de raisons (certaines bonnes, d'autres mauvaises).

Vous avez une longue liste de solutions, une autre consiste à utiliser virtual patcher. Cela crée généralement une atténuation pour le problème avant qu'il n'atteigne le service (je l'ai appris il y a des années grâce à un produit Trend Micro - pas de lien avec eux, mais je l'ai testé et cela a principalement fonctionné). >