If there are some unexploited MSSQL Servers With Weak Passwords Left: They got you now (again)

Published: 2017-04-26
Last Updated: 2017-04-26 15:38:51 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

Setting up a Microsoft SQL server with a stupid simple password like "sa" for the "sa" user is hard. First of all, Microsoft implemented a default password policy that you need to disable. And then, when you finally Googled your way through how to disable it and turned it off with the next password reset, then it will take only minutes for your brand new shiny SQL Server to get compromised. Today, we received a number of reports of a sudden increase in these scans against port 1433 . As far as I can tell from honeypot data, the attacks are nothing special or new, just more of them.

A little bit odd is the distribution in TTLs. I am still trying to see if this is just an artifact in how I collected the data. Since MSSQL typically runs on Windows, I would expect the scans to originate from Windows systems that got compromised by this bot/worm. But instead, the majority of TTLs are just short of 255. So not even the Unix "standard" 64.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
STI|Twitter|

3 comment(s)

Comments

Unix use a wide variety of TTL. Around to 2000 I did some OS identification research to lower the noise compared to what Nmap created when it did OS ID, and it worked out nicely (2 SYN packets sufficed). But I found a link of someone listing default TTLs for various OS'es: http://subinsb.com/default-device-ttl-values

Your TTL could be Solaris boxes? I mean the Solaris zero day (the one that got released recently) would be enough for a substantial bot net. Could also be FreeBSD (seem to recall something similar being released for that).
Could this be someone looking for exposed MSSQL Compact deployments on web servers?
I am not a user (nor a fan) of that MSSQL product, but IMHO it would be a somewhat plausible reason for this kind of a scan.
Just me brainstorming... could be something completely different.
Johannes - Regarding the TTL chart, it looks like the X-axis labels are skewed to the right (or the data is skewed to the left). The Windows TTL spike in the chart, if the actual value is 128, should be more to the right, just past the midway point of the 100-150 labels. I suspect then that the spike on the right is actually a TTL of 255.

Also, there are a number of Linux/OS variants running SQL Server now, which could help explain the TTL spikes.

https://www.microsoft.com/en-us/sql-server/sql-server-2017

Phil

Diary Archives