li4n0/revsuitRevSuit est une plateforme de connexion inverse flexible et puissante conçue pour recevoir des connexions depuis un hôte cible lors d'une pénétration.
English ｜简体中文
RevSuit est une plateforme de connexion inverse flexible et puissante conçue pour recevoir des connexions depuis un hôte cible lors de tests de pénétration. Elle prend actuellement en charge les protocoles HTTP, DNS, RMI, LDAP, MySQL et FTP.
Flexible :
Puissant :
Téléchargez la dernière version directement ou construisez-la en suivant les étapes :
git clone https://github.com/Li4n0/revsuit.git
cd revsuit/frontend && yarn install && yarn build
cd ../ && go build ./cmd/revsuit/revsuit.go
RevSuit générera un fichier de configuration par défaut lors du premier lancement. Modifiez le fichier de configuration selon vos besoins, puis relancez-le. Une description détaillée du fichier de configuration se trouve ici : Configuration Notes
Pour confirmer la localisation IP, il est nécessaire d'utiliser une base de données de localisation IP. QQwry est utilisé comme source de données par défaut, vous pouvez également modifier la configuration pour utiliser GeoIP. Si la base de données sélectionnée n'est pas disponible dans le répertoire actuel ou si la base de données est mise à jour depuis plus d'une semaine, RevSuit téléchargera automatiquement la dernière base de données. Si le téléchargement échoue, le champ IpArea sera toujours null.
$ ./revsuit
2021/05/16 22:55:10 [ INFO] Downloading qqwry.dat...
____ _____ _ __
/ __ \___ _ __/ ___/__ __(_) /_
/ /_/ / _ \ | / /\__ \/ / / / / __/
/ _, _/ __/ |/ /___/ / /_/ / / /_
/_/ |_|\___/|___//____/\__,_/_/\__/
vBeta0.1
https://revsuit.pro
2021/05/16 22:55:22 [ INFO] Starting HTTP Server at :80, token:your_token
2021/05/16 22:55:22 [ INFO] Start to listen FTP PASV port at :2020, PasvIP is 10.9.8.7
2021/05/16 22:55:22 [ INFO] Starting FTP Server at :21
2021/05/16 22:55:22 [ INFO] Starting MySQL Server at :3306
2021/05/16 22:55:22 [ INFO] Starting RMI Server at :1099
2021/05/16 22:55:22 [ INFO] Starting DNS Server at :53
Après l'exécution, vous pouvez visiter le chemin /revsuit/admin/ du serveur HTTP et entrer le token pour accéder au panneau de contrôle.
Prenons l'exemple de la création de règles HTTP :
Quelques remarques :
name et flagFormat d'une règle sont uniques.FlagFormat utilise une syntaxe d'expression régulière, et pour différents protocoles, les champs correspondant à flagFormat sont différents. Vous pouvez consulter les indications correspondantes pour obtenir des détails lors de la création de règles.flagFormat, et le résultat du groupe correspondant sera également utilisé comme variable de template.Comme illustré ci-dessous, nous créons une règle qui utilise les variables de template intégrées et personnalisées du protocole http, et nous la nommons test_create_rule :
Ensuite, effectuez une requête qui satisfait la règle et visualisez la réponse.
La requête sera enregistrée sur la plateforme en même temps.
Si vous souhaitez être notifié des nouvelles connexions sur votre logiciel de bureautique, vous pouvez configurer l'adresse webhook du logiciel concerné dans le fichier de configuration et activer le commutateur Notice pour la règle correspondante. Actuellement, seuls quatre types de logiciels sont pris en charge : dingtalk, wechat, lark, slack. (La prise en charge de Discord et Telegram est prévue.)
Si vous migrez des plateformes ou purgez des données, il peut être fastidieux de recréer des règles. C'est pourquoi la plateforme prend en charge l'import et l'export de règles.
Le point d'entrée de cette fonction se trouve dans Settings>RULES.
Les règles sont stockées au format yaml pour l'import et l'export, comme suit :
http:
- name: test_create_rule
flag_format: (?P<what>\w+)\?
rank: 0
push_to_client: false
notice: false
response_status_code: "302"
response_headers:
Location: ${query.url}
response_body: ${header.say} ${what}
- name: other_rule
flag_format: other
rank: 1
push_to_client: false
notice: true
response_status_code: "200"
response_headers: { }
response_body: Hello Revsuit!
dns:
... ...
RevSuit a été extrait de mon projet de scanner, donc sa prise en charge native fonctionne avec les scanners.
Du point de vue de RevSuit, nous appelons un scanner un client.
RevSuit utilise les Server-sent Events HTTP (SSE) pour établir un canal de communication unidirectionnel avec le client.
L'API pour le canal est : /revsuit/api/events?message. Le client doit d'abord ajouter l'en-tête Token: votre_token à l'en-tête, puis accéder à l'API pour établir le canal. Lorsque la plateforme reçoit une nouvelle connexion, le flag capturé par la règle sera transmis au client via ce canal.
Voici une démo simple utilisant la bibliothèque sse de Golang comme exemple.
Comme indiqué ci-dessus, RevSuit prend en charge plusieurs clients, et chaque client à l'état connecté reçoit une poussée de flag, ce qui permet de prendre en charge le scan distribué.
Si vous ne souhaitez pas que chaque client reçoive toutes les poussées de flag, vous pouvez utiliser l'en-tête de requête Flag-Filter lors de la création d'une connexion sse pour définir le format (expressions régulières) du flag que vous souhaitez que ce client reçoive :
RevSuit stockera temporairement le flag dans la file d'attente lorsqu'il n'y a pas de connexion client et l'enverra lorsque le client se connectera, afin que vous n'ayez pas à craindre de manquer la vulnérabilité parce que le client se déconnecte. (Ceci est particulièrement utile pour découvrir les vulnérabilités déclenchées par un délai.)
Dans un scénario réel de scan de vulnérabilités, vous pouvez envoyer un grand nombre de payloads différents pour un seul point de vulnérabilité, et ils peuvent tous être valides, ce qui peut entraîner la réception de nombreuses requêtes par la plateforme de retour, bien qu'elles soient causées par la même vulnérabilité. Si vous ne souhaitez pas que le client reçoive autant de flags pour la même vulnérabilité, vous pouvez profiter de la fonctionnalité flagGroup du flagFormat de la règle.
FlagGroup est le contenu correspondant au groupe anonyme dans le champ flagFormat de la règle. La plateforme vérifiera le contenu correspondant dans le groupe, et le flag n'est poussé vers le client que lorsque le contenu (flagGroup) est capturé pour la première fois.
Par exemple, le scan SSRF.
Créez d'abord une règle comme suit :
http:
- name: ssrf
flag_format: (ssrf[a-z0-9]{6})[0-9]{1,3}
rank: 0
push_to_client: false
notice: false
response_status_code: "200"
response_headers: { }
response_body: "Here is a SSRF!"
Supposons que notre cible soit https://www.testvuln.com?url=api.com&p=useless, et pour SSRF nous avons 5 payloads. La requête finale envoyée par le scanner peut être ['https://www.testvuln.com?url=http://revsuit.com/ssrfa98oni1&p=useless','https://www.testvuln.com?url=http://revsuit.com/ssrfa98oni2&p=useless', ... ,'https://www.testvuln.com?url=//revsuit.com/ssrfa98oni5&p=useless']. Ils peuvent tous attaquer avec succès.
Cependant, comme un groupement anonyme est utilisé dans le flagFormat de la règle, la plateforme interrogera le flagGroup connecté, dans ce cas ssrfa98oni, et poussera le flag vers le client uniquement lors de sa première apparition, de sorte que le client ne recevra qu'un seul flag : ssrfa98oni1. Cela prouve déjà que le paramètre url de la cible est vulnérable.
Dans les scénarios réels de tests de pénétration, certaines tâches peuvent être effectuées facilement et rapidement en combinant et en faisant correspondre divers modules de RevSuit. Voici un exemple d'XXE aveugle dans une application web Java, montrant comment utiliser les modules HTTP et FTP de RevSuit, combinés avec des variables de template, pour effectuer rapidement un scan de ports.
Créez d'abord une règle HTTP pour retourner evil.dtd, personnalisez la réponse avec le contenu du dtd afin qu'il se connecte au service FTP de RevSuit, et utilisez des variables de template pour passer l'hôte et le port à scanner au FTP via l'utilisateur et le mot de passe FTP.
Créez ensuite une règle FTP qui reçoit l'hôte et le port à scanner à partir des variables de template utilisateur et mot de passe, définies sur l'adresse Pasv.
Utilisez ensuite BurpSuit pour lancer le scan, en définissant les paramètres d'hôte et de port dans l'URL evil.dtd pour définir la cible du scan de ports.
L'effet d'exécution est le suivant :
Étant donné que la connexion FTP échouera si l'Adresse Passive n'est pas accessible, nous pouvons déterminer si le port est ouvert ou non en fonction de si la connexion se termine normalement. Pour cet exemple, nous avons détecté avec succès que les ports 8005 et 8080 sont ouverts.
Un wiki plus détaillé est en préparation, vous pouvez explorer par vous-même en attendant.
Soumettez un problème ou contactez-moi via Weixin : TGk0bjA2Cg==
Ce projet s'inspire du code des projets remarquables suivants :
Merci à mon ami @E99p1ant pour toute l'aide et les conseils que j'ai reçus lors du développement de ce projet.
@Apache License 2.0