11:04
22/8/2017

Podczas wykonywanych przez nas testów penetracyjnych, nasz zespół bezpieczeństwa wypracowuje wiele ciekawych ścieżek ataków. Zazwyczaj zaczyna się od jakiegoś drobnego błędu, a potem, po kilku (czasem kilkudziesięciu) godzinach starań, kończy na dostępie do baz danych albo możliwości nadpisywania firmowych kart zbliżeniowych w systemie kontroli wejścia. Niestety, ze względu na podpisane umowy NDA, nie za bardzo możemy tego typu działania opisywać na łamach Niebezpiecznika. Dlatego zawsze bardzo cieszymy się, kiedy któryś z Czytelników podsyła nam opis odkrytej przez siebie ścieżki ataku. Nasza radość jest podwójna, kiedy Czytelnik jest na tyle etyczny, że o problemie informuje nas po to, aby pomóc poszkodowanej firmie, a nie jej zaszkodzić. I tak było właśnie tym razem.

Ten artykuł to opis drobnego błędu, który choć trywialny do wykorzystania, w konsekwencji umożliwił naszemu Czytelnikowi na dostęp do danych serwera bazodanowego Fundacji Itaka. Dziura została już załatana, ale jak to mówią — warto uczyć się na błędach, najlepiej cudzych — dlatego lekturę tego artykułu polecamy każdemu adminowi i devopsowi. Bardziej jako przestrogę niż tutorial hackingu (bo takie tutoriale udostępniamy tutaj ;)

Co to za listing? Co to za plik?

Fundacja Itaka jest organizacją pozarządową pomagającą rodzinom dotkniętym problemem zaginięcia osoby bliskiej.  Pomaga nie tylko w poszukiwaniach, ale świadczy też pomoc prawną i psychologiczną. To dość oczywiste, że w ramach swojej działalności organizacja gromadzi informacje o ludziach. Fundacja korzysta też z pomocy anonimowych informatorów (i uspokójmy wszystkich zainteresowanych od razu, że ten wrażliwy obszar działań fundacji nie został narażony na skutek opisywanych poniżej “badań”).

Jeden z naszych Czytelników – Maciej – zainteresował się ogłoszeniem fundacji o pewnej zaginionej osobie. Postanowił spytać o tę osobę wyszukiwarkę Google i tak trafił na wynik oznaczony jako [PDF] z adresem plakat.zaginieni.pl/XXXXXXXXXXXXXX (oczywiście zamiast znaków X były cyfry). Niestety, kliknięcie na wynik odesłało go na stronę błędu 404.

Na tym etapie wielu ludzi się podda, ale inni będą szperać dalej i spróbują na przykład zmodyfikować adres. Maciej wyciął z adresu nazwę pliku i trafił na… listing katalogu:

Próby wejścia do katalogów owocowały błędem 403, ale interesujący okazał się plik plakat.php.20110223, który z racji nierozpoznanego przez serwer rozszerzenia, można było podejrzeć. W pliku znajdował się taki oto fragment kodu:

Czy to mogło być takie proste? Plik pochodził z roku 2011 więc dane mogły być mocno nieaktualne… ale nie były. Korzystając ze zwykłej przeglądarki i podając zawarte w pliku dane dostępowe uzyskiwało się dostęp do bazy danych serwisu Zaginieni.pl.

Oczywiście baza osób zaginionych jest jawna, więc dla nikogo te dane nie będą wartościowe. Nie trzeba się nigdzie “włamywać”, wystarczy wejść na stronę Bazy Osób Zaginionych. Niestety taki dostęp do bazy jaki uzyskał Maciej dawał możliwość zdobycia dodatkowych informacji o serwisie zaginieni.pl (np. o administratorze, użytkownikach, etc). Dodatkowo, ktoś o złych zamiarach mógłby zmodyfikować bazę. Poza tym, serwis udostępnia mechanizm newslettera, a więc atakujący mogliby pobrać dane subskrybentów newslettera Itaki (adres e-mail, imię, wiek, miejscowość)

Podkreślamy, że Fundacja nie zostawiła tych danych całkiem bez zabezpieczenia (tak jak swojego czasu pozostawiono dane amerykańskich wyborców). W tym sensie nie doszło do wycieku. Przypadek Itaki bardziej przypomina włamanie do serwera bazodanowego Wykopu parę lat temu, kiedy jeden z użytkowników serwisu odkrył serwer deweloperski z udostępnioną na świat usługą bazodanową i postanowił się do niej zalogować pustym hasłem. Udało mu się. I trafił nie na dane testowe — a na prawdziwą kopię bazy sprzed kilku miesięcy.

Trudno też w przypadku Itaki mówić o jakimś wielkim włamaniu. Ktoś po prostu znalazł “w głębokim ukryciu”, a następnie skorzystał z publicznie dostępnych danych logowania. A przynajmniej “techniczni” Czytelnicy nie nazwą tego włamaniem, bo czytelnicy “prawni” powiedzą, że działanie Macieja można analizować w kontekście art. 267 KK tj. uzyskania dostępu do informacji nieprzeznaczonej dla sprawcy. Z drugiej jednak strony, przypomnijmy nowelizację KK, która weszła w życie 27 kwietnia 2017 i zawierała taki zapis:

§ 1a. Nie popełnia przestępstwa określonego w §1 (artykułu 269b — dop. red.), kto działa wyłącznie w celu zabezpieczenia systemu informatycznego, systemu teleinformatycznego lub sieci teleinformatycznej przed popełnieniem przestępstwa wymienionego w tym przepisie albo opracowania metody takiego zabezpieczenia.

Czy działania osób, które natykają się na błąd konfiguracyjny przypadkiem i chcą go zweryfikować pod kątem bezpieczeństwa są ujęte w tym zapisie? Przepis 269b mówi o wytwarzaniu i zbywaniu narzędzi do “hackingu” i kodów, haseł, a nie dostępie do informacji dla kogoś nieprzeznaczonej. Z drugiej strony, jak inaczej zweryfikować wagę błędu, czyli poprawność ujawnianego hasła, bez podjęcia próby jego wykorzystania?

Fundacja Itaka strzeże najwrażliwszych danych

W ubiegłym tygodniu zgłosiliśmy ten problem Fundacji Itaka. Natychmiast podjęto pewne działania naprawcze i ograniczono dostęp do plików na serwerze. Niestety na komentarz ze strony Fundacji będziemy musieli poczekać. Sezon urlopowy nie sprzyja szybkiemu załatwianiu takich spraw.

Rozmawialiśmy telefonicznie z przedstawicielką Fundacji Izabelą Jezierska-Świergiel. W czasie tej rozmowy dowiedzieliśmy się jednej bardzo istotnej rzeczy. Nie było zagrożenia dla szczegółowych danych dotyczących historii poszukiwań bowiem te niezwykle cenne dane są przechowywane w innej bazie, do której dostęp jest bardzo dobrze strzeżony (nie odbywa się przez internet). To co znalazł Maciej to dane powiązane z serwisem zaginieni.pl, w tym informacje o osobach, które tym serwisem administrują.

Jeszcze raz podkreślamy, że w tym przypadku nie mieliśmy do czynienia z jakimś strasznym włamaniem czy wyciekiem. Był to raczej niefortunny zbieg drobnych przeoczeń, który pozwolił komuś bardzo ciekawskiemu dostać się do bazy danych. Dobrze, że w tej nie znajdowały się istotne informacje. Ucząc się jednak na cudzych błędach, sprawdźcie, czy do Waszego serwera bazodanowego przypadkiem nie można się połączyć z internetu. Jeśli tak, to już wiecie czym to grozi i co należałoby zrobić (wyłączenie listingu plików, odpowiedni reżim pracy na serwerze produkcyjnym, poprawna obsługa błędów i przede wszystkim lokalna polityka firewalla w dostępie do serwera bazodanowego). Pamiętajcie, że nie każdy z przypadkowych internautów będzie tak samo etyczny jak Maciej.

Pomóż znajomej fundacji

Zastanówcie się też, czy w Waszej okolicy nie działa jakaś Fundacja, która mogłaby potrzebować pomocy w działaniach IT. Te organizacje robią wiele dobrego, a często nie mają odpowiednich funduszy na techniczne zabezpieczenie swoich działań na odpowiednim poziomie. Może warto zrobić dobry uczynek i zapytać, czy nie przydałaby im się pomoc?

PS. A jeśli jesteście programistami albo devopsami lub testerami QA i chcielibyście legalnie “pohackować” webaplikacje w kontrolowanym środowisku, to zapraszamy na nasze szkolenie z bezpieczeństwa webaplikacji, które odbędzie się w Gdańsku 18-19 września 2017, zostało jeszcze 5 wolnych miejsc. Ze szczegółowym opisem szkolenia i opiniami uczestników poprzednich terminów możecie zapoznać się w tym artykule.

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

21 komentarzy

Dodaj komentarz
  1. co do tego kodu, to w ogóle $nrsp i $rok było prawidłowo escapowane? o utf8 też nie słyszeli. ani o mysqli, ani pdo. chociaż jeżeli to jest kopia z 2011 to mogli przepisać, chociaż plik dalej waży 13K, więc wątpliwe.

    • Może już było skonwertowane na liczbę, dlatego nie trzeba było escapować. Ale wygląda lipnie, to fakt.

  2. Rozumiem, że skrypt PHP służący do generowania plakatów w PDFie logował się na użytkownika z uprawnieniami do modyfikacji całej bazy… Cudownie…

    • Z tego co widze to to jest hostowane na home.pl a tam nie pozwalaja zakladac osobnych userow do bazy danych.

    • Być może home nie zabrania korzystania z zewnętrznej bazy danych. Tak czy owak błąd leży po stronie programisty.

  3. W tych kilku linijkach widzę kilka błędów:
    Gwiazdka w zapytaniu – z punktu widzenia programistycznego bardzo złe przyzwyczajenie.
    Brak escapowania parametrów lub korzystania z dedykowanych funkcji statement.
    Brak konfiguracji parametrów, czyli tutaj dostępu do bazy.
    Zakładam, że każdy, albo większość plików jest oderwana od całości i każdy łączy się z bazą i zawiera dane dostępowe do bazy, coś strasznego.

    • Pewnie zatrudnili studentów na staż…

    • No cóż – kiepścizna, to fakt, z tymi danymi bazy ;)
      a wystarczyłoby zwykłe include(dbconnect.php);

  4. Czy jest jakikolwiek praktyczny powód by nie blokować directory listingu? Jak ktoś mnie o coś prosi to zwykle przy okazji dorzucam mu Options -Indexes do .htaccess wyjaśniając jednocześnie co to robi i nie spotkałem się z sytuacją, żeby ktoś miał potem problemy.

    • Jednym z praktycznych powodów może być po prostu publiczny serwer przeznaczony do downloadu – czasem plik może być niedostępny i usunięty, a np. nowsza wersja może być w tym samym folderze po inną nazwą – wówczas jest to przydatne.

    • W home.pl opcja -Indexes nie działa (jest zastąpiona -DirList) co często prowadzi do niebezpiecznych sytuacji – na serwerze deweloperskim listingów nie ma, a na produkcyjnym w home już jest

  5. Super administratorzy mają maile w domenie codivate.pl, ciekawe czy to ich błąd.

  6. Takich lików w sieci jest pod dostatkiem.
    np:
    http://people.sugarlabs.org/ignacio/imapextractor.py
    Można użyć również własnego bota, który wyszukuje podatności katalogów….
    A następnie je linkuje do pliku lub na maila.

  7. Ważne ,że wygrała najtańsza firma. Po kodzie widać że tymczasowy licealista za 10PLN/h się uczył.
    Za 12PLN/h byłby student który wie jak wyłączyć directory listing. Za 15 może nawet taki który ogarniałby mysqli i prepared statementy…

    • Tak jak mówisz. W sumie miałem 3 sytuacje;) gdzie “Jak się domyślam”, nie robił tego licealista za 10zł.
      Po wpisaniu odpowiedniego(prostego) adresu www, ***Nie będę pisał jaki sposób***
      Miałem kod źródłowy strony index.php ;D

    • A za 5PLN/h to by nawet gimbus zrobił, żeby miał za co pić z kolegami! :)

  8. Taki mały off-topic: zastanowiło mnie jakiś czas temu, czy ktokolwiek sprawdził, czy osoby uznane za zaginione występują w bazach np. dawców szpiku, honorowych dawców krwi itp.

    • A co by dała taka wiedza?

    • Pewnie Dawid “domyśla się” czemu ludzie znikają. Aluminiowa czapeczka może się przydać w tym przypadku.

  9. W tego typu poufnych katalogach zawsze warto umieścić jakiś mały pliczek index.html i wtedy nie będzie listingu nawet pomimo:
    1) braku “-Indexes” w pliku .htaccess;
    2) wyłączonego AllowOverride (.htaccess nie działa);
    3) hostowania na serwerze innym niż Apache.

  10. Nie wiem czemu piszecie o atakujących i atakowanych. Skoro jakaś sierota zostawiła furtkę to nawet o nieuprawnionym dostępie nie powinno być mowy.

Odpowiadasz na komentarz Czapa

Kliknij tu, aby anulować

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

RSS dla komentarzy: