El problema es que no son exactamente lo mismo y suele pasar, por supuesto en el momento más inoportuno, que se imprima o se visusalize mal un documento.
En este ejemplo, visualizado con sumatra, puede verse como el título del artículo, que se ve perfecto con Acrobat Reader, sale mal. Del mismo modo, otros visualizadores fallan en otros documentos.
Por lo tanto, en una empresa no es tan fácil como decir "pues usa otro". Al menos ciertas personas deberán tener Acrobat Reader por narices ...
(2) Mantener Acrobat Reader Actualizado a la última
Esto supone un montón de trabajo, puesto que salen actualizaciones continuamente y hay que probarlas antes de distribuirlas. Además, en casos como el que comentamos (0-day) no serviría para nada. Tampoco quiero decir que no se deba actualizar siempre que se pueda.
(3) Los usuarios sólo pueden salir a internet vía proxy
Todos los usuarios de la empresa, sin excepción (admins incluídos), deberían salir a internet vía proxy. ¿Por qué? Pues porque todos los exploits se preparan asumiendo una conexión directa a internet y adaptarlos a usar un proxy suele requerir bastante tiempo.
El problema es que ciertas personas suelen tener salida directa a internet:
- admins
- depto. seguridad
- depto. administración
...
Aquellas personas que necesiten total libertad navegando por internet NO deberían usar NAT, sino un proxy que les permita la bajada de ficheros, navegar por cualquier página, etc ... Es decir, un squid metiéndolos a ellos en lista blanca. De este modo, si alguno de ellos ejecuta sin querer un pdf, o lo que sea, infectado, el hacker todavía no podría establecer una shell inversa.
Pero ya hemos dicho que los exploits pueden reescribirse para que salgan vía proxy-HTTP y ofrezcan una shell inversa al hacker ...
(4) Filtrado del tráfico de salida hacia internet con mod_security
Supongamos que uno de los usuarios es infectado por un virus que inyecta código en iexplore y usa su navegación (vía proxy) para recibir comandos del hacker. Una buena solución sería filtrar todo el tráfico de salida y denegar todo lo que contenga comandos (telnet, ftp, ...). Esto hace mucho más complicado el establecer una shell inversa saliendo por el proxy.
Vamos a repasar brevemente cómo se hace esto:
Instalaremos un apache con modsecurity y configuraremos el apache para que haga de proxy. Para ello, necesitamos los siguientes módulos cargados en el httpd.conf:
mod_proxy
mod_proxy_http
mod_proxy_connect
mod_negotiation
Además, necesitamos configurar el apache para que haga de proxy, añadiendo esto al httpd.conf:
<IfModule mod_proxy.c>
ProxyRequests On
<Proxy *>
Order deny,allow
Deny from all
Allow from 192.168.1.0/24
</Proxy>
Además, necesitaremos quitar reglas del modsecurity, porque si no nuestros usuarios apenas podrán navegar. En particular, borraremos todo lo que corresponde a XSS y SQL-injection (también dentro de modsecurity_crs_40_generic_attacks.conf), puesto que no son necesarias, así como las de anomalías en el protocolo HTTP. Yo he dejado estas:
modsecurity_40_generic_attacks.data
modsecurity_50_outbound.data
modsecurity_crs_40_generic_attacks.conf
modsecurity_crs_45_trojans.conf
modsecurity_crs_47_common_exceptions.conf
modsecurity_crs_48_local_exceptions.conf
modsecurity_crs_49_enforcement.conf
modsecurity_crs_50_outbound.conf
Y todavía se puede afinar más ... Con esto, funciona bien gmail, que es un buen indicativo de que todo irá bien.
CONCLUSIONES
Muchas veces nos centramos en securizar la DMZ y nos olvidamos del vector de ataque más simple pero a su vez más eficiente ... el usuario. Tanto Acrobat Reader como Ms Office son líderes en cuanto a la aparición de 0-days y son, por lo tanto, dos importantes vías que intentar a la hora de atacar una empresa.
Nuestros esfuerzos para solucionar esto, aparte de parchear el software del usuario (muchas veces inviable), deben estar centrados en hacer MUY complicado que un exploit pueda establecer una shell inversa, y que mejor forma que filtrar todo el tráfico de salida en busca de comandos como telnet, dir, ...
Saludos y hasta pronto.
