Header Ads Widget

Ticker

6/recent/ticker-posts

Exploits de Flash de día cero, control de versiones y espacio de API

  

exploits-flash-día-cero-01

Este mes, se reveló un exploit de Flash de día cero , exponiendo potencialmente millones de datos de usuarios. Después de que se lanzó un parche de emergencia, se descubrieron rápidamente dos exploits más , lo que llevó a una demanda vocal de una fecha de finalización de la vida útil de Flash .

Icono de Adobe Flash Player v10

Este no es solo un problema que afecta a los medios de comunicación y los sitios de entretenimiento: las vulnerabilidades de servicios como Flash y otras dependencias comúnmente utilizadas en la producción, el uso y la implementación de las API a menudo están sujetas a las mismas vulnerabilidades y divulgaciones de día cero que el asediada plataforma Adobe Flash. Hoy, vamos a discutir la naturaleza de la seguridad en la metodología moderna de diseño centrada en la dependencia, la importancia del control de versiones y algunos pasos básicos que los desarrolladores pueden tomar para asegurar su producto durante todo el ciclo de vida de la API .

Breve historia de la arquitectura de diseño centrada en la dependencia

El acceso no autorizado a los recursos de una red es tan antiguo como la propia red: en 1976 y 1978, por ejemplo, John Draper (también conocido como Capitán Crunch) fue acusado de utilizar un silbato de juguete con forma de caja de cereales para generar tonos para llamadas gratuitas en todo el mundo. Las vulnerabilidades en los sistemas telefónicos, los sistemas de televisión por cable y los primeros sistemas de suscripción basados ​​en Internet han sido durante mucho tiempo el foco de los piratas informáticos hábiles, inteligentes y persistentes.

En los viejos tiempos, piratear sistemas era una perspectiva difícil: una vez que los sistemas comenzaron a alejarse de la generación de tonos (como en el sistema telefónico) y las contraseñas y nombres de usuario básicos sin cifrar, obtener acceso a estos sistemas se volvió más difícil. Los sistemas conectados más grandes pronto comenzaron a implementar soluciones de seguridad patentadas, administrando la autenticación y la autorización utilizando servicios internos detrás de una conexión segura con el mundo exterior.

Sin embargo, a medida que el concepto de servicios orientados al usuario, como el procesamiento de pagos, las compras en línea y los proveedores de medios de Internet, comenzó a afianzarse, se requirió cierta estandarización. Con la floreciente World Wide Web tomando al mundo por asalto en la pila de protocolos TCP / IP estandarizados , los desarrolladores pronto comenzaron a crear sistemas que podían vincular a su propio código para una mayor funcionalidad.

El código creado con estos programas dependía de los programas estandarizados para funcionar, de ahí el término dependencias . Shockwave, Flash y otros sistemas similares permitieron a los desarrolladores dejar de "reinventar la rueda" cada vez que creaban un nuevo producto, y aseguraban la compatibilidad entre sistemas dispares.

Este cambio en el diseño de la arquitectura ha creado muchos de los problemas que enfrentan los desarrolladores de API en la actualidad: el cambio del diseño interno al diseño centrado en la dependencia ha creado una situación en la que las vulnerabilidades de dependencia están causando mayores preocupaciones de seguridad.

Leer más: Equilibrar la complejidad y la simplicidad en el diseño de API

La revisión: control de versiones

Al ver el problema con las dependencias y la necesidad constante de actualizar y revisar, los desarrolladores pronto implementaron una solución conocida como control de versiones . Con el control de versiones, un desarrollador de API o de servicios puede optar por utilizar la versión más actualizada, las versiones beta e incluso las versiones antiguas de una dependencia para su código.

Si bien esto fue en gran parte destinado a la compatibilidad, permitiendo que los servicios utilicen dependencias más antiguas en máquinas sin acceso o permisos para utilizar dependencias más nuevas, esto también creó una situación de seguridad en la que los desarrolladores de las dependencias podrían garantizar la seguridad mediante la implementación de parches para corregir las vulnerabilidades identificadas a través de pruebas y casos de uso del mundo real. Si bien esto simplificó el desarrollo para los desarrolladores , vino con su propio conjunto de advertencias.

Dentro del contexto del desarrollo de API moderno, el control de versiones tiene dos enfoques básicos, cada uno con sus fortalezas y debilidades.

El primer enfoque: actualizar y luego revisar

El primer enfoque y el más común es actualizar y revisar a medida que se lanzan las versiones de dependencia. Al adoptar este enfoque, un desarrollador de API instalará inmediatamente las dependencias o los sistemas actualizados y luego revisará la actualización a través de registros de cambios y uso en la vida real. Este tipo de control de versiones a menudo ignora las versiones beta o de prueba y se centra en las versiones estables.

Si bien esto parece un buen enfoque, existen algunas debilidades enormes. Al no mirar primero el código del parche más reciente para la dependencia, un desarrollador de API está confiando ciegamente en el desarrollador de la dependencia. Esto cambia la responsabilidad de lo personal a lo externo, creando una situación en la que la seguridad de su ecosistema recae directamente sobre los hombros de alguien sin un interés personal en mantener su sistema seguro.

Además, este enfoque podría tener un impacto inverso : al instalar una versión no probada o revisada, un desarrollador de API podría potencialmente abrirse a más exploits que la dependencia anterior sin parchear. Para muchos, esto es simplemente una advertencia demasiado grande para ignorarla: es más fácil librar una batalla con un enemigo que conoces que librar una guerra con enemigos incontables que no conoces.

El segundo enfoque: revisar y luego actualizar

El segundo enfoque, y menos común, es revisar y actualizar. A diferencia del primer enfoque, esto requiere que el desarrollador primero revise el código de la actualización de dependencia, comparándolo con el código conocido anteriormente. El desarrollador instala solo cuando está completamente convencido de la veracidad e integridad de la actualización.

Esto puede parecer contrario a la intuición: "aumente su seguridad al no instalar nuevas actualizaciones". La verdad es que aumenta drásticamente su seguridad al utilizar este enfoque simplemente porque sabrá contra qué está luchando.

Supongamos que usa una dependencia como Flash para el portal web de su API. Sabe que existe un conjunto de exploits que pueden forzar un desbordamiento del búfer. Sabiendo esto, ¿cuál es la mejor solución? Actualice esta dependencia a una nueva versión con código no probado y no revisado, o maneje el desbordamiento del búfer con un sistema de prevención y un parche automático mientras revisa la nueva actualización.

En pocas palabras, un desarrollador de API debe revisar todos y cada uno de los fragmentos del código antes de la implementación , o al menos, compararlo con el código ya existente para garantizar la compatibilidad, la seguridad y la protección entre una amplia variedad de casos de uso .

Leer más: Escribir microservicios en Go Parte II: cuándo no usar Go

Pasos de implementación de la dependencia: EIT

Entonces, ¿cuál es el proceso adecuado que debe seguir un desarrollador de API para asegurarse de que no se produzca algo como los exploits recientes de Flash de día cero? Este proceso se puede resumir en tres letras simples: EIT .

  • E - Examinar. Examine el código del parche de dependencia que pretende instalar. Compruébelo con parches anteriores: ¿ha cambiado drásticamente el código? Si es así, ¿comprende cómo ha cambiado? Utilice registros de cambios y rastreadores de errores para examinar los problemas con los nuevos parches. Utilice estos recursos para profundizar en cómo funciona la dependencia y por qué se tuvo que crear el parche.
  • Yo - Implementar. Una vez que haya examinado a fondo el código de la actualización de la dependencia, la dependencia debe implementarse. Asegúrese de que se mantenga la compatibilidad entre los sistemas de seguridad y la dependencia actualizada.
  • T - Prueba. Prueba tu API. Utilice herramientas de prueba de penetración, intente desencadenar desbordamientos de búfer y envíe llamadas y solicitudes no validadas para ver cómo responde su API. Si desencadena alguna falla en el nuevo parche, agregue su resultado y métodos para duplicar al rastreador de errores para su dependencia después de reparar su ecosistema para asegurarse de que no continúe siendo un problema.

Al seguir este conjunto de pautas, un desarrollador de API puede asegurarse de que sus dependencias de API y el ecosistema completo funcionen según lo previsto, lo que garantiza la seguridad y la funcionalidad a largo plazo a lo largo de la aplicación de parches.

Lecciones aprendidas

Las dependencias son algo maravilloso: para poder crear, implementar y parchear rápidamente, los desarrolladores de API deben usar una cierta cantidad de dependencias. Cuando estas dependencias inevitablemente quedan expuestas, surge rápidamente una tendencia a culpar al desarrollador de dependencias.

Esta es una respuesta deficiente; el hecho es que la vulnerabilidad en la API no es culpa del desarrollador de la dependencia, sino del desarrollador de la API que adoptó esa dependencia. La seguridad es del dominio exclusivo del desarrollador: transferir la responsabilidad al usuario oa otro desarrollador es simplemente una mala práctica y conducirá a un ecosistema menos seguro.

Conclusión

Aunque las vulnerabilidades recientes se centran en Flash, esto tampoco es un problema exclusivo de las plataformas: las vulnerabilidades en las metodologías y las soluciones alternativas en códigos como Scala, Go y otros lenguajes similares pueden provocar desbordamientos de búfer, fugas de memoria y un cifrado deficiente. . Los problemas dentro de la pila de computación en la nube pueden exponer enormes fallas de seguridad. Incluso la falta de un cifrado eficaz podría resultar en la exposición completa de los recursos de la red, lo que podría traicionar su ecosistema de seguridad.

¿La comida para llevar? Verifique sus dependencias y verifique su código; la seguridad de su API es responsabilidad exclusiva de usted.

Publicar un comentario

0 Comentarios