[HN Gopher] Windows x64 handcrafted token stealing kernel-mode s...
___________________________________________________________________
Windows x64 handcrafted token stealing kernel-mode shellcode
Author : fortran77
Score : 140 points
Date : 2022-07-05 08:19 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| brasenose wrote:
| Some critique from a seasoned kernel exploiter
| https://twitter.com/d_olex/status/1544008208641306624:
|
| "You have at least two race condition bugs in your code: manual
| traverse of ActiveProcessLinks without locking the list, and same
| issue with process objects you're working with. Correct approach:
| use appropriate kernel functions to reference needed _EPROCESS in
| error safe way."
|
| And https://twitter.com/d_olex/status/1544013068388433920:
|
| "Seriously, never ever touch nt!PsActiveProcessHead list with
| your own code, nt!ZwQuerySystemInformation() with
| SystemProcessInformation info class can do it for you without any
| risks to catch BSoD ... and if you want direct _EPROCESS pointer
| for your fuckery -- it's better to obtain it with
| nt!PsLookupProcessByProcessId() and free it with
| nt!ObDereferenceObject() call at the end."
| badrabbit wrote:
| Haha, the guy is writing shellcode not production software.
| Some of the criticism is good but malware developers hardly
| care about the proper way of doing things or race conditions.
| charles_kaw wrote:
| >malware developers hardly care about the proper way of doing
| things or race conditions
|
| Yes they do, they absolutely do - especially at this level.
| An easy way to get caught is to show up in a crashdump that
| automated software flags.
| ptsneves wrote:
| Would something like the Linux kernel randstruct plugin, make
| this kind of escalation code more complicated? Suspend your
| disbelief and assume that every windows user compiled his own
| Windows kernel on installation :).
| meibo wrote:
| It would make it a lot harder, either way - depending on the
| struct, you could possibly use heuristics to guess where you
| have to look. Either way, I don't think this would ever be
| possible for Windows. A surprising amount of legitimate
| software actually depends on these being the way they are
| (mostly Antivirus software that you don't want on your system
| in the first place, but they exist nonetheless).
| pedro2 wrote:
| I thought with x64 the days of AV hooking up random places of
| the kernel were over?
| therein wrote:
| They aren't. AV and AC software continue hooking system
| functions to this day. PatchGuard doesn't cover every .data
| ptr and procedure.
|
| You can do things with IoAllocateMdl,
| MmProbeAndLockProcessPages, MmMapLockedPagesSpecifyCache,
| MmProtectMdlSystemAddress to achieve such tasks.
|
| They don't even need to be public, you can just walk the
| exports of ntoskrnl.exe etc.
|
| You can even do insane shit like changing the PML4 of a
| process to the PML4 of another and have them point to the
| same memory. Or change the Win32Thread of your KTHREAD
| structure to that of explorer.exe and draw on the screen
| from kernel with GDI commands.
| greenn wrote:
| If I understand correctly, this is just a kernel-mode snippit to
| copy the System process token to your target process. It assumes
| you've already found a vulnerable driver to execute code in the
| kernel. If you can execute code in the kernel then yeah, you can
| give processes privileges they didn't have before.
| jrtytugy78gftr wrote:
| bob1029 wrote:
| I feel like I've seen something really similar to this (but in
| powershell) that does the TrustedInstaller elevation trick.
| nly wrote:
| In case anyone doesn't get it, this isn't an exploit in itself.
| It's a function you can use to gain system (root) privileges once
| you've found a bug in the Windows kernel that that gives you
| remote code execution.
| [deleted]
| Neil44 wrote:
| Do you mean privilage escalation or have I misunderstood? i.e.
| you could for example exploit one of the recent Exchange
| vulnerabilities then use this to get SYSTEM and own the box.
| 3np wrote:
| The first line in the README:
|
| > Windows x64 kernel-mode handcrafted shellcode to replace
| primary access token of executing process with SYSTEM process
| token for Elevation of Privilege(EoP).
|
| So yes, privilege escalation.
| Perolan2 wrote:
| No, not just privilege escalation. This is shellcode that
| needs to be inserted into a vulnerable driver, as it has to
| run from kernel space. Being privileged isn't enough to run
| this function.
| readams wrote:
| No, this is the code that you inject using your
| vulnerability. The vulnerability is the privilege escalation
| part and this is what you do with your privilege. Exploiters
| call this shellcode since a common way this manifests is that
| the code will launch a root shell.
|
| Shellcode can be hard to write since it might be a small
| amount of code you can execute, you might not be able to jump
| precisely to your code, it might have to use a limited range
| of values (such as correctly parsing as something else) or
| other challenges.
| jpgvm wrote:
| Clean. I love reading nicely commented assembler, something about
| it just makes my coding brain happy.
| pyinstallwoes wrote:
| Wow that is pretty.
___________________________________________________________________
(page generated 2022-07-05 23:01 UTC)