¿Cómo se debe verificar la seguridad del código fuente?

40

¿Cómo comprobar si el código fuente de un proyecto de código abierto no contiene contenido malicioso? Por ejemplo, en un conjunto de archivos de código fuente con un total de 30,000 líneas, puede haber 1-2 líneas que contengan una declaración maliciosa (por ejemplo, llamando a curl http://... | bash ).

Esos proyectos no son bien conocidos y no se puede suponer que estén bien mantenidos. Por lo tanto, la seguridad de reutilizar el código fuente de su proyecto no puede basarse simplemente en la confianza de los ciegos (si bien debe ser una suposición razonable de que sería seguro descargar, verificar, compilar y ejecutar cmake directamente, no suena bien a ciegas). use una biblioteca arbitraria alojada en GitHub).

Alguien me sugirió que filtrara el código fuente y eliminara todos los caracteres no ASCII e invisibles (excepto algunos triviales como saltos de línea). Luego, abra cada archivo con un editor de texto y lea manualmente cada línea. Esto requiere algo de tiempo, requiere mucha atención cuando leo el código y, en realidad, es bastante propenso a errores.

Como tal, estoy buscando métodos generales para manejar este tipo de situaciones. Por ejemplo, ¿hay herramientas estándar disponibles? ¿Hay algo en lo que deba prestar atención si realmente tengo que leer manualmente?

    
pregunta tonychow0929 26.10.2018 - 14:37
fuente

5 respuestas

22

Hay enfoques automatizados y manuales.

Para automatizado, puede comenzar con lgtm , un analizador de código estático gratuito para proyectos de código abierto y luego pasar a soluciones SAST más complejas.

Para manual: puede crear un modelo de amenaza de su aplicación y ejecutarlo a través de OWASP ASVS checklist a partir de sus partes más críticas. Si hay eliminación de archivos en su modelo de amenaza, solo llame a algo como esto: grep -ir 'os.remove(' .

Por supuesto que es mejor combinarlos a ambos.

    
respondido por el odo 26.10.2018 - 14:51
fuente
19

Lo haces tú mismo o confías en otra persona

Como con la mayoría de las cosas en la vida, debes hacerlo tú mismo o confiar en alguien más. Aquí, confiar abarca tanto no tener intenciones maliciosas como ser lo suficientemente competente para realizar la tarea correctamente.

Por ejemplo, puede presentar sus impuestos a usted mismo o confiar a un asesor fiscal para que lo haga (quien no solo no debería intentar defraudarlo sino también saber cómo hacerlo). presentar los impuestos!).

Si eres una empresa, hacerlo solo será realizado por uno o varios de tus empleados, que a su vez deben ser de confianza.

El tercero en el que confías, tampoco necesita ser una sola persona. Podría ser el Equipo de desarrollo de Microsoft Windows o los Desarrolladores principales de Wordpress .

En cuanto a la seguridad del código fuente, desea que el experto no solo tenga buenas intenciones, sino que también tenga conocimientos para codificar el programa de manera segura / encuentre los posibles problemas de seguridad que puedan existir.

(más algunos sistemas de borde adicionales cuando se tratan como un todo, por ejemplo, usted quiere que su código no se vea comprometido mientras lo subieron al repositorio, o el correo electrónico de su empleado indicando que los resultados son reemplazados por un hacker malicioso dentro de su red para decir que la aplicación estaba bien)

Necesitará evaluar sus opciones, evaluar el riesgo asociado con cada una y elegir el camino que mejor se adapte a sus intereses (y presupuesto).

Si tuviera que verificar la seguridad del código fuente de un blog que usaba Wordpress, generalmente confiaría en que el código original estaba bien1¹ y verificar las diferencias entre la versión oficial y la utilizada . Si el sitio web estuviera comprometido, sería mucho más fácil averiguarlo.

¹ Obviamente, verificando el registro de cambios de versiones posteriores si usó uno desactualizado.

Sin embargo, si fue desarrollado por el sobrino del propietario, esperaría encontrar muchas vulnerabilidades allí, y recomendaría una revisión exhaustiva de todo.

En su caso, debe evaluar el riesgo y el costo de desarrollar el equivalente de esa biblioteca (tenga en cuenta que la posibilidad de problemas en su producto interno no es cero, tampoco, y dependerá, entre otras cosas, de) la calidad de las personas involucradas) frente al riesgo y el costo de la auditoría y el uso de esa biblioteca.

Ahora, puede haber factores atenuantes que simplifiquen la auditoría. Por ejemplo, si el código que no es de confianza se puede ejecutar en una máquina virtual aislada, eso puede ser suficiente para no necesitar una auditoría adicional (incluso aquí, confía en la implementación de la máquina virtual). O puede considerarse suficiente para auditar las partes de ese programa que se ejecutan como root.

Para auditar una biblioteca, los analizadores de código pueden ayudar a señalar las partes problemáticas (como se señaló), pero para considerarlo limpio, en realidad habría alguien que leyera y entendiera el código, incluso si superficialmente.

Por ejemplo, la capacidad de eliminar archivos arbitrarios no es maliciosa per se . Debe comprender el programa para saber si tiene sentido.

Nuevamente, es una cuestión de amenazas y riesgos para lo que está haciendo. Si solo le preocupan los datos de la biblioteca que se están filtrando, filtrar las conexiones en el firewall podría ser suficiente. Si le preocupa que la biblioteca elimine archivos importantes (y por alguna extraña razón no puede negar dicho permiso), simplemente puede desplazarse por un montón de código que solo hizo cálculos matemáticos. Si esa biblioteca calcula los parámetros para lanzar un cohete ... bueno, ¡mejor asegúrate de que esos cálculos también sean correctos!

    
respondido por el Ángel 26.10.2018 - 18:04
fuente
3

Usa un servicio

Hay servicios profesionales como Black Duck y Whitesource que audita las dependencias de código abierto.

    
respondido por el DawnPaladin 27.10.2018 - 00:04
fuente
2

Si usa el código de otra persona, entonces está más o menos a merced de los mecanismos de integridad que brindan los mantenedores, eso es cierto para todo el software, no solo para el código abierto.

La firma de código de software de código abierto tanto comercial como empaquetado (es decir, rpm, deb, etc.) es común. Esto demuestra que usted recibió lo que el firmante pretendía que recibiera.

En el caso del código fuente, normalmente se utilizan sumas de comprobación. Pero esto tiene poco valor a menos que se pueda acceder a la suma de comprobación desde una fuente diferente: el código fuente.

Tenga en cuenta que estos solo están diseñados para proteger contra un ataque de tipo MITM en la aplicación.

  

use una biblioteca arbitraria alojada en GitHub

... en cuyo caso todos los archivos / versiones tienen un hash publicado en Github: para subvertir esto, un atacante tendría que subvertirlo a sí mismo o a la cuenta de Github del mantenedor. Puedo bifurcar cualquier cosa en Github, pero es luego se me atribuye y el repositorio original no se ve afectado a menos que el mantenedor acepte mis solicitudes de extracción. Es posible que tenga más confianza en la integridad de Github que en los mantenedores del código, en cuyo caso sería razonable confiar en un hash publicado en el mismo lugar que el código fuente.

Ninguno de estos mecanismos proporciona protección contra el malware que se inyectó antes de que se aplicara la verificación de integridad.

Cuando tiene acceso al código fuente, tiene la opción de examinar el código (que es mucho más fácil que examinar los ejecutables) y existen herramientas automatizadas para hacerlo, como lo sugiere Odo.

    
respondido por el symcbean 26.10.2018 - 15:12
fuente
1

Los analizadores estáticos no siempre funcionarán

Las comprobaciones de os.remove en cualquier parte del código no funcionarán en todos los atacantes, ya que algunos simplemente pueden hacer eval("os" + ".remove") . Se pueden hacer expresiones regulares más avanzadas, pero el atacante siempre puede hacer que su código sea más complicado, por ejemplo:

x = "r"
eval("os." + x + "emove")

Más teóricamente, debido al problema de la detención, es imposible verificar todos los estados potenciales para ver si se invoca una llamada peligrosa al sistema.

Un atacante puede evitar los analizadores de código estático fácilmente creando un pequeño intérprete para un lenguaje personalizado que realice las operaciones maliciosas.

Ejecutando el código dentro de un contenedor / honeypot

Todo el software eventualmente interactúa con el sistema operativo. Al ejecutar el software dentro de un contenedor o honeypot con strace o una herramienta similar, puede ver qué información está intentando recopilar el programa o la biblioteca.

¿El programa intenta averiguar si se está ejecutando dentro de un contenedor? ¿Lee archivos que no deben o incluso los modifica? Entonces puedes tener un software malicioso.

Esto no siempre funcionará, puede ser necesaria alguna inspección manual

Algunos códigos maliciosos solo se activan en fechas específicas, pero al menos verá que se accede a este. Desde allí puede inspeccionar en qué parte del código ocurre esto y por qué.

    
respondido por el Ultimate Hawk 29.10.2018 - 10:41
fuente

Lea otras preguntas en las etiquetas