Bueno, aquí seguimos com el tema del Virtual Patching. Antes de seguir los dejo los enlaces de las 3 entradas anteriores para estar al tanto del tema que nos concierne.
1.- Parches y Virtual Patching
2.- Virtual Patching en funcionamiento (ParteI)
3.- Virtual Patching en funcionamiento (Parte II)
Siguiendo con la última entrada, si no contásemos con el dispositivo Fortigate, un atacante podría haber localizado nuestra vulnerabilidad y lanzar un “exploit” para poder aprovecharse de ella. Esto puede llevarse a cabo con el framework “Metaesploit” destinado a ese fin y con la ayuda de la GUI “Armitage” para un entorno más amigable.
Arrancaríamos la aplicación “Armitage” desde nuestra distribución Kali y seguiríamos los siguientes pasos:
Dar de alta al equipo con su dirección IP que ya la conoceríamos de los pasos anteriores:
Se realiza un escaneo para detectar puertos abiertos y posterior detección del Sistema Operativo:
Ahora se trata de localizar posibles ataques en función de los resultados obtenidos con anterioridad.
A partir de ahí se localiza la vulnerabilidad descubierta con el escáner “Nessus”.
La ejecutamos y comprometemos el objetivo.
Y una vez hecho esto, ya tendríamos nuestro equipo bajo control. Como vemos en la figura siguiente el icono del XP ha cambiado tornándose de color rojo y unos rayos.
Con el equipo comprometido, podríamos hacernos con el control del Windows XP mediante un visor VNC aún sin tenerlo instalado. El exploit genera un proceso en nuestro equipo Kali, al cual nos conectamos ejecutando el comando:
#vncviewer 127.0.0.1:[identificador]
Esto resulta especialmente grave ya que la tener acceso a la interfaz gráfica podríamos realizar alguna serie de cambios y modificaciones sobre las aplicaciones que estarían corriendo en esos instantes.
También, si lo deseásemos, podríamos hacernos con una consola remota tal y como aparece en la parte inferior y otras muchas acciones:
Sin embargo, si configurásemos el motor IDS/IPS para que bloquee en lugar de monitorizar. Esto es:
Y lanzamos de nuevo el ataque veríamos que éste no tiene éxito:
Y los logs generados indicarían el bloqueo:
Así pues queda claro la importancia de no sólo parchear nuestros equipos, sino además en el supuesto de que por distintas razones no podríamos llevarlo a cabo, la obligación de tener que tomar las medidas necesarias.
En entornos industriales podemos ver el esta situación de una forma más habitual que en entornos IT tradicionales ya que por un lado los ciclos de vida de los PCs industriales son mayores y por otro, dada la criticidad de las instalaciones gobernadas por éstos muchas veces no sea aconsejable instalar algún tipo de software tipo “Endpoint” que los bastione con funcionalidades Host IPS, Antivirus y Firewall.
Espero que el ejemplo haya sido de utilidad para tomar conciencia de esta situación y de las medidas que debemos tomar para securizar nuestros equipos.
Así pues nos vemos en la siguiente entrada, no sin antes invitaros a dejar vuestros comentarios. Desde ya muchas gracias.
Un saludo!!
Pingback: ¿Porqué es necesario NGFW en entornos ICS/SCADA? | Enredando con redes …
Estimado, claramente vemos como bloqueas el ataque con un IDS/IPS, pero la vulnerabilidad sigue existiendo. Entonces, mi pregunta concreta es, como defines el concepto de Virtual Patching, pues a mi entender, parchar virtualmente una vulnerabilidad, es aplicar una protección al HOST vulnerable, de tal manera de evitar que la vulnerabilidad sea explotada; pero según entiendo, lo que estás demostrando es, como bloquear el ataque perimetralmente. Puedes darme detalles del concepto que usaste para «Virtual Patching»? Gracias.
Hola Alexander:
Muchas gracias por tu comentario. Opino de la misma forma que tu, en cuanto al concepto original de «Virtual Patching». Sin embargo éste lo he orientado a los entornos Industriales. En éstos, el ciclo de vida de los equipos es más extenso que en entornos IT tradicionales con lo que es muy común que nos encontremos con equipos que tengan Sistemas Operativos obsoletos y sin soporte. Aún cuando sí que haya parches disponibles para corregir vulnerabilidades, puede ser difícil o incluso inviable su instalación por distintos motivos; los equipos no se pueden reiniciar, controlan infraestructuras críticas, los equipos tiene aplicaciones desarrolladas específicamente para ese entorno con lo que no se tiene la certeza que al instalar ese parche o Service Pack puedan hacerse cambio en el sistema y afectar a ese software, pérdida de garantía o soporte por parte de proveedores ya que se entiende que el equipo se ha podido modificar, etc. etc. Esto obliga a «externalizar» la forma en cómo prevenir la explotación de esas vulnerabilidades, empleando para ello equipos como NGFW o UTM con capacidades para detectarlas y mitigarlas. Efectivamente como dices, la vulnerabilidad sigue existiendo porque el equipo final no se toca pero al tener esos equipos delante con esa posibilidad, se previene esa explotación, con lo que conseguimos, sin intervenir en el HOST, el mismo efecto. Esto es, que algo o alguien comprometa nuestro equipos vulnerable, tenga o no soporte por parte del fabricante.
Muchas gracias de nuevo!
Un saludo.
Edorta
Pingback: Puerto espejo, un aliado a veces olvidado. | Enredando con redes …