Nie wiem, czy powstanie seria artykułów „historie z Reddit” (mój ostatni wpis znajduje się w tym miejscu i również dotyczy tematyki ransomware), natomiast chciałbym opisać serię zdarzeń z wątku użytkownika SoliTheFox. Tym razem nie jest to już tak zabawna historia, ale zdecydowanie jest interesująca i wymaga szerszego przedstawienia, bo pokazuje, iż coraz więcej osób ulega presji „chwili”, a oprócz tego nie weryfikuje treści dostępnych w Internecie.
Użytkownik SoliTheFox usunął już swój post (komentarze na szczęście pozostają), ponieważ zawierał całkowicie niesprawdzone informacje. Znalazłem jednak kopię w serwisie web.archive.org, a także zrzuty ekranu oryginalnego wpisu i dodanego do niego zdjęcia udostępnione przez użytkownika angkul07 w ramach portalu X.
windows could never pic.twitter.com/TWcPUJzLa8
— Angkul (@angkul07) November 6, 2025
Jak możemy przeczytać, zainstalowana została paczka z repozytorium PPA, do którego link został znaleziony w „zgłoszeniu” na GitHub’ie. Użytkownik przypuszczał, iż przeprowadzany proces jest bezpieczny. Po dwóch dniach zmienił zdanie, bo zauważył, iż cała zawartość katalogu domowego została zaszyfrowana. Dalej informuje, iż na tym urządzeniu nie posiadał istotnych danych, jednak chciałby odzyskać kilka plików, ponieważ nie zostały wysłane do repozytorium – nie istnieje ich kopia.
Nie jest to bogaty w szczegóły opis, dlatego nikogo chyba nie zaskoczy, iż komentarze z największą liczbą polubień to w większości prośby o udostępnienie adresu repozytorium i linku do zgłoszenia oraz ewentualnie pliku DEB do analizy. Pojawiają się oczywiście słuszne podejrzenia, iż tym razem wektorem ataku jest złośliwe repozytorium, a wzmianka o nim w „popularnym” zgłoszeniu pozwala na szersze rozpowszechnienie szkodliwego oprogramowania.
Autor wpisu w odpowiedzi nakreśla szerszy obraz sytuacji.
I faktycznie oba zgłoszenia dotyczą problemu, który występuje często, co widać po ilości dodanych odpowiedzi. WinBoat, czyli narzędzie do uruchamiania aplikacji z Windows na systemach Linux (wykorzystuje konteneryzację dostarczaną przez Docker), z jakiegoś powodu nie otwiera FreeRDP, który z kolei stanowi „GUI” do uruchamianych aplikacji.
Jako możliwe rozwiązanie zaproponowana została instalacja FreeRDP z nieoficjalnego repozytorium. Nie jest to najlepsza praktyka i co do zasady należy unikać podobnych operacji, jeżeli nie mamy całkowitej pewności, iż dane repozytorium zawiera wyłącznie sprawdzone oprogramowanie. Akurat w tym przypadku okazało się, iż repozytorium ppa:3ddruck/freerdp3full nie stanowiło źródła malware – niestety okazało się to „po fakcie”.
Wystarczyło podanie linków do zgłoszeń, w których autor wpisu na Reddit natrafił rzekomo złośliwe repozytorium, aby inni użytkownicy zaczęli zamieszczać ostrzegawcze komentarze.
Bardziej świadomi użytkownicy zachowali spokój i przeprowadzili odpowiednie analizy, które jednoznacznie wskazują, iż wersja FreeRDP z podanego repozytorium PPA jest zgodna z oficjalnymi wydaniami dostępnymi w repozytorium Git tego projektu (zgadzają się sumy kontrolne). Instalator DEB nie wykonuje żadnych złośliwych działań, a dodatkowe sprawdzenia w serwisie VirusTotal, sandboxach i maszynach wirtualnych nie wskazują, iż zawiera malware.
SoliTheFox dodał wyjaśnienie poprzez edycję wspomnianego wyżej komentarza.
Na GitHub’ie został jeszcze przedstawiony „harmonogram” wydarzeń.
Mało prawdopodobne wydaje się więc, aby ransomware zostało dostarczone podczas instalacji FreeRDP. Niestety, brak jakichkolwiek szczegółów na początku tej historii spowodował ogólną „pewność”, iż repozytorium zawiera malware i lawinę komentarzy na temat „zagrożeń” związanych z wykorzystaniem tego źródła instalacji pakietów. Zabrakło wstępnej weryfikacji, ale bardziej niepokoi zjawisko domyślnego zaufania w treści przedstawiane w Internecie. Można odnieść wrażenie, iż zanika umiejętność analizy faktów. Jako „rozwiązanie” niektórzy podają cenzurę treści generowanych przez AI i ograniczenie rozwoju sztucznej inteligencji, a problem jest przecież na innym poziomie.
Istnieje choćby możliwość, iż to malware uruchomione na Windows spowodowało zaszyfrowanie plików w katalogu użytkownika Ubuntu. Nie znamy konfiguracji WinBoat użytej w tym przypadku, ani przebiegu działań podjętych w zwirtualizowanym środowisku, ale jeżeli katalog domowy był „zamontowany” w kontenerze, to jest to możliwy scenariusz.
W opisanej historii ransomware zaszyfrowało wyłącznie katalog domowy. Wiadomo, iż oznacza to utratę danych (o ile nie została wdrożona odpowiednia polityka kopii zapasowych), jednak działanie systemu operacyjnego nie zostało w ten sposób naruszone – wciąż możliwe byłoby pełne przywrócenie działania. Z tego powodu zdecydowanie powinniśmy do codziennej pracy używać kont bez uprawnień administratora – niezależnie od systemu, niemniej w przypadku Windows ta porada ma większe znaczenie.
Samo wykorzystanie konteneryzacji Docker jest świetnym rozwiązaniem. W zastosowaniach produkcyjnych w znacznym stopniu ogranicza czas potrzebny na wdrożenia aplikacji oraz konfigurację środowisk. istotny jest także pozytywny wpływ na bezpieczeństwo – aplikacja działa w izolowanym kontenerze i (zakładając sensowną konfigurację) nie ma bezpośredniego dostępu do systemu operacyjnego. Z reguły przeprowadza się konteneryzację samych aplikacji, ponieważ ze względów wydajnościowych i możliwości wykonywania kopii zapasowych raczej unika się uruchamiania baz danych w kontenerach. W przypadku środowisk deweloperskich jak najbardziej warto skonteneryzować każdą usługę wymaganą przez budowaną aplikację.
