webscan

webscan est un scanner d'adresses IP réseau basé sur le navigateur et un détecteur d'IP locale. Il détecte les IP liées à l'utilisateur/victime en écoutant sur un canal de données RTP via WebRTC et en bouclant sur le port à travers toutes les IP actives, ainsi qu'en découvrant toutes les adresses IP actives sur des sous-réseaux valides en surveillant les expirations immédiates (paquets TCP RST renvoyés) lors d'appels fetch() ou de balises img cachées pointant vers des sous-réseaux/IP valides. Fonctionne sur mobile et desktop sur tous les principaux navigateurs et systèmes d'exploitation. La version bêta est extensible pour permettre l'ajout de plusieurs techniques.

webscan tire parti du fait que les sockets de balises img non réactives peuvent être fermées pour éviter les limitations de débit du navigateur et du réseau en modifiant l'attribut src vers un URI non socket (la suppression du DOM n'ironiquement pas fermer le socket), ou en utilisant le support de signal de fetch() via l'interface AbortController().

essayez webscan en direct ici
version bêta ici

par @SamyKamkar
publié le 2020/11/07
plus de projets amusants sur samy.pl

webscan fonctionne comme suit

1. webscan parcourt d'abord une liste d'adresses de passerelle courantes
2. pour chaque IP, utilisez fetch() pour effectuer une fausse connexion HTTP vers http://common.gateway.ip:1337
3. si un TCP RST est renvoyé, la promesse fetch() sera rejetée ou le onerror de la balise img se déclenchera avant un délai d'expiration, indiquant une IP active
4. pour éviter la limitation de débit du navigateur ou du réseau, les sockets fetch() non réactifs sont fermés via le signal AbortController() tandis que les balises img voient leur src redirigé vers un URI non socket, fermant ainsi le socket
5. lorsque la passerelle active est détectée, les étapes 1 à 3 sont répétées pour chaque IP du sous-réseau (ex. 192.168.0.[1-255])
6. un canal de données WebRTC est ouvert sur le navigateur, ouvrant un port aléatoire sur la machine de la victime
7. pour toute IP trouvée active sur le sous-réseau, une connexion de canal de données WebRTC est établie vers cet hôte
8. si le canal de données WebRTC réussit, nous savons que nous venons d'établir une connexion avec notre propre IP locale

implémentation

// wait for scan to finish
let scanResults = await webScanAll()
 
// or get callbacks when ips are found with a promise
let ipsToScan = undefined // scans all pre-defined networks if null
let scanPromise = webScanAll(
  ipsToScan, // array. if undefined, scan major subnet gateways, then scan live subnets. supports wildcards
  {
    rtc: true,   // use webrtc to detect local ips
    logger: l => console.log(l),  // logger callback
    noRedirect: false, // if true, doesn't redirect from http to http - Chrome doesn't scan detect network IPs proprly on https atm
    localCallback:   function(ip) { console.log(`local ip callback: ${ip}`)   },
    subnetCallback:  function(ip) { console.log(`router ip callback: ${ip}`)  },
    networkCallback: function(ip) { console.log(`network ip callback: ${ip}`) },
  }
)

retourne

scanResults = {
  "local": ["192.168.0.109"], // local ip address
  "network": { // other hosts on the network and how fast they respond
    "192.168.0.1": 97,
    "192.168.0.2": 82,
    "192.168.0.100": 46,
    "192.168.0.109": 0,
    "192.168.0.117": 74,
    "192.168.0.113": 17,
    "192.168.0.112": 21,
    "192.168.0.114": 25,
    "192.168.0.116": 25,
    "192.168.0.115": 25,
    "192.168.0.105": 57,
    "192.168.0.107": 63,
    "192.168.0.103": 64,
    "192.168.0.108": 31
  }
}

À faire

• utiliser une iframe pour effectuer des analyses par blocs
  • lorsque la frame est détruite, je suppose que cela aide à garantir que les connexions sont fermées
  • comment plusieurs iframes analysant plusieurs blocs fonctionnent-elles ? cela pourrait peut-être permettre de contourner la limitation du débit de connexion du navigateur
• prendre en charge à la fois fetch() et img comme cœurs de scanner (terminé dans beta)
  • Safari
    • remarque : la balise img fonctionne très bien dans certains navigateurs comme Safari
    • inconvénient : changer le .src ne semble pas abandonner la connexion
    • solution potentielle : voir la note sur l'iframe ci-dessus
  • Chrome
    • inconvénient : Chrome n'abandonnera pas la connexion si on supprime l'img du DOM
    • solution : Chrome abandonnera la connexion d'une img si on modifie son .src, c'est génial !
    • inconvénient : changer le img.src en '#' fait une nouvelle requête vers la même page parent
    • inconvénient : changer le img.src en 'about:' produit un avertissement dans la console, y a-t-il autre chose à utiliser qui ne fera pas de requête ?
• utiliser le minutage d'img comme mécanisme de détection d'IP locale

Testé sur

• Chrome 87.0.4280.47 (macOS)
• Edge 86.0.622.63 (Windows)
• Firefox 82.0.2 (macOS)
• Firefox 82.0.2 (Windows 10)
• Safari 13.1.2 (macOS)
• mobile Safari (iOS)
• mobile Chrome (iOS)