Přeskočit na hlavní obsah

Kryptografická selhání

  1. Zjistěte, jaká ochrana je nutná pro aplikační data.
    • Např. hesla, kreditní karty, zdravotní záznamy, osobní data a obchodní tajemství.
  • Tato data vyžadují zvýšenou pozornost a speciální zabezpečení.
    • Zejména v případě, podléhají-li nějakému typu práva nebo regulace v oblasti ochrany soukromí (GDPR, ochrana finančních záznamů - PCI DSS).

Nejčastější zranitelnosti​

  • Únik citlivých a osobních údajů.
  • Hard-coded credentials.
  • Špatný nebo riskantní krypto algoritmus.

Jak zranitelnosti předcházet​

Pro všechna data zajistěte​

🔴 Zabezpečte komunikaci tak, aby se data nepřenášela v plain textu (HTTPS, SMTP, FTP → TLS / STARTTLS).

  • Ověřte, že to platí i pro interní komunikaci (mezi load balancery, web servery nebo backend systémy) - zejména používáte-li cloud řešení jako je např. AWS.
  • Vynuťte šifrovanou komunikaci.

🔴 Ověřte používání a nahraďte staré nebo slabé krypto algoritmy v současném a starém kódu.

🔴 Ověřte, že nedochází ke znovupoužití některých vygenerovaných klíčů v jiných aplikacích nebo na jiných místech v rámci organizace.

🔴 Zkontrolujte, že se v kódu / repozitáři nevyskytují privátní klíče, hesla, API klíče a další credentials.

🔴 Ověřte přijatý serverový certifikát a trust chain.

🔴 Nepoužívejte a neignorujte inicializační vektory, generujte je dostatečně bezpečně.

  • Používejte zabezpečený režim provozu (např. ECB).
  • Používejte autentizované šifrování tam, kde je vhodnější než obyčejné šifrování.

🔴 Zkontrolujte, zda se pro kryptografické účely používá náhodnost a pokud ano, zajistěte, aby byla implementována tak, aby splňovala kryptografické požadavky.

🔴 Nepoužívejte deprecated hash funkce jako je MD5 nebo SHA1.

🔴 Nepoužívejte deprecated krypto padding metody jako je PKCS number 1 v1.5.

🔴 Zkontrolujte, zda se nedají zneužít kryptografická error hlášení.

Jak se dále bránit​

🔴 Určete, která data jsou citlivá (i podle zákona, regulačních nebo obchodních požadavků, ochraně osobních údajů, atd.).

🔴 Neukládejte citlivé údaje, pokud nemusíte (data, která neuchováváte, nelze odcizit).

  • Odstraňte data hned, jak to bude možné, nebo použijte tokenizaci a zkrácení v souladu s PCI DSS.

🔴 Šifrujte všechna citlivá data.

🔴 Používejte up-to-date a silné standardní algoritmy, protokoly a klíče, používejte bezpečný key manager.

🔴 Šifrujte všechna přenášená data pomocí zabezpečených protokolů (TLS s šiframi FS - forward secrecy), šifrovací prioritou serveru a bezpečnými parametry.

  • Vynucujte šifrování pomocí directives jako je HSTS.

🔴 Zakažte cache tam, kde dochází k přenosu citlivých dat.

🔴 Používejte požadované bezpečnostní kontroly podle klasifikace dat.

🔴 Nepoužívejte legacy protokoly (FTP, SMTP) pro přenos citlivých dat.

🔴 Ukládejte hesla pomocí silných adaptivních a solených hashovacích funkcí s work factor (delay factor), například Argon2, scrypt, bcrypt nebo PBKDF2.

🔴 Zvolte vhodný inicializační vektor pro daný provozní režim.

  • Pro mnoho režimů to znamená použití CSPRNG (kryptograficky bezpečná pseudo náhodně generovaná čísla).
  • Pro režimy vyžadující nonce není CSPRNG potřeba.
  • Ve všech případech by inicializační vektor neměl být nikdy použit dvakrát pro pevný klíč.

🔴 Vždy používejte autentizované šifrování namísto pouhého šifrování.

🔴 Generujte klíče kryptograficky náhodně a uložte je v paměti jako pole bajtů.

  • Převeďte heslo na klíč pomocí vhodné funkce pro odvození klíče na základě hesla, pokud je použito heslo.

🔴 Zajistěte, aby byla v případě potřeby použita kryptografická náhodnost a aby nebyla použita předvídatelným způsobem nebo s nízkou entropy.

  • Většina moderních API nevyžaduje, aby vývojář pro zabezpečení použil CSPRNG.

🔴 Nepoužívejte deprecated kryptografické funkce a padding schémata jako jsou MD5, SHA1, PKCS number 1 v1.5.

🔴 Nechte nezávisle ověřit účinnost konfigurace a nastavení.

Příklad zneužití zranitelnosti​

  1. Aplikace šifruje čísla kreditních karet v databázi pomocí automatického šifrování databáze. Tato data jsou však při načítání automaticky dešifrována, což umožňuje získat čísla kreditních karet v plain textu pomocí chyby SQL injection.
  2. Web nepoužívá nebo nevynucuje protokol TLS pro všechny stránky nebo podporuje slabé šifrování. Útočník sleduje síťový provoz (např. v nezabezpečené bezdrátové síti), sníží úroveň připojení z HTTPS na HTTP, zachytí požadavky a ukradne uživatelův session cookie soubor. Útočník pak tento soubor cookie použije a zmocní se (ověřené) relace uživatele, čímž získá přístup k jeho soukromým údajům a možnost je změnit. Místo výše uvedeného může změnit přenášená data, např. příjemce bankovního převodu.
  3. Databáze hesel používá k ukládání všech uživatelů nesolený, nebo jednoduchý hash. Chyba při nahrávání souborů umožňuje útočníkovi získat databázi hesel. Všechny nesolené hashe lze odhalit pomocí tabulky předem vypočítaných hashů. Hash generovaný jednoduchými nebo rychlými hashovacími funkcemi může být prolomen grafickými procesory, i kdyby byl solený.

Kam dál​

Cheat sheety​

Checklisty​

Další​