Si eres usuario de memcached y tienes desplegadas instancias en Amazon EC2, puede que hayas recibido un mensaje de Amazon durante el fin de semana (nosotros recibimos uno el 8/7/2010) indicando que puedes tener una "Posible configuración insegura de Memcached." Este es el cuerpo del mensaje que recibimos:
Te hemos enviado este correo para informarte de que hemos observado que puedes estar ejecutando memcached con una configuración insegura. En concreto, hemos observado que tienes al menos un grupo de seguridad que permite que todo internet tenga acceso al puerto más utilizado por memcached (11211).
Ha habido mucha atención reciente por parte de la comunidad de seguridad sobre la falta de controles de acceso en memcached y recientemente se han publicado algunos exploits. Esto ha puesto de relieve la importancia de ejecutar con estrictos controles de acceso. Aunque no tenemos conocimiento de ningún acceso no autorizado a sus instancias de Amazon EC2, creemos que debería hacer que su equipo técnico revise esto inmediatamente.
Le sugerimos que audite la configuración de su grupo de seguridad y restrinja el acceso únicamente a las instancias y direcciones IP que necesiten acceso. La mayoría de los usuarios solo autorizan a otras instancias de Amazon EC2 a acceder a su servidor memcached. Si necesita acceder a su servidor memcached desde fuera de Amazon EC2, también puede autorizar únicamente a las direcciones de confianza para que accedan a su grupo de seguridad.
Si necesita más ayuda, puede ponerse en contacto con nuestro equipo de Asistencia Premium enviando un correo electrónico a aws-security-support@amazon.com.
Saludos,
El equipo de Amazon Web Services
El correo electrónico y el servicio del equipo de AWS son excelentes, y la solución sugerida es perfecta.
Esta publicación pretende proporcionar algunos antecedentes sobre el problema y la aludida "atención reciente" que ha recibido el problema. El problema es relevante para todos los usuarios de memcached, no sólo los que despliegan en Amazon EC2.
La vulnerabilidad
La génesis de este boletín fue casi con toda seguridad el resultado del desarrollo de go-derper por el equipo de sensepost, destacado en el blackhat USA 2010 el 30 de julio de 2010.
La vulnerabilidad destacada puede resumirse así: si despliegas memcached en un servidor, dejas el puerto TCP en el que memcached está configurado para escuchar (11211, por defecto) expuesto a Internet, dejas habilitado el protocolo ASCII de memcached, Y no estás usando autenticación SASL con el protocolo binario de memcached, entonces hay una forma trivial de que los Malos recuperen y reemplacen la mayor parte de los contenidos de tu caché. go-derper.rb es una sencilla aplicación Ruby, creada por sensepost, que puede utilizarse para explotar la vulnerabilidad.
Eliminar la vulnerabilidad
Examinemos la vulnerabilidad, cláusula por cláusula, y destaquemos lo que puede hacerse para eliminarla, empezando por arriba:
"Si despliegas memcached en un servidor,"
Esto puede parecer una tontería, pero en realidad hay opciones. No todo el mundo necesita desplegar y configurar memcached en un servidor para utilizar la tecnología. Si estás desplegando memcached en una plataforma en la nube, por ejemplo, puedes simplemente aprovechar una imagen pre-construida o incluso un servicio adicional.
Gestionamos el complemento memcached para Heroku (que a su vez se ejecuta en la infraestructura de Amazon), el proveedor líder de plataformas como servicio en la nube para aplicaciones Ruby. Dado que gestionamos el complemento memcached, nuestra profunda experiencia con memcached se pone implícitamente al servicio de las miles de aplicaciones desplegadas en Heroku que aprovechan nuestro complemento memcached.
Además, estamos trabajando estrechamente con nuestros amigos de RightScale para poner a disposición imágenes memcached preconfiguradas para aquellos que deseen desplegar memcached y membrana en Amazon AWS.
Si utiliza una de estas opciones de despliegue, nos hemos asegurado de que la configuración sea segura.
"[si] dejas el puerto TCP en el que memcached está configurado para escuchar (11211, por defecto) expuesto a Internet".
Si has desplegado tu propia instancia de memcached, ya sea en tu propio equipo o en un entorno de computación en la nube, debes asegurarte de que un cortafuegos protege el sistema.
Amazon proporciona un amplio conjunto de capacidades para expresar y aplicar el control de acceso a las instancias que se ejecutan en EC2.
El cofundador de NorthScale, Dustin Sallings, también intervino durante el fin de semana. blog ofrece muchos más detalles, sobre todo en relación con los cortafuegos.
"[si] dejas activado el protocolo ASCII de memcached,"
Tal y como está construido, el exploit go-derper depende del uso del protocolo ASCII.
Memcached ofrece tanto un protocolo ASCII como un protocolo binario. El protocolo binario fue desarrollado por Trond Norbye, de NorthScale, cuando trabajaba para SUN Microsystems.
El hecho de esta vulnerabilidad es que también existe en el protocolo binario, pero el protocolo binario soporta autenticación y control de acceso, proporcionando un mecanismo para asegurar los datos.
El protocolo ASCII, el protocolo original desarrollado para memcached, no tiene ninguna facilidad para la autenticación o el control de acceso, y por lo tanto no es adecuado para colgar en la Internet pública. Este protocolo se desarrolló explícitamente para su uso detrás de un cortafuegos, como un sistema "back-end", protegido.
En el improbable caso de que tengas alguna buena razón para hacer que el puerto de memcached esté disponible para cualquier host en la Internet pública, pero quieras controlar el acceso a los datos, entonces deberías deshabilitar el soporte del protocolo ASCII (y habilitar la autenticación SASL en el protocolo binario, como se describe a continuación). La distribución NorthScale de memcached facilita la configuración de memcached para NO enlazar el oyente del protocolo ASCII al puerto de memcached.
"Y [si] no está utilizando la autenticación SASL con el protocolo binario memcached,"
Como se mencionó anteriormente, el protocolo binario memcached en versiones recientes de memcached soporta autenticación y autorización de acceso a través del protocolo SASL.
La distribución NorthScale de memcached hace que sea muy fácil aprovechar esta capacidad. La creación de un nuevo "bucket" en nuestra distribución de memcached proporciona capacidad multi-tenancy (permitiendo que múltiples aplicaciones se vinculen de forma segura a un único clúster memcached) y sirve como vehículo para la vinculación de credenciales SASL. Es esta capacidad la que nos permite soportar de forma segura miles de usuarios de memcached en Heroku sin tener que ejecutar miles de servidores individuales.
Si estás usando una versión antigua de memcached (la mayoría de las distribuciones linux vienen con versiones anticuadas del software), y necesitas soporte de acceso autenticado, deberías buscar una versión más reciente del software. Sin duda recomiendo nuestra distribución.
El contexto histórico de memcached
La vulnerabilidad no es sorprendente. Memcached fue construido inicialmente por Brad Fitzpatrick para su uso en LiveJournal, en un entorno en el que el control sobre los servidores y la seguridad de la red estaba gestionado por un experto equipo de administradores de sistemas. Con muchas líneas de defensa frente a memcached, no había necesidad de construir otra capa de seguridad en el propio memcached, donde el precio inevitable sería el esfuerzo de desarrollo (esfuerzo mejor invertido en la construcción de características de blogging) y el rendimiento (en un entorno donde muchos millones de transacciones memcached se procesan por día, y cada microsegundo cuenta).
En un mundo perfecto, toda persona que desarrolle e implante software debería conocer a fondo las características de todos los componentes de la infraestructura de software subyacente de la que depende su software; tener un firme conocimiento de la seguridad de la red, la formulación de políticas y su aplicación; y auditar periódicamente su entorno operativo al tiempo que rastrea las amenazas emergentes. Pocos sistemas se desplegarían. De hecho, creo que es justo decir que algunas de las aplicaciones web más populares en Internet hoy en día nunca habrían visto la luz del día bajo esas restricciones.
En el mundo real, hay mucho software interesante que está siendo desarrollado y desplegado por personas que no son ellas mismas, y que a menudo no tienen los recursos para emplear, administradores de sistemas experimentados y especialistas en seguridad de redes. Lo único que quieren es poner su software o servicio en manos del mayor número posible de usuarios, lo antes posible. Cuando se materialicen los miles de millones de operaciones por segundo, se podrán extraer los microsegundos, con suerte gracias a un equipo competente de administradores de sistemas que la organización pueda atraer y permitirse.
Un inciso sobre la computación en nube
En última instancia, ésta es una de las promesas de la computación en nube, como se señala en uno de nuestros libros blancos. La computación en nube no consiste sólo en transformar el capital en gastos operativos, o en aprovechar las economías de escala de los proveedores de servicios. Los proveedores de alojamiento gestionado llevan más de una década haciéndolo. En última instancia, la computación en nube permite a los desarrolladores de software desarrollar e implantar programas sin tener que adquirir conocimientos sobre administración de sistemas y seguridad de redes. En última instancia, el mundo es un lugar mejor gracias a ello. Hay más desarrolladores capacitados para crear y ofrecer soluciones de software.
Amazon ha demostrado parte del valor que proporcionan a su base de clientes: han rastreado una vulnerabilidad recientemente destacada que es ampliamente relevante (dado el amplio despliegue de memcached) para sus usuarios, han identificado a usuarios específicos en riesgo (posible dados los metadatos utilizados para configurar las instancias de máquinas virtuales que en última instancia subyacen a los sistemas en ejecución en EC2) y les han notificado de manera oportuna con precisión cómo abordar el problema. Un gran valor añadido.
¿De dónde sacas tu memcached?
El equipo de NorthScale aporta la mayor parte del código fuente a los proyectos de código abierto memcached y membase. Respetamos el deseo claramente expresado por la gran comunidad de desarrollo de memcached de que el núcleo de memcached siga siendo puro, rápido y más adecuado para aquellos que saben lo que están haciendo.
También ponemos a disposición de las organizaciones versiones comerciales certificadas y menos "crudas" de esos sistemas, facilitando su despliegue, configuración, seguridad y gestión. Mientras que la comunidad de desarrollo de memcached no quiere que el código base se contamine con características de "facilidad de uso", hay una comunidad potencial mucho mayor de usuarios del software que estarán mejor con esas características presentes. Lo mismo ocurre con cosas como la replicación y la reconfiguración en vivo del clúster. Muchos usuarios quieren estas capacidades, pero el núcleo de la comunidad preferiría mantenerlas fuera de memcached propiamente dicho. Las ponemos a libre disposición en nuestra distribución y hacemos que el código fuente esté disponible en proyectos relacionados (por ejemplo, http://github.com/northscale/bucket_engine).
