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

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):

1. define('INTEGRATOR_FAKTUROWNIA', 1); // czy zamiast modułu faktur korzystać z fakurowni?
2. define('FAKTUROWNIA_API_KEY', '[fragment wyredagowany]/loveair');
3. define('FAKTUROWNIA_API_URL', 'http://loveair.fakturownia.pl/');

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