Hola,
Este es un pequeño artículo complementario en el que se explican algunas generalidades de los sistemas UFS. Para ello tomaremos como ejemplo un sistema FreeBSD en que hay sospechas de compromiso.
Lanzamos un uname y un df para saber un poco más del sistema y cómo están conformados los discos.
Resulta fácil observar el particionado estándar de FreeBSD, en el que el disco está vinculado al dispositivo /dev/ad0 con una serie de particiones y puntos de montaje declarados tal y como se aprecia en la captura.
Podemos aprovechar este ejercicio para enseñar cómo se hace una captura de disco remota mediante dd sobre un túnel SSH. Esto es igualmente factible con netcat.
Para ello lanzamos en nuestra máquina de captura el siguiente comando
$ ssh root@172.16.145.129 dd if=/dev/ad0 conv=noerror | dd of=image.dd
Donde evidentemente la IP que se muestra es la IP real de la máquina ejemplo que estoy utilizando. En ejemplos reales no deberíais poder conectar como root en remoto, con lo que conviene discutir con el administrador del sistema la mejor manera de atajar el problema según el caso.
Esta ejecución provocará que abramos una sesión en el sistema a capturar como root, y acto seguido, obtenemos la imagen del disco mediante dd. Ni que decir tiene que en un escenario real, hay que verificar hashes para comprobar que la imagen es válida y representativa.
Una vez disponemos de la imagen, podemos emplear nuestras herramientas tradicionales.
Una vez comprobado que en el offset 63 comienza la porción del disco que más nos puede interesar, obtenemos la información del sistema de ficheros.
Si no se tienen a mano las herramientas, siempre se puede examinar el Master Boot Record a mano, y comprobar que efectivamente, se trata de un sistema BSD. Para ello echamos mano de la teoria, y con un editor hexadecimal, localizamos el byte 446 en el MBR, que indica el comienzo de la primera partición.
El byte 446 (80) indica que la partición está activa. El siguiente valor (01) indica en qué cabeza del disco comienza la partición. Los dos siguientes valores indican sector y cilindro del disco donde comienza la partición (01 y 00) respectivamente. Inmediatamente, aparece un valor hexadecimal A5 (byte 450) que indica el tipo de partición, en este caso, BSD/386. Haced la prueba con vuestra máquina, y verificad que en Linux el valor es 83 para la partición nativa y 82 para el swap, y en el caso de NTFS, el valor es 07.
Tal y como era de esperar en una instalación FreeBSD, tenemos un sistema de ficheros Unix File System, más conocido como UFS. Desde FreeBSD 5.0, el estándar es UFS2. Otros sistemas donde es normal encontrarse UFS son, además de las variantes BSD usuales (Net, Free, Open), Solaris y HP-UX. Y si estás leyendo esto con un Mac, que sepas que OS X también emplea UFS. Si estás usando un equipo Linux con ext2/3, que sepas que estás empleando un sistema de ficheros basado en UFS. Y si tienes una Playstation 3, su disco duro disco duro emplea también UFS.
No vamos a entrar en profundidad sobre UFS, pero es un sistema de ficheros pensado para obtener máximo rendimiento y una excelente fiabilidad, y la verdad es que funciona francamente bien. La principal diferencia entre UFS1 y UFS2 es que la segunda versión soporta timestamps más largos y tamaños de disco más elevados. Desde el punto de vista forense no hay diferencias susceptibles de mención.
Una vez obtenida la imagen y comprendido qué tenemos entre manos, procedemos al montaje en sólo lectura para el análisis. Ojo en Linux ya que el soporte para UFS depende de la versión del kernel y de las opciones que tengamos declaradas en él. No debería ser problemático en versiones recientes (rama 2.6) pero es posible que en ciertas configuraciones haya que recompilar el núcleo para soportar UFS. Echad mano de la documentación en cada caso.
Una inspección del fichero de claves (/etc/passwd) indica la presencia de un usuario sospechoso:
Si alguien ha creado un usuario, ese ha debido ser probablemente el root. Inspeccionamos su historia y notamos la ejecución del comando adduser:
Un vistazo a /var/log/auth.log revela rápidamente lo que ha ocurrido:
9 intentos de login en dos segundos que finalmente concluyen en éxito sólo pueden significar que el sistema ha sido comprometido empleando fuerza bruta automatizada. Una vez obtenidas las credenciales, el usuario ha utilizado el comando adduser, ha creado el usuario sergi0 y ha verificado que todo funciona bien, incluso probando si puede hacer su a root (evento que se realiza con éxito) lo cual indica que el usuario sergi0 ha sido creado con pertenencia al grupo wheel. Por fortuna para nosotros, este aprendiz de hacker no ha eliminado sus huellas, y ha sido trivial identificar el patrón de acciones, e incluso la IP desde la que se ha originado el compromiso.
La acción inmediata es descontaminar, eliminando el usuario ilegítimo y restaurando una contraseña segura para root. El resto de la imagen forense será utilizada para determinar qué acciones exactas ha realizado el atacante, con lo que será procedente obtener una línea temporal y proceder como es habitual en estos casos.
Un saludo,