Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
č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.

květen 03
Nakládání s platebními kartami na portále alza.cz a CSOB

Abychom tu pořád neřešili jenom Office365, tak se pro změnu podívejme na ne zrovna košér nakládání s informacemi o platebních kartách na portále alza.cz, nebo možná na platebnibrana.csob.cz? Dneska jsem zůstal poněkud koukat na to, jak se mi z ničehož nic sama zaplatila objednávka, aniž jsem musel něco vůbec potvrzovat.

Nejprve bych rád uvedl, že alza.cz mám fakt rád. Jsou maximum rychlí, mají maximum výdejních míst otevřených i o víkendu, minulý týden jsem zíral na dokonalost AlzaBox, maximum ochota při reklamacích, žádné problémy s vracením zboží. Prostě něco, co se tady nevidí, cca o jedno století napřed.

Z technického pohledu mají pěkně udělané TLS šifrované HTTPS připojení, mají TLS 1.2, zelený certifikát (EV), všechno dovedeno k dokonalosti. Akorát s těmi kartami to teď už trošku přetáhli.

O co šlo? Nedávno jsem platil něco kartou. Bylo to poprvé, co se platilo viditelně přímo přes alza.cz. Po letech přeskakování mezi platebními portály se (ale jen na první pohled) stali už sami skutečným platebním portálem. To by znamenalo, že zadáváte číslo karty, expiraci i CVV přímo do jejich webové stránky. Dříve to fungovalo stejně jako na jiných webech, kde vás obchodník (třeba České dráhy, nebo dříve Alza) přesměruje na cizí platební portál/bránu (něco jako gbwebpay, paysec, gopay, nebo 3dsecure.csas.cz) a po zaplacení vás to zase vrátí zpátky k obchodníkovi.

U platebních portálů jsem měl vždycky lepší pocit, že si neukládají údaje o mojí platební kartě. Sice to občas nabízejí na zaškrtávátko, ale ve výchozím stavu není nikdy zapnuto, já si ty stránky obvykle poměrně podrobně prohlížím.

Proč nechci, aby si platební portál pamatoval moji kartu?

Řeknete si, že je to přece všechno bezpečné, když adresa je celá zelená a komunikace je zabezpečená. Komunikace ano. V okamžiku transakce. Ale každá online služba má vždycky riziko útoku. Jaká je záruka, že tu platební bránu někdo nenapadne a údaje karet tím nezíská? Klidně za pár měsíců nebo let? Když si nic nepamatuje, není co ukrást.

Už jednou se mi stalo, že si někdo na moji kartu koupil letenku do mexika za 110 000,- Kč. Naštěstí mi to banka (RB velká pochvala :-)) vrátila. Ale byly to nervy.

Nová Alza platební brána? Jen na oko

Alza se nově stala sama platební bránou. Alespoň to tak na první pohled vypadá, protože platební formulář máte přímo v okně s adresou alza.cz. Nikam vás viditelně nepřesměrovávají a rovnou zadáváte údaje karty do jejich vlastní webové stránky. S tím já problém nemám, komunikaci mají perfektně zabezpečenou:

Dokonce nahoře píšou Bezpečná online platba :-) Dobře si prohlédněte formulář. O ukládání údajů karty ani zmínka. Ani zmínka o tom, že se ve skutečnosti jedná o formulář z adresy https://platebnibrana.csob.cz. Tento fakt však dokáže odhalit jen oko zkušeného uživatele F12 Developer Toolbar v IE :-) Fakt je, že data karty byla ve skutečnosti odeslána POST na csob.cz a nikoliv do alza.cz.

Moje karta má zapnutu technologii 3dsecure, což má být druhý faktor ověření platby. Znamená to, že musím platby potvrzovat přímo na portále své banky pomocí SMS na zaregistrované číslo mobilního telefonu. Vím že zahraniční weby většinou 3dsecure nevyžadují, ale tam také neplatím touto kartou. K podivným platbám mám samozřejmě blesk peněženku.

I v případě Alzy jsem byl přesměrován na 3dsecure stránku RB banky a pocit bezpečí byl dokonán:

Následně mě to vrátilo do webové stránky alza.cz, kde jsem si přečetl informaci o doručení zboží a už jsem si moc nevšímal velkého zeleného obdélníku s hrozivou informací...

Další platba už byla překvapivě snadná

Dnes jsem se vypravil zaplatit nějakou další blbinu za cca 400,- Kč. Kliknu na platbu a překvapí mě, že vidím předvybrané číslo své platební karty:

Sice překvapen, nepřikládal jsem tomu přílišnou váhu, protože číslo karty samotné jsem považoval za nepodstatnou informaci. Číslo karty necháváte kudy chodíte. Mám tam přece 3dsecure SMS.

Ale ouha. Ono to šlo až moc jednoduše:

Bez ptaní, bez CVV, bez SMS, bez problémů a hladce. A sakra. Já jsem přece nikdy nikde neautorizoval uložení údajů karty!!!

Jak je to možné?

První podezření samozřejmě padlo přímo na Alza. Platíte na pohled kompletně přes jejich webovou stránku. Šel jsem se tedy podívat do svého Nastavení účtu a v sekci Platební karty pro nákupy byla moje karta. Žádné údaje nejsou přímo vidět, ale to nic neznamená.

Odpověď na přímý dotaz zněla takto:

Čísla karet u nás nejsou nikde ukládána.
Pokud Jste u nás platil kartou, tak je možné kliknou na zapamatovat kartu. Pokud máte povolený recuring (opakování plateb), tak je pak platba již automatická. Musel jste tedy zadat " zapamatovat kartu " 

Což není pravda, protože jsem nikde nic nepotvrzoval.

Ale po menším průzkumu věřím tvrzení, že čísla karet nejsou u nich zaznamenávána. Formulář s údaji karty jsem ve skutečnosti odesílal do ČSOB, takže Alza si skutečně číslo karty asi pamatovat nemusí.

Pokud zkusíte v té stejné sekci Platební karty pro nákupy přidat další kartu (tentokrát to děláte na vlastní žádost), opět ve skutečnosti zadáváte údaje karty pomocí POST požadavku přímo na https://platebnibrana.csob.cz.

No a v tom je celé kouzlo. Alza je jako z obliga. Údajně si nic nepamatují. Myjí si ruce, protože všechny údaje si pamatuje ČSOB platební portál.

To ale není pravda. Musí si pamatovat nějaký identifikátor, který páruje moji uloženou kartu do ČSOB. Takže rozdíl mezi tím, jestli si pamatují přímo kartu, nebo stačí do platebnibrana.csob.cz poslat nějakou kůkinu je podle mě nulový.

Rekurentní platby a 3dsecure

Takže jsem volal do své RB banky, aby mi řekli, jak je možné, že to po mě nechtělo 3dsecure a co znamenají ty údajné recuring (opakované) platby.

Na infolince paní přesně věděla, že to byla platba od alza.cz. O ČSOB platebním portálu ani slovo.

Na dotaz, proč to nechtělo 3dsecure byla odpověď, že jsme už jednou u toho obchodníka zaplatil a on si "kartu zapamatoval", takže 3dsecure už podruhé není potřeba.

Na otázku, jak je možné, že se to považuje za opakovanou platbu, když jsem platil úplně jiné zboží, za jinou cenu, byla odpověď, že když si obchodník pamatuje kartu, tak to proběhne samo.

Na otázku, jestli je možné tyto opakované platby nějak vypnout, byla odpověď že ne. Pouze je možné úplně vypnout veškeré elektronické platby :-)

Celkové shrnutí

Alza nabízí platby kartou sice přes platebnibrana.csob.cz, ale zobrazuje to na své webové stránce pod svým URI. Platební portál si bez diskuze zapamatuje údaje karty pro opakované použití bez 3dsecure. Nevaruje mě o tom ani mi neumožní tuto "výhodu" rovnou odmítnout. Alza si zapamatuje něco, čím vyvolá kdykoliv přes platebnibrana.csob.cz jakoukoliv platbu.

Tohle jednání se mi nelíbí

Zaprvé se údaje karty uloží i bez explicitního vyžádání, prostě při platbě.

Zadruhé se uloží u třetí společnosti platebnibrana.csob.cz a nikoliv na webu, u kterého se to tváří, že to zadáváte.

Zatřetí, kde je jistota, že při požadavku na odstranění karty přes webové rozhraní alza.cz dojde ke smazání údajů karty na platebnibrana.csob.cz?

Začtvrté, co se asi stane, až alza.cz někdo napadne a bude mít v ruce všechny ty identifikátory karet do platebnibrana.csob.cz?

Co se stane, až někdo napadne platebnibrana.csob.cz a ukradne údaje karet, které se tam automaticky ukládají?

Co se asi stane, až někdo uhádne někomu heslo k alza.cz účtu, ve kterém je uložen identifikátor karty? Až dosud nebylo přece podstatné mít moc silné heslo. To že se někdo podívá na moje starší objednávky nejsou trable. Trable začínají, až si může bez autorizace objednat na alza.cz zboží a jít si ho vyzvednout do AlzaBox v kapuci.

To budu zase já čekat s nervem, jestli mi ty peníze vrátí?

Takhle ne, děcka!

květen 02
Kolosální chyba Office365 není vlastně až tak kolosální

Dneska jsem dostal info o tomhle článku dokonce několikrát: http://www.root.cz/clanky/postrehy-z-bezpecnosti-kolosalni-chyba-microsoftu. Na první pohled se to zdá být jasně princpiální úder na bezpečnost služby Office365. Ale není.

Mě samozřejmě nemůže nikdo obvinit, že bych tady chtěl propagovat Office365 z bezpečnostního pohledu. Systém "dejme všechna firemní data do ruky neomezenému počtu indů" mě osobně nevyhovuje. Ale v tomhle případě o to nejde.

Na první pohled to vypadá, že to je díra, která ovlivnila "všechny" společnosti, a z toho má plynout ona kolosálnost. Ale ta tam ve skutečnosti není. Bezpečnostní díry se vyskytují všude a vždy. Tenhle incident je potřeba brát z pohledu každého konkrétního zákazníka. Z pohledu hackera je to samozřejmě paráda, dostat se díky jedné díře k datům více společností. Ale ne z pohledu samotné firmy, která má v Office365 data. Každé jedné firmě může být jedno, že hacker ukradne data i ostatním firmám.

Pro jednoho každého zákazníka to nepřináší větší rizika, než mít svoje data přístupná ve své síti, při stejném zabezpečení vzdáleného přístupu.

Pokud to řekneme zobecněně, tak tady byla využita chyba v technologii ověřování uživatelských účtů. Šlo o přístup z internetu na data společnosti a ověřování mělo chybu. Jednalo se o jedno-faktorové ověření heslem. Technologie ověřování byla pouze jedna (SAML). Stačila tudíž jediná díra k tomu, aby se účtočník dostal na data.

Stejná rizika by měla firma, kdyby měla data u sebe doma a umožňovala k nim přístup s jedno-faktorovým ověřením z internetu přes jedinou ověřovací technologii. Ne?

Proto se taky dělají vícevrstvé ochrany a multi-faktorové autentizace. Například nejprve VPN a teprve potom web, ještě třeba přes reverzní HTTPS proxy. Nebo nejprve RD gateway (opět třeba přes HTTPS proxy) a teprve potom RDP. Protože každá tahle technologie ověřuje uživatele jinak, minimalizuje se tím prostor pro útok. Aby se to povedlo, chyba by musela být ve více technologiích současně.

Pokud navíc tyto vrstvy vyžadují multi-faktorovou autentizaci, opět je o polovinu menší pravděpodobnost incidentu.

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...)