A fun exercise in confidentiality vs authentication, and why "encrypted" doesn't always mean secure.
Imagine the (common) scenario where some sort of service needs to interact with an MSSQL database. The client application opens a "secure" connection with MSSQL, sends over the username and password to authenticate, runs some queries, does its thing, wash, rinse repeat.
All the communication is encrypted so we're good right...? It all depends how you establish that "secure" connection between the client and server. It turns out, by default, MSSQL and the clients that connect to it use and trust self-signed certificates when doing SQL server authentication.
Once you realize this, the dominos start to fall. What this means is that if you're on the same network as a SQL server and you can conduct a man-in-the-middle attack, you can actually trick any clients that connect to that server (using SQL server authentication) to send you their credentials!
On a recent test, we ran into this exact scenario. Not much going on on the network except some MSSQL traffic so I decided to run with a hunch and see what would happen.
The first step was to identify the SQL server and setup Ettercap to ARP spoof traffic between the SQL server and the gateway. Easy enough - now the SQL server traffic is flowing through our machine.
Next we run Responder.py and have it enable it's SQL Server authentication listener. This spins up a "fake" SQL server that will log any credentials sent to it.
Finally - a simple IPTables rule to redirect traffic bound for the real DBMS to the listener running on our machine "iptables -t nat -A PREROUTING -p tcp --dport 1433 -j REDIRECT --to-ports 1433". This will break things. Any connections to the DBMS that are currently open will probably break, the client will try to re-authentication, we'll catch the creds.
SQL Server can then be used to pivot into the network/domain with xp_cmdshell, extract sensitive data etc...
The mitigation here is to use a strong password and Windows or Domain authentication for SQL server.
Imagine the (common) scenario where some sort of service needs to interact with an MSSQL database. The client application opens a "secure" connection with MSSQL, sends over the username and password to authenticate, runs some queries, does its thing, wash, rinse repeat.
All the communication is encrypted so we're good right...? It all depends how you establish that "secure" connection between the client and server. It turns out, by default, MSSQL and the clients that connect to it use and trust self-signed certificates when doing SQL server authentication.
Once you realize this, the dominos start to fall. What this means is that if you're on the same network as a SQL server and you can conduct a man-in-the-middle attack, you can actually trick any clients that connect to that server (using SQL server authentication) to send you their credentials!
On a recent test, we ran into this exact scenario. Not much going on on the network except some MSSQL traffic so I decided to run with a hunch and see what would happen.
The first step was to identify the SQL server and setup Ettercap to ARP spoof traffic between the SQL server and the gateway. Easy enough - now the SQL server traffic is flowing through our machine.
Next we run Responder.py and have it enable it's SQL Server authentication listener. This spins up a "fake" SQL server that will log any credentials sent to it.
Finally - a simple IPTables rule to redirect traffic bound for the real DBMS to the listener running on our machine "iptables -t nat -A PREROUTING -p tcp --dport 1433 -j REDIRECT --to-ports 1433". This will break things. Any connections to the DBMS that are currently open will probably break, the client will try to re-authentication, we'll catch the creds.
SQL Server can then be used to pivot into the network/domain with xp_cmdshell, extract sensitive data etc...
The mitigation here is to use a strong password and Windows or Domain authentication for SQL server.
We could perform a donwgrade attack and sniff a plain-text cred of a real SQL-server. Check this out, it works well.
ReplyDeletehttps://f0rki.at/microsoft-sql-server-downgrade-attack.html