Aukcje.org

Aukcje internetowe w Polsce i na świecie

24/04/2006,

Aukcje internetowe na świecie, Aukcje internetowe w Polsce, E-biznes, Felieton, Bezpieczeństwo

OFF-SITE oraz ON-SITE PHISHING w serwisach aukcji

Najniebezpieczniejsze mechanizmy pozwalające na manipulacje w serwisach internetowych zwykle opierają się na lukach w podstawowych procedurach i odrobinie socjotechniki. Popatrzmy na triki phisherów: wysyłają maile z pytaniem o login i hasło, ew. zapraszają na specjalnie spreparowaną stronę. Czy można wyobrazić sobie coś bardziej prostego i niebezpiecznego?

Co to naprawdę znaczy, że zezwalasz użytkownikom na użycie HTML-a w treściach umieszczanych w serwisie?

Wielu webmasterów pozwala na użycie tagów HTML w postach zamieszczanych w czatach, serwisach ogłoszeniowych, aukcjach, stronach „o mnie” itd. Nawet największe serwisy pozwalają na to, więc mogłoby się wydawać, że nie ma w tym nic niestosownego. Większość webmasterów wie także, że wszystko co jest przesyłane do serwisu, powinno być filtrowane.

Niestety, część filtrów nie jest wystarczająco czuła, aby wyłapać elementy „nietypowe”. Zwłaszcza, jeśli „nietypowe” jest proste i… dobrze imituje „typowe”.

W serwisach pozwalających na umieszczanie tagów HTML w przesyłanych treściach, ze słabymi filtrami, istnieją dwa poważne zagrożenia. Nazwijmy je OFF-SITE oraz ON-SITE PHISHING.

OFF-SITE PHISHING

Podstawowy tag HTML, zwykle pomijany przez filtry: tag linku <a href="cokolwiek”>. Nic w nim specjalnego, nieprawdaż?

Możemy odesłać zalogowanego lub niezalogowanego użytkownika w dowolne miejsce systemu: dezaktywacja konta, wylogowanie, subskrypcja newslettera, złożenie oferty zakupu itd. Dokądkolwiek.
Nie ma już potrzeby wysyłać maili z zaproszeniem, jak robią to phisherzy… Możliwe jest bowiem stworzenie linku-pułapki na stronie serwisu, odsyłającego do spreparowanej strony na zewnątrz, zachęcającej… np. do zalogowania

Przy odrobinie „charakteryzacji” możemy stworzyć całkiem niezłą pułapkę. Tagi CSS wprowadzone przez <STYLE> (zwykle filtrowane), lub w definicji in-line <element style="cokolwiek”> pozwalają na nadpisanie i zdefiniowanie WIDOCZNOŚCI, POŁOŻENIA, KOLORU, CZCIONKI, TŁA itp parametrów oryginalnych oraz nowych elementów.

Przy ich użyciu „pułapka” może perfekcyjnie udawać i ukrywać inne elementy systemu. Ale sprawa jest jeszcze bardziej złożona.

ON-SITE PHISHING

Pora na kolejne tagi, zwykle omijane przez filtry: <FORM cokolwiek> oraz <INPUT cokolwiek>. Jeżeli filtr zamieszczanych treści ominie tę parę – istnieje możliwość stworzenia „pułapki” zapraszającej do „udawanego logowania”… wewnątrz systemu, na jego stronach (ON-SITE).

Inne „podstawy”

Oczywiście istnieje o wiele więcej „typowych” potencjalnie niebezpiecznych elementów:

JavaScript (w dowolnej formie)
JavaApplets (w dowolnej formie)
Flash (w dowolnej formie)
<iframe> (w dowolnej formie)
<object> (w dowolnej formie)
<div>
<span>
definicje zdarzeń (w dowolnej formie):
- onAbort
- onBlur
- onChange
- onClick
- onDblClick
- onError
- onFocus
- onKeyDown
- onKeyPress
- onKeyUp
- onLoad
- onMouseOver
- onMouseDown
- onMouseUp
- onMove
- onResize
- onReset
- onSubmit
- onUnload

Nowe szaty króla

Występowanie opisanych luk w mechanizmach przyjmujących treści sprawdziłem dwoma kodami HTML (ew. ich modyfikacjami):

Kod 1:

Kod 2:

Jeżeli serwis zezwala na umieszczenie kodu 1 (także jego jakiejkolwiek modyfikacji czy maskowania) - oznacza to, że nie jest zabezpieczony na trick „OFF-SITE PHISHING”: zamaskowanie/manipulację zawartością serwisu i/lub odsyłanie użytkowników ze stron serwisu na inną stronę w serwisie/na zewnątrz, bez kontroli dokąd trafią osoby przekierowane, czy są zalogowane, czy strona na zewnątrz nie przechwytuje plików cookie z danymi sesji, czy nie zaprasza do „zalogowania” itp…

Jeżeli serwis zezwala na umieszczenie kodu 2 (także jego jakiejkolwiek modyfikacji czy maskowania) - oznacza to, że nie jest zabezpieczony na trick „ON-SITE PHISHING”: przesyłanie danych bezpośrednio ze stron serwisu, wprowadzanych świadomie bądź nie, przez odwiedzających serwis, bez kontroli dokąd trafią i czego dotyczą.

Jeżeli serwis zezwala na umieszczenie jednocześnie kodu 1 i kodu 2 - cóż.. oznacza to brak kontroli zarówno przekierowań użytkowników, jak i danych.

Miesiąc temu obydwa kody przechodziły bez żadnych przeszkód przez filtry treści zamieszczanych jako opisy aukcji (także przy użyciu oprogramowania do wystawiania aukcji), zawartość „stron o mnie” ("about me” itp. w każdym serwisie), wypowiedzi w kafejkach i/lub forach (tu różnie i nie we wszystkich) w serwisach Allegro.pl (oraz wszystkich filiach narodowych QXL Poland), ebay.com (oraz wszystkich filiach narodowych), Aukcje24.pl (oraz wszystkich filiach narodowych QXL Ricardo), swistak.pl, kiermasz.pl (oraz filii wszystko.pl), skrypcie phpauctions (także wersji XL) itd…

24 marca 2006 opis problemu w wersji polskiej oraz angielskiej udostępniłem przedstawicielom administracji serwisów Allegro.pl, eBay, Aukcje24.pl - czyli tym, które skontaktowały się ze mną po publikacjach w Aukcje.org. Z moich obserwacji wynika, że kroki podjęte przez administracje serwisów najwyżej w okrojonym i dalekim od dostatecznego zakresie wyeliminowały zagrożenie.

To dopiero początek

Na dobrą sprawę potencjalnie niebezpieczne lub umożliwiające manipulację opisem przedmiotu aukcji (a więc umową kupna-sprzedaży) mogą być:

wszelkie linki
wszelkie ilustracje zamieszczone bez pośrednictwa mechanizmów serwisów
kodowanie za pośrednictwem encji
definiowanie stylu, koloru, wielkości, sposobu wyświetlania
Flash, JavaScript, Applety

Zostaje więc „plain text” - we wszystkich miejscach, gdzie użytkownik ma możliwość zamieścić treść w serwisie. W każdym innym przypadku konieczne jest intensywne i przemyślane filtrowanie.

Poza wymienionymi, należałoby jeszcze wspomnieć inne sprawy, o których właściciele/operatorzy serwisów aukcji za przykładem eBay i allegro notorycznie zapominają, wydają się nie wiedzieć lub rzeczywiście nie wiedzą:

niewłaściwie zdefiniowane wyczerpania cookie
brak zabezpieczeń na łamanie haseł metodą brute-force
przyzwolenie na zbyt krótkie/proste hasła użytkowników
przyzwolenie na brak zmian hasła użytkownika - przez lata
zezwolenie na pobieranie/postowanie treści za pośrednictwem serwisów i programów zewnętrznych - sniperów, usług wystawiających aukcje itd. bez kontroli do kogo trafiają dane, hasła i loginy użytkowników
weryfikacja danych kserami oficjalnych dokumentów, listami poleconymi itd..
brak kontroli referencji między newralgicznymi stronami
umieszczanie linku „wyloguj” wtopionego i niewyróżniającego się od pozostałych elementów layoutu
brak supportu w sytuacjach awaryjnych
plagiaryzm - od konceptu po funkcje… kopiowane są także błędy
brak podstawowych audytów bezpieczeństwa wykonywanych przez niezależne podmioty
brak wymaganych prawem informacji na temat aktualnych zagrożeń wykrytych w systemach,
metoda GET w krytycznych funkcjach serwisu
obrót gotówką poza obiegiem, kontrolą i prawem bankowym
brak dostępnych użytkownikom kopii dawnych aukcji, postów, stron użytkowników
tolerowanie oczywistych przypadków przestępstw gospodarczych i skarbowych
krytyczne błędy w regulaminach: klauzule abuzywne, niejednoznacze zapisy, „dopowiedzenia” w helpach
niekompetentna załoga
wszechobecny brak poszanowania dla konsumenta

Listę możnaby ciągnąć w nieskończoność… zaskakująca nonszalancja jak na taką skalę obrotów. Efekt - aukcje internetowe są najczęstszym miejscem popełniania przestępstw elektronicznych. Najwyższy czas to zmienić.

Po miesiącu…

Dziś, po miesiącu od przesłania kompletnego opisu problemu (!!!), otrzymałem mail od administratora z serwisu allegro:

Chciałbym spytać czy opisana metoda została zweryfikowana/przetestowana?

Wg moich informacji dokładnie ten zestaw skryptów nie powinien zadziałać -
wśród dozwolonych (nie blokowanych) tagów HTML nie ma takich, które
pozwalają na zbudowanie aktywnego formularza. Nie wykluczam jednak, że moje
informacje są niepełne, dlatego będę wdzięczny za odpowiedź na powyższe
pytanie i potwierdzenie, że coś takiego istotnie komuś udało się zbudować.

Pozdrawiam.

Cóz… zobacz stronę „o mnie” jankiela i to, co sam sobie tam umieścił.

Więcej informacji:

.. o dziurach w serwisach aukcji

# iG — 25/4/2006 @ 11:43:

to miło że admini allego mają niepełne informacje odnośnie własnego serwisu ;)
# josze — 25/4/2006 @ 21:42:

no jak tam na stołkach informatyków zasiadają co miesiąc nowi pracownicy to nie dziwota
zobaczymy co na e-bay’u się będzie działo po ostatnich zmianach
i czy zrobią cokolwiek w kierunku eliminacji nierzetelnych sprzedawców
poleci jeden z drugi, to trzeci już w h** ciął z aukcją nie będzie
# Onekiss — 30/4/2006 @ 23:39:

Moimz daniem największą potencjalną luką bezpieczeństwa łaskawie nam panującego serwisu jest jego API. Co prawda dostęp do sensonwego wydania jest płatny, ale nielegalnego zdobycie nie powinno stanowić żadnego problemu. Jestem pewien, że nie trudno znaleźć jakąś lukę. Ponieważ to API komunikuje się chyba bezpośrednio z jądrem systemu jednocześnie olewając sporą część zabezpieczeń. W związku z tym stanowi to ogromne zagrożnie. A co do phisingu to szczerze mówiąc bardzo się dziwię, że serwisy były nie zabepieczone. Przecież jest to zagrywka stara jak świat i prosta jak kontrukcja cepa. Z drugiej strony moża się przed nią dość skutecznie zabezpieczyć. Żadnych skryptów, apletów, ramek, obiektów, formularzy i częściowe ograniczenie css powinno wystarczyć. A jak user jest durny to i tak nic nie pomoże. :)

Napisz komentarz:

Opcja komentowania dla tego artykułu została wyłączona.

Zobacz:

Poprzedni news: Bezprecedensowy pozew przeciwko serwisowi Allegro

Następny news: Snipe24.pl - wraca z poprawkami

Partnerzy:

RSS | RSS komentarzy | Kontakt | O stronie | Polityka prywatności