Zpět na seznam článků     Číst komentáře (8)     Verze pro tisk

Studie: Třetina českých e-shopů má bezpečnostní problémy!

Autor: smitka   
28.1.2020

Pro konferenci Reshoper jsem udělal relativně jednoduchý bezpečnostní test 35 tisíc českých e-shopů. Výsledek? Třetina e-shopů má bezpečnostní chyby, desetina kritické.


Na Datablogu Reshoperu vycházejí ve spolupráci s nástrojem Marketing Miner různé studie o stavu české e-commerce. Ty aktuálně pokrývají zhruba 35 tisíc českých e-shopů a zkoumají především SEO a marketingové funkce. Napadlo mě tedy, že by bylo zajímavé přidat i techničtější studii o jejich bezpečnosti.

Zkoumané problémy

Důkladně otestovat 35 tisíc webů je prakticky nemožný úkoly, vybral jsem proto jen několik problémů, se kterými se v praxi velmi často setkávám.

Nejprve mne zajímalo, zda a jak mají nastaveno HTTPS - očekával bych, že především v e-commerce sféře to dnes již bude naprostá samozřejmost. U toho jsem rovnou otestoval, zda mají podporu nového protokolu TLS1.3, zda jsou připraveny na konec podpory TLS1.0/TLS1.1 a také to, zda používají HTTP/2. Zároveň jsem kontroloval, zda weby používají nějaké bezpečnostní HTTP hlavičky, to vcelku spolehlivě ukazuje, zda se bezpečnosti někdo aktivně zabýval. Velmi dobrou pomůckou pro nahlašování bezpečnostních problémů je soubor security.txt, podíval jsem se tedy i na jeho přítomnost.

V dalším kroku jsem se podíval na vážnější problémy. Zda na webu nejsou zapomenuté soubory, které tam nemají co dělat - typicky zálohy, konfigurace, přístupný .git repozitář, file manager, nástroje pro správu databází, soubor s výpisem phpinfo() a další neřesti.

Velká část bezpečnostních problémů vzniká v důsledku nedostatečně ošetřených uživatelských vstupů, pokusil jsem se tedy i o naivní aktivní XSS scan.

Testovací stack

Protože průzkum probíhal "za pochodu", využíval jsem k němu kombinaci různých existujících nástrojů a vlastních skriptů. Obslužné skripty píšu většinou v Pythonu. Pro rychlé zpracování požadavků využívám asyncio s aiohttp. Pokud potřebné knihovny nepodporují asyncio, tak využívám ThreadPoolExecutor a klasicky Requests nebo nově HTTPX. Pokud je třeba test rozložit přes více strojů využívám frontu RabbitMQ a Dramatiq. Někdy potřebuji spouště konzolové nástroje, zde je užitečným pomocníkem GNU Parallel.

HTTPS

Pro získání vyčerpávajícího množství informací o HTTPS je možné použít API z Qualys SSL Test, nebo jejich CLI tool. V obou případech získáte JSON s informacemi o podporovaných šifrách a protokolech, verzích, správnosti certifikačního řetězce, HTTP hlavičkách a mnoho dalších užitečných informací. Pro porovnávání je konfigurace také oznámkovaná od A+ do F.

10 913 e-shopů vůbec HTTPS nepoužívalo, 1952 se nepodařilo otestovat kvůli chybnému nastavení (např. kvůli certifikátu pro jinou doménu) nebo blokaci testu.

  • Z e-shopů s HTTPS fungujících dostalo známku A+ pouze 1373 (je to podmíněno hlavičkou HSTS).
  • Hodnocení A/A- získalo 18 260 e-shopů.
  • B/C získalo 2 216 e-shopů, to většinou za podporu starých slabých šifer, nebo naopak ze nepodporu nových.
  • Nejhorší známku F dostalo 682 e-shopů - většinou kvůli zranitelnostem způsobených neaktualizovanou knihovnou OpenSSL.

Funkční protokol TLS 1.3 jsem detekoval na 4 155 e-shopech (většinou díky používání CloudFlare). Správně nastavené HTTP/2 na 13 449 e-shopech, správně nastavené znamená s OpenSSL 1.0.2+, kde je podpora ALPN. Mnoho serverů se HTTP/2 snaží mít, ale podporují jen NPN a tak jim v průběhu času v majoritních prohlížečích přestalo fungovat.

Bezpečnostní HTTP hlavičky

Bezpečnosntí HTTP hlavičky slouží především jako prevence a mohou snížit dopady některých útoků. Bohužel jsem zjistil, že většina e-shopů nepoužívá ani jednu, což značí to, že na nich bezpečnost zatím nikdo řešit ještě nezačal. Konkrétně se jedná o 27 018 e-shopů s nulou bezpečnostních HTTP hlaviček. Pouze 1866 e-shopů používá 4 a více bezpečnostních HTTP hlaviček. Nejčastěji jsou samozřejmě používány ty nejjednodušeji nasaditelné, tj. X-Frame-Options (5 330), Strict-Transport-Security (3 526), X-XSS-Protection (2 993) - XSS Auditor přestává být ale v prohlížečích podporován, a X-Content-Type-Options (2 910). "Nejmocnější" hlavičku CSP používá pouze 807 e-shopů, část z nich však v nastavení "stejně povol vše". Našlo se 6 e-shopů, které prakticky plnou škálu 8 nejrozšířenějších bezpečnostních HTTP hlaviček.

Informace o bezpečnostních hlavičkách lze vyčíst z Qualys SSL Testu. Bohužel jsem chtěl uspořit trochu dat a při zpracování jsem z JSON výstupu odstraňoval větev s RAW certifikáty a omylem jsem odstranil i informace o hlavičkách. Tento test jsem tedy zopakoval pomocí aiohttp. Zjistil jsem u toho, že se mi velmi pohodlně pracuje s CIMultiDictProxy.

Security.txt

Dalším signálem, který nasvědčuje tomu, že to provozovatel webu myslí s bezpečnostní vážně, je přítomnost souboru security.txt. Ten jsem nalezl na 4 300 e-shopech.

Zapomenuté soubory a nástroje

Velmi často se stane, že vývojář na webu nechá něco, co může případnému útočníkovi udělat radost. Podívejme se rovnou na výběr zajímavých věcí, které jsem na testovaných e-shopech nalezl:

  • Adminer - skvělý nástroj na správu databáze - nalezl jsem ho na 1 144 e-shopech. Na 974 ve verzi 4.6.2 a nižší = umožňující plnou kompromitaci webu.
  • Přístupný GIT repozitář - na 178 e-shopech bylo možné stáhnout zdrojové kódy, často včetně hesel do databází, k SMTP a k různým API.
  • Konfigurace - 28 × config.neon z Nette aplikací, podobně 13 × config.inc/config.ini z různých dalších systémů, 9 × soubor s údaji k (S)FTP z Sublime nebo VS Code, 7 ×  local.xml z Magenta a abychom nebyli jen u PHP, tak i 3 × settings.py z Django.
  • Zálohy a dumpy databází jsem nalezl na 315 e-shopech.
  • Spráce souborů bez autentifikace - špatně nastavený CKfinder a další správci souborů s možností uploadu pro všechny jsem odhalil na nejočekávanějších místech u 64 e-shopů. Obecný uploader jsem nalezl na dalších 122, zde ale nebylo jasné, zda a kam se případně soubor nahraje.
  • Logy - přístupné (error/debug) logy jsem si mohl přečíst na 167 e-shopech.
  • Statistiky :-) - na 331 e-shopech jsem nalezl veřejně přístupné statistiky návštěvnosti z nástrojl Webalizer a AWstats.
  • PHPinfo - na konec jsem si nechal častý neduh a to přístupný soubor s výpisem funkce phpinfo(). Ten byl na 4 878 e-shopech. dva e-shopy prozradily, že používají nejnovější PHP 7.4. Naopak tři prozradily 15 let starou verzi PHP 4.3.

Tyto skutečnosti jsem zvyklý testovat pomocí nástroje GoBuster. Líbí se mi jeho univerzálnost v tom, že mohu jednoduše otestovat soubory na přesných místech, tak si mohu nechat prostřídat koncovky, což se hodí například pro hledání dumpů. Nevýhoda je, že testuje jen funkčnost dané URL, ale už nezkoumá obsah. Může tak docházet k množství false positive, což nevadí u konkrétního scanu,ale hromadné testování to může velmi zkomplikovat. To mohou řešit jiné nástroje - například SnallyGaster. Já zůstal věrný GoBusteru, prošel jsem si co nalezl a nálezy dále otestoval vlastním skriptem s aiohttp. Příště bych to asi celé udělal rovnou pomocí aiohttp...

XSS

Provedl jsem i malinko aktivnější scanování na ošetřené uživatelské vstupy. Test byl velmi primitivní a primitivní byly i nástroje, které jsem k němu využil. Použil jsem knihovnu Mechanize, která částečně simuluje browser. Jejím úkolem bylo "otevřít" hlavní stránku, najít na ní všechny formuláře, vyplnit všechna pole payloadem a odeslat. Potom najít všechny interní odkazy vedoucí z hlavní stránky a provést to samé. Ve výstupu jsem pak testoval, jestli obsahuje payload v nezměněné formě. Jako payload jsem použil řetězec zhruba: <xss>xss"!' - takový řetězec se do výsledné stránky propíše pouze pokud bylo ošetření vstupů opravdu kriticky zanedbáno. I tak jsem XSS nalezl 2 289 e-shopech! Reálný stav bude však mnohem horší, takto jednoduchý test samozřejmě neprošel validacemi formulářů a částečným ošetřením vstupů. Na některých e-shopech způsobil tento dotaz chybu 500, což vzhledem k pouze jedné uvozovce může ukazovat na SQL injection.

Z nalezených webů s XSS jich 401 patřilo i do skupiny s přístupným výpisem phpinfo(). Tato kombinace je obzvlášť nebezpečná, protože je tak možné jednoduše získat session cookie i v případě, že má příznak HTTPonly. 

Závěr

Celý tento test ukázal na poměrně tragický stav české e-commerce. Weby se security.txt jsem o se snažil o problémech informovat nejdříve. Pokračoval jsem s weby se závažnými problémy seřazenými dle jejich odhadované návštěvnosti, bohužel dohledávání kontaktů vedlo nejčastěji k obecnému info@ e-mailu, který není často příliš relevantní. 

Pro zjednodušení nahlašování používám vlastní mini aplikaci postavenou na Flasku. Ta načítá informace o nalezených problémech z databáze, parsuje výstupní soubory z různých nástrojů, snaží se automaticky stáhnout kontakty ze security.txt a z hlavní stránky webu a hlavně jsou v ní předdefinované texty k jednotlivým problémům.

Ukázka nahlašovací aplikace

Po oslovení několika stovek e-shopů a stále se nekrátící se frontou dalších webů k dohledání kontaktů, jsem se rozhodl s pozitivním výsledkem požádat o pomoc Národní CSIRT

Je třeba vzít v potaz, že se jednalo o velmi jednoduchý scan a podrobnější analýza by pravděpodobně přinesla mnohem horší výsledky.

Původní článek s výsledky scanu si můžete přečíst na https://www.reshoper.cz/datablog/studie-tretina-ceskych-e-shopu-ma-bezpecnostni-problemy/.


Líbil se Vám článek?
Budeme potěšeni, pokud vás zaujme také reklamní nabídka

Social Bookmarking

     





Hodnocení/Hlasovalo: 1.94/16

1  2  3  4  5    
(známkování jako ve škole)