Comprueba si tu equipo Linux, Unix o Mac OS X es vulnerable a Shellshock Bash

Escrito por David Valero
Virus

Mientras muchas distribuciones de Linux aún aguardan el lanzamiento de actualizaciones de seguridad que corrijan la vulnerabilidad Shellshock. Si no queremos esperar  podemos realizar una simple prueba por nosotros mismos para determinar si nuestro sistema se ve afectado por este nuevo fallo.

La nueva vulnerabilidad conocida como Shellshock, que afecta a Bash está siendo uno de los principales focos de preocupación para los usuarios de Linux o Max cuyos sistemas aún son vulnerables a este problema de seguridad. Nuestros compañeros de Redes Zone ya nos explicaron ayer como la peligrosidad de este fallo permitía ejecutar código malicioso de forma remota en los servidores web y equipos a través del lenguaje de programación Bash de los sistemas Unix.

Aunque algunas distribuciones  de Linux ya han recibido los parches de seguridad solucionando el problema, hay todavía muchos sistemas que continúan siendo vulnerables, y lo que es peor, los menos conocidos corren el riesgo de que se repita un caso como el de Heartbleed y nunca lleguen a ser parcheados.

Si queremos estar seguros de conocer si nuestro equipo Linux, Unix o Mac es vulnerable a Shellshock podemos llevar a cabo unas pruebas para determinar si nuestro sistema requiere ser actualizado. Al afectar al Bash de Unix, son estos sistemas los que van a estar expuestos al riesgo de un ataque informático, pero desde el terminal podemos ejecutar un comando para saber si la vulnerabilidad nos afecta.

bash-bug

Comprueba si tu sistema es vulnerable

En el caso de ejecutar este comando:

env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’

Si nuestro sistema no es vulnerable debería aparecer lo siguiente:

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ hello

Por el contrario, una forma de confirmar que existe la vulnerabilidad sería recibir este otro mensaje:

vulnerable hello

Como nos cuentan desde Redes Zona, el mantenimiento a través de los gestores de actualización ha comenzado a llegar y aunque los usuarios de Mac todavía esperán la llegada de un parche, pueden optar por actualizar el Bash de Unix de forma manual. Si queremos conocer si nuestra versión requiere ser actualizada podemos ejecutar el siguiente comando que nos indicará que versión de Bash utilizamos:

bash –version

En el portal WonderHowTo explican de qué forma se puede llevar a cabo una actualización del Bash de forma manual. Por alcance y riesgo, los expertos de seguridad informática han situado esta nueva amenaza al nivel de Heartbleed, la grave vulnerabilidad descubierta hace meses que afectaba a las librerías OpenSSL.

Fuente > Lifehacker

Continúa leyendo
Comentarios
26 comentarios
  1. Anónimo
    Usuario no registrado
    26 Sep, 14 12:44 pm

    Vale! Estoy limpioooo! xD

  2. Anónimo
    Usuario no registrado
    26 Sep, 14 1:09 pm

    Ubuntu actualizado, no funciona el bug.

    1. Anónimo
      Usuario no registrado
      26 Sep, 14 1:16 pm

      ahora dentro de 25 años ya llevaras mas tiempo sin ese bug que el tiempo que llevaste con él, rapidez ante todo!

      1. Anónimo
        Usuario no registrado
        26 Sep, 14 1:57 pm

        Mira, esa es la práctica habitual de Microsoft

      2. Anónimo
        Usuario no registrado
        26 Sep, 14 2:50 pm

        Al menos no reaparecerá en sucesivas versiones de Bash a diferencia de lo que ocurre con sucesivas versiones de Windows, como problemas con el ping de la muerte.
        Y qué gloriosos recuerdos los de los BSOD de Windows Vista (cuyo núcleo se usa en 7, 8 y 9) por el puntero del ratón pasando sobre accesos directos… ¡viva la interfaz gráfica empotrada en el núcleo!

        Las estadísticas muestran que el código libre es de mejor calidad que el código cerrado. El software libre tiene menos bugs por línea que el código privativo.

        1. Anónimo
          Usuario no registrado
          26 Sep, 14 2:54 pm

          Ya…por eso ahora tienen que sacar un fix para el fix de bash porque no lo han corregido…

          El código libre, al igual que el privado, adolece del mismo problema, está hecho por personas, y por tanto, se equivocan; Apple usa código privado, MS también, y tienen fallos de seguridad gordos; sistemas open source, resulta que adolecen de lo mismo (herthbleed y éste es de lo peor que ha habido), así que los dogmatismos o asunciones como las que comentas, denotan ya falta de conocimiento práctico y real…

          El nuevo fix a tratar de bash (no el primero)
          http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

          1. Anónimo
            Usuario no registrado
            26 Sep, 14 3:06 pm

            Están hechos por personas pero su metodología de desarrollo es totalmente diferente.

            Supongo que todos los puentes son iguales, ¿verdad?, porque están basados en los mismos principios de la física.

            Y bueno, te lo vuelvo a repetir: las estadísticas muestran que el código libre es de mejor calidad que el código cerrado. El software libre tiene menos bugs por línea que el código privativo. Déjate de falacias anda.

            Por otra parte el bug requiere de un programa ejecutándose como root para ser peligroso.

            1. Anónimo
              Usuario no registrado
              26 Sep, 14 3:13 pm

              ¿Las estadísticas de dónde? Que eres fan del open source, perfecto; para mí el open source me parece genial para la gente que sabe realmente programar, porque puede hacer lo que le de la gana a su gusto, pero de ahí, a que luego sea más seguro hay un trecho -trabajo en seguridad, nadie que no sepa un poco puede decir lo contrario sorry-. A parte; no puedes auditar código privado, por lo que es imposible compararlo y hacer una estadística, que quede claro.
              Y claro que necesitas privilegios de root, el problema está en que consigues ejecutar código a través de servicios que van a estar ejecutándose como tal. Igual de claro que mucha gente en Linux, aunque parezca mentira, trabaja en modo root…un fiasco.
              Y lo dicho, que últimamente los problemas de seguridad son gordos, y nos afectan al final a todos, a mí me da lo mismo que uno quiera usar una cosa u otra, me preocupa que se sepa usar, y que efectivamente se corrijan los problemas lo antes posible -cosa que el mundo open source desde luego se hace mejor y más rápido que con otro software privado-.

              1. Anónimo
                Usuario no registrado
                26 Sep, 14 7:09 pm

                Pues siento decirte que también he trabajado en seguridad y el software libre es más seguro, eso del open source no sé que es pero me suena a FUD de Microsoft.
                Cualquiera puede atestiguar que el software libre es más seguro. El software privativo es el primero en caer en toda conferencia de seguridad.

                En cuanto al bug, pues obviamente si el servicio al que mandas la petición la parsea con bash y establece variables de entorno en la misma instancia, pues supondrá un problema si es root, que no tiene porqué ser así. Ese tipo de fallos los hay en gran cantidad de programas.

                1. Anónimo
                  Usuario no registrado
                  29 Sep, 14 1:36 pm

                  No sé, basta con mirar las slides de toda conferencia de seguridad y en todas hay de todo, MS y no MS…y desde luego, en las pocas que he estado (nacionales, y por falta de presupuesto/tiempo internacionales), y pudiendo hablar con gente del gremio, todos acabamos llegando a la misma conclusión ya, da igual que sea privado, libre, o como lo quieras llamar; todos caen, y con lo que estamos viendo este último año, el que peor lo lleva es el libre (que no sólo es *nix, si no programas que la gente usa y pone a disposición del resto con fallos enormes de seguridad)

              1. Anónimo
                Usuario no registrado
                26 Sep, 14 7:12 pm

                Comenzando por el hecho de que las conclusiones que saca ese estudio no dicen lo que tu mensaje indica, podemos terminar por decir que el software privativo de unos años hacia acá ha mejorado pero el software libre sigue siendo superior con una menor densidad de fallos, así lo indica también el informe del 2013: http://softwareintegrity.coverity.com/rs/coverity/images/2013-Coverity-Scan-Report.pdf

                1. Anónimo
                  Usuario no registrado
                  26 Sep, 14 9:42 pm

                  Si te fijas, el estudio que muestras de 2013 es sensiblemente más incompleto que el estudio de 2012. No en vano uno tiene 25 y el otro 61 páginas.

                  De mi enlace:

                  Página 9: Defect Density of Open Source vs. Proprietary Code:
                  In 2011, we looked at a sample of analysis of more than 300 million lines of code from 41 proprietary codebases and measured a defect density of .64, which was on par with the average defect density of open source codebases of a comparable size.

                  Página 10: TABLE 4: 2012 COMPARISON OF OPEN SOURCE AND PROPRIETARY CODE:

                  Defect Density: Open Source: 0.69 – Propietario: 0.68 (menos es mejor)

                  Similar to the 2011 report findings, in 2012 we found the defect density of open source software to be on par with proprietary software.

                  Dicen “a la par” pero en realidad el software libre es ligeramente peor.

                  Página 17: Densidad de defectos del kernel de linux en 2012: 0.76, peor que la media.

                  A ver qué conclusiones extraes tú.

  3. MALVOSX 26 Sep, 14 2:38 pm

    Fedora parcheado hace tiempo, no hay bug, toy tranquilo

    1. Anónimo
      Usuario no registrado
      26 Sep, 14 2:44 pm

      Míralo bien (como mucho habrás parcheado antes de ayer), más que nada porque Fedora está pendiente, como el resto de sistemas Linux ahora, de un fix mejor por deficiencias en el actual para *nix.
      Lo nuevo descubierto:
      http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

      http://fedoramagazine.org/the-previous-fix-for-shellshock-bash-vulnerability-incomplete-updated-fedora-packages-soon/

      http://fedoramagazine.org/shellshock-update-bash-packages-that-resolve-cve-2014-6271-and-cve-2014-7169-available/

    2. Anónimo
      Usuario no registrado
      26 Sep, 14 2:57 pm

      Por si acaso; Fedora es igual de vulnerable que cualquier otro sistema; si has parcheado hace 2 días, genial; si no, es vulnerable, y aún así, ahora mismo, sigue siéndolo hasta que se corrija con este otro:
      http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

  4. moonlight26 26 Sep, 14 3:09 pm

    El script de comprobación no va bien. El correcto es éste:
    env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’
    Parece lo mismo, pero no lo es (p.ej., el carácter de
    apóstrofe no es el que toca.

    1. Anónimo
      Usuario no registrado
      26 Sep, 14 7:18 pm

      He cambiado el apóstrofe
      env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’
      y me contesta simplemente:
      hello

      1. Anónimo
        Usuario no registrado
        26 Sep, 14 7:20 pm

        El apóstrofe parece el de los acentos pero he puesto el que está debajo del signo “?”
        También me sale hello si uso comillas “.

  5. Anónimo
    Usuario no registrado
    26 Sep, 14 4:16 pm

    syntax error near unexpected token `(‘

  6. Anónimo
    Usuario no registrado
    26 Sep, 14 4:32 pm

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

  7. Anónimo
    Usuario no registrado
    26 Sep, 14 5:19 pm

    () { :;}; Todos a bordar 😛

  8. Anónimo
    Usuario no registrado
    29 Sep, 14 10:26 am

    error sintáctico cerca del elemento inesperado `(‘
    esto es lo que me pone.

  9. bpmircea 29 Sep, 14 10:47 am

    para los que le da error:

    env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’

    1. Anónimo
      Usuario no registrado
      30 Sep, 14 3:42 pm

      El comando para ver la versión de bash también ha salido mal. Delante de “version” hay dos guiones. A ver si así sale bien:

      bash --version

      1. Anónimo
        Usuario no registrado
        30 Sep, 14 3:45 pm

        Correcto. Basta con poner “code” (sin las comillas) entre signos de menor que y mayor que antes del código y “/code” (sin las comillas) entre dichos signos después del código. Entonces, el comando correcto que muestra si nuestro sistema es vulnerable es:

        env x='() { :;}; echo vulnerable' bash -c 'echo hello'