20:29
25/7/2017

Dane setek tysięcy klientów sklepu z odzieżą patriotyczną były zostały udostępnione w internecie i przez pewien czas każdy mógł je pobrać. Wyciek był spowodowany brakiem ograniczenia dostępu do narzędzi deweloperskich frameworka Symfony.

APP_DEV.php IS BAD TOO

Krótko po godzinie 12:00 na naszą redakcyjną skrzynkę zaczęły spływać 2 linki:

https://www.redisbad.pl/app_dev.php/api/client/list oraz
https://www.redisbad.pl/api/client/list.

…umożliwiające podejrzenie panelu developerskiego sklepu redisbad.pl:

…oraz — co gorsza — pobranie danych osobowch klientów związanych z zamówieniami. Wśród dostępnych do ściągnięcia danych znajdowały się m.in.:

  • Imię nazwisko
  • Numer telefonu
  • Adres e-mail
  • Adres zamieszkania

Wedle informacji, jakimi dysponujemy, ostatni ID w bazie miał wartość 218490, jeśli identyfikatory klientów były nadawane od wartości 1, to łatwo można oszacować wielkość bazy danych, która mogła wpaść w niepowołane ręce.

Błąd jako pierwsi odkrył jeden z uczestników grupy poświęconej PHP na Facebooku:

Niektórzy z piszących do nas po kilku minutach od publikacji postu Czytelników, wspomnieli o tym, że poinformowali już sklep o zostawionym w głębokim ukryciu “app_dev.php”. I faktycznie, plik ten po kilkudziesięciu minutach zniknął… ale dalej można było odpytywać sklep o dane przez API:

I nie tylko odpytywać, bo API pozwala na modyfikację danych w serwisie. Jest więc szansa, że jeśli zdolności administratorów sklepu co do rollbacku bazy wyglądają tak jak zdolności reakcji na incydent, to kiedy sklep wróci po “naprawie” (bo teraz wyświetla taki komunikat jak poniżej), to część z produktów może mieć zmienione ceny lub pojawią się rzeczy, których firma nie oferuje.

Jak napisał do nas jeden z Czytelników, który przyglądał się rozwojowi wypadków:

konsola pozwala również na znalezienie odniesień które nie powinny się pojawić, m.in dostępu do listy klientów wraz z adresami poprzez API, zarówno w środowisku dev, jak i produkcyjnym

Niestety, z informacji które napłynęły na naszą skrzynkę, jak i obserwacji dyskusji na grupie na Facebooku, szacujemy że do bazy serwisu dostęp mogło mieć bardzo dużo osób. Klienci sklepu powinni mieć się więc na baczności.

Programuję webaplikacje — co robić, jak żyć?

Programistom za radzimy rzut oka na swoje serwisy i frameworki w celu weryfikacji, czy przypadkiem też nie udostępniacie narzędzi developerskich na świat. Z naszych doświadczeń wynika, że część programistów nie wie nawet, że poszczególne frameworki, czy biblioteki z których korzystają mają tego typu (użyteczne dla “włamywaczy”) narzędzia. Problem jaki został dziś odkryty na redisbad.pl jest bardzo popularny (popatrzcie na wyniki Google).

Dlatego warto czytać dokumentację i warto regularnie testować swój serwis internetowy narzędziami, które szukają tego typu popularnych “plików” znajdujących się w tzw. “głębokim ukryciu” (por. Skipfish, nikto czy DirBuster).

Wiele z nich na żywo pokazujemy na naszych szkoleniach z Atakowania i Ochrony Webaplikacji, które powinno być obowiązkowe dla każdego programisty i testera. Tutaj możecie się zapoznać z opiniami uczestników ostatniej edycji tego szkolenia, a jeśli rozważacie zapisy, to śpieszcie się, bo zostały już pojedyncze wolne miejsca na ostatnie w tym roku terminy!

Dziękujemy Mariuszowi, Damianowi, Cronoksowi, Natx7, Damianowi, Tomaszowi, Anecie i innym Czytelnikom za informacje w tej sprawie

Przeczytaj także:



30 komentarzy

Dodaj komentarz
  1. W jaki sposób tu app_dev był luką? Chodzi o możliwość wykradnięcia sesji czy coś innego?

    • W taki, że wszystkie endpointy api są wypisane jak na dłoni, chcesz zniżki, ctrl+f szukasz, chcesz customerów, robisz to samo.

    • Dostęp do danych, do których dostępu być z frontendu żadnego nie powinno.
      Niestety, taki urok półgotowców. Ja preferuję metodę “albo A, albo B” – czyli albo od początku do końca jechać po CMS-ie, albo mieć pełną kontrolę nad kodem i optymalizować co się da, o unikaniu bezpośrednich zapytań do bazy nie mówiąc. Najlepiej zrobić sobie piaskownicę ze stored procedur i dalej jechać tylko przez nie, a bezpośredni dostęp do danych mieć z konta aplikacji wyłączony.

    • app_dev.php sam w sobie nie powinien iść in public. sam profiler za dużo mówi o aplikacji, może ułatwić późniejszą “penetrację”. Bardziej to że lista userów była dostępna poza mechanizmem uprawnień bo to właśnie chyba tu się stało i jest to niezły fakap programisty.

    • Choćby głupia zmiana plików konfiguracyjnych po wejściu do konfiguratora i zamrożenie strony na X czasu, dane na temat wszystkich routów, scieżek serwerowych, portów i wiele więcej przydatnych informacji do ataków?

  2. Brawo dla osoby która to upubliczniła na FB. Bardzo dorosłe zachowanie. Mnie to nie dotknęło, ale mam nadzieję, że ta osoba poniesie karę i na następny raz najpierw poczeka aż błąd zostanie załatany, a później dopiero go opublikuje.

    • fame na dzielni musi się zgadzać

    • Oj oj ale ból dupy.
      Agresywne upublicznianie tego typu rzeczy to jedyny sposób, żeby zmusić leniwych devów / pazernych właścicieli do poświęcenia odrobiny więcej uwagi temu, co robią.

    • Full disclosure to jak najbardziej dopuszczalna metoda raportowania, tym bardziej, że te dane tak czy inaczej zdążyli już na czarnym rynku przehandlować.

    • Słychać wycie? Znakomicie.

      A serio-na załatanie pewnie trzeba by czekać miesiącami (skąd pewność, że sklep o tym nie wiedział?), a w tym czasie co sprytniejsi po prostu zassali by bazę danych.

    • Zgadzam się z Tobą w 200%.

    • Trzeba się śpieszyć bo jeszcze ktoś cię ubiegnie i nici z 5 minutowej sławy. Tak niestety myśli dużo osób.

    • No nie masz racje – niech ludzie nie wiedza, ze sklep, w ktorym kupuja ma luke w zabezpieczeniach i ich dane typu case-sensitive lataja gdzies po internecie…

      swietnie! gratuluje podejscia xD

  3. Polecam konsole symfony :)
    Lepszy dork od niebezpiecznika :) Wiem ze wymiata :>
    intitle:Console inurl:app_dev.php/_console/

  4. Amatorka (mocna) po stronie sklepu oraz po stronie osoby, która to opublikowała na fejsach.

  5. To ANTIFA ma znowu numery telefonów polskich nazioli? :)

  6. “AAAAkupię bazę”
    Spis Skinów Polskich

  7. > programista
    > frameworki
    > dodajmy do tego code overhead
    > wydajność taka nijaka

    Dlatego, jeżeli jest się dobrym programistą, warto sobie za punkt honoru postawić zasadę: jak najmniej obcego kodu w aplikacji, wagowo i objętościowo. Obcy kod w zasadzie powinien ograniczać się do bibliotek funkcyjnych, a od logiki aplikacji jest przecież właśnie aplikacja. Może i trudniej się przyzwyczaić, ale jak kod jest przejrzysty i ścieżki wejścia też, to łatwiej potem zapanować nad tym, co może user.

    Zaraz się odezwą głosy typu “a na co mam dbać o wydajność, jak mam mocny serwer”. No tak – jak masz jakieś 8 odsłon/minutę to jeszcze spokojnie wyrobi, bo serwer “odpoczywa”… ale jak wejdzie ci 80000 odsłon/minutę, no to się zacznie płacz, że się wcześniej nie myślało nad optymalizacją. A po co przepłacać za moc obliczeniową, skoro można zredukować wymagania na nią?

    • Ludzie z twoim podejściem są prawdziwą zmorą IT. Przejmujesz później taką aplikację po “programiście-geniuszu” co to z frameworków i bibliotek nie korzysta, “bo sam wszystko lepiej zrobi”, i nie wiadomo w co ręce włożyć. Zero dokumentacji, konstrukcje których chyba sam autor nie rozumie, jakieś prowizoryczne rozwiązania i nieprawidłowa obsługa (lub wręcz jej brak) niektórych standardów, o bezpieczeństwie lepiej nie wspominać. Sam system oczywiście wywala się po upgradzie środowiska, a dostosowanie do współczesnych wymagań to droga przez mękę. A za wszystko zapłacił klient, który dał sobie wmówić że “Panie, potrzebuję miesiąc żeby dodać obsługę funkcjonalności X. Co prawda są już co najmniej 3 dojrzałe implementacje których mógłbym użyć i ich wdrożenie i testy potrwają dzień, ale ja sam przecież zrobię to lepiej”. Ja już takie autorskie rozwiązania programistycznych geniuszy omijam szerokim łukiem… Do każdego frameworka można mieć jakieś “ale”, ale przynajmniej częściowo wymuszają na programiście jakieś wzorce i dobre praktyki, które są też udokumentowane. Jak ktoś już na starcie zakłada że świat się musi mylić i on sam wszystko zrobi lepiej, to nie może to wróżyć nic dobrego.

  8. Niedawno jakiś “patriota” napisał tu komentarz, że “Tor to usługa dla pedofilów”. Mam nadzieję, że jego dane też znalazły się w tym wycieku. W końcu nie ma nic do ukrycia, prawda?

  9. app_dev domyślnie w symfony jest zablokowany htaccessem, wiec teoretycznie dostępu powinno nie być.

  10. Ciekawe czy prezydent tę swoją koszulkę co w niej w samolocie zapozował, kupował przez ten sklep internetowy.

  11. Mogliscie chociaż dorka nie dawac bo juz czuje zlot script kiddie

  12. Zgadzam się z Jakubem, bardzo nierozsądne zachowanie…

  13. Niby sklep patriotyczny, a nazwy pól w jsonie po angielsku… nieładnie

    • ciężki orzech do zgryzienia dla programisty.
      albo patriotycznie i po polsku albo profesjonalnie (zgodnie ze sztuką) i po angielsku.
      ciężko być programistą patriotą w tym kraju.

    • Chodzi o to, że powinno się trzymać jednej konwencji. Jeżeli nazwy funkcji, zmiennych itp. po polsku, to od początku do końca, a nie “tu tak, a tam inaczej” – bo taki miszmasz nie za dobrze świadczy o organizacji programisty :)

      BTW. Widziałem już bibliotekę w jakimś języku, w którym nazwy zmiennych były opisane w kanji. Niezbyt fajnie się to wpisywało :D

  14. Widzę znawcy symfony się tutaj zebrali XD Prawda jest taka, że standardowy app_dev.php puszcza tylko lokalne IP, w przeciwnym razie jest forbidden – https://github.com/symfony/symfony-demo/blob/master/web/app_dev.php#L30 więc developer musiał to specjalnie zakomentować.

    “Nie zawsze testuję swój kod, ale gdy to robię to na produkcji”

    • w swojej karierze widziałem “zakomentowania” tychże “filtrów” już w pierwszy commicie “init” ;)

  15. Halo, dlaczego jestem zbanowany na tej facebookowej grupce? :o

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: