A08:2021 – Fallos de Integridad de Software y Datos

Integridad de software y datos

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