Por: Diego Osorio Reina*
El pasado miércoles se publicó el hallazgo de una vulnerabilidad en el componente de software Bash, herramienta histórica y propia de los sistemas operativos Unix, Linux y Mac OS X, que ya bautizaron Shellshock, Bashdoor o Bash bug. La vulnerabilidad es un error en el software que permite engañar a la línea de comandos para que ejecute una orden que no estaba concebida, como visualizar archivos confidenciales, espiar la actividad, realizar algún daño o apagar el sistema.
Aunque para alcanzar la línea de comandos y así Bash se requiere que la persona esté sentada frente al computador o que acceda remotamente con usuario y contraseña. Muchos componentes de software de Unix, Linux y Mac OS X que dan servicios masivos en internet como la publicación de páginas web, se comunican con Bash. De esta forma sale a la luz que a partir del miércoles, millones de páginas del planeta permiten ser engañadas para ejecutar comandos no autorizados dentro de los sistemas que las publican. El gran revuelo es ocasionado precisamente por esta situación, llegándose a estimar que los perjuicios pueden ser mucho más altos que el de la última vulnerabilidad famosa de hace unos meses atrás Heartbleed.
Haciendo una analogía, la vulnerabilidad es como si de un momento a otro descubrieran que el aluminio se derrite con una mezcla de sal y limón, teniendo en cuenta que un alto porcentaje de las ventanas en la construcción moderna de casas y apartamentos usan aluminio. ¿Qué ocurriría? Todos los delincuentes saldrían corriendo a derretir las ventanas para robar las casas y todos los propietarios y habitantes de las casas saldrían corriendo a cambiar las ventanas de aluminio. Esto último es lo que está ocurriendo: todos los propietarios y responsables de Unix, Linux y Mac estamos corriendo a remendar Bash con las actualizaciones que están liberando los fabricantes. (La de Mac OS X se puede descargar acá).
En el mundo de la seguridad de internet cuando ocurren este tipo de situaciones, cómo lo es descubrir un error de un programador que permite la ejecución arbitraria de comandos en millones de servidores de publicación web, los fabricantes de software corren a remendar el software por medio de parches y actualizaciones, y por su parte, los delincuentes informáticos corren a aprovecharse de la vulnerabilidad, creando virus y redes de computadores delincuentes en los ya comprometidos (botnets).
Bash es un software histórico y se estima que la vulnerabilidad llevaba 22 años existiendo sin ser descubierta, esto esta dando mucho que hablar y hay quienes afirman que esto es la prueba de que existe un Big Brother que espía todas las actividades de la sociedad. Si esto es cierto o no, no lo se, simplemente sé que les recomiendo a todos remendar a la mayor brevedad sus sistemas Linux, Unix y Mac OS X.
______
*Diego es CIO de LockNet, una empresa de seguridad informática en Bogotá, Colombia. Además es especialista en redes y consultor de seguridad informática.
(editado) así como lo describen me parece un poco exagerado. bash es un shell. un shell no es el núcleo del sistema operativo, sino lo que pone en contacto al usuario con el sistema operativo (lo que en dos era el command .com), es decir no el que hace las cosas sino el que interpreta la línea de comandos y de acuerdo con eso llama los servicios que ofrece el sistema, o en pocas palabras, ‘es’ la línea de comandos (el sistema de ventanas, como unity, también es un shell, pero en vez de texto se maneja con el mouse. no confundir con ‘the bash’ de ubuntu, que también es una ventana).
por un lado, así como en dos había forma de cambiar el shell y escoger otra cosa diferente a command .com (pero nadie lo hacía, ya que como para qué), pues si el problema es de bash, se puede escoger otro shell.
por otro lado, lo que dicen acá.. hay páginas que llaman comandos etc etc. hmm.. tal vez eso sea posible, pero si llega a suceder, al que hizo eso deberían despedirlo. eso se llama ‘inyecciones de código’, y equivale a decir que lo que escriba el usuario en un for,ato de una página, se ejecuta como un comando; por ejemplo, que en vez de ‘enter.co’ yo escribiera ‘enter.co?com=del*.*’ [aclaración, lo anterior no hace nada, pero lo pongo de ejemplo como si se pudiera hacer], o que en vez de nombre de usuario,c uandof uera a hacer el login, le pusiera algo como dir /root/. lo de inyecciones no es nuevo, se usa en bases de datos y como no es nuevo, para eso se revisa cuando se hace una página.. pero si eso llega apasar, es porque el que hizo la página así lo permite. y si se toman medidas de seguridad para bases de datos, pues nadie con dos dedos de frente va a conectar directamente la línea de comandos con lo que el usuario ponga en la página.. entonces el problema realmente no es ése, y dudo que en realidad, para fines prácticos, haya páginas que hagan eso (aunque es posible hacerlas, pero tendrían qué hacer eso a propósito).. y si se le suelta la línea de omandos al usuario.. pues el hecho de hacer cadenas raras sería el mínimo de los problemas
por otro lado, no es que los comandos se ejecuten desde la página, es que un usuario tenga acceso ala línea de comandos por otro lado (no a travñes de una página). normalmente los administradores de sitios web tienen eso en cuenta y cierran los accesos externos a la línea de comandos, pero es algo a tener en cuenta
Generalmente todos los publi-reportajes de lock net son asi, vagos, incompletos y con comparaciones nada comparables.
VooDooChicken gracias me ahorro un post.
(editado) así como lo describen me parece un poco exagerado. bash es un shell. un shell no es el núcleo del sistema operativo, sino lo que pone en contacto al usuario con el sistema operativo (lo que en dos era el command .com), es decir no el que hace las cosas sino el que interpreta la línea de comandos y de acuerdo con eso llama los servicios que ofrece el sistema, o en pocas palabras, ‘es’ la línea de comandos (el sistema de ventanas, como unity, también es un shell, pero en vez de texto se maneja con el mouse. no confundir con ‘the bash’ de ubuntu, que también es una ventana).
por un lado, así como en dos había forma de cambiar el shell y escoger otra cosa diferente a command .com (pero nadie lo hacía, ya que como para qué), pues si el problema es de bash, se puede escoger otro shell.
por otro lado, lo que dicen acá.. hay páginas que llaman comandos etc etc. hmm.. tal vez eso sea posible, pero si llega a suceder, al que hizo eso deberían despedirlo. eso se llama ‘inyecciones de código’, y equivale a decir que lo que escriba el usuario en un for,ato de una página, se ejecuta como un comando; por ejemplo, que en vez de ‘enter.co’ yo escribiera ‘enter.co?com=del*.*’ [aclaración, lo anterior no hace nada, pero lo pongo de ejemplo como si se pudiera hacer], o que en vez de nombre de usuario,c uandof uera a hacer el login, le pusiera algo como dir /root/. lo de inyecciones no es nuevo, se usa en bases de datos y como no es nuevo, para eso se revisa cuando se hace una página.. pero si eso llega apasar, es porque el que hizo la página así lo permite. y si se toman medidas de seguridad para bases de datos, pues nadie con dos dedos de frente va a conectar directamente la línea de comandos con lo que el usuario ponga en la página.. entonces el problema realmente no es ése, y dudo que en realidad, para fines prácticos, haya páginas que hagan eso (aunque es posible hacerlas, pero tendrían qué hacer eso a propósito).. y si se le suelta la línea de omandos al usuario.. pues el hecho de hacer cadenas raras sería el mínimo de los problemas
por otro lado, no es que los comandos se ejecuten desde la página, es que un usuario tenga acceso ala línea de comandos por otro lado (no a travñes de una página). normalmente los administradores de sitios web tienen eso en cuenta y cierran los accesos externos a la línea de comandos, pero es algo a tener en cuenta
editado 2: y no me parece comparable a lo de heartbleed. para esto, ud puede revisar su computador y mirar si sus páginas están bien hechas yq ué permisos le da a cada cosa, para el hertbleed ud no puede controlar si alguien lo chuza o no lo chuza durante el camino de los datos
Generalmente todos los publi-reportajes de lock net son asi, vagos, incompletos y con comparaciones nada comparables.
VooDooChicken gracias me ahorro un post.
… Hace ya unos días que en los repositorios está la actualización de Bash. Con tener el sistema al día es más que suficiente.
Cof Cof Cof
env x='() { :;}; echo Tener el sistema al dia no es suficiente’ bash -c «Los sistemas estaban al dia hace uno dias antes de bash bug»
ya existen 13 variantes conocidas del bug y 7 sin parche oficial.
… Hace ya unos días que en los repositorios está la actualización de Bash. Con tener el sistema al día es más que suficiente.
Cof Cof Cof
env x='() { :;}; echo Tener el sistema al dia no es suficiente’ bash -c «Los sistemas estaban al dia hace uno dias antes de bash bug»
ya existen 13 variantes conocidas del bug y 7 sin parche oficial.