![]() ![]() Second SQL Injection attempt: xp_dirtree + responder + hashcat The only content sqlmap is able to dump from the databases consists in the various products available on the website, so nothing interesting. If we add an “-a” or “–all” flag to the command above we can retrieve every information sqlmap can find from the database, including the content of all the databases, the current user, current database, passwords, and so on:įrom this part of the output we find out that our current user is called stacy and unfortunately said user isn’t part of the DBA (Database Administrator) group so we aren’t going to be able to read sensitive information such as passwords, in fact we can see this on another section of the output generated by sqlmap: So we can confirm that the Database Management System (DBMS) behind Giddy is Microsoft SQL Server (MSSQL) and we found the names of five databases hosted on the box. We can use this information to learn more from the database using sqlmap: $ sqlmap -u -dbs There is also yet another possible injection point, it being the GET parameter used to switch between categories on the website: Īdding a single quote will cause another SQL error signaling its vulnerability. From the developer tools we can see the name of the POST parameter we want to use to attack the web application is called “SearchTerm”: ![]() Surely enough the website is vulnerable and appears to be a test application to practice with SQL injection attacks, plus the error message gives us the name of one of the users on the box: jnogueira. Thinking a database backend could be behind this I try typing a single quote character in the textbox and see what happens, if the page returns an error the website is vulnerable to SQL injection: The website has a page to search for products: mvc on the other hand reveals a simple shopping website: remote shows a login page for PowerShell Web Access: Let’s rungobuster to see if it finds anything interesting: $ gobuster dir -w SecLists/Discovery/Web-Content/big.txt -t 50 -u Īspnet_client is a forbidden path as expected, /remote and /mvc are very interesting though. ![]() The source code doesn’t contain anything interesting either, but from the IIS version, 10.0, we can tell Giddy is running Windows 10 or Windows Server 2016. While the web server on port 443 provides an invalid SSL certificate making it impossible to connect to it the other port shows nothing but an image of a dog: We find two web servers running on ports 80 and 443, and a Windows terminal server on port 3389. Let’s start with a simple classic nmap scan to perform service enumeration (-sV) and to execute the list of default NSE scripts (-sC) and setting a nice speed (-T4). Root on the other hand is much more straightforward, a local privilege escalation exploit. It probably was a little bit easier for me than for some other players because I had already solved Querier some time before touching Giddy, with which it shares the NTLM authentication trigger through xp_dirtree, a very interesting undocumented MSSQL function that allows to list the content of a remote directory, we’ll use this to force the database into connecting to our box, thus providing its NTLM hash that we’ll crack to login on the system. Giddy was a very nice box, one of those where the path to user is more difficult than escalating privileges, as we’ll see.
0 Comments
Leave a Reply. |