Blog

Archive for Debian

Cómo Debian solucionó el CVE-2016-1247, escalado de root por el log de NGINX

Introdución

Este artículo explora el exploit CVE-2016-1247, y cómo fue corregido por Debian y qué lecciones podemos extraer de él para incluso ir un poco más allá para proteger/asegurar sus sistemas.

Este artículo también aplica a CVE-2016-6664-5617, escalado root MySQL, que aunque no es una cuestión específica de Debian, es el mismo fallo conceptual en el wrapper mysql que permitió al autor del PoC (Dawid Golunski) crear un exploit funcional.

Cómo funciona el PoC de Dawid Golunski (CVE-2016-1247 antecedentes)

Recientemente Dawid Golunski (https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-PrivEsc-CVE-2016-1247.html) informó un PoC que escala sin problemas desde el usuario www-data (el usuario nginx por defecto) al la cuenta root completa. ¡Casi nada!

Revisando en detalle el bug reportado, reduciendo los pasos tomados por Dawid para romper el sistema, e ignorando algunos detalles por brevedad, éstos son los siguientes:

  1. Primero, el PoC comienza con la suposición (no muy complicada de conseguir) que se dispone del control de la cuenta www-data mediante el control de un fichero .php, cgi similar, una cuenta de administración WordPress a la web o un mecanismo similar que permita subir ficheros .php para ejecutar comandos arbitrarios.
  2. Desde ahí, Dawid descubrió que la rotación de log hecha por “logrotate” ajusta los siguientes permisos cada día que rota:
         /var/log/nginx/*.log
         create 0640 www-data adm

    Eso es, “logrotate” rotará y creará (este es el punto) un fichero vacío con los permisos www-data:adm. Parece inocuo, pero aquí está el detalle fatal.

  3. Desde ahí, el resto sólo es consecuencia: el PoC de Dawid borra el fichero /var/log/nginx/error.log y crea un enlace a /etc/ld.so.preload:
        rm /var/log/nginx/error.log
        ln -s /etc/ld.so.preload /var/log/nginx/error.log

    NOTA: para aquellos preguntándose, “¿pero para qué demonios es ese fichero?”

    Básicamente ese fichero permite configurar las “librerías” que serán “pre cargadas” antes de que otra librería lo sea antes de lanzar un binario.

    En esencia, este mecanismo permite “interceptar” símbolos/funciones para ser reemplazadas con el código que se desee. Puede ser usado como un mecanismo “para una solución externa” sin modificación de binario, pero, como todo mecanismo, puede ser utilizado para el mal.

    Para más información vea: http://man7.org/linux/man-pages/man8/ld.so.8.html

  4. Una vez que el PoC de Dawid crea ese enlace, ya solo resta esperar para el siguiente día para que la rotación de log ocurra y dejar que el propio sistema “abra la puerta para nosotros” através “de ajustar unos permisos www-data:adm” a /etc/ld.so.preload.

    NOTA: aquí es donde puede darle al play de “Carmina Buruana” para escucharlo de fondo

  5. Desde ahí, el PoC de Dawid crea una pequeña librería que es “precargada” y enlazada a cualquier binario cargado por su sistema, incluyendo código para detectar “cuando ejecuta como root”…y cuando lo haga, “Pumba!”, este código creará una copia con setuid de una shell para que el atacante pueda escalar sin clave.

Pero oiga, el artículo comenzó diciendo “cómo Debian corregió este problema”, ¿no?

Cierto, queríamos hacer un repaso de cómo el PoC funciona para entender mejor la corrección introducida y qué podemos aprender de ella.

Regresando a la solución, si mirando el “ChangeLog” de Debian, lo que han hecho es “asegurar” los permisos de log para que el directorio sea poseido por “root:adm” en lugar de “www-data:adm”:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842295

    +  * debian/nginx-common.postinst:
    +    + CVE-2016-1247: Secure log file handling (owner & permissions)
    +      against privilege escalation attacks. /var/log/nginx is now owned
    +      by root:adm. Thanks ro Dawid Golunski for the report.
    +      Changing /var/log/nginx permissions effectively reopens #701112,
    +      since log files can be world-readable. This is a trade-off until
    +      a better log opening solution is implemented upstream (trac:376).
    +      (Closes: #842295)

Ciertamente, tener el directorio “/var/log/nginx” bajo los permisos de root:adm hace imposible que para www-data pueda borrar el fichero /var/log/nginx/error.log y hacer así que “logrotate” nos cree un fichero /etc/ld.so.preload poseido por www-data (que es la clave).

Sin embargo, ¿hay más lecciones que podamos aprender para asegurar mejor nuestro sistema para defenderse mejor para este tipo de ataques de rotación? Siga leyendo.

Cómo los servicios deberían gestionar los logs (consejos para desarrolladores y administradores)

Uno de los problemas de la configuración nginx es que no separa la gestión de los logs de la producción de los mismos. Al hacer que el servicio nginx gestione el log directamente en lugar de usar syslog hace que se cree un problema de permisos que no puede ser fácilmente solucionado/asegurado.

Si separa la gestión de los logs (de manera que syslog gestione todos los logs producidos por nginx), puede asegurar todos los logs (poseidos y accesibles para root:adm), rotarlos, etc, sin preocuparse de lo que puedan hacer los usuarios (en principio usuarios de privilegio bajo). Éstos solo podrán atacar los ficheros poseídos por ellos mismos (en principio sólo los ficheros de la web) que, además, no son rotados.

Vea https://nginx.org/en/docs/syslog.html (para comenzar a usar syslog en su configuración nginx)

El servicio nunca debería poseer el log
Así que una conclusión general que podemos extraer de esto es: nunca deje que el log sea poseído por el servicio que lo produce, de lo contrario, esto podrá ser usado para escalar usando el mismo mecanismo que el PoC de Dawid Gulonski.

Como ejemplo, lo siguiente es incorrecto:

   service-user:adm   640        # configuración mala/débil

…y una buena definición es:

  root:adm  640   # Esta es una buena/recomendada configuración porque impide al usuario
                  # borrar este log y crear un link a ficheros sensibles.

Pero espero, ¿qué hago con clamav, roundcube, mysql, dovecot (por nombrar algunos)?

Algunos servicios vienen con una configuración de paquete por defecto que no permite cambiar este log a “root:adm” debido a que el servicio necesita abrir y escribir a estos logs.

En cualquier caso, todos estos servicios PUEDEN ser configurados para usar syslog y usted debería considerar configurar su sistema para que lo hagan así.

De hecho, Dawid Golunski también descubrió “exáctamente” el mismo tipo de fallo en los paquetes de MySQL, donde el escalado a root vía log es posible (https://legalhackers.com/advisories/MySQL-Maria-Percona-RootPrivEsc-CVE-2016-6664-5617-Exploit.html ).

La configuración de gestión de log por defecto puede no ser buena
Este artículo pretende elevar la atención sobre la configuración por defecto de los logs. Las distribuciones Linux proporcionan una configuración por defecto pero aún así tiene que revisar cuidadósamente cómo el log es gestionado, rotado y poseído.

Primera conclusión: use siempre la separación de servicio para el log (si la seguridad es importante para usted)

Por este motivo es muy importante concentrar la gestión/reporte de log a syslog (o similar) para que pueda separar el servicio de la gestión de log (lo que soluciona todo este lío).

De nuevo, si hace que su servicio ejecute con un usuario de privilegio bajo (por ejemplo: mysql, www-data, clamav,…) y la gestión de logs está gestionada por un servicio independiente (rsyslog, por ejemplo), entonces podrá crear configuraciones de rotado que serán siempre seguras y “que no dependerán de fallos de wrappers o problemas en el empaquetamiento” que, al final, pueden ocasionar que al final se tomen decisiones controvertidas (más sobre esto después).

Segunda conclusión: ¿porqué esperar a que ocurra el problema?

Para evitar que mayores problemas ocurran y no puede controlar cómo el empaquetamiento es hecho, o cómo la supervisión de wrappers es escrita, etc, puede bloquear este tipo de ataques ejecutando lo siguiente:

   touch /etc/ld.so.preload
   chown root:root /etc/ld.so.preload 
   chmod 644 /etc/ld.so.preload        
   chattr +i /etc/ld.so.preload

De esta manera puede asegurarse que el fichero existe y no puede ser actualizado (incluso para el root! a no ser que el atacante ya posea la cuenta de root para quitar el flag +i).

Con este ajuste deshabilitará completamente el PoC de Dawid Golunski y hará más complicado que su sistema sea atacable por este tipo de técnicas de escalado por rotado de log.

Tercera conclusión: “logrotate” debe ser constantemente comprobado

El servicio “logrotate” es parte del esquema para atacar el sistema a través de la creación de configuraciones “débiles” que rotan usando usuarios de privilegios bajos como los siguientes (ejemplo Debian):

  /etc/logrotate.d/mysql-server:	create 640 mysql adm

Como se muestra en https://legalhackers.com/advisories/MySQL-Maria-Percona-RootPrivEsc-CVE-2016-6664-5617-Exploit.html, esta configuración puede ser explotada (escalado de log desde usuario mysql). Lo mejor es hacer que el servicio de MySQL use el syslog para gestionar todo el reportado de log y hacer que el propietario del log sea:

   /etc/logrotate.d/mysql-server:	create 640 root adm

Sabiendo esto, puede usar el siguiente comando para revisar aquellas configuraciones “logrotate” que puedan ser posibles brechas en su sistema:

   find /etc/logrotate.d /etc/logrotate.conf -type f -exec grep -H create {} \; | grep -v "create 640 root adm"

Cuarta conclusión: no puede escapar de esto

Puede que esté pensando “bien, pero esto es un tema interno..” o “puedo gestionarlo”. Quizás. En cualquier caso, veamos más detenidamente lo que “realmente” Debian hizo para corregir el error mirando el changlog:

  nginx-common (1.6.2-5+deb8u3) jessie-security; urgency=high

  In order to secure nginx against privilege escalation attacks, we are
  changing the way log file owners & permissions are handled so that www-data
  is not allowed to symlink a logfile. /var/log/nginx is now owned by root:adm
  and its permissions are changed to 0755. The package checks for such symlinks
  on existing installations and informs the admin using debconf.

  That unfortunately may come at a cost in terms of privacy. /var/log/nginx is
  now world-readable, and nginx hardcodes permissions of non-existing logs to
  0644. On systems running logrotate log files are private after the first
  logrotate run, since the new log files are created with 0640 permissions.

   -- Christos Trochalakis   Tue, 04 Oct 2016 15:20:33+0300

Eso es, Debian ha tomado el camino de limitar la creación de enlaces pero a costa de permitir que todos los usuarios puedan acceder al directorio de logs. De hecho, durante la instalación/actualización del parche, el paquete intenta detectar links de hacking que ya puedan existir:

  Template: nginx/log-symlinks
  Type: note
  _Description: Possible insecure nginx log files
    The following log files under /var/log/nginx directory are symlinks
    owned by www-data:
   .
   ${logfiles}
   .
   Since nginx 1.4.4-4 /var/log/nginx was owned by www-data. As a result
   www-data could symlink log files to sensitive locations, which in turn
   could lead to privilege escalation attacks. Although /var/log/nginx
   permissions are now fixed it is possible that such insecure links
   already exist. So, please make sure to check the above locations.

Como puede ver, “Sí”, la actualización de seguridad permite que todos los usuarios del sistema puedan acceder a estos logs y “sí”, la actualización no corrige los posibles hackings, tendrá que revisarlos de todas formas.

Esto puede ser interesante, pero para el alcance de este artículo, como puede ver, si no corrige la configuración de su sistema para “separar la gestión de logs de la producción del mismo” tendrá que tomar malas decisiones que de otro modo son fácilmente corregibles (y que no son la responsabilidad de Debian, por cierto).

Cómo Core-Admin gestiona y mitiga CVE-2016-1247 y CVE-2016-6664-5617

Con todos estos detalles explicados, Core-Admin hace dos cosas para migitar este tipo de atacaques de escalación a root mediante rotado de log:

  1. El comprobador “Renamed process” automáticamente asegura que el fichero /etc/ld.so.preload es protegido. También reporta cualquier cambio que ocurra en ese fichero.
  2. Tiene un comprobado de “log” que asegura que las configuraciones de “logrotate” estén funcionando y tengan declaraciones de propietario conocidas (o al menos aceptadas) que sean seguras, reportando cualquier configuración insegura que pueda conducir a problemas.

Posted in: Core-Admin, Debian, LogRotate, Seguridad

Leave a Comment (0) →

KB: 07072014-001: Desactivando la llamada de sistema ptrace()

Índice de claves

Introducción

El siguiente artículo explica cómo deshabilitar la llamada ptrace en varias plataformas (ver la lista de plataformas soportadas). Al desactivar esta llamada, puede eliminar una fuente importante de problemas de seguridad y una característica del kernel utilizada en muchos ataques para implementar ataques de modificación de memoria de procesos en tiempo real que son difíciles de detectar.

El artículo propone deshabilitar la llamada ptrace() mediante la instalación de un módulo del kernel que deshabilita dicha llamada.

Plataformas soportadas

  • Debian Squeeze amd64
  • Debian Squeeze i686
  • Debian Wheezy amd64
  • Ubuntu Precise LTS 12.04 amd64
  • Linux Mint 13 Maya amd64

Instalando el módulo

Para instalar el módulo, tiene que actualizar su fichero /etc/apt/sources.list  para incluir la fuente apt apropiada. Vea el siguiente enlace para obtener la adecuada para su distribución:

https://dolphin.aspl.es/svn/publico/noptrace2/README

Después de eso, tan solo tiene que actualizar referencias e instalar con tan solo ejecutar lo siguiente::

apt-get update
apt-get install noptrace2

Después de eso, el módulo será compilado usando los ajustes actuales de su servidor/sistema y el módulo será cargado si no hay problemas.

¿Cómo compruebo que el módulo está bloqueando llamadas ptrace()?

Ejecutando el siguiente comando. Debería obtener algo como “No child processes”:

strace -p 1
Process 1 attached - interrupt to quit
detach: ptrace(PTRACE_DETACH, ...): No child processes
Process 1 detached

¿Cómo lo habilito/deshabilito temporalmente?

Puede utilizar el siguientecomando para parar/descargar el módulo que causa que llamada ptrace() sea bloqueada:

service noptrace2 stop

Al mismo tiempo, puede utilizar el siguiente comando para reactivar el módulo que bloquea la llamada ptrace():

service noptrace2 start

¿Esto genera alguna operación en el log que pueda inspeccionar?

Claro, eche un vistazo en el registro  /var/log/syslog. Debería encontrar algo como:

Jul 7 11:14:40 vulcan kernel: [4721108.617232] [noptrace2] ptrace syscall disabled
Jul 7 11:14:54 vulcan kernel: [4721122.990270] [noptrace2] ptrace() invoked against process 1 by process 20675
Jul 7 11:14:54 vulcan kernel: [4721122.990304] [noptrace2] ptrace() invoked against process 1 by process 20675
Jul 7 11:15:02 vulcan kernel: [4721130.689160] [noptrace2] ptrace() invoked against process 29912 by process 20746
Jul 7 11:15:02 vulcan kernel: [4721130.689188] [noptrace2] ptrace() invoked against process 29912 by process 20746
Jul 7 11:15:22 vulcan kernel: [4721150.219577] [noptrace2] ptrace syscall restored
Jul 7 11:15:44 vulcan kernel: [4721172.921028] [noptrace2] ptrace syscall disabled
Jul 7 18:11:15 vulcan kernel: [4746103.948870] [noptrace2] ptrace() invoked against process 1 by process 9821
Jul 7 18:11:15 vulcan kernel: [4746103.948897] [noptrace2] ptrace() invoked against process 1 by process 9821

¿Le gustó el artículo, lo encontró interesante o tiene algo que comentar?

Genial. Por favor, contacto con nosotros en http://www.core-admin.com/portal/es/about-us/contact o síganos en https://twitter.com/core_adm o https://twitter.com/aspl_es

Posted in: Administration, Debian, Debian Squeeze, Debian Wheezy, Linux Mint, Seguridad, Ubuntu, Ubuntu Precise LTS

Leave a Comment (0) →

KB: 16052014-001: Corrigiendo el error /usr/sbin/grub-probe: error: no such disk. para el dispositivo /dev/md0

De manera que está actualizando un sistema Debian (o similar) y durante el proceso, obtiene el siguiente error:

update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
Generating grub.cfg ...
/usr/sbin/grub-probe: error: no such disk.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.32-5-amd64.postinst line 799.

Posiblemente está buscando en google y ha encontrado varias soluciones como las siguientes pero ninguna de ellas funciona:

http://www.linuxexpert.ro/Troubleshooting/grub-error-no-such-disk.html

https://lists.debian.org/debian-user/2011/06/msg00359.html

http://www.linuxquestions.org/questions/debian-26/usr-sbin-grub-probe-error-no-such-disk-922118/

La cosa curiosa es que su sistema está ejecutando correctamente, no hay ningún error en /proc/mdstat (por favor, ejecute un “cat” sobre ese fichero para asegurarse) and si ejecuta un simple “ls -la” sobre /dev/md0 y los discos componentes que hacen ese disco encuentra que todo está correcto (sin errores).

En algún punto, encuentra que tiene que ejecutar la siguiente comprobación para comprobar cual es la idea que tiene grub-probe sobre sus discos:

/usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=fs -v /boot/grub

Sin embargo, al final, informa del siguiente error:

/usr/sbin/grub-probe: info: opening md0.
/usr/sbin/grub-probe: error: no such disk.

Si tiene todos estos elementos en común, por favor, asegúrese de que tiene el comando mdadm disponible. Es posible que lo haya borrado por error. Debido a que grub-probe usa mdadm –examine /dev/md0, este está confundiendo un error de ese comando con el error de no encontrar el comando.

Por favor, intente lo siguiente para ver si funciona:

>> apt-get install mdadm
>> apt-get install -f

Nota aclaratoria para usuarios de Core-Admin

Si está ejecutando el checker mdadm de Core-Admin, este se asegurará de que tiene mdadm disponible además de comprobar los discos y todos los detalles dentro de /proc/mdstat.

Por favor, asegúrese de que tiene el comprobador mdadm para asegurarse de que este error no lleva a sus servidores.

Posted in: Administration, Debian, Debian Squeeze, KB

Leave a Comment (0) →

KB: 05112013-001: El gestor de alojamientos falla al añadir un nuevo alojamiento informando con un error de cuotas

Síntoma

Cuando se intenta crear un alojamiento con la herramienta de Gestión de Alojamientos, aparece un error similar a:

setquota: Cannot open quotafile /home/aquota.user: Permission denied
setquota: Not all specified mountpoints are using quota.

Revisiones afectadas

Todas

Solution

Reinicie el sistema de cuotas. Para hacerlo, puede utilizar uno de los siguientes métodos:

  1. Ejecute el siguiente comando si tiene acceso fácil a una shell de root en el servidor:
    >> /etc/init.d/quota restart
  2. También puede reiniciar el servicio usando el “Visor de procesos y servicios”, seleccionando el servicio “quota” dentro de los servicios no manejados. Después de seleccionarlo, use la opción de reinicio disponible.

Posted in: Core-Admin, Debian, Debian Lenny, Debian Squeeze, Debian Wheezy, KB

Leave a Comment (0) →

KB: 04112013-001: El instalador del administrador de correo falla porque no puede encontrar libmail-sender-perl

Síntoma

Cuando se lanza el instalador del administrador de correo, este para y falla diciendo que no puede encontrar el paquete libmail-sender-perl.

Revisiones afectadas

Debian Lenny (5.0), Debian Squeeze (6.0), Debian Wheezy (7.0)

Solución

  1. Actualize su /etc/apt/sources.list para incluir la declaración “non-free” a la fuente de paquetes por defecto. Un ejemplo funcionando sería:
    deb http://ftp.es.debian.org/debian/ squeeze main non-free
  2. Después de esto, reiniciar el instalado y comenzar de nuevo.

Posted in: Debian, Debian Lenny, Debian Squeeze, Debian Wheezy, KB

Leave a Comment (0) →