Conversation

Notices

1. Embed this notice
   Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 12-Sep-2024 01:47:45 JST Will Dormann

   This is a fun one from Elastic Security Labs.
   https://www.elastic.co/security-labs/dismantling-smart-app-control

   In the process of canonicalizing the path in a LNK file when it is clicked on, Windows rewrites the LNK file, clobbering the Mark of the Web (MotW) along with it. The impact here is that things that rely on MotW, e.g. Smart App Control (SAC) or SmartScreen, fail to protect the user in any way with such files. This has been abused ITW for 6 years.

   MSRC has said that they might possibly address it in the future.
   There is no CVE for this, as Microsoft doesn't assign CVEs to vulnerabilities. They assign CVEs to fixes.

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 12-Sep-2024 01:47:43 JST Will Dormann

     in reply to

     Note that with variant 2 ("Target File DOS Name" ends with a '.'), it's worth noting that there's nothing special about the '.' character. It can be just about anything. It could be a space, or a newline, or probably a wide number of characters.

     But to fall victim to this requires double-clicking on the LNK file twice. The first time Windows will normalize the path and strip the MotW. The second time will invoke the target.

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 12-Sep-2024 01:47:43 JST Will Dormann

     in reply to

     Note that this is only now officially CVE-2024-38217, and Microsoft has released a fix for it:
     https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38217

     Why did this public, exploited-in-the-wild vulnerability not get a CVE for more than a month?
     It's because Microsoft doesn't follow CVE CNA rules, and they only assign CVEs to updates, rather than vulnerabilities.
     It's also because MITRE doesn't follow the CVE CNA rules, functioning as a CNA-LR (they ignored the request to get this issue a CVE).

     Great job, folks!

     Kevin Beaumont repeated this.
   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 12-Sep-2024 01:47:43 JST Will Dormann

     in reply to

     More than one month after Elastic Security Labs publicly described "LNK Stomping" (now CVE-2024-38217) exploit variants, the "path segment" variant has still zero detections on VirusTotal.

     I slapped together a naive YARA rule that seems to work well to detect this variant of CVE-2024-38217 exploits:
     https://gist.github.com/wdormann/7379c4c4fb0631d8ec6a5b12d50ba782

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 12-Sep-2024 01:47:44 JST Will Dormann

     in reply to

     The sample LNK files that Elastic Security Labs made public a month ago that exploit this vulnerability were never uploaded to VirusTotal. I had to upload all 3 variants.

     This to me is... unexpected?
     https://www.virustotal.com/gui/file/a688c1f260fefd4cb071d268dde451fd36a7b43a92d8ee1bc5c415174f61c2d5/details
     https://www.virustotal.com/gui/file/949ee5111405e5fd27d8ea422b23b88c4e4c135c1ed03174273578644a01e482/details
     https://www.virustotal.com/gui/file/2c4d74eccf65d8df1961e5ead02d542d1b09eba93f4bb011d23eceb230fd02bc/details

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 12-Sep-2024 01:47:44 JST Will Dormann

     in reply to

     I already have a good number of LNK files that have exploited this to-be-CVE'd vulnerability over the years.

     A precise search for one of the three variants seems to be to look for ExifTool metadata where the TargetFileDOSName value has slashes in it.

     However, while VirusTotal obviously captures and stores this data, it doesn't seem to be possible to construct a search that looks for anything there? 🤔

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 12-Sep-2024 01:47:44 JST Will Dormann

     in reply to

     Less-efficient workaround:
     Do a VirusTotal RetroHunt with a close-enough YARA rule, and then just manually run exiftool on them.

     And then ask ChatGPT to tell me what some of them do because I'm lazy. This attacker from 4.5 years ago at least had a sense of humor. 😂
     https://www.virustotal.com/gui/file/ca2723ce8388eda11d5b07e788145d9779a6d38bac2d448a89ba860e4899ab35/details

     Microsoft has refused to assign a CVE to this, as they don't feel obligated to follow CNA rules. ("CNAs SHOULD assign CVE IDs to Vulnerabilities, not Fixes for Vulnerabilities. ")

     MITRE has refused to assign a CVE (by way of ignoring the request), as they too apparently don't feel obligated to follow CNA rules ("... MUST direct a CNA-LR or another CNA with appropriate scope to assign as quickly as possible and no later than 72 hours after becoming aware of the first refusal.")

     So have fun with this one, folks. It's been exploited ITW for years, and it definitely works. But "LNK Stomping" has no CVE because, well, draw your own conclusions...

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 12-Sep-2024 01:47:44 JST Will Dormann

     in reply to

     • Joe Desimone

     The Elastic blog post admits that signature-based detection on LNK files is difficult.

     A simple Python script to detect abusers of this LNK vulnerability was created by @dez , but it is fragile in that it relies on pylnk3 being able to parse the LNK file without error to be successful.

     Out of a set of about 2000 LNK files, lnk_stomping.py fails to analyze about 1400 of them due to errors thrown by pylnk3 (e.g. year out of scope, drive as second element required, utf-8 decode error, struct unpack error)

     Out of a set of about 1200 LNK files that abuse the "pathsegment" variant of LNK Stomping, lnk_stomping.py detects 13 of them.

     So yeah, lnk_stomping.py is better than nothing. But if you're statically looking at LNK files to see if they are abusing LNK Stomping, you might be better off using exiftool and looking for one of:

     1) "Target File DOS Name" has a '\' in it
     2) "Target File DOS Name" ends with a '.'
     3) "Relative Path" begins with ".\"

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 12-Sep-2024 01:47:45 JST Will Dormann

     in reply to

     The flow is pretty straightforward:
     First, the MotW is written when the from-the-internet ZIP is extracted, as any well-behaved (e.g. NOT 7-zip) archiving utility will do.

     Then, as Windows parses the LNK file, it rewrites it to fix the path. In the process of doing this, the MotW is removed.

     Finally, Windows checks to see if it needs to use SAC or SmartScreen. Because there is no MotW, the file is deemed "safe" and no SAC or SmartScreen comes into play. 🎉

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 12-Sep-2024 01:47:45 JST Will Dormann

     in reply to

     This month's Patch Tuesday addresses a MotW bypass: CVE-2024-38213

     Of interest:
     1) Microsoft mentions a SmartScreen bypass, but no mention of Smart App Control (SAC). They do know that SAC is a thing, right?
     2) It's a completely different vulnerability credited to Trend Micro. Apparently called copy2pwn, as it involves copy and paste in the attack.

     Apparently the Elastic Security labs issue, which doesn't require copy and paste, is not important enough to fix. Or give a CVE to. 🤷♂️

     https://msrc.microsoft.com/update-guide/en-us/advisory/CVE-2024-38213