The DMZ - 2021-05-16 (page 6 of 6)

« first day (3804 days earlier) ← previous day next day → last day (1068 days later) »

10:00 PM

It is. I'm trying to understand this myself since I find it very hard to compare Linux and Windows kernel security. I know that Linux has a lot of really insecure things enabled by default, but I also know that Windows has a lot of compatibility bloat.

@Jis12yearsold. Interesting. It looks like VBS can be used to isolate SMM.

And here I am with a BUG_ON() if SMI_COUNT ever goes up. :D

Anonymous

One thing I am not totally getting, KDP is a set of APIs right. But, at what level?

Anonymous

Because, there has to be a way of turning it off. Since it needs to do that itself.

Anonymous

Or well... Maybe it doesn't because of the whole "secured memory pool" element? :think:

@Jis12yearsold. Yeah I don't get that either. Is it to allow drivers to security communicate with the rest of the kernel while isolated? Or are they talking about the "secure kernel" (the VM host) whose only purpose is to enable and disable EPT-based protection on "guest" kernel pages?

Anonymous

@forest Yeah, I cannot quite figure that out myself...

Anonymous

10:04 PM

Also, they say that it will "promote driver developers to implement VBS compatibility".

Anonymous

SO, if they don't do that... Then what? KDP just doesn't work for THAT driver?

Anonymous

Because if so, that's fuckin' stupid.

Anonymous

That means you just need to find a driver with no VBS and then you know KDP isn't working on that driver...

Yeah, I don't know. My guess is the "major drivers" like some GPU drivers and Microsoft-developed drivers would use it. But does it only protect drivers, or does it protect the rest of the kernel?

@Jis12yearsold. It sounds to me like it's used to protect components of the whole kernel, not just drivers?

Anonymous

It sounds like it protects the drivers from messing with the kernel by isolating the driver into a code space which has an NX like bit set on it.

Anonymous

10:06 PM

Or also you know, other low level components like drivers (anti cheats and stuff)

Anonymous

But if they don't support VBS, then I am not sure how KDP works - it sounds like it doesn't...

Yeah if you don't have VBS support in hardware, KDP doesn't do anything, I think.

Anonymous

Yeah, seems a bit bonkers then, no?

Anonymous

Quite easy to bypass if that's the case...

Is KDP the same thing as HVCI (Hypervisor Code Integrity)?

docs.microsoft.com/en-us/windows-hardware/drivers/bringup/…

> Hypervisor-Protected Code Integrity can use hardware technology and virtualization to isolate the Code Integrity (CI) decision-making function from the rest of the Windows operating system. When using virtualization-based security to isolate Code Integrity, the only way kernel memory can become executable is through a Code Integrity verification.

Anonymous

10:07 PM

Good question, I was about to ask the same thing.

Anonymous

I don't think it is the same thing though, no.

Anonymous

Because KDP makes it such that you cannot execute code.

Anonymous

HVCI is actively checking it instead, no?

But so does HVCI.

Anonymous

SO, they're similar. But not the same.

10:08 PM

Oh, I think HVCI just checks before allowing it.

Anonymous

yeah.

Anonymous

I think so too.

Anonymous

So, they are similar. But not the same.

Does that mean HVCI is just KDP with signed drivers?

Anonymous

Yeah, pretty much...

Anonymous

10:10 PM

I mean, the way they've written the article. It seems to me it is literally just kernel DEP.

Anonymous

That's how it reads. Obviously, it is a bit more complicated than that.

Sure, but enforced using EPT, which is a lot stronger than NX.

Anonymous

But the end goal is very much that of NX.

To implement HVCI compatible code, make sure your driver code does the following:

    Opts in to NX by default
    Uses NX APIs/flags for memory allocation (NonPagedPoolNx)
    Does not use sections that are both writable and executable
    Does not attempt to directly modify executable system memory
    Does not use dynamic code in kernel
    Does not load data files as executable
    Section alignment is a multiple of 0x1000 (PAGE_SIZE). E.g. DRIVER_ALIGNMENT=0x1000

Anonymous

Yeah, you're right.

Anonymous

10:11 PM

Heh "driver alignment"#

Anonymous

So, I guess you're right. It is just KDP with signed drivers? :think:

Anonymous

@forest Andrea Allievi, Matthew Woolman, Jon Lange, Eugene Bak, Mehmet Iyigun

Anonymous

might be worth trying to find one of them to ask...

Anonymous

there's not a whole lot of info onlinea bout this.

Anonymous

im struggling to find muich at all...

10:13 PM

Well HVCI looks like it enforces NX, whereas KDP enforces WP?

Anonymous

> Kernel mode code integrity checks all kernel mode drivers and binaries before they're started, and prevents unsigned drivers or system files from being loaded into system memory.

Anonymous

So yeah, KDP is HVCI for signed drivers.

Anonymous

Or at least, it is very similar.

Other way around, I think.

HVCI is for signed drivers.

Anonymous

Oh right.

10:14 PM

So maybe it's just something equivalent to Linux's kernel module verification, but enforced with VBS? Man this is confusing. Windows is so convoluted.

Anonymous

Yeah, so VBS seems to be the.. Class?

Anonymous

And then HVCI and KDP are solutions inside of wider VBS.

Anonymous

However you want to phrase it.

docs.microsoft.com/en-us/windows-hardware/drivers/… I wish Linux paid this much attention to driver security.

Whether or not Microsoft's techniques actually work.

Anonymous

I really hope someone can answer your question.

10:17 PM

I hope so too. It's a fascinating topic. I wish I could just read the source code. :/

Anonymous

> Code integrity and Windows Defender System Guard are two of the critical features of Secured-core PCs. KDP enhances protection for these vital security systems and raise the bar that attackers need to overcome to compromise Secured-core PCs.

Anonymous

> The goal of using KDP is to protect internal policy state after it has been initialized (i.e., read from the registry or generated at boot time). These data structures are critical to protect as if they are tampered with—a driver that is properly signed but vulnerable could attack the policy data structures and then install an unsigned driver on the system. With KDP, this attack is mitigated by ensuring the policy data structures cannot be tampered with.

Anonymous

Yeah, so it covers what HVCI does not.

Anonymous

In a different way, but is pretty similar to HVCI in its goal.

Given how it looks like HVCI only requires pages to be aligned and none of them marked RWX, it seems like it really is just verifying signed modules and ensuring that there are no trivial ways for the modules to be compromised through modifying an RWX page with unsigned data.

Whereas KDP protects what, the rest of the kernel from drivers? Specific data structures in the kernel?

Anonymous

10:21 PM

"These data structures" sounds like specific data structures.

Anonymous

Specifically, policy data structures.

It does, but if all it does is protect specific data structures, then it sounds like that one horrible Linux kernel module that everyone laughs at that protects creds.

Anonymous

Yeah, it seems very specific.

Ah, LKRG, but just enforced using EPTs?

Anonymous

Their only goal for KDP is to seemingly stop someone using a signed driver to install an unsigned one.

Anonymous

10:22 PM

And it does that by stopping an attacker from modifyingt the policy data structure.

Right, whereas LKRG attempts to detect post-exploitation (which is a stupid concept).

Anonymous

That's what I understand it to be.

Anonymous

So, that's what it does in summary.

Anonymous

It protects the policy data structure such that you cannot install an unsigned driver from a signed one.

Anonymous

That's it...

Anonymous

10:23 PM

SO it isn't protecting the whole kernel.

Anonymous

I mean, I could be wrong but.

Anonymous

And I guess HVCI stops you from being able to use the unsigned driver anyways?

Anonymous

SO when you add them together its like...

Anonymous

Stops driver based attacks...?

Anonymous

almost entirely...?

Anonymous

10:25 PM

If I am right on this, I am quite impressed I figured it out.

Anonymous

I was not expecting to be any use.

But if you exploit a driver due to a vulnerability (despite the driver being signed), then you can modify almost all of the kernel, except parts marked RO, enforced using EPTs. With that much surface area, surely there are a million other data structures that you could modify to gain sufficient control of the kernel.

Anonymous

Hmm.

Anonymous

Yeah, I have to say... There must be ways to bypass this.

Anonymous

It is really only protecting one thing right, the driver policy structure.

10:26 PM

Is that all it's protecting? Not other sensitive components of the kernel?

Anonymous

Seems like it.

> Static KDP enables software running in kernel mode to statically protect a section of its own image from being tampered with from any other entity in VTL0.

> Dynamic KDP helps kernel-mode software to allocate and release read-only memory from a “secure pool”. The memory returned from the pool can be initialized only once.

Anonymous

It is literally designed to stop you from overwriting that policy to get an unsigned driver installed.

Anonymous

Hmm. Yeah, I still don't get quite this part...

So static KDP sounds like it can do more (any part of the kernel can protect some of its own image). Dynamic KDP just sounds like EPT-enforced W^X.

Anonymous

10:29 PM

Oh, this too.

Anonymous

> To provide runtime attestation, the attestation broker is only allowed to connect to the attestation driver one time. This is because the state is stored in VTL1 memory. The driver stores the connection state in its memory and this needs to be protected to prevent an attack from trying to reset the connection with a potentially tampered with broker agent. KDP can lock these variables and ensure that only a single connection between the broker and driver can be established.

Anonymous

So, KDP can lock also the required variables to get a new device installed and working, right?

VLT1 sounds like the "secure" kernel (the host), and VTL0 is the "regular" kernel (the guest)?

Anonymous

So even if you install an unsigned driver. You couldn't get it working?

Anonymous

Because the variables to get it established would be locked and you couldn't write them over?

10:30 PM

And VLT0 needs to request that VLT1 change the permissions through a secure API.

Anonymous

Yeah, sounds like it.

Anonymous

Yeah.

> Protection for executable pages is already provided by hypervisor-protected code integrity (HVCI), which prevents any non-signed memory from being ever executable, granting the W^X (a page that is either writable or executable, but never both) condition.

Ah so that answers my HVCI question, mostly.

Anonymous

So, I think that with KDP, even if you got a driver installed (an unsigned one) then you couldn't get a connection to establish because you need to change the state of the driver?

Anonymous

And KDP makes it such that you cannot just overwrite the variables for the state?

Anonymous

10:31 PM

Whereas you could before?

Anonymous

But then of course, KDP also protects the whole page to even install a driver at all.

Anonymous

BAsed on what I quoted above.#

> The caller can then specify the size of the allocation and the initial buffer from where to copy the memory in a POOL_EXTENDED_PARAMS_SECURE_POOL data structure. The returned memory region can’t be modified by any entity running in VTL0. In addition, at allocation time, the caller supplies a tag and a cookie value, which are encoded and embedded into the allocation.
> The consumer can, at any time, validate that an address is within the memory range reserved for dynamic KDP allocations and that the expected cookie and tag are in fact encoded into a given allocation. This allows the caller…

Anonymous

Hah.

Anonymous

So you're right.

Anonymous

10:33 PM

Well, I think.

> KDP is a set of APIs that provide the ability to mark some kernel memory as read-only, preventing attackers from ever modifying protected memory. For example, we’ve seen attackers use signed but vulnerable drivers to attack policy data structures and install a malicious, unsigned driver. KDP mitigates such attacks by ensuring that policy data structures cannot be tampered with.

Anonymous

Yeah :D

That makes it sound like it is indeed only about drivers.

Man this is confusing.

Anonymous

Yeah, that is what I quoted above, I believe.

Anonymous

It seems it is specifically to stop signed driver hijacking.

10:35 PM

But if an attacker is already in kernel mode...

Or does this only protect against overwriting the policy file (prior to code exec)?

Anonymous

By A) stopping you installing an unsigned driver from a signed driver. B) stopping you establishing a connection between any unsigned driver and the machine by locking the necessary variables you need to overwrite (which are in VTL1).

Anonymous

@forest That's a good question...

Anonymous

That's my understanding, anyways.

Anonymous

So, I guess, when the driver gets installed - the kernel would mark the driver policy memory page as RO.

Anonymous

And in doing so, you cannot ever write to the driver policy, so you cannot possibly install a new driver (an unsigned one)

Anonymous

10:37 PM

That seems to be the key point.

But if someone has an arbitrary write vulnerability...

Anonymous

Yeah, this is where I think the downfall is, when they say "API"

Anonymous

That makes me think, you can turn it off, quite easily.

Anonymous

It sounds like if you had an arbitrary write, you could just change the policy setting back to RX.

I think that "API" doesn't allow arbitrarily changing things. The API is what verifies code integrity?

Anonymous

10:39 PM

Oh, you might be right, yes.

Anonymous

I do think you're also right that, this seems pretty pointless in a sense because of how many other policies there are you could just change.

Anonymous

It seems like a very specific issue.

Anonymous

I mean, its a cool protection but..

Anonymous

If you already got a write...

Anonymous

What does it really do?

Anonymous

10:40 PM

Just removes one technique only, no?

Anonymous

AGHHH i really hope someone knows the answer

Anonymous

I really want to know.

I'm guessing they also enforce W^X so the exploit couldn't just directly overwrite RWX code, and they couldn't overwrite RX code because KDP enforces write-protect?

Anonymous

Yeah, one would assume.

Anonymous

You said Linux has nothing even remotely similar to this, right?

10:42 PM

They have LKRG which scans certain data structures for modification and panics if they change, but it's completely stupid (it's security through obscurity, since it only detects post-exploitation so any exploit could trivially disable LKRG).

Well, I take that back. They don't "have LKRG", but it's a kernel module that you could install.

Anonymous

Hmm, yes, doesn't sound that similar...

It's not in upstream.

I'm also not entirely certain whether or not KDP automatically protects any data in the text section or rodata section, or if that API has to specifically call out data that is to be protected.

I can imagine that it would by default protect the text and rodata sections, and also protect data sections which the kernel knows will no longer need to be modified and thus can be protected.

Anonymous

So, I think I somewhat understand static KDP.

(significantly updated my question)

2

Q: How effective is Windows KDP for exploit mitigation in practice?

Windows Kernel Data Protection is a kernel security feature which appears to use Extended Page Tables (EPT, a hardware virtualization feature) to enforce read-only pages. How effective is this at protecting from kernel exploits in the real world? Is this an effective mitigation, or security theat...

windows windows-10 kernel anti-exploitation

Anonymous

1) Load driver.
2) Make driver pages private.
3) Mark all pages as "owned by vtl0"
4) Add normal table addresses and update the underlying secure pfns which belong to vtl1
5) Secure kernel can now track the pages
6) Apply RO to the VTL0 SLAT table.
7) VTL0 can no longer right to any of the pages, even though they are still owned by VTL0

Anonymous

10:48 PM

That's how static KDP works, in summary. I think.

> A driver that wants a section of its image protected through static KDP should call the MmProtectDriverSection API, which has the following prototype:

NTSTATUS MmProtectDriverSection (PVOID AddressWithinSection, SIZE_T Size, ULONG Flags)

Anonymous

So, before you do that process, the pages were allocated by the NT kernel in VTL0 (so VTL0 can do what it wants with them)

@Jis12yearsold. And MmProtectDriverSection is the API to do that?

Anonymous

After that process, only VTL1 can write to the pages...

Anonymous

Yes.

Anonymous

10:49 PM

It seems like it :d

And any attempt of VT0 to write to them triggers a vmexit which VT1 then handles (by denial).

Anonymous

AH WAIT

Anonymous

No, that API doesn't do that.

Oh, but some other API?

Anonymous

The NT kernel calls the secure kernel which does all that.

10:49 PM

ah

Anonymous

So, VTL1 does that...

NT kernel is VT0 and secure kernel is VT1?

Anonymous

Yeah.

Anonymous

Mysteriously.

But does it also protect rodata and text sections by default?

Anonymous

10:50 PM

Exactly.

Like, if someone has a structure with function pointers and the structure is marked static const, is it also protected by KDP?

Anonymous

It doesn't say. It just says that it protects pages owned by that driver.

Anonymous

So, I guess?

But only pages that the driver wants it to protect, not all pages.

Plus it protects pages in the rest of the kernel like driver policy.

Anonymous

OH

Anonymous

10:51 PM

I FOUND THE CALL

Anonymous

So, VTL1 does the process I said above via this ModifyVtlProtectionMask

Anonymous

ONLY VTL1 can make that call to the hypervisor.

Anonymous

So, that's how VTL1 does that whole process of changing the pages protection settings.

Anonymous

SInce you asked which api. thats it.

Oh so VTL1 isn't the hypervisor itself.

Anonymous

10:52 PM

@forest It protects all the pages.

Anonymous

No, VTL1 is the "secure kernel" not the hypervisor itself.

All of them? How is that possible? The driver is running in VTL0 as is the rest of the code.

I think it's only specific pages that the driver wants protected.

Anonymous

"the NT kernel then brings all the pages that belong to the section in memory and makes them private (i.e., not addressed by the prototype PTEs"

Anonymous

Seems like it is the entire address space of the driver.

Anonymous

You might be right.

Anonymous

10:54 PM

But, it seems like it does it for all the pages belonging to the address space of the driver.

The driver address space is the same as the NT address space.

Because it's not a microkernel.

Anonymous

Hm, you're right.

Anonymous

Oh man, this is confusing.

Anonymous

We are getting somewhere though, right?

Anonymous

I think??

10:55 PM

Yeah for sure.

I think all of KDP is attempting to work around the fact that vulnerable code is in the same address space as trusted code, which appears to me to be a losing battle.

Anonymous

I don't know what this means... "The NT kernel then brings all the pages that belong to the section in memory"

Anonymous

What is the "section"? Is that the drivers memory region?

Context?

I think section is the range of pages that are "marked" as protected.

Anonymous

Right.

Anonymous

But as you said, they have the same address space.

Anonymous

10:58 PM

But it says "all the pages" but how;s that possible? As you pointed out...

Anonymous

So, if it is ALL the pages, how does that work?

Anonymous

I don't get it...

Anonymous

OH WAIT.

Anonymous

"the secure kernel in this scenario has protected some memory pages that were initially allocated by the NT kernel in VTL0."

Anonymous

So, you were right. It isn't all the pages, it is some pages.

Anonymous

10:59 PM

Pages which VTL0 requests.

Anonymous

So you were right, it isn't every page for the driver. It is what pages from the driver VTL0 wants to be protected.

Yeah. And Dynamic KDP does the same but rather than enforcing RO, enforces W^X.

Anonymous

Then VTL1 makes that call to the hypervisor.

And presumably not just pages from the driver, but pages in the core of the kernel.

Anonymous

Yeah, presumably.

11:00 PM

So that the exploit can't just do the equivalent of Linux current->cred->uid = 0 or whatever.

Anonymous

So the key point is that, once KDP finishes you cannot write to the pages protected by KDP because they are only writable from VTL1.

Yeah, and no one can write to it (except presumably the secure kernel, which doesn't need to).

Anonymous

Yes. Precisely.

Anonymous

And if you do find a way to write to vtl1

Anonymous

this is what you invoke ModifyVtlProtectionMask to turn off KDP :D

Anonymous

11:02 PM

well, that was fun!

Anonymous

Time to build a poc? ;)

Or... just modify some sensitive data structure that isn't protected by KDP.

Anonymous

Yeah :D

Surely there are many of them, and all it takes is one and it's game over.

Anonymous

Hopefully someone else can verify everything we've come up with.

Anonymous

11:03 PM

That would be super, super useful and cool.

Anonymous

Who said kernels weren't fun? They're an idiot. And I think I even made you interested in Windows now ;)

Heh, a little, but only because I'm curious about how this could be applied to Linux.

Anonymous

Hahah :D

I hope you'll still get into Linux and not stay stuck with this ugly bloated closed-source monster.

Anonymous

Well, thanks for asking me to help, that was really enjoyable.

11:05 PM

It was!

Anonymous

I am going to go sleep, that used my last energy...

Can someone recommend me any place where I can buy a VPN with Crypto?

Hopefully you feel better now. :P

Anonymous

Hopefully I wake up to a really good answer!

@RoryAlsop I dunno, IPredator or something? But know that VPNs are not good for real anonymity.

Anonymous

11:05 PM

@forest Hah! A little.

Anonymous

@Warlock Better off with Tails or Whonix than a VPN :)

Anonymous

(in most cases)

I thought I needed to use a VPN in Tails

Just Tails is enough?

Anonymous

@forest I'm sure I will :D

Anonymous

VPN with Tor = bad.

11:07 PM

@Warlock You only need Tails.

I don't think Tails even supports VPNs. But yeah, VPNs centralize you.

Unless you just want to torrent, then a VPN is better (Tor does not support BitTorrent).

Anonymous

If you need to hide Tor use from ISP, use Bridges instead of VPN.

^ Yeah. In fact, your ISP can tell that you're using Tor through a VPN!

The reason is that Tor sends traffic in 514 byte cells, which shows up through a VPN.

Anonymous

Starring random message so I can go back to that whole conversation with ease when I wake up...

Interesting

@Warlock What is your threat model (i.e. who do you want to protect against)?

Anonymous

11:09 PM

If it's the NSA... You're too late, opsec burned, asked a question about Tails, caught already :D

Anonymous

(joking...)

I want to attack, so I want to protect myself hah

@Warlock Then you'll probably want to buy or hack a server and control it through SSH, and hack over that. Don't attempt to hack directly over Tor.

I wasn't able to use nmap in Tails, so I think I probably won't be able to use some Tools in Tails?

Anonymous

Don't download stuff in Tails.

Anonymous

11:10 PM

Bad for privacy...

@Jis12yearsold. Well you can use the package manager safely.

Since it forces everything through Tor anyway.

Anonymous

That's true!

Anonymous

But even still - it opens up an attack vector. NMAP can have bugs.

@Warlock Right. You won't be able to use many security tools over Tor. That's why you should use Tails only as a thin client to control some other box from which you attack directly.

Yeah true. But nmap doesn't work through Tor anyway.

Anonymous

@forest By the way, does the 514 byte cell also have something to do with the whole cell based DDoSing problem?

11:13 PM

@Jis12yearsold. No, it's just that it's the size that a single cell is.

Anonymous

Oh right.

Anonymous

Countries that are against the place you're targeting is a good start ^

Anonymous

specific recommendations are likely detrimental to forests opsec.

Yeah, sorry

:58020640 Dunno. I'm sure a web search for "VPS that takes cryptocurrency" would help. If you're a real hacker, you'd just pwn a server yourself instead of buying a VPS. :)

Anonymous

11:14 PM

also countries which do not have extradition treaties, are a good start too.

@Jis12yearsold. I think that only applies if you live in those countries.

Anonymous

@Warlock no need to apologise :D

Anonymous

@forest yes of course, it is relative to where you live :D

Anonymous

with me being in the uk.

Anonymous

i have like three options...

Anonymous

11:15 PM

:D

@Jis12yearsold. Here have

It's actually often best to hack a server relatively near your real target and make it your attack box. If you do that, it's less likely that people (or IDSes) will be suspicious of the connections.

Whereas if you pwn some router in Croatia, it'll set off red flags when you attack a server in Canada.

Anonymous

Anyway, forest is mostly better equipped for these sorts of questions and I am tired so, I'll leave you in his safe hands :D

Anonymous

Goodnight! :D

Thanks for the tips guys

11:17 PM

gnight J

You're really smart

@forest Btw, what's the reason of the same photo as @Jis12yearsold.?

@Warlock We actually changed our avatars recently to stand in solidarity with the Palestinians in Gaza being attacked by Israel. The BDS (Boycott, Divestment, and Sanctions) movement focuses on pressuring Israel to stop its apartheid settlements and military attacks on civilians.

Basically, we're pro-Palestine, not pro-Israel. :P

@forest Undestand, and I support the cause. I'm also pro-Palestine :D

Awesome. Glad to see there are so many people coming out of the woodwork in support.

Can I use the same photo?

11:25 PM

Yes.

Both me and J got it from someone who said it was, I believe, public domain.

11:40 PM

Hm, there are no Sec.SE questions on HNQ right now, and my question already got 4 upvotes. Maybe if a few more people upvote it, it'll hit HNQ and I'll get a good answer. :D

user image

Journeyman Geek

11:56 PM

@forest waaaaitttt

You took it literally at face value...?

@JourneymanGeek Took what?

« first day (3804 days earlier) ← previous day next day → last day (1068 days later) »

Transcript for

May '2116

The DMZ

A serious place where infosec is discussed PS we don't do hard...

404-errors moderate-anarchism pretending-to-work staring-into-the-abyss

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile