I was doing an pen test in a website and the programmer did a big mistake and I was able to read any file. So I read the web.config and see the password for database was in ConnectionStrings_Prod.config.

Before report and just for curiosity, I tried to connect to database. This is MS SQL Server 2014. Because my lack of knowledge, I wasn't able to connect using common program.

So, this was my mistake only? Or this is a second line of defense, because only computer inside the server can connect to the database? (I am outside, in my company)

This is the entire file.

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

What is the impact of this security fault?

2 Answers 2


From my limited point of view, an attacker would not be able to immediately gain access to the database.

The data source in your snippet refers to a database server on 10.#.#.#. The network is reserved for private networks according to RFC 1918. If you are an external attacker without direct access to the private Network the database server is in, 10.#.#.# is not sufficient to connect to the database directly. You have, however, learned important information from your target.

Depending on what you're aiming for and depending on the structure of username and password, this information can be valueable for any of the following attacks (note that I only consider the database connection information here and that this list is certainly incomplete; access to all files is a different chapter which you should not omit in your report):

  • Connect directly to the Database, using some other vulnerability granting you access to the network in some way (another server in the same network is sufficient)
  • Connect directly, with physical access. If the target has some kind of public area, an attacker may be able to gain access to the internal network through some misconfigured WiFi or a LAN port on the wall...
  • Use the username/password combination for a different service. If the developers were lazy and re-used these credentials somewhere, that may open up some other things
  • Use the username and / or the address 10.#.#.# for targeted social engineering attack towards the credential holder (if that is a person) or administrators

I'm no MSSQL user so I cannot give you any insight in the MSSQL-Specific part (maybe somebody else will provide an answer on that if that is necessary?).

  • Your top paragraph is way off. You're assuming the server is not multihomed and is connecting to an internal database. You're also assuming this test is not on a local network. Because the author stated "web based system" does not necessarily mean a web based system connected to the public Internet.
    – munkeyoto
    Dec 12, 2014 at 18:10
  • @munkeyoto How can an external attacker without direct access to the private Network connect to the database directly? Or is my English ambiguous? Or do you refer to the first sentence?
    – dst
    Dec 12, 2014 at 18:13
  • Let's say you're running a multihomed server (two networks one public, one private), if you get on access to the machine remotely from the public side, you can access pivot into the internal networks. Configurations like these are common in low LAMP environments, hence one of the reasons for metasploit having its pivoting functions. While you from the outside cannot access the Internal side, the machine itself has connections to both ends. Getting ONTO THAT MACHINE is the key. Once on the machine itself, you're free to roam to whatever 1918 address is configured on 2nd NIC
    – munkeyoto
    Dec 12, 2014 at 18:16
  • @munkeyoto I'm aware of the possibility, but is that still called direct, as you're basically routing through the multihomed server?
    – dst
    Dec 12, 2014 at 18:21
  • The moment you connect to a multihomed network it has "direct" access to whatever it is configured to have direct access for. In this instance he documents, there is the possibility that IF that machine is multihomed, that it has direct access via it's networking configuration to a 1918 address.
    – munkeyoto
    Dec 12, 2014 at 18:33

Just because you were not able to connect directly, this still poses a few problems (will speak on them in a second). Anything and all should always be reported for a few reasons, it is informational, it illustrates that time was taken to analyze information during an engagement. Now there are a few reasons I can think of, for this happening (permissions)"

  • 1) Developer took shortcuts (made permissions changes to ease his/her work)
  • 2) Developer could not get it to work otherwise and needed that permission (read all) to make it work

With the information in the configuration readable, depending on their structure, an attacker can likely use this to escalate privileges (depending on the configuration of accounts), access data otherwise meant to be private (e.g, logging into a SQL server elsewhere on the network given credentials were provided, etc).

Depending on what kind of engagement (black box pentest, white box pentest) you could ask the developer as to why this is configured as such, yet still report it, and offer the risks associated with having data stored/visible like that. It will all boil down to tolerance. For example: "You have access to this information to log into a machine WHILE ONLY on the server" albeit horrible to leak data, you cannot exploit any server to even use the data you found, so the risk is lower than if you EXPLOITED the server, then used that data.

I have done pentest engagements where data from robots.txt allowed me to escalate via chained attacks. E.g. config files and comments in pages pointed to other directories, which allowed me to connect dots to exploit something, and once I was in, I didn't need to escalate. Everything was handed to me usernames in comments, old configuration files with db names, hashes, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.