TruffleHog olfatea Github en busca de claves secretas

Las claves secretas son, literalmente, la clave de la seguridad en el desarrollo de software. Si un actor malintencionado accede a las claves que protegen sus datos, brinde. El problema es que al usar claves, debe escribirlas en algún lugar, a menudo en el código fuente. TruffleHog ha llegado a oler esas claves secretas en su repositorio de Github.

Es un truco ingenioso: un script de Python recorre el historial válido de un repositorio, observa cada cadena de texto de más de 20 caracteres y analiza su entropía de Shannon. Esta es una forma matemática de determinar si parece una cadena relativamente aleatoria de números y letras. Si tiene una entropía alta, probablemente sea algún tipo de clave.

Compartir el código fuente es siempre un arma de doble filo para la seguridad. Todos los defectos son visibles para todos, y hay tanto los que aprovecharán los defectos como los que ayudarán a repararlos. Es una cuestión de opinión si los beneficios superan las ganancias, pero es difícil discutir los beneficios laborales de tener más ojos en el código para detectar errores. Sin embargo, asumimos que muchos lectores entregaron accidentalmente claves secretas en un repositorio de git y tuvieron que regresar antes de presionar. Esta herramienta puede explorar algunas publicaciones públicas de git rap, pero podría ser igualmente útil en los controles de seguridad de su propia base de código para garantizar que las claves visibles al azar se cancelen y reemplacen.

Para ver un ejemplo del mundo real de claves secretas robadas, lea esta filtración de HDMI que huele a claves HDCP.

  • nsayer dice:

    Apuesto a que TruffleHog obtendría claves públicas. Estos no son necesariamente agujeros de seguridad. Por ejemplo, si configura un sitio web de confianza, probablemente compile la clave de anclaje de confianza (o certificado) en su código.

    Por supuesto, debe asegurarse de mantener y proteger cuidadosamente la clave * privada * relevante …

    Muchas valiosas claves privadas de anclaje de confianza existen solo en papel. Usas una computadora completamente sin conexión a Internet para generar el par de claves raíz, luego tienes que imprimir la clave privada que guardas en la caja fuerte. Luego, genera inmediatamente un par de claves secundarias, convirtiendo la clave pública en un certificado firmado por la clave privada raíz. Luego imprime ese certificado de afiliado y la clave, luego apaga la computadora (y si está paranoico, la rompe y tira los pedazos a la basura). La clave privada raíz bloqueada la guarda en un secreto seguro, toma los dos certificados y la clave privada del afiliado y los carga en una computadora conectada. La clave privada que bloquea con cualquier protección adecuada para su aplicación. Los dos certificados que puedes publicar.

    Usted hace todo lo posible para que, si la clave privada que está utilizando realmente se compromete, pueda sacar la clave privada raíz de la caja fuerte y usarla para emitir una CRL y un nuevo certificado. También mitiga ese riesgo de compromiso estableciendo una fecha de vencimiento más baja en el certificado de afiliado y, poco antes de que expire, regresa y realiza el ritual de emitir un nuevo certificado de afiliado desde la raíz de papel a través de una computadora desconectada. Hace todo esto porque no hay una solución fácil para comprometer la clave raíz que no sea una actualización global universal del firmware y el buque insignia, que es relativamente muy costosa.

    • Adán dice:

      Eso, sin embargo, es todo. Si bien todo lo que dices es cierto, para las personas que no usan claves raíz, la clave privada a veces está en código, que se ejecuta al azar, desde un lado accede a alguna base de datos con una contraseña simple y listo. Apuesto a que hay muchas de estas contraseñas ocultas en las obras de GitHub.

    • John Doe dice:

      Tiene algunos falsos positivos. Por ejemplo, en mis repositorios encontró “doble pi = 3.141 …” y un código base64.

  • roberto dice:

    > Si tiene una entropía alta, probablemente sea algún tipo de clave.

    Er … o … iduno, ¿comprimido?

    • algún chico dice:

      esto. El pensamiento entrópico también puede funcionar para claves, pero no para (muchas) contraseñas de ASCII.
      Podría ser interesante: http://www.devttys0.com/2013/06/differentiate-encryption-from-compression-using-math/ (del tipo binwalk (s?))
      Por cierto, del mismo tipo, podría ser útil algún día: base de datos de claves privadas SSL / SSH para dispositivos integrados https://github.com/devttys0/littleblackbox

    • Hombre negro dice:

      O borroso.

  • BioSehnsucht dice:

    O simplemente puede usar Github Search

    http://www.securityweek.com/github-search-makes-easy-discovery-encryption-keys-passwords-source-code

  • WJCarpenter dice:

    Paso la mitad de mi tiempo “sombrero de seguridad” castigando a los desarrolladores por insertar claves en el código fuente. Nunca se puede decir nunca, pero aun así encontré un caso en la práctica en el que no fue un error o simplemente una pereza.

    • GNUtoo dice:

      Encontrar una forma de contactar al propietario o los autores del proyecto no es difícil de hacer, los comisionados tienen un correo electrónico dentro del campo del autor, probablemente github también tiene una forma de enviar un mensaje a los usuarios, por panel de control o por algún otro medio.

      Por lo tanto, se podría usar una herramienta que busque una clave, contraseña o secretos para encontrar los problemas y avisar a las personas que pueden solucionarlos.

      Sin embargo, la pregunta es cómo prevenir la gran cantidad de posibles falsos positivos:
      – crear una herramienta que entienda cómo encontrar frases de contraseña podría ser difícil
      – Asumiría que muchas frases de contraseña cambiarían por defecto a CHANGEME en los archivos de configuración.
      – los archivos de configuración podrían enviarse a lugares donde no se utilizan realmente, sino que se utilizan como documentación o ejemplos.
      – Muchos programas tienen certificados SSL predeterminados que se envían con ellos, luego el usuario espera generar otros nuevos. Me pregunto si tal práctica tiene sentido, ssh, por ejemplo, generará nuevas claves al inicio si no hay nadie presente. Ahora que lo hemos cifrado, dicho software podría usar su protocolo para generar claves válidas.
      – Software de “enraizamiento”: algunos dispositivos de consumo con GNU / Linux o Android no permiten al usuario acceder al sistema subyacente. El Archos 605 WiFi es un ejemplo entre muchos otros. En ese caso, existen herramientas para aprovechar los problemas de seguridad en el firmware predeterminado para ayudar al usuario a recuperar el control de sus dispositivos. A veces envían digitales de lluvia con una contraseña codificada.
      – Configuración y seguridad en otra parte: SSH está fácilmente disponible en todas partes, con imagen LEDE, sin interfaz de Internet, aún necesita iniciar sesión en el dispositivo para configurar la frase de contraseña o las claves SSH. Sin embargo, puede conectar el dispositivo directamente a su computadora: esto evitará que un atacante pueda conectarse frente a usted.

      Una buena manera de resolver algunos de los problemas anteriores (enrutamiento y OpenWRT / LEDE) sería inyectar las claves o la contraseña del usuario dentro de la imagen o el binario antes de instalarlo en el dispositivo, pero actualmente AFAIK no existe tal herramienta.

      Si hay una manera de mantener baja la cantidad de falsos positivos (lo que daría lugar a una gran cantidad de claves perdidas), sería genial tener una herramienta que busque claves privadas y que envíe un correo electrónico al usuario.
      ¿Hay alguna forma de hacer que el propietario del repositorio indique si se pueden encontrar claves privadas en el repositorio, una buena forma de lidiar con los falsos positivos?

      Otra cosa a hacer sería encontrar una manera de lidiar con muchos de los problemas anteriores. Algunos programas conocidos vienen con certificados ssl predeterminados que se conocen públicamente.
      Algunos documentos sobre buenas prácticas de seguimiento podrían ser un comienzo para encontrar formas de abordar las tesis.

      Denis.

  • ROBÓ dice:

    Así que usemos hacks como “mi palabra secreta” para que tenga menos de 20 caracteres y una entropía baja para que no se descubra, ¿verdad?

  • GrowlerBoy dice:

    Aquí vamos de nuevo … ¡Alguien escribió un script en Python! ¡Noticias maravillosas! ¡Alguien está llamando la atención de los principales medios de comunicación! #NotAHack

    • JIm B dice:

      Aquí estamos de nuevo … alguien escribe “NotAHack” y no da un enlace a su trabajo digno de hackear. Está bien, tiene razón, la-tecnologia, por favor, devuelva sus honorarios.

      El desprecio es barato. Proporcione algo mejor.

  • jajaja dice:

    si tiene una clave secreta estática en su código, eso es un problema, sí. (estos deben generarse y / o leerse desde un archivo de texto separado)

    • Greenaum dice:

      Luego, guarde el archivo de texto en una tarjeta SD e insértelo con un fragmento.

      • Crioindio dice:

        También necesitará quemar la trituradora. Vio demasiado.

      • ROBÓ dice:

        La matriz SD probablemente terminará en una sola pieza cortada e intacta, excepto por los cables de conexión, por lo que los datos se recuperarían.

        Si solo escribe todo en la tarjeta SD, se eliminará y ni siquiera se podrá recuperar legalmente.

        Por otro lado, los datos del disco duro son mucho más recuperables, ya que necesita alrededor de 35 pases de datos aleatorios o simplemente saque el plato (s) y dóblelos, eso funciona bien 🙂

        • algún chico dice:

          Un paso para HDD es suficiente. http://www.howtogeek.com/115573/htg-explains-why-you-only-have-to-wipe-a-disk-once-to-erase-it/
          Pero para SD (o SSD), es posible que alguien aún pueda recuperar algunos datos debido a sectores defectuosos que ya no son utilizados por el controlador (y, por lo tanto, no se reemplazan).

          • ROBÓ dice:

            Si fuera simplemente una niebla urbana, entonces el Departamento de Defensa de EE. UU. Tendría una especificación para eliminar datos.
            Estándar DoD 5220.22-M

            Claro, entiendo que ya no se necesitan 35 pases, pero 7 pases aleatorios probablemente sean tan buenos como complementarios y luego un pase aleatorio. Sin embargo, no tengo un programa complementario.

            Y sobre los sectores defectuosos, si su software no escribe en los sectores defectuosos, no se tomará la seguridad en serio.

            Algunos incluso creen que un sistema operativo como Windows * eliminará * archivos cuando en realidad el archivo permanece completamente intacto. las ventanas simplemente te lo ocultan.

          • algún chico dice:

            Sé que hay especificaciones que dicen eliminar 35 veces, pero tal vez los militares que escriben esto son realmente preocupados / paranoicos o las especificaciones son realmente antiguas
            En los sectores defectuosos, hablé del controlador en la tarjeta SD que asigna el acceso de un sector a otro porque el sector original era malo. No puede reemplazar el sector defectuoso, excepto tal vez usar comandos especiales para la tarjeta SD.
            Sí, conozco Windows y, a veces, es algo bueno, especialmente en personas que no son tan buenas con las computadoras. …

          • ROBÓ dice:

            Es un cambio en la tecnología ie. Los discos duros son analógicos y en los antiguos se pueden extraer tres capas de datos de ellos. Los discos duros más nuevos utilizan el mismo margen con más recursos para obtener mayores capacidades.

  • Paul Klemstine dice:

    Construí una interfaz que toma una lista aleatoria de repositorios de github y los atraviesa con TruffleHog. También funciona en un contenedor Docker.
    https://github.com/raver1975/secretpig

  • Mackenzie dice:

    TruffleHog y otros proyectos de código abierto son excelentes como plataforma para crear soluciones de detección personalizadas. He tenido un mayor éxito, especialmente a gran escala, con alternativas comerciales que aún brindan cierta flexibilidad de código abierto.

    https://www.gitguardian.com/gitguardian-vs-trufflehog-alternatives

Matías Jiménez
Matías Jiménez

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *