A08: Fallas de integridad de datos y software (by OWASP) | Libros Tecnológicos

Visión general

Una nueva categoría para 2021 se enfoca en hacer suposiciones relacionadas con actualizaciones de software, datos críticos y canalizaciones de CI/CD sin verificar la integridad. Uno de los impactos ponderados más altos de los datos de Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS). Las enumeraciones de debilidades comunes (CWE) notables incluyen CWE-829: inclusión de funcionalidad de 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 en la integridad del software y los datos se relacionan con el código y la infraestructura que no protegen contra las violaciones de la integridad. Un ejemplo de esto es cuando una aplicación se basa en complementos, bibliotecas o módulos de fuentes, repositorios y redes de entrega de contenido (CDN) que no son de confianza. Una canalización de CI/CD insegura puede presentar el potencial de acceso no autorizado, código malicioso o compromiso del sistema. Por último, muchas aplicaciones ahora incluyen la función de actualización automática, donde las actualizaciones se descargan sin una verificación de integridad suficiente y se aplican a la aplicación de confianza anterior. Los atacantes podrían cargar sus propias actualizaciones para distribuirlas y ejecutarlas en todas las instalaciones. Otro ejemplo es cuando los objetos o datos se codifican o serializan en una estructura que un atacante puede ver y modificar y es vulnerable a una deserialización insegura.

Como prevenir

Utilice firmas digitales o mecanismos similares para verificar que el software o los datos provengan de la fuente esperada y no hayan sido alterados.
Asegúrese de que las bibliotecas y las dependencias, como npm o Maven, consuman repositorios de confianza. Si tiene un perfil de mayor riesgo, considere alojar un repositorio interno conocido que esté examinado.
Asegúrese de que se utilice una herramienta de seguridad de la cadena de suministro de software, como OWASP Dependency Check u OWASP CycloneDX, para verificar que los componentes no contengan vulnerabilidades conocidas.
Asegúrese de que haya un proceso de revisión de los cambios de código y configuración para minimizar la posibilidad de que se introduzcan códigos o configuraciones maliciosos en su proceso de software.
Asegúrese de que su canalización de CI/CD tenga la segregación, la configuración y el control de acceso adecuados para garantizar la integridad del código que fluye a través de los procesos de compilación e implementación.
Asegúrese de que los datos serializados sin firmar o sin cifrar no se envíen a clientes que no sean de confianza sin algún tipo de verificación de integridad o firma digital para detectar la manipulación o la reproducción de los datos serializados.

Ejemplos de escenarios de ataque

Escenario #1 Actualizar sin firmar: muchos enrutadores domésticos, decodificadores, firmware de dispositivos y otros no verifican las actualizaciones a través del firmware firmado. El firmware sin firmar es un objetivo cada vez mayor para los atacantes y se espera que empeore. Esta es una preocupación importante ya que muchas veces no existe un mecanismo para remediar más que corregir en una versión futura y esperar a que las versiones anteriores caduquen.

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 que es el ataque SolarWinds Orion. La empresa que desarrolla el software tenía procesos seguros de compilación y actualización de integridad. Aún así, estos pudieron subvertirse y, durante varios meses, la empresa distribuyó una actualización maliciosa altamente dirigida a más de 18,000 organizaciones, de las cuales alrededor de 100 se vieron afectadas. Esta es una de las infracciones de esta naturaleza más trascendentales y significativas de la historia.

Escenario #3 Deserialización insegura: una aplicación React llama a un conjunto de microservicios Spring Boot. Al ser programadores funcionales, intentaron asegurarse de que su código sea inmutable. La solución que se les ocurrió es 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 la ejecución remota de código en el servidor de aplicaciones.