Biblioteka pobierana dwa miliony razy w tygodniu dostała tylną furtkę umożliwiającą kradzieże bitcoinów. A cały proces infekcji polegał na tym, że ktoś kogoś poprosił o przejęcie nad nią kontroli. Witajcie w świecie darmowego oprogramowania.
Wczoraj wieczorem wybuchła bomba – okazało się, że bardzo popularna biblioteka Node.js EventStream korzystała z kodu, który korzystał z kodu, który był złośliwy – i do tego zaszyfrowany. Ta sytuacja trwała od tygodni i nikt się nie zorientował.
Jakim cudem
Jak zainfekować bibliotekę pobieraną dwa miliony razy tygodniowo? Wystarczy poprosić. Tak niestety wygląda smutna rzeczywistość programistów, którzy kiedyś coś stworzyli, nie chcieli na tym zarabiać, a teraz zostali z bagażem obowiązku wspierania swojego dzieła, z którego korzystają miliony. Ale o tym za moment – najpierw spójrzmy, co się stało.
Krótkie wyjaśnienie – Node.js to bardzo, ale to bardzo popularne środowisko uruchomieniowe pomagające szybko i skutecznie budować aplikacje WWW. Używa managera pakietów npm, który z kolei korzysta z ogromnego repozytorium kodu. Prawie każdy pomysł, jaki możecie mieć, ktoś już miał i oprogramował. Zamiast zatem pisać dużo swojego kodu, można użyć już gotowego. Wygodne. Ale niestety nie zawsze bezpieczne. Sześć dni temu jeden z użytkowników popularnego pakietu EventStream zgłosił problem. Dodany do EventStream moduł flatmap-stream zawierał złośliwy kod o nieznanym wówczas jeszcze przeznaczeniu. Skąd się wziął złośliwy moduł?
Twórca pakietu EventStream otrzymał ofertę pomocy w utrzymywaniu pakietu i z niej skorzystał. Nie znał osoby, której przekazał prawa modyfikacji – ale nie widział w tym problemu. Nowy deweloper wprowadzał drobne zmiany. Najpier 8 września dodał do kodu inny moduł, flatmap-stream. Moduł ten nie robił nic złego, był niewinny jak świeżo narodzone niemowlę. Dopiero 5 października do flatmap-stream dodano złośliwy kod, który automatycznie stał się też częścią popularnego EventStream. Sprytne.
Co robił złośliwy kod
Pierwsze analizy kodu wskazywały jedynie, że robi coś niedobrego – lecz nikt nie wiedział co, ponieważ kluczowy fragment kodu był zaszyfrowany algorytmem AES, a kluczem była… nazwa innego, nieznanego pakietu. Odszyfrować docelowy kod można było, dopiero gdy w aplikacji znajdował się moduł będący celem ataku. Bardzo mądra technika, utrudniająca analizę i zapewniająca, że nie będzie przypadkowych ofiar. Udało się jednak ustalić, że celem ataku była aplikacja Copay – „bezpieczny” portfel BTC.
Jeśli używaliście portfeli Copay w wersji od 5.0.2 do 5.1.0 i macie jeszcze swoje bitcoiny, to przenieście je szybko do innego portfela. Możecie skorzystać z wersji podobno już bezpiecznej, czyli 5.2.0 lub innego rozwiązania. Celem złośliwego kodu była kradzież kluczy prywatnych portfeli BTC. Na razie nie wiemy, czy cel został osiągnięty – ale warunki ku temu bez wątpienia istniały.
Z technicznego punktu widzenia złośliwy kod sprawdza, czy został uruchomiony we właściwej aplikacji, a następnie przeszukuje wszystkie portfele BTC i BCH. Szuka tych, w których saldo BTC > 100 lub saldo BCH > 1000 i wysyła ich klucze prywatne oraz hasła do serwera w Kuala Lumpur. Tu znajdziecie sam kod, a historię dobrze podsumowuje thegrugq:
Co począć z tym problemem
Początkowo część społeczności obwiniała głównego dewelopera EventStream za to, że oddał kontrolę nad pakietem przypadkowej osobie. On sam jednak odpowiadał bardzo sensownie – pakiet stworzył, ponieważ dawało mu to radość, lecz potem radość się skończyła, a została ciężka praca nad utrzymywaniem modułu. Bezpłatna praca – warto zauważyć. Nic więc dziwnego, że gdy pojawiła się oferta pomocy, chętnie z niej skorzystał. Trudno stawiać mu jakiekolwiek zarzuty – społeczność open source nie wypracowała skutecznego i bezpiecznego modelu przejmowania odpowiedzialności za porzucone elementy kodu, z których korzystają miliony użytkowników na całym świecie. Dobrym zwyczajem jest udział w rozwijaniu kodu, którego się używa, ale o ileż prościej jest po prostu zaimportować bibliotekę wobec konieczności rozwiązania zgłoszonych do niej ticketów. Problem jest i nigdzie się nie wybiera – opisany powyżej incydent jest tylko jednym z przykładów skutków tej sytuacji. Bez wątpienia będzie tego więcej.
Piszę w Node.js, co mam zrobić?
Po pierwsze sprawdź, czy Twoja aplikacja zawiera złośliwy moduł:
$ npm ls event-stream flatmap-stream ... [email protected] ...
Jeśli widzisz taką odpowiedź, to musisz zaktualizować do [email protected]. To powinno usunąć problem – na dzisiaj. Po drugie… nie ma dobrej rekomendacji. Bo kto sprawdzi wszystkie moduły?
Komentarze
open source zdało egzamin – błąd szybko wykryto i usunięto.
a ile takich niespodzianek jest w closed source, możemy się tylko domyślać.
A kolega przeczytał materiał? Tam nie ma mowy o jakimś błędzie. Po błędzie to najwyżej windows swieci na niebiesko, a w linuksie kernel panikuje. Tam jest mowa o dodanym module „flatmap-stream”, który miał wykradać klucze prywatne do portfeli BTC i zapewne napisany był bez błędów. Tu nie chodzi o szybką reakcję. Tu chodzi o fakt dodania (przez przypadkową osobę) do oprogramowania z którego korzystają miliony użytkowników, złośliwej funkcjonalności. I w tym przypadku żaden czas reakcji społeczności open source nie zdałby egzaminu. Bo chodzi o to, że złośliwy kod nie miał prawa w ogóle się tam znaleźć.
Chyba wręcz przeciwnie, bo kod odpalający koparkę BTC właśnie się pojawił przez open source, w zamkniętym sofcie nie miałby prawa się taki błąd pojawić :D
https://niebezpiecznik.pl/post/backdoor-producenta-w-urzadzeniach-alcatel-lucent-spowodowal-olbrzymie-straty-u-wielu-operatorow-ktos-wykorzystal-go-do-zbrickowania-dziesiatek-tysiecy-urzadzen/
Sorki za źródło konkurencji, ale argumenty typu „Skoro każdy kwadrat jest prostokątem, żaden prostokąt nie jest kwadratem” są po prostu dziecinne. To jest logika na poziomie poniżej podstawówki. Albo zamierzona retoryka, mam tylko nadzieję że o taką właśnie Ci chodziło.
Tak się kończy gdy do stworzenia aplikacji Hello World potrzebne jest użycie 100, 200, 500 MB kodu bibliotek, framework-ów, i innych polepszaczy, przyśpieszaczy i upiększaczy.
O to to właśnie. Hello world jest tak skomplikowane, że nie pozostaje nic innego, jak odpalić dedykowany dla niego userspace, w postaci dockera czy czego tam jeszcze. Najczęściej ściągnięty z przypadkowego źródla. Co jest w środku, tylko bozia wie.
docker run -ti –rm –entrypoint bash node
i wszystko – „node” jest oficjalnym obrazem od core teamu Dockera.
Jeśli chcecie korzystać z innych to sprawdźcie, czy został opublikowany Dockerfile – jeśli został, to go najpierw przestudiujcie, jeśli nie – nie ma co ryzykować. Zawsze też można stworzyć własny obraz oparty o te core’owe.
Docker jest wygodny, nawet do „hello world”, bo jak chcecie to napisać w nowym środowisku, to możecie chcieć przetestować różne wersje chociażby.
„Witajcie w świecie darmowego oprogramowania.” – witajcie w swiecie idiotow.
https://i.imgur.com/7T7Cwz4.png
Odpowiem: Zatrudniony człowiek do szukania złych paczek – github już takie coś ma.
Problemem jest zaufanie w open source, gdzie się zakłada że kod jest otwarty i przecież możesz dodać co chcesz „to twój projekt”.
Uważam że popularne paczki powinny mieć większy poziom bezpieczeństwa – np weryfikacja zmian. Ale nikt tego za darmo nie zrobi
Kłopot też w tym, że niektóre dobre aplikacje są pisane i utrzymywane przez jedną osobę, która ma swoje życie i nie będzie się uwiązywać na zawsze tą sprawą. Trochę więcej spokoju jest wtedy, gdy prace wykonuje jakiś zespół.
Może nie totalnie że darmo ale…
https://snyk.io
Problemem jest pisanie w języku ktòry nie posiada biblioteki standardowej. Zagadka ile zależności ma pythonowe Django? Odpowiedź to żadnej bo wszystko jest w bibliotece standardowej.
„On sam jednak odpowiadał bardzo sensownie – pakiet stworzył, ponieważ dawało mu to radość, lecz potem radość się skończyła, a została ciężka praca nad utrzymywaniem modułu. Bezpłatna praca – warto zauważyć. Nic więc dziwnego, że gdy pojawiła się oferta pomocy, chętnie z niej skorzystał.” Zamieńcie „pakiet” na „dziecko”. W sumie nie dziwię się że społeczność go obwiniała, tak jakby społeczeństwo obwiniało rodzica który oddał dziecko obcej osobie.
Właśnie przez takie idiotyczne porównania i żądania odechciewa się cokolwiek udostępniać „społeczności”. Nikt palcem nie kiwnie żeby pomóc, ale gębę do krytyki taaaaaką szeroką mają.
„Społeczność” musi opracować co robić w różnych wypadkach. Szczególnie jeśli to dotyczy popularnych pakietów. Jakby autorzy mogli oddać opiekę nad kodem „społeczności” i dalej „społeczność” by się nim „opiekowała” to pewnie nie byłoby takiej sytuacji jak opisana powyżej.
@fyx: Nie przesadzasz? :D Od razu go zlinczować!
Grugq jak zwykle głosi oczywistości po fakcie.
Którzy jest ten gość, który to przewidział prawie rok wcześniej
https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5?gi=9612ff721be
Niestety jest też i druga strona medalu. Jestem sobie takim DevOpsem i staram się korzystać z kodu, który jest,jestem wielkim przeciwnikiem wymyślania koła na nowo. Jak znajdę jakiś błąd i coś mi nie działa to jeżeli umiem to naprawiam. Naprawiłem już trochę rzeczy. Problem jest taki, że moja pull requesty czasami wiszą po kilka miesięcy bez żadnego odzewu, kontakt z właścicieliem repo też nie rozwiązuje problemu.
Pracuję nad systemem który zatrzymałby takie ataki:https://github.com/dpc/crev . Na razie zaimplementowany dla Rust, jest też kilku developerów Julia, którzy chcą go zaimplementować.
Z3s bardzo ok portal…ale nie lubicie wolnego oprogramowania …ciagle chwalicie googlowe rozwiaznia..taki portal security..dla nie wtajemniczonych…czasem mam wrazenie ze sluzby go nasze polskie prowadza.
Tak jest!