Protect your Software from the Zero Day Wget Vulnerability

While researching CVE-2024-38428 in GNU’s Wget, our team found a new 0-day vulnerability. The vulnerability, later assigned CVE-2024-10524, may lead to various types of attacks – including phishing, SSRF, and MiTM. These attacks can have severe consequences such as resource restriction bypass and sensitive information exposure.

Upon discovering this vulnerability, our team responsibly disclosed it to the Wget maintainers. A patch was released on November 11 and is included in Wget 1.25.0.

CVE-2024-10524 Overview

Wget is a popular program that is used to download content from servers and is part of the GNU project. It primarily supports the HTTP and FTP protocols.

In addition to normal URLs (e.g. http://user@host/file or ftp://host/file), Wget supported shorthand URL formats. For example, wget user@host/file would issue a request for http://user@host/file, and wget host:/file would issue a request for ftp://host/file. These two formats have been considered deprecated for quite some time now. They were originally introduced by NcFTP and Netscape, which is why Wget supported them.

It has been discovered that when using the HTTP shorthand format with user-provided input, unexpected behavior may occur. Wget might issue an FTP request to a different host – a potentially attacker-controlled host or a restricted host which the user normally does not have access to. This SSRF vulnerability can be the starting point for many types of attacks.

Which versions of Wget are affected?

CVE-2024-10524 is a medium severity vulnerability that affects any Wget version up to and including 1.24.5, with 1.25.0 including a fix for this issue. Users are recommended to update their Wget to version 1.25.0 to avoid this vulnerability.

Are you affected by CVE-2024-10524?

The CVE is only exploitable when a vulnerable Wget version is used and the attacker is able to control the credentials in a shorthand HTTP URL that is supplied to Wget. See the example below.

CVE-2024-10524 In-Depth Details and Exploitation

Consider an application that uses Wget to access a remote resource using shorthand HTTP, and passes the user’s credentials in the userinfo part of the URL. For example:

wget user_input@host/file

The application should sanitize the input, and make sure that it doesn’t contain characters that allow for command injection. However, it should allow the user to input a colon – a character which is allowed to be part of userinfo. But this may be dangerous. Let’s see what Wget does when receiving a URL like user:input@example.com/filename – which should issue an HTTP request for example.com, requesting the file filename.

Almost the first thing the program does after parsing the command line arguments, is checking if the URL provided to it is written in shorthand format. This is done in rewrite_shorthand_url, located in url.c. The function receives the URL, and returns either a full URL or NULL if the URL is not shorthanded. The function first checks if the URL is already in a normal, full format. It then searches for either a colon or a slash in the URL:



   char *
   rewrite_shorthand_url (const char *url)
   {
     const char *p;
     char *ret;
 
    if (url_scheme (url) != SCHEME_INVALID)
       return NULL;
 
    /* Look for a ':' or '/'.  The former signifies NcFTP syntax, the
        latter Netscape.  */
    p = strpbrk (url, ":/");
     if (p == url)
       return NULL;
 
    ...
   }

If a colon is found, Wget concludes that the URL is a shorthand FTP request (unless the colon is followed by a number representing a port). If a colon is not found, Wget converts the URL to an HTTP URL:



   if (p && *p == ':')
       {
         /* Colon indicates ftp, as in foo.bar.com:path.  Check for
            special case of http port number ("localhost:10000").  */
         int digits = strspn (p + 1, "0123456789");
         if (digits && (p[1 + digits] == '/' || p[1 + digits] == '\0'))
           goto http;

         /* Turn "foo.bar.com:path" to "ftp://foo.bar.com/path". */
         if ((ret = aprintf ("ftp://%s", url)) != NULL)
           ret[6 + (p - url)] = '/';
       }
     else
       {
       http:
         /* Just prepend "http://" to URL. */
         ret = aprintf ("http://%s", url);
       }

Thus, if Wget finds a colon anywhere in the URL, it considers it an FTP URL. So in our example, running wget user:input@example.com/file would issue an FTP request for the domain user, requesting the file input@example.com/file. This behavior is unexpected, and an attacker might utilize this to initiate an attack.

We have responsibly disclosed this vulnerability to Wget, and a patch has been released. The patch removes support for the FTP shorthand format, since it was already considered deprecated and is not supported by other tools which are similar to Wget.

As you can see in the examples section below, this vulnerability can lead to all kinds of dangerous attacks. However, we have decided to give it a Medium CVSS score. Note that using the HTTP shorthand format with user input is very uncommon, so exploitation of this CVE in real-world scenarios is unlikely.

CVE-2024-10524 Examples

Let’s take a look at a few examples and see how this vulnerability can be exploited.

SSRF

First, let’s see how this issue can lead to an SSRF (server-side request forgery) attack. Consider an app that connects to an external web server using a user’s username. So, for a user named myuser, the server would issue an HTTP request for myuser@myserver.

Notice how the user cannot and should not have any control over the domain name (myserver). Still, by utilizing this issue, an attacker could actually change it. For example, the attacker could buy the domain maliciousdomain, and then register as the user maliciousdomain:aaa. The URL in this case would be maliciousdomain:aaa@reliableserver. Wget would interpret this as an FTP shorthand URL, which would cause the request to be sent to maliciousdomain – the attacker’s domain.

This scenario gives the attacker the ability to perform an SSRF attack, by providing a malicious username to the app that will be used by Wget as the host to connect to. For example, the app might use Wget to download content from a remote URL and display it to the user. By exploiting this vulnerability the attacker is able to change the host in the URL that is used in Wget and obtain access to an internal address that is normally inaccessible externally. For example, a local server that stores sensitive PII information that is accessible only from an internal network.

The attack can be seen in the image below, where the request for the should be sent to reliableserver, but gets sent to maliciousdomain instead.

Phishing

Another example of where this vulnerability can be exploited is in a phishing attack. In this scenario, the attacker could have the victim make a request for a file from maliciousdomain:@reliableserver (note the colon before the @ sign). The victim, seeing the reliable hostname reliableserver, might trust this link. But as we have seen before, the link would actually turn the user to the attacker’s domain – maliciousdomain. The attacker could then provide the user with a malicious file that looks like it is reliable, but in fact executes malicious code when opened.

Man In The Middle

This vulnerability can also be used to initiate a MiTM attack. The attacker could supply a user with the link maliciousdomain:@reliableserver. The user, seeing the hostname reliableserver, might trust this link and use it. In reality however, the link would bring the user to maliciousdomain. Up until now, everything is the same as the phishing attack described before. In this scenario, however, the attacker could take it a step further by acting as a proxy between the user and reliableserver, effectively committing a man-in-the-middle attack.

Data Leakage

Finally, the vulnerability could also lead to data leakage. The app might provide the user with error logs if something fails. If this is the case, an attacker can cause the request to fail by supplying crafted credentials and leak the original hostname. Sensitive data can also be leaked by other forms of attacks like SSRF or MiTM.

How to resolve CVE-2024-10524?

A fixed Wget version which addresses this issue, 1.25.0, has already been released. Users are recommended to upgrade to it.

Is it possible to mitigate CVE-2024-10524 without upgrading?

It is possible to mitigate CVE-2024-10524 without upgrading or hurting Wget functionality, by converting all shorthand HTTP requests to their full format. For example, convert wget input@myserver to wget http://input@myserver or preferably to wget https://input@myserver if HTTPS is supported.

Is the JFrog Platform Vulnerable to CVE-2024-10524?

After conducting internal research, we can confirm that the JFrog Platform is not vulnerable to Wget’s CVE-2024-10524.

Stay up-to-date with JFrog Security Research

The security research team’s findings and research play an important role in improving the JFrog Software Supply Chain Platform’s application software security capabilities.

Follow the latest discoveries and technical updates from the JFrog Security Research team on our research website, and on X @JFrogSecurity.

CVE-2024-10524 Wget Zero Day Vulnerability