Realizando Pivoting sobre un EC2
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
¿Crees tener lo que se necesita para ser un experto en Pentesting contra AWS? Si nuestro libro te abrió los ojos a las posibilidades de la ciberseguridad ofensiva o si ya cuentas con habilidades en este campo, es momento de subir de nivel. Te retamos a certificarte en el CPNA - Curso Profesional de Pentesting Contra AWS. No será fácil: te enfrentarás a un examen riguroso de 12 horas donde deberás hackear una infraestructura completa alojada en AWS. ¿Listo para el desafío? Acepta el reto y demuestra tu verdadero potencial.
Después de desplegar el laboratorio, ejecutamos el siguiente comando:
Como podemos apreciar hemos encontrado dos conexiones de VPC y son:
10.1.0.0/16 – (vpc-0788a2b695ffbf6ae)
10.2.0.0/16 – (vpc-075cb81f5ac4a4d20)
A continuación, se enumeran las subredes de dichos VPC que hemos encontrado previamente:
Ahora que hemos identificado las subredes para cada VPC, vamos a identificar las tablas de enrutamiento de networking configuradas para cada VPC:
En la evidencia previa, podemos identificar que la subred 10.1.0.0/16 tiene acceso a la otra subred 10.2.0.0/16
Algo que también puede ser importante, es revisar los ACL para el VPC:
Algo que hemos conseguido información relacionada a los VPC, vamos a identificar que EC2 hace parte de dichos VPC:
En el VPC vpc-075cb81f5ac4a4d20, Vemos que la instancia NO tiene una IP publica y por lo tanto no tenemos acceso directo a esta desde internet.
En el VPC vpc-0788a2b695ffbf6ae, Vemos que la instancia tiene una IP publica y por lo tanto SI tenemos acceso directo a esta desde internet.
Si durante un pentesting se logra comprometer una EC2, es recomendable revisar si existen otros servidores a los que se tenga alcance con el objetivo de intentar movernos lateralmente contra el servidor identificado.
En los pasos previos, hemos enumerado los diferentes VPC y sus subredes e incluyendo las tablas de enrutamiento para cada una.
Ahora sabiendo que tenemos acceso a una instancia (i-0f96192e594ab7200); y hemos identificado la existencia de otra instancia (i-07076437e17354e9f) en otra VPC a la que tenemos alcance desde nuestra EC2 comprometida; vamos a validar si podemos realizar una conexión SSH.
Primero nos conectamos a la primera instancia utilizando su dirección IP Publica:
En ciertas ocasiones, los arquitectos de AWS o los desarrolladores otorgan acceso internamente a sus instancias por medio de la misma llave SSH y como pudimos apreciar en el retorno de los comandos previos ambas instancias pueden ser accedidas por medio de la llave privada llamada id_rsa.
Desde nuestra Shell inicial, vamos a ingresar el siguiente comando para conectarnos a la otra instancia por medio de SSH:
En la evidencia previa, se puede apreciar la conexión por SSH contra el otro equipo desde nuestra primera instancia.
Ahora suponiendo que identificamos el puerto 80 corriendo el servicio HTTP en la instancia inaccesible con IP 10.2.1.83 y queremos acceder desde nuestro navegador obtendremos un error debido a que no tenemos alcance.
Para este ejercicio, vamos a iniciar el servicio de HTTP por medio de Python:
Es importante tener en nuestro grupo de seguridad para la instancia inalcanzable la siguiente configuración:
Luego de la configuración previa, podríamos hacer una petición GET solo desde la instancia inicial.
Vamos a realizar un Port Forwading con SSH dinámico utilizando proxychains.
Primero ejecutamos el siguiente comando para que nuestro tráfico utilice el puerto por defecto de proxychains:
Luego de lo anterior, ya tenemos alcance contra el servidor de una manera directa desde nuestra maquina atacante por medio de proxychains:
En la evidencia previa, podemos apreciar que Nmap tiene alcance y detecto el puerto 80 que está corriendo en la instancia 10.2.1.83.
Cabe resaltar, que este análisis de puertos fue realizado desde nuestra maquina atacante.
