Aktualności

Kilka miliardów dolarów wyszło z portfeli giełdy kryptowalut Binance, w większości w pierwszych dwudziestu minutach, a według wstępnych ustaleń giełdy atak mógł obejmować laptop inżyniera i kontener usługi. To dwa elementy, które istnieją w wielu firmach, w których zespół wdraża oprogramowanie, a automat zleca przelewy. Stawką jest to, co w takiej chwili da się jeszcze zamrozić i kto o tym decyduje.

Osobno stoi to, co podał sam Binance, a osobno to, co o mechanizmie i sprawcach mówią TRM Labs i Chainalysis. Zestawiamy kwoty brutto z trzech źródeł i porównujemy atak z Bybit, Ronin i Bitfinex z zaznaczoną metodą wyceny, a do tego opisujemy włamania do Bybit i Bitget, które go poprzedziły. Na końcu są rekomendacje redakcji dla firm, które nie prowadzą giełdy: pięć kontroli, z których trzy opieramy na art. 21 ust. 2 dyrektywy NIS2, a dwie na zaleceniach TRM, oraz lista pytań, na które odpowiedzi jeszcze nie ma.

Po śmierci bliskiej osoby zostają jej konta: profil w mediach społecznościowych, skrzynka pocztowa i chmura ze zdjęciami. Rodzina chce je zamknąć, zachować albo wydobyć z nich pamiątki, a każda platforma odpowiada inaczej, bo według NASK polskie przepisy nie ustalają obowiązków serwisów wobec kont zmarłych. Konto, którego nikt nie pilnuje, bywa przy tym łupem: nie ma komu zmienić hasła ani włączyć drugiego składnika logowania, a NASK opisuje sprawców, którzy przejmują profile zmarłych, piszą do ich bliskich i żądają pieniędzy za oddanie konta.

Artykuł zestawia w jednej tabeli procedury Facebooka, Instagrama, Google, Apple i Microsoftu: kto może zgłosić śmierć, jakiego dokumentu to wymaga, co rodzina dostaje i czego nie dostanie od żadnej z tych firm. Wyjaśnia, co działa tylko wtedy, gdy właściciel ustawi to za życia, co o danych zmarłych mówi RODO i jak niemiecki sąd rozstrzygnął dziedziczenie konta. Pokazuje też przejęcie profilu krok po kroku i osobno opisuje konta zmarłego pracownika.

Aplikacja z niezałataną kopią dekodera, która rozpakowuje dane w formacie Brotli, ryzykuje uszkodzenie pamięci własnego procesu już w chwili, gdy dekoder czyta spreparowany strumień, a więc zanim jej kod, logowanie czy uprawnienia zobaczą cokolwiek z treści. Dotyczy to serwerów przyjmujących skompresowane żądania, klientów pobierających odpowiedzi od cudzych serwerów i programów otwierających wgrane pliki, także wtedy, gdy Brotli trafiło do nich ukryte w zależności. Poprawka dla Node.js wyszła w trzech liniach, ale pozostałe środowiska mają własne kopie dekodera i własne terminy.

Dostajesz tabelę środowisk z wersją poprawki i statusem na 28 października 2026 roku: Node.js, Bun, Python, Java, .NET, PHP, Ruby, Go, curl, Envoy i Istio, z osobnym oznaczeniem tam, gdzie poprawki wciąż brakuje. Do tego kolejność działań od inwentarza po restart procesów, sposób odrzucania skompresowanych danych tam, gdzie poprawki jeszcze nie ma, wskaźniki do przejrzenia w logach i chronologia od lutowego commita do wydań z ostatnich dni. Rozdzielamy też ocenę GitHuba od oceny Node.js i wyjaśniamy trzy nazwy, pod którymi luka krąży.

Strony, sklepy i aplikacje działające na PHP są narażone na dwie krytyczne podatności, przez które atakujący może bez logowania uruchomić własny kod na serwerze. Błąd uruchamia się, zanim ruszy kod aplikacji, więc nie chronią przed nim ani hasła, ani role użytkowników, a pierwszą znaną próbę ataku zarejestrowano cztery dni przed publikacją poprawek. W Polsce część stron Biuletynu Informacji Publicznej została czasowo wyłączona, a Wykop tymczasowo wyłączył serwis.

Dostajesz zestawienie wersji PHP z poprawką i bez niej, kolejność działań od inwentaryzacji po restart procesów oraz zestawienie ustawień php.ini z rozróżnieniem, co zaleca zespół PHP, a co CERT Polska i czego te ustawienia nie zamykają. Pokazujemy też, co przejrzeć w logach i w systemie, gdzie zgłosić ślady włamania i jak wyglądała droga od sierpniowego odkrycia do ujawnienia, z godzinami podanymi w UTC, oraz co zrobiły polskie instytucje.

Kupujący używany telefon, tablet lub komputer Mac trafia czasem, już po wyzerowaniu sprzętu, na ekran zarządzania obcej organizacji, a sprzedawca nie umie albo nie chce pomóc. Po drugiej stronie stoi firma, która sprzedaje flotę i chce, żeby kolejny właściciel nie trafił na ten ekran. Obie strony potrzebują tej samej wiedzy: co ten ekran oznacza i kto może go zdjąć.

Artykuł pokazuje, kto może zdjąć taką blokadę w Apple Business, w zero-touch od Google i w Knox Mobile Enrollment od Samsunga, dlaczego usługi obiecujące obejście nie zastępują drogi przewidzianej przez producenta i jakie prawa przysługują kupującemu od firmy, a jakie od osoby prywatnej. Osobna część prowadzi firmę przez zwolnienie urządzeń przed sprzedażą, z kolejnością kroków dla Apple, Google i Samsunga, tabelą platform i wymazem danych osobowych, który zwolnienia nie zastępuje. Całość opiera się na dokumentacji producentów, tekstach ustaw i wytycznych NIST.

Serwisy od lat żądają wielkiej litery, cyfry i znaku specjalnego, a hasła mimo to są odgadywane, bo wymóg składu spełnia się jednym dopisanym znakiem, co CERT Polska widzi w hasłach z dopisaną jedynką. Atakujący nie zgaduje wtedy od zera. Przechodzi po gotowych wzorcach, a wyciekłe hasło sprawdza na kolejnych kontach, więc jedno słabe albo powtórzone hasło otwiera więcej drzwi, niż zwykle się zakłada.

Tekst przekłada to, co o hasłach mówią dziś amerykański standard NIST i CERT Polska, na decyzje osoby prywatnej: od ilu znaków hasło przestaje być łatwym celem, dlaczego reguły składu zawodzą, dlaczego pierwszym wyborem jest hasło wygenerowane w menedżerze haseł i jak ułożyć ciąg do zapamiętania tam, gdzie menedżer nie pomoże. Opisuje też klucze dostępu jako zamiennik hasła oraz to, co zostaje po stronie użytkownika nawet przy dobrym haśle. Zamiast gotowców dostajesz schematy, bo każdy opublikowany przykład trafia do słowników atakujących.

Firma, która układa zasady dla haseł pracowników, szuka w przepisach liczb: ile znaków, jak często zmieniać, czy wymagać cyfr i znaków specjalnych. W NIS2 i w ustawie o krajowym systemie cyberbezpieczeństwa takich liczb nie ma, a CERT Polska zauważa, że wiele organizacji nadal wymusza cykliczną zmianę hasła i znaki specjalne, choć sam ocenia te praktyki jako szkodliwe. Skutek bywa podwójny: pracownicy dostają reguły bez podstawy, a wymóg, który istnieje dla wąskiej grupy dostawców usług cyfrowych, może umknąć.

Artykuł oddziela wymóg od zalecenia i pokazuje je w jednej tabeli: co mówią dyrektywa, ustawa i rozporządzenie wykonawcze, a co rekomenduje CERT Polska, razem z napięciem między okresową zmianą danych uwierzytelniających a zaleceniem, by jej nie wymuszać. Dalej wyjaśnia, po co filtr oparty na znanych hasłach z wycieków i kiedy drugi składnik logowania wynika z przepisów. Do wydruku jest karta dla pracowników na jednej stronie A4, a na końcu opisujemy prace, które firma zamawia u wykonawców.

Reguły haseł w organizacjach zwykle zaczynają się od składu: wielka litera, cyfra, znak specjalny. Hasła, które wyciekają z serwisów, układają się jednak w kilka powtarzalnych schematów, a wśród nich imię z dopisaną cyfrą, ciąg sąsiednich klawiszy i długość urywająca się na ośmiu znakach. Skoro schematy powtarzają się w milionie wpisów, słownik takich haseł powstaje łatwo, a CERT Polska określa to zadanie dla przestępcy jako znikome.

Dostajesz przeliczenie całej listy CERT Polska w kategoriach: długość, imiona i zdrobnienia, ciągi klawiszy, końcówki cyfrowe, wielkie litery i znaki specjalne, każde w czterech progach rankingu od pierwszej setki po cały milion. CERT opisał pięćdziesiąt pierwszych pozycji, a tu liczy się cały zbiór, z definicjami kategorii i sumą kontrolną pliku wejściowego. Udziały dotyczą wpisów, nie ludzi, a na końcu przekładamy je na decyzje o hasłach w organizacji: odrzucanie haseł znanych z wycieków, minimalną długość, drugi składnik logowania i menedżer haseł.

Zaszyfrowane serwery, żądanie zapłaty i zarząd, który chce usłyszeć jedno słowo: tak albo nie. Tak prostej odpowiedzi zwykle nie ma, a pytanie pada w najgorszym momencie, gdy każda godzina bez systemów kosztuje, a decyzję trzeba będzie później uzasadnić. O tym, czy zapłata jest legalna, decyduje przede wszystkim to, do kogo trafią pieniądze. O tym, czy ma sens, od lat wypowiadają się instytucje publiczne, a kto w firmie bierze tę decyzję na siebie, przepisy o sankcjach i ochronie danych nie rozstrzygają. Firmy objęte ustawą o krajowym systemie cyberbezpieczeństwa i RODO mają do tego zegar zgłoszeń, który rusza z wykryciem incydentu albo stwierdzeniem naruszenia.

Rozdzielamy to, co wynika z przepisów, od zaleceń Europolu, ENISA, CERT Polska i Ministerstwa Cyfryzacji, a każde ustalenie ma wskazane źródło. Pokazujemy, na czym opiera się ostrzeżenie, że zapłata nie gwarantuje odzyskania danych, kiedy przelew może zatrzymać bank i które terminy zgłoszeń biegną bez względu na decyzję zarządu. Na końcu znajdziesz pięć pytań, na które powinien odpowiadać zapis decyzji o okupie, także odmownej.

Pod koniec września 2026 roku w odstępie kilku dni ujawniono trzy incydenty: w oprogramowaniu Medyc firmy Qbusoft, z którego korzystają placówki medyczne, w sieci Enel-Med i w serwisie do faktur Fakturownia. Chodzi o numery PESEL i adresy pacjentów, dane kont, rachunki bankowe i kontrahentów przedsiębiorców, a zawiadomienie jednej z placówek mówi także o danych o zdrowiu. Firmy podają różny zakres i różne daty, sprawcy własne liczby, a do skrzynek mogą trafiać zarówno prawdziwe zawiadomienia, jak i wiadomości, które tylko je udają.

Każdą sprawę rozkładamy na daty i źródła: co firmy potwierdziły, co pozostaje deklaracją sprawców i gdzie relacje stron się rozchodzą. Zestawiamy tempo informowania firm, sprawdzamy, co naprawdę łączy te incydenty, i opisujemy własne nagranie strony statusowej Medyc z 21 września, zrobione trzy dni przed ujawnieniem wycieku. Na końcu są osobne kroki dla pacjentów i dla użytkowników Fakturowni.