03 diciembre 2010

Información disclosure en los correos de notificación al sistema

Es importante que los administradores/operadores de sistemas reciban en tiempo real las notificaciones de los eventos críticos. En la mayoría de los sistemas estos correos de notificación son enviados en texto plano, suponiendo un riesgo si contienen información que pueda ser usada por un atacante para acceder a un equipo.

Normalmente se suelen enviar correos de monitorización de alarmas, como sucede en los sistemas puros de monitorización de sistemas (como Nagios) o en sistemas de centralización de eventos de seguridad (o SIEM). Estos correos de notificación reportan información interna de la red o de elementos remotos que monitorizan. También las tareas programadas basadas en el demonio cron envían por defecto la salida estándar de una tarea en texto plano como pueden ser: chkrootkit (monitorizar posibles rootkits en el sistema), AIDE/Tripwire (integridad de ficheros), fail2ban (baneo mediante iptables por intentos excesivos de login hacia sshd, ftpd...), logcheck o logwatch (notificación de posibles eventos en los logs del sistema), etc.

Podemos ver en el cron el script para ejecutar chkrootkit:

  [root@se cron.daily]# more chkrootkit
  #!/bin/sh

  /usr/bin/chkrootkit | mail -s "Daily chkrootkit from se" lain@localhost

En los logs del cron /var/log/cron vemos como se lanza la tarea:

  Nov 23 03:25:05 se run-parts(/etc/cron.daily)[7082]: starting chkrootkit
  Nov 23 03:25:21 se run-parts(/etc/cron.daily)[8594]: finished chkrootkit

Mediante Wireshark capturamos el correo donde vemos como se envía en texto plano:



Una notificación de red puede facilitarnos información disclosure como por ejemplo, usuarios logeados, ficheros que cambian, eventos notificados por correo, posibles cuentas de correo de sysadmins o del departamento de seguridad.

Vemos otro ejemplo de una salida del log de logcheck:

  Nov 16 17:40:01 se cron[18283]: (root) CMD (logcheck finished && mail lain@localhost )

Email de monitorización de logcheck que circula por la red:

  [header removed]
  To: lain@localhost
  Subject: se 11/16/10:14.00 system check

  Unusual System Events
  =-=-=-=-=-=-=-=-=-=-=
  Nov 16 13:00:01 se kernel: grsec: exec of
  /usr/bin/logtail (/usr/bin/logtail /var/log/iptables.log ) by
  /bin/bash[sh:17739] uid/euid:0/0 gid/egid:0/0, parent
  /bin/bash[sh:17725] uid/euid:0/0 gid/egid:0/0
  Nov 16 13:00:01 se kernel: grsec: exec of
  /usr/bin/logtail (/usr/bin/logtail /var/log/pax.log ) by
  /bin/bash[sh:17740] uid/euid:0/0 gid/egid:0/0, parent
  /bin/bash[sh:17725] uid/euid:0/0 gid/egid:0/0
  Nov 16 13:00:01 se kernel: grsec: exec of
  /usr/bin/logtail (/usr/bin/logtail /var/log/grsec.log ) by
  /bin/bash[sh:17741] uid/euid:0/0 gid/egid:0/0, parent
  /bin/bash[sh:17725] uid/euid:0/0 gid/egid:0/0
  grsec: From 192.168.13.77: exec of /usr/sbin/useradd (useradd ) by
  /bin/bash[bash:18333] uid/euid:0/0 gid/egid:0/0, parent
  /bin/bash[bash:18311] uid/euid:0/0 gid/egid:0/0
  grsec: From 192.168.13.77: exec of /bin/dmesg (dmesg ) by
  /bin/bash[bash:18334] uid/euid:0/0 gid/egid:0/0, parent
  /bin/bash[bash:18311] uid/euid:0/0 gid/egid:0/0
  ...

Como podemos ver, este simple correo nos da suficiente información como para ir organizando un poco la metodología de trabajo del administrador del servidor. A qué hora se envía, a qué destinatario (es una cuenta externa), el kernel usa grsec, se analizan los logs en busca de eventos para iptables, pax/grsec. El usuario root conecta desde la máquina 192.168.13.77 a este servidor por lo que no hay una buena configuración del demonio SSH. En general es información sensible que no debe circular por la red.

Si un atacante consiguiera acceso a un servidor de una organización podría capturar los paquetes que circulan por la red, estos podrían serle de utilidad para acceder a determinadas máquinas y obtener datos que más tarde le servirían para obtener información vital a la hora de hacer un pentesting.

Cualquier red es sniffable, si no es mediante un MitM, se puede intentar conseguir acceso al switch, podría ser que usasen VLANs pero hay técnicas para saltárselas o unirse a una VLAN. Destacamos la herramienta Yersinia de s21sec que surge tras la necesidad de realizar ataques de capa 2.

- Contramedidas:

Para evitar poner en manos de un atacante este tipo de información, se deberían empezar a concienciar en la necesidad de cifrar los correos de notificación al sistema. Lo ideal sería que la organización incluyera una política de cifrado para todos los correos, pero ¿en cuántas organizaciones se cifran los emails? A no ser que estén supeditados por auditorías o contengan información con un alto grado de confidencialidad, bien sabemos que pocas. Debemos concienciarnos que el cifrado de los correos es vital para mantener la confidencialidad de la información que circula por nuestra red. Y ya no hablemos de información corporativa como puede ser documentación interna, contratos, facturación, etc.

Nos replanteamos nuestras notificaciones de las tareas programadas cifrando los correos de notificación:

Modificamos nuestro script de logwatch, cifrando con GnuPG los correos enviados, previamente habremos importado la clave publica del destinatario:

  [root@se cron.daily]# more logwatch
  #!/bin/sh

  /usr/sbin/logwatch | gpg -ea -r "Recipient" | mail -s "Daily logwatch from se" lain@localhost

Podemos ver en el log de cron la tarea ejecutada:

  Nov 21 15:38:25 se run-parts(/etc/cron.daily)[3224]: starting logwatch
  Nov 21 15:38:32 se run-parts(/etc/cron.daily)[5171]: finished logwatch

Capturamos la traza que se envía por red, y vemos como el correo ha sido cifrado:


Además de los correos de notificación del sistema, debemos tener en cuenta los mensajes que se envían desde Syslog. Syslog es un sistema de gestión de logs en red que registra información sobre actividades del sistema operativo, anomalías, alertas, errores, accesos correctos/incorrectos al sistema, etc. y también se envían mensajes en texto plano que podrían facilmente ser capturados por un sniffer. Para mantener la confidencialidad de la información que viaja por la red podríamos usar Stunnel para que los datos viajen cifrados mediante SSL/TLS.

Estas medidas harán que la información viaje por la red de forma más segura manteniendo la confidencialidad de los datos, y así se lo pondremos un poco más difícil a los atacantes que intentan comprometer nuestros sistemas.

Artículo cortesía de: Laura García.

2 comments :

Anónimo dijo...

La información que das sobre syslog es algo inexacta, ¿puedes desarrollarla más?

El logger del sistema sigue unas políticas de seguridad muy estrictas y por defecto usa un socket unix local. De hecho esas políticas son muy restrictivas con el acceso local a los ficheros donde se almacenan los logs (que es más sensible que la posibilidad de capturar paquetes, cuando no hay paquetes que capturar).

Imagino que te refieres a un escenario en el que una máquina usa el logger de otra vía red, y además sobre una red insegura.

En ese caso, ¿hablaríamos de una implementación de syslog que soporte TCP? El RFC3164 solo soporta UDP, y en tal caso no podríamos usar stunnel.

Anónimo dijo...

@Anónimo: En efecto, me refería a las implementaciones de syslog que soportan TCP :-)

Salu2