Finding Microsoft SQL Server Targets – SQL Attacks

After all the posts about attacking different parts of IT infrastructure, it seems impossible that we have never used nmap as a tool before. Nmap is one of the most reliable and well-known tools of the trade for attackers. More than that, it is used by security pros and IT admins for a huge number of tasks. In their own words, the makers of nmap say it is a “utility for network discovery and security auditing.” I think that sells it short by a long shot. We don’t have even a fraction of the time needed to cover everything nmap can do here – but you can literally read the book about it if you really want to know. We will focus on how we used it to scan our little lab network and find MS SQL in order to zero in for the attack. We could have used it for many other parts of this as well, but we will give some other tools a chance as well.

MS SQL will listen on a number of ports on the network to serve SQL requests. This may in include a “Browser” service that hands out connection information to anyone who requests it and a standard port (1433 by default) to answer transaction requests. Nmap will scan a given network for posts like this across a huge array of well-known services and (true to its name) map out what it finds. There are literally thousands of options you can feed into nmap, and the choices you make will affect how the scan runs in important ways. The scan we used to run our discovery was this:

nmap -sT -A -P0 169.254.7.6

A quick breakdown of this command is:

• -sT instructs nmap to attempt TCP connections to the open ports in order to gather more information. Specifically, it does this is a way that any user on the system where the scan originates is allowed to do. If you already had a privileged user on the originating system (e.g. root or Administrator), then you could run a raw packet scan that talks directly to the wire. Since most users cannot do this and we are assuming the least privileges possible in this fist attack phase, we use this lesser privileged approach. The down side of this is that savvy admins will watch for the type of TCP connects this approach uses and be able to tell they are being scanned.
• -A turns on the OS detection, version detection, script scanning, and traceroute features for the scan. Basically, this means “All” and throws the kitchen sink at the systems you are scanning.
• -P0 (that’s a zero) turns off ICMP pings. This is both a time saver since many systems won’t respond and a tactic to try and hide our actions a bit more.
• We have fed a specific IP to this command, but don’t be fooled into thinking you need to. I did this because my lab is tiny and it saved time, but you can set nmap loose on whole subnets, specific lists, and more. One of the most powerful aspects of nmap is its ability to scan just about any network.

The results of this scan give me this:

Host script results:

| ms-sql-info:
|   169.254.7.6:1433:
|     Version:
|       Product: Microsoft SQL Server 2012
|       name: Microsoft SQL Server 2012 RTM
|       Service pack level: RTM
|       number: 11.00.2100.00
|       Post-SP patches applied: false
|_    TCP port: 1433
|_nbstat: NetBIOS name: APP02, NetBIOS user: <unknown>, NetBIOS MAC: 00:15:5d:09:25:18 (Microsoft)
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_smbv2-enabled: Server supports SMBv2 protocol

This isn’t the complete results of the scan, just the results section. It reads out every attempt it makes that has any sensible reason for output. After all that noise, it summarizes the signal if finds as you see here. Because the scan wasn’t restricted to MS SQL, you see the results for the NetBIOS service as well. But the important bit for us is this gives us the fact that MS SQL is here, it’s on the default port, and it gives us the version and patch info about it as well. The MS SQL I have running on this host is pretty much default options in every case. So this is close to what you may expect to see on your systems if you were to run the same scan.

Taking Advantage of Soft Targets

Another widely used tool for initial stages of a compromise is medusa. Medusa is a multi-homed, brute force password cracker. Essentially, you feed it places to try lists of passwords, and it does so quickly and efficiently. It has modules for testing out passwords on a large number of platforms, and MS SQL is one of them. The command we ran against our systems looks like this:

medusa -h 169.254.7.6 -u sa -p DontUseThis -M mssql -e ns

As with nmap, it can be run against many systems at once, even though we only point it at my one system here. A quick break down of this command:

• -u specifies a user name to try. This can also be replaced with an explicit list or even a pointer to a file containing many user names. We are trying the ‘sa’ user since it is notorious for having a weak password set.
• -p specifies a password to try as a default. Again, we specified a specific one for convenience, but you can use a list or point to a file containing hundreds or thousands of possible passwords. The real trick is when you specify both a file containing usernames and another containing passwords. Medusa will then try each combination to see if any will get you to the promise land.
• -M specifies a module, in this case MSSQL
• -e is interesting. This tells medusa to try both a null password (n) and a password that is the same as the account name (s). In this case, it tries ‘sa’ as the password along with the empty string.

Here are the results when we run medusa against my MSSQL server:

ERROR: [mssql.mod] SQL server (169.254.7.6) did not respond to port query request. Using default value of 1433/tcp.

ACCOUNT CHECK: [mssql] Host: 169.254.7.6 (1 of 1, 0 complete) User: sa (1 of 1, 0 complete) Password:  (1 of 3 complete)

ACCOUNT CHECK: [mssql] Host: 169.254.7.6 (1 of 1, 0 complete) User: sa (1 of 1, 0 complete) Password: sa (2 of 3 complete)

ACCOUNT CHECK: [mssql] Host: 169.254.7.6 (1 of 1, 0 complete) User: sa (1 of 1, 0 complete) Password: DontUseThis (3 of 3 complete)

ACCOUNT FOUND: [mssql] Host: 169.254.7.6 User: sa Password: DontUseThis [SUCCESS]

What To Do Next For MS SQL Attacks – And Preventing Them

On my little lab network, we’ve found a MS SQL server running, we know a bit about its version and patching status, and we even know the sa password. In our next step for the blog, we’ll dive into the PowerUpSQL PowerShell toolkit to exploit the SQL Sever even more. It’s worth mentioning that we could have accomplished everything we did here with a similar toolkit called metasploit. Metasploit, similar to PowerUp SQL, would automate some of the choices we made here, as well as given us one unified toolkit to do what we did separately with nmap and medusa (also worth nothing is that nmap could have done most of what medusa did as well). All that is to say that there are lots of ways to achieve the kind of progress we made today, which should make you feel more push to see all this stuff mitigated in your own world.

The other question is how could we have stopped some or all of this from happening? At this level of the attack, we’re dealing with the meat and potatoes advice security pros will always give. Let’s run through that meal:

1. When you can, avoid running services like the “SQL Server Browser” that is there to explicitly hand out information attackers would like to get.
2. When possible, run services on alternate ports to make detecting them a little bit harder for the bad guys.
3. Monitor for TCP connect requests that don’t result in a valid connection or transaction. If you see a bunch of these in a small window of time, chances are you’re being scanned by a tool like nmap.
4. Use tools like nmap, medusa, and similar tools to regularly scan and asses your security posture. This is especially handy for finding instances of MS SQL that may have been put up without proper oversight and are broadcasting out insecure data.
5. If you choose to allow database authentication, make sure all the passwords, especially the sa password and other admin level ids, are complex and rotated often. When possible, use a vault technology to store and rotate those passwords to ensure a high level of security. When possible also use multi-factor authentication to protect these accounts.

Post #1: Attacking Microsoft SQL Server Databases

Learn about how STEALTHbits addresses SQL auditing and monitoring with StealthAUDIT for SQL here.

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

Name

Email*