1 Protegiendo servicios con VPSs, cifrado Gentoo Hardened Francisco Blas Izquierdo Riera (klondike) Gentoo Staffer Daniel Kuehn (lejonet) Telecomix Agent

2 El nacimiento de la empresa ● Hace unos meses estaba alojado en el VPS en que trabajaba un amigo. Eso me permitió instalar Gentoo Hardened y creé el primer prototipo. ● Poco después la empresa cesó sus servicios de VPS. ● Tenía que buscar una alternativa pero... ● No había garantías de seguridad ● Eran muy caras ● No soportaban Gentoo Hardened

3 Lejklon (protodenominación) ● Quiere proveer servicios a precios razonables. ● Orientada a ser razonablemente “segura por defecto”. ● Principal servicio: auditorías y consultorías no alojamiento... (A clientes alojados). ● Pretende ofrecer flexibilidad → Configura tu VPS y tan a medida como te sea posible y instala lo que quieras. ● Apoyo al código libre.

4 Resumiendo Queremos ofrecer seguridad y flexibilidad a precios razonables.

5 ¿Qué es Gentoo Hardened? Gentoo Hardened es un proyecto de Gentoo destinado a proveer opciones de seguridad avanzadas y punteras a sus usuarios. Gentoo logo and trademark are owned by Gentoo Foundation Inc. lejklon is not related to Gentoo In any other way than one of its founders being a staffer and using it.

6 ¿Por qué no es parte de Gentoo en sí? Porque las mejoras en seguridad suelen tener costes tanto en el rendimiento del sistema como en la dificultad del mantenimiento de los mismos.

7 ¿Qué sistemas de protección ofrece? ● A nivel de compilación ● -D_FORTIFY_SOURCE=2 ● SSP ● PIC/PIE ● A nivel de enlazador: ● RELRO ● BIND_NOW

8 ¿Qué sistemas de protección ofrece? ● A nivel de kernel: ● ASLR ● RANDMMAP ● RANDKSTACK ● UDEREF ● MIN_MMAP_ADDR ● Memoria no ejecutable ● Restricciones sobre mprotect ● Protección contra overflow en contadores de referencias

9 ¿Qué sistemas de protección ofrece? ● A nivel de kernel: ● Sanitización de memoria liberada ● Sanitización de la pila del kernel ● Comprobación de límites en las transferencias entre kernel y espacio de usuario ● Denegación de escrituras en /dev/mem /dev/kmem y /dev/port ● Restricción del modo VM86 ● Desactivación de I/O privilegiada ● Eliminación de direcciones de smaps maps y stat ● Detención de explotación por fuerza bruta

10 ¿Qué sistemas de protección ofrece? ● A nivel de kernel: ● Endurecimiento de la carga automática de módulos ● Ocultación de símbolos del kernel ● Ocultación de procesos del kernel ● Restricción de /proc al usuario ● Restricciones adicionales en /proc ● Restricciones sobre sysfs y debugfs ● Restricciones de enlazado ● Restricciones en FIFOs ● Protección de particiones de sólo lectura

11 ¿Qué sistemas de protección ofrece? ● A nivel de kernel: ● Restricciones en jaulas basadas en chroot ● Forzado del limite de procesos en el exec (aparte del fork) ● Restricciones sobre dmesg ● Detención de ptraces sobre procesos no hijos ● Ejecución de código sólo en directorios confiables ● Protección mediante blackholing en TCP/UDP y protección contra ataques LAST_ACK

12 ¿Qué sistemas de protección ofrece? ● A nivel de kernel: ● Restricciones de socket ● Thread_info está fuera de la pila ● Respuesta activa frente a explotación ● Auditoria de kernel ● MACs (RBAC/SELinux)

13 Stack overflows para novatos

14

15

16

17

18 ¿Qué necesitamos? ● Clásico: ● Pila ejecutable ● Dirección de la pila ● Acceso a la dirección de retorno ● Ret2libc: ● Dirección de la función ● Acceso a la dirección de retorno

19 SSP

20 PIE/PIC Permiten la ejecución del código en posiciones independientes.

21 -D_FORTIFY_SOURCE=2 Realiza varias operaciones para detectar vulnerabilidades en tiempo de compilación y ejecución

22 ASLR y RANDMMAP Estas funciones fuerzan el uso de direcciones aleatorias en los segmentos del programa y en las direcciones de retorno del MMAP (cuando esto sea posible).

23 RANDKSTACK Aleatoriza la ubicación de la pila entre diferentes llamadas al sistema.

24 Memoria no ejecutable Permite separar código (memoria ejecutable) de datos. Hay alternativas basadas en segmentación y en paginación.

25 Restricciones sobre mprotect Evita la introducción de código nuevo al impedir los mapeos ejecutables y escribibles.

26 Eliminación de direcciones de smaps maps y stat Estos ficheros en /proc suelen contener información sobre la ubicación de la pila o las librerías.

27 Restricción de /proc al usuario Esto hace que sólo el propietario (y si se desea un grupo) pueda acceder a información sobre los procesos en /proc

28 Detención de fuerza bruta Si un demonio aborta o recibe alguna señal peligrosa (por ejemplo SIGILL) no puede tener hijos durante 30 segundos. Adivinar el canario se vuelve más complicado. Lo mismo respecto a las direcciones de la pila.

29 RELRO y BIND_NOW RELRO marca como de sólo lectura algunas secciones críticas como las tablas GOT y PLT. BIND_NOW fuerza la carga de símbolos en el arranque de la aplicación de modo que las tablas GOT y PLT puedan marcarse completamente de sólo lectura.

30 Condiciones de carrera Algunas vulnerabilidades se basan en escribir antes que el proceso legítimo cierta información, por ejemplo una FIFO.

31 Restricciones de enlazado y FIFOs Estas restricciones impiden seguir enlaces y escribir a FIFOs que no sean propiedad del usuario en directorios escribible por todos con el bit sticky (a menos que el propietario del fichero posea el directorio también). También impide enlaces duros a ficheros que no se posean.

32 Ataques a referencias en espacio de usuario El kernel a veces hace referencias a espacio de usuario (principalmente a NULL) de forma „descontrolada” como forma de detectar bugs y valores inválidos.

33 UDEREF Imposibilita los accesos a funciones y datos en espacio de usuario.

34 MIN MMAP ADDR Imposibilita la reserva de memoria en las direcciones más bajas.

35 Infoleaks Un infoleak es una vulnerabilidad que permite obtener información sobre el kernel que puede ser usada por el atacante

36 Reescritura de datos Algunas vulnerabilidades permiten escribir datos de forma arbitraria lo que puede causar cosas como una escalada de privilegios.

37 Protección contra overflows en contadores de referencias Evita que se libere memoria cuando el contador de referencias pasa al valor máximo. En vez de esto nos quedamos con un objeto no liberable.

38 Comparación de límites en usercopy El objetivo de esto es evitar que se copien más datos de los del propio tamaño del objeto.

39 Sanitización de memoria Borra las páginas de memoria liberada para evitar que otros procesos puedan leerla.

40 Sanitización de la pila del kernel Borra la pila del kernel antes de volver de la llamada al sistema.

41 Obtención de información El atacante puede intentar obtener información sobre las vulnerabilidades que afectan al kernel o la ubicación de ciertos registros.

42 Restricciones de dmesg Esto impide el uso de dmesg por usuarios que no sean root.

43 Ocultación de símbolos del kernel Esto hace que kallsyms sólo pueda ser leído por root y se requiera la capacidad SYS_MODULE para acceder a dicha información.

44 Ocultación de procesos del kernel Esto permite evitar que los procesos puedan saber cuales son los hilos del núcleo.

45 Restricciones adicionales sobre /proc El sistema de archivos /proc contiene información sensible. Esto sólo permite que root pueda acceder a esta información.

46 Restricciones sobre sysfs y debugfs Esta funcionalidad evita el acceso a usuarios distintos de root a estos sistemas de ficheros.

47 Rootkits en el kernel Una vez se ha conseguido escalar privilegios es posible insertar código malicioso en el kernel que pase desapercibido.

48 Denegación de escrituras en /dev/mem /dev/kmem y /dev/port Estos dispositivos permiten la inserción de código en el kernel.

49 Desactivar I/O privilegiada Esto deshabilita las funciones ioperm y iopl que permiten el acceso a puertos de I/O

50 Otros ataques Hasta ahora hemos visto ataques „estándar” sin embargo existen otros ataques mucho más creativos y modelados para explotar bugs de todo tipo.

51 Restricción del modo VM86 El modo VM86 es conocido por haber provocado bugs serios en la mayoría de sistemas operativos. Esta funcionalidad hace que sea necesario la capacidad de RAWIO para poder activarlo.

52 Endurecimiento de la carga automática de módulos Esto evita que procesos no privilegiados puedan cargar módulos.

53 Restricciones en las jaulas chroot Esto permite por un lado restringir acciones que pueden usarse para escapar de la jaula y por otro acceder a procesos fuera de la misma así como utilizar ciertas capabilities.

54 Thread_info está fuera de la pila Esto permite evitar la mayoría de las escaladas de privilegios pues al pasar al SLAB los accesos desde espacio de usuario son controlados con más fuerza.

55 Respuesta activa frente a explotación La explotación por parte de usuarios no privilegiados causa un baneo hasta el reinicio de los mismos de modo que no pueden usar el sistema, por otro lado si se detecta una explotación por parte de root o en una interrupción producen un kernel panic.

56 Ejecución de código sólo en directorios confiables Esto evita la inserción de nuevo código que el atacante puede usar para ejecutar exploits de forma local. Una versión extendida evita también condiciones de carrera.

57 Detención de ptrace sobre procesos no hijos Esto evita que un proceso pueda ejecutar ptrace sobre otros lo que puede ser explotado para obtener información del mismo o modificar su memoria.

58 Forzado del límite de procesos en el exec Esto permite evitar cierto tipo de fork bombs.

59 Protección mediante blackholing en TCP/UDP y protección contra ataques LAST_ACK Esto se evita simplemente eliminando el estado LAST_ACK y evitando responder a paquetes no esperados.

60 Protecciones tras el ataque Algunas protecciones evitan los ataques después de que ocurran restringiendo lo que el atacante puede hacer.

61 Restricciones de socket Evitan que ciertos usuarios puedan abrir sockets en modo cliente servidor u ambos.

62 Auditoria de kernel Permite registrar las acciones realizadas por un grupo de usuarios o por todos ellos.

63 MACs Las MACs permiten restringir las acciones disponibles incluso para root.

64 Restricción de particiones de sólo lectura Una vez activada impide que se monten nuevas particiones con permisos de escritura (o se remonten) y las escrituras a los dispositivos de bloques.

65 Mejorando tu seguridad con VPS ● Es posible aislar servicios distintos en VPSs distintas. ● Por ejemplo: Web y MySQL. ● Se puede restringir como se comunican mediante iptables → physdev y ebtables ● Se debe proteger el host pues tiene acceso a información sensible. ● ¡Y AISLAR LAS VPS COMO SI FUERAN SERVICIOS!

66 ¿Cómo metemos el FDE? ● Una solución → Raíz de confianza ● El initrd contiene un servidor de ssh en una partición cifrada por nosotros (la del host no está cifrada) que desbloquea el disco (segura mientras no se lea la clave privada). ● Se puede usar TXT o TPM en el host para garantizar la autenticidad del código. ● Incluso si es comprometida la información sólo serviría si se reiniciase la máquina.

67 ¿Pero aún tengo que confíar en vosotros no? ● Sí, en cualquier caso puesto que el host puede controlar el proceso de la MV puede acceder a información sensible, por ello debería blindarse.

68 Intercomunicando los VPSs ● Se utilizan puentes de nivel 2 (MAC) para comunicar las máquinas. ● El filtrado se hace en la máquina principal ¿para qué hacer pasar el paquete por dos pilas de si va a caer en cualquier caso? ● El prototipo usa reglas optimizadas ● Las versiones finales usarán una tabla por usuario.

69 Decisiones sobre el hardware ● AMD sobre Intel porque tenemos más núcleos reales por un precio menor. ● Más núcleos → Más clientes ● Esperamos a Bulldozer por AES-NI (entre otras) ● Elegimos discos SAS puesto que tienen más rendimiento y fiabilidad que SATA. ● Memoria ECC para evitar problemas de hardware.

70 ¿Por qué libraremos todo como software libre? ● La seguridad a través de la oscuridad no funciona. ● Los clientes pueden acceder a los initrds... y copiarlos. ● Nuestro objetivo es ofrecer servicios a los clientes no vender software.

71 Gracias por atender Contacto: klondike ( e n ) xiscosoft.es daniel ( e n ) kuehn.se Material: ??? Webs de interés: http://www.gentoo.org/proj/en/hardened/http://pax.grsecurity.net/docs/