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