Skip to content

Personal Blog

Menu
  • Home
  • News
  • Categories
  • About
  • Contact
Menu

Zhakowano eSIMy! Ale (na razie) się nie martw.

Cześć. Rozwój technologii co do zasady czyni ją nie tylko przyjaźniejszą, ale też bezpieczniejszą. Nie inaczej jest w przypadku kart SIM, gdzie odchodzimy od może i coraz mniejszych, ale jednak
fizycznych plastikowych kart na rzecz tych wirtualnych SIMów. Nie tylko ciężej jest zgubić, nie zużywają się z czasem, łatwiej mieć ich kilka na jednym urządzeniu i nie jest potrzebna tacka,
przez którą do środka telefonu może wlać się woda. Łatają one też kilka poważnych luk w bezpieczeństwie swoich przodków. No bo przy okazji odejścia od plastiku zaktualizowano mechanizmy szyfrujące do
bardziej współczesnych, a aktualizacja oprogramowania karty jest teraz możliwa w czasie w miarę rzeczywistym. Po prostu wysyła się update na telefon, podczas gdy fizyczne karty SIM zostają raczej w
stanie, w którym zostały wyprodukowane wraz z zawartymi w nich ewentualnymi błędami. SIM zabezpiecza też przed jednym ze sposobów kradzieży wprowadzając dodatkowy czynnik
uwierzytelniający, bo jeżeli ktoś teraz pozna pin do naszej karty, to nie wystarczy ją po prostu przełożyć do innego telefonu. konieczne jest przeprowadzanie procedury transferu,
przeważnie dodatkowo zabezpieczonej uwierzytelnianiem na samym telefonie, choćby za pomocą biometrii. Super, ale to nie oznacza oczywiście, że SIMki są idealne, bo niedawno odnaleziono w ich
implementacji poważną lukę. Zapraszam. [Muzyka] Security Explorations, czyli badawcze ramię AG Security Research Adama Gowdiaka, nasi Polacy rodacy znaleźli w
esimkach pewne podatności, bazując zresztą na wielu latach wcześniejszej pracy w tym obszarze. Udało im się wyciągnąć głęboko zaszyte klucze kryptograficzne, do których absolutnie
nie powinni być w stanie uzyskać dostępu. No i postanowili podzielić się ze światem swoimi odkryciami. Choć tu należy się z góry pewne doprecyzowanie, aby nie popadać w clickbait, który już
widziałem gdzieniegdzie w mediach. Opisane luki dotyczą konkretnej implementacji standardu kartim autorstwa firmy Kigen. Skupia się ona na dostarczaniu rozwiązań głównie dla
urządzeń internetu rzeczy, czyli tych wszystkich kamerek, smart domowych gadżetów czy nawet różnych czujników stosowanych w ogromnych fabrykach. Ogólnie grube kotlety działają też na
rynku smartfonów, ale to jakiś niewielki ułamek ich biznesu. Dlatego spokojnie, nasze telefony są raczej nadal w miarę bezpieczne, czego przynajmniej przez jakiś czas nie można było powiedzieć o 2
miliardach urządzenia JT, w których siedzą rozwiązania Kigena. Tylko czym ten Kigen w ogóle jest i za co w tej historii odpowiada? A no w standardzie zdefiniowane jest coś, co nazywa się
Embed Universal Integrated Circuit Card. Jest to po prostu chip wraz z działającym na nim oprogramowaniem, zarządzającym wszystkim, co z SIMami związane. Na przykład przechowuje je,
przełącza pomiędzy nimi, czy nawet pozwala na zdalne nimi zarządzanie. Kigen jest jednym z producentów takiego rozwiązania kompatybilnego oczywiście z oficjalnymi standardami. Niestety w
swojej implementacji popełnili pewien błąd, który zresztą z programistycznego punktu widzenia jest dość trywialny. Otóż gdzieniegdzie pominięto sprawdzenie typów przetwarzanych danych w trakcie
ich rzutowania, a rzutowanie typów pomiędzy obiektami a macierzami jest w stanie ujawnić choćby informacje o rozmiarze tych drugich, co może pozwolić na odkrycie pewnych sekretów. Wiem
głęboko, ale dla zrozumienia całości nie jest to w sumie istotne, także zostańcie ze mną jeszcze chwilę, bo skoro wiemy już jak, to teraz warto odpowiedzieć na pytanie gdzie? No w Javie wiadomo. A tak
dokładniej to w implementacji apletów uruchamianych na kartach SIM, napisanych w tym języku. Są one częścią standardu, który ciągnie się za nami od dekad i z racji kompatybilności wstecznej staje
się on coraz słabszym ogniwem. Zresztą te naleciałości przeszkadzają również w innych miejscach, bo Java sama w sobie wcale nie jest aż tak zła, mimo że lubię sobie z niej żartować. posiada mechanizm
weryfikacji byttecodu. Służy on do tego, aby sprawdzić, czy ktoś nie majstrował przy uruchamianych aplikacjach. Problem w tym, że się z niego w opisywanych realiach nie korzysta. Dlaczego?
Plastikowe karty SIM wyposażone były w mikroprocesory o bardzo słabej wydajności, tysiące razy niższej niż te napędzające nasze telefony czy komputery. Migracja na ESIM oczywiście
to zmieniła, ale nie zmieniła podejścia i nadal taka weryfikacja nie jest standardową praktyką. Wykorzystanie wspomnianych błędów i niedopatrzeń pozwoliło badaczom uruchomić i
zainstalować w obrębie ESIMA dowolną aplikację bez przejścia procesu uwierzytelniania. również taką bez odpowiednich certyfikatów, a więc potencjalnie złośliwą. Jakie są tego
konsekwencje? A no potencjalnie poważne, bo w tym konkretnym środowisku nie ma pełnego rozdziału pomiędzy aplikacjami Javy, które na kartach SIM działają. działać muszą w związku z
kompatybilnością wsteczną, a danymi użytkownika, które też na karcie są przechowywane. Rozdział taki jest przecież jednym z podstawowych filarów bezpieczeństwa każdego systemu.
Uruchomienie nieautoryzowanego oprogramowania na karcie SIM pozwala na wydobycie certyfikatów zaszytych w pamięci SIMA, umożliwiając choćby ich skopiowanie albo modyfikację, co nie
powinno zgodnie z ustalonymi standardami w ogóle być możliwe. Obejście tego zabezpieczenia uderza w cały system i zaufanie w to, że poufnych danych raz zapisanych na kartach SIM nie da się już
z nich wyciągnąć. Ale to dopiero początek kłopotu z zaufaniem, bo w związku z tym, że EUIC, czyli system, w którym znaleziono opisywane błędy, uznawany jest domyślnie przez operatorów
telekomunikacyjnych za bezpieczny, to ufa mu się niejako w ciemno. Jeśli więc telefon poprosi Telekom o przesłanie profilu sieci, podpisując się certyfikatem zaszytym w karcie SIM, no
to operator bez chwili zastanowienia na takie zapytania odpowie. A profil taki zawiera wiele sekretów operatora dotyczących konfiguracji jego sieci. różne inne klucze kryptograficzne czy
aplikacje. Pełne złamanie zabezpieczeń EUICC nie tylko pozwala na odczytywanie sekretów, ale też modyfikowanie ich i wgrywanie z powrotem na urządzenie. Badacze przetestowali to w jednej z
polskich sieci komórkowych. zamówili do posiadanego numeru dodatkową kartę SIM, taką jaką wykorzystuje się choćby w zegarku, aby można było iść pobiegać bez telefonu i nadal odebrać rozmowę czy
SMS-a. Taką kartę zainstalowali na urządzeniu z wewnętrznym oprogramowaniem dostarczonym przez Kigena. Dzięki złamaniu jego zabezpieczeń mogli podglądać całą odszyfrowaną komunikację
pomiędzy Telekomem a ich urządzeniem. W efekcie pozwoliło to choćby sklonować taką kartę jeden do jednego już bez wiedzy operatora i wgrać ją na inny telefon. Uruchomienie jej równolegle
pozwoliło na przechwytywanie komunikacji kierowanej do głównego numeru bez pozostawiania żadnego śladu w telefonie potencjalnej ofiary. W dodatku operator nie dysponuje żadnymi gotowymi
mechanizmami, które pozwoliłyby mu na wykrycie, że łączy się do jego sieci ktoś korzystający z takiego zmodyfikowanego profilu. A to otwiera puszkę Pandory, bo potencjalnie wytrąca
operatorowi wszelki oręż w walce z kimś dysponującym takimi możliwościami. Nie jest on w stanie nawet odciąć atakującego od swojej sieci lub zweryfikować, czy w prawidłowy sposób
odpowiada na żądania. Na przykład związane ze standardaryzowanymi przez 3GP mechanizmami lowful interception, gdzie odpowiednie służby mogą nakazać karcie przesłanie pewnych danych do
operatora. Taka zhakowana karta może to po prostu olać stawiając jej właściciela niejako ponad prawem. Pozwala też potencjalnie na podsłuchiwanie prowadzonej przez sieć komunikacji. Choć
tu znowu ważna uwaga. Nie powinno to być możliwe wobec użytkowników, którzy już są w sieci zarejestrowani za pomocą swojego własnego SIM-a. Luki te pewnie da się załatać i nakładając na cały
system kolejną warstwę bezpieczeństwa w postaci odpowiednich firewall analizujących choćby w czasie rzeczywistym zachowania obonentów, ich lokalizację i tak dalej, i tak dalej.
Ale to jest naprawdę nietrywialne i nietanie rozwiązanie. Na razie, aby przeprowadzić atak, który zasymulowali badacze, koniecznym jest posiadanie fizycznego dostępu do urządzenia swojej
potencjalnej ofiary. No bo trzeba na jego karcie SIM najpierw zainstalować złośliwą aplikację, a następnie za jej pomocą wykraść klucze, którymi przedstawimy się sieci komórkowej, aby
ta przesłała nam swój profil. Natomiast nie chodzi tu jedynie o problem samego uwierzytelniania, bo z racji architektury całej sieci komórkowej opartej w dużej mierze po prostu o
zaufanie, możliwość taką mają setki różnych podmiotów w rodzaju producentów oprogramowania czy operatorów telekomunikacyjnych. Wystarczy, że jeden taki podmiot, czy nawet jakiś złośliwy w
nim pracownik będzie miał złe zamiary i układanka ta potencjalnie może lec w gruzach jak domek z kart. Możemy śmiało poczynić parę założeń i w efekcie wyobrazić sobie sytuację, że to operator
telekomunikacyjny albo dostawca urządzeń jest tym złośliwym, choćby w jakimś kraju o mało demokratycznych standardach czy po prostu szpiegującym w ten sposób kogoś innego. Pomija to cały pierwszy
etap ataku, bo umożliwia instalację dowolnej aplikacji na karcie, gdy polecenie to wydaje zaufany podmiot. Co ważne, pozwala na przeprowadzenie takiego ataku zdalnie, a to już czyni go
naprawdę bardzo niebezpiecznym. Czy to tylko teoria? Przykład, na którym badacze oparli swoje wnioski, nawet emuluje atak z zewnątrz z wykorzystaniem odpowiednio spreparowanego SMS-a, ale
wolą pewnie nie rzucać słów na wiatr bez testowania tego w realnym świecie. Natomiast to pewnie jest mocno nielegalne, stąd nie powinna dziwić nas ich rozwaga. W tym miejscu dochodzimy do
sedna problemu. No bo czy w ten sposób można zaatakować nasze telefony, jak mogły sugerować niektóre nagłówki czy nawet artykuły w mediach? No nie, nie można. Raczej nie. Przynajmniej nic na
to na razie nie wskazuje, ani tego wprost nie udowodniono. Bo aby uzyskać ten sam poziom dostępu w iPhonie czy Androidzie, trzeba przełamać jeszcze zabezpieczenia platformy. To nie znaczy,
że nie da się tego zrobić, ale to zdecydowanie bardziej skomplikowane niż może się wydawać. Choćby dlatego, że nasze telefony komórkowe na każdym z tych etapów, gdzie odkryto błędy,
posiadają swoje dodatkowe metody ich remediacji. Mogą choćby weryfikować poprawność kodu, ponieważ dysponują do tego w zupełności wystarczającą mocą obliczeniową. Gdyby jednak atak taki
powiódł się, konsekwencje mogą być zdecydowanie poważniejsze, ponieważ telefony mogą przechowywać w tym miejscu, czyli w tej bezpiecznej enklawie, również dane dotyczące choćby
kart płatniczych. Badacze poinformowali firmę Kigen o swoim odkryciu z końcem marca tego roku. Podatność zarejestrowano i oceniono na 6.7 w skali CVSS, czyli niebezpieczeństwo założone
na takim średnim poziomie. Dlaczego tak słabo? bo oceniono udokumentowane odkrycia, a nie potencjalne zagrożenie. Zgodnie z przeprowadzonymi przez badaczy testami konieczny jest przecież
bezpośredni dostęp do urządzenia ofiary. Gdyby udowodniono na konkretnym przykładzie w pełni zdalny wektor ataku, punktacja ta byłaby na pewno sporo, sporo wyższa, zbliżając się do pełnej
dziesiątki. Niestety, aby to zrobić pewnie trzeba by złamać prawo, a mało kto zaryzykuje aresztem w imię nauki. Security Explorations przyznano oczywiście nagrodę z programu Back
Bounty w wysokości 30 000 $arów oraz ustalono trzymiesięczny okres przejściowy, który niedawno minął, podczas którego naprawiano tę lukę i opublikowano odpowiednie aktualizacje.
Oczywiście to czy trafi ona szeroko na wszystkie podatne urządzenia to już zupełnie inna historia. Badacze poinformowali też GSMA czyli Stowarzyszenie Operatorów
Telekomunikacyjnych, że odkryli takie luki, aby cała branża gotowa była na ewentualny audyt i sprawdzenie po swojej stronie, czy podatność ta ma wpływ na ich działalność. Poinformowano też
Oracle, czyli firmę stojącą za Javą działającą na kartach SIM. Security Explorations zaproponowali pewne rozwiązania, które mogłyby rozbroić tę bombę w zarodku, ale w tym przypadku
zostali po prostu zlani ciepłym znowu. Chwila, jak to znowu? A no okazuje się, że atak ten bazuje w pewnym stopniu na podatnościach zgłoszonych do Oracle dobrych kilka lat temu. Ich załatanie na
tamtym etapie nie pozwoliłoby na dotarcie tym razem aż tak daleko. Jednak wtedy firma zbagatelizowała te doniesienia. Twierdząc, że luki te są jedynie teoretyczne, a no i
zabezpieczenie na te okoliczności jest zadaniem implementującego standard i nie leży w kręgu zainteresowania Oracle. To pierwszy potwierdzony atak tego rodzaju na rozwiązania tej kategorii, a to nie
lada wyczyn. Potwierdza się kolejny raz teza, że każdy system da się złamać i nie można w ciemno ufać jakiemuś elementowi większej układanki, uznając go automatycznie za bezpieczny. Zero
trust to nie jest pusty slogan. O ile pokazano podatność na konkretnej konfiguracji, o tyle problem ten jest cechą całego protokołu i leży w jego architekturze, a to czyni go naprawdę
ciężkim do załatania. Jeśli nie zostanie naprawiony, to prędzej czy później ktoś odkryje, w jaki sposób wykorzystać go przeciwko naszym telefonom. Po bardziej szczegółowe technikalia odsyłam was
oczywiście do pełnego opracowania ekspertów, które znajdziecie w linkach pod materiałem. Co robić i jak żyć? Nie wyciągaj zbyt daleko idących wniosków z samych nagłówków. W kilku miejscach w
Internecie mogłeś przeczytać, że złamano zabezpieczenia SIM, jakby to wszystkie nasze telefony miały nagle zacząć sypać sekretami na prawo i lewo. A to nie jest prawda. Przynajmniej na razie. Jeśli
widzisz, że cytowane jest jakieś badanie, to zerknij w nie i przeczytaj choć abstrakt. Czasami to już wystarczy, aby zaprzeczyć tezom stawianym w clickbaitowych artykułach. Luki te
częściowo nie są nowe. Security Explorations odnalazło błędy w kartach Java w 2019 roku i zgłosiło je do Oracla dostawcy technologii. Firma ta jednak uznała, że nie są one istotne, a w sumie
to nawet nie są błędami. Cóż, jak widać byli w błędzie, bo właśnie na kanwie tamtych odkryć udało się opracować opisywany dziś atak. Dlatego jeżeli ktoś zgłasza ci jakiś błąd, nie bagatelizuj
tego, twierdząc, że nie ma on na nic wpływu. Błędy się naprawia, bo w innym przypadku zawsze zemszczą się one w przyszłości. Architektura SIM niestety nadal w paru bardzo istotnych miejscach
opiera się na zaufaniu w ciemno, a to naraża już nie tylko potencjalnie na właśnie takie podatności, które z czasem pojawią się też w innych aspektach. W paru miejscach korzysta się też z
dzielonych sekretów, gdzie klucz do bram na każdym z telefonów jest identyczny, a przecież sekret, który dzielą więcej niż dwa podmioty, przestaje być automatycznie sekretem i nie można o
niego opierać bezpieczeństwa. To zła praktyka, której nigdy nie warto stosować w swoich rozwiązaniach. Niestety istnieje spora szansa, że podobne luki zostaną albo nawet już
zostały odnalezione przez osoby o zdecydowanie słabszym kompasie moralnym od naszych rodaków. A tacy zamiast poinformować o tym zainteresowanych, po prostu sprzedadzą swoje dokonania
najlepiej płacącemu, czyli w tym przypadku albo jakiemuś krajowemu wywiadowi, albo firmie produkującej oprogramowanie szpiegowskie w rodzaju Pegasusa. Dla takich podmiotów podatność
tej wagi to święty gral, ponieważ nie tylko pozwala na inwigilację, ale też nie da się w łatwy sposób wykryć, że ktoś z niej korzysta. A wtedy wszyscy będziemy mieć naprawdę spory problem.
Dlatego Security Exploration, kawał dobrej roboty, czapki z głów i wielkie gratulacje. W szczególności za upór, z którym walczycie z zabetonowanymi korporacjami. A jeżeli chcesz być na
bieżąco z takimi doniesieniami, to zapisz się do mojego newslettera pod adresem newsletter.pl. I to już wszystko na dziś. Tymczasem dziękuję za waszą uwagę i do zobaczenia.
[Muzyka]

13.08.25

  • NAJLEPSZE FILMY FANTASY WSZECH CZASÓW I WARTE POZNANIA PEREŁKI
  • CIEKAWOSTKI O PINGWINACH – ODKRYJ ZASKAKUJĄCE FAKTY
  • CIEKAWOSTKI O PINGWINACH – ODKRYJ ZASKAKUJĄCE FAKTY
  • 🏠 Szkoda spreparowana przez AI?
  • 💸 Uważaj na tę „aplikację”!
  • Contact
  • Czy mObywatel szpieguje Polaków?
  • Zhakowano eSIMy! Ale (na razie) się nie martw.

LOREM IPSUM

Sed ut perspiciatis unde omnis iste natus voluptatem fringilla tempor dignissim at, pretium et arcu. Sed ut perspiciatis unde omnis iste tempor dignissim at, pretium et arcu natus voluptatem fringilla.

LOREM IPSUM

Sed ut perspiciatis unde omnis iste natus voluptatem fringilla tempor dignissim at, pretium et arcu. Sed ut perspiciatis unde omnis iste tempor dignissim at, pretium et arcu natus voluptatem fringilla.

LOREM IPSUM

Sed ut perspiciatis unde omnis iste natus voluptatem fringilla tempor dignissim at, pretium et arcu. Sed ut perspiciatis unde omnis iste tempor dignissim at, pretium et arcu natus voluptatem fringilla.

© 2026 Personal Blog | Powered by Superbs Personal Blog theme