Cómo una vulnerabilidad en Bash de Linux, OS X y *NIX es un gran problema de seguridad para todo Internet

Si alguna vez habéis trabajado con OS X o Linux, seguro que conocéis bash. Es la terminal por defecto de estos sistemas, donde ponemos los comandos que queremos ejecutar. Es el espacio de trabajo, el equivalente al escritorio cuando usamos el ratón.

Como podréis imaginar, bash es omnipresente y no lo usamos sólo los usuarios sino también muchos programas para ejecutar algunos comandos. Por ejemplo, hay páginas web que internamente llaman a bash para generar algunas páginas (CGI), servidores (y ordenadores) que usan DHCP para obtener sus direcciones IP al conectarse a Internet, y muchas más cosas. Imaginaos qué divertido sería que hubiese un fallo en bash. O mejor aún, no os lo imaginéis: está pasando. De hecho, hasta tiene nombre y todo: Shellshock.

> El problema: ejecutando código cuando no toca

Para funcionar, los programas necesitan datos. Supongamos un servidor de Internet que llama a unscript de bash para generar una página web. Este script necesitará datos, como las cookies, la ruta de la página que se pide o la cadena que identifica al navegador (user-agent). La forma de pasar estos datos a bash son las llamadas variables de entorno.

La analogía sería que tu ordenador es una habitación. Tú, el servidor, recibes una petición de un usuario y escribes algunos datos sobre esa petición en una pizarra. Luego llamas a bash para que pase a la habitación y haga lo que tiene que hacer. Y una de las primeras cosas que hará será leer de la pizarra los datos que le has dejado (las variables de entorno).

Normalmente, esto funciona bien. La shell (bash) llega, lee los datos, ejecuta sólo lo que tiene que ejecutar y listos. El problema es que a veces, con una cadena especialmente preparada, no sólo lee los datos sino que los ejecuta. Más concretamente, bash ejecuta los comandos que encuentre después de la definición de una función en una variable de entorno. Algo como esto:

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

debería definir una función llamada x que no hace nada (el cuerpo de la función es lo que está entre llaves {}). La cuestión es que después bash sigue leyendo y ya no sólo se limita a leer valores sino a ejecutar el código que viene, en este caso echo vulnerable, que imprime «vulnerable» por pantalla.

> ¿Cómo se puede explotar el fallo?

Bien, ya sabemos cuál es el fallo. Ahora bien, ¿para qué sirve? ¿Cómo se puede alguien aprovechar de ello?

Decíamos al principio que bash está presente en prácticamente todos los ordenadores, y muchos lo tienen expuesto de alguna forma u otra. El ejemplo más llamativo es el de los servidores que generan páginas con bash. En esos casos, simplemente con crear una petición en la que el identificador de navegador (user agent) sea algo como () { :; }; micomandoaquí, podríamos ejecutar comandos arbitrarios en esos servidores. Y con comandos arbitrarios quiero decir que se puede usar la vulnerabilidad para cualquier cosa, desde tumbar todos los servidores vulnerables en un momento hasta montar una enorme botnet, pasando por supuesto por montar ataques de denegación de servicio haciendo que todos los vulnerables envíen tráfico a un cierto objetivo.

Ese es el principal punto de explotación del fallo, y es grave porque es muy fácil de aprovechar. Para que os hagáis una idea, en apenas unas horas y con una búsqueda automatizada muy ingenua, en Errata Sechan encontrado más de 3000 servidores vulnerables. Perfeccionando un poco esa búsqueda y con más capacidad de escaneo, un atacante se podría hacer con muchos sistemas. De hecho, esos ataques ya están en marcha.

Pero no son sólo esos servidores que ejecutan scripts de bash. En Redhat explican que DHCP (el protocolo para que un ordenador obtenga su dirección IP y más instrucciones para conectarse a Internet cuando entra en una red) podría ser otro punto de ataque, ya que permite que el servidor pase variables de entorno que serían interpretadas por el cliente.

En ese caso, sería posible que un servidor de DHCP vulnerable pudiese atacar además a todos los dispositivos que se conecten a su red. Imaginaos qué desastre en grandes empresas.

También es posible que otros servicios, como servidores que ofrecen shells restringidas a sus usuarios (algunos servidores de Git, por ejemplo), puedan ser vulnerables: este fallo permitiría a un atacante saltarse esas restricciones y obtener acceso completo. Además, teniendo en cuenta quebash está presente por todas partes y que muchos programas lo usan incluso sin darse cuenta, podríamos ver todavía más vectores de ataque.

> ¿Soy vulnerable? ¿Cómo puedo protegerme?

Empecemos diciendo que si no gestionas ningún servidor expuesto a Internet no deberías preocuparte, probablemente. Los sistemas afectados son los que tienen bash, así que estamos hablando de sistemas Linux, OS X y demás derivados UNIX (BSD, Solaris…).

La mayoría de distribuciones Linux ya han distribuido un primer parche, aunque está incompleto y no acaba de corregir del todo la vulnerabilidad. Imaginamos que en cuanto los desarrolladores debash saquen el parche definitivo lo distribuirán a todos los usuarios. Mientras, una opción puede ser desactivar bash y usar otra shell hasta que esté cien por cien parcheado (nota: hacedlo sólo si sabéis lo que estáis haciendo).

Los que están un poco más expuestos son los usuarios de Apple. Los de Cupertino, con su rapidez habitual en temas de seguridad, todavía no han dado ninguna respuesta. Por suerte, estos ordenadores suelen estar menos abiertos a Internet, y en última instancia ya hay instrucciones para parchear su instalación.

Si queréis comprobar si vuestro sistema está afectado, podéis ejecutar estos dos comandos (el primero para el fallo original, el segundo para el parche incompleto). En el primer caso, si imprime «vulnerable», todavía no estáis parcheados. El segundo test creará un archivo llamado «echo» si no estáis parcheados.

env x='() { :;}; echo vulnerable' bash -c "echo Fallo 1 parcheado"
env X='() { (a)=>\' sh -c "echo date"; cat echo

Más información | CVE 2014-6271 – CVE 2014-7169 (vulnerabilidad 2) | Lcamtuf

Fuente | Genbeta

 

La seguridad de Lion en entredicho: es posible (y relativamente fácil) obtener las contraseñas de los usuarios

Únicamente necesitamos una utilidad convenientemente programada, como la herramienta DaveGrohl para obtener la contraseña del usuario, mediante fuerza bruta.

Levantemos la mano los que tenemos una contraseña para evitar ojos y manos indiscretas en nuestras respectivas máquinas. Es una buena manera de mantener a los neófitos lejos de nuestra máquina (y, por ende, de nuestros datos).

Aunque sería interesante saber hasta qué punto nuestra máquina está segura. En Windows, por ejemplo, muchos no utilizamos BitLocker. Sabemos que con un LiveCD de Ubuntu y poca maña es más que posible ver todos los archivos del equipo. Y vulnerabilidades de este tipo las hay en todos los sistemas operativos, todas (o casi todas) por descuido del usuario. No es el caso.

En el caso de OS X, lo que se descubrió hace tiempo, es que es posible extraer la contraseña de un usuario, siendo necesario únicamente acceso físico a la máquina. Vemos cómo.

Lion almacena ciertos datos del usuario (la contraseña, convenientemente cifrada, entre ellos) en archivos .plist, visibles únicamente por usuarios con privilegios elevados (básicamente, por usuarios root). Y aquí viene el primer detalle: es posible cambiar la contraseña de root sin tener cuenta de usuario en el equipo, únicamente teniendo acceso físico al mismo.

Teniendo la contraseña de root tendremos, por tanto, acceso al equipo mediante la cuenta root. Y teniendo una cuenta con privilegios de administrador tenemos acceso a esos archivos .plist que comentaba en el párrafo anterior. Únicamente necesitamos una utilidad convenientemente programada, como la herramienta DaveGrohl para obtener la contraseña del usuario, mediante fuerza bruta.

Esa utilidad extrae automáticamente el hash de la contraseña (codificada mediante SHA-512), que estará en el archivo /private/var/db/dslocal/nodes/Default/users/[tu nombre de usuario aquí].plist y, mediante los diccionarios correspondientes (incluso los que podemos crear e introducir nosotros mismos), obtiene la contraseña. Todo ello, reitero, siendo únicamente necesario acceso físico a la máquina.

Aunque es importante resaltar que, aunque en este caso el descuido del usuario al poner una contraseña débil o no proteger sus datos lo suficiente no se aplica (es un bug o una feature del sistema operativo, vaya), sí que sigue siendo necesario tener acceso físico a la máquina. Y con acceso físico a la máquina podría incluso destruirla. Por lo que no estoy diciendo que OS X sea poco seguro, sino que tiene ciertas vulnerabilidades y que éstas son públicas, como en el caso de todos los sistemas operativos.

Fuente

Malware para Mac. Mentiras y verdades

«Numerosas campañas afirman estar a salvo de Malware gracias a las defensas integradas de Mac OS X»

Con la excusa de la reciente aparición de rogueware para Mac (algo relativamente novedoso) vamos a intentar aclarar algunos mitos con  respecto al mundo del malware para Mac donde, según percibimos, campa  la imprecisión, medias verdades y mitos marquetoides. Esto afecta a  usuarios, casas antivirus e incluso la propia Apple.

Apple se encarga (y le interesa) que continúe así. Numerosas campañas  publicitarias nada rigurosas lo demuestran. Por ejemplo, confunde al  potencial cliente afirmando que, gracias a su sistema, quedará «inmune  a los virus del PC». Ese «del PC» con la que termina la frase, es una  afirmación que a veces es omitida por los usuarios. Y aunque fuese  cierta (que no lo es, solo habría que programar en Java, entre otras posibilidades), está realizada con poco rigor técnico. La página oficial
muestra mensajes como «El Mac es invulnerable a los miles de virus que amenazan a los ordenadores con Windows gracias a las defensas integradas de Mac OS X». No son miles, sino millones. Y no es gracias a las defensas, sino a una arquitectura diferente. A tenor de los datos expuestos en el boletín anterior (sobre la base de datos de VirusTotal y las muestras recogidas en los últimos 30 días):

• Malware Android: 117 muestras únicas

• Malware Symbian: 54 muestras únicas

• Malware para iPhone: una única muestra

Sería como si Nokia promocionase sus terminales afirmando que Symbian es «inmune a los cientos de virus que amenazan a los terminales con Android, gracias a sus defensas integradas». Una propuesta publicitaria más honesta, describiría las características técnicas de Mac OS X para luchar contra su propio malware, no contra el de plataformas con las que no es compatible ni comparable.

Por otro lado, a muchas casas antivirus que quieren conquistar la cuota de mercado de Apple les interesa inducir «miedo» en el usuario. Esto puede percibirse como una exageración u oportunismo y, por tanto, como una falsa alarma a la que no es necesaria prestar atención. En realidad sí existe peligro, y no hay que desdeñar la opinión de las casas antivirus, aunque tengan intereses comerciales en el asunto. Como siempre, se deben observar sus apreciaciones con criterio y perspectiva.

Por último, el perfil típico de usuario de Apple tiende a «proteger» la marca. Esto puede llevarle a no ser objetivo, y «querer creer» en ciertas afirmaciones para mantener un status que suponen inquebrantable. Es uno de los mayores logros comerciales de Apple: la creación de una imagen de marca, de un «estilo» que hace que los usuarios se influyan mucho entre sí y confíen ciegamente en el producto.

En definitiva, la eterna pregunta es: ¿podemos esperar que la industria del malware tenga como objetivo mayoritario Mac OS en un futuro próximo? Es posible, pero no demasiado probable. Se lleva años hablando de lo mismo. En 2007 se vivió un repunte del malware para Mac, que no ha prosperado hasta estas fechas en que parece que vuelve a despuntar tímidamente. Una teoría es que lo único que mantiene a Mac OS fuera del circuito del malware masivo es su cuota de mercado. Otra es que las características técnicas de Mac impiden que sufra un ataque masivo como el de Windows. Pero esto no es cierto.

Si nos detenemos en los aspectos técnicos, Windows contiene cada vez más características positivas de Mac OS y Apple está cometiendo cada vez con mayor frecuencia errores que Microsoft tiene superados. Por ejemplo, la gestión de seguridad global en Microsoft (desde la programación al parcheo) se ha ido perfeccionando con el tiempo mientras que la de Apple parece que no levanta cabeza (ya dijimos en la entrega anterior que Apple, en número, sufre ya más vulnerabilidades que Microsoft).

Otro ejemplo técnico en el que cada vez se parece más, es el hecho de usar el sistema con privilegios limitados. Es una de las mejoras defensas contra el malware. Mac OS tuvo la precaución de obligar al usuario a no ser root en el sistema por defecto. Esta medida la ha adoptado Windows sólo desde Vista. Por tanto, en este sentido Windows siempre fue un objetivo sencillo. Ahora que ambos limitan los permisos del usuario por defecto, los creadores de malware se enfrentan en igualdad de condiciones a los dos sistemas operativos. Además, ciertas variantes de rogueware, que en los últimos tiempos se ha mostrado muy lucrativo, ni siquiera depende de este tipo de restricciones.

Otra ventaja para los creadores de malware es que Mac OS es un sistema relativamente homogéneo (una configuración parecida en todas sus variantes). Esto facilita la labor de programar malware que funcione correctamente en todas las versiones, como siempre ha ocurrido en Windows, donde la homogeneidad es total.

Fuente