0

I am practicing pen testing in a protected box and I have a vulnerable Magento website and I managed to get its MySQL config file which is app/etc/local.xml.

In this file there is information such as: 

<crypt>
    <key><![CDATA[414c9022922d31b62bbe4447356e4ed6]]></key>
</crypt>
<disable_local_modules>false</disable_local_modules>
<resources>
    <db>
        <table_prefix><![CDATA[]]></table_prefix>
    </db>
    <default_setup>
        <connection>
            <host><![CDATA[]]></host>
                <username><![CDATA[MYSQL_USERNAME]]></username>
                <password><![CDATA[MYSQL_PASSWORD]]></password>
                <dbname><![CDATA[DATABASE_NAME]]></dbname>
                <initStatements><![CDATA[SET NAMES utf8]]></initStatements>
                <model><![CDATA[mysql4]]></model>
                <type><![CDATA[pdo_mysql]]></type>
                <pdoType><![CDATA[]]></pdoType>
                <active>1</active>
        </connection>
    </default_setup>
</resources>
<session_save><![CDATA[files]]></session_save>

However, I found admin folder as well but do not have the login details. Only http and ssh ports are open. The SQL port is closed so remote access is not possible.

Apparently code injection is possible as on the default 404.php page I found a <script>alert('hacked')</script>

Apparently there are loads to do with <key><![CDATA[414c9022922d31b62bbe4447356e4ed6]]></key>. But I dont know how to use it.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Danny
  • 121
  • 5
  • Neither database credentials nor encryption keys do you any good without being able to directly access the database (which apparently you can't) or being able to execute your own code on the server (RCE - a remote code execution vulnerability). Apparently there is an **XSS** vulnerability (the alert you found), but that still doesn't let you run code on the server. So you need to find an SQLi vulnerability (in which case you may need the key to read data you extract) or a RCE so that you can run code and connect to the DB. In other words: keep hacking. – Conor Mancone Sep 24 '19 at 18:45

1 Answers1

1

Some things you can try:

  • Check for credential re-use. For example, can you log into the SSH server using the DB credentials?
  • Try to get code execution on the server. Since the web server obviously has access to the database, if you can launch another process with the web server's permissions, you should be able to access the DB from there.
  • Attempt SQL Injection (SQLi) attacks on the web application, which can be used to get at the contents of the database without ever directly connecting to it yourself.
  • Port-scan the server to see if the DB is perhaps listening on a non-standard port, or if there's some other vulnerable program listening on another port (a privileged debug service listening on 8080, for example).
  • Look up what the crypt key is used for (I'm not familiar with this system myself, but I'm sure the info is online) and see if it's anything useful like encrypting/signing authentication tokens (would let you spoof being an arbitrary user). This probably won't give you direct access to the DB, but might let you do something like access an administrator account in the web app and from there you can possibly access more data or find vulnerabilities in new attack surface.
CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • About the port scan if the ssh server is badly configured to allow all connection ports to be port forwarded, it could be possible to bypass possible firewall rules to maybe find and connect to the MySQL port if the MySQL port could not be found.. – Raymond Nijland Oct 03 '19 at 15:08