Un DDoS donnera certainement à un attaquant des informations sur les temps de réponse, la capacité de charge et le routage.

Il peut également donner des informations sur la manière 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 n'est pas ce que sont les principales utilisations.

En général, les deux principales raisons de DDoS sont:

• prendre un service ou site Web hors ligne
• détourner l'attention d'une attaque, d'un exploit ou d'une intrusion plus large

Le premier est bien connu, très populaire et relativement simple à mettre en œuvre, avec la seule défense contre une attaque de grande envergure étant un service d'atténuation DDoS à haut volume.

Le second est plus rarement utilisé, mais est considéré comme faisant partie de l'ensemble d'outils d'un attaquant. Le chargement de l'équipe de réponse aux incidents peut rendre la détection d'une intrusion plus difficile, masquer la véritable raison de l'attaque et masquer la preuve 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é, je vais donc la garder générale.

Un DoS peut divulguer des informations comme effet secondaire. Dans les temps anciens, 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 le transformer à nouveau en un grand domaine de collision en lançant une attaque DoS contre le commutateur et vous pouvez écouter à nouveau toute 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 de cette machine et transfère le trafic uniquement vers ce port. 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 tiendrait dans la mémoire du commutateur. Les comportements courants sont:

• L'envoyer tout le trafic vers tous les ports
• Le commutateur arrêterait d'apprendre de nouvelles machines
• Le commutateur oublierait les machines les plus anciennes

Le premier type était particulièrement courant: un attaquant laissait sa machine faire semblant d'avoir une énorme quantité de machines sur ce port en le faisant avec des annonces.

Une autre attaque liée à DoS est une attaque de déclassement de sécurité. Vous disposez d'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 DoS système B, il a un jeu plus facile car il n'a besoin que de 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 DoS système B 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.

On sait également que certains groupes / organisations avancés lancent des attaques (D) DoS pour détourner l'attention de leur véritable attaque en attirant l'attention du personnel de sécurité sur la cible du DDoS ou masquer le trafic d'attaque entre le trafic DDoS. / p>

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 les 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 celui-ci, 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'ils sont utilisés contre les services cachés du 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 hypothèse est correcte et l'identité derrière le service caché a été compromise.

Chaque fois que vous testez cela, vous obtiendrez un échantillon, 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. Outre les réponses de Rory Alsop et H. Idden, qui se concentrent sur l'obtention d'informations sur l'infrastructure ou sur 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 à l'échelle automatiquement une attaque DDOS, vous pouvez utiliser le fait qu'elle évolue automatiquement pour faire quelque chose. Cela devrait être de concert avec un autre type d'attaque ou d'information, mais l'idée générale est que si vous en savez suffisamment 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 la balance extrait le 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 (d'après les commentaires) est un exemple mais il y en a d'autres. Tout service qui réserve quelque chose à un utilisateur sur une approche premier arrivé, premier servi, peut être exploité via DDOS. Soit en occupant tous les emplacements jusqu'à ce qu'une personne spécifique soit la leur, soit en forçant un redémarrage et en obtenant une autre chance aux «emplacements» après le redémarrage. Ceux-ci sont assez courants, et bien qu'un service qui l'utilise pour l'authentification soit un peu étrange, ce n'est pas rare. En fait, les services de licences 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, où un démarrage du serveur entraînait des services "laissés" 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 "tout peut télécharger n'importe quoi pendant 2 minutes". Cela fait généralement 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 permettre à votre "mauvais code" d'entrer.

En gros, un DDOS par lui-même peut vous dire certaines choses, mais généralement seulement des choses qui sont inutiles en soi. Un DDOS en conjonction avec d'autres vecteurs d'attaque peut être extrêmement efficace.

Remarque Les méthodes utilisées ici fonctionneraient dans un laboratoire, mais il y a peu de fruits à suspendre pour une équipe de sécurité (ou même IT ordinaire). Bien qu'ils existent dans la nature, un attaquant devrait avoir acquis un accès / une connaissance des éléments internes bien au-delà de celui de quelqu'un qui ne fait qu'un DDOS.

Un exemple concret de ce phénomène est celui de 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 d'autres utilisateurs.

Les systèmes ont parfois un comportement inattendu sous une charge système importante, ce qui peut entraîner des failles de sécurité. C'est une possibilité pour les pirates d'exploiter cela, mais il est peu probable qu'ils soient capables de planifier cela, et l'exploit est probablement imprévisible. Ils doivent également gérer le fait que le serveur est probablement lent à répondre en raison de la forte 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 un.

Considérez le bug 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 collecter les informations ainsi diffusées.

Forcer le temps de démarrage du serveur

Une chose qui a été mentionnée de manière tangentielle dans les commentaires, mais qui n'a été abordée dans aucune des autres réponses tout à fait excellentes, est que cela peut parfois être utile pour savoir quand une application / 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 qui le sont toujours de temps en temps) utilisent l'heure système comme leur graine "aléatoire".

Cela étant cas, si vous pouvez déduire quand le RNG a été amorcé (de préférence dans quelques minutes de précision) et avoir quelques échantillons de sortie du générateur, il est raisonnablement trivial de trouver la graine et de reconstruire l'état RNG pour prédire les futurs jetons. Désormais, normalement, un serveur ne devrait pas exposer son heure de démarrage (bien que, encore une fois, certains le font invariablement), cependant si une attaque DDoS peut être utilisée pour forcer le redémarrage du serveur, vous avez pris connaissance de l'heure de démarrage du serveur.

Cela peut conduire à diverses attaques basées sur des jetons comme le détournement de session.

Cela peut être corrigé mais je sais qu'au début de la stratégie de groupe, un exploit était de 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 pour exploiter l'autorité réduite de la politique du serveur. Je sais que je n'ai pas tous les termes corrects - cela fait un moment que je n'ai pas fait d'administrateur de stratégie de groupe.

Supposons que vous ayez compromis un routeur mais que ce routeur n'obtient pas le trafic souhaité. Vous pouvez faire un DoS sur un bon routeur pour, espérons-le, acheminer le trafic vers le routeur piraté.

Je suppose que l'attaque DoS peut être utilisée avec un type d'exploit de race-condition. 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.

Et une attaque chronométrée? Cela a été discuté comme une faille de sécurité possible dans Java, Python, probablement beaucoup d'autres, et pourrait en fait apparaître comme une attaque DOS.

Quand diverses bibliothèques vérifient l'égalité, généralement elles préparent octet par octet et comparent, retournant false si elles ne correspondent pas - si quelque chose de ce genre est utilisé pour vérifier le mot de passe / cookie, théoriquement, ils peuvent chronométrer la requête la plus longue et supposer qu'elle a progressé dans la comparaison.

Ce n'est généralement pas incroyablement intrusif. Cela dépend des ports ouverts et des paquets envoyés. DDoS peut provenir de personnes qui renforcent brutalement les détails et les bases de données de votre serveur, en particulier sur le LAN, et peuvent impliquer une attaque bruteforce discrète dans certains cas. Un serveur Web typique est difficile à pirater, j'héberge du Web et des jeux vidéo. Demandez à un professionnel, ou je suppose que c'est une vulnérabilité inévitable.