The title says pretty much all that you need to know, the got HTTP request library for Node will follow redirects to a Unix socket. So an attacker who can invoke a request (SSRF) to a server they control could redirect that request back towards a unix socket on the local machine. The actual damage you could do with this would vary depending on what is available on the target server, but services running with a unix socket tend to be more privileged, like the docker management service is often exposed at unix:/var/run/docker.sock.

An attacker would already need some sort of SSRF issue to abuse this, but the idea of targeting unix sockets is not something I’ve considered before.

Research post that focuses on DNS resolvers, particularly closed resolvers. It’s commonly thought that closed DNS resolvers are inaccessible to the internet and thus unbreachable, but this isn’t entirely true. In this post, they look at email spam filter services and the requests that can be made via things like SPF, DKIM, and DMARC DNS queries. In many cases, it’s possible to get email-related DNS queries passed from the closed resolver to the email domain. In these cases, an attacker can send an email to a server with an “analysis” domain which can receive and analyze DNS queries from these closed resolvers. Sec consult uses this to probe for security features like source port randomization on a wide spectrum of domains.

In one domain they looked at, they found the distribution of source ports was static. After further analysis, they found it belonged to a hosting provider, and was also associated with an authoritative DNS (ADNS). They found hundreds of domains hosted on this ADNS, and found hundreds more domains using static ports. From there, they talk about some of the stuff you can attack via DNS cache poisoning internal resolvers through email queries, such as email spoofing by getting manipulated responses cached for SPF/DKIM/DMARC.

Multiple static functions inInetAddress like getByName and getAllByName can be used both to resolve a name string to an IP address, and to validate the format of an address. The problem is that the OpenJDK implementation does not properly validate the format of an IP address string. The problem comes from the handling of the % character, which for IPv6 is used to specify a zone index at the end of the address. The vulnerable functions use the private method checkNumericZone check this value. The problem is that the function doesn’t do much validation, simply checking for the location of the % character, and for the ] character which should indicate the end of the address, making sure there is atleast one character after that %. It does not validate that there are not characters after ].

This allows for various malformed IP addresses to be validated such as:

• 2606:4700:4700::1111%1]foo.bar baz'"
• [::1.1.1.1%1]foo.bar baz '"]

The authors do provide an example of how this code might be used to validate a host before including it in a ping command, though it does feel rather contrived. It is a little testcase that might be worth tossing into your lists.

This vulnerability builds on/is complicated by two past issues. The first being an RCE via caching of remote font files, we discussed this vulnerability on Episode 129. The core issue was that Dompdf would download remote font files and save them locally with the original file extension. So basically the ability to upload a .php file onto the server which may then be executed by the server. The second issue was that phar:// urls could be used in HTML element src attributes, and would be interpreted.

The patch for the first issue was just to ensure it only downloaded valid TrueType Font files and forced the .ttf extension, and wouldn’t download files by default. The second issue was patched by creating an allow list of protocols and phar:// being blocked by default. They found the patch for the second bug was insufficient in the registerFont(). It would check the allowlist and issue a warning, but it would continue executing even if the scheme was not allowed.

So they could get Dompdf to read a phar://, but they still needed to get one saved. They were able to use a data: URI with the font-face src attribute to save a file locally without downloading. The last remaining trick would be to generate a phar:// that was also a valid TTF.