elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Curso de javascript por TickTack


+  Foro de elhacker.net
|-+  Seguridad Informática
| |-+  Seguridad (Moderador: r32)
| | |-+  Mantener anonimáto con TOR desde el punto de vista de un atacante(ideas y dudas)
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: Mantener anonimáto con TOR desde el punto de vista de un atacante(ideas y dudas)  (Leído 2,150 veces)
Skali

Desconectado Desconectado

Mensajes: 100



Ver Perfil
Mantener anonimáto con TOR desde el punto de vista de un atacante(ideas y dudas)
« en: 31 Agosto 2018, 05:00 am »

Hola gente! Buen día! Luego de las conversaciones en el foro de hace una semana sobre TOR y privacidad, decidí instalar Tortilla, una herramienta de la que había leído pero no había probado. Seguí los pasos de nuestro colega #!drvy, a través de éste post:

https://foro.elhacker.net/seguridad/tutorial_tortilla_tor_privacidad-t409824.0.html;msg1970898


y logré instalarlo satisfactoriamente, pero ahora me surgen algunas ideas, y varias dudas que me gustaría plantear y debatir... (tengan en cuenta que no pretendo implementar ninguna de las ideas que voy a mencionar al final, solo quiero informarme y sacarme dudas):

Mientras se utilice Tortilla es imposible levantar un servidor de cualquier tipo en la VM que utiliza la interfaz de red de Tortilla, asi como utilizar metasploit escuchando en un puerto en espera de una shell inversa, ya que, la única forma de conectarnos a internet es cuando nosotros somos quién inicia la conexión, ya que sino, en caso de que alguien se quiera conectar a un servicio nuestro, como nos identificaría? La IP privada de la VM es la misma que la de la máquina host, y la pública es la del exit node de tor... Entonces supongo que el que tendría que estar configurado para escuchar en un puerto y devolvernos la conexión a nosotros sería el exit node, pero al no controlarlo, se haría imposible. Corríjan por favor cualquier conclusión incorrecta de éste párrafo.

Para poder controlar remotamente otra PC previamente comprometida, la forma sería a través de una conexión directa (y no inversa), y que la PC que queremos controlar, sea la que esté escuchando en un puerto, ya que de ésta forma todo funciona perfectamente, y la PC remota vería la IP del exit node de tor y no la nuestra, como se esperaría...

Nota: cuando hablo de conexión directa, me refiero a lo contrario de la inversa, es decir, que seamos nosotros el que inicia la conexión y el destino quién esté escuchando, aunque la conexión directa la hagamos a través de TOR...

Como sabemos, conectarnos de forma directa a una PC que hayamos infectado (dejándola en escucha y siendo nosotros quien inicia la conexión), no siempre es tan sencillo, ya que puede ser que exista un NAT, y necesitemos acceder al router de la red de la pc remota para configurar el forwarding. A veces si es muy facil ya que se deja el password del router por defecto, o habilitado UPnP, lo que nos permite hacer forwarding sin saber el password, asi como posibles vulnerabilidades en los routers...

Se me ocurrió un esquema, que nos permitiría controlar cómodamente dispositivos infectados teniendo en cuenta el NAT, y manteniendo nuestro anonimato. Estoy seguro que  el esquema que yo voy a plantear es usado por muchos atacantes, pero quiero contarlo para poder debatir sobre él luego:



Como ven, la idea es que si logramos el acceso a algún servidor (preferentemente con Linux, que tenga poco tráfico y no sea muy supervisado), si éste no se encuentra detrás de un NAT, (o bien logramos controlar al NAT), podemos dejarlo escuchando en un puerto, que luego al conectarnos, nos daría una shell. Ésta conexión se podría realizar tranquilamente a través de TOR. Luego, los demás dispositivos que controlemos, que puedan estar detrás de un NAT, haremos que le envíen una reverse shell al servidor Linux que controlemos (nuestro "centro de operaciones"). De ésta forma, podemos controlar a los dispositivos finales, a través de nuestra conexión directa con el "centro de operaciones", sin necesidad de enfrentarse con el NAT de todos los dispositivos bajo nuestro control. Me parece importante tener más de un servidor de "centro de operaciones", y que los dispositivos finales se traten de conectar a los dos, para descentralizar un poco, y que si el día de mañana pasa algo en alguno de los servidores Linux, todavía tengamos el otro. Los comandos que puse de nc en la foto, son para tomar como referencia, pero podríamos usar metasploit, o en caso de los dispositivos finales, hacer que envíen la reverse shell cada X segundos, para mantener el acceso efectivamente.

Bueno, ahora que plantié dicho esquema, me gustaría discutir sobre él. Mis preguntas son: éste esquema es muy usado por atacantes? Que cambios le harían? Existe alguna alternativa mejor? Si un administrador de cualquier dispositivo final inspecciona el tráfico, vería tráfico entrante y saliente hacia el Linux de nuestra base de operaciones... El dueño del servidor, podría tener que pagar el precio de nuestras malas acciones?

Gracias desde ya!




« Última modificación: 2 Septiembre 2018, 02:04 am por Skali » En línea

Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  

Mensajes similares
Asunto Iniciado por Respuestas Vistas Último mensaje
Leer fichero desde un punto a un punto(Python)
Scripting
¨°o.O (ßa¢Kg|姧) O.o° 3 5,019 Último mensaje 29 Marzo 2010, 21:05 pm
por Novlucker
La web desde el ojo de un atacante... « 1 2 »
Nivel Web
fede_cp 10 5,690 Último mensaje 4 Abril 2010, 22:01 pm
por fede_cp
Uso de Tablet desde punto de vista Hacking
Dudas Generales
..:ALT3RD:.. 1 4,557 Último mensaje 26 Septiembre 2011, 22:33 pm
por Aberroncho
Tails 0.10, una distribución para mantener el anonimato en la red
Noticias
wolfbcn 0 2,766 Último mensaje 14 Enero 2012, 17:30 pm
por wolfbcn
Desactivar voltaje USB (planteamiento desde otro punto de vista)
Programación General
Haskell++ 2 3,355 Último mensaje 6 Septiembre 2012, 02:29 am
por sistemx
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines