Qual è la gravità se qualcuno ha letto ConnectionStrings_Prod.config?

0

Stavo facendo un pen test in un sito Web e il programmatore ha fatto un grosso errore e sono riuscito a leggere qualsiasi file. Quindi ho letto web.config e ho visto che la password per il database era in ConnectionStrings_Prod.config .

Prima di segnalare e solo per curiosità, ho provato a connettermi al database. Questo è MS SQL Server 2014. A causa della mia scarsa conoscenza, non ero in grado di connettermi usando un programma comune.

Quindi, questo è stato solo un mio errore? O questa è una seconda linea di difesa, perché solo il computer all'interno del server può connettersi al database? (Sono fuori, nella mia compagnia)

Questo è l'intero file.

<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>

Qual è l'impatto di questo errore di sicurezza?

    
posta Rodrigo 12.12.2014 - 18:33
fonte

2 risposte

1

Dal mio punto di vista limitato, un utente malintenzionato non sarebbe in grado di accedere immediatamente al database.

L'origine dati nello snippet si riferisce a un server di database su 10.#.#.# . La rete 10.0.0.0/8 è riservata alle reti private in base a RFC 1918 . Se sei un utente malintenzionato esterno senza accesso diretto alla rete privata in cui si trova il server del database, 10.#.#.# non è sufficiente per connettersi direttamente al database. Hai, tuttavia, appreso informazioni importanti dal tuo target.

A seconda di cosa si sta puntando e in base alla struttura del nome utente e della password, queste informazioni possono essere valutabili per uno dei seguenti attacchi (si noti che qui considero solo le informazioni sulla connessione al database e che questo elenco è certamente incompleto ; l'accesso a tutti i file è un capitolo diverso che non dovresti omettere nel tuo rapporto):

  • Connettiti direttamente al Database, usando qualche altra vulnerabilità che ti conceda l'accesso alla rete in qualche modo (un altro server nella stessa rete è sufficiente)
  • Connessione diretta, con accesso fisico. Se l'obiettivo ha una sorta di area pubblica, un malintenzionato può essere in grado di accedere alla rete interna tramite una connessione Wi-Fi errata o una porta LAN sul muro ...
  • Utilizza la combinazione nome utente / password per un servizio diverso. Se gli sviluppatori sono stati pigri e hanno riutilizzato queste credenziali da qualche parte, questo potrebbe aprire alcune altre cose
  • Utilizza il nome utente e / o l'indirizzo 10.#.#.# per un attacco di social engineering mirato verso il titolare delle credenziali (se questa è una persona) o gli amministratori

Non sono un utente MSSQL, quindi non posso darti alcuna informazione sulla parte specifica di MSSQL (forse qualcun altro fornirà una risposta in merito se ciò è necessario?).

    
risposta data 12.12.2014 - 19:01
fonte
1

Solo perché non sei riuscito a connetterti direttamente, questo pone ancora alcuni problemi (parleremo in un secondo). Qualunque cosa e tutto dovrebbe sempre essere segnalato per alcuni motivi, è informativo, illustra che è stato impiegato del tempo per analizzare le informazioni durante un incarico. Ora ci sono alcune ragioni per cui posso pensare, perché questo accada (permessi) "

  • 1) Lo sviluppatore ha preso scorciatoie (ha apportato modifiche alle autorizzazioni per facilitare    il suo lavoro)
  • 2) Lo sviluppatore non riusciva a farlo funzionare diversamente e ne aveva bisogno    permesso (leggi tutto) per farlo funzionare

Con le informazioni nella configurazione leggibili, a seconda della loro struttura, un utente malintenzionato può probabilmente utilizzarlo per aumentare i privilegi (in base alla configurazione degli account), accedere ai dati altrimenti riservati (ad esempio, accedere ad un server SQL altrove sulla rete sono state fornite le credenziali fornite, ecc.)

A seconda del tipo di coinvolgimento (pentest black box, pentest box bianco) si potrebbe chiedere allo sviluppatore perché questo è configurato come tale, ma ancora segnalarlo, e offrire i rischi associati ad avere dati memorizzati / visibili come quello . Tutto si ridurrà alla tolleranza. Ad esempio: "Hai accesso a queste informazioni per accedere a una macchina SOLO sul server" anche se è orribile perdere dati, non puoi sfruttare alcun server per utilizzare anche i dati che hai trovato, quindi il rischio è inferiore rispetto a quando EXPLOITED il server, quindi utilizzato quei dati.

Ho fatto impegni poderosi in cui i dati da robots.txt mi hanno permesso di aumentare l'escalation tramite attacchi concatenati. Per esempio. i file di configurazione e i commenti nelle pagine puntavano ad altre directory, il che mi permetteva di collegare punti per sfruttare qualcosa, e una volta entrato non avevo bisogno di escalation. Tutto mi è stato consegnato nomi utente nei commenti, vecchi file di configurazione con nomi db, hash, ecc.

    
risposta data 12.12.2014 - 19:01
fonte

Leggi altre domande sui tag