Add CVE-2024-49138 #42
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
0day-RCAs/2024/CVE-2024-49138.md
Outdated
| * As an example, take a malicious BLF which has a `ullDumpCount` value of 2 and a `Usn` value of 1. Following the sector signature format of `[Sector Block Type][Usn]`, each sector of this BLF would have a sector signature of `0x10 0x01`. | ||
| * `WriteMetadataBlock()` will increment both `ullDumpCount` and `Usn` by 1 before jumping to `ClfsEncodeBlock()` and `ClfsEncodeBlockPrivate()`. | ||
| * `ClfsEncodeBlockPrivate()` would calculate the new sector signature as `0x10 0x02`, following the sector signature format. | ||
| * Each sector would have its old signature of `0x10 0x01` stored at the `signatures array` located at `SignaturesOffset`, and its new sector signature value of `0x10 0x02` be written to the sector signature. However, due to the overlapping header sections that are present in the maliciou BLF, when `ClfsEncodeBlockPrivate()` stores the old signature into the `signatures array`, it will overwrite the new sector signataure value of that sector. |
There was a problem hiding this comment.
I think this is incorrect. The signatures array does not contain the old signatures, but rather the original data. My understanding of what happens is rather that:
- Since the signature array overlaps with a sector boundary, one of the entries in the signature array will contain the initial signature of that sector, i.e.
0x10 0x01. All the other entries will contain0x00 0x00. - When the BLF is loaded, the entries of the signature array are patched in the respective signature slots.
- When
ClfsEncodeBlockPrivate()iterates over the sectors, it:- First copies out the two data bytes from the signature slot to the signature array
- Then writes the signature (
0x10 0x02) in the signature slot
Let's take example of Iandoli's blog:
- pContainer overlaps with signature of sector[10]
- signature_array[59] overlaps with signature of sector[11], which contains initial sector signature
0x10 0x01
When ClfsEncodeBlockPrivate() iterates over the sectors, the following sequence happens:
- (Update signatures of sector 0 to 9, not important)
- Update signature of sector 10. Part of
pContainergets corrupted with0x10 0x02 - Update signature of sector 11. signature_array[59] gets overwritten with
0x10 0x02(but not important because another overwrite will happen in later step). - (Update signatures of sector 10 to 58, not important)
- Update signature of sector 59. The original bytes of signature slot in sector 59 (
0x10 0x01) are placed in signature_array[59], (with overlaps with signature slot of sector[11] !). Signature of sector 59 is set to0x10 0x02. - (Update signatures of sector 60 to 61)
End result:
- pContainer is changed
- sector[11] has invalid signature of
0x10 0x01
0day-RCAs/2024/CVE-2024-49138.md
Outdated
| * POC can now read and copy the systems `_EPROCESS.Token` using a series of call to `NtReadVirtualMemory()/NtWriteVirtualMemory()` and plant it into our current process, giving our user mode POC the same privileges as system. | ||
| * Spawn a cmd shell with system privileges. | ||
|
|
||
| In depth analysis of the chained exploit has been performed and documented below. |
There was a problem hiding this comment.
| In depth analysis of the chained exploit has been performed and documented below. | |
| In depth analysis of the chained kernel functions has been performed and documented below. |
0day-RCAs/2024/CVE-2024-49138.md
Outdated
|
|
||
| **Known cases of the same exploit flow:** There have been other exploits that all have the end-goal of being able to read and copy the systems `_EPROCESS.Token`, thus leading to elevation of privilege. | ||
|
|
||
| **Part of an exploit chain?** Was likely used as part of an exploit chain. |
There was a problem hiding this comment.
I think it was used standalone to elevate privileges on a Windows machine?
0day-RCAs/2024/CVE-2024-49138.md
Outdated
|
|
||
| What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? | ||
|
|
||
| **Ideas to kill the bug class:** N/A |
There was a problem hiding this comment.
|
|
||
| **Ideas to kill the bug class:** N/A | ||
|
|
||
| **Ideas to mitigate the exploit flow:** N/A |
There was a problem hiding this comment.
SMAP would kill the usermode dereference, but has been discarded on Windows (https://github.com/microsoft/MSRC-Security-Research/blob/master/papers/2020/Evaluating%20the%20feasibility%20of%20enabling%20SMAP%20for%20the%20Windows%20kernel.pdf)
The leaks via NtQuerySystemInformation from medium IL are killed on Windows 11 24H2.
Overwriting Previousmode should also not work anymore on Windows 11 24H2.
See "Limitations and improvements" at https://security.humanativaspa.it/cve-2024-49138-windows-clfs-heap-based-buffer-overflow-analysis-part-1/
0day-RCAs/2024/CVE-2024-49138.md
Outdated
|
|
||
| ### 0-day detection methods | ||
|
|
||
| What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? N/A |
There was a problem hiding this comment.
We can mention:
- Dropping and modifying BLF files
- Spawning cmd.exe as SYSTEM
- Monitoring suspicious API calls such as NtQuerySystemInformation
Co-authored-by: Benoit Sevens <[email protected]>
Based on suggestions from benoitsevens
2 participants
No description provided.