Patrones para buscar datos privados en un repositorio de origen

5

Recientemente descubrí un caso en el que un colega había comprometido accidentalmente sus credenciales de inicio de sesión (host, nombre de usuario y contraseña) en un repositorio de código fuente local, y luego envió estos cambios a un repositorio público en GitHub. Por supuesto, esto no fue un incidente aislado: hace unos años, GitHub eliminó su función de búsqueda de código completo después de que la gente descubriera > cientos de claves privadas y otras credenciales en repositorios públicos .

Me gustaría asegurarme de que este tipo de cosas no hayan sucedido en el pasado con ninguno de nuestros otros repositorios públicos (y, en caso de que así sea, para limpiar los datos privados, cambiar las contraseñas expuestas, revocar las llaves expuestas, etc.). No es un problema para mí armar un script de shell para pasar las confirmaciones pasadas a un repositorio Git o Subversion determinado para que pueda escanearlos en busca de datos privados. Pero, ¿qué tipo de nombre de archivo y patrones de texto debo usar? Por ejemplo, quiero capturar archivos cuyo nombre sugiere que contienen claves privadas o credenciales ( password.txt , id_dsa , id_rsa , secring.gpg , .netrc y probablemente varios más estándar que estoy olvidando) o ni siquiera estoy al tanto de). ¿Hay alguna lista que cubra los casos más comunes? Del mismo modo, me gustaría escanear el contenido de los archivos de texto y de origen en busca de patrones que indiquen credenciales de inicio de sesión codificadas. Tal vez alguien ya haya producido una lista de expresiones regulares para comenzar?

    
pregunta Psychonaut 22.06.2016 - 09:18
fuente

2 respuestas

2

Los archivos importantes varían según el lenguaje de programación y el entorno. Por ejemplo, si está ejecutando nginx, los archivos .htaccess , por defecto, no afectarán el comportamiento del servidor. Sin embargo, esos mismos archivos realmente podrían desordenar si alguien carga su aplicación en un entorno de Apache. Por lo tanto, debe personalizar cualquier lista según sus propias necesidades.

Hay algunos archivos que probablemente siempre se consideran confidenciales aunque:

  • Claves privadas ( id_rsa , id_dsa , *.pfx )
  • Archivos Shadow ( /etc/shadow ): si está ingresando estos en el control de código fuente sin una buena razón, ¡está haciendo algo mal!
  • Archivos de historial ( .bash_history y similares): estos a menudo tienen contraseñas que se escribieron mal o se usaron en líneas de comando para almacenar herramientas interactivas
  • Archivos de registro ( /var/log/* ): una vez más, a menudo tienen detalles que quizás olvide buscar en

Archivos más específicos que no deberían estar en el control de código fuente:

  • .htaccess , .htpasswd - Archivos de configuración específicos del directorio de Apache
  • web.config - archivo de configuración específico del directorio IIS
  • wp-config.php - Configuración de Wordpress
  • sites/*/*settings*.php - Archivos de configuración de Drupal
  • *.jks - archivos de almacén de claves
  • y así sucesivamente ...

Github tiene una buena muestra de contenido del archivo gitignore , aunque estos también cubren cosas que no deberían estar en el control de código fuente debido a otras razones (por ejemplo, la salida compilada generalmente no debería estar en el control de fuente, debido a que no es fuente ...)

    
respondido por el Matthew 22.06.2016 - 10:34
fuente
1

Hay una aplicación llamada " OpenDLP " ( prevención de pérdida de datos) que se puede usar para explorar su red en busca de datos confidenciales. Se basa en expresiones regulares para que pueda configurarlo para buscar lo que desee: contraseñas, palabras clave en propiedad intelectual, números de seguridad social, tarjetas de crédito. Esto definitivamente ayudaría a minimizar las ocurrencias de fuga de datos.

Cada vez que realizo un pentesting, disfruto encontrando datos en repositorios. El error humano es siempre la causa número de una violación. Durante mi pentesting, ejecuto OpenDLP para ayudarme a rastrear recursos compartidos, servidores de archivos, lo que sea, en busca de lo que pueden ser credenciales y contraseñas. No solo deben abordarse los sistemas públicos, sino también los sistemas internos, donde un administrador puede dejar un archivo de configuración con credenciales que tiene poca protección en el archivo. Esto permitiría a un atacante si entrara a través del ataque del lado del cliente, para minimizar otros ataques contra las credenciales (por qué descifrar las contraseñas si me las dan).

Aparte de eso, realmente no se puede resolver un problema social (empleados olvidadizos) con tecnología. La formación y la conciencia solo pueden llegar hasta aquí. Lo que más importa es el cumplimiento y las pruebas de esa capacitación. Tómese el tiempo para que sus empleados comprendan: "Antes de enviar / cargar / cambiar / implementar su trabajo, tómese un momento para asegurarse de que no ha divulgado información confidencial. Cualquier persona que no siga el procedimiento está sujeta a una advertencia, seguida de una suspensión, seguido de la terminación ".

    
respondido por el munkeyoto 22.06.2016 - 14:35
fuente

Lea otras preguntas en las etiquetas