Cómo saber si su Mac está en riesgo de ‘Shellshock’

shellshock
Si esto le sale, está en peligro.
shellshock
Si esto le sale, está en peligro.

Ayer jueves salió un problema de seguridad informática que tiene a todo el mundo con los pelos de punta. El bug se llama ‘Shellshock’ y ataca Bash, un programa que se usa para darle comandos a las máquinas. Bash está instalado en más del 70% de la máquinas conectadas a internet y es fundamental en los sistemas operativos basados en Unix (Linux y Mac OS X). Además afecta a miles de servidores que corren Apache o algún otro programa de Linux.

Sin embargo, como Bash está instalado por defecto en OS X, teóricamente todos los computadores con la versión más reciente del sistema operativo podrían estar en riesgo. Apple, teniendo en cuenta la importancia de la vulnerabilidad, le dijo a iMore que «la gran mayoría de los usuarios de OS X no están en peligro […] con OS X, los sistemas están protegidos por defecto y no están expuestos a vulnerabilidades remotas de Bash al menos que el usuario haya configurado los servicios avanzados de Unix».

Cómo dice iMore, si usted un usuario suficientemente avanzado para configurar estos servicios, también podrá desactivarlos o corregir el bug con Xcode. No obstante, también puede seguir los siguientes pasos para saber si su computador esta bajo riesgo.

El primer paso es abrir Terminal y escribir el siguiente código:

 env X="() { :;} ; echo vulnerable" /bin/sh -c "echo stuff"

Si la consola le responde «vulnerable stuff», usted está abierto a un ataque de ‘Shellshock’. En estas dos páginas hay instrucciones para corregir el error (ReadWrite y WonderHowTo).

No obstante, para los usuarios comunes y corrientes seguramente no habrá problemas. Además, seguramente Apple lance un parche que corrija la vulnerabilidad automáticamente, de acuerdo con Ars Technica. Si no está cómodo metiendo comandos en Terminal, puede esperar un rato a que esto ocurra.

Aunque ‘Shellshock’ tiene el potencial de ser devastador, la mayoría de usuarios promedio no tienen por qué preocuparse. En cambio, los administradores de servidores y usuarios avanzados deben tomar las medidas adecuadas para proteger sus sistemas.

Imagen: ENTER.CO

Mateo Santos

Mateo Santos

En vez de un tetero, nací con un Mac Classic en mi cuarto. Esa caja con pantalla en blanco y negro fue mi primera niñera. Por ahí, también rondaba un balón de fútbol y una camiseta de Millonarios. Desde ese día, sabía que la tecnología y el fútbol iban a ser mi estrella de Belén. El primer juego que tuve en mis manos fue Dark Castle, también en un Macintosh. No me gusta la música. Soy un amante escéptico de la tecnología. Hago parte del proyecto de ENTER.CO para llenar el vacío en información de tecnología que hay en América Latina, o como dirían los enterados, en LATAM. Me gradué de Administración de Empresas en los Andes y después hice una maestría en periodismo en la Universidad Europea de Madrid.

View all posts

16 comments

  • según entiendo el problema es un tipo de inyección de código en una aplicación en la que a nadie se le había ocurrido inyectar código. es una aplicación específica, y si los ataques vienen de afuera, serían atendidos por el puerto que atiende esa aplicación. según eso, para los usuarios caseros de mac, de pronto es simplemente usar algo que de pronto ellos ya han escuchado pero no conocen ya que supuestamente no lo necesitan, llamado ‘firewall’, y en el firewall, cerrar el puerto de hiperterminal, que para manejar el computador localemnte casi no se usa. no sé si eso ya quede, que alguien más corrija

    editado: el puerto de hyperterminal (telnet) en forma predefinida es el 23. pero no sé si el problema es con telnet o si esto lo arregla, si alguien está seguro mejor aclarar

    • Hasta donde vi son vulnerables todos aquellos que permitan acceder a una maquina con cualquier tipo de servicio que deje al usuario ejecutar comandos por bash por ejemplo si tienes configurado un servidor SSH, telnet etc, ademas de eso si tienes servidores web y dichos servidores web tienen alojadas paginas que dentro de sus funciones internas este el ejecutar comandos del sistema tambien pueden ser vulnerables sumando a lo anterior cualquier aplicacion que haga uso de bash internamente tambien abre el agujero.

      En cuanto se reporto el problema ayer las principales distribuciones GNU/Linux sacaron parches y en la manana lei en internet la noticia y probe si mis PCs eran vulnerables y si pero minutos despues revisando actualizaciones del sistema ya habia actualizaciones para bash que solucionaban de una forma el fallo. Hoy tambien ya habian nuevas actualizaciones ya que se iban implementando parches que cubrian parte del problema pero podian haber otras formas de explotarlo y por eso las nuevas actualizaciones de hoy.

      En teoria los que se podrian ver mas afectados son los portales de internet y no tanto los usuarios caseros.

      • si hay páginas web que permitan ejecutar comandos dels istema, creería que bash sería el mínimo de los problemas. la diferencia es que un portal de internet tiene ip conocida y quienes lo atacan saben a qué van, mientras que para atacar a los usuariso caseros es como adivinar quién está ahí, pero si le llegan, el ataque sería el mismo, y de hecho seguramente el administrador de un portal toma más madidas de seguridad que un usuario casero (o para el portal sería más devastador, pero seguramente más fácil para atacar al usuario casero)

        editado: aunque igualq ue la spáginas que dejen correr comandos del sistema, si no tiene firewall y alguien puede usar telnet desde afuera, con eso ya puede hacer estragos, bash o no bash. no comento más, lo que digo es basado en suposiciones

      • Eso es lo bueno de tener una buena distro de Linux, soportada por la comunidad. Ayer hice la prueba en un Debian 7.6, me marcó vulnerable. Esta mañana actualicé desde repositorios, y ya no me apareció más.

  • según entiendo el problema es un tipo de inyección de código en una aplicación en la que a nadie se le había ocurrido inyectar código. es una aplicación específica, y si los ataques vienen de afuera, serían atendidos por el puerto que atiende esa aplicación. según eso, para los usuarios caseros de mac, de pronto es simplemente usar algo que de pronto ellos ya han escuchado pero no conocen ya que supuestamente no lo necesitan, llamado ‘firewall’, y en el firewall, cerrar el puerto de hiperterminal, que para manejar el computador localemnte casi no se usa. no sé si eso ya quede, que alguien más corrija

    editado: el puerto de hyperterminal (telnet) en forma predefinida es el 23. pero no sé si el problema es con telnet o si esto lo arregla, si alguien está seguro mejor aclarar

    editado 2: estuve mirando a ver si ‘bash’ tiene su propio socket (puerto) y al parecer no, parece que es un comando del sistema, pero no un proceso servidor (si fuera así tocaría bloquear el puerto del proceso, pero eso sisgnificaría que si otro comando lo utiliza internamente causaría problemas, porque las cosas que ya funcionan dejaríand e funcionar). al parecer no es un proceso que use su propio socket (buscando por google). posiblemente se pueda simplemente bloqueando el puerto 23, pero eso significa que queda inservible hyperterminal (telnet), que para el usuario casero pues tampoco es que se use mucho

    thesmithfam. org/blog/2006/05/23/bash-socket-programming-with-devtcp-2/

    re-re-editado 3: de hecho para los usuarios ‘comunes y corrientes’ es el problema. si se conectan a internet, alguien puede mirar su dirección de internet y solicita conectarse al puerto 23 de esa dirección, y escribe algo que cause daño, ej: 192.168.1.1:23 (pero no con el navegador, que no sabe cómo abrir telnet)

    • Hasta donde vi son vulnerables todos aquellos que permitan acceder a una maquina con cualquier tipo de servicio que deje al usuario ejecutar comandos por bash por ejemplo si tienes configurado un servidor SSH, telnet etc, ademas de eso si tienes servidores web y dichos servidores web tienen alojadas paginas que dentro de sus funciones internas este el ejecutar comandos del sistema tambien pueden ser vulnerables sumando a lo anterior cualquier aplicacion que haga uso de bash internamente tambien abre el agujero.

      En cuanto se reporto el problema ayer las principales distribuciones GNU/Linux sacaron parches y ayer en la manana lei en internet la noticia y probe si mis PCs eran vulnerables y si pero minutos despues revisando actualizaciones del sistema ya habia actualizaciones para bash que solucionaban de una forma el fallo. Hoy tambien ya habian nuevas actualizaciones ya que se iban implementando parches que cubrian parte del problema pero podian haber otras formas de explotarlo y por eso las nuevas actualizaciones de hoy.

      En teoria los que se podrian ver mas afectados son los portales de internet y no tanto los usuarios caseros.

      • si hay páginas web que permitan ejecutar comandos dels istema, creería que bash sería el mínimo de los problemas. la diferencia es que un portal de internet tiene ip conocida y quienes lo atacan saben a qué van, mientras que para atacar a los usuariso caseros es como adivinar quién está ahí, pero si le llegan, el ataque sería el mismo, y de hecho seguramente el administrador de un portal toma más madidas de seguridad que un usuario casero (o para el portal sería más devastador, pero seguramente más fácil para atacar al usuario casero)

        editado: aunque igualq ue la spáginas que dejen correr comandos del sistema, si no tiene firewall y alguien puede usar telnet desde afuera, con eso ya puede hacer estragos, bash o no bash. no comento más, lo que digo es basado en suposiciones

      • Eso es lo bueno de tener una buena distro de Linux, soportada por la comunidad. Ayer hice la prueba en un Debian 7.6, me marcó vulnerable. Esta mañana actualicé desde repositorios, y ya no me apareció más.

Archivos