Incydent bezpieczeństwa w Fakturownia.pl. Czy dane klientów naszego biura są bezpieczne?

Incydent dotyczący Fakturownia.pl nie spowodował naruszenia systemów księgowych wykorzystywanych przez nasze biuro.

Nasze biuro nie korzysta z Fakturownia.pl do prowadzenia księgowości

Chcemy przede wszystkim uspokoić naszych klientów: nie wykorzystujemy Fakturownia.pl jako systemu księgowego ani jako miejsca przechowywania dokumentacji księgowej naszych klientów.

Niektórzy przedsiębiorcy korzystający z naszych usług mogą oczywiście samodzielnie używać Fakturownia.pl do wystawiania faktur. Jest to jednak system wybrany i wykorzystywany przez danego przedsiębiorcę, niezależnie od infrastruktury informatycznej naszego biura rachunkowego.

Bezpieczeństwo danych jest częścią usługi księgowej

Nowoczesna księgowość to już nie segregatory pełne dokumentów. Biuro rachunkowe przetwarza m.in. faktury, wyciągi bankowe, dane pracowników, informacje o wynagrodzeniach, rozrachunkach, podatkach oraz kontrahentach.

Dlatego wybierając biuro rachunkowe, warto pytać nie tylko o cenę prowadzenia księgowości.

Warto również wiedzieć:

gdzie przechowywane są dane księgowe,
kto ma do nich dostęp,
w jaki sposób zabezpieczone są konta użytkowników,
czy wykonywane są kopie zapasowe,
w jaki sposób zabezpieczane są integracje między systemami,
czy pracownicy otrzymują wyłącznie dostęp niezbędny do wykonywania swoich obowiązków,
jak biuro reaguje na potencjalne incydenty bezpieczeństwa.

Nie istnieje system, którego bezpieczeństwo można zagwarantować w 100%

Dlatego nie będziemy obiecywać naszym klientom, że jakikolwiek wykorzystywany przez nas system jest „niemożliwy do zhakowania”.

Takiej gwarancji nie może odpowiedzialnie udzielić żaden dostawca usług informatycznych ani biuro rachunkowe.

Możemy natomiast ograniczać ryzyko poprzez odpowiedni dobór systemów, kontrolę dostępu, kopie zapasowe, aktualizacje, właściwe zarządzanie uprawnieniami oraz ograniczanie liczby miejsc, w których przechowywane są dane.

To właśnie takie podejście stosujemy w naszej pracy.

Korzystasz z Fakturownia.pl?

Sam fakt korzystania z Fakturownia.pl nie oznacza, że należy w panice zmieniać system. Dostawca poinformował o incydencie oraz wskazał działania, które powinni wykonać użytkownicy.

Jeżeli jesteś naszym klientem i samodzielnie korzystasz z Fakturownia.pl, zalecamy przede wszystkim zapoznanie się z komunikatem dostawcy i wykonanie wskazanych przez niego czynności bezpieczeństwa.

Szczególną ostrożność warto zachować wobec wiadomości dotyczących płatności i zmian numerów rachunków bankowych.

Co jest już potwierdzone przez Fakturownię

CTO Fakturowni Paweł Charyło przekazał Niebezpiecznikowi, że napastnik znalazł i wykorzystał podatność w szablonach faktur, a następnie dziurę w bibliotece do generowania PDF-ów.

Według Fakturowni dzięki temu zdobył klucz używany do podpisywania sesji, a znajomość tego klucza pozwoliła mu następnie uzyskać dostęp do serwera. Źródło: niebezpiecznik.pl

To jest bardzo istotna informacja, bo wygląda na pełny łańcuch eskalacji, a nie zwykłe „wykradziono hasło administratora”.

W uproszczeniu najbardziej prawdopodobny przebieg wygląda więc tak:

podatność w szablonie faktury → generator PDF → ujawnienie/uzyskanie sekretu aplikacji → klucz podpisujący sesje → sfałszowana sesja/cookie → przejęcie uprawnień → dostęp do serwera → baza/dane

Fakturownia nie ujawniła publicznie dokładnej biblioteki PDF ani konkretnego CVE. Szczegóły mają trafić do CERT Polska i organów ścigania. Źródło: niebezpiecznik.pl

Co ciekawe, oficjalna chronologia działań obronnych bardzo dobrze pasuje do tego scenariusza: 28 września firma zmieniła klucze aplikacji i hasła usług, postawiła nowe serwery od zera, dezaktywowała wykradzione klucze, a następnie o 2:35 29 września wdrożyła „dodatkowe zabezpieczenia generatora plików PDF”. Źródło: Fakturownia

To prawdopodobnie najmocniejszy publiczny dowód pośredni na to, że generator PDF rzeczywiście był elementem wejścia.

To pochodzi przede wszystkim z relacji osoby/grupy określanej jako Fingerprint, która przypisała sobie atak.

Według relacji przekazanej mediom atakujący miał użyć czegoś określanego jako „timing oracle” / wyrocznia czasowa, aby wydobyć główny sekret aplikacji Ruby. Następnie miał użyć tego sekretu do spreparowania ciasteczka/sesji i osiągnąć remote code execution na serwerze. Źródło: CyberScope.pl

Pierwsza interpretacja techniczna była więc mniej więcej taka:

time-based blind SQLi → odczyt sekretu/master key → sfałszowanie cookie Ruby/Rails → RCE

CERT Orange również opisywał możliwość wykorzystania time-based blind SQL injection. Źródło: CERT Orange

Dziś jednak nie przedstawialibyśmy SQL injection jako potwierdzonego faktu. Późniejsza odpowiedź CTO Fakturowni mówi wyraźniej o szablonach faktur i bibliotece PDF.

Możliwe, że oba opisy dotyczą różnych fragmentów tego samego łańcucha, ale bez raportu technicznego CERT nie da się tego potwierdzić.

Co budzi największe pytania o zaniedbania w Fakturownia.pl

Tu robi się ciekawie. Na forach pojawiają się zarzuty, których nie da się obecnie traktować jako potwierdzonych faktów, ale warto je odnotować.

Na Wykopie jeden z komentujących twierdzi, że już w 2023–2024 zgłaszał Fakturowni błędy bezpieczeństwa, które miały być ignorowane. Inni użytkownicy opisują podobne doświadczenia. W tej samej dyskusji przypomniano pytanie skierowane do Fakturowni jeszcze w 2016 r. o uruchomienie programu bug bounty. Źródło: Wykop

To oczywiście nie dowodzi, że zgłaszane wtedy błędy miały cokolwiek wspólnego z atakiem z 2026 r. Bez raportów tych podatności takie połączenie byłoby spekulacją.

Natomiast jeżeli potwierdziłoby się, że podatność była wcześniej zgłaszana albo była długo obecna w kodzie, ocena organizacyjnego bezpieczeństwa firmy wyglądałaby dużo gorzej.

Druga kwestia to zarządzanie sekretami.

Jeżeli kompromitacja komponentu odpowiedzialnego za PDF rzeczywiście umożliwiła zdobycie klucza pozwalającego później przejąć aplikację/serwer, nasuwa się bardzo poważne pytanie architektoniczne:

dlaczego proces generujący PDF miał możliwość dotarcia do sekretu o tak wysokiej wartości?

W dobrze izolowanej architekturze kompromitacja generatora dokumentów powinna mieć ograniczony „blast radius”. Generator PDF można np. uruchamiać w odseparowanym kontenerze/procesie bez dostępu do sekretów głównej aplikacji i infrastruktury.

Nie oznacza to automatycznie, że Fakturownia „nie stosowała izolacji” — szczegółów architektury jeszcze nie znamy — ale skala eskalacji wskazuje, że właśnie segmentacja i zarządzanie sekretami powinny być jednym z głównych tematów późniejszego post-mortem.

Jest jeszcze jeden bardzo ważny szczegół

Atak nie trwał miesiącami. Według aktualnego komunikatu Fakturowni nieautoryzowany dostęp trwał od około 27 września 03:20 do 28 września 17:45.

Mimo tak krótkiego okresu atakujący zdążył kopiować bazę na własne serwery. Fakturownia obecnie mówi już wprost, że incydent dotyczy każdego konta w Fakturowni. Źródło: Fakturownia

Według późniejszych informacji przekazanych przez CTO dostęp obejmował m.in. faktury utworzone do marca 2021 r., pozycje faktur do czerwca 2019 r. i kontrahentów utworzonych do 2024 r. Źródło: niebezpiecznik.pl

Atakujący twierdził natomiast, że zdobył około 6 TB danych/faktur. Tej liczby nie udało się niezależnie potwierdzić, więc nie traktowalibyśmy jej jako ustalonego faktu. Źródło: Definium GRC

Co naszym zdaniem warto obserwować?

Najważniejsze niewyjaśnione pytanie nie brzmi już „czy to był SQL injection?”, tylko:

jak dokładnie kompromitacja generatora PDF doprowadziła do zdobycia klucza podpisującego sesje i dlaczego zdobycie tego klucza pozwoliło następnie uzyskać dostęp do serwera?

To może ujawnić rzeczywisty problem architektoniczny.

Są trzy zupełnie różne możliwości: zwykły błąd w pojedynczej bibliotece; niebezpieczna konfiguracja Ruby/Rails i obsługi sesji; albo poważniejszy problem z izolacją usług, sekretami i uprawnieniami procesów. Dopiero techniczny raport CERT/Fakturowni pozwoli powiedzieć, czy mamy do czynienia przede wszystkim z pechową podatnością 0-day, czy z zaniedbaniami w projektowaniu bezpieczeństwa.

Jak 360BIURO dba o bezpieczeństwo danych klientów

Incydent w Fakturownia.pl traktujemy jako okazję, aby pokazać naszym klientom, w jaki sposób my sami chronimy powierzone nam dane. Poniżej opisujemy zasady, które stosujemy na co dzień — wraz z wyjaśnieniem, dlaczego każda z nich ma znaczenie.

1. Sprawdzone oprogramowanie zewnętrzne

Do prowadzenia księgowości korzystamy wyłącznie z oprogramowania renomowanych dostawców, które przechodzi regularne audyty bezpieczeństwa. Nie eksperymentujemy z niszowymi narzędziami tylko dlatego, że są tańsze — dostawca systemu księgowego musi mieć udokumentowane podejście do bezpieczeństwa.

2. Bezpieczne stacje robocze

W biurze pracujemy na komputerach z systemem macOS, który zapewnia wysoki poziom zabezpieczeń: szyfrowanie dysków, izolację aplikacji oraz regularne aktualizacje bezpieczeństwa instalowane na bieżąco. Zmniejsza to ryzyko, że dane klientów wyciekną przez zainfekowaną stację roboczą — a to wciąż jeden z najczęstszych wektorów ataku na małe firmy.

3. Nie przechowujemy loginów i haseł klientów

Nie gromadzimy danych dostępowych naszych klientów do ich systemów bankowych czy fakturowych. Czego nie przechowujemy, tego nie można nam wykraść — to najprostsza i najskuteczniejsza zasada minimalizacji ryzyka.

4. Izolacja generatora PDF w naszych aplikacjach

Nasze autorskie aplikacje generują pliki PDF na oddzielnym serwerze, dedykowanym wyłącznie temu procesowi, bez dostępu do sekretów i bazy danych głównej aplikacji. To dokładnie ten element architektury, którego brak najprawdopodobniej umożliwił eskalację ataku na Fakturownia.pl — nawet jeżeli komponent PDF zostałby skompromitowany, jego „blast radius” pozostaje ograniczony.

5. Logowanie wyłącznie kluczami Passkey

Dostęp do naszych aplikacji możliwy jest tylko za pomocą kluczy Passkey — metody uwierzytelniania odpornej na phishing. W przeciwieństwie do haseł, klucza Passkey nie da się podejrzeć, wykraść z bazy danych ani wyłudzić fałszywą stroną logowania.

6. Rotacja kluczy szyfrujących

Klucze szyfrujące wykorzystywane w naszych aplikacjach są regularnie rotowane. Nawet gdyby klucz kiedykolwiek wyciekł, jego przydatność dla atakującego jest ograniczona w czasie. Przypomnijmy: w ataku na Fakturownia.pl to właśnie zdobycie długowiecznego klucza aplikacji otworzyło napastnikowi drogę do serwera.

7. Zasada minimalnych uprawnień

Każdy użytkownik naszych aplikacji — w tym pracownicy biura — otrzymuje wyłącznie te uprawnienia, które są niezbędne do wykonywania jego obowiązków. Dzięki temu przejęcie pojedynczego konta nie oznacza dostępu do wszystkich danych.

8. Kopie zapasowe i aktualizacje

Regularnie wykonujemy kopie zapasowe danych oraz na bieżąco aktualizujemy wykorzystywane systemy. Kopie zapasowe chronią przed utratą danych, a szybkie instalowanie poprawek zamyka znane podatności, zanim ktokolwiek zdąży je wykorzystać.

9. Wąski krąg osób z dostępem do danych

Jesteśmy rodzinną firmą informatyczno-księgową. Do poufnych informacji — zwłaszcza kluczy, loginów i haseł do naszych aplikacji — nie dopuszczamy osób spoza tego grona. Krótka, przejrzysta lista osób z dostępem to mniejsze ryzyko zarówno błędu ludzkiego, jak i celowego nadużycia.

Szukasz biura rachunkowego, które poważnie traktuje bezpieczeństwo danych?

Prowadzenie księgowości oznacza powierzenie biuru jednych z najbardziej wrażliwych informacji dotyczących przedsiębiorstwa.

Dlatego bezpieczeństwo danych traktujemy jako element usługi księgowej, a nie jako dodatek do niej.

Jeżeli rozważasz zmianę biura rachunkowego i chcesz dowiedzieć się, w jaki sposób możemy prowadzić księgowość Twojej firmy, zapraszamy do kontaktu.