Help with Rogue sql server for CSPP attack

[eyenit0]

Hi all,

So, I'm testing out a web app and found a CSPP vulnerability, as detailed here (http://www.blackhat.com/presentations/bh-dc-10/Alonso_Chema/Blackhat-DC-2010-Alonso-Connection-String-Parameter-Pollution-wp.pdf). Chema illustrates setting up a rogue SQL server and forcing the victim to connect to your server, while you sniff their windows credentials.
Whenever I set up a rogue server and force a connection, I don't get the goods from the victim. I set up Cain to sniff, as in the white paper, but nothing. I loaded up wireshark and see some NTLMSSP messages back and forth, but then my rogue server responds with "Login failed. The login is from an untrusted domain and cannot be used with Windows authentication."
The victim and rogue server are not on the same network or domain.

Does anyone know of a way to configure my rogue server to accept the victim domain and therefore capture the credentials? Thanks in advance!

[ajohnson]

What database server/version are you using (assuming a version of SQL Server)?

Is there any relevant information in the database logs?

This may provide some direction: http://support.microsoft.com/?ID=kb;en-us;Q247931

[eyenit0]

Thanks for the reply. The target server is SQL Server 2012. I've set up rogue servers with SQL 2005, 2008, and 2012 Express versions.
I'm in the process of setting up a SQL instance on a test domain controller with the same domain name as the target domain.

I wish there was a way to use the CSPP attack to cause the target server to send over it's SQL user credentials, not Windows,then this wouldn't be an issue, but I don't think that's possible.

I'll check out that link a little more and check the logs on this new server once I get it up and running. I'll post back after i find out more.

[eyenit0]

The error in the SQL log says:
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed. [CLIENT: xxx.xxx.xxx.xxx]

Even though I set this box up as a domain controller, the SQL instance still shows as COMPUTERNAME\sqlinstance instead of DOMAINNAME\sqlinstance.

The more I look at it, I think it may be a problem with DNS name mismatches. When I enter my IP as the data source on the victim's server, it seems to do a reverse DNS lookup and connect via the DNS name, which doesn't match the Active directory domain name of the system. So, it will try to connect to something like d-127-0-0-1.comcast.net\sqlinstance instead of DOMAINNAME\sqlinstance.

On the actual SQL/AD server, if I try to log into via SQL Management studio to d-127-0-0-1.comcast.net\sqlinstance, it gives me the same "untrusted domain" error.

I tried adding d-127-0-0-1.comcast.net to the hosts file and pointing it back to the server, but no change.

Sorry if this post makes no sense - I've been going at it all day and may be a little loopy.

[eyenit0]

So, I even emailed Chema and he verified that getting that error is normal, but even though it's an untrusted domain, you should still be able to grab the hashes before that error is raised. He suggested Cain for sniffing, but Cain isn't grabbing anything, even when I did a test connection with valid credentials and no error. I have the PCAP with the traffic, but can't pick out if there are any hashes.
Are there any other good sniffers out there for capturing SQL or NTLM credentials?
I ran the pcap through dsniff, but didn't get any results.

Looks like this is now moving more into the realm of network pen testing.

[ajohnson]

Thanks for the follow-up posts. I'm not familiar with this specific attack; sorry I can't be of more help.

If Cain's not seeing the hashes, they're probably not being sent. That's a basic exchange that Cain handles easily. I wouldn't spend time trying to find other tools; the problem probably lies elsewhere.

 

[eyenit0]

You're probably right. I guess proving the CSPP vulnerability is present will have to be enough for now. Thanks for your help.