Niebezpiecznik

Atak nastąpił 16 października 2017 r. o świcie czasu polskiego równolegle na terminale dostępowe GPON w kilku różnych krajach. Wykorzystane zostały m.in. loginy i hasła zaszyte w firmware urządzeń abonenckich [dostarczanych przez Alcatel-Lucent. Ktoś odczytał zaszyte w firmware dane dostępowe do konta administracyjnego i za pomocą tych danych zalogował się na tysiące urządzeń, psując je fizycznie].

OD AUTORA: Niniejszy tekst jest efektem mojego zmęczenia i bezsilności po pół roku korespondencji i spotkań z przedstawicielami firmy Nokia oraz mijania kolejnych terminów na dostarczenie wolnego od wad produktu. Tekst jest równocześnie opisem problemu, z którym zmierzyć może się każdy operator na dowolnym sprzęcie, którego – moim zdaniem – nie mamy szans samodzielne wykryć i w 100 proc. zabezpieczyć. Wreszcie chciałbym, by niniejszy artykuł był głosem w dyskusji o odpowiedzialności producentów sprzętu i oprogramowania za swoje produkty.

Efekt domina

16 października 2017 r. po 6:10 rano urządzenia OLT (ang. optical line termination) w naszej sieci zalogowały pierwsze z serii alarmów utraty komunikacji z ONT (ang. optical network termination). Wszystko działo się bardzo szybko i wyglądało jak efekt domina. „Kładło się” po kilkadziesiąt terminali na minutę. W zasadzie nie było czasu na reakcję, gdyż – jak wykazały późniejsze analizy różnego typu logów – ataki na wybrane sieci zostały przygotowane wcześniej, a do ich przeprowadzenia wykorzystano m.in. login i hasło zapisane w jednym z modułów oprogramowania ONT opracowanego przez podmiot trzeci, inny niż dostawca terminalna, którym w naszym przypadku jest Alcatel-Lucent, który w 2016 r. został przejęty przez Nokię.

Przygotowania napastników były zresztą szersze i dzięki nim, w chwili ataku, nie było potrzeby włamywania na urządzenia, czy bieżącego skanowania IP podatnych urządzeń. Ten proces został wykonany wcześniej. W krytycznym momencie wystarczyło uruchomić skrypty.

Skala zniszczeń

Nieautoryzowany dostęp do terminali ONT (i w efekcie np. zresetowanie ustawień sieciowych) byłoby zdarzeniem uciążliwym, ale możliwym do opanowania w oparciu o zasoby własne operatora. Napastnik doprowadził jednak do zniszczenia zawartości układów flash, uniemożliwiając uruchomienie urządzeń w jakimkolwiek trybie, który pozwoliłby choćby wgrać nowe oprogramowanie. Awaria dotknęła kilkunastu procent usług realizowanych w oparciu o podatny na wykonany atak model ONT. Rozdzwoniły się telefony – abonenci żądali niezwłocznego rozwiązania problemu. Konieczne stało się fizyczne wymienienie setek uszkodzonych końcówek klienckich na nowe, tymczasem nasze własne zapasy magazynowe nie zapewniały tak masowej wymiany.

W tej krytycznej sytuacji nie było możliwości pozyskania od producenta dodatkowych urządzeń na wymianę. Bez względu na to, czy uznalibyśmy ją za pilną interwencję serwisową z winy producenta, czy priorytetowe zlecenie zakupu. Sprzętu serii 240, ani żadnych zamienników w magazynach Nokii nie było. Dopiero po kilku tygodniach udało nam się zakupić jedynie 130 nowych urządzeń. Oczywiście pomogły, ale dotarły późno i w zbyt małej ilości.

Akcję przywracania usług oparliśmy więc o patchwork różnych rozwiązań. W pierwszym rzędzie w oparciu o własne zapasy wymieniliśmy urządzenia dla usług triple-play. W innych przypadkach dokupiliśmy i wdrożyliśmy (na szczęście przetestowane wcześniej) konkurencyjne dostępne od ręki terminale 1-portowe, dodając do nich gdzie była potrzeba dodatkowe RG (ang. residential gateway). Część abonentów zdecydowała się na zakup routerów we własnym zakresie.

Niestety, z uwagi na skalę, wymiana urządzeń zajęła kilka tygodni. Problemem był nie tylko brak sprzętu Nokii, ale i ilość urządzeń jaką dziennie mogła wymienić każda z ekip serwisowych. Za wydatkami na sprzęt poszły oczywiście rabaty dla klientów za braku usług i, niestety, pewna ilość rezygnacji osób, które nie chciały lub nie mogły czekać na wymianę.

Mechanizm ataku

Jak już wspomniałem, wykorzystano loginy i hasła zaszyte w oprogramowaniu terminali. Czasem wprowadza je sam producent, tłumacząc, że jest to „hasło serwisowe” na wypadek, gdy klient zapomni danych dostępowych. Zawsze uważałem, że w takich wypadkach powinna istnieć raczej procedura password recovery, niż backdoor. Problemem w gruncie rzeczy jest to, że nie da się zabezpieczyć tego typu loginów i haseł przed osobami niepowołanymi.

Taka furtka do logowania jest najczęściej kompletnie niewidoczna dla administratora urządzeń. Nie wiedząc o niej, trudno stwierdzić, że takie ukryte konto istnieje. Równocześnie nie można go usunąć, czy zmienić mu hasła. Totalna blokada zdalnego zarządzania terminalami na nadrzędnych firewallach oznacza zaś odcięcie lub ograniczenie administrowania sprzętem. W omawianym przypadku ONT – jeśli są routerami – mają publiczne IP, z którym wiąże się zwyczajowo polityka jak najmniejszych restrykcji w zakresie blokowania portów. Równocześnie nie istnieje żaden racjonalny argument, by tego typu backdoor z powodów serwisowych umieszczać w terminalach domowych. „Mydelniczki” mają przecież przycisk reset. A domyślny login i hasło nadrukowane są na pudełku lub naklejce.

Rozkręcone terminale Alcatel-Lucent ONT I-240W-A czekające na wymianę uszkodzonych modułów pamięci flash.
(źr.TPnets.com)

W opisywanej sytuacji wydaje się, że jest inaczej. Wedle naszych ustaleń ten konkretny backdoor nie został wprowadzony przez producentów, tylko dostawcę oprogramowania. Okazuje się, że oprogramowanie terminali, to często nie autorska produkcja vendora, a zlepek modułów kupowanych z różnych źródeł. Kluczowe pytanie brzmi: czy producent urządzeń kontroluje zakupy i odpowiada za to, co sprzedaje? Nie mam wątpliwości, że powinien odpowiadać producent, a własne roszczenia za szkody klientów może i powinien kierować do swoich dostawców. Nie powinien uchylać się od odpowiedzialności za sprzedany i niebezpieczny bubel. Gdy popatrzymy np. na branżę motoryzacyjną, to zauważymy co jakiś czas wezwania serwisowe do wymiany wadliwych poduszek powietrznych, czy hamulców. Elementów produkowanych często przez podmioty zewnętrzne.

Trudno byłoby też przyjąć, że gdy np. montujemy drzwi antywłamaniowe, a ich producent udostępnia każdemu zainteresowanemu klucze do nich, to koszty „włamania” ponosić powinien nabywca drzwi. Nie można też uzależniać odpowiedzialności producenta od tego, czy nabywca zainwestował w zasieki i zatrudnił ochroniarza. Ani argumentować, że zamek w drzwiach, to tylko ozdoba. Niestety, z taką argumentacją się spotykamy, słysząc, że dostęp do naszych ONT możemy przecież blokować na innych urządzeniach w sieci.

Co na to producent?

W przypadku wielu urządzeń sieciowych nie ma możliwości wyboru oprogramowania innego niż producenta, ani sprawdzenia, czy nowsze wersje nie mają stwierdzonej przez nas podatności. To platformy zamknięte. Stąd w przypadku sprzętu GPON pod marką Alcatela-Lucenta konieczne jest udostępnienie poprawionego oprogramowania przez Nokię.

Jak wspomniałem, z uwagi na skalę, o incydencie poinformowaliśmy producenta jeszcze tego samego dnia po południu. Zakładaliśmy, że problem może dotyczyć również innych sieci (później uzyskaliśmy potwierdzenia). W ciągu dwóch dni do producenta trafiły dwa uszkodzone terminale ONT z naszej sieci. Potwierdzono naszą diagnozę o uszkodzeniu pamięci flash. W pierwszych dniach wydawało się, że wypracujemy rozwiązania programowe (patch) i ustalimy zasady wymiany wadliwego sprzętu. Niestety, proces szybko wyhamował.

Producent przyjął, że skoro nie mamy aktywnego kontraktu serwisowego, to nie pomoże bez względu na charakter zdarzenia i brak możliwości wykupienia przez nas takiego kontraktu w przeszłości. Nie czuł się w obowiązku zabezpieczyć choćby możliwości zakupu w niezbędnej ilości nowych terminali. Równocześnie zasugerowano, że skoro mamy problem na starej wersji oprogramowania, to… możemy kupić nową w cenie opisanej liczbą 6-cyfrową. Co ważne, na pytanie, czy nowa wersja jest wolna od udokumentowanej wady usłyszeliśmy, że nie ma takiej gwarancji. Odmówiono nam możliwości przeprowadzenia testów najnowszej wersji oprogramowania pod kątem bezpieczeństwa.

Pikanterii całej sytuacji dodaje fakt, iż w efekcie naszych poszukiwań ustaliliśmy, iż na Youtube już w czerwcu 2016 r. opublikowane zostały filmiki pokazujące jak można się włamać na terminale serii 240. Podzieliliśmy się tą wiedzą z producentem, ale do dziś nie otrzymaliśmy żadnej formalnej wypowiedzi w tym zakresie. Jedyną reakcją była kolejna propozycja sprzedaży rozwiązań z większymi rabatami w koszcie oprogramowania przy równoczesnym wymogu zakupu wsparcia na poziomie Gold.

Stacja lutownicza wykorzystywana w procesie usuwania i montażu powierzchniowego uszkodzonych modułów pamięci.
(źr.TPnets.com)

Przekazaliśmy sporo danych (logi z urządzeń i linki do materiałów). Jeżeli ktokolwiek je przeanalizował, to wyników tych prac nie otrzymali żadni znani nam użytkownicy problematycznych urządzeń tych urządzeń. My też nie.

Własne działania naprawcze i koszty

Nie mogąc wymienić uszkodzonych terminali, ani nawet kupić w to miejsce nowych, poprosiliśmy producenta o wsparcie w zakresie ewentualnej naprawy. Niestety, ponownie nie uzyskaliśmy z Nokii nic. Nawet dokumentacji technicznej urządzeń.

W tym miejscu głęboki ukłon wobec Marcina Kuczery (Leon sp. z o.o.), który w swojej firmie przeprowadził diagnostykę uszkodzeń, po czym ustalił źródło problemu i sposób naprawy.

W efekcie jego prac opracowaliśmy procedurę usuwania, programowania i montażu powierzchniowego nowych układów flash. Wymontowywane pamięci często były nie tylko nadpisane losowymi danymi, ale zawierały fizycznie uszkodzone komórki uniemożliwiające ich ponowne zaprogramowanie i montaż. Konieczne było zorganizowanie nowych kości pamięci, programatorów i stacji lutowniczej. W warunkach braku linii produkcyjnej ręczna naprawa to żmudny, a więc i kosztowny proces, który pochłonął dotąd setki roboczogodzin. Nie mieliśmy wyjścia. Część urządzeń nadal czeka na naprawę.

Okazało się ponadto, że również zainstalowany nam system AMS jest dziurawy. Zmuszeni byliśmy wyłączyć serwer z tym systemem (możemy kupić nowe oprogramowanie, które może będzie działać lepiej…).

Całkowite koszty poniesionych przez nas strat obejmują uszkodzony i zakupiony sprzęt, rabaty i rezygnacje abonentów, setki roboczogodzin, kosztów dojazdów itp. Dodatkowo to co przeżyło nasze Biuro Obsługi Klientów ze strony niektórych klientów, było wybitnie toksyczne.

Kluczowe jest pytanie, jak wygląda proces nadzoru nad oprogramowaniem firmowanym przez dużych dostawców sprzętu?
Części funkcjonalności systemów nie odzyskaliśmy do dziś. Na razie działają blokady na urządzeniachnadrzędnych. Ale nie wiemy, czy nie ma innych dziur w oprogramowaniu. Nokia do dziś nie przesłała nam żadnego komunikatu lub biuletynu technicznego w tej sprawie. Nie udostępniła też aktualizacji.

Komu służy taki atak?

Patrząc na międzynarodową skalę i rodzaj zdarzenia, pojawiła się teza, że cytuję: „to wygląda na testy podatności sieci telekomunikacyjnych państw ościennych”. Świadczyć może o tym zarówno fakt równoległego ataku w kilku krajach na różne platformy i wykorzystanie w nim podatności zaszytej w jednym z modułów oprogramowania bez wiedzy vendorów. Z perspektywy naszych rozważań i bezpieczeństwa sieci kluczowe jest jednak bardziej pytanie o to, jak wygląda proces nadzoru nad oprogramowaniem firmowanym przez dużych dostawców sprzętu? W tym przypadku okazał się nieskuteczny.

W ciągu kilku kolejnych tygodni odtworzyliśmy we współpracy z innymi zaatakowanymi sieciami oraz zaprzyjaźnionymi ekspertami przebieg zdarzeń. Wszystkie materiały i analizy były na bieżąco przekazywane do producentów urządzeń (przynajmniej dwóch), na które – wedle naszej wiedzy – przeprowadzono wtedy skuteczne ataki. Pierwszy z producentów podjął dość sprawnie działania obejmujące kolejno: przesłanie swoim klientom e-maili opisujących problem, sugestie działań ad-hoc, a wreszcie udostępnienie stosownych uaktualnień oprogramowania. My nie mieliśmy takiego szczęścia.

Zakończenie

Tekst powstał dopiero w pół roku po opisywanych zdarzeniach. Najpierw ratowaliśmy sytuację, później reanimowaliśmy sprzęt i prowadzili długie, bezowocne rozmowy z producentem. Nie kryję, że przez cały ten czas czekaliśmy na jego skuteczną i adekwatną pomoc.

Dziękuję w tym miejscu wszystkim osobom, które podzieliły się z nami wiedzą, logami i informacjami na temat opisanych wyżej wydarzeń. Szczególne podziękowania kieruję do ekspertów i instytucji, którzy poświęcili swój często prywatny czas na analizę gromadzonych przez nas materiałów.

Dziękuję również kilku pracownikom starego zespołu Alcatel-Lucent Polska, którzy – mimo braku zaangażowania korporacji – pomogli nam w takim zakresie, w jakim mogli.

Autor artykułu, Piotr Marciniak, fot. telko.in

Piotr Marciniak — udziałowiec i prezes zarządu firm z sektora ISP. Współtwórca i do 2017 r. prezes Krajowej Izby Komunikacji Ethernetowej. Członek kilku resortowych zespołów roboczych. Z wykształcenia prawnik. Z zamiłowania administrator systemów informatycznych i integrator. Specjalizuje się w projektowaniu i zarządzaniu sieciami teleinformatycznymi oraz usługami IT.
 

Komentarz redakcji Niebezpiecznik.pl

Opisywany przez Piotra Marciniaka incydent jest nam znany od października w kontekście innego producenta urządzeń ONT, ZTE. Urządzenia ZTE problem dotknął już 14 października. Na temat tego incydentu świetną prezentację podczas konferencji PLNOG wygłosił Tomasz Brol, CTO w firmie Syrion.

Kluczowa informacja? To nie wojna hybrydowa, a atak botnetem “Brickerbot” — jego autor opublikował swoje przemyślenia tutaj (warto przeczytać). Z kolei dzięki uprzejmości Tomasza, możemy Wam udostępnić całość prezentacji dot. tego incydentu.

I tu moglibyśmy zakończyć ten komentarz pod przedrukowanym artykułem i pozwolić Wam już popastwić się nad głupotą pozostawiania haseł serwisowych w firmware. Ale jest jeszcze jedna rzecz, związana z tym incydentem, którą należy dla pełnego obrazu przedstawić. Chodzi o stanowisko producenta, Alcatel-Lucenta. Oficjalnego nie ma, jednak pod postem dotyczącym tego artykułu na fanpage serwisu Telko.in wypowiada się Pani Wioleta Jędrzejewska, która pracuje w Alcatel-Lucent i dzieli się informacjami dotyczące tego incydentu z innej perspektywy niż Piotr Marciniak.

Pani Wioleta potwierdza to, do czego sam Piotra Marciniak się przyznał w artykule. Jego firma nie wykupiła wsparcia technicznego:

Niestety pan Marciniak zapomniał powiedzieć że kupił sprzęt ale nie wykupił wsparcia producenta. Pozbawił sie dobrowolnie upgradow i wsparcia na wypadek takich właśnie trudnych sytuacji. Próbowaliśmy pomóc: spotkania , negocjacje, oferty ale to na nic bo po drugiej stronie był szantaż i próba wymuszenia zrobienia wszystkiego za zero! Sory ale tak sie nie robi biznesu. Zawsze możemy sie dogadać i udzielić wsparcia ale nie w taki sposób

Ale czy takie wsparcie powinno być potrzebne do usunięcia “wady” wygenerowanej przez samego producenta, bez winy użytkownika czy operatora? Celnie podsumowuje to Andrzej Karpiński z Orange:

klient kupił auto, które po 30000km jazdy wybucha. nie ważne czy go serwisuje w ASO, czy na własną rękę – niedoróbka producenta ma być naprawiona przez i na koszt producenta. wszedzie to tak działa, tylko nie w it.. to nie jest coś, co się wydarzyło nagle, z winy uzytkownika, z racji zużycia sprzętu itd. wpienia mnie, że dostawcy wymuszają wykupienie suportu na obsługę spraw, do których są zobligowani nie tylko ustatowo, ale w sumie moralnie. nie kupiłbym nic od dostawcy, który w ten sposób postępuje, i szantażuje klienta z powodu chęci upsellu

Na tę kwestię producent ma jednak inne spojrzenie. Oto riposta Pani Wiolety:

Pan uważa, że jak ktoś 30 lat temu kupił auto w ASO to należy mu się za darmo dożywotni serwis i wymiana oleju bo kupił w ASO? Proszę mi wybaczyć ale prowadzimy biznes a nie fundację charytatywną i jeżeli klient oczekuje od nas świadczenia usług to winien za nie zapłacić, jeżeli zaś uważa, że poradzi sobie sam, to ma taki wybór ale potem nie może płakać, że jednak się nie udało

Nie nam oceniać, czy tak powinien na publicznym forum wypowiadać się pracownik producenta. Więc na koniec oddajmy głos pracownikowi innego operatora, którzy sprawę podsumował tak:

Szanowna Pani, serdecznie dziękuję za Pani wypowiedzi pod tym artykułem. Do tej pory znałem tylko jedną stronę “medalu”, któremu bacznie się przyglądałem – tj. to co napisał Piotr Marciniak w swoim felietonie. Teraz poznałem także drugą stronę w Pani osobie – stanowisko jak rozumiem Alcatela/Nokii. Dzięki Pani wypowiedziom wypracowałem już sobie opinię na ten temat i wiem, że nie ma mowy, żebym kiedykolwiek kupił produkty Waszej firmy, która ma tak niepoważne podejście do klienta, tak fatalny sprzęt, że aż zagraża stabilności firm, które go kupiły oraz tak żałosnych pracowników lub alternatywnie bardzo profesjonalnych pracowników, którzy są wbrew swojej woli zmuszani przekazywać żałosne stanowisko swojej korporacji.
Z pozdrowieniami od firmy Diament, wpis do Rejestru Przedsiębiorców Telekomunikacyjnych UKE nr 690.

Tak czy inaczej, z dialogu z Alcatelem należy się cieszyć. Doskonale wiemy, jak ciężko jest od tej firmy uzyskać jakiekolwiek informacje będąc prasą — próbowaliśmy w trakcie zgłaszania Alcatelowi dziur w jego urządzeniach Alcatel Link OneTouch por. Z tego routera do mobilnego internetu można komuś zdalnie zdjąć blokadę Premium SMS i nabić rachunek.

Nauczka i dylemat

Po pierwsze, opisany przez Piotra Marciniaka i Tomasza Brola incydent to świetny przykład na to, że każde urządzenie trzeba poddać hardeningowi. Obciąć co się da i nie wpinać interfejsami w sieci/VLAN-y, do których urządzenie nie powinno mieć dostępu (u jednego z operatorów tylko jeden ONT był wystawiony do publicznego internetu. Reszta nie. Ale ten jeden był z tą resztą połączony siecią zarządczą…).

Po drugie: Czy producent powinien odpowiadać za błędy (dziury) w oprogramowaniu? A jeśli tak, to jak długo? I czy tylko wobec klientów, którzy wykupili “support”?

PS. To co spotkało ONT-y zaraz może spotkać Mikrotiki. Właśnie grasuje botnet, który atakuje niezhardeningowane routery tego producenta. Załatajcie je, zanim będzie za późno — opis ataku i zalecane kroki znajdziecie tutaj.

Aktualizacja 26.04.2018, 14:31
Skontaktowała się z nami Pani Wioleta Jędrzejewska, która poinformowała nas, że:

“moje komentarze pod postem na Fb Telko.in są, a raczej były wyłącznie moją prywatną opinią i punktem widzenia. W żadnym momencie nie są to informacje, które można opisać jako ‘nieoficjalne stanowisko firmy”

Zgodnie z powyższym, uszczegółowiliśmy zdanie, w które mogło sugerować, że wypowiedź Pani Wiolety jest nieoficjalnym stanowiskiem firmy Alcatel-Lucent. Nie jest, jest prywatną opinią Pani Wiolety. Jednocześnie zwróciliśmy się o wypowiedź w tej sprawie do firmy Alcatel-Lucent. Kiedy otrzymamy odpowiedź, zaktualizujemy ten artykuł.

Aktualizacja 27.04.2018, 12:14
Oto oświadczenie rzecznika prasowego Nokii:

In October 2017, TPNet in Poland contacted their account team, a
channel partner of Nokia, as they experienced difficulties with their
fiber Optical Network Terminals (ONTs). Investigations at the time
indicated an external Brickerbot attack had affected some types of
residential gateways, causing them to lose internet connection,
without the ability to restart remotely. To our knowledge no customer
data was affected, and the attack was focused on damaging the ONTs;
anecdotal evidence shows that other ONT providers were affected as
well.

Nokia takes security very seriously. Once notified by the channel
partner, we took immediate action and worked closely with the local
partner responsible for this customer to analyze and address the
issues and restore service with the shortest delay possible.

We are aware of the comments made by TPnet and are working with our
new channel partner in Poland to respond. We will not make any further
comments at this point.