Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
srpen 17
Jak vzniká pocit, že Windows je úplně zabagovanej

Třeba takto. Nějakej "výzkumník" objeví (dlouho známý) velmi těžko zneužitelný nedostatek a když o tom napíše dostatečné hrozivý článek tak je z toho hned poprask a lidi ládují do registrů bezhlavě hodnoty, které zablokují všechno. Ten článek je v podstatě komplet přehnané strašení. Upozorňuje to explicitně navíc na firemní oběti, protože to ani pro workgroup počítače ani pro doménové stroje mimo dosah DC nefunguje.

Zaprvé to využívá SMB přístup do internetu. Jestli má firma na svém firewallu povolen zevnitř přístup na SMB do internetu, tak to se pak nemá proč divit. Druhak jestli firma neimplementuje žádnou multifaktorovou autentizaci, tak se nemá čemu divit. Takže prostor pro útok je minimální.

Třeťak to vychytává NTLMv2 response. Což je zasolená MD5 hash hesla. Takže jestli má uživatel správně dlouhé a komplexní heslo, to znamená alespoň 12 znaků, tak při použití nejrychlejšího nástroje hashcat a jedné GPU za cca 5000 Kč to bude krekovat cca 76 000 let. Takže drama největší. Začal jsem se toho děsně obávat.

Pokud chce někdo vychytávat hesla uživatelů, tak garantuju, že pokud uděláte stránku s nápisem "přihlašte se pomocí svého firemního účtu", tak to do toho formuláře zadá každý druhý uživatel a nemusí se krekovat žádná hash.

Dále rada na konci článku ohledně použití hodnoty RestrictReceivingNTLMTraffic a RestrictSendingNTLMTraffic je už úplný nesmysl, to se na mě nezlobte. Blokovat "receiving NTLM" (neboli Network Security: Restrict NTLM: Incoming NTLM traffic) tzn. příjem NTLM na straně podnikového klienta nejspíš provozně nevadí, ale zaručeně to neřeší popisovanou vulnerabilitu.

Ano, zablokovat "sending NTLM" (neboli Network Security: Restrict NTLM: Outgoing NTLM traffic) by proti tomuto "útoku" ochránilo. Dobrá tak to udělejte a užijte si těch padesát věcí, které vám potom nepojedou. Tohle nastavení, tedy zablokovat NTLM se snažím dělat posledních pár let všude, kde dělám nějaké zabezpečení a ze zkušenosti můžu garantovat, že to udělat nemůžete. Protože vám potom x věcí prostě nepojede. První je RDP v 90% případů. Druhý je SQL klienti v 50% případů. NTLM prostě v podnikové síti vypnout nejde, protože to na to není připravené. Howgh.

Takže až zase budete číst nějaké strašáky, tak to berte jako stejnou propagandu, jako jsou libovolné jiné zaručeně "nejdůvěryhodnější" články o politice, válkách, společnosti, ekologii apod.

srpen 15
Narozen hackerem :-)

Jsem prostě rozenej hacker :-) Dojdu po měsíci školit do GOPASu v Praze a vidím, že máme na učebnách nové hypermoderní displeje zobrazující seznam účastníků a také heslo na WiFi a kód na dveře. Asi jsem se narodil hackerem, protože první co mě napadlo, bylo jít se podívat ven, jestli ten kód na dveře není vidět skrze naše skleněné dveře. Dveře jsou prosklené, s kódovou klávesničkou, a přímo za nimi jsou učebny s viditelnými displayi :-)

No trošku mě zklamalo, že to vidět není. Údajně to dřív vidět bylo, ale už si toho někdo všiml a panely na inkriminovaných místech zobrazují jen hvězdičky :-)

Škoda, těšil jsem se, že budu mít hezkou přednášku na HackerFest :-)

červenec 20
Vyhledání adresářů, které se už dlouho nezměnily

Problém - máme file server a potřebujeme najít všechny adresáře, jejichž obsah se už dlouho nezměnil. Použijeme k tomu samozřejmě PowerShell. Vyhledat dlouho nezměněné soubory není vůbec problém, stačí porovnat jejich atribut LastWriteTime. Jenže tohle nechceme, bude toho obvykle (sto)(deseti)tisíce, prostě mnoho. Já chci vidět jen adresář, jehož celý obsah má poslední modifikaci starší, než například 410 dnů.

Takže zde je funkce, která prohledá celou adresářovou strukturu a vrátí jen adresáře, jejichž žádný soubor se nezměnil nedávno, než před nějakým počtem dnů.

function Get-FsAgeMap (
  [Parameter(Position=0, Mandatory=$true)] [ValidateScript({ Test-Path $fsRoot })] [string] $fsRoot,
  [Parameter(Position=1)]                  [ValidateScript({ $_ -ge 0 })] [int] $ageDaysAtLeast = 0,
                                                                          [switch] $returnOnlyParent
  )
{
  if ($returnOnlyParent -and ($ageDaysAtLeast -eq 0)) {

    throw 'You must specify some minimum days of age to use the -returnOnlyParent parameter'
  }

  $fsRoot = $fsRoot.TrimEnd('\')

  [hashtable] $ageMap = @{}
  [bool] $uncFsRoot = $fsRoot -like '\\?*\?*'

  # Note: using -Force parameter in order to obtain System and Hidden files as well
  dir $fsRoot -Recurse -Force | ? { -not $_.PsIsContainer } | % { 

    [IO.FileInfo] $oneFile = $_
    [int] $ageDays = ([DateTime]::Now - $oneFile.LastWriteTime).TotalDays

    [string] $onePath = $oneFile.FullName
    while ($true) {

      [string] $onePath = Split-Path -Parent $onePath

      if ((-not ([string]::IsNullOrEmpty($onePath))) -and ($onePath.Length -ge $fsRoot.Length)) {

        if ($ageMap.ContainsKey($onePath)) {

          $ageMap[$onePath] = [Math]::Min($ageDays, $ageMap[$onePath])

        } else {

          [void] $ageMap.Add($onePath, $ageDays)
        }
      
      } else {

        break
      }
    }
  }

  if ($ageDaysAtLeast -gt 0) {

    [Collections.ArrayList] $ageMapKeys = $ageMap.Keys
    foreach ($oneAgeMapKey in $ageMapKeys) {

      if ($ageMap[$oneAgeMapKey] -lt $ageDaysAtLeast) {

        [void] $ageMap.Remove($oneAgeMapKey)
      }
    }

    if ($returnOnlyParent) {

      [Collections.ArrayList] $ageMapKeys = $ageMap.Keys
      $ageMapKeys.Sort()

      [int] $i = 0
      while ($i -lt $ageMapKeys.Count) {

        [string] $oneAgeMapKey = $ageMapKeys[$i]
        $i ++

        while (($i -lt $ageMapKeys.Count) -and ($ageMapKeys[$i] -like (Join-Path $oneAgeMapKey '?*'))) {

          [void] $ageMap.Remove($ageMapKeys[$i])
          $i ++
        }
      }
    }
  }

  return $ageMap
}

Zavoláte to jednoduše, buď s pomocí lokální cesty, nebo pomocí UNC síťové cesty, to je jedno. Parametr returnOnlyParent způsobí, že ve výsledku budou opravdu jen ty nejvrchnější adresáře. Pokud byste to tam nedali, tak by to vrátilo všechny adresáře, jejichž obsah je starší než zadaný počet dnů, takže by tam jedna podcesta byla zbytečně vícekrát. Například takto:

$ageMap = Get-FsAgeMap -fsRoot '\\fs1\profiles' -ageDaysAtLeast 210 -returnOnlyParent

 

červen 15
Všechno je tu boží!

Dvacet minut, padesát poslechů a ještě najít anglická slova jsme tu museli, abychom zjistili český text Všechno je tu boží z filmu Lego příběh. Ten čtvrtý verš není skoro rozumět.

Tak výsledek je tady:

všechno je tu boží
všechno jde ti líp když jsi týmový hráč
všechno je tu boží
tak teď žít chcem sen náš

Teď už si to z hlavy nikdy nevyndám :-)

červen 15
Mimikatz se nezajímá o délku hesla

Zde je jednoscreenshotová odpověď na dotaz z dnešní konference časopisu Chip o Windows 10. Ano, mimikatz bere všechny délky hesel, čtrnáct znaků nehraje roli. Čtrnáct znaků hrávalo roli ve Windows XP, kde se pro delší hesla už neukládala LM hash, která šla kreknout pomocí rainbow table během pár sekund.

Na mé přednášce se jednalo o plné textové formy hesel v paměti lsass procesu, které tam sice taky někdy nejsou, ale určitě se to neřídí délkou 14 znaků:

květen 31
WPA a WPA2 otázka a odpověď ohledně rainbow table

Dneska dorazila otázka:

... Pak jsem se ale zacetl do ruznych doporuceni, napr http://cybercoyote.org/classes/wifi/wpa2.shtml a vsude se pise, ze nazev site ma byt nahodne generovanych 32 znaku a heslo 64 znaku ...

Due to the naive design of WPA2, the name of your network is the starting point for hackers. It is broadcast in the clear, and it's easy to look up your encryption key on widely available rainbow tables if your SSID is simple.

... Já jsem dosud žil v domění, že na názvu SSID záleží jen do tý míry, aby pokud možno neobsahovalo jméno firmy a tak nelákalo záškodníky. A že s 20znakovým heslem jsem v klidu. I když mám teda pocit, že jsem něco o vlivu dálky SSID taky nedávno čet. Ale když nad tím teď přemejšlím, tak mi není, jasný proč by to mělo mít vliv ...

Odpověď

To jsou mi zase rady. A nějaká teorie o jednoduchém SSID jak to jde pak strašně jednoduše krekovat pomocí rainbow-table.

Nezkoumal jsem to nějak moc do detailu, ale WPA a WPA2 údajně používají SHA-1 hash hesla zasoleného SSID (pairwise transient key (PTK)). To znamená, zjednodušeně, že se heš generuje z heslo+SSID. Tím se ten zahešovaný text prodlouží (obrazně řečeno, ono se to mixuje dohromady samozřejmě). Solí se to SSID aby nešlo poznat rovnou, že dvě sítě mají stejné heslo. Sůl je z definice soli známá a veřejná.

Pokud by útočník získal výslednou heš(heslo+SSID), tak z toho heslo přímo nedostane, od toho je tam ta hash. Může zkusit buď brute-force, nebo rainbow-table.

Aby to bylo lépe chráněné proti brute-force tak se ta SHA-1 hash zatočí ve skutečnosti 16388 krát, výpočet je tudíž poměrně pomalejší. Rychlost brute-force kreku pomocí https://hashcat.net a jedné GPU karty to krásně dokumentuje dole v tabulce. Zatímco to je schopné počítat pro SHA-1 celých 3 037 000 000 heší za sekundu, tak v případě WPA/WPA2 to dokáže pouze 142 000 heší za sekundu.

Jak dlouho by tedy trvalo kreknout WPA heslo z takto zahešovaného produktu? Řekněme heslo osm znaků, na každé pozici znaku cca 80 možných (26 malých, 26 velkých, 10 čísel a paušálně do 80 speciální znaky). Takových hesel na brute-force je 80^8 = 1 677 721 600 000 000. Děleno 142 000 za sekundu je 374 let.

Jak je na tom rainbow-table? Zaprvé si musíte uvědomit, že tu rainbow tabulku musí nejprve někdo napočítat, což by na tom jednom GPU trvalo přesně stejně, tzn. 374 let. Zadruhé to bude delší, protože rainbow tabulku musíte počítat pro osolená hesla. Takže v případě SSID délky 3 znaky a hesla pořád jen osmiznakového by to trvalo 80x80x80x374 let což je 192 milionů let. Možná trošku méně, protože do SSID si nedáváte speciální znaky.

A nejspíš ještě méně, protože každé dva roky se zdvojnásobuje výkon hardware, takže by se to postupem času zrychlovalo - až mě bude 90 let (je mi 36 let tzn. 2^27 krát rychlejší krek), tak to bude akorát hotovo.

Napočítat je pěkné. Ale taky musíte uvážit, že se ta tabulka musí někde uložit. Rainbow tabulka pro hesla osmiznaková má velikost 460 GB. Jenže tady při tříznakovém SSID máme heslo už jedenácti znakové. Taková tabulka by byla něco jako 10x10x10x460 GB (neroste to osmdesátkrát, rainbow-table jde komprimovat), což dělá pěkných 460 TB.

Takže až to ti borci z článku za 50 let napočítají, tak v té době už to asi moc místa žrát nebude :-)

Samozřejmě se dá spekulovat o tom, že bychom mohli počítač na více grafických kartách, ale to by zase stálo mnohem víc peněz. A to se tu bavíme o hesle osmiznakovém, což doufám každý už dávno ví, že osmiznaková hesla jsou obecně hodně špatně. Libovolné časy si vynásobte osmdesáti pro každý další znak v hesle.

A ani tak nemá útočník vyhráno. Má sice napočítanou rainbow-tabulku hodnot PTK. Jenže ono se to PTK nepřenáší jen tak samo, samozřejmě :-) To by se dal udělat reply útok. Každé ověření znovu ještě zasolí to PTK nějakým randomem.

Takže tu tabulku potom vezmete a opět netriviálně (ale už rychleji) přepočítáváte na jejím základě celou tu ověřovací transakci.

Naivní design?

květen 24
Aktuální hitovka - kontrola ukradené emailové adresy

​V poslední době je žhavým hitem možnost nechat si na webu zkontrolovat, jestli se vaše emailová adresa nenachází v nějaké databázi ukradených přihlašovacích údajů. Údajně.

Moje technologie zachází dokonce ještě dál a umí zkontrolovat zda někdo neukradl dokonce číslo vaší kreditní ​karty.

Zkuste zde: https://www.sevecek.com/UkradeneKarty/byla-vase-karta-ukradena.htm

květen 19
Poděkování a prezentace z konference GOPAS TechEd 2016

Děkuji všem co byli na mých přednáškách na TechEd a doufám, že se jim to líbilo a hlavně, že je to bavilo! Příští rok se těším opět na shledanou na konferenci, která už bude mít patnácté narozeniny! Už teď připravujeme například i nový formát přednášek.

Moje letošní prezentace ke stažení zde.​

V kalendáři mám přidány kurzy a WUG přednášku na červen a červenec.

květen 17
BitLockerem AES CBC vs. XTS-AES z dnešní přednášky o novinkách ve Windows 10

Nojo. Jak jsem se už zmiňoval, jsem chaotik. Dneska jsem předváděl, co znamená, když se na sektory disku zašifrovaného BitLocker používá jen prosté CBC. Pokud znáte dešifrovací klíč (tedy FVEK), můžete se podívat, že jste schopni dešifrovat téměř celý libovolný sektor i bez ohledu na to, jestli znáte jeho pozici na disku, nebo ne.

Každý sektor se šifruje nezávisle na ostatních sektorech. Inicializačním vektorem (IV) je pouze číslo sektoru vzhledem k oddílu.

Tím se myslí, že neznáte inicializační vektor (IV) pro AES CBC. Při dešifrování se vám nepodaří dešifrovat správně jen prvních 16 bytes (tedy velikost AES bloku). Zbytek sektoru uvidíte v pořádku. Viz. následující obrázek z mého ukázkového prográmku. Je v něm sektor plný ASCII znaků 16-255. Jen prvních šestnáct znaků je chaos.

Proč mi to nefungovalo na přednášce? Protože jsem blázen. Sektory jsou sice dlouhé 0x200, ale taky člověk musí začít na pozici tímto dělitelné. V obou případech jsem si prostě vzal 512 bajtů od poloviny jednoho do poloviny druhého sektoru. No prostě únava materiálu :-(

BitLocker Diffuser a XTS-AES

Proč to vadí? Proč nestačí jenom CBC? Vždyť jsem znal FVEK. Když znáte dešifrovací klíč, tak je přece jasné, že ty sektory dešifrujete.

Ale v případě offline sector-switch útoku ten FVEK neznáte. Nejste schopni nic sami dešifrovat. Ale přehodit dva zašifrované sektory (tedy nečitelné) můžete vždycky. Až se bude disk později normálně dešifrovat - uživatel si prostě počítač spustí - sektory se dešifrují korektně, kromě svých prvních 16 bajtů.

Dalo by se to tedy využít k tomu, že nahradíte, offline a bez znalosti klíče, některé systémové soubory, nebo konfiguraci v registrech. Samozřejmě byste museli vědět (offline bez dešifrování), které sektory máte vyměnit. Ale ono je v systému hodně míst, která mají poměrně pevnou pozici na disku.

Proto byl dříve v BitLocker proprietární Diffuser. A od Windows 10 je k dispozici standardní XTS-AES. A je dokonce výchozí. S jedním z těchto dvou algoritmů už sektory závisí na své pozici vzhledem k ostatním sektorům a nelze je tedy přehodit.

květen 17
Názorná ukázka proč není dobré šifrovat BitLocker jenom v režimu "used space only"

Tak zrovna jsem narazil na pěknou ukázečku nebezpečnosti used-space-only. To je možnost, jak nastavit BitLocker. BitLocker může šifrovat buď celý oddíl a tím pádem všechny jeho sektory, i "prázdné". Dokonce ani jinak nelze šifrovat například VHD soubory, a to ani v případě že jsou pevné velikosti (tedy ne dynamicky rostoucí). Navíc je to výzhozí volba.

Podívejte se na obrázek. Je na něm kousíček obsahu VHD souboru, který je zašifrován BitLockerem v režimu used space only. Dal jsem do něho veliký soubor s ASCII znaky od 16 po 255. A ouha. Sice je velká část disku zašifrována a nic vidět není, našel jsem tam ale i nějaké sektory, které obsahují části souboru viditelně nezašifrované.

Proč? No asi se to tam zapsalo dříve, než se šifrovalo a soubor byl průběžně nějak realokován po disku. Nebo kdo ví :-) NSA nikdy nespí :-) 

květen 17
Řešení prvního problému z přednášky o novinkách ve Windows 10

Ukazoval jsem virtuální čipovou kartu na TPM čipu, do které se vydá přihlašovací certifikát a přitom to má hardware atestation.

Atestation znamená, že je zaručeno, že se ten certifikát vytvoří na TPM ​a nikoliv jenom nějak na software. Nelze tedy vydat větší počet certifikátů.

Atestation se zajistí tím, že do CA zadáte "id" jednotlivých vaších TPM čipů a je to. Píšu ID, aby to bylo přehlednější. Ve skutečnosti se tam zadává thumbprint (otisk) zabudovaného TPM certifikátu, který má každé TPM uvnitř.

No dobře. Ale teď k tomu problému. Jsem blb. Ještě jsem kvůli tomu instaloval TeamViewer. Ty virtuální čipové karty nefungují z RDP sešny. Stačilo se zastavit venku na vzduchu a hned mi došlo, jakj jsem zmatkář.

květen 16
Rozřešení problému z přednášky o PKI

Jak jsem říkal na dnešní přednášce na ​konferenci GOPAS TechEd, nemám rád nevyřešené problémy. Ukazoval jsem přihlašování klientským certifikátem na web server a ono to nejelo.

Do háje.

Jako vždy na hodinové přednášce to zkazí dojem a není čas to řešit. Tak jsem se rozhodl to aspoň trošku odčinit, a sice to vzalo tak hodinu, ale nakonec jsem to rozlousknul. Napsal jsem to rovnou anglicky (kritika na adresu mé "angličtiny" je zbytečná, rovnou se přiznávám :-) . Třeba se to bude někomu hodit.

květen 13
PowerShell a pole vs. ArrayList vs. HashTable vs. SortedList

Dělám teď nějaké operace citlivé na rychlost přes mnoho objektů a můžu tedy poskytnout nějaký pohled na to, jak je to v PowerShellu s těmito čtyřmy typy "kolekcí". Budu se bavit primárně o chování PowerShell 2.0 protože to je dneska ještě mnohde mainstream a musí s ním všechno fungovat.

Pole

Pole je peklo. Pokud do něho přidáváte položku (například pomocí operátoru +=) tak se vytvoří nové pole, to staré se do něho zkopíruje a přidá se nový prvek. To se změnilo do PowerShell 3.0, kde už je pole kolekce a má i metodu Add() a Clear().

Ale není to zase až tak strašlivé, protože jako parametr funkce se pole předává odkazem. Tedy pokud se ovšem nemusí konvertovat jeho prvky na jiný typ. To se potom celé zkopíruje a prvky nakonvertují. Příklad by byl například parametr funkce [object[]] a do něho vložené pole typu [string[]]. Tady se nemusí konvertovat, takže jenom odkaz. Naopak kdyby parametr funkce měl typ [string[]] a přitom byste do něho rvali [object[]], tak by se to muselo zkonvertovat po jednom a tedy zkopírovat.

Samozřejmě, pokud ho vracíte z funkce jako návratovou hodnotu, tak se jeho prvky přeskládají do nového pole typu [object[]] a to bez ohledu na jeho původní typ. Prostě výsledkem funkce je vždy buď [object[]] nebo jeden konkrétní objekt - klasická demence PowerShellu.

Rozhodně nebrat

ArrayList

Je lepší a já ho rád používám. Má ale jednu podstatnou nevýhodu. I tady, pokud ho totiž vracíte z funkce jako návratovou hodnotu, tak ten list PowerShell celý projede kus po kusus a přeskládá všechny prvky do pole [object[]]. Jak u blbých na dvorku.

Můžete tomu pomoci operátorem čárka (něco jako return ,$list) ale to zase potom ten výstup funkce nelze přímo pajpnout do dalšího příkazu - pajpne to tam celý ten list, tedy v podstatě jeden objekt.

HashTable a SortedList

Potřeboval jsem rychle vyhledávat duplicity. K tomu jsem si potřeboval vytvořit index řetězcových hodnot. Vyzkoušel jsem to nejprve na random 200 000 řetězců. A překvapivě!

HashTable je v tomhle dokonce cca 10 krát rychlejší než SortedList jak v případě vkládání klíčovaných hodnot, tak i v případě jejich vybírání (indexer).

Navíc pokud vracíte HashTable jako návratovou hodnotu funkce, tak vám to nekonvertuje její typ a prostě to vrátí ten odkaz.

Tak tohle je miláček. HashTable.

květen 05
Implementace MD4 a NT hash pomocí C#

Jenom taková malá ​zmínečka, kdyby někdo chtěl, zrovna jsem si v C# naimplementoval MD4 algoritmus podle RFC 1320. Ne že by to byl nějaký světoborný algoritmus, ale ony se pomocí toho počítají NT hash. Tedy to, jak jsou v Active Directory uložena hesla. Zdroják zde.

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
zhulený powershellu 27.6.2016 16:30
proč mě ten powershell pořád svádí psát místo operátoru -join operátor -joint ? :-)
 
můj nový security bulletin MS16-081 14.6.2016 22:00
můj nový security bulletin MS16-081: https://technet.microsoft.com/library/security/mt674627.aspx Je to sice jenom DoS a jenom "important", ale stejně :-)
 
Network Bindings - deprecated ve Windows 10  1.6.2016 6:58
Dorazilo mailem, díky: http://www.alexandreviot.net/2015/10/07/windows-10-change-network-bindings/
 
kontrola kradené karty 24.5.2016 0:00
zkontrolujte si, zda se vaše karta nenachází v databázi kradených karet: https://www.sevecek.com/UkradeneKarty/byla-vase-karta-ukradena.htm
 
seznamy "kradených" mailů 23.5.2016 22:44
všude jsou seznamy kradených mailů. a důkaz? není to metoda, jak ukrást mail? škoda, že tam obvykle nemají "ověřit, zda bylo ukradeno heslo (kreditka)" :-)
 
(More Announcements...)