lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Jul 2016 17:08:54 -0700
From: Kurt Buff <kurt.buff@...il.com>
To: fulldisclosure@...lists.org
Subject: Re: [FD] RCE by abusing NAC to gain Domain Persistence.

This seems more like an argument to not use DA accounts for NAC,
rather than a sure-fire method to undermine NAC.

I've not used NAC, but I'd have to guess that the machine wanting
access to the network has to announce itself by name, at least.

If that's the case, how hard would it be to use the local
administrator account of the machine requesting admission? Assuming
that MSFT LAPS (or some similar system, such as the one from SANS) is
in place, it shouldn't be too hard to use the password that's unique
to that account, rather than some highly-privileged account with broad
access.

Kurt

On Sat, Jul 9, 2016 at 5:45 AM, Alexander Korznikov <nopernik@...il.com> wrote:
> link:
> http://www.korznikov.com/2016/07/rce-by-abusing-nac-to-gain-domain.html
>
> Hi there!
> I want to share how to compromise whole enterprise network in less than ONE
> minute :)
>
> Let's begin... As security consultants, we often advice to our clients to
> implement Network Access Control systems to prevent some nasty people to do
> their nasty things...
>
> This article is not about how to bypass Network Access Control systems, but
> if you're interested, read this:
> http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Arkin.pdf
> In two words, NAT can bypass almost everything and stay undetectable in
> enterprise network.
>
> So when somebody (huge organisations) implementing NAC in their network
> environment, they are implementing a huge backdoor -  called NAC.
>
> Let me explain some NAC logic:
> 1. Check for trusted MAC address.
> 2. Check installed components/registry keys in workstation via WMI
> interface.
> 3. Check another stuff in workstation's NAC agent.
>
> Wait for a second. How NAC will connect to a workstation to check (2)
> Registry Keys via WMI?
> Right. SMB Authentication with highly privileged account, in Domain Admin
> group.
>
> Let's assume these:
> 1. We have a list of workstation's IPs gathered in passive reconnaissance
> (wireshark for example)
> 2. We know which IP belongs to Domain Contoller.
>
> Is something or someone can prevent me from performing SMB-Relay attack? NO!
> On servers this will not work, because of SMB Signing option is required.
>
> We take some workstation IP address, and while NAC is performing it's host
> validation, we will relay SMB authentication to legitimate workstation.
>
> It is trivial, but as result we are able to:
> 1. Reuse this authentication token and create a new Domain Admin account.
> 2. In case if this fails, we can create a local administrator account on
> ANY workstation.
> 3. Extract credentials of ALL local users including local admins.
> 4. Gain full control of the corporate network, including Domain Admin
> accounts.
>
> All this is done in less than ONE minute, before the port will be closed
> (by NAC).
>
> This issue was tested on several Network Access Control systems.
>
> Alexander Korznikov & Viktor Minin
>
> _______________________________________________
> Sent through the Full Disclosure mailing list
> https://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists