GitHub Dorks: Buscando "Trufas" en GitHub usando TrufleHog & GitRob

El teletrabajo está demostrado que puedes ser más eficiente para las empresas de lo que la mayoría de las organizaciones pensaba hasta hace unos meses. Pero también puede traer consigo un incremento de “leaks” de información confidencial si no tenemos cuidado con la manera de implementarlo. Inspirándome en el post que escribí sobre el  "Google Dorks & Low Hanging Fruit: Open Redirects" podría decirse que esta es una segunda parte, ya que vamos a usar dorks similares para encontrar "trufas" en una de las plataformas que más está dando que hablar últimamente en la comunidad: Github

Figura 1: GitHub Dorks: Buscando "Trufas"
en GitHub usando TrufleHog & GitRob

Github es una plataforma para desarrolladores donde pueden compartir código en diferentes lenguajes de programación. En ella se permite editar simultáneamente un proyecto, lo que resulta de gran utilidad en escenarios de teletrabajo, pero si no se usa con cuidado, también presenta una gran amenaza a la seguridad de las empresas, ya que en este entorno es relativamente sencillo que a alguien se le termine escapando en el código que sube alguna KEY, algún TOKEN o contraseña…

Figura 2: Hacking con Buscadores 3ª Edición
de Enrique Rando

Y ahí viene la gracia, es un entorno fantástico para aplicar todas las técnicas de Hacking con Buscadores, pero en este caso dentro de la plataforma de GitHub, así que vamos a ver cuáles son sus posibilidades. En esta plataforma cuenta con un buscador con multitud de comandos, entre los más útiles destacaría:

Figura 3: Comandos de búsqueda en GitHub

Como podéis ver, se pueden utilizar comandos bastante específicos para localizar cosas jugosas, así que ahora es el momento de ver qué tipos de GitHub Dorks podemos crear para sacar partido en un entorno de búsqueda de objetivos en un pentesting.

Github Dorks

Teniendo estos comandos claros, las posibilidades son infinitas. Podemos probar filtrando por la organización objetivo y campos como “password”, “pwd”, “token”, “credential”….

Figura 4: Buscando "password" en GitHub

Con esta técnica podemos encontrarnos con auténticas bases de datos de usuarios y clientes volcadas en Github por descuido, así como credenciales de AWS (aws_secret), tokens calentitos que han sido recientemente indexados y que todavía no han expirado. Este tipo de técnicas son similares a las que se pueden ver en la charla de Chema Alonso de "Dorking & Pentesing with Tacyt", donde hacía dorks similares para buscar en el código fuente de las apps que el servicio de ElevenPaths tiene indexado, que es lo mismo que podemos hacer en GitHub.


Figura 5: Dorking & Pentesting con Tacyt por Chema Alonso
Aquí surge una segunda derivada, ya que si la organización cuenta con mecanismos de control contra leaks en Github, el riesgo no se mitiga por completo, ya que los trabajadores cuentan con su página personal en Github donde puede haber leaks fuera del radar de la organización. Veamos por ejemplo, Netflix, una compañía que si tiene un mecanismo de control de leaks en su repositorio oficial de Github:

Figura 6: Netflix Open Source Platform

Vemos que cuenta con 15 usuarios registrados en su repositorio oficial. Lo que podríamos hacer aquí es meternos en la página personal de cada uno de esos usuarios y buscar repositorios propios donde se suelen guardar notas o trozos de código que no están en el repositorio oficial y que son altamente peligrosos para la compañía. 

Si nos fijamos en la dimensión de Netflix, suena raro que tan solo cuente con 15 empleados desarrollando código, y esto no es así, el problema es que muchos de los que trabajan en el repositorio no han vinculado su perfil al de Netflix, algo todavía más peligroso, ya que podríamos buscar “developer” en Linkedin y filtrando por la organización podríamos obtener usuarios de Github que sabemos que trabajan pero cuyo perfil no está vinculado al de Netflix. 

Figura 7: Libro Open Source INTelligence (OSINT):
Investigar personas e Identidades en Internet
de Vicente Aguilera y Carlos Seisdedos

Utilizar Linkedin como fuente de datos OSINT es algo habitual, y el libro que publicaban ayer sobre OSINT y la investigación en redes sociales dedica un capítulo enorme solo a este asunto, como puedes ver en el índice del libro. Estos usuarios que trabajan en una compañía y lo anuncian en Linkedin, y luego no están vinculados a los repositorios oficiales de la empresa en Github son estos los que, por norma general, guardan la mayor cantidad de Leaks. Por suerte, Netflix ("rara avis") también tiene a estos usuarios controlados, pero no es lo habitual.

Trapos sucios de las organizaciones en Github

Otra de las curiosidades que nos está dejando esta cuarentena es una gran cantidad de discusiones en repositorios, en las que parece que los usuarios implicados no recuerdan que su conversación es pública. 

Figura 8: Issues & Discussions en GitHub

Para ello basta con buscar en las secciones “Issues” y “Discussions” donde los desarrolladores presentan un problema y discuten (no siempre de las mejores formas, poniendo en riesgo reputacional a la compañía) hasta conseguir solucionarlos.

Automatizando la búsqueda: TrufleHog & GitRob

Sería ideal que las organizaciones tuvieran alertas sobre posibles leaks en Github de sus empleados, para ello existen dos herramientas que permiten automatizar este proceso. La primera es TruffleHog que por supuesto está en GitHub y puedes ver en ejecución en la imagen siguiente en la que busca Keys de AWS que puedan estar fresquitas.

Figura 9: TruffleHog

Y la segunda que os dejo, que también está en GitHub, por supuesto, es Gitrob, que te animo a que pruebes un rato para ver qué es lo que eres capaz de encontrar. Recuerda que constantemente hay actualizaciones de código, así que siempre hay "trufas" frescas que localizar.

Figura 10: GitRob en GitHub

Hay que remarcar que las posibilidades son infinitas tanto para la parta atacante como para la atacada. Es especialmente importante que en entornos de teletrabajo seamos más cuidadosos que nunca y que trabajemos con la VPN de nuestra organización que nos permita tener una conexión segura. Estos escáneres también son susceptibles de ser usados por los “malignos” y no sería recomendable que ellos se enteraran antes que nosotros de que hemos tenido un “leak”. 

Figura: Contactar con Nico Waisman

Por último, me gustaría recalcar que el equipo de seguridad de GitHub se preocupa mucho por este tipo de leaks y ayuda a la comunidad de developers constantemente con herramientas y seminarios de concienciación. Cuenta en su equipo con grandes profesionales y siempre que desde la comunidad de hackers se ha reportado algo a GitHub lo han corregido y mejorado. Son developers trabajando para developers, y eso se nota. Ha sido una alegría ver que Nico Waisman está en el equipo como Senior VP de Innovación en Seguridad de GitHub, así que os podéis hacer una idea de cómo de serio se toma la seguridad esta compañía.

Un saludo,

Autor: Pablo García Pérez

Contactar con Pablo García