Para los cazadores de recompensas por errores, los repositorios de GitHub pueden revelar una variedad de información potencialmente útil. Puede haber problemas con objetivos que no siempre son de código abierto. A veces, los miembros de la organización y sus iniciativas de código abierto revelan por error información que podría usarse contra la empresa objetivo. Le daré una descripción general rápida en este artículo que debería ayudarlo a comenzar a escanear los repositorios de GitHub en busca de vulnerabilidades y realizar un reconocimiento general.

1-Clonación Masiva

Puede realizar su investigación en github.com; sin embargo, para habilitar las pruebas locales, le aconsejo que clone todos los repositorios de destino. El GitHubCloner de @mazen160 es un producto fantástico. Todo lo que tiene que hacer es ejecutar el script para estar listo.

$ python githubcloner.py --org organization -o /tmp/output

      
                

                    
                    
                
            

Es crucial comprender realmente el proyecto al que apunta antes de comenzar un análisis estático. Use las funciones principales mientras ejecuta el proyecto. La razón por la que me refiero a esto como el "paso de Jobert" es porque he oído que antes de comenzar cada cacería, Jobert usa el proyecto y obtiene una buena comprensión del objetivo antes de buscar debilidades.

3- Análisis manual

El dicho "aprende a hacerlo, luego rómpelo" se aplica en esta situación. Si puede aprender un lenguaje de programación, debería poder comprender los entresijos de las precauciones de seguridad que debe tomar y evitar.

Puede comenzar a hacer grepping una vez que esté familiarizado con el objetivo y su arquitectura. Busque palabras clave que le interesen, con las que esté familiarizado o que sepa que los desarrolladores se equivocan con frecuencia.

Aquí hay una lista básica de algunos de los términos de búsqueda que usaré durante una primera evaluación amplia:

• API y clave. (Obtenga algunos puntos finales más y encuentre claves API).
• simbólico
• secreto
• HACER
• contraseña
• vulnerable
• http:// y https://

• CSRF
• aleatorio
• picadillo
• MD5, SHA-1, SHA-2, etc..
• HMAC

Otro paso crítico es revisar el historial de confirmaciones. Te sorprenderá la cantidad de información que puedes obtener de las confirmaciones. He visto colaboradores que creen erróneamente que han eliminado las credenciales mientras permanecen en el historial de confirmaciones. Debido a la historia de git, descubrí puntos finales antiguos que aún funcionan. Además de las preocupaciones actuales, es posible que encuentre problemas históricos que pueden evitarse debido a compromisos anteriores.

4- Herramientas

A veces, la automatización de las tareas aburridas puede ayudar a darle una visión general básica de lo que debe buscar. Es crucial recordar que nunca debe copiar y pegar los resultados del análisis en los informes. Obtendrá una gran cantidad de falsos positivos, por lo que siempre debe investigar cuidadosamente cualquier problema potencial para asegurarse de que pueda ser explotado.

La principal herramienta que empleo cuando persigo proyectos de Python es Bandit .

Bandit identificará problemas comunes, pero con frecuencia devolverá falsos positivos o frutos al alcance de la mano. Así que úsalo con precaución. Sin duda, no se debe confiar en él.

$ bandit -r path/to/your/code -ll

Snyk.io es una herramienta maravillosa para verificar dependencias. La plataforma admite una amplia variedad de idiomas.

Para el reconocimiento, muchos investigadores sugieren usar Gitrob . Esta herramienta buscará información confidencial en los repositorios públicos de GitHub.

$ gitrob analyze acme,johndoe,janedoe

$ truffleHog https://github.com/dxa4481/truffleHog.git

Para las aplicaciones de Ruby on Rails, recomiendo Brakeman . Brakeman es un escáner de seguridad de análisis estático que puede encontrar una gran cantidad de problemas de seguridad en el código.

Utilice LinkFinder de Gerben Javado para encontrar puntos finales en los archivos JS del repositorio.

$ python linkfinder.py -i 'path/to/your/code/*.js' -r ^/api/ -o cli

OK, en serio, no hagas ingeniería social a los propietarios del proyecto.

Informe de sus hallazgos

Como siempre, cuando se trata de la caza de recompensas por errores, lea detenidamente la política del programa. Muy rara vez un programa acepta informes a través de GitHub. Póngase en contacto con el equipo de seguridad o, si es posible, utilice una plataforma de recompensas por errores como HackerOne o Bugcrowd

Como nota al margen, lo bueno de las pruebas de caja blanca es que, dado que tiene acceso al código, puede ser más fácil sugerir una solución o enviar un parche.

¡GRACIAS POR LEER ESTO!