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.
Envío de mensajes Syslog en S7 CPUs
Library description: Sending SYSLOG messages with a SIMATIC S7 CPU
¿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.
Un saludo.
