TechHeaven – Security & kryptografie 1/3

Dne 12. 6. 2018 uspořádala společnost TechHeaven z.ú. akci SECURITY KRYPTOGRAFIE, která byla zaměřena na vývojáře webových aplikací. Na akci se objevili 3 zajímaví řečníci ze společností Lynt services s. r. o.,  Heureka.cz a Unicorn a. s.. V tomto článku se zaměřím na prvního řečníka ze společnosti Lynt services s. r. o.

Vladimír Smitka | @smitka | Lynt services s. r. o.

Lynt service na TechHeaven

Na úvod hodně silný kalibr. V jeho prezentaci se hned na začátku pustil do zabezpečení webu. Zdůraznil nutnost nastavení cookies na HTTP only, aby nedošlo k odcizení identity například pomocí HTTP request trace. uživatelé stále používají staré nezabezpečené prohlížeče.

Další hodně zajímavý způsob, který pan Smitka ukázal, je například odkoupení staré expirované domény, kam se nahraje záludný kód. Poté lze pomocí window.opener lze ovlivnit rodiče a podstrčit falešné stránky. Proto je vhodné vždy do odkazů, které mají target=“_blank“ nastavit rel=“noopener noreferrer“.

Není apple jako apple

Jeden z další phishingových způsobů, jak podvrhnout uživateli nakažený odkaz, je například zadáním regulérní domény, která vypadá jako jiná známá doména, ale je napsaná například cyrilicí, řeckou abecedou, nebo jinými znaky, které vypadají podobně jako běžný text. Například, pokud ve Firefoxu otevřete tento odkaz: https://www.xn--80ak6aa92e.com/ zobrazí se Vám doména, která vypadá jako www.apple.com. Po rozkliknutí zjistíte, že to není doména, kterou byste čekali.

V následujícím bodě jsme se dozvěděli, jak můžeme útočníkům usnadnit napadnout náš web. Například díky vypsání backtrace se dá zjistit jaký typ správce webu je použit a tím se zaměřit na hledání slabin tohoto systému. Jsou systémy, kde se uživatelské jméno k FTP vypíše v cestě k souboru, ve kterém se zobrazila chyba. Dá se zjistit použité CMS nebo technologie či framework a taktéž se zaměřit na jeho slabiny.

Bacha na laděnku

Spousta systému využívá v debugu různé ladicí systémy. všechno funguje správně, dokud není zapotřebí zavést například loadbalancing. Poté se může stát, že například nginx, který komunikuje s apachem je na stejném stroji a tudíž komunikace je na úrovni localhost a najednou se nám začne zobrazovat například tracy z nette. A ejhle… ono je zde heslo k DB v plaintextu… K vyvolání chyby pak stačí upravit vstupní parametry a místo index.php?id=5 zavolat index.php?id[]=5 a problém je na světě.

Občas se stává, že ve výchozí konfigurace Apache je aktivní výpis adresářů a souborů. Tím se dá hodně usnadnit útočníkovy najití slabiny. Například tak, že zjistí, že máme na webu nějaký wysiwyg, který má plugin pro nahrávání obrázků. Tento plagin pravděpodobně bude umět nahrát data bez authentizace. Takže pak stačí správně zavolat URL a máe script na serveru. A pak si vlastně můžeme dělat co chceme.  Dost často se dá editor zavolat na úvodní stránce systému vložením krátkého scriptu do konzole.

GIT a máme všechna data webu

Pokud web máte napojený na git a dostupný adresář .git, jsou nástroje, které umožní vysosat tento git soubor s obsahem a tím si vlastně stáhnout celou verzi Vašeho webu. Poté už je jen na útočníkovy, aby našel v systému slabinu a tu napadl. Takže git je super, ale nezapomeňte na jeho zabezpečení. Jedním z nástrojů, který vám umožní vysosat celý web naleznete například zde: https://github.com/internetwache/GitTools

Bacha na user-agenty. Pokud logujete přístupy na web a ukládáte si user-agenty, tak se snadno může stát, že součástí je scrypt, který zavolá například obrázek. Jenže ten obrázek může být scrypt, který sice vrátí obrázek, ale zároveň upozorní útočníka, že na webu asi nemáte ošetřené vstupy. Takže k vám pak propašovat script nebude úplně tak složité.

XXE – málo známá, ale velmi účinná metoda pro odstřelení serveru. Tato technika umožní na serveru například vyžrat operační paměť a tím server uměle přetížit. Jde o útok pomocí XML External Entity.  Doporučuji si pročíst tento dokument, pokud ve své aplikaci načítáte a zpracováváte externí XML, který řeší obranu proti tomuto útoku: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

HTTP Parameter Pollution

Jako poslední typ útoky byl prezentován HPP – HTTP Parameter Pollution. Jde o řetězení vstupních parametrů za sebe. Víte jak se chová jazyk, který používáte pro vývoj? Například při zavolání stránky: example.com?id=1&id=2:

  • PHP použije jako hodnotu poslední použitý parametr
  • Ruby se zachová stejně
  • Perl použije první parametr
  • Python stejně jako Perl
  • Node z toho udělá pole [1,2]
  • ASP.NET je spojí v řetězec 1,2

Co ale udělá právě ta vaše aplikace při tomto neočekávaném vstupu? Spadne a nebo to ustojí bez ztráty kytičky? A co když pošlu GET id=1&id=2 k tomu POST id=3 a k tomu cookie id=3;id=4? Co z toho tedy asi bude? Vyzkoušejte a sami si odpovězte.

Ještě nás čeká HPP selfreference. aneb vazbení parametrů pomocí html entit. Pokud kód není dostatečně zabezpečný, tak například pomocí tohoto nevinného dotazu:

  • page.php?action=edit&page=<PAGE_ID>
  • page_id = 1%26action%3ddelete

Tak máme krásný výsledek page.php?action=edit&page=1&action=delete a tudíž místo abychom editovali, budeme mazat.

Pan Smitka upozornil na několik příkladů, kdy HPP potrápil velké společnosti jako Yahoo Classic Mail, Twitter, Blogger nebo WordPress.

Pár otázek na závěr

  • Mají mé session cookies HTTP Only + Secure?
  • Používám target=“_blank“ s noopener, noreferrer?
  • Nezobrazuji chybové hlášky a stacktrace?
  • Zakazuji výpis složek (autoindex), a přístup ke všemu, co začíná tečkou (především .git)?
  • Ověřuji uživatele u filemanageru v HTML editoru?
  • Jak se zachová aplikace když se jí pošle více stejných parametrů?
  • Jak nakládá XML parser s entitami?
  • Kolik používám bezpečnostních hlaviček? https://securityheaders.com/

Druhou přednášku shrnu v dalším článku >>