Włamanie do Fakturowni: po co dostawcom faktur program nagród

Program nagród za podatności w systemie do fakturowania płaci badaczom za potwierdzone błędy, które mogą ujawnić dane klientów, naruszyć integracje lub zmienić dane finansowe. Najpierw trzeba jednak uruchomić program ujawniania podatności (VDP): określić bezpieczny zakres testów, udostępnić kanał zgłoszeń i wyznaczyć osoby, które sprawdzą oraz naprawią znalezione błędy. Komunikat Fakturowni z 29 września pokazuje, dlaczego ma to znaczenie dla platformy przechowującej konta i dokumenty innych firm. Nie ma publicznych dowodów, że program nagród zapobiegłby temu włamaniu.

Co potwierdziła Fakturownia?

Fakturownia podaje, że 28 września 2026 roku wykryła nieuprawniony dostęp do swoich serwerów. W komunikacie opublikowanym dzień później napisała, że osoba nieuprawniona wykorzystała lukę w systemie i miała wgląd w dane kont użytkowników, kontrahentów oraz dokumenty wygenerowane w serwisie. To data wykrycia zdarzenia, a nie ustalony początek włamania. Spółka nie opisała technicznie podatności ani nie potwierdziła, ile danych wyniesiono.

Według Fakturowni dostęp mógł obejmować dane kont wszystkich użytkowników, ich kontrahentów i faktury wystawione przed 2023 rokiem. Firma wymienia skróty haseł, tokeny sesji oraz tokeny API i integracji wygenerowane po jej stronie, numery rachunków i dane o płatnościach, część danych z faktur, a także klucze i hasła systemowe aplikacji. Skrót hasła użytkownika to nie jego hasło w jawnym tekście. Możliwy dostęp do tokenów i sekretów systemowych wymaga jednak osobnej oceny. Fakturownia informuje, że odcięła nieuprawniony dostęp, rozpoczęła rotację kluczy i haseł, uruchomiła nowe serwery oraz zawiadomiła CBZC, CERT Polska i UODO. Analiza zdarzenia trwa.

Spółka podaje też, że według dotychczasowych ustaleń incydent nie objął certyfikatów KSeF, danych przechowywanych w integracjach, danych kart płatniczych ani faktur wystawionych po 2023 roku. Komunikat nie wyjaśnia jednoznacznie, co z fakturami z samego 2023 roku. Tokeny integracji wygenerowane po stronie Fakturowni i dane przechowywane w zewnętrznych integracjach to różne kategorie. Nie należy łączyć obu stwierdzeń w jedno.

Zaufana Trzecia Strona podała, że osoba przyznająca się do ataku twierdzi, iż wykradła 6 TB faktur. To deklaracja atakującego, a nie wielkość potwierdzona przez Fakturownię. Publikacja przytacza także domniemany sposób włamania, ale firma potwierdziła tylko wykorzystanie luki w systemie. Szczegółowy przebieg ataku, tożsamość sprawcy i objętość wyniesionych danych pozostają publicznie niezweryfikowane.

Dlaczego jeden błąd w systemie do faktur dotyka wielu firm?

Dostawca systemu do fakturowania skupia dane kilku stron. Konto klienta może zawierać uprawnienia pracowników, nazwy i dane kontaktowe kontrahentów, numery rachunków, pozycje faktur oraz dane uwierzytelniające używane przez systemy księgowe, sklepy i usługi płatnicze. Błąd po stronie platformy może więc wymagać reakcji wielu firm, ich zespołów finansowych i osób, które nigdy nie założyły w niej konta.

Dlatego zgłoszenie dotyczące dostępu między kontami firm trzeba potraktować inaczej niż błąd wizualny. Jeśli jedno konto testowe należące do badacza może odczytać fakturę z osobnego konta testowego, ktoś po stronie dostawcy musi odtworzyć problem, sprawdzić pozostałe miejsca z podobną kontrolą dostępu, wdrożyć poprawkę i odpowiedzieć badaczowi. Badacz powinien móc wykazać błąd na kontach i dokumentach, które sam kontroluje, bez otwierania cudzej faktury. OWASP API Security Top 10 wskazuje błędy autoryzacji dostępu do obiektów i uwierzytelniania jako osobne zagrożenia dla API. Oba warto uwzględnić w zasadach testów platformy do fakturowania.

Podobnie jest z tokenami dostępowymi i polami związanymi z płatnościami. Zgłoszenie może pokazać, że token działa po odwołaniu, użytkownik wykonuje działania poza przypisanym kontem albo zmianę rachunku bankowego da się przeprowadzić z pominięciem zabezpieczenia. To przykłady proponowanego zakresu programu nagród, a nie ustalenia dotyczące ataku na Fakturownię. Testy zewnętrzne mogą pomóc znaleźć błędy w dostępnych interfejsach produktu. Nie zastąpią bezpiecznego projektowania, przeglądu kodu, ograniczania uprawnień, monitoringu ani reagowania na incydenty.

Co naprawdę wynika ze starszych komentarzy o programie nagród?

Publiczne ślady skłaniają do pytania, jak zgłoszenie podatności trafia do osoby odpowiedzialnej za produkt. W indeksie forum Fakturowni widać pytanie z 2016 roku o planowany program BugBounty. Nie udało nam się zweryfikować odpowiedzi w podlinkowanym wątku. Publiczna strona Fakturowni o bezpieczeństwie opisuje zgłaszanie podejrzanych faktur, phishingu i problemów ze stroną logowania. Na sprawdzonej przez nas stronie nie ma zakresu testów podatności, zasad safe harbor, terminu odpowiedzi ani reguł przyznawania nagród. Nie dowodzi to, że firma nie ma wewnętrznego lub prywatnego procesu przyjmowania takich zgłoszeń.

W komentarzach na LinkedIn przekazanych nam po incydencie dwie osoby twierdzą, że we wcześniejszych latach zgłaszały Fakturowni błędy. Jedna z nich pisze o rozwiązaniach typu proof of concept dotyczących przychodów spółki, a nie bezpieczeństwa danych klientów. Nie widzieliśmy tych zgłoszeń, odpowiedzi firmy ani dowodu na związek między tymi relacjami a włamaniem. Komentarze nasuwają pytanie o konstrukcję programu, ale nie potwierdzają, że wcześniej zignorowano podatność wykorzystaną w ataku.

To pytanie dotyczy także innych dostawców. Co robią, gdy ktoś zgłosi rzeczywiste nadużycie, które nie pasuje do krótkiej listy podatności technicznych? Luka w naliczaniu opłat lub rabatów nie zawsze jest podatnością bezpieczeństwa. Nadal powinna trafić do osoby, która oceni jej skutki, zdecyduje o ewentualnej nagrodzie i odpowie zgłaszającemu. Firma, która pomija takie zgłoszenie bez oceny, traci użyteczny sygnał, nawet jeśli jej program bezpieczeństwa nie przewiduje za niego nagrody.

Do kogo powinno trafić zgłoszenie błędu w systemie do faktur?

Dobry program określa kolejną decyzję, a nie tylko adres e-mail. Wytyczne NIST zalecają formalny proces przyjmowania, oceny i obsługi zgłoszeń oraz komunikacji z badaczami. Zespół bezpieczeństwa może przyjmować je jako pierwszy, ale musi umieć przekazać sprawę osobie z inżynierii, finansów lub produktu, która może podjąć działanie.

W każdym przypadku badacz potrzebuje potwierdzenia odbioru, informacji o postępie i uzasadnionej decyzji. Potwierdzony błąd nie powinien utknąć między zespołami, z których jeden uzna go za problem produktu, a drugi za kwestię bezpieczeństwa. Firma może ustalić odmienne zasady nagradzania, ale musi opublikować ich granicę i odpowiadać za przekazanie sprawy.

Co opublikować przed uruchomieniem nagród?

Opublikuj program ujawniania podatności (VDP) z łatwym do znalezienia kontaktem, zakresem własnych systemów i API, zasadami safe harbor dla testów prowadzonych w dobrej wierze, terminami odpowiedzi i sposobem wyjaśniania wątpliwości co do zakresu. Plik security.txt może wskazać kontakt i zasady, ale sam nie daje zgody na testy. Szersze kroki opisuje poradnik konfiguracji VDP.

W przypadku systemu do faktur przygotuj dwa osobne konta testowe należące do badacza i fikcyjne dokumenty. Na jednym koncie może działać kilka firm, więc dwa wpisy firmowe na tym samym koncie nie wystarczą do sprawdzenia granicy między kontami. Gdy badacz natrafi na prawdziwe faktury, numery rachunków bankowych lub dane uwierzytelniające, powinien przerwać test i przesłać minimalny dowód z zasłoniętymi danymi. Zabroń masowego pobierania danych, zmian płatności, testów destrukcyjnych, socjotechniki i testów obciążeniowych. Wymień tylko systemy, które należą do dostawcy albo na których testowanie ma zgodę. Aktualna polityka Visma pokazuje, jak rozdzielić szeroki kanał zgłoszeń z zasadami safe harbor od płatnego programu ograniczonego do wskazanych systemów.

Potem zapewnij budżet na płatny program nagród o określonym zakresie, kiedy zespół potrafi sprawdzać dodatkowe zgłoszenia, naprawiać błędy i wypłacać obiecane kwoty. OWASP zwraca uwagę, że nagrody zwiększają zarówno liczbę zgłoszeń, jak i pracę potrzebną do ich obsługi. Płać za wykazany wpływ błędu, a nie za etykietę przypisaną zgłoszeniu. Opublikuj przedziały kwot i zasady duplikatów, żeby badacz wiedział, czego oczekiwać. Szczegóły opisuje poradnik ustalania nagród.

Żadne publiczne źródło nie wskazuje, że badacz z zewnątrz wcześniej znalazł lukę wykorzystaną przeciw Fakturowni, mógł ją bezpiecznie przetestować lub próbował ją zgłosić. Nie można przypisać programowi nagród zdolności zapobieżenia temu incydentowi. Może on za to zwiększyć szansę, że przyszły błąd trafi do odpowiedzialnego zespołu, zanim ktoś wykorzysta go przestępczo.

Co klienci Fakturowni powinni zrobić i o co zapytać?

Zgodnie z komunikatem Fakturowni z 29 września klienci powinni zmienić hasło do konta i wszędzie tam, gdzie używali tego samego hasła, zabezpieczyć powiązaną skrzynkę e-mail, włączyć uwierzytelnianie dwuskładnikowe oraz sprawdzić numer rachunku i listę użytkowników w ustawieniach. Spółka ostrzega też przed wiadomościami i telefonami podszywającymi się pod banki, urzędy, Fakturownię lub kontrahentów. To jej publiczne zalecenia na czas ustalania, kogo powiadomić. O stan używanych tokenów sesji, API i integracji warto zapytać Fakturownię bezpośrednio: komunikat wymienia je wśród danych, do których mógł być dostęp, ale nie zawiera kompletnej instrukcji ich wymiany dla klientów.

Następnie zapytaj dostawcę o proces zgłaszania podatności. Czy badacz bez konta znajdzie kontakt do zespołu bezpieczeństwa? Czy zasady dopuszczają testowanie systemów dostawcy, a zarazem chronią dane klientów? Czy zgłoszenie dotyczące faktury z innego konta, tokenu, rachunku lub reguły naliczania opłat trafi do osoby, która może naprawić błąd i odpowiedzieć badaczowi? Te pytania dotyczą systemów księgowych, platform rozliczeniowych i również naszej kategorii narzędzi związanych z KSeF. Artykuł o safe harbor wyjaśnia znaczenie zgody na testy, a poradnik określania zakresu pokazuje granicę między systemami dostawcy a infrastrukturą klienta.

Jak Kit pomaga przejść od zgłoszenia do decyzji?

Kit pomaga opublikować program z określonym zakresem testów i łatwy do znalezienia kontakt w pliku security.txt. Badacz może wysłać zgłoszenie przez portal. Zespół przypisuje osobę prowadzącą sprawę, pilnuje czasu odpowiedzi, omawia podatność i zapisuje ewentualną decyzję o nagrodzie. Kit śledzi przekazanie sprawy do wypłaty, a pieniądze firma przelewa przez własnego dostawcę płatności.

Najprostsza próba to wysłanie fikcyjnego zgłoszenia o dostępie między kontami i sprawdzenie drogi od odbioru do decyzji zespołu inżynierskiego oraz odpowiedzi dla badacza. To pokaże, czy badacz otrzyma odpowiedź. Kit porządkuje ten proces. Dostawca nadal musi zbadać błąd, naprawić go i chronić klientów.