¿Cuál es la gravedad si alguien lee el archivo ConnectionStrings_Prod.config?

Navega tus respuestas
0

Estaba haciendo una prueba de lápiz en un sitio web y el programador cometió un gran error y pude leer cualquier archivo. Así que leí web.config y veo que la contraseña para la base de datos estaba en ConnectionStrings_Prod.config .

Antes del informe y solo por curiosidad, traté de conectarme a la base de datos. Esto es MS SQL Server 2014. Debido a mi falta de conocimiento, no pude conectarme utilizando un programa común.

Entonces, ¿este fue solo mi error? ¿O esta es una segunda línea de defensa, porque solo la computadora dentro del servidor puede conectarse a la base de datos? (Estoy afuera, en mi empresa)

Este es el archivo completo. 

<connectionStrings>
  <remove name="LocalSqlServer" />
  <add name="LocalSqlServer" connectionString="Data Source=10.#.#.#\MSSQLSRV2014,24##;Initial Catalog=****;uid=*****;pwd=****;pooling=true; Min Pool size=50;; Max Pool Size=1000000;Connect Timeout=200;Packet Size=32767;trusted_connection=false;"
    providerName="System.Data.SqlClient" />
  <add name="**.Properties.Settings.*****ConnectionString"
    connectionString="Data Source=10.#.#.#\MSSQLSRV2014,24##;Initial Catalog=*****;uid=******;pwd=******;pooling=true; Min Pool size=50; Max Pool Size=1000000;Connect Timeout=200;Packet Size=32767;trusted_connection=false;"
    providerName="System.Data.SqlClient" />
</connectionStrings>

¿Cuál es el impacto de esta falla de seguridad?

    
pregunta Rodrigo 12.12.2014 - 18:33
fuente

2 respuestas

1

Desde mi punto de vista limitado, un atacante no podría obtener acceso inmediato a la base de datos.

El origen de datos en su fragmento se refiere a un servidor de base de datos en 10.#.#.# . La red 10.0.0.0/8 se reserva para redes privadas de acuerdo con RFC 1918 . Si usted es un atacante externo sin acceso directo a la red privada en la que se encuentra el servidor de base de datos, 10.#.#.# no es suficiente para conectarse directamente a la base de datos. Sin embargo, ha aprendido información importante de su objetivo.

Dependiendo de a qué se dirija y de acuerdo con la estructura del nombre de usuario y la contraseña, esta información puede valorarse para cualquiera de los siguientes ataques (tenga en cuenta que solo considero la información de conexión a la base de datos aquí y que esta lista es ciertamente incompleta ; el acceso a todos los archivos es un capítulo diferente que no debe omitir en su informe):

  • Conéctese directamente a la base de datos, utilizando alguna otra vulnerabilidad que le permita acceder a la red de alguna manera (otro servidor en la misma red es suficiente)
  • Conectar directamente, con acceso físico. Si el objetivo tiene algún tipo de área pública, un atacante puede obtener acceso a la red interna a través de una conexión WiFi mal configurada o un puerto LAN en la pared ...
  • Utilice la combinación de nombre de usuario / contraseña para un servicio diferente. Si los desarrolladores eran perezosos y reutilizaban estas credenciales en algún lugar, eso podría abrir algunas otras cosas
  • Use el nombre de usuario y / o la dirección 10.#.#.# para el ataque dirigido de ingeniería social hacia el titular de la credencial (si es una persona) o administradores

No soy usuario de MSSQL, por lo que no puedo darte una idea de la parte específica de MSSQL (¿quizás alguien más responderá si es necesario?).

    
respondido por el dst 12.12.2014 - 19:01
fuente
1

Solo porque no pudo conectarse directamente, esto todavía plantea algunos problemas (hablaremos sobre ellos en un segundo). Cualquier cosa y todo debe informarse siempre por algunas razones, es informativo, ilustra que se tomó el tiempo para analizar la información durante un compromiso. Ahora puedo pensar en algunas razones para que esto suceda (permisos) "

  • 1) El desarrollador tomó atajos (hizo cambios de permisos para facilitar    su trabajo)
  • 2) El desarrollador no podría hacerlo funcionar de otra manera y necesitaba eso.    permiso (leer todo) para que funcione

Con la información en la configuración legible, dependiendo de su estructura, un atacante probablemente puede usar esto para escalar privilegios (dependiendo de la configuración de las cuentas), acceder a los datos que de otra manera serían privados (por ejemplo, iniciar sesión en un servidor SQL en otra parte) en la red se proporcionaron las credenciales, etc.).

Dependiendo de qué tipo de participación (caja negra, caja blanca, caja blanca) puede preguntarle al desarrollador por qué está configurado como tal y, sin embargo, informar de ello, y ofrecer los riesgos asociados con tener datos almacenados / visibles de esa manera . Todo se reducirá a la tolerancia. Por ejemplo: "Usted tiene acceso a esta información para iniciar sesión en una máquina MIENTRAS SOLAMENTE en el servidor", aunque es horrible filtrar datos, no puede explotar ningún servidor para usar los datos que encontró, por lo que el riesgo es menor que si EXPLOTÓ el servidor, luego usaste esos datos.

He realizado compromisos pentest donde los datos de robots.txt me permitieron escalar a través de ataques encadenados. P.ej. Los archivos de configuración y los comentarios en las páginas apuntaban a otros directorios, lo que me permitía conectar puntos para explotar algo y, una vez que estaba dentro, no necesitaba escalar. Todo se me entregó nombres de usuario en comentarios, archivos de configuración antiguos con nombres de db, hashes, etc.

    
respondido por el munkeyoto 12.12.2014 - 19:01
fuente

Lea otras preguntas en las etiquetas

¿Alojar una aplicación en un virtualbox? [duplicar] Forense de enrutador [cerrado]