Category: Security

Fabiano Amorim offers some advice:

The SQL Server attack pattern is consistent: attackers do not always need a spectacular vulnerability. They often succeed by chaining normal features that were granted too broadly, trusted too much, or monitored too narrowly. 

In this article, I’ll focus on operational blind spots in SQL Server. These are the features DBAs use every day to keep SQL Server healthy: linked servers, traces, Dynamic Management Views, Extended Events, and session-management commands such as KILL.

These tools, while necessary, also create visibility, automation, and trust paths that attackers can abuse after compromising a low-privileged application account or a local database owner. 

Because of this, a SQL Server DBA should know the answer to the following questions at all times: where am I exposed, what should I monitor, and what should I change first? In this article, you’ll learn the answers to all three.

Click through for the advice.

Marlon Ribunal builds a checklist:

Here’s a follow up for our US Department of Defense STIG document. In my previous post, SQL Server Security Hardening Guide Using the DoD STIG Checklist, I walked through how I used the DoD STIG checklist as a starting point for reviewing and hardening a SQL Server environment.

After going through the checklist, I started thinking about what I would actually want to use the next time I perform a security review.

The DoD STIG for SQL Server is a great, solid starting point for establishing your security practices with SQL Server. In fact, it’s also a good template for your own STIG in your organization. So, you may want to create a custom checklist that makes sense from the perspective of your SQL Server environment.

The STIG is detailed, which is a good thing, but I found myself wanting something a little more practical for day-to-day DBA work. Something I could open, work through one item at a time, record what I found, and come back to later without having to navigate through the entire STIG document every time.

Click through to see what Marlon came up with.

Andreas Wolter shares some thoughts:

CISA recently published guidance on using cyber decoys, tripwires, breadcrumbs, and honeytokens to detect attackers who are already operating inside an environment: Using Cyber Decoys to Strengthen Detection and Response

Looking at this through my SQL Server lens, I think it is worth considering how these concepts can be applied to database systems.

Before building any kind of database honeypot, you need to ask yourself:

Click through for that list of questions, as well as additional thoughts from Andreas.

Fabiano Amorim explains a vulnerability:

SQL injection inside Microsoft-signed system stored procedures is not supposed to happen. Yet, as I’ve been documenting in this series, it happens more often than you may assume.

This article walks through another one I found and reported to the Microsoft Security Response Center (MSRC). It’s a textbook SQL injection sitting inside sys.sp_MSdeletefoldercontents, a system stored procedure used by SQL Server replication.

What makes it interesting is not the injection technique itself (there is no clever Unicode trick this time), but what it enables: a working execution path for xp_cmdshell on a server where xp_cmdshell is explicitly disabled by configuration.

Admittedly, I kind of shrug my shoulders at this one as well. You already need to be sysadmin, and sysadmins can enable xp_cmdshell whenever. I understand that the point of Fabiano’s post is that the procedure call ignores xp_cmdshell’s status, so there’s something to it. But I have trouble thinking that the SQL Server team made the wrong call in deciding it’s a low-risk vulnerability.

Andreas Wolter notes some security requirements:

Azure Arc for SQL Server comes with a so-called “least privilege mode.”

But certain Azure Arc components still execute SQL Server operations with sysadmin authority, which can expose that authority to database-scoped code.

Fabiano Amorim recently demonstrated how a database-scoped principal can take advantage of exactly this privileged execution context to escalate to sysadmin through a database-level DDL trigger: How Azure Arc allows a DB admin to become SQL Server sysadmin – the vulnerability explained

Fabiano covers the exploit itself in detail. What I want to put under the magnifying glass here is the “least privilege” mode itself – a topic I have written about extensively:

Click through for Andreas’s take on this.