Bezpečnost B2B přes ISDS Aktuální výzvy a jejich řešení

Bezpečnost B2B přes ISDS Aktuální výzvy a jejich řešení

Stávající B2B agenda ==>>>>> Nakolik se lze spoléhat na SSL tunel? Problém MSIE8 s doménovým kontextem Chiméra: Ale, my máme spisovku! Formáty příloh, nejčastější prohřešky Závěrečná doporučení

SSL tunel Problém SSL protokolu spočívá v handshackingu při renegociaci, který je dělán v otevřené řeči Jedná se o chybu protokolu TLS, která vyžaduje změnu RFC Útoku nedokáže zabránit (nebo ho zjistit) ani klient ani server

SSL tunel (pokr.) Již první fáze útoku umožňuje injektování příkazů do SSL spojení V praxi ISDS by to znamenalo, že útočník za Vás může např. poslat zprávu Navíc, hrozí krádež autentizačního cookie, tj. krádež otevřené relace uživatele vůči systému

SSL tunel (pokr.) Dlouho se soudilo, že útočník nebude moci číst komunikaci, teď víme, že to není pravda Do prolomené SSL komunikace lze vložit reverzní proxy, která provoz degraduje na http (což by pozorný uživatel mohl odhalit narozdíl od odesílání požadavků, kde jsou jeho šance minimální) Co myslíte, děláte s ISDS renegociaci nebo ne?

SSL tunel (řešení) V předstihu jsme postavili novou přístupovou bránu nedělá SSL renegociaci nepoužívá autentizační cookies provádí basic autentizaci zvyšuje rychlost vyřizování požadavků usnadňuje připojení programátorům aplikací

Vaše spisovka to neumí? Řešením je produkt 3. strany Bezpečná schránka připojí Vás k nové přístupové bráně; odhalí zneužití SSL renegociace; ochrání Vás před krádeží relace; zjistí pokus o degradaci https připojení na http; viz www.bezpecnaschranka.cz

Problém MSIE8 Vztahuje se k autentizačním cookies parametr secure (zabraňuje odeslání cookie do nešifrovaného spojení) parametr httponly (zabraňuje předání hodnoty cookie skriptu) Všimněte si, httponly mizí z internetových bankovnictví!

Problém MSIE8 (pokr.) Autentizační cookie je používáno pro udržování relace Vystavuje ho server, klient ho přidává ke každému požadavku Protokol http je bezestavový, pomocí cookie je rozeznávána transakce a historie požadavků Klient sám cookie k ničemu jinému nepotřebuje

Problém MSIE8 (pokr.) Hodnota cookie je vracena pouze do stejného doménového kontextu (mojedatovaschranka.cz) Autentizační cookie jsou v ISDS vystavována doménovým jménem login.mojedatovaschranka.cz Vracena jsou webovému serveru s doménovým jménem www.mojedatovaschranka.cz

Problém MSIE8 (pokr.) A teď to přijde: Nastavíte-li v MSIE8 zónu na Vysoká, nevrací hodnotu cookie (s n httponly) jinému doménovému jménu ani v rámci stejného doménového kontextu Vypnete-li httponly, MSIE8 hodnotu cookie vrací, ale vydá ji skriptu, který je v kontextu domény spuštěn!!! Riziko krádeže otevřené relace!

Problém MSIE (řešení) Přejít k nové přístupové bráně, která autentizační cookies nepoužívá (a problém neexistuje!) Nemůžete-li (nebo užíváte-li i webovou aplikaci, byť jen pro nastavení!), můžete použít Bezpečnou schránku. Pak nejsou v prohlížeči uložena platná autentizační cookies a nelze je ukrást! Váš uživatel nemusí mít ani paralelní http spojení.

Máme spisovku No dobrá, a co z toho? Postrádáte end-to-end (SSL tunel je point-to-point) otevřená poslední míle XML v SOAP zprávách není šifrováno ( 20, odst. 1, písm. a) znemožňuje implementaci WS-Security Nastavení děláte v prohlížeči s autentizačními cookies

Máme spisovku (pokr.) A dále: Do cesty se zařadila další aplikace, o které toho mnoho nevíte (jaké jsou například parametry úložiště klíčů, které používá?) Vaši uživatelé nadále otevírají zranitelný PDF formát ve svých readerech Už jste nasadili patch na problémy CVE-2010-0188 a CVE-2010-0186? Že nevíte? Vždyť je už tři týdny venku http://www.adobe.com/support/security/bulleti ns/apsb10-07.html

Máme spisovku (pokr.) A proto: Váš uživatel si otevře datovou zprávu, do které někdo mohl vložit deformovaný TIFF, který byl umístěn do XFA formuláře Až ho uživatel otevře ve svém readeru, bude na jeho počítači spuštěn kód dle volby útočníka (čí bude ten počítač nadále?) Nebo bude útok neúspěšný, což skončí DoS útokem na daný stroj Návod k provedení je už v oběhu a je snadný!

Máme spisovku (pokr.) Další problém se skrývá v PDF formátu samotném: lze ho zlomyslně připravit tak, že zcela bez přetečení zásobníku vyvolá spuštění logiky na počítači oběti, a to dle volby útočníka; viz dále ukázka spuštění CMD.EXE přes PDF přílohu datové zprávy (praktická ukázka);

Máme spisovku (pokr.) Co tedy vyřešila věta Máme spisovku? SOAP ani XML většina Vašich firewallů hloubkově nekontroluje, ale pouze je propouští Soubory kontrolujete zpravidla antivirem. Co provede s aplikačním útokem proti readeru, který jsem popsal? Od včerejška byl do metasploit framework přidán nový způsob zneužití CVE-2010-0188, užívající Return-oriented programming a překonávající i DEP (tedy už žádný JavaScript)!

Máme spisovku (řešení) Udělejte si její audit. Řešte poslední míli. Ověřte si správnost formátů. Zajistěte minimální práva uživatelů! Kontrolujte SOAP! Alternativě můžete použít systém Bezpečná schránka. Tato virtuální appliance to vše (v rámci in box řešení) obstará za Vás.

Formáty příloh Ukázka z 10. března: 277620 přiložených souborů 973 chyb, z toho např.: MIME typ application/octet-stream: 254 MIME typ tmp: 129 MIME typ pdf a pripona zfo (OMG): 59 Nepovolené přípony: 216, z toho např. 83 zip, 18 eml, 11 isds, 7 ssl, (perlička: urg ) Nepovolený obsah souboru neodpovídající příponě: 123

Formáty příloh K tomu brzy přidáme formát pro EDI, zejména pak INVOIC pro GS1 a pro EAN Při tom bude uplatněn MIME-TYPE TXT a XML (oba dva jsou již podporovány) ISDS však nyní nepodporuje šifrování ani vnitřní kontrolu integrity (ta, spolu s dalšími prvky EDI bezpečnosti, musí být zajištěna na straně uživatele nebo VAN poskytovatele)

Formáty příloh (řešení) Tohle všechno od Vás nemusí odcházet (ani k Vám přicházet). Jak na to? Došlápněte si na vývojáře své spisovky a zjednávejte postupnou nápravu (alespoň v odchozím směru) Nasaďte Bezpečnou schránku, která zajistí kontrolu formátů v odchozím i příchozím směru (včetně chystaného EDI). Může Vás upozornit na přílohy s krátkou dobou konverze, poskytnout statistiky a tak dále.

Závěrečná doporučení Prosazujte bezpečnost XML a SOAP zpráv, inspektujte ji na FW. Přejděte k basic autentizaci na nové přístupové bráně. Nespoléhejte na spisovky. Přinášejí i další problémy. Řešte bezpečnost pracovních stanic. Při příjmu EDI zpráv kontrolujte integritu.