KB5034441 0x80070643 fix

maj 14, 2024nExoRDevOps/Scripting, tips'n'tricks

Microsoft zapowiedział, że nie wyda poprawki do poprawki KB5034441, która w większości wypadków wysypuje się błędem 0x80070643. w takim razie pół-automatyczne rozwiązanie do zassania tutaj, a poniżej informacje o co chodzi i jak to działa.

czemu to się sypie

niby opis naprawy można znaleźć na stronie Microsoft. ale po pierwsze, nie każdy jest na tyle odważny, żeby grzebać na żywych partycjach. po drugie w całym tym opisie brakuje bardzo ważnej informacji: potrzebny jest plik w winRE. teoretycznie wykonanie komendy 'reagentc /disable’ powinno skopiować plik winRE, ale tego nie robi. a więc po zmianie wielkości partycji, próbujemy włączyć… i nie działa.

w związku z tym ogólne kroki do wykonania to:

przygotowanie pliku winRM.wim i umieszczenie go w katalogu 'recovery’.
wyłaczenie winRM
znalezienie partycji recovery
zmniejszenie partycji systemowej, żeby zrobić miejsce na winRM
zwiększenie partycji recovery
właczenie winRM

Skrypt

na github

skrypt wymaga uruchomienia jako administrator. co robi:

pobiera plik winRM.wim do katalogu 'recovery’
próbuje znaleźć partycję recovery i jak mu się uda:
przygotowuje plik wsadowy dla diskpart
wypluwa instrukcje do robić dalej

jeśli skrypt się nie wysypał – to prawie na pewno wszystko jest ok. jeśli się wysypał przed końcem – cóż, może masz pecha i Twoja konfiguracja jest niestandardowa.

nie działa w 1oo% oczywiście – dla tego nie jest w pełni automatyczny. są różne dziwne scenariusze, ale w większości, na komputerach firmowych sytuacja jest dość prosta. skrypt odpaliłem na wielu serwerach i stacjach roboczych i skuteczność jest na poziomie 95%, oszczędzając mojemu zespołowi godzin pracy i dziargania w diskpart.

Przypadki, które sprawiały problemy to:

kilka przypadków z bitlocker, dziwnym układem partycji
trudne do wyjaśnienia przypadki w których winRE nie było włączone a patch i tak chciał się instalować. partycja recovery była w 'dziwnym’ stanie [chyba ktoś przy niej wcześniej grzebał (; ]
w kilku przypadkach, kiedy zabrało miejsca na dysku systemowym, chociaż było go dużo – pomogła defragmentacja.

w sumie nie dziwię się, że Microsoft nie wydaje automatu, bo nie chce potem odpowiadać za utracone dane. i ja również dodam: USE ON YOUR OWN RISK.

powodzenia

eN.

nieaktywni użytkownicy EntraID

lut 7, 2024nExoRCloud, DevOps/Scripting, tips'n'tricks

w AD sprawa była prosta… no może nie tak bardzo prosta, bo historia atrybutów lastLogon i lastLogonTimeStamp też ma swoje drugie dno, ale od wielu lat wiadomo jak aktywność użytkownika zbadać… i pojawiła się Chmura i hybryda, która całość skomplikowała…

przez wiele lat nie było prostego sposobu na zapytanie 'wyszukaj nieużywane konta’, ponieważ nie było w EntraID odpowiednika lastLogonTimeStamp i trzeba było każdy system badać na dziwne sposoby. wedle Microsoft, należało odpytać logu audytu, który miał standardowo 3o dni.. wielce przydatne. nie drążąc dalej historii, od kwietnia 2o2o GraphAPI produkcyjnie obsługuje ’signInActivity’ – w końcu atrybut/zasób, który jest automatycznie aktualizowany ostatnią datą uwierzytelnienia.

uwaga. atrybut może mieć do 6h opóźnienia w aktualizacji

jak odpytać

kilka przykładów jak przygotować sobie raport, korzystając z commandletów Microsoft.Graph

wyświetlenie wszystkich użytkowników, wraz z ich mailem oraz datą ostatniej aktywności:

Get-MgUser -Property displayname,mail,signInActivity -all|
    select displayname,mail,@{L='signin';E={$_.SignInActivity.LastSignInDateTime}}

korzystanie z commandletów graphowych nie jest przyjemne i wymaga cierpliwości. większość operacji, ze względu na optymalizację, nie wyświetla prawie żadnych atrybutów – dla tego trzeba wyraźnie zaznaczyć w 'property’ czego będzie się potrzebowało.

trochę bardziej złożony raport, wyrzucany na csv, zawierający dodatkowo informacje o licencjach:

Get-MgUser -Property id,displayname,givenname,surname,accountenabled,userprincipalname,mail,signInActivity,userType -all|
    select id,displayname,givenname,surname,accountenabled,userprincipalname,userType,mail,`
    @{L='signin';E={$_.SignInActivity.LastSignInDateTime}},`
    @{L='licenses';E={(Get-MgUserLicenseDetail -UserId $_.id).SkuPartNumber -join ','}}|
        export-csv -nti c:\temp\EntraUsers.csv -Encoding utf8

co mnie denerwuje w tych commandletach, to że nie są przyjmują w prosty sposób obiektów, np to nie zadziała:

get-mgUser -all|get-mgUserLicenseDetail

to było abecadło PS, ale wzięli się za to developerzy webowi i taki efekt… trzeba też zawsze pamiętać o dodaniu 'all’ bo standardowo jest paging na 1oo obiektów.

i jeszcze drobny przykład na użycie filtra. nie jest co prawda widoczne w helpie od get-mgUser ale to jest filtr OData – z którego ogólnie korzysta cały Graph. tutaj prosty filtr, żeby wyświetlić tylko konta typu guest. nie podjąłem się filtrowania po dacie w OData bo to by kosztowało mnie za dużo czasu na rozkminkę – operacje na datach nie są oczywiste, a PowerShell sobie świetnie z tym radzi:

Get-MgUser -Filter "userType eq 'guest'" -Property displayname,usertype,signinactivity|
    ?{$_.SignInActivity.LastSignInDateTime -lt (get-date).AddMonths(-2)}|
    select displayname,usertype,@{L='activity';E={($_|select -ExpandProperty SignInActivity).LastSignInDateTime}}

connect

oczywiście żeby korzystać z commandletów graph trzeba się połaczyć z odpowiednim zakresem (scope). jeśli to jest dla ciebie nadal problemem to koniecznie wrzuć do bookmarków ten link, który opisuje jak użyć Find-MgGraphCommand żeby sprawdzić niezbędne zakresy.

jak Microsoft potrafi strzelić klientom w kolano

ciekawostką jest, że żeby być w stanie odczytać ten atrybut, trzeba mieć minimum EntraID P1 – inaczej wyskoczy błąd:

Get-MgUser_List: Neither tenant is B2C or tenant doesn't have premium license

Status: 403 (Forbidden)
ErrorCode: Authentication_RequestFromNonPremiumTenantOrB2CTenant

…dlaczego? nie chodzi mi o techniczne wyjaśnienie, ale to krzyk w stronę MS – dla czego tak podstawowa funkcjonalność, jak wyszukiwanie nieaktywnych kont, wymaga dodatkowej licencji?

eN.

’touch me’ – nieoczywista oczywistość

sty 17, 2024nExoR4 komentarzecuriosity

czemu tokeny FIDO chcą żeby je dotknąć?

ktoś zadał mi takie pytanie i w sumie ja też sobie je kiedyś zadawałem…

kiedyś

jako dinozaur, bardziej naturalnym [czy też tradycyjnym] sposobem uwierzytelnienia są dla mnie karty karty inteligentne. nie do końca rozumiem, czemu nigdy nie zdobyły popularności na rynku małych i średnich firm oraz prywatnie:

są super tanie!! pojedyncza karta to koszt ok. $1-2
łatwo dostępna technologia – przez długi czas dużo laptopów wychodziło z wbudowanymi czytnikami
fajnie integrowały się z systemami bezpieczeństwa dostępu fizycznego – ta sama karta do bramki przy wejściu i potem odpowiednie poziomy dostępu do pomieszczeń.
ta sama karta do logowania do systemu co do drzwi

taki klasyczny 'żarcik edukacyjny’ w niektórych firmach w jakich pracowałem, to szybka podmiana pulpitu na jakieś złośliwe zdjęcie, albo wysłanie maila do całego teamu 'stawiam wszystkim pączki!’, kiedy ktoś odszedł od kompa nie blokując pulpitu… dodatkowa zaleta smartcard jest taka, że kiedy osoba odchodzi od komputera – np. do toalety – musi użyć tej samej karty, a wyjmując ją z kompa automatycznie blokowana jest stacja.

a jednak to tokeny FIDO2, ze wszystkimi swoimi wadami, od ceny zaczynając, rozpychają się na obecnym rynku…

dodatkowo przez jakiś czas zastanawiałem się po co trzeba je dotknąć? spodziewałem się że to małe coś na tokenach, to czytnik linii papilarnych – to by miało sens. ale nie – to zwykłe zwarcie jest. niektóre 'nowoczesne’ modele są tak zaprojektowane, żeby były malutkie i 'nie przeszkadzały’ podobnie do nadajników radiowych, i żeby nie trzeba było ich w ogóle wyciągać – a więc co to za zabezpieczenie? to tak jakby zostawiać klucz w zamku – wystarczy przyjść i przekręcić.

odpowiedź

odpowiedź jest prosta – te klucze nie mają chronić przed próbą dostępu fizycznego. konieczność dotyku powoduje, że przy próbie uwierzytelnienia zdalnego, kiedy wymagany jest 2FA, potencjalny atakujący nie będzie w stanie go użyć… bo jest zdalnie, czyli nie może dotknąć tokenu. statystycznie patrząc, nie bronimy się raczej przed kolegami z pracy, dość rzadkim scenariuszem są również sytuacje, w których atakujący ma fizyczny dostęp do naszego komputera.

dodatkowo, bardziej prawidłową odpowiedzią będzie – „wygoda”. bo przecież konieczność wpisania PINu daje ten sam poziom [ba! wyższy! bo ktoś musi go znać], tylko jest bardziej upierdliwa. zresztą do tokenów też trzeba często podać PIN.

no to czemu nie smart card?

Pozostaje pytanie – czemu jednak nie karty inteligentne, skoro mają tyle zalet? w końcu to, że tokeny są tak ładnie obsługiwane przez przeglądarki i urządzenia to kwestia tego, że powstały standardy, które zostały zaimplementowane przez dostawców. są takie, ale mogły być inne. czego zatem brakuje kartom inteligentnym i czemu nie dostosowano tej technologii do protokołów Chmurowych WebAuthn/CTAP? co przełamało prawo konwergencji, forkując technologię, która wydawała się wygodniejsza [i tańsza] – pozostawiając karty inteligentne w niszy dostępu fizycznego, a stworzono Fast IDentity Online [FIDO]?

podstawowym powodem jest cały model uwierzytelnienia, tzw. authentication workflow. obsługa certyfikatu zorientowana jest na zcentralizowanym modelu. FIDO z założenia jest zdecentralizowane, oparte na szybkiej weryfikacji, bez konieczności dodatkowego sięgania do jakiegoś centralnego serwera. niepotrzebna jest Infrastruktura Klucza Publicznego [PKI] – która ma swoją własną złożoność, problemy, podatności etc…

można z tym wszystkim niby polemizować – że certyfikaty nie muszą być drogie, że wdrożenia PKI to wcale nie musi być nie-wiadomo-jak-skomplikowane… ale jak to wszystko zebrać razem, to po prostu nie tędy droga. tak na prawdę FIDO powinno być ewolucyjnie porównywane z tokenami OTP – np. RSA SecureID – a nie z kartami inteligentnymi. elektronika, która jest w tokenach pozwala na wiele więcej, niż pasywne przechowywanie certyfikatów:

generowanie tokenów jednorazowych TOTP/HOTP
izolację procesu generacji klucza publicznego bezpośrednio na urządzeniu, dodanie TPM, a więc nie ma praktycznie możliwości przechwycenia części prywatnej. przy klasycznym PKI mamy architekturę serwer-klient, a więc dodatkowy punkt potencjalnej słabości
proces uwierzytelniania WebAuthN nie jest trywialny… dodatkowa komplikacja w postaci weryfikacji certyfikatów na serwerach CA zabiła by Internet. kto przepalił godziny na rozwiązywaniu problemów uwierzytelnienia ten wie, że w
i w końcu wszystkie te bajery, które nie są bez znaczenia typu możliwość dodania biometrii – np. czytnika odcisków palców [jasne… cena jest kosmiczna, ale są],
self-service … [well… można polemizować z tym self-service. nie wszystkie scenariusze pozwalają na self-service…]

w skrócie – wymagana była aktywna elektronika.

pisząc ten art zadałem sobie pytanie – czemu nie połączy się tych dwóch technologii tworząc FIDO2 smart card… i jak to zwykle bywa – ktoś już odpowiedział na to pytanie – a czemu by nie? mam nadzieję kiedyś pracować przy wdrożeniu takiego cuda, jako część Integrated Security System, bo wygląda smacznie.

Exit

jednym z drażniących ograniczeń FIDO jest brak jego natywnej obsługi przez Windows logon. do tego celu można oczywiście wykorzystać system innych firm – jak np. Duo. problemem są koszty rozwiązania – same tokeny FIDO do najtańszych nie należą, a i subskrypcja Duo kosztuje… dochodzi dodatkowy poziom integracji, wybór IdP i tak dalej…

…nie podejmuję się odpowiedzi na pytanie 'dlaczego?’… a w każdym razie nie dzisiaj…

eN.

wyszukiwanie aktywności konta

sty 12, 2024nExoRtips'n'tricks

ostatnimi czasy wróciłem do podstaw… i tak się stało, że duża część moich obowiązków związana jest z bezpieczeństwem. bezpieczeństwo zawsze było istotnym elementem mojej pracy zawodowej, ale zawsze jako dopełniający element, a nie przewodni – czy się zarządza, czy projektuje, zawsze trzeba mieć na uwadze czy środowisko/konfiguracja spełnia odpowiednie normy. wbrew niektórym poglądom środowiska on-premises prędko nie odejdą do lamusa, choć coraz bardziej się odchudzają. a ponieważ klienci, z którymi mam ostatnio do czynienia, nie mają wyszukanych rozwiązań, wszystko trzeba robić 'po staremu’.

podrzucam zatem przydatne komendy, które pomogą w manualnej inwestygacji. przyda się zarówno przy ogólnym audycie ale i w momencie jeśli próbujemy znaleźć gdzie jakieś konto 'żyje’, gdzie jest używane.

Event Log

można przeglądać live i offline. ponieważ jednym z pierwszych kroków jest zabezpieczenie logów i powinno się ograniczać pracę w zagrożonym środowisku, poniższy przykład pokazuje jak przeglądać wyeksportowane logi w poszukiwaniu aktywności użytkownika:

logi z DC nie są synchronizowane, każdy DC ma własne, w związku z tym trzeba wyeksportować z każdego oddzielnie. okazało się, że nie każdy to wie, więc tak na wszelki wypadek przypominam…
okazuje, nie jest również oczywiste, że logowanie nieudanych prób logowania jest co najmniej tak samo ważne, jak logowanie udanych. nieudane próby mogą świadczyć o próbie bruteforce na kontach albo po prostu próbach nieautoryzowanego dostępu
następnie można przeszukać korzystając z Get-WinEvent. problem z obróbka polega na tym, że zwrócony hashtable nie ma ustalonego formatu – zależnie od typu zdarzenia będzie inna ilość pól
poniższy przykład obrazuje wyszukiwanie udanych (4624) i nieudanych (4625) zdarzeń logowania dla kont 'account01′ oraz 'account02′
nazwy kont są bez domeny, match korzysta z regex więc dowolnie rozbudowywać i wyszukuję po atrybucie 'message’ ponieważ nazwa użytkownika przy tych zdarzeniach jest *zazwyczaj* na 6 pozycji w tablicy.. ale nie zawsze. dzięki przeszukaniu zawartości 'message’ wyłapuje się więcej

$events = Get-WinEvent -Path "C:\incident01\DC01_security.evtx" | Where-Object { ($_.ID -eq 4624 -or $_.ID -eq 4625) -and $_.message -match 'account01|account02'}
$events += Get-WinEvent -Path "C:\incident01\DC02_security.evtx" | Where-Object { ($_.ID -eq 4624 -or $_.ID -eq 4625) -and $_.message -match 'account01|account02'}
$events += Get-WinEvent -Path "C:\incident\DC03_security.evtx" | Where-Object { ($_.ID -eq 4624 -or $_.ID -eq 4625) -and $_.message -match 'account01|account02'}
$events|%{"{0},{1}" -f $($_.Properties.value -join ','),$_.TimeCreated}|Out-File C:\incident01\events_aggregated.csv

a jak ktoś korzysta z eNLib to jeszcze można sobie ułatwić życie i obejrzeć sformatowane w Excel:

&(convert-CSV2XLS c:\incident01\events_aggregated.csv)

smutną informacją będzie, że klasyczne logi Windows pokazują gdzie nastąpiło uwierzytelnienie… ale nie pokazują skąd – co w przypadku logowania sieciowego jest dużym brakiem, bo znalezienie gdzie takie konto w zasadzie jest używane bywa trudne. przydatna będzie również wiedza dotycząca właśnie typu logowania, a najważniejsze to:

Type 2 – klasyczne logowanie lokalne
Type 3 – non-interactive, network logon
Type 5 – non-interactive, service logon (chyba najtrudniejszy w interpretacji)

żywe elementy systemu

jak na szybko sprawdzić czy coś nie działa w kontekście danego użytkownika?

task scheduler:

Get-ScheduledTask | select TaskName,@{L='context';E={$_.Principal.ID}}|sort context

usługi systemowe:

gcim win32_service|select name,startname|sort startname

oraz procesy:

Get-Process | ForEach-Object {
    $process = $_
    $cimProcess = Get-CimInstance -ClassName Win32_Process -Filter "ProcessId = $($process.Id)"
    $owner = Invoke-CimMethod -InputObject $cimProcess -MethodName GetOwner
    [PSCustomObject]@{
        Name = $process.Name
        Id = $process.Id
        Owner = $owner.User
    }
}

warto zwrócić uwagę na get-CimInstanstance zamiast get-WmiObject – i to trochę będzie zależało od wersji systemu. na bardzo starych Windowsach może być problem z CIM, a na nowych nie działa już gwmi.

Exit

chmury, SIEM, EDR, XDR, MFA, całe to AI i przełomy technologiczne… łatwo zapomnieć że to tylko fragment świata – tego lepiej dofinansowanego, rozwiniętego, technologicznego… ale jest też druga strona. środowiska on-premises, skonfigurowane… mówiąc delikatnie, odbiegając od jakichkolwiek norm i standardów, gdzie klienci nie rozumieją tego co jest potrzebne lub niepotrzebne w środowisku – widzą tylko czy działa aplikacja na ich komputerze i tylko tyle są w stanie ocenić. cała reszta to jakiś techniczny bełkot, którego nie chcą słyszeć… a zazwyczaj również nie bardzo za to płacić.

często zastanawiam się nad tym dysonansem – z jednej strony wydaje się, że technologiczna osobliwość jest tuż tuż i czytam artykuły straszące AI, które przejmie władzę nad światem i kolonizacji Marsa, a z drugiej ta część świata, w której pracują systemy z przed dekad czy te odległe miejsca, w których szczytem technologii jest żarówka i kuchenka gazowa…

eN.

App Registrations vs Enterprise Apps

gru 13, 2023nExoRCloud, tips'n'tricks

różnica pomiędzy App Registrations a Enterprise Apps w EntraID niby jest oczywista.. ale po chwili zastanowienia robi się dość niejasna i sprawia problemy. zgodnie z zasadą Feynmana, która mówi, że naprawdę rozumie się tylko to, co potrafi się w przystępny sposób wytłumaczyć, długo miałem z tym problem. niby wiedziałem… ale nie byłem w stanie odpowiedzieć na to pytanie przekonywająco.

normalnie poleciłbym opis mojego ulubionego 'nauczyciela Azure’ – John Savill, ale o ile uważam, że bardzo warto obejrzeć ten wykład, nie do końca dobrze tłumaczy to, co najważniejsze. bardzo fajnie rozkłada na czynniki pierwsze model uwierzytelnienia i autoryzacji i pokazuje workflow podczas uzyskiwania dostępu – a więc arcyważny i ciekawy element… ale prezentacja urywa się tam, gdzie tak na prawdę powinna się zacząć. i kiedy dochodzi już do pokazania praktycznej różnicy pomiędzy App Registrations i Enterprise Apps – czegoś mi zabrakło – zbyt dogłębnie, za mało praktycznie.

to coś, czyli bardziej praktyczne wyjaśnienie tych elementów, znalazłem natomiast tu:

Azure – App registration and Enterprise Applications

tłumaczy 'po mojemu’ – trochę teorii, trochę praktyki, jak to 'dotknąć’ PowerShell’em i po co to wszystko. to pierwsza z kilku części dotyczących tego tematu (SIC!), co pokazuje, że wcale nie jest taki trywialny i oczywisty – i tak patrząc na inne ich spotkania, jeszcze trochę czasu poświęcę na ich nagrania.

eN.