Aplikacje internetowe

Bełdziowe spojrzenie na aplikacje internetowe

Sklep z dziurami

. grzech:

  • przechowywanie haseł klientów w jawnej formie
  • słabe filtrowanie danych wejściowych
  • korzystanie z PostgreSQL – w połączeniu z SQL Injection umożliwia dostęp do całej bazy za pośrednictwem wykonania kilku zapytań za jednym razem
  • pokazywanie komunikatów o błędach
  • publiczny dostęp do logu błędów PostgreSQL – ujawnienie struktury bazy danych
  • nazwa firmy – patrz vivid.com ( 18) ;-)

konsekwencja:

  • całkowity dostęp do bazy danych – umożliwia nie tylko pobieranie danych, ale także ich zapis i modyfikacje

Pod koniec ubiegłego roku sklep internetowy Vivid.pl został kupiony przez Telefonię DIALOG S.A. ( KGHM Polska Miedź S.A. ) za kwotę 2 mln 150 tyś. zł. Mimo dużego kapitału ( 6 mln 300 tyś. zł ) nic nie zostało zainwestowane w bezpieczeństwo zarówno samego sklepu jak i jego klientów.

Największym błędem popełnionym przez programistów Vivid.pl było zostawienie włączonej obsługi błędów, która to przy wystąpieniu błędu bazy danych wyświetlała ścieżkę do loga zawierającego wszystkie niepoprawne wykonane zapytania. Plik ten zajmował ponad 300 MB i odzwierciedlał większą część struktury bazy danych. Wykorzystując jedną z właściwości serwera bazy danych PostgreSQL tj. możliwość wykonania kilku zapytań za jednym razem można było dokonać dowolną operację na bazie danych sklepu. Poczynając od pobrania danych klientów (wraz z hasłami, które przechowywane są w jawnej formie), których jest 183 107 (sądząc po wyniku funkcji COUNT()), poprzez możliwość modyfikacji produktów, kończąc na możliwości usunięcia wszystkich danych ze sklepu.

Wynik działania funkcji COUNT( )

Wynik działania funkcji COUNT( )

Proces poprawienia wykrytych przeze mnie błędów miał być częścią wdrożenia nowego systemu. Aby uchronić w międzyczasie sklep przed potencjalnymi atakami stworzyłem reguły mod_rewrite, które miały w nieinwazyjny sposób uchronić system. Więcej na ich temat można przeczytać w notce mod_rewrite jako pierwsza linia obrony przed wstrzyknięciami. Mimo stworzonego przeze mnie zabezpieczenia nie zostało ono wdrożone.

Po pół roku od mojego maila z informacjami o błędach wdrożony został nowy system do obsługi sklepu. System teoretycznie został załatany, niestety tylko teoretycznie. Drugie podejście do przełamania zabezpieczeń sklepu dało pozytywny wynik. Nadal możliwe jest przeprowadzenie ataku SQL Injection i nadal hasła klientów przechowywane są w formie jawnej.

Login użytkownika o identyfikatorze = 1

Login użytkownika o identyfikatorze = 1

Żeby być oficjalnym: Oświadczam że pomimo dostępu do danych klientów nie logowałem się na ich konta oraz nie modyfikowałem danych zawartych w bazie. Dodatkowo po analizie logów bazy danych mogę stwierdzić, że nie znajdowało się w nich nic co mogłoby świadczyć o innych przełamaniach zabezpieczeń oraz nieautoryzowanego dostępu do danych klientów.

30.07.2007 – admin Vivid’a informuje mnie, że błędy zostały już naprawione, miejmy nadzieję, że tak właśnie się stało.


Tagi: , ,
Kategoria: Bezpieczeństwo, BugTraq


3 komentarze

  1. pedros napisał(a):

    A nie lepiej bylo sciagnac sobie DB na dysk i wyslac im maila z nr konta na ktore ma trafic odpowiednia suma pieniedzy bo jak nie to odpowiednio wykorzystasz baze klientow, chociazby rozrzucenie wydruku kilkuset klientow pod redakcja gazety jakiejs ;) Zwlaszcza ze jak napisales wlasciciel sklepu dosc wolno reagowal na zgloszenia, pewnie jakis prezes/kierownik jak by wezwany zostal do prokuratora na rozmowe za udostepnienie danych osobowych wzial by sobie bardziej do serca bezpieczenstwo sklepu :>

  2. Michał `Bełdzio` Ławicki napisał(a):

    Ja bym pierwszy odwiedził produratora ;-)

    Bełdzio jest grzeczny ;-)

  3. vladimir napisał(a):

    <lekki off-top>
    @Bełdzio: stosuj niestandardowe rozmiary wrzucanych rysunków, bo Twoje 250×250 na każdej podstronie blokuje mi Norton Internet Security'06 ;) 120×90 też są nielubiane przez NIS-a – dzisiaj właśnie przerabiałem stronkę na zlecenie i przypadkowo to zauważyłem, na początku myślałem że chodzi o 'zakazane' ciągi w adresie pliku, bo swego czasu Kaspersky blokował mi folder 'bans', ale to nie dało rezultatu, i dość długo kminiłem nim wpadłem na to, że właśnie szer./dług. rysunku na to wpływają. Jeśli nie chce Ci się przerabiać, możesz po chamsku ustawić w html-u width="251" i już nie będzie blokował ;) Innych rozmiarów nie sprawdzałem, więc tylko się domyślam że chodzi o 'ładne' rozmiary – wielokrotności 10 albo konkretne wymiary.

    I teraz nie mów mi że masz to gdzieś i żebym zmienił antywira ;P Z tego co widzę wszyscy validują sobie stronki, ustawiają tabindexy, a na anty-spamy nikt nie zwraca uwagi. Ja już tego pilnuję po tym jak kiedyś po zmianie antywira zobaczyłem swoją stronkę bez 3/4 designa (miałem pliki topban.png, leftban.png itd. :) )

Dodaj komentarz