Cercando di eseguire il tunneling di una shell inversa da una rete interna

4

Sto facendo pratica con un pentest e mi sto bloccando cercando di ottenere una shell inversa interattiva da una macchina interna alla mia macchina attaccante.

Questo è quello che ho fatto finora:

Me (attaccante): 67.67.67.67 (qualche ip pubblico)
App Web (vittima): 68.68.68.68 (alcuni IP pubblici)
Macchina interna (server Web): 10.1.1.80

Informazioni sul server Web:

  • CentOS
  • Apache
  • PHP
  • mysql

Ho trovato una vulnerabilità di SQL Injection nell'applicazione Web in 68.68.68.68 e l'utilizzo di sqlmap con l'opzione --os-shell. Sono riuscito a ottenere una shell Web tramite questa applicazione come utente apache. Poi ho eseguito il comando 'ifconfig' che mi ha dato un ip interno 10.1.1.80.

Il mio obiettivo è ottenere una shell interattiva, quindi ho cercato di utilizzare una shell inversa per eseguire il tunneling dalla rete interna al mio computer di attacco pubblico. Credo che il problema che sto incontrando sia il firewall.

Questo è quello che so (usando la shell Web):

  • Impossibile visualizzare le regole del firewall

  • Posso caricare file tramite la shell Web, ma non posso scaricare o utilizzare HTTP / HTTPS direttamente dalla macchina interna tramite la shell Web in modo che la shell inversa http non funzioni.

  • Ho anche provato a eseguire "host google.com > /tmp/output.txt 'attraverso la shell Web che non fornisce alcun output che mi induce a credere che DNS non sia consentito neanche.

  • Ho anche provato l'ascolto della mia shell inversa su numerose porte popolari, il che mi fa pensare che il firewall stia eseguendo un'ispezione approfondita dei pacchetti, motivo per cui non consentirà il tunneling su queste porte.

  • L'unica cosa che ha funzionato è stato il ping della mia macchina hacker pubblica dalla macchina interna attraverso la webshell che mi fa pensare che potrei fare il tunnel di una shell inversa usando ICMP. Ho trovato uno strumento chiamato 'icmpsh', ma sfortunatamente il client che gira sulla macchina vittima è scritto solo in C per Windows. Ho pensato che avrei usato 'wine' per fare ciò sulla scatola interna di Linux, ma non posso installare nessun programma da internet e caricare vino attraverso il webshell ha portato a molti errori di dipendenza. Quindi il mio prossimo piano era scrivere la mia shell inversa ICMP in puro python ma usare SOCK_RAW richiede sudo.

La mia domanda è: pensi che l'ICMP sia il modo di scavare un guscio inverso o ci sia un protocollo diverso da usare o testare? Forse c'è una versione portatile di vino o equivalente che posso caricare?

PS: Questo è per la pratica quindi è possibile che l'installazione sia raggiungibile

    
posta user0809452345 16.10.2017 - 22:11
fonte

1 risposta

2

Ho risolto il problema.

TL; DR: TCP 53 era disponibile per il traffico in entrata / in uscita

Controllando quali protocolli sono stati autorizzati attraverso il firewall, stavo controllando il DNS usando 'host google.com' e 'host -T google.com' e 'scavare @ 8.8.8.8 google.com' e quando non l'ho fatto ricevere la risposta prevista, supponevo che ciò significasse che il DNS non era permesso. Dopo essere tornato alla macchina un paio di giorni più tardi ho deciso di installare 'nc -nvlp port #' sulla mia macchina attaccante e provare a connettermi dalla macchina vittima usando più porte e per lungo tempo è stato in grado di connettermi tramite la porta 53. Quindi da lì ho impostato il mio payload, ottenuto la mia shell e poi i privilegi escalation.

Quindi la lezione che ho imparato non è basata su risultati di un singolo strumento o metodo. Prova più di un metodo.

Come pensavo da parte, se qualcuno ha qualche idea sul perché i miei comandi 'dig' e 'host' non funzionassero anche se avrebbe accettato il traffico su 53, sarebbe fantastico. Immagino che abbia permesso il traffico su 53 solo non specificamente DNS?

Grazie per i suggerimenti

    
risposta data 22.10.2017 - 04:10
fonte