15 Abr 2016

Hoy, en como se hizo… Los papeles de Panamá

Buenas a todos!
a día de hoy, imagino que todo el mundo ha oído hablar de los papeles de Panamá, donde se han revelado los nombres de cientos de personalidades de todo el mundo con empresas offshore en dicho paraíso fiscal.

De la legalidad de esas empresas o sus implicaciones no os puedo hablar porque no tengo ni idea de economía y leyes, para eso están los tertulianos de Tele5, que igual te hablan de offshore como de la Pantoja. De lo que sí que puedo hablar un poco, es de cómo se consiguió la filtración desde el punto de vista de la seguridad de la información.

El bufete Mossak Fonseca, tiene su página web en el domino www.mossfon.com montado sobre un blog WordPress. Esta web, tiene un plugin llamado Revolution Slider para mostrar diferentes imágenes en modo carrousel. El problema está en que la versión que utilizan tiene un fallo de seguridad que permitía hacerse con el control del servidor.

[ Parte técnica. Si no te interesa, te la puedes saltar ]

Accediendo a los documentos del propio plugin, se podía ver que la versión era la 2.1.7, que tenía un fallo de seguridad.

Screen-Shot-2016-04-07-at-11.17.35-AM

Este fallo de seguridad, era conocido desde octubre de 2014 y existía información pública de como aprovecharlo. Aquí por ejemplo: https://www.exploit-db.com/exploits/35385/

Pongo también la parte del código del plugin que tenía el fallo:

Screen-Shot-2016-04-07-at-10.31.37-AM

La 7º línea permite a usuarios no autenticados subir ficheros. Esto provoca que sea facil subir un archivo .php que permita tomar el control del equipo.

[/Parte técnica ]

Esta web, a parte de este plugin, también tenía un plugin destinado a gestionar las listas de correo. Este plugin, almacenaba el usuario y la contraseña para acceder al servidor de correo en la base de datos:

Screen-Shot-2016-04-08-at-2.37.47-PM

Esto les permitió conectarse a ese servidor y descargar miles de correos electrónicos con información confidencial.

Sin embargo, el hackeo no se quedó ahi. Mossack Fonseca también tenía una web donde ponía a disposición de sus clientes toda la documentación para que estuviera accesible desde cualquier parte del mundo.

Screen-Shot-2016-04-08-at-2.11.53-PM

En este caso, la tecnología era Drupal. Del mismo modo que en el anterior caso, el no actualizar la versión de la web hizo que fuera vulnerable y los atacantes tuvieron total acceso al servidor y a los miles de ficheros contenidos en el.

Como habéis visto, el ataque no fue nada sofisticado. Utilizaron fallos públicos muy conocidos para tener acceso a los datos. En este caso, Mossack Fonseca se hubiera salvado de este ataque con solo tener activas las actualizaciones automáticas.

Mas info: Aquí y aquí

David Lladró
Responsable de Seguridad en Datadec Online

[subscribe2]

27 Nov 2015

Consejos de seguridad para el Black Friday

Como todos sabéis y siguiendo esa costumbre tan española que es apuntarse a cualquier fiesta,sea patria o extranjera, hoy es Black Friday. Como dato curioso que podréis usar para ser unos auténticos “cuñados”, el origen del término Black Friday se remonta a principios del siglo XIX en Philadelphia, donde los policías empezaron a llamar así al día siguiente a Acción de Gracias por el caos circulatorio que se generaba.

Desde hace unos pocos años, las tiendas españolas han empezado a ofrecer descuentos en sus productos copiando a las tiendas americanas. Por ello, me gustaría dar unos pocos consejos de seguridad que podréis aplicar o decir a vuestros familiares.

1- Cuidado con las falsas ofertas

Podremos importar las fiestas de fuera, pero la picaresca española siempre está ahí. Se ha detectado el caso en varias tiendas de supuestas rebajas que realmente no lo son. Por ejemplo, el caso de una cámara GoPro que hace dos lunes valía 375€, el lunes pasado subió a 446€ para hoy poder hacer descuento volviendo al precio original. Mas info aquí.

2- Ofertas recibidas por correo electrónico

Durante estos días, nuestras bandejas de entrada están siendo bombardeadas por las ofertas de todas las tiendas en las que hemos hecho alguna compra. Esto lo saben también los delincuentes, que aprovechan esta fiebre consumista y de spam para colar sus “regalitos”. Como consejo, es recomendable desconfiar de los correos recibidos de páginas web que no conozcamos. En el caso de recibir un correo de una web conocida, vale la pena que no pulsemos en el enlace y que visitemos directamente la web. Recordad de los correos anteriores lo fácil que era suplantar una dirección email.

3- Sistemas de pago seguros

Desconfiad de sitios que os obliguen a pagar mediante Wester Union o Moneygram. Estas empresas tienen un largo historial de uso por parte de los delincuentes ya que ponen las cosas muy difíciles a los compradores en casos de estafa.

4- Si algo no cuadra, dejad pasar la oferta o preguntad

Como no tengo espacio para muchos más consejos, voy a dar un último consejo genérico. Cuando algo no cuadra, inmediatamente lo sabemos. No es normal un iPhone 6s a 300€ y huele a estafa a km. Ante la duda, desconfiad.

Pasad un buen fin de semana.

David Lladró
Responsable de Seguridad en Datadec Online

[subscribe2]

04 Sep 2015

SSH restringido desde Windows

El otro día, un compañero me planteó el siguiente problema: ¿Cómo puedo hacer que un usuario de Windows ejecute, en un linux, unos comandos específicos a través de SSH sin saber el password del usuario destino?

Mi respuesta fue: Para lo del password, habrá que usar certificados. Para lo otro, déjame que te lo mire. Y así empezó el “viaje” que me llevó a conocer un poco más SSH. Para aclarar el escenario, voy a explicarlo con un poco más de detalle.

Tenemos a un usuario del dominio de Windows que va a ejecutar un fichero .bat o .ps1… Este fichero tendrá una llamada a la versión de linea de comandos de putty (plink) para ejecutar un script remoto en una máquina linux. Esta típica configuración presenta un gran problema, el usuario puede ver el password en claro en el fichero .bat. ¿Cómo solucionarlo? Vamos a ello.

Configuración del servidor Linux

El servidor Linux en el que se vayan a ejecutar los comandos no debe tener ninguna característica especial que lo diferencie de otros Linux. La primera opción que hay que configurar el el fichero authorized_keys del usuario que va a ejecutar los comandos:

[root@srerver]# cat /home/user/.ssh/authorized_keys 
command="/usr/local/bin/wrapper.sh",no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa CLAVE_PUBLICA_SSH rsa-key-20150703

Esta línea realiza lo siguiente:

  • command=”/usr/local/bin/wrapper.sh”: Cuando se realice una conexión con la CLAVE_PUBLICA_SSH, ejecuta el script wrapper.sh.
  • no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding: Estas opciones deshabilitan las capacidades extras de SSH para evitar que se abuse de la cuenta utilizada.
  • ssh-rsa CLAVE_PUBLICA_SSH rsa-key-20150703: esta parte de la línea es donde se incluirá la clave pública RSA que se generará en los pasos siguientes.

Con la configuración actual, cuando se intente ejecutar un comando vía SSH, este no se ejecutará, ya que hemos puesto en la configuración que ejecute el script wrapper.sh. Este script será el encargado de comprobar que el comando que llegue sea uno de los permitidos y de ejecutarlo:

[root@server]# vim /usr/local/bin/wrapper.sh
#!/bin/sh
# Script: /usr/local/bin/wrapper.sh 

case "$SSH_ORIGINAL_COMMAND" in
        "/u01/script/elevated_command.sh")
                $SSH_ORIGINAL_COMMAND
		echo "elevated_comand ejecutado " 
                ;;
        "scp -r -p -f /etc")
                $SSH_ORIGINAL_COMMAND
                ;;
   
        *)
                echo "Command: $SSH_ORIGINAL_COMMAND" >> ~/command.txt
                exit 1
                ;;
esac

Este script, aprovecha la funcionalidad de SSH que guarda en la variable $SSH_ORIGINAL_COMMAND el comando original que se había pasado por parámetro. Por lo tanto, este script incluye en un switch todos los comandos permitidos para posteriormente, ejecutar el correcto.

Hay que tener en cuenta, que en muchas ocasiones, el comando que se ejecuta internamente, no es exactamente igual al que se pasa por parámetro. Por eso, se ha añadido la opción de *) que guardará en el fichero command.txt cual ha sido el comando interpretado.

No hay que olvidar que dicho script debe tener permisos de ejecución:

[root@server]# chmod +x /usr/local/bin/wrapper.sh

Configuración del equipo Windows

Windows todavía no dispone de herramientas nativas para la ejecución de comandos SSH. Por esto, vamos a necesitar diferentes herramientas:

Lo primero que necesitaremos, será generar el par de claves RSA. Para ello, ejecutaremos PuTTyGen. Para asegurarnos de que la clave sea lo suficientemente robusta durante unos años, habrá que cambiar en la parte inferior derecha el parámetro “Number of bits in a generated key:” de 2048 a 4096. Seguidamente deberemos pulsar en “Generate”:

putty_key_generator

Una vez generada la clave, deberemos exportar la clave privada de dos formas diferentes, la nativa de Putty y la de OpenSSH. Para exportar la clave privada de forma nativa, pulsaremos en “Save private key”, lo que nos abrirá un menú para guardar el fichero *.ppk

Para exportar la clave en formato OpenSSH, hay que pulsar en el menú “Conversions” y luego en “Export OpenSSH key” en formato *.key.  Esto es necesario porque en función del programa que utilicemos, necesitará la clave privada en un formato o en otro.

Por último, nos queda copiar la clave pública que se encuentra en el cuadro con título: “Public key for pasting into OpenSSH authorized_keys file”. Una vez copiada, la incorporaremos al fichero authorized_keys del servidor Linux.

A continuación, se muestra un ejemplo de uso de dicho sistema:

@echo off
REM /* cwRsync utiliza una unidad virtual llamada /cygdrive/ por lo que las rutas debe
REM    ser relativas a esa unidad /*
SET LOG_DIR="/cygdrive/C/logs"
SET LOG_DIR_NOTEPAD="C:\Programs\Notepad\logs"
SET RSYNC="C:\cwRsync_5.4.1\rsync.exe"
SET PLINK="C:\plink.exe"

REM En windows no es necesario encerrar el comando entre comillas simples. Si lo
REM hacemos, debermos incluir dichas comillas en el script wrapper.sh
REM Plink utiliza el formato de clave privada nativo de Putty en fichero *.ppk

%PLINK% -v -ssh -i C:\private.ppk user@10.0.0.1 /u01/script/elevated_command.sh

REM cwRsync utiliza el formato de clave privada de OpenSSH en fichero *.key

%RSYNC% -av -e "/cygdrive/c/cwRsync_5.4.1/ssh -i C:\private.key" user@10.0.0.1:/u01/logs %LOG_DIR%

Con esto hemos visto un ejemplo de ejecutar un comando mediante ssh y realizar un rsync sin necesidad de contraseña y limitando los comandos que se pueden ejecutar.

David Lladró
Responsable de Seguridad en Datadec Online

[subscribe2]

20 May 2015

Solventado el bug de Suricata y los proxies

Una de las mejores prácticas en lo que a seguridad corporativa se refiere, es la implantación de un proxy para la navegación web. Con esta medida, se puede controlar el tráfico web que abandona la organización.

Una de las medidas de seguridad mas aplicadas, es la de restringir en el firewall todo el tráfico web, excepto el que proviene del proxy. Con esta medida, evitamos la conexión de malware sencillo que no lee la configuración de proxy del sistema.

Sin embargo, si disponemos de un sistema de detección de intrusiones ( en nuestro caso, Suricata ) nos vamos a encontrar con diferentes problemas. A continuación explico dichos problemas y los workarounds que he utilizado.

proxy

El primer problema que nos encontramos es que los orígenes o los destinos de las alertas nos son inservibles. En la imagen anterior, si Suricata está escuchando antes del proxy, nos vamos a encontrar con que todos los paquetes http tienen como destino el proxy. Si por el contrario ponemos Suricata entre el proxy y el firewall, nos encontraremos con que los paquetes http tienen como origen el proxy.

Una posible solución, sería activar en el proxy la cabecera X-Forwarded-For. De esta forma, todos los paquetes que salieran del proxy llevarían una cabecera HTTP con la IP interna y Suricata podría hacer el matching. El problema de esta aproximación, es que si el firewall no elimina dicha cabecera, se enviaría al servidor web destino con el consecuente problema de privacidad.

Si no se puede eliminar la cabecera en el firewall, podríamos tratar la IP del firewall como una IP externa, así las reglas de Suricata podrían volver a funcionar correctamente. Para hacer esto, simplemente hay que editar el fichero de configuración de Suricata ( por defecto, se encuentra en /etc/suricata/suricata.yaml ) y modificar la variable $HOME_NET e indicar que la IP del proxy no pertenece a esa variable:

HOME_NET: "[10.0.0.0/24,!10.0.0.254]"

Esto debería ser suficiente para arreglar nuestro problema, pero actualmente existe un bug en Suricata que hace que el inicio del programa sea extremadamente lento. En mis pruebas, dicho inicio duró mas de dos horas.

¿Que podríamos hacer para solventar el problema? La opción que utilicé es la de modificar las reglas mediante un sencillo script. El primer paso es declarar la variable PROXY_SERVERS en el fichero de configuracion:

PROXY_SERVERS: "[10.0.0.254,10.0.0.253]"

El segundo paso sería reemplazar todas las referencias a EXTERNAL_NET por PROXY_SERVERS. ¿Todas? La respuesta es …. no. Solo deberíamos reemplazar las reglas que empiecen por “alert http ….”. De esta forma, nos aseguramos que solo modificamos las reglas que queremos.

Asumiendo que tenemos nuestras reglas en /opt/reglas/ y que disponemos del directorio /opt/reglas_proxy, solo deberíamos ejecutar el siguiente script:

#!/bin/bash

#For que recorre todos los archivos .rules
for archivo in $(ls /opt/reglas/); 
do
  #Reemplazo condicional. Si la linea empieza por "alert http" substituir
  #$EXTERNAL_NET por $PROXY_SERVERS y guardarlo en un nuevo fichero
  sed '/^alert http/s/$EXTERNAL_NET/$PROXY_SERVERS/g' /opt/reglas/$archivo > /opt/reglas_proxy/$archivo
done

y cambiar el directorio de las reglas en el fichero de configuración de Suricata.

David Lladró
Responsable de Seguridad en 
Datadec Online

[subscribe2]

27 Ene 2015

¿Tan malos son nuestros passwords?

WorstPasswords-2014Recientemente ha aparecido una de esas listas que más gustan a los medios de comunicación: la lista de los passwords mas usados en 2014. Como ha ocurrido en los últimos años, la compañía SplashData ha hecho pública su lista de las contraseñas más usadas en 2014. Como era de esperar, 123456 y sus variantes copan la mayoría del top ten.

Esto me hace reflexionar sobre la labor de concienciación que realizamos en materia de seguridad y hacerme la pregunta que da título a este post: ¿Tan malos son nuestros passwords? La respuesta, menos mal, es no.

La información importante de esta lista no es el top ten, sino los porcentajes de ese top ten. Por ejemplo, vamos a analizar el caso del password ‘123456’. En 2011, el porcentaje de passwords que era ‘123456’ se situaba en el 8,5%. En 2014, ese porcentaje disminuyó hasta menos del 1%, lo cual es aceptable. Como se desprende de estas estadísticas, la cultura de seguridad sí que está calando en la sociedad y cada vez los passwords que se usan son mejores.

Pero no todo van a ser buenas noticias. Desgraciadamente, los passwords siguen siendo débiles y resulta bastante sencillo obtener las contraseñas de los usuarios. Vamos a hacer un ejercicio de cracking. Nos vamos a poner en el caso que hemos obtenido una lista de contraseñas cifradas en MD5 de la empresa Empresa S.A. y queremos obtener contraseñas de forma rápida. Para ello, deberíamos generar un diccionario con las siguientes reglas:

  • Hacer una lista de usuarios de la empresa buscando en fuentes de información pública. Añadir estos usuarios a la lista de passwords.
  • Añadir variaciones de los nombres de usuario: dlladro, Dlladro, DlladrO, dll4dr0, Dll4dr0…
  • Añadir a los nombres de usuario 3 cifras: dlladro1, dlladro11, dlladro111, dlladro999
  • Realizar las mismas acciones con el nombre de la empresa: empresa, Empresa, 3mpr3s4…
  • Añadir todos los posibles números de 9 cifras desde 000000000 hasta 999999999. Con esta regla obtendríamos todas las contraseñas que sean fechas (01012015), DNIs, números de teléfono…

Con esta lista bastante genérica, obtendríamos de forma rápida, muchas credenciales de la empresa atacada. Una vez terminado este ataque, podríamos empezar con un ataque de fuerza bruta clásico utilizando una tarjeta gráfica.

A modo de ejemplo, os adjunto una imagen de lo que se tardaría en obtener una contraseña en función de su complejidad y longitud con una tarjeta gráfica potente (200€ aprox).

MD5- AMD R9 290

 Viendo esta gráfica, el panorama parece desolador para los usuarios. ¿Como se puede recordar múltiples contraseñas del tipo Adj37%·dsaDASF? Imposible para un ser humano normal. Pero, ¿sería difícil recordar una contraseña como “escribo en blog seguridad informatica”?

No lo creo, es mas, yo creo que ya la han memorizado. Sin ninguna dificultad, se puede memorizar contraseñas de 37 caracteres o incluso más. Así que no hay excusa para cambiar las contraseñas por unas robustas y sencillas de recordar.

David Lladró
Responsable de Seguridad en 
Datadec Online

[subscribe2]

31 Jul 2014

Radiografías y pentest

Me gustaría contaros una historia que me ocurrió el otro día y que me hizo pensar en las similitudes que tiene mi trabajo (Seguridad de la información) con los accidentes que ocurren a diario.

Imaginaos la situación, son las 8 de la tarde y había quedado con unos amigos para cenar. Ese día tenía especialmente prisa porque tenía que pasar a hacer unos recados antes de ir a casa de mis amigos. Cogí el móvil, la cartera y salí de casa junto con mi pareja. No tuve que dar ni 5 pasos para darme cuenta de que no había cogido las llaves de mi casa.

En aquel momento le dije a mi pareja:

–          Déjame las llaves, que me he dejado las mías dentro.
–          Vaya, yo también me las he dejado dentro.Read More

24 Jul 2014

Auditoría de seguridad a WordPress

En el pasado post, hablé sobre cómo proteger nuestra instalación de WordPress en sencillos pasos. En el post de esta semana, vamos a dar un paso más en la protección de nuestra instalación y vamos a realizar una serie de comprobaciones para saber si hemos hecho bien las cosas.

Para hacer estas comprobaciones, nos vamos a apoyar en una herramienta que caería dentro de la categoría de “analizadores de vulnerabilidades web”: WPScan. Esta herramienta está centrada en la tecnología WordPress y está escrita en el lenguaje Ruby.

Antes de seguir con el post, me gustaría recordar que estas herramientas lanzan ataques simulados contra las páginas web analizadas, por lo que es estrictamente necesario disponer de un permiso por escrito que nos autorice a enviar dichos ataques. Así que no probéis las herramientas del post contra este blog ;)…Read More

17 Jul 2014

Protege tu WordPress de forma sencilla

Proteje tu wordpressEn el post de esta semana, me gustaría centrar mi atención sobre uno de los CMS (Content Management System) más utilizados actualmente: WordPress. Junto con Blogger, la plataforma de Google para blogs, ha conseguido que generar contenido en Internet sea una cosa sencilla. Otro de los logros ha sido que personas con conocimiento 0 de programación puedan tener su página web en unos pocos y sencillos pasos.

Pero su sencillez es también un arma de doble filo ya que muchas veces se olvida el mantenimiento del blog, lo que provoca que se produzcan incidentes de seguridad. Para evitar esto, os propongo una serie de consejos con los que evitar ser víctima de un ataque informático.

Este post está enfocado para un público sin muchos conocimientos en seguridad o sistemas y pretende mostrar cómo proteger WordPress de forma sencilla. En el caso de que el lector sí que posea dichos conocimientos en informática, recomendaría complementar los consejos de este post con la guía Hardening WordPress” . Vamos pues a ver de qué forma podríamos asegurar nuestra instalación:Read More

10 Jul 2014

El cibercrimen, un negocio muy lucrativo

Seguridad informática

Me gustaría estrenarme en este blog con una entrada donde se repase de forma global cuáles son los principales actores, sus motivaciones y las cifras que se barajan en el negocio del cibercrimen.

Esto nos dará una idea, tanto a los usuarios como a las empresas, de los peligros a los que nos enfrentamos para poder tomar acciones en consecuencia y protegernos.

Cuando hablamos de cibercrimen nos referimos a todos los delitos que se pueden cometer a través de medios electrónicos. Esto incluiría desde la modificación ilegal de las páginas web, hasta el robo de dinero de una cuenta bancaria, pasando por los timos mediante correos electrónicos o el robo de información confidencial.

Como vemos, la cantidad de posibles ataques que podemos recibir se adivina enorme y así lo demuestran las constantes noticias sobre ataques a grandes empresas. Esto nos hace preguntarnos:Read More

24 Jun 2014

Seguridad informática

Bienvenid@ a nuestro nuevo blog en el que escribiremos constantemente sobre la seguridad informática. Desde consejos y recomendaciones, pasando por las mejores prácticas, hasta noticias de interés y el seguimiento de algunos grandes eventos relacionados con el tema que abordamos: la seguridad informática.

Si en cualquier momento quieres contactar con nosotros, sólo deberás rellenar el formulario de la página ‘contacto‘ y enseguida te escribiremos.

¡Hasta pronto!