A fun exercise in confidentiality vs authentication, and why “encrypted” doesn’t always mean secure.

360 Mobile Vision - 360mobilevision.com North & South Carolina Security products and Systems Installations for Commercial and Residential - $55 Hourly Rate. ACCESS CONTROL, INTRUSION ALARM, ACCESS CONTROLLED GATES, INTERCOMS AND CCTV INSTALL OR REPAIR 360 Mobile Vision - 360mobilevision.com is committed to excellence in every aspect of our business. We uphold a standard of integrity bound by fairness, honesty and personal responsibility. Our distinction is the quality of service we bring to our customers. Accurate knowledge of our trade combined with ability is what makes us true professionals. Above all, we are watchful of our customers interests, and make their concerns the basis of our business.

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.

By admin