Fallos de Integridad de Software y Datos es una nueva categoría para 2021, centrada en hacer suposiciones relacionadas con actualizaciones de software, datos críticos y pipelines de CI/CD sin verificar la integridad.
¿Qué implica?
El código y la infraestructura que no protegen contra violaciones de integridad pueden llevar a que una aplicación entregue software malicioso o modificado sin detección.
Riesgos principales
- Dependencias de fuentes no confiables
- Pipelines CI/CD inseguros que permiten acceso no autorizado
- Actualizaciones de software sin firma digital
- Deserialización insegura de datos
- Datos serializados sin verificación de integridad
- Ausencia de verificación de checksums/firmas
¿Cómo prevenir?
- Usar firmas digitales para verificar el software y los datos
- Asegurar que las bibliotecas y dependencias provengan de repositorios confiables
- Implementar revisión de código y controles en CI/CD
- No enviar datos no confiables a deserializadores sin validación
- Verificar checksums de los artefactos de software
Archivo de la web anterior
Contenido original publicado
Resumen
Una nueva categoría para 2021 se enfoca en hacer suposiciones relacionadas con actualizaciones de software, datos críticos y pipelines de CI/CD sin verificar la integridad. Esta categoría incluye uno de los impactos más ponderados según los datos del Sistema de Puntuación de Vulnerabilidades Comunes/Exposiciones Comunes (CVE/CVSS). Algunas Enumeraciones de Debilidades Comunes (CWE) notables son CWE-829: Inclusión de Funcionalidad desde una Esfera de Control No Confiable, CWE-494: Descarga de Código sin Verificación de Integridad, y CWE-502: Deserialización de Datos No Confiables.
Descripción
Las fallas de integridad del software y los datos están relacionadas con el código y la infraestructura que no protegen contra violaciones de integridad. Un ejemplo de esto es cuando una aplicación depende de plugins, bibliotecas o módulos provenientes de fuentes no confiables, repositorios y redes de entrega de contenido (CDNs). Una pipeline de CI/CD insegura puede introducir el potencial de acceso no autorizado, código malicioso o compromisos del sistema. Por último, muchas aplicaciones ahora incluyen funcionalidad de actualización automática, donde las actualizaciones se descargan sin una verificación de integridad suficiente y se aplican a la aplicación previamente confiable. Los atacantes podrían potencialmente subir sus propias actualizaciones para ser distribuidas y ejecutadas en todas las instalaciones. Otro ejemplo es cuando los objetos o datos son codificados o serializados en una estructura que un atacante puede ver y modificar, lo que los hace vulnerables a una deserialización insegura.
Cómo prevenir
- Utiliza firmas digitales u otros mecanismos similares para verificar que el software o los datos provienen de la fuente esperada y no han sido alterados.
- Asegúrate de que las bibliotecas y dependencias, como npm o Maven, consuman repositorios confiables. Si tienes un perfil de riesgo más alto, considera alojar un repositorio interno de confianza que haya sido verificado.
- Asegúrate de utilizar una herramienta de seguridad de la cadena de suministro de software, como OWASP Dependency Check o OWASP CycloneDX, para verificar que los componentes no contengan vulnerabilidades conocidas.
- Asegúrate de que exista un proceso de revisión para los cambios de código y configuración para minimizar la posibilidad de que se introduzca código malicioso o configuraciones no deseadas en tu pipeline de software.
- Asegúrate de que tu pipeline de CI/CD tenga la segregación, configuración y control de acceso adecuados para garantizar la integridad del código que fluye a través de los procesos de construcción y despliegue.
- Asegúrate de que los datos serializados que no están firmados o encriptados no se envíen a clientes no confiables sin algún tipo de verificación de integridad o firma digital para detectar alteraciones o reproducciones de los datos serializados.
ejemplos de escenarios de ataque
Escenario #1 Actualización sin firma: Muchos routers domésticos, decodificadores, firmware de dispositivos y otros no verifican las actualizaciones mediante firmware firmado. El firmware no firmado es un objetivo creciente para los atacantes y se espera que empeore. Esto es una gran preocupación, ya que muchas veces no hay un mecanismo para remediar la situación, aparte de corregirlo en una versión futura y esperar a que las versiones anteriores queden obsoletas.
Escenario #2 Actualización maliciosa de SolarWinds: Se sabe que los estados-nación atacan los mecanismos de actualización, con un ataque notable reciente siendo el ataque a SolarWinds Orion. La empresa que desarrolla el software tenía procesos seguros de construcción y de integridad de actualizaciones. Aun así, estos fueron subvertidos, y durante varios meses, la empresa distribuyó una actualización maliciosa altamente dirigida a más de 18,000 organizaciones, de las cuales aproximadamente 100 fueron afectadas. Este es uno de los incumplimientos más importantes y de mayor alcance de esta naturaleza en la historia.
Escenario #3 Deserialización Insegura: Una aplicación React llama a un conjunto de microservicios de Spring Boot. Siendo programadores funcionales, intentaron asegurarse de que su código fuera inmutable. La solución que idearon fue serializar el estado del usuario y pasarlo de un lado a otro con cada solicitud. Un atacante nota la firma del objeto Java “rO0” (en base64) y utiliza la herramienta Java Serial Killer para obtener ejecución remota de código en el servidor de la aplicación.
Referencias
- Hoja de Trucos de OWASP: Seguridad en la Cadena de Suministro de Software (pronto)
- Hoja de Trucos de OWASP: Construcción y Despliegue Seguro (pronto)
- Hoja de Trucos de OWASP: Infraestructura como Código
- Hoja de Trucos de OWASP: Deserialización
- Controles de Integridad de Software de SAFECode
- Un ‘Peor Pesadilla’ Ciberataque: La Historia No Contada del Hackeo de SolarWinds
- Compromiso del Cargador Bash de CodeCov
- Asegurando DevOps por Julien Vehent