Monthly Archives: June 2008

Antivirus software whitelisting

Česká pobočka Symantecu vydala tlačovú správu o nimi zamýšľanom napredovaní antivírusových riešení. V nej je spomenutých hneď niekoľko zaujímavých štatistických čísel (okrem iného z nich aj vyplýva, že cena za ukradnuté World of Warcraft konto je niekoľkonásobne vyššia ako cena ukradnutých informácií o kreditnej karte) – podľa Symantec-u bolo na konci roku 2007 viac ako 1 200 000 variánt malware. V ich štúdii je tiež spomenuté, že v roku 2007 bolo 65% všetkého uvoľneného unikátneho software charakterizovaného ako nebezpečný kód.

A tieto alarmujúce čísla napovedajú, že bude v budúcnosti jednoduchšie identifikovať neškodný software ako identifikovať malware. Tu ale správnemu paranoikovi vhupne do hlavy ďaľšie spiknutie. Buď bude používať antivírus, alebo bude neustále atakovaný malware-om. Antivírus ale bude musieť na základe rôznych algoritmov / databáz identifikovať spúštaný (resp príchodzí) software (teda bude mať dokonalý prehľad nie o infikáciách počítača, ale o jeho regulérnom software) a navyše bude rozhodovať o tom, či ho dovolí na počítači spustiť (resp vôbec uložiť). Toto môžu byť dosť citlivé informácie/schopnosti a nechcel by som, aby nimi nejaký program disponoval (a čo si ešte paranoik môže myslieť o zasielaní týchto informácií na “anonymné štatistiky” :-) )

CSS history exploit

Veľmi ma zaujal článok CSS exploit a neexistující soukromí na webu, pojednávajúci o zneužiteľnosti jednej feature CSS (dokonca už verzie 1). Zneužiteľná je schopnosť odlišne štýlovať odkazy vedúce na navštívené url, teda :visited. Pomocou tohoto CSS selektoru môžete nastaviť spomínaným odkazom odlišný štýl ako nenavštíveným, čo je pre používateľa príjemná vlastnosť.

Zároveň je to ale skrytý informačný kanál z histórie browsera do oblasti prístupnej JavaScript-u ale informácia sa môže dostať mimo Vášho počítača aj inak.

Príklad: dajme tomu, že tento exploit ide zneužiť e-shop. Na svoju stránku schová odkazy na konkurenčné e-shopy a nastaví im ID v tvare “konkurenciameno” (napríklad konkurenciaeshop2, konkurenciaeshop3), podľa toho, na ktoré e-shopy odkaz vedie. V CSS potom použije takéto pravidlá:


#konkurenciaeshop2 { background-image: url(log.php?eshop2); }
#konkurenciaeshop2 { background-image: url(log.php?eshop3); }
...

Skript log.php potom vráti prázdny obrázok, ale popri tom dostane a zaloguje aj informáciu o tom, že užívateľ, ktorý si obrázok pýta, navštívil danú stránku. Túto informáciu môže uložiť k užívateľovým session dátam a následne ich zneužiť.

Toto je primitívny spôsob zneužívania takéhoto chovania browsrov, ale pomocou JavaScriptu sa dá doviesť k dokonalosti. Nevýhodou je, že vždy môžete otestovať iba konkrétnu URL. Ale skript sa môže chovať tak, že dostane zoznam úvodných stránok, ktoré otestuje. Následne oznámi servru, ktoré z úvodných stránok má užívateľ (obeť?) v histórii, na čo mu server zašle ďaľšiu sadu URL-čiek (na danej doméne), ktoré skript tiež otestuje. Takto je možné dokonca zistiť napríklad aké produkty si užívateľ prehliadal na konkurenčných stránkach a podľa toho upravovať cenu, za ktorú by mu ich e-shop (útočník?) predal.

Samozrejme tento exploit nieje taký závažný ako niektoré iné, ktoré inštalujú rôzny malware, ale zaujímavé (a nebezpečné) na ňom je, že toto chovanie je z užívateľovho hľadiska feature, navyše podporovaná takmer všetkými browsermi.

Cvičenie: Web #2

Popri sledovaní live streamu z BarCamp-u som dostal ďaľší nápad na zadanie cvičenia. Osobne sa mi toto cvičenie ľúbi najviac zo všetkých (mojich) a dúfam, že sa bude páčiť aj vám.

Správnu odpoveď (ktorú si môžete overiť tu) nájdete pri vŕtaní sa v deravej stránke na tejto url.

Viac hintov vám azda nebude treba, diera podľa mňa bije do očí dostatočne.

Ešte pripomeniem, že ak ste zaregistrovaní na mojom blogu a prihlásení cez prihlasovací systém cvičení, tak sa váš nick objaví vo výsledkovej listine úspešných riešiteľov.

Cvičenie: Captcha

Nedávno mi ehmo (synopsi) povedal, že by nebolo odveci vytvoriť aj dáke cvičenia na prelomenie (z počiatku jednoduchých) captcha systémov. No a dnes som si našiel trochu času a prvé (dúfam, že bude záujem aj o pokračovanie) cvičenie vyrobil.

Vašou úlohou je 100 krát za sebou vyriešiť jednoduchý captcha systém. Na každý pokus máte (od vyrenderovania stránky po prijatie vašej odpovede na servri) jeden a pol sekundy. Po zvládnutí úlohy vám stránka prezradí tajnú frázu, ktorú si môžete overiť tu.

Ak ste ešte žiadne moje cvičenie z bezpečnosti neriešili, prečítajte si aj článok o cvičeniach.

Ako fungujú internetové platby cez i-banking

V tomto článku by som chcel ozrejmiť, ako fungujú internetové platby cez i-banking. Prednedávnom som niektoré platobné systémy implementoval a preddávnom ma veľmi zaujímalo, ako asi tieto platby fungujú (a preto sa s vami, o mnou nadobudnuté informácie, delím). Na príklade budem opisovať komunikáciu medzi aplikáciou e-shopu a aplikáciou internetbankingu.

Opisovaná situácia: zákazník si na e-shope vyberie tovar, potvrdí objednávku a chce zaplatiť cez i-banking svojej banky.

Priebeh platby

Schéma priebehu internetových platieb

Po objednávke musí zákazník zvoliť, aký druh platby použije na zaplatenie, pretože aj keď majú slovenské banky (aspoň tie, s ktorými mám skúsenosť) veľmi podobné protokoly na platby, nie sú rovnaké a napríklad Tatra banka má dokonca 2 druhy platieb (TatraPay a CardPay). E-shop následne má všetky informácie, aby vygeneroval payment request (na obrázku krok 1). V payment requeste je okrem iného uvedená suma, identifikácia obchodníka (e-shopu), identifikátor platby (variabilný symbol, niekedy aj špecifický symbol a konštantný symbol) a návratová url na stránku obchodníka. Payment request bude zaslaný banke prostredníctvom zákazníkovho browsra – teda potenciálne nebezpečným kanálom. Preto treba dodatočne zabezpečiť integritu a autenticitu dát uvedených v payment requeste.

Používaným spôsobom zabezpečenia payment requestu je podpis prenášaných dát. Podpísané musia byť všetky dôležité atribúty uvedené vyššie. Tieto sú skombinované do základu podpisu, z ktorého sa spraví hash. Hash sa následne zakryptuje symetrickou šifrou (používanými sú DES a 3DES) kľúčom, ktorý je známy iba obchodníkovi a banke (kľúče samozrejme rozdeľuje banka a každému obchodníkovi by mala prideliť iný kľúč), a vypadne podpis. Podpis je pridaný ako ďaľší atribút payment requestu.

E-shop teda má už kompletné údaje o payment requeste. Väčšinou sú to dvojice názov-hodnota, ktoré sa podľa špecifikácie príslušného protokolu zapracujú do HTML formu alebo URL a zobrazené v zákazníkovom prehliadači. Zákazníkov browser potom opustí obchodníkov web odoslaním payment requestu na server banky (podľa typu platby GET alebo POST HTTP requestom) (na obrázku kroky 2,3).

Banka následne autentifikuje zákazníka (prihlasovacími údajmi do i-bankingu, grid kartou, “kalkulačkou”…) a ten môže potvrdiť platbu (na obrázku krok 4). Ešte pred potvrdením platby ale musí banka samozrejme overiť digitálny podpis payment requestu a ten aj validovať (či sú správne zadané údaje etc.). Po potvrdení platby banka spracuje transakciu a vygeneruje payment response, ktorý obsahuje minimálne identifikátor platby (variabilný symbol) a výsledok transakcie. Prirodzene aj payment response je chránený digitálnym podpisom, ktorý sa spravidla generuje rovnakým postupom ako v payment requeste. Výsledky platby môžu byť OK (transakcia prebehla/prebehne), fail (transakcia neprebehne) a pri niektorých typoch e-platieb tiež timeout (platba zatiaľ neprebehla). Keď už banka vygenerovala payment response, zákazníkov browser je s payment response-om presmerovaný naspäť na stránku obchodníka (na obrázku kroky 5,6) (stránka obchodníka, kam má byť zákazník presmerovaný po spracovaní transakcie, bola uvedená v payment requeste – väčšinou sa používa HTTP GET).

Obchodník musí overiť podpis a validnosť payment response-u a ak sa to podarí, môže spracovať výsledok platby (na obrázku krok 7). Najprv musí spárovať platbu, ktorej sa payment response týkal, s objednávkou, ktorú zákazník odoslal. Na toto slúži identifikátor platby. Ďalej môže pokračovať v spracúvaní objednávky.

Zabezpečenie

Ako ste možno postihli, o celé zabezpečenie doteraz opísaného protokolu sa starajú podpisy správ vymieňaných medzi bankou a obchodníkom. Potencionálnemu útočníkovi (zákazník) by teda stačilo vedieť vygenerovať želaný payment response a dobre ho podpísať, aby mohol obchodníka presvedčiť o tom, že za objednané produkt(y) už zaplatil. Preto je veľmi dôležité zabezpečenie tajného symetrického kľúča, ktorý nesmie uniknúť ani z banky, ani od obchodníka.

Toto môže byť celkom riskantné, preto banky obchodníkovi väčšinou posielajú zabezpečeným mailom sumáre platieb realizovaných cez i-banking. Obchodník tak môže zistiť, ktorá objednávka v skutočnosti zaplatená nebola.

Záverom

Opisoval som spoločné vlastnosti fungovania internetových platieb. Samozrejme, že niesú všetky rovnaké. Niektoré protokoly môžu mať podporu na session dáta obchodníka, niektoré používajú okrem variabilného symbolu aj ďaľšie vlastnosti na identifikáciu platby, niektoré majú podporu na zadanie jazyka zobrazeného i-bankingového systému v payment requeste a podobne.