Emulate NET VIEW behaviour from Powershell
Am fost pus de multe ori in situatia in care am avut nevoie sa listez share-uri de pe un sistem remote folosind un script, si cu toate ca un simplu utilizator poate face asta foarte simplu din Windows Explorer, din linie de comanda sunt foarte putine optiuni.
Una dintre ele ar fi folosind NET VIEW. Cu NET VIEW poti lista foarte usor share-urile de pe o masina remote, si nici nu iti trebuie drepturi deosebite.
Problema cu NET VIEW este ca output-ul este text, intr-un format ce este greu de manipulat. Desigur ca poti face un parser peste acest output si sa scoti de acolo doar ce este necesar.
Am incercat varianta cu Powershell si ma gandeam ca ar fi destul de simplu. Dar nu este. In Powershell singurele moduri de a executa acest task sunt via WMI. Adica te conectezi la masina remote si interoghezi namespace-ul WMI. Doar ca pentru asta iti trebuie drepturi de admin pe masina remote.
O varianta gasita aici ar fi fost folosind ADSI cu providerul WinNT:
([adsi]"WinNT://$computername/LanmanServer,FileService").Children | Select-Object @(
@{n='CurrentUserCount';e={$_.CurrentUserCount}}
@{n='Name'; e={$_.Name.Value}}
@{n='Server'; e={$_.HostComputer | Split-Path -Leaf}}
@{n='Path'; e={$_.Path.Value}}
@{n='Description'; e={$_.Description.Value}}
)Mai multe detalii pe tema asta gasiti si in urmatoarele link-uri:
Dar am cautat o alta varianta, pentru ca doream sa emulez exact ceea ce face NET VIEW pentru a putea interactiona si cu sisteme non windows dar care partajeaza resurse prin CIFS.
Si am gasit pana la urma solutia intr-un proiect pe GitHub ce emuleaza comenzile NET * si foloseste API-urile WIN32 via Powershell. Proiectul foloseste destul de mult cod de pe ExploitMonday si poate parea dubios, dar este proiect ce ofera tool-uri in special pentru zona de PenTest.
https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1
Iar in acest modul powershell gasiti si functia Get-NetShare.
Vechiul proiect il gasiti aici:
https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerView
Si alte cateva link-uri cu informatii ajutatoare:
http://www.exploit-monday.com/2012/05/accessing-native-windows-api-in.html
https://www.veil-framework.com/veil-powerview-usage-guide/
Nu este nevoie sa importati toate functiile de acolo. Cu putina munca, puteti gasi dependintele si pastra doar functiile de care aveti nevoie (pastrati totusi Get-DelegateType si Get-ProcAddress; sunt necesare ca sa puteti lucra cu Win32 API).
Optimizing Powershell functions by using a filter function
Cred ca cel mai bine ar fi sa incep explicand cum preia o functie input-ul ce vine prin pipeline.
In mod normal o functie in powershell poate sa preia input din pipeline folosind variabila $Input.
Si daca trimitem ceva prin pipeline catre functie iata ce obtinem:
Pare normal, nu-i asa? Dar iata ce se intampla cu adevarat in spate. Functia noastra asteapta pana intreg continutul array-ului ce vine prin pipeline este stocat in variabila $Input si abia apoi functia isi continua executia. Daca am dori ca in codul functiei sa prelucram continutul ce vine prin pipeline, ar trebui sa folosim o structura de tip ForEach si sa trecem prin toate obiectele din variabila $Input. Ceva ca in exemplul de mai jos:
Nota:Bineinteles ca rezultatul va fi identic cu cel din primul exemplu pentru ca doar am enumerat obiectele.
Va intrebati de ce nu folosesc $_ ca sa acceses obiectul curent din pipeline. Pentru ca nu este definit cand folosesc acest model si am zis si mai sus in ce moment se incepe executia functiei.
Dar daca vom defini functia ca un filtru si anume asa:
Scapam de ForEach si putem accesa variabila $_. Si mai mult de atat, in cazul in care avem un volum mare de obiecte ce vine prin pipeline, functia le va prelua pe rand si nu va trebui sa astepte pana cand toate vor fi stocate in $input.
Si acum ca stiti la ce foloseste Filter in powershell, va doresc Happy Scripting!
PS: Puteti folosi si definitia Function si sa accesati $_, dar folosing blocul Process:
E un topic mai advanced cand vine vorba de functii, asa ca prefer sa folosesc in continuare Filter.
Azure AD Connect – Single Sign On (SSO)
Am scris prin Ianuarie despre noi functionalitati in AD Connect. Si mai exact am scris despre Azure AD Pass Through Authentication. Dar mai este ceva nou in AD Connect. Si anume optiunea de SSO in cloud ce poate functiona chiar si impreuna cu Pass-through Authentication, fara a mai fi nevoie de ADFS sau alte componente; doar AD Connect.
Ca si mentiune, aceasta optiune de SSO functioneaza pentru clientii ce sunt joinati in domeniul AD on premises si pot contacta un domain controller (poate fi chiar si via VPN).
Iata cerintele aici:
SSO is a feature that is enabled through Azure AD Connect and works with password sync or Pass-through authentication and your on-premises Active Directory. For your end users to use single sign-on in your environment, you need to ensure that users are:+
- On a domain joined machine
- Have a direct connection to a domain controller, for example on the corporate wired or wireless network or via a remote access connection, such as a VPN connection.
- Define the Kerberos end-points in the cloud as part of the browser’s Intranet zone.
If any of these requirements are not present, such as the machine is off the corporate network, then the user is prompted to enter their password as they would without single sign-on.
Nota: Trebuie sa mentionez ca SSO din Edge nu merge deocamdata. Poate pe viitor. In schimb mie mi-a functionat din Chrome si IE.
Imaginea din documentatia de aici cu modul de autentificare arata cam asa:
In principiu este Integrated Windows Authentication (IWA) si Kerberos, folosind si acel computer account creat de AD Connect (AZUREADSSOACCT).
Clientul va discuta cu DC-ul local, ce va incripta un ticket cu informatiile din computer accountul AZUREADSSOACCT ce va fi mai apoi decriptat in Azure.
Iata si toti pasii pe care ii parcurge clientul:
- Azure AD challenges the client, via a 401 Unauthorized response, to provide a Kerberos ticket.
- The client requests a ticket from Active Directory for Azure AD.
- Active Directory locates the machine account, created by Azure AD Connect, and returns a Kerberos ticket to the client encrypted with the machine account’s secret. The ticket includes the identity of the user currently signed in to the computer.
- The client sends the Kerberos ticket it acquired from Active Directory to Azure AD.
- Azure AD decrypts the Kerberos ticket using the previously shared key. Then it either returns a token to the user or asks the user to provide additional proofs such as multi-factor authentication as required by the resource.
Cerintele sunt putin diferite pe partea de networking daca folositi Password Sync. Daca folositi Pass-through, nu mai este nevoie de nimic suplimentar.
If you are enabling ‘Single Sign On’ with ‘Password Sync’, and if there is a firewall between Azure AD Connect and Azure AD, make sure that:
- The Azure AD Connect server can communicate with *.msappproxy.net
- Azure AD Connect can make HTTPS requests to Azure AD on the ports below:
Protocol
Port Number
DescriptionHTTPS
9090
Enable SSO registration (required only for the SSO registration process).
In afara de asta mai e nevoie de inca o configurare pe statii (ce se poate face prin GPO) ce va permite browserului sa trimita ticketul Kerberos catre Azure (si anume sa fie adaugate in intranet zone). Site-urile necesare sunt:
https://autologon.microsoftazuread-sso.com
https://aadg.windows.net.nsatc.net
Puteti folosi Site to Zone Assignment List aflat in User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page:
Gasiti toate detaliile necesare in documentatia oficiala:
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso
Si tineti minte, nu merge cu Edge deocamdata.
Windows Management Framework (WMF) 5.1 Released
WMF 5.1 este disponibil la download in versiunea finala. Asta inseamna ca puteti upgrada clientii vechi (W2012/W8.1/W2008R2/W7) la aceeasi versiune de Powersehll/WMI/WinRM ca si Windows Server 2016 si Windows 10 Anniversary Edition. In felul acesta puteti avea un baseline in intreaga infrastructura:
https://www.microsoft.com/en-us/download/details.aspx?id=54616
Totusi instalarea nu este chiar asa directa pentru W2K8R2 si W7 (recomandat ca WMF 3.0 sa fie dezinstalat) asa ca va sugerez sa cititi cu atentie release notes:
https://msdn.microsoft.com/en-us/powershell/wmf/5.1/install-configure
Azure AD Pass Through Authentication
Inca in preview dar cu potential mare de a intra in infrastructurile mici si medii este Azure AD Pass Through Authentication. Initial mi s-a parut greu de inteles conceptul, pentru ca era prea simplu. Daca pana acum metodele de autentificare si integrare cu Azure si Office 365 erau password synchronization si ADFS, in curand (pentru ca inca este preview) o sa avem si pass through. O sa va intrebati, ce era rau cu celelalte doua metode de autentificare si pana la urma si pass-through authentication face acelasi lucru. O sa va explic si care este diferenta si cu ce vine in plus aceasta noua metoda de autentificare:
1. Parolele nu parasesc on premises. Pentru cei care aveau astfel de griji, trebuiau sa recurga la ADFS.
2. ADFS pare complicat de configurat si cateodata chiar este. Ai nevoie de certificate si endpointuri deschise in internet din infrastructura locala. Cu pass-through nici macar nu trebuie sa deschizi porturi inbound in infrastructura ta. Tot ce trebuie sa ai este conectivitate outbound de pe sistemele ce ruleaza AD Connect. Nimic altceva de setat, nu certificate, nu porturi de retea deschise catre interior.
Tot ce trebuie facut este sa instalati si sa setati AD Connect:
Si bineinteles sa activati sincronizarea pentru userii ce se vor autentifica la Azure.
In continuare procesul este foarte simplu. Connectorul va deschide o conexiune outbound catre Azure si va verifica in permananta o coada de autentificare. In momentul in care un request de autentificare vine din cloud, acesta va fi pus in coada, conectorul va prelua cererea de autentificare de acolo, o va valida si va treimite raspunsul inapoi in cloud.
Mai jos este o imagine preluata din documentatia de pe Technet insa cum mie mi s-a parut confuza m-am gandit sa explic procesul.
Masina ce va rula AD Connect trebuie sa ruleze Windows Server 2012 R2 sau mai mare si sa fie joinata la domeniul AD in care se va face autentificarea.
Pentru redundanta se pot instala mai multe instante de AD Connect. Procedura este descrisa in documentatia de aici:
Tot aici gasiti si porturile de retea necesare pentru conexiunile outbound (in caz ca sunt filtrate).
Personal consider ca AD pass-through authentication este o solutie binevenita pentru cei ce nu au impementat inca ADFS si care vor sa simplifice configuratia pe zona de autentificare. Nu este un inlocuitor 100% pentru ADFS, asa ca daca veti avea nevoie sa faceti claim based SSO cu third party, atunci tot la ADFS ajungeti. Dar pentru cei ce au nevoie de autentificare doar cu Azure, atunci mi se pare super.
Privileged Access Workstation aka PAW
Conceptul de Privileged Access Workstation sau Secure Admin Workstation sau PAW e ceva destul de frecvent discutat in ultimii ani si deja vad multe companii ce au inceput sa implementeze modelul.
Totusi, multe din elementele din acest subiect sunt “de bun simt” pentru un admin cu experienta. Plus ca nu sunt chestii chiar atat de noi. Conceptul de administration workstation era discutat chiar de pe vremea Windows 2000/2003. Inca mai tin minte documentatia de Securing/Design de la Windows 2003 unde era recomandat sa folosesti credentialele de administrare doar pe statii dedicate si erau detaliate pana si GPO-urile pe care sa le aplici. Deci nu e ceva chiar atat de nou, pentru cei cu vechime e chiar boring.
Dar sa incercam sa discutam putin subiectul. De ce o statie dedicata pentru administrare?
Pentru a diminua riscul ca un atacator sa compromita contul unui admin, printr-un cont de user normal deja compromis (exploituri web, email, executabile, keyloggers, etc).
Deci in conceptul de PAW, discutam de un sistem dedicat folosit pentru administrare. Asta inseamna ca orice persoana cu rol de admin va folosi doua sisteme pentru activitatile de zi cu zi in companie. Un sistem pentru regular tasks (web, email, office apps, LOB apps etc) si inca un sistem unde se va loga folosind credentialele de admin. Si pentru a nu fi compromise aceste credentiale, acestea nu vor avea drept de logon pe sistemele unde un user normal se poate loga (dupa cum am spus, riscul ca un user normal sa fie compromis este mult mai mare).
Separand aceste doua taskuri – admin tasks & regular user tasks, punem o bariera intre interactiunea celor doua si diminuam riscurile de escalare a privilegiilor.
Si in mare ar fi doua variante de implementare:
1. Doua statii fizice. Una pentru taskuri normale si alta pentru cele de admin. Avantajul este separarea clara intre cele doua; cele doua sisteme nu interactioneaza in nici un fel. Dezavantaje: destul de multe. Nimeni nu vrea sa foloseasca doua seturi de tastaturi si sa se mute de la un monitor la altul, sau sa care doua laptopuri dupa el.
2. Partajarea unui singur sistem folosind tehnologiile de virtualizare existente. Avantajul fiind aici in usurinta de utilizare (comparand cu primul scenariu). Dezavantaj: unii ar spune ca daca exista o vulnerabilitate in tehnologia de virtualizare, un atacator s-ar putea folosi de aceasta vulnerabilitate sa compromita intreaga statie sau sa acceseze date din partitia administrativa. Scenarii pot fi foarte multe aici, dar important este ca pana acum tehnologiile de virtualizare au fost destul de sigure si as spune ca riscul este destul de mic.
Daca pentru primul scenariu, setup-ul este simplu, doua sisteme fizice separate, in al doilea scenariu poti sa ai nenumarate variante. Nu o sa incerc sa le descriu pe toate, doar o sa va dau cateva idei si o sa mentionez regula de baza dupa care trebuie sa va ghidati cand setati acest model.
Nota: In continuare o sa denumesc statia administrativa PAW si statia userului standard UW.
Intotdeauna directia de acces trebuie sa fie dinspre PAW catre UW si nu invers. Si vad greseala asta facuta foarte des chiar acolo unde s-a incercat implementarea unui astfel de model. Daca vrei cu adevarat sa implementezi o astfel de solutie, respecta aceasta regula de baza.
Exemple de scenarii gresite:
– UW instalat direct pe hardware in care ruleaza hypervizor si un PAW VM. Admin-ul isi face taskurile normale din acest host OS, si cand vrea sa isi acceseze contul de admin, porneste PAW VM-ul si se conecteaza la el. In acest scenariu daca acel host OS este compromis, automat si PAW-ul va fi, sau credentialele administrative pentru ca sunt introduse direct de la tastatura host-ului (un keylogger in host, compromite absolut tot)
– UW instalat direct pe hardware si PAW remote (VDI, Jump server, etc). La fel ca si in primul scenariu, tot ce tastezi, trece prin UW (cu acces la internet si foarte expus). Bineinteles ca scenariul este clar mult mai bun decat daca te-ai loga pe acelasi sistem cu ambele seturi de credentiale, dar se poate si mai bine.
Exemplu de scenarii ok:
– Host OS cu hypervisor in care ai VM-uri pentru diversele roluri pe care ai. VM pentru UW si alt VM pentru PAW. Separare clara intre cele doua, nu se acceseaza unul pe celalalt. Protectia este oferita de hypervizor. OS-ul de pe host este folosit doar pentru a te conecta la VM-uri.
– PAW instalat direct pe hardware + hypervizor. UW instalat ca VM de pe PAW. Din sesiunea de logon de pe PAW se poate accesa UW. Chiar daca UW-ul este compromis, nici macar un keylogger nu poate afecta sesiunea de pe PAW. (cu toate ca acest scenariu este recomandat de MS, eu il prefer pe primul; prefer sa folosesc contul de admin numai cand este nevoie, nu sa trec prin sesiunea de admin doar ca sa ma conectez la UW).
Si de aici poti sa faci o gramada de scenarii, cu VDI, thin clients, jump servere etc. Bineinteles ca exista si alte detalii, gen hardware-ul folosit, OS, procedura de hardening, metode de enforcement pentru a limita folosirea credentialelor doar pe anumite sisteme, monitorizare. Dar subiectul este vast si am vrut doar sa punctez una dintre cele mai frecvente greseli facute.
Microsoft a facut o super treaba in ultimii ani si a publicat documentatie foarte bine pusa la punct pe aceasta tema:
https://msdn.microsoft.com/en-us/library/mt186538.aspx
J5 Wormhole – un produs interesant
Cautand un cablu USB host to host am dat peste acest produs:
Se lauda ca ar permite pana si copy/paste intre sisteme si multe altele. Nu l-am testat dar din review-uri se pare ca ar functiona. Si exista si varianta pentru Mac (bineinteles mai scumpa).
http://www.j5create.com/our-products/wormhole-switches/juc400.html
Updating Nano Server image
Daca am inceput sa ma joc cu Nano server, era si timpul sa incerc sa invat cum sa il updatez. Personal mi se pare cam peste mana tot procesul si fara tooluri specializate nu cred ca se va aventura nimeni sa faca mass deployment.
Metodele de update sunt descrise aici:
https://blogs.technet.microsoft.com/nanoserver/2016/10/07/updating-nano-server/
Toate necesita Powershell si/sau DISM.
Cea mai apropiata de modul actual de lucru cu Windows Server mi s-a parut varianta cu Windows Update (dar tot via Powershell):
-
Scan for available updates
Option 5: Download and install the cumulative update to a running Nano Server
If you have a running Nano Server VM or physical host, you can use the Windows Update WMI provider to download and install the update while the operating system is online. With this method, you don’t need to download the .msu file separately from the Microsoft Update Catalog. The WMI provider will detect, download, and install all available updates at once. After installing an update from Windows Update, you can find the log files at %ProgramData%\SoftwareDistribution\Logs\WindowsUpdate.
Enter-PSSession -ComputerName (Read-Host "Enter Nano Server IP address") -Credential (Get-Credential)
-
Install all available updates
$ci = New-CimInstance -Namespace root/Microsoft/Windows/WindowsUpdate -ClassName MSFT_WUOperationsSession $result = $ci | Invoke-CimMethod -MethodName ScanForUpdates -Arguments @{SearchCriteria="IsInstalled=0";OnlineScan=$true}$result.Updates
-
Get a list of installed updates
$ci = New-CimInstance -Namespace root/Microsoft/Windows/WindowsUpdate -ClassName MSFT_WUOperationsSessionInvoke-CimMethod -InputObject $ci -MethodName ApplyApplicableUpdatesRestart-Computer; exit
$ci = New-CimInstance -Namespace root/Microsoft/Windows/WindowsUpdate -ClassName MSFT_WUOperationsSession$result = $ci | Invoke-CimMethod -MethodName ScanForUpdates -Arguments @{SearchCriteria="IsInstalled=1";OnlineScan=$true} $result.Updates
Connecting to standalone/workgroup Nano server
Pe masura ce invat despre Nano server incep sa imi dau seama ca Microsoft trebuie sa faca ceva neaparat pentru ca totul pare a fi ceva gen work in progres. Sau poate nu mai am eu rabdare sa citesc toata documentatia si sa fac totul perfect din prima incercare.
Am ajuns in punctul in care l-am instalat iar acum vine intrebarea: cum ne conectam la el prin Powershell? Nefiind in domeniu, IP-ul va trebui sa fie adaugat pe lista de TrustedHosts din Winrm.
Dar inainte de asta va trebui sa porniti si sa configurati serviciul WinRM pe statia locala. Cel mai simplu este sa folositi WINRM QUICKCONFIG:
Abia acum putem adauga IP-ul serverului remote in lista TrustedHosts:
set-item wsman:\localhost\client\trustedhosts ‘192.168.111.41’ -force
Iar acum putem sa folosim powershell remoting ca sa ne conectam la Nano Server:
Enter-PSSession -ComputerName 192.168.111.41 -credential (Get-Credential)
Nano Server Image Builder
A venit timpul sa ma joc si eu putin cu Nano server. Cu toate ca pe zona mea de lucru nu prea am vazut cerere pentru asa ceva, totusi am zis ca e bine sa fii cu un pas in fata.
Iar ca sa incepi cu Nano server, trebuie sa creezi imaginea. Si cu toate ca Microsoft impinge din ce in ce mai mult lucrul in command line, era nevoie de o interfata grafica. Se numeste Nano Server Image Builder si se poate downloada din link-ul de mai jos:
https://www.microsoft.com/en-us/download/details.aspx?id=54065
Ca sa functioneze aveti nevoie si de Windows Assesment and Deployment Kit:
https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit
Odata instalat, crearea unei imagini este destul de simpla.
Sunt doua optiuni de baza in pagina de start. Crearea unei imagini VHD/VHDX sau deploymentul unei astfel de imagini pe un stick USB (pentru a fi folosita mai departe pentru instalarea pe un alt sistem).
Nota: Exista si optiunea de a crea un ISO de instalare dar mi se pare amuzant modul in care a fost implementat. In loc sa permita direct exportul intr-un format ISO gata de instalare, va trebui sa faci un VHD/VHDX, dupa care sa faci din el un USB bootabil, iar mai apoi sa transformi continutul de pe acel USB in ISO.
Majoritatea optiunilor sunt simplu de inteles asa ca nu voi sta sa le mai explic in detaliu.
Atentie la maximum size extension. Eu am incercat cu 0.5 si am adaugat rolul de Hyper-V & File Storage, iar procesul a dat eroare din lipsa de spatiu.
Driverele pentru Nano server trebuie sa le adaugati din procesul de build, altfel va fi un cosmar. Dar daca folositi masini virtuale pe Hyper-V, atunci ar trebui sa fie simplu si sa nu aveti nevoie de nimic in plus.
Partea de domain join merita discutata intr-un articol separat. Deocamdata pentru teste eu am ales varianta standalone.
Si cam atat pentru a crea un VHD/VHDX cu Nano server. Ce faci dupa cu aceasta imagine, este cu totul alta poveste.
Pentru curiosi pun si cateva screenshoturi din partea de USB & ISO creation:
Iar cu ISO-ul obtinut se poate instala imaginea pe un alt sistem (fizic sau virtual).
Oricare din variante le-am alege, ISO,USB sau VHDX, in final trebuie sa reusim sa bootam si sa obtinem promptul de mai jos:
Pare complicat tot procesul la inceput; dar pe masura ce va jucati cu procesul de instalare, o sa inceapa sa para mai simplu.