reverse_tcp o reverse_https?

painpills · 29 Febrero 2020, 04:30 AM

Hola, hace poco que inicie a familiarizarme con kali linux y sus herramientas. He estado creando Backdoors para android con mfsvenom utilizando el siguiente payload:

android/meterpreter/reverse_tcp

Pero hace poco me di cuenta viendo algunos tutoriales que algunas personas lo utilizan de esta manera:

android/meterpreter/reverse_https

Alguien podría aclararme que diferencia hay entre los dos?
O si es más conveniente usar uno u otro en casos específicos.

Cualquier otra información adicional me vendría de maravilla. Gracias.

@XSStringManolo · 29 Febrero 2020, 15:02 PM

HTTPS son 3 capas/protocolos. La capa TCP/IP, encima va la capa SSH y encima va la capa http. Las 3 juntas forman HTTPS.

Es decir, es lo mismo que un TCP inverso pero añade una capa de negociación de cifrado y utiliza el protocolo http. Esto significa que en vez de conectarse directamente en un stream de bytes sin cifrado, negocia el cifrado con tu cliente y una vez se establece una canal cifrado, realiza una petición a tu cliente utilizando el protocolo http.

El protocolo http es texto plano que sigue una forma estandarizada de comunicarse. Para simplificarlo mentalmente puedes entender como si http fuese un lenguaje de programación. Por ejemplo para conectarte a google.com mediante http tu navegador envía:

Código (http) [Seleccionar]

GET / HTTP/1.1
Host: google.com:80
Connection: keep-alive:
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.0) Chrome /Version ...
Accept: text/plain,text/html...
Acept-Language: es-Es...

Entonces google te podría responder algo como:

Código (http) [Seleccionar]

HTTP/1.1 200 OK
content-type: text/html

<html><body>Hola</body></html>

Esto significa que si la víctima instala un https inverso, va a hacer una petición para negociar la conexión (msfvenom tiene un cliente ssh y manejo de sesiones) una vez se establezca el canal seguro, te va a enviar la petición GET y tu le debes responder con un 200 OK enviándole una lista de comandos para que los ejecute o lo que sea.

Si quieres probar, puedes hacer lo siguiente desde la terminal:
netcat -v -l -k 127.0.0.1 8080

Con esto tienes un "servidor" a la escucha en la terminal. Si ahora vas al navegador y pones:
http://127.0.0.1:8080
Verás que te llega una petición http GET a la terminal.

El navegador se quedará como cargando a la espera de una respuesta HTTP. Podrías escribirla en la terminal para contestar o hacer cat a un archivo o cualquier historia.

Si ahora pones https://127.0.0.1:8080 verás como se envía unos "caracteres" raros. No es texto, son bytes, pero la terminal intenta traducirlo a texto y por eso se ve raro. Esta es la capa SSH sobre HTTP que sirve para que alguien inspeccionado el tráfico no pueda ver que es lo que se envia.
De esta forma, si la victima pusiese un analizador de tráfico en su red, no vería que pone: comandos: subir imágenes, descargar malware, ...
O si el antivirus lo hace, tampoco podrá detectar automáticamente la conexión robando datos personales.

painpills · 1 Marzo 2020, 16:34 PM

Hice la prueba con todo lo que me dijiste y realmente funciono, muchas gracias

Cita de: @XSStringManolo en 29 Febrero 2020, 15:02 PM
HTTPS son 3 capas/protocolos. La capa TCP/IP, encima va la capa SSH y encima va la capa http. Las 3 juntas forman HTTPS.

Es decir, es lo mismo que un TCP inverso pero añade una capa de negociación de cifrado y utiliza el protocolo http. Esto significa que en vez de conectarse directamente en un stream de bytes sin cifrado, negocia el cifrado con tu cliente y una vez se establece una canal cifrado, realiza una petición a tu cliente utilizando el protocolo http.

El protocolo http es texto plano que sigue una forma estandarizada de comunicarse. Para simplificarlo mentalmente puedes entender como si http fuese un lenguaje de programación. Por ejemplo para conectarte a google.com mediante http tu navegador envía:
Código (http) [Seleccionar] Expandir
GET / HTTP/1.1 Host: google.com:80 Connection: keep-alive: Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 6.0) Chrome /Version ... Accept: text/plain,text/html... Acept-Language: es-Es...

Entonces google te podría responder algo como:
Código (http) [Seleccionar] Expandir
HTTP/1.1 200 OK content-type: text/html <html><body>Hola</body></html>

Esto significa que si la víctima instala un https inverso, va a hacer una petición para negociar la conexión (msfvenom tiene un cliente ssh y manejo de sesiones) una vez se establezca el canal seguro, te va a enviar la petición GET y tu le debes responder con un 200 OK enviándole una lista de comandos para que los ejecute o lo que sea.

Si quieres probar, puedes hacer lo siguiente desde la terminal:
netcat -v -l -k 127.0.0.1 8080

Con esto tienes un "servidor" a la escucha en la terminal. Si ahora vas al navegador y pones:
http://127.0.0.1:8080
Verás que te llega una petición http GET a la terminal.

El navegador se quedará como cargando a la espera de una respuesta HTTP. Podrías escribirla en la terminal para contestar o hacer cat a un archivo o cualquier historia.

Si ahora pones https://127.0.0.1:8080 verás como se envía unos "caracteres" raros. No es texto, son bytes, pero la terminal intenta traducirlo a texto y por eso se ve raro. Esta es la capa SSH sobre HTTP que sirve para que alguien inspeccionado el tráfico no pueda ver que es lo que se envia.
De esta forma, si la victima pusiese un analizador de tráfico en su red, no vería que pone: comandos: subir imágenes, descargar malware, ...
O si el antivirus lo hace, tampoco podrá detectar automáticamente la conexión robando datos personales.

Test Foro de elhacker.net SMF 2.1

reverse_tcp o reverse_https?

painpills

@XSStringManolo

painpills