Une attaque DDoS peut-elle fournir des informations?
Une attaque DDoS peut-elle révéler des informations ou être utilisée pour monter un hack? D'après ce que je comprends, l'intérêt du DDoS ou du DoS est de consommer toutes les ressources/surcharger le serveur, ce qui provoque son plantage. Et c'est la seule raison de faire un DDoS.
J'ai entendu dire que DDoS est utilisé pour obtenir des informations. Est-ce vrai ou totalement faux?
Un DDoS donnera certainement à un attaquant des informations sur les temps de réponse, la capacité de chargement et le routage.
Il peut également fournir des informations sur la façon dont les incidents sont traités en interne et en externe, ainsi que sur la manière dont ils sont signalés au public.
Mais ce ne sont pas les principales utilisations.
En règle générale, les deux principales raisons du DDoS sont les suivantes:
- mettre un service ou un site Web hors ligne
- détourner l'attention d'une attaque, d'une exploitation ou d'une intrusion plus large
Le premier est bien connu, très populaire et relativement simple à réaliser, la seule défense contre une attaque de grande envergure étant un service d'atténuation des DDoS à volume élevé.
Le second est plus rarement utilisé, mais est considéré comme faisant partie de la panoplie d'outils d'un attaquant. Le chargement de l'équipe de réponse aux incidents peut compliquer la détection d'une intrusion, masquer la véritable raison de l'attaque et masquer les preuves d'une intrusion parmi un grand nombre d'entrées de journal du DDoS.
Une réponse complète dépendrait de l'attaque et de ce qui serait attaqué, donc je vais garder les choses générales.
Un DoS peut entraîner des fuites d'informations comme effet secondaire. Auparavant, des commutateurs étaient utilisés dans les réseaux pour empêcher les machines d'écouter la communication entre 2 autres machines. En raison d'un problème de conception, vous pouvez à nouveau le transformer en un grand domaine de collision en lançant une attaque DoS contre le commutateur et vous pouvez réécouter n'importe quelle communication. Explication de l'attaque: les commutateurs apprennent quelle machine est connectée à quel port. Lorsqu'une machine envoie un paquet à une autre machine, le commutateur recherche dans sa mémoire le port sur lequel se trouve cette machine et transfère le trafic vers ce port uniquement. Une machine sur un autre port ne verrait pas le trafic. Un problème survient lorsqu'il y a plus de machines sur le réseau que ce qui pourrait tenir dans la mémoire du commutateur. Les comportements courants sont:
- L'envoyer tout le trafic à tous les ports
- Le commutateur arrêterait d'apprendre de nouvelles machines
- L'interrupteur oublierait les machines les plus anciennes
Le premier type était particulièrement courant. Un attaquant laisserait sa machine faire semblant d'avoir une énorme quantité de machines sur ce port en le faisant avec des diffusions d'annonces.
Une autre attaque liée à DoS est une attaque de rétrogradation de sécurité. Vous avez un système composé de 2 sous-systèmes, A et B. B est utilisé par A pour effectuer des contrôles de sécurité supplémentaires. Si B ne répond pas à temps, A ignorerait cette vérification et la considérerait comme réussie. Si l'attaquant peut faire le système B du DoS, il a un jeu plus facile car il n'a qu'à passer les contrôles de sécurité sur le système A. Certains systèmes sont conçus de cette façon parce que la disponibilité du système A est importante et personne ne pensait qu'un attaquant pourrait faire le système B du Do ou accepterait le risque. Je ne peux pas vous donner les détails d'une attaque réelle, mais certaines listes noires anti-spam fonctionnent de cette façon.
Il est également connu que certains groupes/organisations avancés lancent des attaques (D) DoS pour distraire de leur attaque réelle en attirant l'attention du personnel de sécurité sur la cible du DDoS ou masquer le trafic d'attaque entre le trafic DDoS.
Une autre option est que vous avez besoin de cette quantité de trafic mais que vous n'avez pas besoin de (D) le faire. Par exemple, certaines attaques sur SSL nécessitent suffisamment de paquets pour récupérer/manipuler des informations. Ici, le DoS serait un effet secondaire de la quantité de trafic.
Identifier les ressources partagées
Une attaque de déni de service , distribuée ou non, peut être utilisée pour identifier avec succès les machines qui partagent des ressources. Si vous souhaitez pirater un service, vous pouvez lancer une attaque contre lui, tout en surveillant d'autres services. Si ceux-ci disparaissent également, il est probable qu'ils soient hébergés sur la même machine. Ces autres services peuvent être plus sujets au piratage et peuvent être utilisés comme un "pied-de-biche" pour accéder au service que vous souhaitez.
Services cachés
Cela peut être dévastateur lorsqu'il est utilisé contre services cachés dans le réseau Tor. Si vous avez des raisons de croire qu'une certaine personne héberge un service caché, vous pouvez le tester en lançant une attaque contre un service ouvert sur le même matériel ou dans le même centre de données. Si le service caché tombe en panne, vous avez peut-être confirmé que votre supposition est correcte et l'identité derrière le service caché a été compromise.
Chaque fois que vous testez cela, vous obtiendrez un échantillon, ce qui peut être un faux positif. En le faisant suffisamment de fois à des intervalles aléatoires, vous pouvez augmenter la probabilité d'avoir raison.
Il est possible d'utiliser une attaque DDOS pour obtenir des informations. En plus des réponses de Rory Alsop et H. Idden qui se concentrent sur l'obtention d'informations sur l'infrastructure ou la surcharge de l'équipe de réponse aux incidents afin que d'autres attaques restent non détectées plus longtemps, il existe quelques autres possibilités.
Applications de mise à l'échelle automatique - Lorsque vous travaillez avec une plate-forme d'application qui met automatiquement à l'échelle une attaque DDOS peut utiliser le fait qu'ils se mettent à l'échelle automatiquement pour faire quelque chose. Cela devrait être de concert avec un autre type d'attaque ou d'informations, mais l'idée générale est que si vous en savez assez pour exploiter le processus de "redémarrage", vous pouvez utiliser DDOS pour forcer un nouveau serveur en ligne qui passerait par le processus de redémarrage. , permettant votre exploit. Il est important de noter que cela s'ajoute à un problème de sécurité déjà existant. C'est juste l'outil par lequel l'exploit totalement différent est mis en ligne (ou peut-être testé). Un exemple auquel je peux penser est un serveur de production hébergeant sa base de code dans un référentiel github public, lorsque les échelles tirent du nouveau code dans le serveur, puis démarre. Vous pouvez ajouter du mauvais code à ce dépôt github (s'il n'est pas géré correctement), forcer un redémarrage et avoir votre exploit.
Applications premier arrivé, premier servi - Certaines applications sont "premier arrivé, premier servi" dans une partie de leur processus. IRC (à partir des commentaires) en est un exemple mais il y en a d'autres. Tout service qui réserve quelque chose à un utilisateur selon une approche du premier arrivé, premier servi, peut être exploité via DDOS. Soit en reprenant tous les jusqu'à ce qu'une personne spécifique obtienne la leur, ou en forçant un redémarrage et en obtenant une autre chance sur les "emplacements" après le redémarrage. Celles-ci sont assez courantes, et bien qu'un service qui l'utilise pour l'authentification soit un peu étrange, ce n'est pas inconnu. En fait, les services de licence le font tout le temps. Le premier utilisateur avec une licence "ABC" est l'utilisateur qualifié d'ABC. Si ces données sont perdues après un redémarrage, DDOS pourrait provoquer ce redémarrage et mettre le pied dans la porte.
Vulnérabilités au démarrage - J'ai vu, à plusieurs reprises, qu'un démarrage du serveur a entraîné la "mise sous tension" des services au cas où. Par exemple, laissons les mots de passe SSH activés après le redémarrage, puis désactivons-les après quelques heures au cas où nous aurions besoin d'un accès d'urgence. Ou, FTP est activé pendant 30 minutes après le redémarrage. Ceci est plus courant sur les appliances réseau. Des choses comme "accès wifi non sécurisé pendant les 2 premières minutes" ou "n'importe quoi peut télécharger n'importe quoi pendant 2 minutes". Habituellement, cela fait partie d'un mécanisme de mise à niveau/mise à jour. Par exemple, un routeur Cisco peut accepter toutes les données TFTP qu'il trouve après le redémarrage. Certains ordinateurs écouteront TOUT serveur de démarrage réseau au redémarrage. DDOS peut lancer le redémarrage et laisser entrer votre "mauvais code".
En substance, un DDOS par lui-même peut vous dire certaines choses, mais généralement seulement des choses inutiles en soi. Un DDOS associé à d'autres vecteurs d'attaque peut être extrêmement efficace.
Note Les méthodes utilisées ici fonctionneraient dans un laboratoire, mais il y aurait peu de fruits pour une équipe de sécurité (ou même juste un service informatique ordinaire). Bien qu'ils existent dans la nature, un attaquant devrait avoir acquis un accès/une connaissance des internes bien au-delà de celui de quelqu'un qui fait juste un DDOS.
Un exemple réel de ce qui se passe est avec Steam. Ils ont subi une attaque DoS le jour de Noël. En réponse à cela, ils ont modifié les règles de mise en cache du service Steam, afin que les clients puissent toujours accéder à la page du magasin. Malheureusement, ils ont fini par faire une erreur de configuration, ce qui a parfois amené les utilisateurs à voir les informations personnelles des autres utilisateurs.
Les systèmes ont parfois un comportement inattendu sous une charge système élevée, ce qui peut entraîner des failles de sécurité. C'est une possibilité pour les pirates d'exploiter cela, mais ils sont peu susceptibles de planifier cela, et l'exploit est probablement imprévisible. Ils doivent également faire face au fait que le serveur est probablement lent à répondre en raison de la lourde charge.
Une attaque DDOS pourrait exploiter une vulnérabilité
En théorie, une attaque DDOS pourrait non seulement détourner l'attention d'un exploit comme mentionné dans une autre réponse, mais elle pourrait également être combinée avec une autre.
Considérez le bogue Heartbleed , qui renvoyait des informations lorsqu'un serveur était contacté d'une manière particulière.
On pourrait augmenter les informations obtenues du serveur en contactant le serveur lors d'une attaque DDOS et en collectant les informations qui ont été libérées de cette manière.
Forcer le temps de démarrage du serveur
Une chose qui a été mentionnée tangentiellement dans les commentaires, mais qui n'est abordée dans aucune des autres excellentes réponses, est qu'il peut parfois être utile de savoir quand une application/un serveur a démarré. Par exemple, certains générateurs de nombres aléatoires horriblement peu sûrs (qui ne devraient jamais être utilisés pour des tâches liées à la sécurité, mais le sont invariablement de temps en temps) utilisent l'heure système comme leur graine "aléatoire".
Dans ce cas, si vous pouvez déduire quand le RNG a été amorcé (de préférence en quelques minutes de précision) et avoir des échantillons de sortie de générateur, il est raisonnablement trivial de trouver la graine et de reconstruire l'état RNG pour prédire les futurs jetons . Maintenant, normalement, un serveur ne doit pas exposer son heure de début (mais encore une fois, certains le font invariablement), cependant si une attaque DDoS peut être utilisée pour forcer un redémarrage du serveur, alors vous avez acquis une connaissance de l'heure de début du serveur.
Cela peut conduire à une variété d'attaques basées sur des jetons comme le détournement de session.
Et une attaque chronométrée? Cela a été discuté comme une vulnérabilité de sécurité possible dans Java , Python , probablement beaucoup d'autres, et pourrait en fait sembler être une attaque DOS.
Lorsque diverses bibliothèques vérifient l'égalité, elles préparent généralement octet par octet et comparent, retournant false si elles ne correspondent pas - si quelque chose comme cela est utilisé pour vérifier le mot de passe/cookie, théoriquement, elles peuvent chronométrer la demande la plus longue et supposer qu'elle est allée plus loin dans la comparaison .
Il peut être corrigé, mais je sais qu'au début de la stratégie de groupe, un exploit consistait à surcharger le serveur de stratégie de groupe et dans certaines configurations, la stratégie locale était appliquée. Nous configurerions donc la politique locale comme minimale. Vous ne pouvez utiliser le refus que comme un exploit pour lequel la politique du serveur a réduit l'autorité. Je sais que je n'ai pas tous les termes corrects - cela fait un moment que je n'ai pas administré la stratégie de groupe.
Supposons que vous ayez compromis un routeur mais que ce routeur n'obtenait pas le trafic que vous vouliez. Vous pouvez faire un DoS sur un bon routeur pour, espérons-le, obtenir du trafic vers le routeur de piratage.
Je suppose que l'attaque DoS peut être utilisée avec un type d'exploit de condition de race. Lorsque le serveur est lourdement chargé, l'exploit sera plus facile à utiliser.
Cependant, l'attaque DoS seule peut fournir des informations, comme cela a été montré dans les réponses précédentes - sur le routage, le temps de réponse et la gestion des incidents internes.