Aquí volvemos con la segunda parte. Como dijimos en el post anterior Syslog, ¿amigo o enemigo? Parte I, a continuación veremos que también puede tener inconvenientes …
Ahí va la primera!
Syslog emplea UDP, concretamente el puerto 514. Al emplear UDP podríamos generar fácilmente paquetes manipulados haciéndonos pasar por el equipo legítimo. Éstos los enviamos al servidor y conseguiríamos confundir, o engañar, a los administradores informando de supuestas actividades en los equipos que en realidad no están sucediendo. Y ¿con qué fin? Por ejemplo obligar a un administrador a que se conecte al supuesto equipo que está fallando. Ahí podríamos llevar a cabo un MITM o cualquier otro ataque factible que nos permitiese capturar, por ejemplo, las credenciales de este administrador que por otro medio no podríamos. Y aquí es donde quedaría incluida la idea que hablaba al inicio, la 1. Es decir, si directamente no podemos hacernos con ese usuario y contraseña, vamos a generar falsas alarmas para obligarle a que se conecte y mediante otro ataque cumplir con el objetivo inicial.
Vale, y esto, ¿cómo lo hacemos?
Pues con el generador de paquetes Mausezahn. No viene instalado por defecto en Kali, pero desde el instalador de software lo podemos hacer fácil.
Aquí os dejo algunos tutoriales que he encontrado, Link 1 , Link 2 , Link 3
Supuesto apagado de varias interfaces.
O bien podríamos decir que un Switch tiene una temperatura > 70º C. Aquí le introduciremos un retardo de 60 segundos entre mensaje y mensaje de forma indefinida. Ver columna de tiempo, la diferencia es de un minuto.
La segunda desventaja…
Basándonos en la primera, ¿qué pasaría si en lugar de mandar paquetes sueltos mandásemos 30, 50, 100, 200? ¿y si encima lo hiciésemos a intervalos distintos? Y para más difícil, que pasa si además lo hacemos supuestamente desde equipos distintos? Pues yo me volvería loco. Imaginaros la situación, empezar a recibir mensajes (que de normal no llegan) desde distintos equipos de la red. Vamos sembramos la confusión, y entre esa confusión un atacante podría iniciar otro ataque contra otro equipo. Es decir, el atacante desvía la atención del administrador hacia unos equipos que se supone están fallando, pero que en realidad no es así, y de mientras inicia un ataque contra otro sistema. Y además si éste equipo atacado genera algún tipo de alarma es más probable que pase desapercibida ya que estaremos generando un montón de otras falsas. Y aquí es donde incluiría la segunda idea, la 2. Esto es, generamos mucho ruido, provocamos que salten las alarmas y entre todas ellas nos camuflamos.
Estos ejemplos los he hecho utilizando un router que es lo que tengo más a mano, pero bien podría ser otros dispositivos.
Por ejemplo, los autómatas industriales también soportan Syslog. En el siguiente enlace podréis encontrar como lo aplican los de la gama Siemens S7-300.
¿Y si en lugar de mensajes de un router mandamos haciéndonos pasar por un autómata? Os imagináis que pasaría si en una estación de transformación llegasen mensajes diciendo que una línea eléctrica se ha caído cunado no es así? ¿O que una entrada de un autómata está DOWN mientras que todo sigue funcionando?
Por ejemplo podríamos hace pensar que se podría estar llevando un ataque aprovechando un vulnerabilidad de los autómatas cuando no es así. Esto seguramente cuando poco sembraría una confusión que conllevaría un revuelo en mayor o menor medida y quién sabe si la toma de alguna decisión si haber ninguna necesidad. Ni qué hablar que tal vez paralelamente sí que estuviesen llevando un ataque en sí mismo.
En fin es para pensarlo, bueno o malo que cada cual emplee Syslog según sus criterios y decida si es un amigo un enemigo.
Hola de nuevo, aquí estamos con otra entrada. A decir verdad, me cuesta un poco la manera de catalogarla si como un ataque en sí mismo o bien como como un ataque que sirva de pantalla a otro. Bueno, principio quieren las cosas, así que vamos a ello.
Vamos a dejar momentáneamente las cuestiones técnicas a un lado para charlar un poco de otros conceptos. Cuando se trata de auditar o realizar un test de penetración no siempre hemos de ir directos contra nuestro objetivo. Esto es, quizás debemos comprometer primero un equipo o sistema y luego desde éste, dirigirnos al objetivo en cuestión. ¿Qué es lo que quiero decir con esto? Que muchas veces deberemos dar un “rodeo” o dar pasos “intermedios” para conseguir nuestro fin. Este es el concepto número 1.
Una vez dentro de ese proceso de “pentesting” una premisa es hacer el menor “ruido” posible para no ser descubierto ya que eso mismo es lo que trataría de hacer un atacante. Un atacante, procurará ser sigiloso, discreto, cauto, no sólo para no levantar sospechas sino para que las distintas medidas y equipos de seguridad no hagan saltar alarmas y delaten su presencia. Obviamente, no empleará configuraciones “por defecto” sino que modificará los parámetros, campos, según sus necesidades. Sin embargo, esto no tiene por qué ser siempre así. Me explico. La idea es que no te detecten, pero esto también puede lograse haciendo mucho ruido y colándote entre la multitud. Imaginemos a un ladrón que ha conseguido burlar las medidas de seguridad de un banco; se hace con el botín; tira una bomba de humo o gas lacrimógeno y hace que todos los clientes entren en “modo pánico” y salgan despavoridos de la oficina, entre ellos, el ladrón. Este es el concepto número 2.
Bueno, se me olvidaba. Para que el ladrón burle las medidas de seguridad una buena opción podría ser suplantar la identidad (spoofear) de algún miembro del personal del banco. Este es el concepto número 3.
Vale, vale, tanto rollo ¿para qué? ¿Qué tiene que ver esto con Syslog? Venga va, ahora sí nos metemos con las cuestiones técnicas.
Syslog es un protocolo con el que podemos hacer que un equipo o sistema (cliente) envíe a un servidor mensajes que informen sobre eventos en él. Entre otras cosas, podría ser:
1.- Acceso correcto o incorrecto al sistema.
2.- Anomalías de algún tipo.
3.- Cambios en las configuraciones.
4.- Errores en los sistemas.
5.- Otros…
Existen servidores de pago y también algunas versiones gratuitas como Free Kiwi Syslog Server u otros que podréis encontrar en Sourceforge. Iros allí y buscar por la palabra, como es lógico, Syslog.
Para esta entrada voy a tener 3 equipos. Un router virtualizado con GNS3, un servidor Syslog con el software Free Kiwi Syslog Server y un equipo con Kali Linux. Estos últimos en máquinas virtuales.
Aquí os dejo una muestra de lo que sería mensaje de un login del usuario “netadmin” al router.
Deshabilitar y habilitar de la interfaz Fastethernet 1/1.
El tipo de mensaje que recibamos irá en función del nivel de aviso que queramos que se nos comunique. A más nivel, mayor control de lo que pasa pero también tendremos más cantidad de mensajes y, dependiendo el número de equipos, que tengamos pues puede llegar a ser un poco caótico.
Esto es yendo a buenas pero ¿qué pasaría si alguien intentase lanzar un ataque para ganar acceso a nuestro equipo mediante la herramienta THC-Hydra?
Por cada intento de conexión recibiremos un aviso.
Una de las posibilidades que nos puede ofrecer el software de servidor Syslog es que cada aviso que recibamos podremos enviarlo a su vez por correo electrónico, lo cual puede llegar a ser de gran utilidad si creamos una cuenta específica para el servidor y recibimos los avisos a nuestro correo. Lo digo no para dar más trabajo sino para esos puestos que requieran hacer guardias o disponibilidad 24×7, etc.
Sin embargo, ¿son todo ventajas? Tal vez no, puede haber algún inconveniente. Eso lo dejamos para la próxima….
Aquí estamos con otra entrada, la primera en este 2013. A ver si gusta y se convierte en un buen presagio para el resto del año.
En esta ocasión vamos a meternos con DNS. Como muchos sabréis DNS es un protocolo que permite asociar, de forma jerárquica, nombres de dominio a IPs así como identificar hosts dentro de estos dominios. Para los que no lo conozcan os dejo el enlace de la Wikipedia donde se habla de este protocolo, pinchar aquí.
Dejando de lado el servicio que presta en Internet, vamos a ceñirnos esta vez al ámbito empresarial. Muchas organizaciones contarán con su propio servidor DNS para resolver los nombres de equipos en direcciones IP para un dominio concreto, que es al fin y al cabo, lo que emplean los sistemas operativos y las aplicaciones para establecer conexiones contra otros hosts, principalmente servidores. En este caso se utilizará DNS sobre protocolo UDP y el puerto 53. Cabe mencionar que en muchos casos el servidor DNS presta servicios de DHCP, o viceversa. Si bien servidores, impresoras, u otros equipos tendrán un direccionamiento estático, los equipos finales podrán emplear un direccionamiento asignado mediante DHCP. Si ambos servicios son prestados por el mismo equipo, cuando la parte de DHCP asigne una dirección IP, automáticamente se generará un registro DNS para ese equipo.
Sin embargo también existe la posibilidad de utilizarlo sobre TCP y en el mismo puerto. Pero ¿para qué se emplea? Pues para realizar Transferencias de Zona, por ejemplo de un servidor primario a uno secundario. Es decir, habrá un servidor primario DNS al que le llegan todas las consultas de los clientes (UDP:53); pudiendo existir otro, para que el caso de que el primero caiga, sea el secundario el que continúe resolviendo los nombres de máquina y así garantizar el servicio. Lógicamente el servidor secundario tiene que saber en todo momento las entradas de IPs, nombres de máquina, etc. que maneja el servidor primario. Esto se realiza mediante lo que se denomina “Transferencia de Zona”. Esto es, el servidor secundario abre una conexión mediante TCP al puerto 53 del servidor primario y le solicita todos los registros de nombres para el dominio de la empresa.
Como se puede ver un servidor DNS es una gran fuente de información, y como tal también hay que tomar medidas en lo que a la seguridad se refiere. ¿Por qué? Porque si no restringimos de alguna forma y mantenemos el servidor primario con el puerto TCP:53 abierto, “alguien” con no muy buenas intenciones podría detectarlo y solicitar realizar una trasferencia de zona y hacerse con todo el direccionamiento de nuestro dominio sin necesidad de lanzar ni un solo escaneo para detectar hosts o servicios. Aparte hay que tener en cuenta que DNS permite asociar un texto a un registro de equipo, generalmente utilizado para añadir una descripción a éste.
A continuación veremos cómo se podría desarrollar esto mismo, por supuesto en un entorno de test.
Para ello tendremos un laboratorio virtual creado con GNS3 y VMware. Tendremos 3 switches, dos de core y uno de acceso. A este último irán conectados 3 máquinas, un XP, un Windows 7 y la máquina atacante que será un Backtrack 5 R3. Y por supuesto un servidor DHCP/DNS para asignación de IPs y resolución de nombres. Quedaría algo así:
Si mantenemos nuestro Wireshark arrancado mientas ejecutamos “dhclient eth0” para solicitar una IP y capturamos el tráfico resultante veremos entre otros datos que nos proporciona DHCP el nombre del dominio en el que nos encontramos, es decir edorta.lcl.
Como podemos apreciar nuestro servidor de nombres (DNS) tiene la IP 192.168.10.5, que curiosamente es la misma IP desde la cual se nos asigna la nuestra, la 192.168.10.20. O sea, DHCP y DNS están el mismo equipo. A continuación lanzaremos nmap para saber sobre qué protocolos de Capa 4 tiene abierto el puerto 53.
root@bt:~# nmap -sU -sS -p53 192.168.10.5Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-05 19:47 CET
Nmap scan report for XXXXXXXX.edorta.lcl (192.168.10.5)
Host is up (0.00099s latency).
PORT STATE SERVICE
53/tcp open domain53/udp open domain
MAC Address: 00:0C:29:FB:52:A8 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
¡Perfecto! Tenemos el TCP:53 “open” con lo que vamos a tratar si podemos llevar a cabo la transferencia de zona. Para ello utilizaremos la herramienta “dig”. Dig, es una utilidad que nos permitirá realizar consultas DNS de distintas formas y ajustar las opciones que nosotros deseemos. Entre ellas está la de llevar a cabo una transferencia de zona. Esto se realiza ejecutando:
root@bt:~# dig edorta.lcl axfr
; <<>> DiG 9.7.0-P1 <<>> edorta.lcl axfr
;; global options: +cmd
edorta.lcl. 259200 IN SOA XXXXXXX.edorta.lcl. hostmaster.edorta.lcl. 2012123076 28800 7200 2419200 86400
edorta.lcl. 259200 IN NS XXXXXXX.edorta.lcl.
edorta.lcl. 259200 IN A 192.168.10.5
edorta.lcl. 259200 IN A 192.168.11.5
bt.edorta.lcl. 900 IN A 192.168.10.20
bt.edorta.lcl. 900 IN TXT «00445d89f28c340342881e7f7a4605c117»
core-of-01.edorta.lcl. 259200 IN A 192.168.5.10
core-of-01.edorta.lcl. 259200 IN TXT «switch» «01» «de» «core» «de» «oficinas»
core-of-02.edorta.lcl. 259200 IN TXT «switch» «02» «de» «core» «de» «oficinas»
core-of-02.edorta.lcl. 259200 IN A 192.168.5.11
core-srv-01.edorta.lcl. 259200 IN TXT «switch» «01» «de» «core» «de» «servidores»
core-srv-01.edorta.lcl. 259200 IN A 192.168.5.13
core-srv-02.edorta.lcl. 259200 IN TXT «switch» «02» «de» «core» «de» «servidores»
core-srv-02.edorta.lcl. 259200 IN A 192.168.5.12
fw-01.edorta.lcl. 259200 IN TXT «Firewall» «Granja» «Servidores»
fw-01.edorta.lcl. 259200 IN A 192.168.100.254
IPS-01.edorta.lcl. 259200 IN TXT «IPS» «Granja» «de» «servidores»
IPS-01.edorta.lcl. 259200 IN A 192.168.100.253
of-01.edorta.lcl. 259200 IN A 192.168.10.10
srv-01.edorta.lcl. 259200 IN TXT «switch» «de» «la» «granja» «de» «servidores»
srv-01.edorta.lcl. 259200 IN A 192.168.100.10
srvficheros.edorta.lcl. 259200 IN TXT «Servidor» «de» «ficheros»
srvficheros.edorta.lcl. 259200 IN A 192.168.100.5
XXXXXXX.edorta.lcl. 259200 IN A 192.168.1.1
XXXXXXX.edorta.lcl. 259200 IN A 192.168.10.5
XXXXXXX.edorta.lcl. 259200 IN A 192.168.11.5
edorta.lcl. 259200 IN SOA XXXXXXX.edorta.lcl. hostmaster.edorta.lcl. 2012123076 28800 7200 2419200 86400
;; Query time: 13 msec
;; SERVER: 192.168.10.5#53(192.168.10.5)
;; WHEN: Sat Jan 5 19:47:19 2013
;; XFR size: 27 records (messages 1, bytes 835)
¡Tranferencia realizada! A continuación os dejo la captura en la que se puede apreciar el “Three Way Handshake” de TCP desde Backtrack hacia el servidor, paquetes 6 al 8. Una vez establecida la conexión el PC realiza la consulta para la transferencia de zona, paquete 9. Y finalmente la respuesta del servidor, paquete 11, y que corresponde con la información que sale en la ventana de abajo y donde se pueden ver listados todos los equipos.
Como podemos ver tenemos los registros de los equipos que figuran en la imagen del escenario y alguno más que he metido a propósito para agregar más contenido al ejemplo. A partir de aquí un atacante podría saber los nombres de equipos, su descripción si la hubiese, IPs, redes implementadas, y otra información proporcionada por los distintos registros que emplea DNS como CNAME, MX, NS, etc.
Fijaros de qué manera más tonta, un atacante se ha ahorrado tener que lanzar escaneos para localizar equipos, servicios, etc. y así seguir avanzando en sus propósitos. Aparte, ha minimizado el riesgo de ser detectado por algún IPS o que se logue en algún firewall el descarte de paquetes de las sondas que envía NMAP. Ahora podrá ir a tiro fijo sobre un equipo. Como decía, existen algunos registros que nos indican la funcionalidad de los equipos. Tal es el caso de MX que se emplea para identificar los servidores de correo electrónico asociados a ese dominio. Por tanto, ¿tiene mucho sentido lanzar a destajo sondas para ver si tiene otros servicios abiertos con el riesgo que esto supone? Si sabemos que es un servidor de correo, lanzará las sondas a los puertos que sabemos emplea ese servicio. A ver, un servidor puede tener varios servicios corriendo en un mismo equipo, pero bueno primero vayamos contra los puertos que sabemos que puede estar utilizando. ¿Que no puede cumplir con sus objetivos? pues entonces ya realizará un escaneo para ver si corre otro servicio más vulnerable, comprometerlo y llevar a cabo otras acciones. Otro ejemplo, en la captura vemos que hay un equipo llamado “srvficheros” con una descripción acorde a su nombre. Por tanto, ¿tiene mucho sentido lanzar escaneos contra un servicio IPSEC, aplicación OpenVPN, detección de Web Proxy, etc? Mejor hacerlo al TCP:139,445; ¿no? A partir de estos detectar el sistema operativo, número de saltos, etc.
En cualquier caso lo que se pretende mostrar es la manera cómo, a partir de una mala configuración, o no afinada como debiera, un atacante podría hacerse con multitud de información que revelaría nombres de equipos, IPs, funcionalidades de servidores, si éstos corren más servicios, etc. Si además esto lo complementamos con otras técnicas mejor que mejor.
Así que, de una forma u otra deberemos proteger este servicio que de lo contrario, podría suponer una desagradable sorpresa.
