Question:
Les attaquants peuvent-ils obtenir quoi que ce soit avec les attaques DoS, sauf en cas de crash du service?
Martin Thoma
2015-05-27 18:50:00 UTC
view on stackexchange narkive permalink

Une attaque DoS (abréviation de «déni de service») est une forme d'attaque utilisée sur les services Web qui vise à «planter» le service.

Y a-t-il un motif de cette forme d'attaque en plus faire planter le service / site Web?

Par exemple, je pourrais penser au chantage / faire du tort à un concurrent / des raisons politiques comme un motif direct d'attaque DoS. Mais y a-t-il d'autres motifs plus indirects? Serait-il possible d'obtenir des données du service avec une attaque DoS? Si oui, comment?

Par définition, non. Si vous utilisez une attaque DoS pour "obtenir des données du service", alors ce n'est plus * juste * une attaque DoS.
Si je suis votre concurrent dans , en faisant tomber vos serveurs, je suis susceptible de gagner certains de vos clients.
Il pourrait être utilisé comme une diversion pendant qu'une attaque plus sophistiquée (visant à voler des données, etc.) est en cours.
Ils peuvent. Voir ma réponse ici pour un exemple: http://security.stackexchange.com/a/81274/66382
Deux sites Web populaires (Feedly et GitHub) ont tous deux été attaqués par DOS; le premier a reçu une rançon, le second a semblé être un geste politique (cibler des pages qui contournent la censure d'Internet en Chine).
35 personnes ont pensé que cela montrait un effort de recherche.
Une attaque DoS peut faire partie d'une attaque plus large, par exemple: l'attaque de Mitnick sur les serveurs Shimomura impliquait de se faire passer pour l'un des serveurs et d'empêcher le serveur usurpé d'interférer sur l'attaque via l'inondation de synchronisation.
Neuf réponses:
#1
+74
Motoma
2015-05-27 19:25:37 UTC
view on stackexchange narkive permalink

En général, une attaque de déni de service (distribuée) ne vous fournira pas beaucoup d'informations directement. Cependant, il existe quelques scénarios dans lesquels des informations pourraient être glanées à la suite d'un DoS. Voici quelques exemples, mais ce n'est pas du tout exhaustif:

  • Un équilibreur de charge peut divulguer des informations de sous-réseau interne ou divulguer des noms de machine internes dans des situations où les systèmes de sauvegarde sont hors ligne.
  • Un DoS qui arrête d'abord la base de données peut amener une application à révéler le type de moteur de base de données, le nom d'utilisateur de connexion ou l'adresse IP interne via un message d'erreur.
  • Une API mal implémentée peut entraîner un "échec -open "scénario - DoS'ing un serveur Single Sign On peut donner à un attaquant la possibilité de se connecter non authentifié, ou avec des informations d'identification locales.
  • Dans les scénarios Advanced Persistent Threat, l'infrastructure de détection DoS peut autoriser un attaquant de ne pas être détecté pendant les autres étapes de collecte d'informations.
  • De même, la gestion par DoS de l'interface d'administration d'un pare-feu pourrait entraver les efforts de réponse aux incidents de l'administration réseau.
  • Dans un cas extrême, DoS contre un service de révocation de clé pourrait permettre à un attaquant de continuer à utiliser révoqué ou connu - informations d'identification compromises.

D'autres motifs d'une attaque par déni de service deviennent apparents si vous considérez les utilisateurs d'un système comme des cibles en plus du système lui-même: Une attaque par déni de service contre un site Web qui vend des billets de concert peut permettre à un attaquant d'acheter des billets pour un événement qui, autrement, se seraient vendus en quelques minutes. Un DoS contre un système de contrôle de version pourrait empêcher une société de développement de livrer un logiciel à temps. Un DoS contre un site de média social pourrait rendre la coordination des manifestations politiques plus difficile, voire impossible.

Je pense qu'un DOS pourrait également inviter un serveur ou des clients à négocier des options de chiffrement moins sécurisées qu'ils ne le feraient autrement, s'il provoque l'expiration des tentatives de connexion avec des options plus sécurisées, mais permet aux tentatives de connexion avec des options moins sécurisées de suggérer.
@supercat +1: Les navigateurs / plugins de navigateur configurés pour préférer HTTPS à HTTP peuvent revenir à HTTP si HTTPS n'est pas disponible.
Je changerais cet exemple en service SVN, car une panne de serveur git serait généralement * beaucoup * plus facile à récupérer en raison de sa nature distribuée. Mais c'est toujours plausible si nous parlons d'un nombre massif de dépôts qui prendraient beaucoup de temps à migrer vers un nouveau serveur, donc je ne fais que diviser les cheveux. +1
Pour un examen plus approfondi: un DoS peut déclencher une limitation de débit ou simplement épuiser la capacité de journalisation / d'audit, cela peut supprimer ou masquer la source ou l'intention d'un attaquant. Certains services sont également sensibles à diverses attaques de devinettes, et DoS -ing tous sauf un serveur peut améliorer les chances de succès, par ex. DNS.
En outre, un serveur totalement surchargé peut être plus vulnérable aux attaques de synchronisation car la différence de temps augmente lorsque tout est ralenti par le DoS.
_DoS contre un service de révocation de clés pourrait permettre à un attaquant de continuer à utiliser des informations d'identification révoquées, expirées ou compromises connues_ "révoquées" et "connues-compromises", bien sûr… mais "expirées"?
@jpmc26: Je pensais au modèle "git push to deploy", mais je l'ai changé en "version control system". Fends ces cheveux, bébé.
* DoS contre un système de contrôle de version ... * pour un exemple - GitHub a été récemment ciblé probablement par le [gouvernement chinois] (http://arstechnica.com/security/2015/04/ddos-attacks-that-crippled -github-linked-to-great-firewall-of-china /) parce que le logiciel y est hébergé.
#2
+13
Polynomial
2015-05-27 19:00:25 UTC
view on stackexchange narkive permalink

En général, les attaques DoS sont uniquement conçues pour provoquer (comme leur nom l'indique) un déni de service, c'est-à-dire une compromission de la disponibilité du service.

Autres formes de DoS, par exemple déclenchant un déréférencement de pointeur nul, peut être utilisé pour compromettre l'intégrité en plantant un service sans qu'il ait le temps de fermer proprement les fichiers, entraînant une corruption des données (perte d'intégrité). Les bases de données sont une cible évidente pour ce genre de choses.

Les pare-feu et autres services de sécurité devraient échouer fermés s'ils sont effectivement DoS. Je ne suis au courant d'aucun cas où quelque chose comme ça échouerait. Cependant, je pourrais prévoir un scénario où un serveur derrière un équilibreur de charge tombe à une attaque DoS, donc l'équilibreur de charge passe à un système secondaire, qui est configuré de manière plus faible, révélant ainsi cette vulnérabilité en externe.

En dehors de la triade CIA, vous constaterez peut-être que les attaques DoS sont utilisées pour détourner l'attention et les ressources en personnel d'une attaque plus subtile.

Poly - J'ai passé un contrat dans une organisation qui avait des pare-feu de grande marque qui ne s'ouvraient pas sous une charge lourde !!
@RoryAlsop Yikes. Ça a l'air idéal!
@RoryAlsop était-il un système conçu pour revenir à un état semi-ouvert pour améliorer les performances dans des conditions bénignes mais occupées et dépassé?
Non - il fonctionnait bien au-delà de toutes les charges de conception attendues :-)
#3
+13
Edheldil
2015-05-28 23:20:12 UTC
view on stackexchange narkive permalink

Oui, l'attaque DoS peut être utile à un attaquant.

(Au fait, il ne s'agit pas d'une attaque uniquement contre les services Web. Elle peut être dirigée contre n'importe quel périphérique réseau).

Le but de DoSing un appareil dans de tels cas est de le faire répondre plus lentement ou plus tard qu'il ne le ferait normalement. Du haut de ma tête, je vois:

  • Empoisonnement du cache DNS (attaque de Kaminsky) - Cela dépend de la capacité de l'attaquant à fournir une réponse DNS plus tôt que le serveur DNS faisant autorité, ce qui pourrait être accompli par Faire le serveur faisant autorité.
  • L'attaque d'insertion Quantum de la NSA repose sur une réponse plus tôt que le serveur légitime
  • L'usurpation d'adresse TCP / IP est également facilitée en ralentissant la réponse légitime
  • Les serveurs OCSP (état des certificats) sont tellement peu fiables et surchargés que certains navigateurs Web ne les vérifient pas par défaut, ouvrant la voie à de fausses attaques de certificats

Dans un autre ordre d'idées, les serveurs DoSing clearnet ( par exemple par un DOS classique, ou simplement en coupant l'accès au réseau) pourrait être utilisé pour vérifier l'identité du service caché de Tor - par exemple il aurait pu être utilisé pour localiser le serveur de Silk Road.

Dans la même veine, les nazis pendant la Seconde Guerre mondiale ont utilisé une sorte de DoS (couper l'électricité dans les quartiers et les rues de la ville) pendant la résistance les transitions des radios pour connaître leur emplacement.

Je pense qu'à l'ère numérique, nous pensons rarement que DoS est également utile dans un vecteur d'attaque physique. Comme écraser / désactiver un lecteur d'étiquettes RFID.
Très bonne réponse! J'aurais aimé pouvoir remonter ça plus d'une fois. Cloué dans les points de balle une anecdote impressionnante.
#4
+5
dr_
2015-05-27 18:55:24 UTC
view on stackexchange narkive permalink

Une attaque DoS (abréviation de «déni de service») est une forme d'attaque utilisée sur les services Web qui vise à «planter» le service. *

Pas exactement . Comme son nom l'indique, le but est de rendre le service indisponible pour les utilisateurs légitimes. La manière la plus courante de procéder pour un service Internet tel qu'un serveur Web est de saturer les connexions afin que personne d'autre ne puisse se connecter. Cela peut être fait par ex. via un flux SYN.

Modifier: comme @RoryAlsop l'a commenté, un attaquant pourrait également essayer de planter le service afin de le rendre complètement hors ligne.

Serait-il possible d'obtenir des données du service avec une attaque DoS? Si oui, comment?

Non, c'est un type d'attaque complètement différent - qui, cependant, pourrait être mené en conjonction avec un DoS, ce dernier ayant pour but de saturer les ressources de un appareil lié à la sécurité, par exemple un IDS, un pare-feu ou même un enregistreur.

Le post de dr01 est correct, mais nous voyons des attaques DDoS utilisées comme parties d'attaques plus larges, soit comme précurseur, pour saturer le personnel de support / réponse et les outils de surveillance afin que le vol (par exemple) ne soit pas repéré, soit comme un outil de force contondant pour assommer les fonctions défensives.
@RoryAlsop qui devrait être une réponse.
@RoryAlsop: Bon point, a ajouté cela à ma réponse.
#5
+4
user530873
2015-05-31 03:58:59 UTC
view on stackexchange narkive permalink

Un résultat d'une attaque DoS qui, je pense, n'a été mentionné dans aucune des autres réponses, est la possibilité qu'une action particulière puisse entraîner le stockage de données, même s'il ne s'agit que d'octets. Par exemple, si la visite d'une URL particulière peut enregistrer quelque chose dans un fichier, le but de l'attaquant pourrait être de remplir le disque dur.

Cela pourrait créer des ravages pour libérer l'espace disque, en particulier si les données sont créées dans des fichiers séparés, avec éventuellement des noms aléatoires, ou si les données sont ajoutées à une base de données avec des données légitimes.

#6
+2
March Ho
2015-05-28 02:15:01 UTC
view on stackexchange narkive permalink

Bien qu'un DoS ne puisse normalement pas être utilisé pour causer des dommages autres que simplement mettre le serveur hors ligne, dans certaines circonstances (le plus souvent en raison de systèmes mal configurés), ils peuvent entraîner de graves conséquences, telles que des fuites de données.

Un exemple célèbre est la fuite d'informations sur le site Web de la loi ACS. Le serveur mal configuré, lorsqu'il est redémarré après la fin de l'attaque DoS, a perdu ses paramètres d'origine et a permis à sa racine de répertoire d'être visible publiquement.

«Leur site est revenu en ligne [après l'attaque DDoS] - et sur leur page d'accueil se trouvait accidentellement un fichier de sauvegarde de l'ensemble du site (liste par défaut du répertoire, leur site était vide), y compris les e-mails et mots de passe », a déclaré un chef du groupe attaquant à TorrentFreak. "L'e-mail contient des mots de passe de facturation et des informations indiquant qu'ACS: Law a des problèmes financiers."

Cela a ensuite entraîné de graves répercussions financières et de réputation pour ACS Law.

#7
+2
jk - Reinstate Monica
2015-05-31 21:37:36 UTC
view on stackexchange narkive permalink

Je pense à des gains non techniques pour l'attaquant:

  • Extraction d'une rançon du service attaqué pour arrêter l'attaque DoS
  • Attirer l'attention du public pour une cause politique (le groupe anonyme a utilisé des attaques DoS dans le passé de cette manière)
  • Obtenir un avantage commercial en faisant tomber le site Web du concurrent (un attaquant peut proposer cela comme un service illégal)
#8
+1
Nzall
2015-05-28 18:09:50 UTC
view on stackexchange narkive permalink

La plupart des réponses ici mentionnent les effets secondaires des attaques DOS. Cependant, je pense qu'il y a aussi l'option inverse possible: que l'attaque DOS n'est pas la cause des effets secondaires, mais plutôt elle-même un effet secondaire d'une autre attaque. Par exemple, une attaque DOS peut être un effet secondaire d'une force brute de botnet énumérant les adresses e-mail via un écran de mot de passe oublié, ralentissant le service ou même le plantant.

Le motif de cette forme de l'attaque n'est pas de détruire le système, mais plutôt d'obtenir une liste d'utilisateurs du service, où la méthode utilisée pour obtenir la liste des utilisateurs a pour effet secondaire de détruire le système.

#9
  0
ddyer
2015-05-28 00:20:45 UTC
view on stackexchange narkive permalink

Habituellement, mais pas nécessairement. Tout dépend de ce qui se passe ensuite lorsque le service prévu échoue en raison de l'attaque. Imaginons que l'attaque ait pour effet de surcharger l'authentification de l'utilisateur pour un site, et que l'effet de l'échec soit d'autoriser le service au lieu de le refuser. Probablement pas le comportement prévu, facilement un comportement qui pourrait être manqué lors des tests normaux.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...