Knocking on servers doors

28 de septiembre de 2015 Por

¿Quién no ha visto en algún tebeo o película al protagonista golpeando unos puntos concretos en la pared o moviendo unos libros de la librería para que mágicamente se abra un acceso oculto? Quizás surgió de ahí la idea de crear Port Knocking, un script cuyo funcionamiento se podría comparar al de una combinación que permite abrir una caja fuerte.

El objetivo de esta herramienta es habilitar de forma temporal el puerto al que se quiere conectar mediante una serie de llamadas previas a otros puertos (knocks) en un orden determinado. El único requisito previo para que funcione es tener instalado un firewall a nivel local, que será quien habilite y bloquee los accesos realmente. En nuestro caso utilizaremos iptables, el cual ya viene incluido en distribuciones como Debian, junto a iptables-persistent para no perder los cambios que vayamos realizando.

[Read more…]

Un script para correlarlos a todos

12 de junio de 2015 Por

En esta entrada vamos a hablar de la herramienta Simple Event Correlator (SEC), un script que realiza tareas de correlación cogiendo como fuentes cualquier tipo de log que podamos recibir en nuestros sistemas. Sus puntos fuertes son que no consume demasiados recursos en su ejecución y está escrita íntegramente en Perl, sin necesidad de librerías adicionales a las incluidas en la instalación por defecto de este lenguaje, por lo que podremos utilizarlo casi en cualquier plataforma.

El flujo de procesamiento que realiza se divide en tres partes: especificar qué logs queremos monitorizar, definir una serie de reglas que se comprobarán con cada nueva entrada en el log y, si aparece alguna correspondencia, se realizará automáticamente una acción definida previamente.

Las reglas están formadas por una serie de atributos para definir las acciones a realizar. Hay varios tipos de reglas que se pueden crear: detección de patrones, ya sean escritos en la propia regla (Single) o en un script (SingleWithScript), emparejar dos eventos independientes (Pair), o basadas en una hora y/o fecha específicas (Calendar) son varios ejemplos de lo que nos podemos encontrar entre todas sus opciones.

[Read more…]

Instalaciones mediante tutoriales: ¿sabemos lo que hacemos?

18 de marzo de 2015 Por

Alguien dijo en una ocasión: “Wikipedia es la nueva Biblia. Nadie sabe quién la escribió pero todo el mundo cree en ella”. Dejando aparte el acierto o no de la frase, se podría decir algo similar sobre los tutoriales que podemos encontrar por Internet. En este artículo vamos a hacer un breve análisis de lo que podemos encontrar en este tipo de guías (principalmente aplicable a las que están relacionadas con algún tema de informática, pero no por ello son las únicas) y hablaremos de una serie de precauciones y nociones básicas a tener en cuenta para no lanzarnos de cabeza con ellas, sino pensando y entendiendo lo que vamos haciendo.

Lo primero es buscar varias guías y echar un ojo por encima para ver los pasos que vamos a realizar y requisitos que necesitamos. Con ello podremos hacer un primer filtro sobre aquellos textos que nos parezcan excesivamente complejos o simplemente no nos enteremos de lo que estamos haciendo. Una vez hecho esto, pasamos a leer tranquilamente la guía elegida que vamos a seguir, con el objetivo de localizar posibles dudas que nos surjan y que no nos pille con las manos en la masa, al igual que erratas y similares. Si el tutorial contiene una sección de comentarios, es muy probable que otros usuarios hayan indicado los fallos que aparecen en el texto o problemas que les han surgido durante su realización, e incluso con la solución si tenemos suerte.

Hasta ahora solo hemos comentado cosas de sentido común. A continuación, entraríamos en la parte de seguridad, empezando por los enlaces que podamos ir encontrando a lo largo del tutorial. Por un lado, los que nos facilitan las descargas de ficheros que necesitemos sin tener que rebuscar demasiado en la página oficial del producto puede que nos proporcionen una versión obsoleta, quizás hasta con vulnerabilidades ya descubiertas, o incluso un fichero alojado en un hosting gratuito con “regalo” incluido (¿quién no se ha encontrado alguna vez con ese fichero nombre.zip.exe?).

Por otro lado, los enlaces acortados gracias a webs como TinyURL que tanto se pueden ver, por ejemplo, en descripciones de videos de YouTube, es posible que incluyan alguna que otra sorpresa (dependiendo de dónde estemos navegando y nuestro nivel de paranoia). Para estos casos existen dominios como TrueURL, mediante los cuales se puede averiguar el contenido de este tipo de redirecciones.

Comprobación de una URL abreviada

Como colofón, recomendar dar “un toque personal” a aquellas instalaciones donde se pueden configurar o editar algunas de sus propiedades. Para ello, vamos a ilustrarlo con un ejemplo basado en el gestor de contenidos WordPress. Tras realizar los preparativos previos (Apache, MySQL), nos conectamos a la dirección donde estamos hospedando el blog para comenzar la configuración inicial.

Configuración por defecto en WordPress

En muchas ocasiones campos como el nombre de la base de datos o los prefijos de la tabla se dejan con el texto sugerido por defecto para poder identificarlo fácilmente, pero para un posible atacante es una fuente de información que le puede ahorrar mucho trabajo.

Siempre es recomendable hacer modificaciones por otras referencias que nos resulten igual de fácil identificar que pertenecen al blog. Por ejemplo, si vamos a utilizarlo para promocionar el restaurante familiar cuyo nombre es “Arrocerías El Delfín”, podemos añadir una abreviatura al nombre de la base de datos y al prefijo de las tablas con el siguiente formato:

En definitiva, sobra decir que los pasos indicados anteriormente no son los únicos que podemos seguir para ir con pies de plomo. Incluso si seguimos buscando, seguro que podemos encontrar más consejos y continuar con un bastionado para aquello que estemos instalando, pero eso ya es tema para otra ocasión.

Vulnerabilidad en Bash explotable remotamente – CVE-2014-6271

25 de septiembre de 2014 Por

Hoy nos hemos levantado con una noticia a la altura del reciente Heartbleed: una vulnerabilidad en el intérprete de comandos Bash permite la posibilidad de ejecutar código remoto en la máquina. Esta vulnerabilidad ha sido catalogada como CVE-2014-6271 con una puntuación de CVSS de 10.

Están afectadas todas las versiones hasta 4.3 incluida. La vulnerabilidad se produce cuando el intérprete no procesa adecuadamente las variables de entorno. Mediante la declaración de funciones puede incluir al final código que será ejecutado independientemente del nombre de la variable; esto es especialmente crítico en servidores web que tengan instalados módulos CGI. Una forma rápida de comprobar si somos vulnerables o no es ejecutando el siguiente código:

env x='() { :;}; echo vulnerable'  bash -c "echo prueba en bash"

En ambos casos aparecerá lo último por pantalla ‘prueba en bash’. Si se muestra por pantalla la cadena de texto ‘vulnerable’, nuestra versión de bash estará afectada ya que ha seguido ejecutando el código añadido a la cola de la función; por el contrario, si vemos el siguiente mensaje de error, quizá no seamos tan vulnerables:

bash: warning: x: ignoring function definition attempt

bash: error importing function definition for `x’

La última frase no se ha dicho de forma arbitraria: pese a que ya ha sido publicado un primer parche, una investigación en profundidad del mismo ha demostrado que aún tiene posibles vectores de ataque, por lo que habrá que esperar a una nueva actualización para poder decir que ya está completamente solucionado.

Más información:

Permisos en Android y malware, el nuevo “He leído las condiciones del contrato”

3 de julio de 2014 Por

El malware no es nuevo a día de hoy, y uno de los sectores en los que más está creciendo es en el campo de los dispositivos móviles debido al auge continuo de smartphones y tablets. Un ejemplo de ello es la cifra proporcionada en el reciente Google IO 14 de 1000 millones de dispositivos Android activos actualmente.

Hace unos días aparecía un informe de McAfee donde se destacaba la cantidad de clones del juego Flappy Bird que cuentan con algún tipo de malware en su código. Curioso. Con este dato decidí hacer una revisión rápida a esa colección de clones para centrarme en los permisos solicitados por cada uno de ellos.

Pero claro, ¿cómo saber si son un exceso de permisos o no? Para ello, empecemos con nuestra propia lógica: es un juego sencillo que lo único que hace es guardar una puntuación máxima y de vez en cuando sale algún anuncio, por lo que deberíamos esperar al menos los permisos de conexión a internet y de almacenamiento. Casualmente decidí probar el juego en su momento y aún dispongo de acceso al mismo en mi historial de Google Play, así que pude acceder a ver los permisos que realmente necesitaba la aplicación:


Los permisos originales del juego.

Al final resulta que solo necesita tres permisos, los cuales son aceptables para lo que se espera de la aplicación. Sin embargo, a la hora de ver otras similares, nos encontramos con el siguiente abanico de opciones extra que debemos autorizar o no en función del clon elegido:


Recopilación de los múltiples permisos que pueden solicitar los clones. No es la lista de permisos de una aplicación.

Hasta cierto punto algunos de estos permisos son razonables. Por ejemplo, buscar cuentas en nuestro dispositivo para publicar nuestra última puntuación en la red social correspondiente: no nos garantiza que junto a nuestra marca personal además añada publicidad de otros productos ajenos al juego (un enlace a una web que oferta productos de China). Sin embargo, ¿por qué deberíamos permitir averiguar nuestra localización? ¿Es necesario para el caso anterior de compartir nuestro récord? ¿O realmente tiene otro propósito?

Instalando una de las aplicaciones en un dispositivo limpio (sin tarjeta SIM, formateado de fábrica y sin ningún dato de cuenta introducido) nos encontramos con la siguiente imagen. Referida al compartir lo que suponemos que era la tabla de récords, dado el inconveniente que nos encontramos con el idioma de la misma (coreano, concretamente). Las dos primeras redes sociales no hay problemas en reconocerlas, ¿pero las dos siguientes? ¿Y la opción de compartir por correo? ¿En verdad alguien la usa para enviar ese tipo de información?

No hay duda de que Google trabaja en mantener limpio su mercado de aplicaciones, pero se ve que hace falta mucho más control para evitar ya de base la posibilidad de subir aplicaciones comprometidas, y más aún si logran tener cierto éxito. Otro caso similar relativamente reciente fue el de las aplicaciones del tipo linterna que suscribían a servicios SMS de pago y conseguían ocultarlo hasta que llegaba la factura del mes, con permisos para leer SMS entre otros. ¿Nadie se extraña de eso en una aplicación que lo único que tiene que hacer es encender un LED?

Y es que al final la culpa no es solo de quien proporciona acceso a la descarga de la aplicación, sino también del propio usuario que por no gastar quince segundos mirando los permisos de la aplicación puede acabar pagando hasta 30 euros extra a fin de mes, junto a algún que otro susto.

Como consejo final, decir que si revisáis un contrato o una factura antes de firmarlo, ¿por qué no hacer lo mismo con el móvil y las aplicaciones que instaléis?