Cybersecurity researchers have uncovered a novel malware campaign that leverages Google Sheets as a command-and-control (C2) mechanism.
The activity, detected by Proofpoint starting August 5, 2024, impersonates tax authorities from governments in Europe, Asia, and the U.S., with the goal of targeting over 70 organizations worldwide by means of a bespoke tool called Voldemort that's equipped to

Cybersecurity researchers have uncovered a novel malware campaign that leverages Google Sheets as a command-and-control (C2) mechanism.

The activity, detected by Proofpoint starting August 5, 2024, impersonates tax authorities from governments in Europe, Asia, and the U.S., with the goal of targeting over 70 organizations worldwide by means of a bespoke tool called Voldemort that's equipped to gather information and deliver additional payloads.

Targeted sectors include insurance, aerospace, transportation, academia, finance, technology, industrial, healthcare, automotive, hospitality, energy, government, media, manufacturing, telecom, and social benefit organizations.

The suspected cyber espionage campaign has not been attributed to a specific named threat actor. As many as 20,000 email messages have been sent as part of the attacks.

These emails claim to be from tax authorities in the U.S., the U.K., France, Germany, Italy, India, and Japan, alerting recipients about changes to their tax filings and urging them to click on Google AMP Cache URLs that redirect users to an intermediate landing page.

What the page does is inspect the User-Agent string to determine if the operating system is Windows, and if so, leverage the search-ms: URI protocol handler to display a Windows shortcut (LNK) file that uses an Adobe Acrobat Reader to masquerade as a PDF file in an attempt to trick the victim into launching it.

"If the LNK is executed, it will invoke PowerShell to run Python.exe from a third WebDAV share on the same tunnel (\\library\\), passing a Python script on a fourth share (\\resource\\) on the same host as an argument," Proofpoint researchers Tommy Madjar, Pim Trouerbach, and Selena Larson said.

"This causes Python to run the script without downloading any files to the computer, with dependencies being loaded directly from the WebDAV share."

The Python script is designed to gather system information and send the data in the form of a Base64-encoded string to an actor-controlled domain, after which it shows a decoy PDF to the user and downloads a password-protected ZIP file from OpenDrive.

The ZIP archive, for its part, contains two files, a legitimate executable "CiscoCollabHost.exe" that's susceptible to DLL side-loading and a malicious DLL "CiscoSparkLauncher.dll" (i.e., Voldemort) file that's sideloaded.

Voldemort is a custom backdoor written in C that comes with capabilities for information gathering and loading next-stage payloads, with the malware utilizing Google Sheets for C2, data exfiltration, and executing commands from the operators.

Proofpoint described the activity as aligned to advanced persistent threats (APT) but carrying "cybercrime vibes" owing to the use of techniques popular in the e-crime landscape.

"Threat actors abuse file schema URIs to access external file sharing resources for malware staging, specifically WebDAV and Server Message Block (SMB). This is done by using the schema 'file://' and pointing to a remote server hosting the malicious content," the researchers said.

This approach has been increasingly prevalent among malware families that act as initial access brokers (IABs), such as Latrodectus, DarkGate, and XWorm.

Furthermore, Proofpoint said it was able to read the contents of the Google Sheet, identifying a total of six victims, including one that's believed to be either a sandbox or a "known researcher."

The campaign has been branded unusual, raising the possibility that the threat actors cast a wide net before zeroing in on a small pool of targets. It's also possible that the attackers, likely with varying levels of technical expertise, planned to infect several organizations.

"While many of the campaign characteristics align with cybercriminal threat activity, we assess this is likely espionage activity conducted to support as yet unknown final objectives," the researchers said.

"The Frankensteinian amalgamation of clever and sophisticated capabilities, paired with very basic techniques and functionality, makes it difficult to assess the level of the threat actor's capability and determine with high confidence the ultimate goals of the campaign."

The development comes as Netskope Threat Labs uncovered an updated version of the Latrodectus (version 1.4) that comes with a new C2 endpoint and adds two new backdoor commands that allow it to download shellcode from a specified server and retrieve arbitrary files from a remote location.

"Latrodectus has been evolving pretty fast, adding new features to its payload," security researcher Leandro Fróes said. "The understanding of the updates applied to its payload allows defenders to keep automated pipelines properly set as well as use the information for further hunting for new variants."

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

Cyberattackers Exploit Google Sheets for Malware Control in Likely Espionage Campaign

As we head into the final third of 2024, we caught up with Talos' Nick Biasini to ask him about the biggest shifts and trends in the threat landscape so far. Turns out, he has two major areas of concern.

Thursday, August 29, 2024 14:00

Hello Talos followers. I’m back for my annual takeover of the Threat Source newsletter. First, an update on that killer sloth movie I was so excited about in August 2023. “Slotherhouse” debuted with an impressive $137,133 at the box office, with critics hailing its various set pieces such as “death by sleeping bag balcony trap” (read that again) and “a particularly gruesome use of hair straighteners.” 

Onto less grisly fare. In the times when I used to frequent the site formerly known as Twitter, my favorite account to follow was “Sorkinese” – a daily elocution safari with the wit and wisdom of Aaron Sorkin characters (mainly from The West Wing). Before Sorkinese’s well timed final tweet in July last year (“The internet people have gone crazy!”) one piece of Sorkin dialogue that I always enjoyed seeing on the feed was “What kind of day has it been?.” The Wingnuts amongst you will know that Sorkin used this as the title of key episodes in several of his shows. It’s meant to signal the end of something, and a reflection of what’s important.  

As summer is drawing to a close and “sweater weather” begins again in earnest, I wanted to use this opportunity to reflect a little…what kind of summer has it been? 

I live in the UK, so “wet” is the first word that comes to mind. But since I allegedly work in the security industry, and this is allegedly a security newsletter, I’ll steer things in that direction. In a "here's what I made earlier" moment (hello to the small percentage of Brits who will get that reference), this is a video which features Talos’ Head of Outreach Nick Biasini. We asked him to reflect on his two biggest areas of concern/importance in the threat landscape right now: 

One more quick thing – it’s now a week until we launch our new documentary, “The Light We Keep: A Project PowerUp Story.” This video will explore first-hand accounts of the chaos and consequences of electronic warfare, and how we developed a solution to maintain reliable power in the event of GPS jamming on Ukraine's electrical grid.

Keep an eye on our social channels for its release and be sure to join us for the live online launch event which will include a Q & A with myself, Joe Marshall, Matt Watchinski, and Matt Olney. 

Register for the livestream on September 5th 

Watch The Light We Keep trailer 

**The one big thing **

 BlackByte is a ransomware-as-a-service (RaaS) group believed to be an offshoot of the infamous Conti ransomware group. They have continued to leverage tactics, techniques and procedures (TTPs) that have formed the foundation of its tradecraft since its inception, continuously iterating its use of vulnerable drivers to bypass security protections and deploying a self-propagating, wormable ransomware encryptor. In recent investigations, Cisco Talos Incident Response (Talos IR) has also observed BlackByte using techniques that depart from their established tradecraft. Members of the team, in collaboration with Talos Intelligence and Interdiction, wrote a blog detailing their findings. 

** Why do I care? **

 During an investigation of a recent BlackByte attack, Talos IR and Talos threat intelligence personnel noted close similarities between indicators of compromise (IOCs) discovered during the investigation and other events flagged in Talos’ global telemetry. Further investigation of these similarities provided additional insights into BlackByte’s current tradecraft and revealed that the group has been significantly more active than would appear from the number of victims published on its data leak site. 

**So now what? **

 Talos IR has provided a full set of recommendations to help defenders protect against RAAS groups such as BlackByte. Including how to detect lateral movement. You’ll find these recommendations in the blog, alongside the MITRE ATT&CK mapping of new TTPs, and Indicators of Compromise. 

**Top security headlines of the week **

*   Hundreds of open-source large language model (LLM) builder servers and dozens of vector databases are leaking highly sensitive information to the open Web. Dark Reading 
*   A recent Qilin ransomware attack targeted credentials that were stored in Google Chrome browsers on a portion of the impacted network’s endpoints. Researchers said the move is an “unusual tactic, and one that could be a bonus multiplier for the chaos already inherent in ransomware situations.” Decipher 
*   Labor Day warning: Protect your date with these high-tech travel tips. Talos’ Nick Biasini recently gave advice on how to spot travel related phishing emails, and how to be aware of vulnerable Bluetooth connections and WIFI spots. Share with your friends and family! ABC News 

**Can’t get enough Talos? **

Talos’ Kelly Patterson just released a 3-part blog series of her research into the intricacies of fuzzing µC/OS protocol stacks. Kelly hopes her research will encourage more widespread use of fuzzing of RTOS software components.  

Check out the series below: 

*   Part 1: HTTP server fuzzing 
*   Part 2: Handling multiple requests per test case  
*   Part 3: TCP/IP server fuzzing, implementing a TAP driver  

**Upcoming events where you can find Talos **

Live launch of The Light We Keep documentary, followed by Q & A (Sept. 5th) 

Online 

BSides Krakow (Sept. 14)   

Krakow, Poland  

LABScon (Sept. 18 - 21)  

Scottsdale, Arizona 

VB2024 (Oct. 2 - 4) 

Dublin, Ireland 

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

**SHA 256:** a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  

MD5: 7bdbd180c081fa63ca94f9c22c457376 

Typical Filename: c0dwjdi6a.dll 

Claimed Product: N/A  

Detection Name: Trojan.GenericKD.33515991 

**SHA 256**:9ef2e8714e85dcd116b709894b43babb4a0872225ae7363152013b7fd1bc95bc 

**MD5:** 4813fa6d610e180b097eae0ce636d2aa 

**Typical Filename:** xmrig.exe 

**Claimed Product:** XMRig 

**Detection Name:** Trojan.GenericKD.70491190 

**SHA 256:** 24283c2eda68c559f85db7bf7ccfe3f81e2c7dfc98a304b2056f1a7c053594fe

**MD5:** 49ae44d48c8ff0ee1b23a310cb2ecf5a

**Typical Filename:** nYzVlQyRnQmDcXk

**Claimed Product:** N/A

**Detection Name:** Win.Dropper.Scar::tpd

**SHA 256:** c67b03c0a91eaefffd2f2c79b5c26a2648b8d3c19a22cadf35453455ff08ead0

**MD5:** 8c69830a50fb85d8a794fa46643493b2

**Typical Filename:** AAct.exe

**Claimed Product:** N/A

**Detection Name:** PUA.Win.Dropper.Generic::1201

What kind of summer has it been?

Online Graduate Tracer System version 1.0.0 suffers from an insecure direct object reference vulnerability.

**Online Graduate Tracer System 1.0.0 Insecure Direct Object Reference**

Posted Aug 29, 2024

Authored by indoushka

Online Graduate Tracer System version 1.0.0 suffers from an insecure direct object reference vulnerability.

tags | exploit

SHA-256 | 0abd7e5d887d9e2204c565886d418ad0656b2616bb80e508761e6e23aa8bf66f

Download | Favorite | View

**Online Graduate Tracer System 1.0.0 Insecure Direct Object Reference**

    =============================================================================================================================================| # Title     : Online Graduate Tracer System V 1.0.0 IDOR Vulnerability                                                                    || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 128.0.3 (64 bits)                                                            || # Vendor    : https://www.sourcecodester.com/sites/default/files/download/oretnom23/tracking.zip                                          |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Direct Object Reference : leads to the creation of a new admin.[+] use payload : /admin/user_ad.php or /admin/homead.php[+] http://127.0.0.1/tracking/admin/user_ad.phpGreetings to :============================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * CraCkEr |==========================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,590)
*   Arbitrary (16,908)
*   BBS (2,859)
*   Bypass (1,880)
*   CGI (1,034)
*   Code Execution (7,844)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,413)
*   DoS (25,127)
*   Encryption (2,389)
*   Exploit (53,324)
*   File Inclusion (4,266)
*   File Upload (1,001)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,244)
*   Local (14,809)
*   Magazine (587)
*   Overflow (13,180)
*   Perl (1,435)
*   PHP (5,228)
*   Proof of Concept (2,397)
*   Protocol (3,733)
*   Python (1,649)
*   Remote (31,707)
*   Root (3,639)
*   Rootkit (529)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,033)
*   Shell (3,282)
*   Shellcode (1,217)
*   Sniffer (903)
*   Spoof (2,279)
*   SQL Injection (16,630)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,027)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,270)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,941)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,657)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,783)
*   UNIX (9,443)
*   UnixWare (187)
*   Windows (6,679)
*   Other

Online Graduate Tracer System 1.0.0 Insecure Direct Object Reference

Online Appointment System version 1.0 suffers from an ignored default credential vulnerability.

**Online Appointment System 1.0 Insecure Settings**

Posted Aug 29, 2024

Authored by indoushka

Online Appointment System version 1.0 suffers from an ignored default credential vulnerability.

tags | exploit

SHA-256 | d5e851d5d33d2e7f80f5f84bed4e54f5abf704b307cd6b2d6284ec6e7d940a3c

Download | Favorite | View

**Online Appointment System 1.0 Insecure Settings**

    ====================================================================================================================================| # Title     : Online Appointment System v1.0 Insecure Settings Vulnerability                                                     || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                   || # Vendor    : https://www.sourcecodester.com/php/14502/online-appointment-system-php-full-source-code-2020.html                  |====================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Settings : appears to leave a default administrative account in place post installation.[+] use payload : user =  admin & pass = admin123[+] https://www/127.0.0.1/yorubanwitness000webhostappcom/admin/Greetings to :==================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R |================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,590)
*   Arbitrary (16,908)
*   BBS (2,859)
*   Bypass (1,880)
*   CGI (1,034)
*   Code Execution (7,844)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,413)
*   DoS (25,127)
*   Encryption (2,389)
*   Exploit (53,324)
*   File Inclusion (4,266)
*   File Upload (1,001)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,244)
*   Local (14,809)
*   Magazine (587)
*   Overflow (13,180)
*   Perl (1,435)
*   PHP (5,228)
*   Proof of Concept (2,397)
*   Protocol (3,733)
*   Python (1,649)
*   Remote (31,707)
*   Root (3,639)
*   Rootkit (529)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,033)
*   Shell (3,282)
*   Shellcode (1,217)
*   Sniffer (903)
*   Spoof (2,279)
*   SQL Injection (16,630)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,027)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,270)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,941)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,657)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,783)
*   UNIX (9,443)
*   UnixWare (187)
*   Windows (6,679)
*   Other

Online Appointment System 1.0 Insecure Settings

Multi-Vendor Online Groceries Management System version 1.0 suffers from an ignored default credential vulnerability.

**Multi-Vendor Online Groceries Management System 1.0 Insecure Settings**

Posted Aug 29, 2024

Authored by indoushka

Multi-Vendor Online Groceries Management System version 1.0 suffers from an ignored default credential vulnerability.

tags | exploit

SHA-256 | cd8e33861bcd681954a3b899d067996fd35799bcecc9ac6f0764304867a5ecb8

Download | Favorite | View

**Multi-Vendor Online Groceries Management System 1.0 Insecure Settings**

    =============================================================================================================================================| # Title     : Multi-Vendor Online Groceries Management System v1.0 Insecure Settings Vulnerability                                        || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                            || # Vendor    : https://www.sourcecodester.com/php/15166/multi-vendor-online-groceries-management-system-phpoop-free-source-code.html       |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Settings : appears to leave a default administrative account in place post installation.[+] use payload : user =  admin & pass = admin123[+] https://www/127.0.0.1/yorubanwitness000webhostappcom/admin/Greetings to :==================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R |================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,590)
*   Arbitrary (16,908)
*   BBS (2,859)
*   Bypass (1,880)
*   CGI (1,034)
*   Code Execution (7,844)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,413)
*   DoS (25,127)
*   Encryption (2,389)
*   Exploit (53,324)
*   File Inclusion (4,266)
*   File Upload (1,001)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,244)
*   Local (14,809)
*   Magazine (587)
*   Overflow (13,180)
*   Perl (1,435)
*   PHP (5,228)
*   Proof of Concept (2,397)
*   Protocol (3,733)
*   Python (1,649)
*   Remote (31,707)
*   Root (3,639)
*   Rootkit (529)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,033)
*   Shell (3,282)
*   Shellcode (1,217)
*   Sniffer (903)
*   Spoof (2,279)
*   SQL Injection (16,630)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,027)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,270)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,941)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,657)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,783)
*   UNIX (9,443)
*   UnixWare (187)
*   Windows (6,679)
*   Other

Multi-Vendor Online Groceries Management System 1.0 Insecure Settings

Single sign-on systems from several Big Tech companies are being incorporated into deepfake generators, WIRED found. Discord and Apple have started to terminate some developers’ accounts.

Major technology companies, including Google, Apple, and Discord, have been enabling people to quickly sign up to harmful “undress” websites, which use AI to remove clothes from real photos to make victims appear to be “nude” without their consent. More than a dozen of these deepfake websites have been using login buttons from the tech companies for months.

A WIRED analysis found 16 of the biggest so-called undress and “nudify” websites using the sign-in infrastructure from Google, Apple, Discord, Twitter, Patreon, and Line. This approach allows people to easily create accounts on the deepfake websites—offering them a veneer of credibility—before they pay for credits and generate images.

While bots and websites that create nonconsensual intimate images of women and girls have existed for years, the number has increased with the introduction of generative AI. This kind of “undress” abuse is alarmingly widespread, with teenage boys allegedly creating images of their classmates. Tech companies have been slow to deal with the scale of the issues, critics say, with the websites appearing highly in search results, paid advertisements promoting them on social media, and apps showing up in app stores.

“This is a continuation of a trend that normalizes sexual violence against women and girls by Big Tech,” says Adam Dodge, a lawyer and founder of EndTAB (Ending Technology-Enabled Abuse). “Sign-in APIs are tools of convenience. We should never be making sexual violence an act of convenience,” he says. “We should be putting up walls around the access to these apps, and instead we're giving people a drawbridge.”

The sign-in tools analyzed by WIRED, which are deployed through APIs and common authentication methods, allow people to use existing accounts to join the deepfake websites. Google’s login system appeared on 16 websites, Discord’s appeared on 13, and Apple’s on six. X’s button was on three websites, with Patreon and messaging service Line’s both appearing on the same two websites.

WIRED is not naming the websites, since they enable abuse. Several are part of wider networks and owned by the same individuals or companies. The login systems have been used despite the tech companies broadly having rules that state developers cannot use their services in ways that would enable harm, harassment, or invade people’s privacy.

After being contacted by WIRED, spokespeople for Discord and Apple said they have removed the developer accounts connected to their websites. Google said it will take action against developers when it finds its terms have been violated. Patreon said it prohibits accounts that allow explicit imagery to be created, and Line confirmed it is investigating but said it could not comment on specific websites. X did not reply to a request for comment about the way its systems are being used.

In the hours after Jud Hoffman, Discord vice president of trust and safety, told WIRED it had terminated the websites’ access to its APIs for violating its developer policy, one of the undress websites posted in a Telegram channel that authorization via Discord was “temporarily unavailable” and claimed it was trying to restore access. That undress service did not respond to WIRED’s request for comment about its operations.

**Rapid Expansion**

Since deepfake technology emerged toward the end of 2017, the number of nonconsensual intimate videos and images being created has grown exponentially. While videos are harder to produce, the creation of images using “undress” or “nudify” websites and apps has become commonplace.

“We must be clear that this is not innovation, this is sexual abuse,” says David Chiu, San Francisco’s city attorney, who recently opened a lawsuit against undress and nudify websites and their creators. Chiu says the 16 websites his office’s lawsuit focuses on have had around 200 million visits in the first six months of this year alone. “These websites are engaged in horrific exploitation of women and girls around the globe. These images are used to bully, humiliate, and threaten women and girls,” Chiu alleges.

Harmful 'Nudify' Websites Used Google, Apple, and Discord Sign-On Systems

Multiple media reports this week warned Americans to be on guard against a new phishing scam that arrives in a text message informing recipients they are not yet registered to vote. A bit of digging reveals the missives were sent by a California political consulting firm as part of a well-meaning but potentially counterproductive get-out-the-vote effort that had all the hallmarks of a phishing campaign.

Multiple media reports this week warned Americans to be on guard against a new phishing scam that arrives in a text message informing recipients they are not yet registered to vote. A bit of digging reveals the missives were sent by a California political consulting firm as part of a well-meaning but potentially counterproductive get-out-the-vote effort that had all the hallmarks of a phishing campaign.

Image: WDIV Detroit on Youtube.

On Aug. 27, the local Channel 4 affiliate **WDIV** in Detroit warned about a new SMS message wave that they said could prevent registered voters from casting their ballot. The story didn’t explain how or why the scam could block eligible voters from casting ballots, but it did show one of the related text messages, which linked to the site **all-vote.com**.

“We have you in our records as not registered to vote,” the unbidden SMS advised. “Check your registration status & register in 2 minutes.”

Similar warnings came from an ABC station in Arizona, and from an NBC affiliate in Pennsylvania, where election officials just issued an alert to be on the lookout for scam messages coming from all-vote.com. Some people interviewed who received the messages said they figured it was a scam because they knew for a fact they _were_ registered to vote in their state. WDIV even interviewed a seventh-grader from Canada who said he also got the SMS saying he wasn’t registered to vote.

Someone trying to determine whether all-vote.com was legitimate might visit the main URL first (as opposed to just clicking the link in the SMS) to find out more about the organization. But visiting all-vote.com directly presents one with a login page to an online service called bl.ink. DomainTools.com finds all-vote.com was registered on July 10, 2024. Red flag #1.

The information requested from people who visited votewin.org via the SMS campaign.

Another version of this SMS campaign told recipients to check their voter status at a site called **votewin.org**, which DomainTools says was registered July 9, 2024. There is little information about who runs votewin.org on its website, and the contact page leads to generic contact form. Red Flag #2.

What’s more, Votewin.org asks visitors to supply their name, address, email address, date of birth, mobile phone number, while pre-checking options to sign the visitor up for more notifications. Big Red Flag #3.

Votewin.org’s Terms of Service referenced a California-based voter engagement platform called **VoteAmerica LLC.** The same voter registration query form advertised in the SMS messages is available if one clicks the “check your registration status” link on voteamerica.org.

VoteAmerica founder **Debra Cleaver** told KrebsOnSecurity the entity responsible for the SMS campaigns telling people they weren’t registered is **Movement Labs**, a political consulting firm in San Francisco.

Cleaver said her office had received several inquiries about the messages, which violate a key tenet of election outreach: Never tell the recipient what their voter status may be.

“That’s one of the worst practices,” Cleaver said. “You never tell someone what the voter file says because voter files are not reliable, and are often out of date.”

Reached via email, Movement Labs founder **Yoni Landau** said the SMS campaigns targeted “underrepresented groups in the electorate, young people, folks who are moving, low income households and the like, who are unregistered in our databases, with the intent to help them register to vote.”

Landau said filling out the form on Votewin.org merely checks to see if the visitor is registered to vote in their state, and then attempts to help them register if not.

“We understand that many people are jarred by the messages – we tested hundreds of variations of messages and found that these had the largest impact on someone’s likelihood to register,” he said. “I’m deeply sorry for anyone that may have gotten the message in error, who is registered to vote, and we’re looking into our content now to see if there are any variations that might be less certain but still as effective in generating new legal registrations.”

Cleaver said Movement Labs’ SMS campaign may have been incompetent, but it wasn’t malicious.

“When you work in voter mobilization, it’s not enough to want to do good, you actually need to be good,” she said. “At the end of the day the end result of incompetence and maliciousness is the same: increased chaos, reduced voter turnout, and long-term harm to our democracy.”

To register to vote or to update your voter registration, visit vote.gov and select your state or region.

When Get-Out-The-Vote Efforts Look Like Phishing

This time, I’ll discuss why this approach is more challenging than simply substituting a socket file descriptor with a typical file descriptor.

Wednesday, August 28, 2024 12:00

So far in this series, I’ve developed a fuzzer for the µC/HTTP-server. As described in the previous post, this fuzzer reads from a file to enable compatibility with AFL++. That implementation only fuzzes a single request at a time. Although that single request fuzzer uncovered a few security vulnerabilities, there are complex and interesting object interactions and internal state transitions that occur when multiple requests are received in a single session. 

I wanted to be able to fuzz those interactions and transitions by providing a single test case file containing multiple requests. So, this time, I’ll discuss why this approach is more challenging than simply substituting a socket file descriptor with a typical file descriptor, and I’ll describe the feature I added to the open-source library libdesock to support multiple requests.

**Reading from a socket vs. reading from a file**

It’s a bit confusing thinking about solving this problem because socket communication is two-way communication with a request-response pattern, while reading from a file occurs one way. In a networking client/server model, the client will typically make a request of the server, and the server will respond before the client sends another request. 

The µC/HTTP-server works in a single thread so it completely processes and responds to the first request before ever reading from the socket descriptor for a second time. 

Our goal is to simulate multiple requests from the client using a single test case file. But what happens if we include two requests within the same test case file? The server code will read the available data from the file until it reaches EOF or fills the buffer.

For instance, suppose a test case file contains two complete HTTP requests. The buffer size of the µC/HTTP-server is 1,460 bytes and the length of our two requests combined are only 841 bytes. This means the entire test case fits within the buffer and is read into memory at once. The µC/HTTP-server will process the first HTTP request and then discard the remaining data in the buffer. Then, when the server code reads from the test case file again, it will have reached EOF while only actually processing the first request. 

To address this, we need a way to instruct the server to stop reading the file after processing the first request. This can be achieved by using a delimiter in the test case file. The delimiter should be a unique value that is unlikely to appear anywhere else in the request.

**libdesock **

To implement this strategy of using a delimiter to indicate where one request ends and another begins, I added a feature to an existing library called libdesock. The purpose of this library is to de-socket a network application to enable fuzzing. This is because fuzzers typically provide their test inputs via stdin while network applications expect their inputs from network connections. Typically, a network server application will call the libc functions socket, listen, accept and then read/recv. 

Libdesock operates by leveraging the Linux dynamic linker feature, LD_PRELOAD. When the LD_PRELOAD environment variable is set to the path of a shared object file, it instructs the dynamic linker to load that shared object before all others. As a result, when the dynamic linker searches for a symbol being called in the executable, it will first look in the shared object specified by the LD_PRELOAD environment variable. Normally, the symbols for the functions socket, listen, accept and read/recv are found within libc.so and executed from there. However, when LD_PRELOAD is set to libdesock.so, those symbols are found within the libdesock library and executed there instead. This allows libdesock to alter the behavior of those calls. By intercepting these calls, libdesock cleverly redirects recv/read to stdin rather than a network socket.

**Multiple request feature**

Originally, the libdesock code would read up to the size of the buffer used from stdin. This leads to the same issue as mentioned above when attempting to read multiple requests from an input file (stdin in this case): 

> “For instance, suppose a test case file contains two complete HTTP requests. The buffer size of the µC/HTTP-server is 1460 bytes and the length of our two requests combined are only 841 bytes. This means the entire test case fits within the buffer and is read into memory at once. The µC/HTTP-server will process the first HTTP request and then discard the remaining data in the buffer. Then, when the server code reads from the test case file again it will have reached EOF while only actually processing the first request.” 

To address this, I added a feature to the libdesock read code to look for a request delimiter while reading. If the delimiter is found, it returns all the data read before encountering the delimiter. On the next call to read, it will begin reading after the delimiter and search for another delimiter. This approach works for fuzzing multiple requests in most networked applications because these applications typically run a processing loop where read/recv is called, the data is processed, and then read/recv is called again. This loop continues until the connection is closed. As mentioned in the first blog post, it was necessary to modify the executable for fuzzing so that it would exit when read returns 0. This is crucial for fuzzing, as it indicates the executable has finished processing the test case and has exited normally. If you’d like to see the code, you can check out libdesock here.

**Vulnerability highlight**

This version of the µC/HTTP-server fuzzer, which supports multiple requests per test case, uncovered two additional vulnerabilities. In both instances, a vulnerability in the processing of the first request is exploited by the second request.

When disclosing these vulnerabilities, I discovered that much of the µC/HTTP-server codebase is shared across multiple products. The other affected products are the Silicon Labs Gecko Platform and Weston Embedded Cesium NET. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:203:1 and 119:282:1. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

Below is an overview of each vulnerability.

**TALOS-2023-1726**

When processing the protocol version portion of an HTTP request, an integer underflow occurs, which leads to an extremely large value within the connection object’s buffer length p_conn->RxBufLenRem. In the next iteration of the processing loop, that large value is used as an argument when calling receive. This means that the next request wouldn’t be limited by the max buffer size (1,460 bytes), and an attacker could overflow the receive buffer directly with the second request. 

**TALOS-2023-1732**

In this vulnerability, a buffer overflow of one byte occurs when handling the header fields in an HTTP request. This one-byte overflow is significant because the µC/HTTP-server heap implementation stores a pointer to a free chunk of memory in the first four bytes of an allocation. This means that the one byte overwrite can modify the free chunk address which will be used as an allocation sometime in the future. Abusing this vulnerability required four requests. The first two were innocuous and caused specific heap allocations to occur (a technique known as “heap grooming”). The one-byte overwrite is triggered by the third request, while the fourth request leads to an improper allocation in the heap.

Both vulnerabilities involved modifications to global objects between requests. These types of interactions can be difficult to understand with static code analysis because it is not always obvious the order that functions will be called under specific circumstances. There are more of these types of complex vulnerabilities out there that could be revealed with multi-request fuzzing and I hope that using this file delimiter technique will lead to more of them being found and fixed. 

In Part 3, I write a TAP device driver to fuzz the µCOS TCP/IP implementation.

Fuzzing µCOS protocol stacks, Part 2: Handling multiple requests per test case

Any vulnerability in an RTOS has the potential to affect many devices across multiple industries.

Wednesday, August 28, 2024 12:00

This is the first post of a three-part series, where we will be delving into the intricacies of fuzzing µC/OS protocol stacks. The techniques I will discuss are universally applicable to various RTOS environments, though our focus will primarily be on µC/OS. 

I’ll highlight some of the strategic code modifications I implemented across different µC/OS components. The objective is to streamline the process of developing a fuzzing harness tailored for the µC/HTTP-server. In the second installment of this series, I’ll discuss a technique that I used for delivering multiple requests per fuzz test case. The third post will be like this one, as I’ll describe the code modifications that I made with the aim of fuzzing the µC/TCP-IP stack.

For a bit of context, µC/OS is an RTOS, or “Real-Time Operating System.” An RTOS is a specialized operating system designed to manage hardware resources and host applications that need to run in systems where timing is critical, such as in embedded systems, medical devices, or industrial controls. RTOSes haven’t been fuzzed as thoroughly as software that runs on desktop operating systems, primarily due to the complexities associated with setting up a fuzzing harness for these systems. 

Developing a harness for an RTOS requires more coding effort than what is typically required for a straightforward, single-line fuzzing harness used with desktop applications or libraries. 

Any vulnerability in an RTOS has the potential to affect many devices across multiple industries. It’s important to put these codebases through the same rigorous testing as is common for desktop operating systems. My hope is that the techniques described in this blog post series will encourage more widespread use of fuzzing of RTOS software components. 

Historically fuzzing RTOS code involved a custom hardware setup to fuzz the code in its native environment, or fuzzing on an emulated version of the system. However, when Weston Embedded made the full µC/OS source code openly available in 2020, it sparked my curiosity about whether there could be a less complex approach to fuzz this type of code.

The goals for my fuzzer are:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case (more on this in part 2).

Additionally, the constraints (self-imposed) for my HTTP fuzzer are:

*   A software-only solution.
*   Run natively on Linux.

With that in mind, I wanted to avoid using emulation or dedicated hardware for my fuzzer.

**Linux port**

To make use of a modern fuzzing framework like AFL++, I needed to write some code that would allow the µC/HTTP-server to operate on Linux instead of the native µC/OS kernel. However, I had to give some thought to what exactly I wanted my fuzzer to target and determine appropriate insertion points for my hooks that would enable this protocol implementation to run on Linux.

Below is a basic architecture diagram showing the software component structure of a µC/HTTP-server application. The blue highlight represents the components that I will be modifying to port the application to Linux. The orange highlight represents the code which is the target for the fuzzer.

The modular design of µC/OS makes it wonderful to work with for this type of fuzzing. The Kernel Abstraction Layer (KAL in the diagram) provides a common API that is utilized by each of their libraries. This makes it easy to create a custom KAL that either mimics the desired RTOS functionalities for my fuzzer or simply returns a success signal for features that aren't relevant to the fuzzing process. Although µC/OS provides a POSIX-compatible KAL that enables the µC/HTTP-server to run on Linux, I chose to create my own KAL interface to simplify the entire setup. 

The KAL lays out an API blueprint for operating system components like task management, locks, semaphores, timers, and message queues. In the case of µC/HTTP-server, the only KAL function it calls is KAL_TaskCreate, which means I only needed to implement this particular function in my custom KAL interface. Additionally, since the task in question is the main HTTP processing loop, I found a workaround by directly invoking the function itself within the KAL_TaskCreate function, bypassing the need for a more complex task creation process. Example code below:

    void  KAL_TaskCreate (KAL_TASK_HANDLE     task_handle,
                          void              (*p_fnct)(void  *p_arg),
                          void               *p_task_arg,
                          CPU_INT08U          prio,
                          KAL_TASK_EXT_CFG   *p_cfg,
                          RTOS_ERR           *p_err)
    {
        /* return success  */
        *p_err = RTOS_ERR_NONE;
        /* fake it and call the function */
        p_fnct(p_task_arg);
        return;
    }

**Networking port****Socket reads**

Much like the Linux port mentioned earlier, there is a network abstraction called NetSock within µC/OS's TCP/IP protocol suite which is like a POSIX socket in its functionality. For the purposes of this fuzzing project, my attention isn't on probing the underlying TCP/IP stack; instead, I'm focused on the µC/HTTP-server code. To ensure that the fuzzing input is fed directly to the µC/HTTP-server code without first passing through the TCP/IP code, I created a custom NetSock implementation. 

My ultimate goal for this fuzzer is to read network data from a file. However, it will simplify the testing and debugging process to use existing tools to send real network traffic to my application. Once my µC/HTTP-server application is working enough to load a web page in a browser, it shouldn’t be too difficult to redirect protocol data from a file. 

I decided to implement a NetSock to POSIX socket port. All that was required to do that was to call the POSIX counterpart within the NetSock API and return an appropriate µC/OS error code. Below is example code demonstrating receiving data from a socket:

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        *p_err = NET_SOCK_ERR_NONE;
        ssize_t recvLen = 0;
        recvLen = recv(sock_id, p_data_buf, data_buf_len, 0);
        if (recvLen < 0)
        {
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
        }
        else if (recvLen == 0)
        {
            *p_err = NET_SOCK_ERR_RX_Q_EMPTY;
        }
        return recvLen;
    }
    

I then repeated this process for each of the NetSock_\* functions. I used the correct NetSock_\* function signature, called the corresponding POSIX socket function call and then returned an error code that was of the type NET_SOCK_RTN_CODE.

**File reads**

With my µC/HTTP-server application now properly responding to HTTP requests, the next step was to set it up for fuzzing by having the NetSock code read from a file instead of a real POSIX socket. There are a few different options of how to achieve reading from a file. The first is using a tool called libdesock. The way that file redirection works with this tool is that the library gets loaded by the Linux linker before other libraries by using LD_PRELOAD. This allows the libdesock library to intercept POSIX socket calls and redirect them to stdin and stdout. 

Since I was already well acquainted with modifying the NetSock code, another simple approach is to read from a file instead of calling recv within NetSock. To implement this, my µC/HTTP-server application takes a file name as an argument and stores a file pointer to that file in a global variable named curr_inputfd. Below is an example of “receiving” data from a file: 

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        ssize_t totalLen = 0;
    
        *p_err = NET_SOCK_ERR_NONE;
    
        totalLen = read(curr_inputfd, (char*)p_data_buf, data_buf_len);
    
        if (0 > totalLen)
        {
            /* return an error */
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
            
        }
        else if (0 == totalLen)
        {
            /* we've read the whole file and we can leave*/
            *p_err = NET_SOCK_ERR_CLOSED;
        }
    
        return totalLen;
    }
    

It is important to note that the above code returns an error when the end of the file (EOF) is reached. This happens because NetSock_RxData is invoked within a processing loop, and the error serves as an indicator to the caller that this "socket" has been closed.

When fuzzing an application, it is crucial for the fuzzer to differentiate between a clean exit (normal program termination) and a crash. Additionally, the program should terminate after processing the fuzzed input. Therefore, I needed to make another code modification for fuzzing purposes, ensuring that the program exits after the file has been read and processed, resulting in a "normal" termination. 

Without this modification, the application would continue running in a processing loop, causing the fuzzer to mistakenly count this as a hang rather than a normal program termination, leading to false-positives for hangs.

By placing the exit in this location, it will be called during the typical execution flow of closing a connection. And, as noted above, when the error code NET_SOCK_ERR_CLOSED is returned from NetSock_RxData, it triggers the HTTPsConn_Close function, which subsequently terminates the program's execution.

**Memory errors**

A major benefit of porting my µC/HTTP-server application to run natively on Linux is that I can compile my application with AddressSanitizer. AddressSanitizer, or ASAN, is a compiler feature in GCC and Clang that can detect memory errors in C/C++. 

This can be a very valuable tool when used in conjunction with fuzzing to reveal software vulnerabilities. When ASAN is enabled, the application will crash when a memory error is encountered. 

Things like use after free, NULL pointer dereference, and buffer overruns will cause an immediate crash even if the test input would not have normally crashed the program. When ASAN causes a program to crash, it’s like an alarm bell going off for a vulnerability researcher (**“**Look over here, there are problems in this section of code!**”**). I wanted to use ASAN when running my fuzzer, but it didn’t work straight away for heap memory in my µC/HTTP-server application. This is because µC/OS provides its own heap implementation. 

ASAN works by tracking heap memory allocations made with glibc malloc, but my application doesn’t use malloc at all. The simplest solution that I produced was to add preprocessor macros to detect when the application was being compiled with ASAN and redirect the allocation to glibc malloc. Here’s an example of what I mean:

    void  *Mem_DynPoolBlkGet (MEM_DYN_POOL  *p_pool,
                              LIB_ERR       *p_err)
    {
    #ifdef __SANITIZE_ADDRESS__
        p_blk = malloc(p_pool->BlkSize);
        if (NULL == p_blk)
        {
            *p_err = LIB_MEM_ERR_POOL_EMPTY;
            return(DEF_NULL);
        }
        else
        {
            *p_err = LIB_MEM_ERR_NONE;
        }
        return (p_blk);
    
    #endif /*__SANITIZE_ADDRESS__*/

µC/OS provides developers the capability to define constraints on the heap's location and utilization with its specialized heap allocator. This feature is particularly useful in systems with limited memory, where developers require fine-tuned control over memory allocation. However, since my application is running on Linux, I'm not constrained by memory limitations, and I have access to the standard glibc malloc function. Simply calling malloc within Mem_DynPoolBlkGet  works because the caller of Mem_DynPoolBlkGet doesn’t care about the specific memory location of the pointer that's returned. Rather, it expects the pointer to reference a chunk of memory that's ready for use and meets the minimum size requirement. By making this minor adjustment to the code, I enabled the Address Sanitizer (ASAN) features I wanted, without affecting the rest of the application's functionality.

**Vulnerability highlight**

To this point, we’ve made strategic modifications to µC/OS code, creating a software-only fuzzing solution capable of running natively on Linux and accepting input from a file. The approach we discussed here has proven its efficacy by uncovering five unique vulnerabilities: TALOS-2023-1725 (CVE-2023-24585), TALOS-2023-1733 (CVE-2023-27882), TALOS-2023-1738 (CVE-2023-28379), TALOS-2023-1746 (CVE-2023-31247) and TALOS-2023-1843 (CVE-2023-45318).

When disclosing these vulnerabilities, I discovered that much of the µC/HTTP-server codebase is shared across multiple products. Other affected products are the Silicon Labs Gecko Platform and Weston Embedded Cesium NET. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

The next installment of this series will describe the complexities of handling multiple requests per test case — an enhancement that holds the potential to reveal even more vulnerabilities.

Fuzzing µC/OS protocol stacks, Part 1: HTTP server fuzzing

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server.

Wednesday, August 28, 2024 12:00

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server. 

The first post highlighted code modifications necessary for developing a fuzzing harness tailored for the µC/HTTP-server. The second discussed a technique for delivering multiple requests per fuzz test case. Finally, I’ll detail the code modifications required for fuzzing the µC/TCP-IP stack. Please refer to the first post in the series for a description of Real-Time Operating Systems (RTOS) and the motivations for this research project. 

My goals in fuzzing µC/TCP-IP are the same as for µC/HTTP-server:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case.

Self-imposed constraints:

*   A software-only solution.
*   Run natively on Linux.

I wanted to find a straightforward way to fuzz this code without relying on emulation or dedicated hardware. 

**Linux port**

To utilize the AFL++ fuzzing framework, this code must run on Linux rather than µC/OS. This is a similar challenge I faced in Part 1. This time, however, I opted to use the POSIX KAL implementation that µC/OS provided rather than develop my own. This architecture diagram shows the layout of the various software components of µC/OS. The blue highlight represents the components I will be modifying to port the application to Linux. The orange highlight represents the code that’s the fuzzer’s target.

With my µC/HTTP-server fuzzing harness, I decided against using the provided POSIX KAL implementation. The µC/HTTP-server code I was targeting did not use many of the OS components, so it was simple to implement my own minimalist KAL interface. In contrast, the µC/TCP-IP implementation uses a separate task for receiving data and uses semaphores and message queues requiring a more complete KAL implementation. 

Using the code provided by µC/OS felt like taking a shortcut. It was painless and worked right out of the box with only minor modifications. That’s not something that I can say for working with the networking side of things, which required a lot of development.

**Network port ****TAP device**

My primary goal for the fuzzer is to enable it to accept network data from a file. To start, I adopted the strategy I used for my µC/HTTP-server, which involves ensuring my program functions with actual network data. Doing this initially allows for more straightforward debugging and testing of my code, as I can use standard Linux utilities to send real network traffic to my program.

It was a bit more complicated to get data from the network to be processed by µC/TCP-IP than it was for µC/HTTP-server. This is because TCP/IP is a lower-level protocol than HTTP. HTTP is an application layer protocol while TCP/IP is a transport layer protocol. Typically, user mode applications interact with the network at the application layer via POSIX sockets or a NetSock for µC/OS. 

In Linux, when using sockets, the kernel manages the TCP/IP processing and only delivers application layer data to the user mode application. However, my challenge was that my user mode µC/TCP-IP application is intended to handle the TCP/IP protocol itself. To bypass the kernel’s TCP/IP stack, I utilized a TAP device — a purely software-based kernel virtual network device.

Although this module is called µC/TCP-IP, it actually covers multiple layers of the OSI model. The layers circled in orange indicate layers of the OSI model for which the µC/TCP-IP module will process:

The µC/TCP-IP code is expecting to receive an Ethernet frame, and it includes handlers for ARP, IP, TCP and UDP. Because µC/TCP-IP is expecting to receive Ethernet frames, a TAP device should be used because it transfers Ethernet frames unlike a TUN device which transfers IP packets. 

A TAP device is meant to be used by user space programs that attach to it. When the operating system sends packets to a TAP device, they are delivered to the attached user space program. Conversely, packets sent by the user-space program to the TAP device are injected into the kernel network stack as if they originated from an external source.

To use a TAP device, I wrote my own Ethernet device driver using the API provided by µC/TCP-IP. I needed to create and configure my TAP device with the driver and implement functions to transmit and receive data. Again, µC/OS was great to work with for this because their API was well-defined and documented. Additionally, there are dozens of device drivers in the µC/TCP-IP repository for various ethernet hardware. Having all this example code and documentation was immensely helpful. In implementing this, I used the open-source tapip utility as a guide for creating and configuring a TAP device within my µC/TCP-IP Ethernet driver.  

The most confusing part of this was visualizing the network topology involving the TAP device. I created and assigned the TAP device an IP address of 10.10.10.1 and the Linux kernel assigned it a MAC address of 46:31:92:b0:48:5b. For remote communication, I'd need to create a network bridge, but for testing, local communication is adequate. The TAP device that I created is given the name tap0 and even shows up when running ifconfig: 

I also needed to assign my µC/TCP-IP application its own MAC and IP addresses, effectively creating another virtual Ethernet device. This adds a layer of complexity, as it's a virtual ethernet device operating through another virtual Ethernet device. Within the µC/TCP-IP application I've set up a virtual Ethernet device with an IP address of 10.10.10.64 and a MAC address of 12:12:12:34:34:34. This setup is a bit confusing because it's not externally visible in the Linux system — it's exclusive to the µC/TCP-IP application, as if the application were running on a separate machine, with the tap interface acting as the link between the Linux host and the µC/TCP-IP application.

To validate the functionality of µC/TCP-IP, I developed an echo server running on port 10001. To test my setup, I used the Linux utility netcat to establish a TCP connection to the µC/TCP-IP application. When traffic is sent from a linux application using tap0 and the mac or ip address of the µC/TCP-IP virtual interface is provided, it will be processed by my application. To send a test message and establish a TCP connection, I could execute a netcat command such as echo 'test' | nc -N 10.10.10.64 10001. Here, the netcat tool operates through a socket connected to the tap0 interface. This socket uses the Linux kernel TCP/IP stack which will first send an ARP request from tap0’s address to broadcast to learn the corresponding MAC address for that IP address. Then, the µC/TCP-IP application will receive that broadcast message, process the request, and respond with its own MAC/IP address pair. Then, a TCP connection will be initiated using the MAC/IP address pair of the µC/TCP-IP application. The image below was captured using Wireshark attached to the tap0 interface. 

The µC/TCP-IP application is not using sockets when interacting with the tap0 interface, instead, it uses a file descriptor to directly read from and write the device. The result is that the µC/TCP-IP application is writing packet data directly to the network without modification. The diagram below shows how each of these components work together to establish the TCP connection shown above. 

**File reads**

At this point, I’ve confirmed that my µC/TCP-IP echo server works using netcat. The next step for fuzzing is to modify the Ethernet driver to read from a file instead of the TAP device. Although my Ethernet driver isn’t using sockets, it is still possible to use libdesock because it overrides the read and write from libc. However, this required some code modifications in addition to using LD_PRELOAD with libdesock. First, I needed to create a socket descriptor that libdesock would redirect to stdin. Since the µC/TCP-IP application does not use sockets when interacting with the tap0 interface, I had to utilize a libdesock debug function, _debug_instant_fd, which provides a file descriptor that is automatically redirected to stdin. 

Typically, libdesock would redirect a file descriptor when accept is called, but since this is happening at a lower level, I needed to use the file descriptor that libdesock provided with the call to _debug_instant_fd. I used a compile time flag to create this libdesock file descriptor instead of creating a tap device for my fuzzing build:

    #ifdef DESOCK_FUZZ
        /* calling _debug_instant_fd for libdesock */
        fd = _debug_instant_fd(0);
        p_dev_data->tunFd = fd;
    #else
        /* Create TAP device */
    

Then, I needed to add code to terminate the µC/TCP-IP echo server once the last request was read from the file.

           ret = read(p_dev_data->tunFd, p_dev_data->RxDataPtr, p_dev_data->rxSize);
    …
    #ifdef DESOCK_FUZZ
            } else if (0 == ret)
            {
                exit(0);
            }
    #else
    	/* Continue processing */

After those code modifications, when we use LD_PRELOAD with libdesock, our application will read request data from stdin. By utilizing libdesock I immediately gained support for handling multiple requests because of that added feature. For more information on how libdesock works, refer to Post 2 from this series. 

**Memory errors**

I wanted to use Address Sanitizer (ASAN) with my fuzz application, as it is designed to detect many different types of memory errors like use after free, NULL pointer dereference and buffer overruns. The heap implementation used by µC/TCP-IP is different from that of µC/HTTP-server, but I was able to employ the same technique that I described in Post 1 from this series.

**Vulnerability highlight**

Now, we've successfully adapted the µC/TCP-IP code to develop a fuzzing solution that operates solely in software, is native to Linux, and can process inputs from a file. The approach we discussed here uncovered two unique vulnerabilities: TALOS-2023-1828 and TALOS-2023-1829. One of which is a result of fuzzing multiple requests at a time.

When disclosing these vulnerabilities, I discovered that much of the µC/TCP-IP codebase is shared across multiple products. Silicon Labs Gecko Platform is also affected by TALOS-2023-1828. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 116:2 and 116:151.

**Conclusion **

Thank you for following along in this series about fuzzing µCOS protocol stacks. To recap, we created software-only fuzzing solutions for fuzzing µC/HTTP-server and µC/TCP-IP. The fuzzing solutions discussed here include the ability to run natively on Linux and accept input from a file. We also covered a feature contribution to libdesock which allows for multiple requests to be processed by the application in a single test case, resulting in more complex vulnerability findings. My hope is that the techniques described in this series will encourage others to fuzz other RTOS platforms to make these important systems more secure.

Below is a list of vulnerabilities that were disclosed because of this research presented in this blog series:

*   TALOS-2023-1725: Out-of-bounds write vulnerability
*   TALOS-2023-1726: Buffer overflow vulnerability
*   TALOS-2023-1732: Memory corruption vulnerability
*   TALOS-2023-1733: Heap-based buffer overflow vulnerability
*   TALOS-2023-1738: Memory corruption vulnerability
*   TALOS-2023-1746: Memory corruption vulnerability
*   TALOS-2023-1828: Denail of service vulnerability
*   TALOS-2023-1829: Double-free vulnerability
*   TALOS-2023-1843: Heap-based buffer overflow vulnerability

The following is a list of Snort rules that will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908, 119:203:1, 119:282:1, 116:2 and 116:151. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

Tag

#cisco