5 dic 2020

"Uno de cada cinco errores se planta con fines maliciosos" [Github]

GitHub, la plataforma más grande del mundo para software de código abierto, descubrió que el 17% de todas las vulnerabilidades en el software se plantaron con fines maliciosos. GitHub informó que casi una quinta parte de todos los errores de software fueron colocados intencionalmente en el código por actores maliciosos en su informe Octoverse 2020.

Los fabricantes de software patentados a lo largo de los años han sido criticados regularmente por "seguridad a través de la oscuridad" o por no poner el código fuente a disposición de expertos ajenos a la empresa para su revisión.

El código abierto, por otro lado, se considera una forma de desarrollo más transparente porque, en teoría, puede ser examinado por cualquiera. Pero la realidad es que a menudo no se examina debido a la falta de financiación y las limitaciones de recursos humanos.

Un buen ejemplo del impacto potencial de los errores en el código abierto es Heartbleed, el error en OpenSSL que un investigador de Google reveló en 2014, que puso de relieve lo mal financiados que están muchos proyectos de software de código abierto. Afectando una pieza central de la infraestructura de Internet, Heartbleed impulsó a Amazon, IBM, Intel, Microsoft, Cisco y VMware a invertir dinero en la Fundación Linux para formar la Iniciativa de Infraestructura Central (CII).

Durante los últimos años, GitHub ha estado invirtiendo fuertemente en herramientas para ayudar a los proyectos de código abierto a corregir fallas de seguridad a través de su Gráfico de Dependencia, una función que funciona con su función de alertas de seguridad. El servicio de alertas de seguridad escanea las dependencias de software (bibliotecas de software) utilizadas en proyectos de código abierto y alerta automáticamente a los propietarios del proyecto si detecta vulnerabilidades conocidas. El servicio admite proyectos escritos en Java, JavaScript, .NET, Python, Ruby y PHP.

El informe Octoverse 2020 de GitHub señaló que el uso más frecuente de las dependencias de código abierto fueron JavaScript (94%), Ruby (90%) y .NET (90%). Si bien casi una quinta parte de las vulnerabilidades en el software de código abierto fueron puertas traseras plantadas intencionalmente, GitHub destaca que la mayoría de las vulnerabilidades eran simplemente errores antiguos.

"Estas vulnerabilidades maliciosas generalmente se encontraban en paquetes de uso poco frecuente, pero activaban solo el 0,2% de las alertas. Si bien es más probable que los ataques maliciosos llamen la atención en los círculos de seguridad, la mayoría de las vulnerabilidades se deben a errores", señala GitHub. Como informó Charlie Osborne de ZDNet, las vulnerabilidades en los proyectos de código abierto permanecen sin ser detectadas durante cuatro años en promedio antes de que se revelen al público. Luego, se tarda aproximadamente un mes en emitir un parche, según GitHub. En otras palabras, todavía hay margen de mejora a pesar de los esfuerzos de GitHub para automatizar la corrección de errores en proyectos de código abierto.

GitHub señala en su informe que la "gran mayoría" de las puertas traseras intencionales provienen del ecosistema npm. Catalin Cimpanu de ZDNet informó esta semana que el equipo de seguridad de npm tuvo que eliminar una biblioteca JavaScript maliciosa del sitio web de npm que contenía malware para abrir puertas traseras en las computadoras de los programadores. El uso de este lugar para distribuir malware a los desarrolladores tiene sentido dado que JavaScript es el lenguaje de programación más popular en GitHub

GitHub señala que solo el 0,2% de sus alertas de seguridad estaban relacionadas con actividades explícitamente maliciosas. "Una gran parte del desafío de mantener la confianza en el código abierto es garantizar a los consumidores intermedios la integridad y la continuidad del código en un ecosistema donde el acceso de compromiso voluntario es la norma. Esto requiere una mejor comprensión del gráfico de contribución de un proyecto, una revisión constante por pares, firma de compromiso y liberación, y seguridad de la cuenta reforzada a través de la autenticación de múltiples factores (MFA)".

GibHub señala que las fallas pueden incluir 'puertas traseras', que son vulnerabilidades de software que se plantan intencionalmente en el software para facilitar la explotación, y 'puertas de error' (bugdoors), que son un tipo específico de puerta trasera que se disfraza de errores convenientemente explotables pero difíciles de detectar, en lugar de introducir un comportamiento explícitamente malicioso.

El indicador más evidente de una puerta trasera es que un atacante obtiene acceso de confirmación al repositorio de código fuente de un paquete, generalmente a través de un secuestro de cuenta, como el ataque ESLint de 2018, que usó un paquete comprometido para robar las credenciales de un usuario para el registro de paquetes npm. La última línea de defensa contra estos intentos de puerta trasera es una cuidadosa revisión por pares en el proceso de desarrollo, especialmente de los cambios de los nuevos confirmadores.

Muchos proyectos maduros cuentan con esta cuidadosa revisión por pares. Los atacantes son conscientes de eso, por lo que a menudo intentan subvertir el software fuera del control de versiones en sus puntos de distribución o engañando a las personas para que obtengan versiones maliciosas del código, por ejemplo, cambiando apenas (typosquatting) el nombre de un paquete. 

Fuente: ZDNet

Suscríbete a nuestro Boletín

0 Comments:

Publicar un comentario

Gracias por dejar un comentario en Segu-Info.

Gracias por comentar!