Obronić się przed MiTM

Minęło wiele lat od kiedy napisałem tu ostatni post a do tego temat na (re)debiut już nie jest gorący. Chociaż z drugiej strony nie zdążył jeszcze wystygnąć i w każdej chwili może ponownie wybuchnąć. Ale do rzeczy. Dziesięć miesięcy temu okazało się, że przez pół roku Lenovo raczyło swoich użytkowników certyfikatami umożliwiającymi ataki MiTM (https://www.us-cert.gov/ncas/alerts/TA15-051A). Wiadomo, generalne oburzenie, Chińczycy nas śledzą, na pewno to sprawa służb, teorie spiskowe  i w ogóle koniec świata. Szczerze mówiąc temat spłynął po mnie jak po kaczce, sprawdziłem swój tablet (kupiony w przypływie weny wracając z baru po spotkaniu świąteczno noworoczny) i zapomniałem o temacie. Potem gdzieś pojawił się problem z Dell System Detect i zdalnym wywołaniem kodu, który został załatany przed opublikowaniem dziury (http://tomforb.es/dell-system-detect-rce-vulnerability). To ruszyło mnie trochę bardziej, sprawdzanie kto ma zainstalowane oprogramowanie i usunięcie starych wersji okazało się nie być trzema kliknięciami ale koniec końców temat załatwiony i systemy załatane w kilka godzin.

Niby dwie z pozoru niepowiązane rzeczy a jednak ostatnio okazało się, że niektórzy wolą się uczyć na własnych błędach zamiast na cudzych i Dell obdarzył nas kolejną serią serią wpadek (http://joenord.blogspot.in/2015/11/new-dell-computer-comes-with-edellroot.html,http://www.kb.cert.org/vuls/id/925497) instalując razem ze swoim oprogramowaniem certyfikaty w Trusted Root razem z ich kluczami prywatnymi. Do tej pory jest jeszcze prawie ok. Oprogramowanie potrzebuje coś samo podpisać żeby system się nie burzył przy instalacji, certyfikat jest oznaczony jako nieeskportowalny. Nie jest najgorzej, w końcu to narzędzie systemowe a nie aplikacja pokazujące  reklamy jak w przypadku Lenovo i jesteśmy zadowoleni dopóki nie zauważymy, że nasz kolega ma ten sam certyfikat a ktoś nam powie, że klucz prywatny można wyeksportować na przykład za pomocą mimikatz.

W głowie zaczynają układać się klocki pokazujące bardzo prosty scenariusz ataku:

  1. Eksportujemy certyfikat (patrz link powyżej)
  2. Stawiamy darmowe WiFi z SSID Starbunio i idziemy w pobliże kawiarni
  3. Czekamy na kogoś z laptopem Della kto podłączy się do naszego WiFi i otworzy stronę, którą warto przechwycić
  4. Zmieniamy SSID i miejsce bo w naszym pierwotnym celu są same błyszczące Maci
  5. Bingo, złapaliśmy klienta otwierającego stronę banku. Dla niego wszystko wygląda w porządku, jest https, jest zielona kłódeczka a przeglądarka nie ma żadnych podejrzeń. Dopiero jak gość będzie bardzo dociekliwy to okaże się, że certyfikat uwierzytelniający bank wystawił Dell a nie Verisign. My sobie po drodze cały ruch odszyfrowujemy, podmieniamy numery kont (bo kto to sprawdza w smssach) i jesteśmy szczęśliwi.

Problem pojawia się kiedy zdamy sobie sprawę, że nie tylko my możemy tak zrobić a nasi użytkownicy na pewno nie sprawdzają za każdym razem kto wystawił certyfikat stronie i możemy się założyć, że kwestią czasu jest kiedy wypłyną dane z naszej firmy albo ktoś dostanie karnego na Facebook’u. A co jeśli nie tylko Dell i Lenovo mają problem z certyfikatami? Będziemy czekać na białe kapelusze aż opublikują artykuły i łatać za każdym razem licząc na to, że czarne kapelusze nie wkroczyły jeszcze do akcji? A może pójdziemy o krok dalej i będziemy bardziej proaktywni sprawdzając czy mamy jakiekolwiek podejrzane certyfikaty na naszych komputerach?

Teoria mówi, że żaden certyfikat znajdujący się w Trusted Root Certification Authorities nie powinien mieć klucza prywatnego. Gdzieś daleko od nas jest CA a my jemu ufamy ponieważ znamy klucz publiczny CA pasujący do klucza prywatnego używanego do podpisywania certyfikatów. Tyle teorii, praktyka okazuje się być trochę bardziej brutalna ale o tym później.

Kiedy mamy problem z pomocą przychodzi korporacyjna nowomowa i nagle problem staje się on wyzwaniem, a kto nie lubi wyzwań? Do tego jeszcze można zaprzęgnąć lubianego PowerShell i System Center lubiane … inaczej ;)

Zaczynamy od kawałka banalnego kodu:

foreach($BaseStore in Get-ChildItem cert:\)
{
   Get-ChildItem $BaseStore.PSPath -Exclude "My","Remote Desktop","SMS" |ForEach-Object{
      [array]$comptmp = Get-ChildItem $_.PSPath |Where-Object {
         $_.HasPrivateKey `
         -and $_.Subject -notmatch 'DO_NOT_TRUST_FiddlerRoot' `
         -and $_.Subject -notmatch $env:COMPUTERNAME
      }
   [array]$Compromised += $comptmp
   }
}
if($Compromised.Count -eq 0){
   return "Compliant"
}
else
{
   $output = ($Compromised | Out-String)
   return $output
}

Który przeleci nam po wszystkich dostępnych certificates stores wyłączając z tego:

  • My – certyfikaty użytkownika/komputera
  • Remote Desktop – to chyba nie wymaga tłumaczenia
  • SMS – certyfikaty używane przez klienta SCCM

w tym kroku można się pokusić jeszcze o wyłączenie innych rzeczy (np. certyfikatów klienta SCOM) albo zamianę

Get-ChildItem $BaseStore.PSPath -Exclude "My","Remote Desktop","SMS"

na

Get-ChildItem $BaseStore.PSPath -Include "Root"

żeby zaglądać tylko do Trusted Roots. Na razie trzymajmy się pierwszej wersji żeby zobaczyć co się w ogóle dzieje.

 

Jak już wiemy jakie mamy Certificates Stores to warto do nich zajrzeć i zobaczyć jakie mamy certyfikaty z kluczami prywatnymi

[array]$comptmp = Get-ChildItem $_.PSPath |Where-Object {
     $_.HasPrivateKey `
     -and $_.Subject -notmatch 'DO_NOT_TRUST_FiddlerRoot' `
     -and $_.Subject -notmatch $env:COMPUTERNAME
}

żeby uniknąć szumu wywalamy:

  • certyfikat Fiddlera – jego celem jest robienie MiTM i osoby mające go na komputerach wiedzą co robią
  • certyfikat zawierający z temacie nazwę hosta – tak to ciągle jest niebezpieczne ale wiemy, że ten certyfikat mamy tylko my i ewentualnie ktoś kto go nam wygenerował a nie cały internet. Takie świństwa podrzuca na przykład Skype ze skonfigurowanym Click to call

Reszta to proste działania mające na celu sprawdzenia czy mamy jakiekolwiek podejrzane certyfikaty i podanie ich listę lub potwierdzenie, że komputer jest ok.

 

Kiedy mamy już PowerShell to warto byłoby uruchomić go na wszystkich komputerach i sprawdzić kto ma coś podejrzanego na swojej maszynie. Fajnie byłoby też aby sprawdzanie odbywało się cyklicznie i informowało nas kiedy jest coś nie tak. Tutaj przydaje się SCCM i Compliance Settings.

Tworzymy Configuration Item uruchamiające skrypt i sprawdzające co jest na wyjściu

Configuration item

2015-12-08_21-47-13

Compliance Rules

2015-12-08_21-47-35

Compliance Rule

Potem robimy Configuration Baseline, dodajemy do niego nasz Configuration Item i robimy Deploy na kolekcje użytkowników oraz na kolekcje komputerów (odpowiednio All Users i All Systems). Ostatnie może się wydać trochę dziwne ale jest potrzebne żeby sprawdzić zarówno co mają użytkownicy jak i konto local system. Configuration baseline uruchomiony w kontekście systemu (Deploy na kolekcję komputerów) nie może zajrzeć do certyfikatów użytkowników bo te są trzymane w profilach*, a użytkownicy nie mogą zobaczyć jakie certyfikaty ma konto local system, za to zarówno użytkownik jak i local system mogą sprawdzić zawartość Certificate Store: Local Machine.

*-to nie jest do końca prawda bo można podmontować Hive i dekodować certyfikaty ale są na to prostsze sposoby

Jakby ktoś się pokusił dodatkowo o Remediation script żeby usuwać podejrzane certyfikaty to warto pamiętać, że Local System będzie mógł usuwać certyfikaty zarówno swoje jak o Local Machine a użytkownik będzie mógł usuwać wyłącznie swoje.

Na koniec pozostaje skonfigurowanie alertów, wysyłanie ich do SCOM i workflow do obsługi zdarzeń ale to już temat na osobny wpis.

 

AD FS – zmiana certyfikatu SSL

AD FS (Active Directory Federation Services) to usługa bezpiecznego udostępniania tożsamości poprzez jednorazowe logowanie (SSO), dzięki tej usłudze jesteśmy w stanie zalogować się do aplikacji zewnętrznych wykorzystując login/hasło konta z Active Directory.

W przypadku mojej konfiguracji są to dwa serwery działające w trybie farmy AD FS, dzięki nim użytkownicy domeny którą zarządzam są w stanie zalogować się wykorzystując swój login/hasło np. do Google Gmail lub Office 365. Nadmienię tylko, że w trybie farmy konfiguracja serwerów jest synchronizowana – zmiany wprowadzamy tylko na jednym, głównym serwerze, przy próbie ręcznego wprowadzenia zmian na drugim serwerze dostaniemy informację, że zmiany możliwie są do wprowadzenia tylko i wyłącznie na serwerze oznaczonym jako „Primary”

….

Jak dobrze wiecie certyfikaty wygasają ;-) , więc pewnie za jakiś czas każdy kto zajmuję się usługą Active Directory Federation Services stanie przed problemem zmiany certyfikatu SSL.

AD FS 2.2 (2012 R2) nie wymaga IIS, więc zmiana certyfikatu odbywa się trochę inaczej.

Byłem przekonany, że zmiana certyfikatu Service communication odpowiedzialnego za szyfrowanie wszystkich połączeń klientów wystarczy, okazało się,że nie. Przeglądarka twardo informowała, że korzysta ze starego certyfikatu…

Zmiana certyfikatu Service communication

AD FS Management -> Service -> Certificates -> Set Service Communication Certificate

Sam certyfikat, który wykorzystywany jest przez przeglądarkę zmienimy już tylko wykorzystując polecenia PS.

Set-AdfsSslCertificate -Thumbprint thumbprint

Do sprawdzenia czy został zmieniony:

Get-AdfsSslCertificate

Na koniec restart usługi AD FS, test w przeglądarce.

ozz.

Lepsze wrogiem dobrego

Na dobre nastał Ms Office 2013. Funkcjonalność nowych wersji zgubiłem gdzieś w okolicach 2007, ale z tym da się żyć. Rozumiem też, że nowe wersje są konieczne z wielu powodów, głównie finansowych. Nie zmienia się jedynie procent wykorzystania możliwości kolejnych Officów przez „standardowego użytkownika”, który od wersji 95 oscyluje w granicach 1.
Nie o tym jednak jest ten wpis.
Cały czas staram się wskazywać klientom, że rozwiązania IT takie jak Ms Office to nie tylko edytor do napisania listu motywacyjnego, ale cały ekosystem, który odpowiednio użyty potrafi drastycznie zwiększyć wydajność każdej instytucji. Cały czas też spotykam się z tzw. „barierą Crtl-C/Crtl-V” – która jasno pokazuje, że te dwa skróty klawiszowe są maksymalnym pułapem wykorzystania funkcjonalności najlepszego programu biurowego poprzez „zwykłego użytkownika”. Fakt, że w roku 2014 wykorzystanie śledzenia zmian przy pracy nad dokumentem wciąż jest ewenementem wywołuje myśli samobójcze w działach IT i nie tylko ale też nie jest tematem tego wpisu.
Do rzeczy zatem. Na nic moje starania, gdy odbijam się od wściekłego użytkownika, który nie może pracować, bo „pan informatyk zainstalował nowe i zepsuł”  Potwierdzone, co prawda jedynie moim przeczuciem statystyki awaryjności Offic’a 2013 a ZWŁASZCZA Outlooka z ostatniego pół roku, które dotknęły wszystkich – od domowych użytkowników wersji „zgodny z oryginalną” po korporacje z domeną i tych z Officem 365 mówią jedno – coś poszło nie tak.
Zwiechy przy ładowaniu, przycinanie się, aż po całkowitą niemożność załadowania profilu wszystko po zainstalowaniu Office’a 2013. Dotyczy nie tylko Outlooka, ale także pozostałych programów.
Zanim dotrą łatki, rozwiązanie które działało w ok 95% przypadków.

Disable hardware acceleration

1. Run regedit (Win + R ; „regedit”)
2. Browse to HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common
3. Create a New Key and name it „Graphics”
4. Select Graphics, right-click on the right panel and create a New DWORD (32-bit) Value and name it DisableHardwareAcceleration.
5. Enter Value data as 1

Nie mam bladego pojęcia, co robi ten wpis w rejestrze, ale działa.

Postaw ptaszka

Od wersji Windows Server 2008 mamy dostępną w AD opcję „ProtectedFromAccidentalDeletion”. Generalnie nigdy bym nie pomyślał, żeby kiedykolwiek miało by sens używanie tej opcji, ale od niedawna dodaję ją jako wymaganą i  k_r_ y_t_y_c_z_n_ą  praktycznie w każdej mojej dokumentacji, która zawiera opis obiektów AD.

Generalnie nie ma większego problem gdy skasujemy obiekt komputera czy użytkownika. Nawet jeśli jest to konto serwisowe, po kilku minutach możemy sytuacje  naprawić. Ja jednak byłem świadkiem sytuacji w której jakiś durny program, lub admin … a generalnie admin nawet jak był to program …skasował obiekt serwisu klastra (hosta Cluster Service). To spowodowało, że przestała działać cała instancja SQL oparta na tym klastrze i inne usługi (np.. MSDTC). Obiekt nie jest prosty, więc od tak nie można go sobie stworzyć. Cały klaster SQL oparty na MSCS w zasadzie byłby do przeinstalowania a dokładniej każdy node musiał by być wyciągnięty z clustra, następnie trzeba by było usunąć wszystkie ślady po cluster service i poinstalować wszystko od początku. Roboty, przy kilku nodach na około 8 godzin (a produkcja leży!). Na szczęście jest na to myk .. Ale o tym w kolejnych wpisach.

Generalnie myślałem, że problem był wyjątkowy i że już nic gorszego się stać nie może. Środowisko bez  SPoF. Cały sprzęt nadmiarowy, urządzenia sieciowe dobrej klasy, load balancery, macierze itp. … Ale nie doceniłem adminów.

Po kilku dniach kolejna awaria. Ktoś dopatrzył że są 3 podobne do siebie nazwy komputerów… SuperProdDB1, SuperProdDB2 i SuperProdDB. Popingał, popatrzył na listy VMwareów i postanowił zrobić porządek. Skasował wpisy DNS SuperProdDB. Był to host name dla instancji klastra SQL  składającego się z w/w nodów.

Naprawa tego poszła już znacznie sprawniej.

Generalnie … postaw ptaszka!

Przenieś/Kopiuj do folderu…

Opcja bardzo przydatna i niedostępna domyślnie w windowsach.

przen

Ku pamięci zapisuję, może ktoś jeszcze skorzysta :)

W drzewie HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers

Dla „kopiowania” dodajemy klucz o nazwie „kopiuj do” i wartości domyślnej

{C2FBB630-2971-11D1-A18C-00C04FD75D13}

Dla „przenoszenia dodajemy klucz o nazwie „przenies do” i wartości domyślnej

{C2FBB631-2971-11D1-A18C-00C04FD75D13}

Wartości przepisujemy/kopiujemy razem z nawiasami klamrowymi jako jeden ciąg znaków!

Załączam gotowe pliki .reg dla leniwych lub nietechnicznych -> copyto_moveto

Po rozpakowaniu wystarczy je uruchomić i zatwierdzić.

 

 

 

Gdy skasujesz konto w Windows Live na komputerze

Właśnie ktoś miał problem, bo skasował sobie konto razem z całą pocztą i nigdzie nie miał backupu.

Przetestowaliśmy poniższe rozwiązanie i działa, więc ku pamięci:

  1. Closed Windows Live Email.
  2. Made a backup copy of C:\Users\Philu\AppData\Local\Microsoft\Windows Live Mail and also of C:\Users\Philu\AppData\Local\Microsoft\Windows Mail (not sure if that second directory is needed but I did it too, just to be safe).
  3. Made a System Restore Point.
  4. Downloaded and installed ShadowExplorer.
  5. Selected the most recent time in the Toolbar button.
  6. In the navigation pane, navigated to C:\Users\Philu\AppData\Local\Microsoft.
  7. Right-clicked on Windows Live Mail and exported it to a temporary directory.
  8. Did the same for the Windows Mail directory.
  9. Closed ShadowExplorer.
  10. Opened Windows Explorer.
  11. Cut C:\Users\Philu\AppData\Local\Microsoft\Windows Live Mail and alsoC:\Users\Philu\AppData\Local\Microsoft\Windows Mail and pasted them into another backup directory.
  12. Moved my exported copies of Windows Live Mail and Windows Mail from steps 7 and 8 into C:\Users\Philu\AppData\Local\Microsoft.
  13. Opened Windows Live Mail.
    All my mail was back!

Źródło: http://powerphil.wordpress.com/2011/02/11/how-to-recover-email-after-deleted-windows-live-mail-account/

Przyspieszyć IIS

Zabieram się do tego artykułu jak pies do jeża chyba więc prościej będzie wrzucać treść na raty…

Problem:
Zmieniam coś w konfiguracji lub podmieniam coś w aplikacji webowej. Wykonuję iisreset. Pierwsze użycie stronki trwa wieki. Nieważne czy jest to Sharepoint czy prosta witryna z gołą babą. Uruchamianie worker procesów, kompilowanie aplikacji, sprawdzenie certyfikatów a raczej CRLi … to wszystko zabiera nam cenne sekundy. Do tego Application poole mają swoje czasy uśpienia i recycling co powoduje, że przy braku użytkowników, strona znowu usypia… Przy rzadko odwiedzanych stronach generalnie mamy wrażenie że coś jest nie tak i za każdym razem musimy czekać nawet dwie minuty by zobaczyć efekt końcowy. Jak z tym walczyć? No jest kila trików, między innymi „warm up” skrypty w PS używane od lat przez Microsoft przy prezentacjach Sharepointów… Nie opisze tutaj wszystkich sztuczek a jedynie podam prosty sposób na  automatyczne wymuszenie uruchomienia application poola czyli uruchomienia worker procesu na IIS. Bez zaawansowanych skryptów i potrzeby wnikliwego analizowania swojej aplikacji.

Rozwiązanie:
Narzędzie stworzone do IIS 8 dostępne dla IIS 7.5 o nazwie Application Initialization
Użycie banalne, składające się z dwóch kroków.

  1. Instalacja Application Initialization
    1. Uruchom appwarmup_x64.msi
    2. Zrestartuj server
  1. Wybierz który application pool ma być zawsze uruchomiony
    1. Uruchom CMD jako Administrator
    1. Przejdź do lokalizacji c:\Windows\system32\inetsrv\
  1. Przykładowo dla DefaultAppPool uruchom
    appcmd.exe set apppool „DefaultAppPool” /startMode:AlwaysRunning

W ramach sprawdzenia możesz zrobić iisreset i zobaczyć że na liście Worker processów pojawi się DefaultAppPool pomimo braku wywołania strony.

Generalnie wypróbujcie to w domu, u mnie 120 sekund do przodu ;)

SCCM – rozszerzamy Hardware Inventory

Zbierałem się do napisania artykułu, a wyszło jak zwykle Puszczam oczko

Więc szybka notka na blogu:

SCCM za pomocą Hardware Inventory potrafi zbierać informacje nie tylko o sprzęcie, ale o wszystkim co mamy zapisane w WMI. Szczegółowo jest to opisane na MyITForum – http://www.myitforum.com/myitwiki/SCCMINV.ashx 

Ostatnio trafił mi się przypadek – zbierz info o wszystkich profilach użytkowników i ich ścieżkach.

Najpierw trzeba wyciągnąć info z kluczy rejestru HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList

Więc do pliku configuration.mof dodajemy na końcu sekcję:

#pragma namespace("\\.\root\CIMV2")

#pragma deleteclass("Local_SID_List",NOFAIL)

[dynamic,provider("RegProv"),ClassContext("Local|HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList")]

Class Local_SID_List

{

  [key]   string KeyName;

  [PropertyContext("ProfileImagePath")]  String ProfileImagePath;

};

Dzięki temu na każdym komputerze z zainstalowanym agentem SCCM-a w rootcimv2 stworzy się klasa Local_SID_List, która automatycznie będzie się wypełniać kluczami rejestru. Dzięki temu mamy parę: SID <-> profil

Teraz trzeba połączyć SID <-> User. Żeby to osiągnąć dodajemy do tego samego pliku następną sekcję:

#pragma namespace("\\.\root\cimv2")

#pragma deleteclass("User_Account",NOFAIL)

 

[Union,ViewSources{"select * from Win32_Account where SIDType=1"},ViewSpaces{"\\.\root\cimv2"},dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]

Class User_Account

{

  [key,PropertySources{"Domain"}]    string    Domain;

  [key,PropertySources{"Name"}]    string    Name;

  [key,PropertySources{"SID"}]    string    SID;

};

Na każdym kompie wyciągnie info o użytkownikach lokalnych. Jeśli chcemy mieć info o SIDach kont domenowych, to musimy po prostu mieć agenta SCCM na jednym z kontrolerów domeny (konta domenowe mają swoje instancje w klasie Win32_Account)

Teraz trzeba zmusić agentów SCCM, żeby raportowali info z lokalnego WMI (instancje klas Local_SID_List i User_Account) do serwera. W tym celu modyfikujemy plik sms_def.mof

#pragma namespace("\\.\root\cimv2\sms")

#pragma deleteclass("Local_SID_List",NOFAIL)

[SMS_Report(TRUE),SMS_Group_Name("Local_SID_List"),SMS_Class_ID("SMSExpert|Local_SID_List|1.0")]

Class Local_SID_List : SMS_Class_Template

{

  [SMS_Report(TRUE),key] string   KeyName;

  [SMS_Report(TRUE) ]    string   ProfileImagePath;

};

 

#pragma namespace("\\.\root\cimv2\SMS")

#pragma deleteclass("User_Account",NOFAIL)

[SMS_Report(TRUE),SMS_Group_Name("User_Account"),SMS_Class_ID("SMSExpert|Local_User_Account|1.0") ]

Class Local_User_Account : SMS_Class_Template

{

  [key,SMS_Report(TRUE)]    string    Domain;

  [key,SMS_Report(TRUE)]    string    Name;

  [key,SMS_Report(TRUE)]    string    SID;

};

Teraz SMS Provider na serwerze sam stworzy dane w bazie SQL (w formie tabel i perspektyw), które możemy wykorzystywać do tworzenia raportów. Jeśli nie chce nam się bawić w SQLki, to można na maszynie uruchmić SCCMowy Resource Explorer i obejrzeć wyniki Hardware Inventory.

Co do dokładnego procesu tworzenia raportów – to już temat na inny wpis Uśmiech