Kompleksowe szkolenie: wprowadzenie do bezpieczeństwa IT od sekuraka z rabatem 50%. Jedyna taka okazja w tym roku. Nie przegap! :-)

Od .git do panelu administracyjnego systemu z fakturami/paragonami. Historia pewnej podatności w jednej z polskich firm.

05 stycznia 2021, 13:44 | W biegu | komentarzy 17
Tagi: ,

W listopadzie 2020r. jeden z czytelników (nazwijmy go na potrzeby tekstu Pawłem) zgłosił nam problem bezpieczeństwa zlokalizowany w sklepie loveair[.].pl

Zaczęło się dość niewinnie – dostępny tam był katalog .git. Czym to grozi? Odpowiedź brzmi zawsze – to zależy. Czasem niczym, czasem czymś poważniejszym.

W tym przypadku Paweł poinformował, że udało się uzyskać dostęp do klucza API – umożliwiającego komunikację z zewnętrznym systemem fakturowo/paragonowym. Oto mały fragment kodu źródłowego (który był dostępny przez .git):

W skrócie – pewien plik był dostępny całkiem publicznie, a w nim wspomniany klucz. Jak trudno było się dostać do tego pliku? Z jednej strony łatwo (w końcu był publiczny), z drugiej strony – trudno (trzeba było trochę rozpoznać strukturę katalogu .git).

Teraz najważniejsze – wg relacji Pawła klucz API dawał dostęp do całego panelu administracyjnego po stronie zewnętrznego systemu fakturowego.

W ramach PoC Paweł dodał swoje konto administracyjne (ostatni wiersz):

W szczególności miał mieć dostęp do listy/szczegółów paragonów / faktur:

Co dalej? Paweł nie miał złych zamiarów, więc po odkryciu problemu, od razu zgłosił problem do firmy loveair[.]pl

Timing wyglądał następująco:

11.11.2020 po 23 – zlokalizowany katalog .git na loveair, a później zlokalizowanie klucza API
12.11.2020 po 12 – weryfikacja czy klucz API daje dostęp do zewnętrznego systemu – fakturowni
12.11.2020 o 15:15 wysyłka powiadomienia o szczegółach znaleziska do loveair/fakturowni i niezależnie do sekuraka
12.11.2020 o 15:35 odpisał pan Dariusz Ożóg, CEO loveair. „Przepraszają, będą zgłaszać do IODO i pospieszać devów”.
12.11.2020 16:04 -Jako sekurak wysłaliśmy wiadomość na skrzynkę kontaktową loveair z prośbą o wyjaśnienie „incydentu bezpieczeństwa”.
12.11.2020 18:21 – na skrzynkę sekuraka otrzymaliśmy dodatkowe wyjaśnienia od Pana Dariusza Ożóg:

Dziękuję serdecznie za informację. Pan Paweł już się z nami dzisiaj w tej sprawie skontaktował. Problem ten został niezwłocznie zgłoszony programistom, zmieniliśmy hasła/klucze API, a firma programistyczna, która nas obsługuje, usunęła przed tym lukę bezpieczeństwa. Proszę jednak przesłać szczegóły, możliwe że coś przeoczyliśmy.

Badamy sprawę razem z firmą od programu fakturowego, nasz Inspektor Danych Osobowych został o sprawie poinformowany. W bazie faktur i paragonów nie występują dane wrażliwe – wyłącznie imię, nazwisko i adres (NIP i nazwa firmy też niekiedy, ale to dane „publiczne”), bez numerów telefonów i bez e-maili.

Na pochwałę na pewno zasługuje tutaj błyskawiczne tempo reakcji (20 minut od zgłoszenia!). Pozytywne są również odpowiedzi w rozsądnym tonie, bez „zamydlania oczu”.

Przed publikacją tekstu poprosiliśmy jeszcze pana Dariusza o komentarz do całej sytuacji i otrzymaliśmy takie wyjaśnienia:

(…) nie doszło do pobrania bazy klientów, która zawierała dane w postaci imienia, nazwiska i adresu fakturowego, bez e-maila i nr telefonu. Zweryfikowaliśmy to po swojej stronie i otrzymaliśmy potwierdzenie od Fakturowni, że do tego nie doszło. Pan Paweł otworzył jeden dokument sprzedaży [ten jeden klient został o tym fakcie poinformowany w terminie i sposobie zgodnym z przepisami prawa. Mamy powołanego inspektora ochrony danych (osoba biegła w tematyce), która pilotowała sprawę w tym zakresie.]

Według naszych programistów luka została już usunięta oraz zabezpieczyli się na przyszłość na występowanie podobnych luk. Ponadto mają częściej wykonywać audyty bezpieczeństwa naszych systemów.

Jakie mamy wnioski dla wszystkich?

  1. Pamiętaj aby usunąć katalog .git (i inne „wrażliwe” pliki i katalogi – tutaj większe opracowanie o temacie)
  2. Sprawdź czy klucz do API, którego używasz w aplikacji nie daje daje dostępu do wszystkich operacji (np. jest to to master key dający dostęp jako administrator). Powinna tutaj obowiązywać zasada „najmniejszych uprawnień” – klucz powinien dawać dostęp tylko do tego co jest wymagane przez aplikację (np. wystawianie/pobieranie dokumentów księgowych, ale już nie zakładanie nowych użytkowników).
  3. Wykonuj regularne testy bezpieczeństwa (wskażą one Ci luki/podatności, które możesz następnie „na spokojnie” załatać).
  4. Po zgłoszeniu tego typu problemu bezpieczeństwa / po incydencie zmień wszystkie klucze API / hasła – do których można było publicznie uzyskać dostęp.
  5. Potwierdź do jakich danych udało się uzyskać dostęp.
  6. Współpracuj z badaczami bezpieczeństwa. Dzięki nim Twój system będzie bezpieczniejszy i możesz uniknąć niekontrolowanego wycieku danych.

–ms

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Z tymi wnioskami jest ten problem, że one nie są dla wszystkich. One są dla tych, którzy są już (choćby w pewnym stopniu) przekonani, że w dzisiejszym świecie niezbędne są wydatki na bezpieczeństwo.

    Przydałyby się jeszcze wskazówki dla tych, którzy przekonani nie są. Być może w nieco bardziej dosadnej formie. Zacząć by tu trzeba od obalenia u czytelnika mitu „ale przecież my nie jesteśmy korporacją i nie mamy żadnych ważnych danych” – bo to ten mit leży u podstawy podejścia, że nie ma co marnować kasy na bezpieczeństwo, skoro nikt nie będzie akurat ich celowo atakował, bo i po co…

    Odpowiedz
    • Komasz Tlim

      Panie Tomaszu, dlaczego Pan już tak chętnie nie pisze do niebezpiecznik.pl w komentarzach?

      Odpowiedz
    • Jaro

      Drogi kolego,
      podejście straszenia bezpieczeństwem, jest podejściem czasów minionych. Jeśli chcesz straszyć i nie masz nic więcej do powiedzenia, to nikogo tym nie przekonasz, a wręcz zrobisz większą krzywdę.

      Szanuję Sekuraka za danie na tacy prawidłowych rozwiązań, zamiast straszyć wilkiem w lesie.

      Odpowiedz
      • asdsad

        Święte słowa!
        Bo to jest świetna metoda: pogodzić się z tym, że dane klientów pójdą w świat albo się utracą. Wtedy nie trzeba się bać.

        Odpowiedz
        • MK

          No bo zabezpieczenia należy robić z przemyśleniem i adekwatnie do ryzyka. Jak się robi ze strachu, to potem biznes ma związane ręce. Nic nie można robić, bo to „niebezpieczne”. Zatem i koszty powinny być adekwatne do ryzyka. Najpierw funkcjonalność, potem bezpieczeństwo. Nigdy odwrotnie.

          Odpowiedz
          • asdsad

            Ta, jasne…
            Jak niby szacować ryzyko? Przykłady oparte na forsie: Jeśli mam dużo kasy, to zamek ma być lepszy niż jak mam mało kasy? Przecież złodziej nie wie ile mam, więc ryzyko włamu jest identyczne. A jak już do niego dojdzie, to ukradnie mi WSZYSTKO, więc w obu przypadkach zostanie mi równe ZERO.
            A może mam spać spokojnie, jeśli kasę mam w dwóch skrytkach po równo, bo ukradną mi „najwyżej” połowę?

            Najpierw bądź ofiarą przestępcy, a potem kup se zamek do drzwi. Bo wygoda pierwsza.

            Wiadomo, że można się zastanawiać czy kupować zabezpieczenie warte tyle, co chronione dobro.

            Ale „najpierw funkcjonalność, potem bezpieczeństwo”?!? Jak dla mnie głupota. Gdzie się da mam włączone 2FA. Najchętniej U2F. Gdzie się nie da, to SMS. Ostatecznie e-mail. + Żadnego dodawania urządzeń jako zaufane. I żyję.
            Może jeszcze hasła jednakowe wszędzie ustawiać?

  2. Miki

    Apeluje poraz kolejny o nieumieszczanie kodu w obrazkach. Uniemożliwia to czytanie niewidomym użytkownikom czytników ekranu. Jeżeli już musicie, przeklejcie chociaż kod do alta, zamiast zostawiać go pustym.

    Odpowiedz
    • To moja wina, taki obrazek wysłałem im ja, bo jest tam zaciemniony fragment :)

      Pozdrawiam,
      artykułowy Paweł ;)

      Odpowiedz
    • Ack. Choć czasem jest ciężko (jak mamy jako źródło tylko obrazek, a nie kod ;)

      Odpowiedz
      • Mogę potem pogrzebać, może jeszcze mam źródła to wyślę Wam ten fragment z wyredagowanym kluczem na maila żeby faktycznie wstawić w alt czy coś :)

        Odpowiedz
  3. ToJa

    A ten Pan Paweł to miał pozwolenie na „testowanie” powyższej aplikacji webowej? Z tego, co mi wiadomo – działanie to nie jest zgodne z prawem…

    Odpowiedz
    • Art. 269c Kodeksu karnego:
      Nie podlega karze za przestępstwo określone w art. 267 § 2 lub art. 269a, kto działa wyłącznie w celu zabezpieczenia systemu informatycznego, systemu teleinformatycznego lub sieci teleinformatycznej albo opracowania metody takiego zabezpieczenia i niezwłocznie powiadomił dysponenta tego systemu lub sieci o ujawnionych zagrożeniach, a jego działanie nie naruszyło interesu publicznego lub prywatnego i nie wyrządziło szkody.

      Pan Paweł: a) działał wyłącznie w celu zabezpieczenia systemu informatycznego b) niezwłocznie powiadomił właściciela c) jego działanie nie naruszyło interesu publicznego lub prywatnego i nie wyrządziło szkody

      Odpowiedz
  4. Marek

    „(…) wyjaśnienia od Pana Dariusza Ożóg.”
    Nazwiska w języku polskim się deklinują, więc powinno być „Ożoga” :)

    Odpowiedz
  5. Konusek

    Tzn. że prawo jest dziurawe. Mamy prawa i prawka. Pytanie do securaka. Skąd wiecie że te punkty nie zostały naruszone. A, B, C? O taki paradoks…… 😂 U nas w Polsce jest prawo i lewo. Ale co ja mogę

    Odpowiedz
    • Skąd wiemy? Z relacji obu stron. Oczywiście nie robiliśmy tutaj pełnego profesjonalnego dochodzenia, czy przypadkiem nie było inaczej ;)

      Odpowiedz
  6. Michał

    Tez znalazłem .git na stronie sklepu z materacami. Znalazłem tam dane do logowania do serwera mysql który wpuszczał z całego świata. Powiadomiłem ich problem usunęli, ale nie raczyli nawet odpisać.

    Odpowiedz

Odpowiedz