li4n0/revsuitRevSuit è una piattaforma di connessione inversa flessibile e potente progettata per ricevere connessioni dall'host target durante la penetrazione.
RevSuit è una piattaforma di connessione inversa flessibile e potente progettata per ricevere connessioni dal sistema target durante un penetration test. Attualmente supporta i protocolli HTTP, DNS, RMI, LDAP, MySQL e FTP.
Flessibile:
Potente:
Scarica l'ultima versione direttamente o compila seguendo questi passaggi:
git clone https://github.com/Li4n0/revsuit.git
cd revsuit/frontend && yarn install && yarn build
cd ../ && go build ./cmd/revsuit/revsuit.go
RevSuit genera un file di configurazione predefinito al primo avvio. Modifica il file di configurazione secondo le tue esigenze, quindi riavvia. Una descrizione dettagliata del file di configurazione è disponibile qui: Note di configurazione
Per determinare la posizione IP, è necessario utilizzare un database di geolocalizzazione IP. Per impostazione predefinita viene utilizzato QQwry, ma puoi modificare la configurazione per usare GeoIP. Se il database selezionato non è disponibile nella directory corrente o è stato aggiornato più di una settimana fa, RevSuit scaricherà automaticamente l'ultima versione. Se il download fallisce, il campo IpArea rimarrà sempre nullo.
$ ./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
Dopo l'esecuzione, puoi visitare il percorso /revsuit/admin/ del server HTTP e inserire il token per accedere al pannello di controllo.
Prendiamo come esempio la creazione di una regola HTTP:
Alcune note:
name e flagFormat della regola sono univoci.FlagFormat utilizza la sintassi delle espressioni regolari e, per protocolli diversi, i campi a cui si applica flagFormat sono diversi; puoi controllare i suggerimenti corrispondenti durante la creazione delle regole per maggiori dettagli.flagFormat; il risultato del gruppo corrispondente sarà usato come variabile template.Come mostrato di seguito, creiamo una regola che utilizza variabili template integrate e variabili template personalizzate del protocollo http, e la chiamiamo test_create_rule:
Quindi effettuiamo una richiesta che soddisfi la regola e osserviamo la risposta.
La richiesta verrà registrata contemporaneamente sulla piattaforma.
Se desideri ricevere notifiche per nuove connessioni sul tuo software per ufficio, puoi configurare l'indirizzo webhook del software pertinente nel file di configurazione e attivare l'interruttore Notice per la regola corrispondente. Attualmente sono supportati solo quattro tipi di software: dingtalk, wechat, lark, slack. (Il supporto per Discord e Telegram è in programma.)
Se stai migrando tra piattaforme o pulendo i dati, ricreare le regole può essere scomodo. Per questo la piattaforma supporta l'importazione e l'esportazione delle regole.
Il punto di accesso per questa funzione si trova in Settings>RULES.
Le regole vengono memorizzate in formato YAML per l'importazione/esportazione, come nell'esempio seguente:
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 è stato separato dal mio progetto scanner, quindi il suo supporto nativo funziona con gli scanner.
Dal punto di vista di RevSuit, chiamiamo uno scanner un client.
RevSuit utilizza HTTP Server-sent Events (SSE) per stabilire un canale di comunicazione unidirezionale con il client.
L'API per il canale è: /revsuit/api/events?message. Il client deve prima aggiungere l'intestazione Token: your token all'Header, quindi accedere all'API per stabilire il canale. Quando la piattaforma riceve una nuova connessione, il flag catturato dalla regola verrà passato al client attraverso questo canale.
Ecco una demo semplice che utilizza la libreria sse di Golang come esempio.
Come mostrato sopra, RevSuit supporta più client, e ogni client nello stato connesso riceve la notifica del flag, quindi è possibile supportare scansioni distribuite.
Se non desideri che ogni client riceva tutte le notifiche dei flag, puoi utilizzare l'intestazione della richiesta Flag-Filter quando crei una connessione sse per impostare il formato (espressioni regolari) del flag che quel client deve ricevere:
RevSuit memorizza temporaneamente i flag in una coda quando non ci sono client connessi e li invia quando un client si connette, quindi non devi preoccuparti di perdere vulnerabilità a causa della disconnessione del client. (Ciò è particolarmente utile per scoprire vulnerabilità che si attivano con ritardo.)
In uno scenario reale di scansione delle vulnerabilità, potresti inviare un gran numero di payload diversi per un singolo punto di vulnerabilità, e potrebbero essere tutti validi, con il risultato che la piattaforma di backlink riceve molte richieste, ma sono tutte causate dalla stessa vulnerabilità. Se non desideri che il client riceva molti flag per la stessa vulnerabilità, puoi sfruttare la funzionalità flagGroup di flagFormat della regola.
FlagGroup è il contenuto corrispondente al gruppo anonimo nel campo flagFormat della regola. La piattaforma controlla il contenuto corrispondente nel gruppo e il flag viene inviato al client solo quando il contenuto (flagGroup) viene catturato per la prima volta.
Ad esempio, scansione SSRF.
Prima crea una regola come la seguente:
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!"
Supponiamo che il nostro target sia https://www.testvuln.com?url=api.com&p=useless, e per la SSRF abbiamo 5 payload. La richiesta finale inviata dallo scanner potrebbe essere ['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']. Potrebbero avere tutti successo.
Tuttavia, poiché nella regola è stato utilizzato un gruppo anonimo in flagFormat, la piattaforma cercherà il flagGroup connesso, in questo caso ssrfa98oni, e invierà il flag al client solo al suo primo verificarsi, quindi il client riceverà un solo flag: ssrfa98oni1. Questo dimostra già che il parametro url del target è vulnerabile.
In scenari reali di penetration testing, alcuni compiti possono essere svolti facilmente e rapidamente combinando e abbinando vari moduli di RevSuit. Di seguito è riportato un esempio di XXE cieco in Java Web, che mostra come utilizzare i moduli HTTP e FTP di RevSuit, combinati con variabili template, per eseguire rapidamente una scansione delle porte.
Prima crea una regola HTTP per restituire evil.dtd, personalizzando la risposta con il contenuto del dtd in modo che si connetta al servizio FTP di RevSuit, e utilizza variabili template per passare Host e Porta da scansionare a FTP tramite l'utente e la password di FTP.
Quindi crea una regola FTP che riceve Host e porta da scansionare dalle variabili template utente e password, impostate su Pasv Address.
Poi utilizza BurpSuit per avviare la scansione, impostando i parametri host e porta nell'URL di evil.dtd per definire il target della scansione delle porte.
Il risultato dell'esecuzione è il seguente:
Poiché la connessione FTP viene interrotta se Passive Address non è raggiungibile, possiamo determinare se la porta è aperta o meno in base al fatto che la connessione termini normalmente. In questo esempio, abbiamo rilevato con successo che le porte 8005 e 8080 sono aperte.
Una wiki più dettagliata è in preparazione; puoi esplorare autonomamente nel frattempo.
Invia un issue o contattami tramite Weixin: TGk0bjA2Cg==
Questo progetto si ispira al codice dei seguenti progetti eccezionali:
Grazie al mio amico @E99p1ant per tutto l'aiuto e i consigli ricevuti durante lo sviluppo di questo progetto.
@Apache License 2.0