Polski operator telekomunikacyjny INEA przez większą część sierpnia przekierowywał do swojej sieci ruch internetowy kilku brazylijskich klas adresowych. Dwa dni temu przechwycił tez ruch amerykańskiego Departamentu Obrony.
W zeszłym roku opisywaliśmy ciekawe ataki, polegające na ogłaszaniu w sieci fałszywych tras rutingu. Polegają one na tym, że zaufany operator celowo (najczęściej rękami włamywaczy) informuje swoich partnerów, że obsługuje cudzą klasę adresową. Powoduje to, że do jego sieci trafia ruch przeznaczony dla kogoś innego. Właśnie dowiedzieliśmy się, że w podobny incydent zamieszany jest polski operator telekomunikacyjny INEA a jego problemy trwają od sierpnia.
Manipulacje trasami BGP
Czasem błędne definicje tras rutingu mogą być wynikiem błędu pracownika operatora – tak prawdopodobnie było w przypadku indonezyjskiej firmy, która przez chwilę otrzymywała ruch ponad połowy internetu. Czasem z kolei jest to ewidentnie działanie osób o złych intencjach – tutaj przykładem niech będą niedawne ataki na kopalnie kryptowalut. Jak było w przypadku polskiej firmy? Dużo bardziej prawdopodobny wydaje się ten drugi wariant.
Polski ślad w globalnym spisku
Firma Renesys, monitorująca bezpieczeństwo protokołu BGP, opublikowała własnie podsumowanie niedawnych incydentów wstrzykiwania błędnych tras BGP przez dużych operatorów sieci na całym świecie. Z zaskoczeniem zauważyliśmy, że spora część raportu poświęcona jest operatorowi INEA (oraz Inotel, który został przez INEĘ przejęty). Czym zasłużył się nasz operator?
Jak ustaliła firma Renesys pierwszy poważny incydent z udziałem INEI zaczął się 6 sierpnia 2014. Jej sieć rozgłosiła wtedy dwa nienależące do niej prefiksy:
177.39.184.0/23 oraz 187.106.32.0/19
Śledzenie pakietów z sieci GTS do brazylijskich zakresów adresacji przejętych przez INEĘ wyglądało tak przed incydentem:
trace from Warsaw, Poland to Revo Telecomunicaç?es at 00:35 Aug 05, 2014
1 *
2 217.153.202.161 (GTS Poland Sp. z o.o., Warsaw, PL) 0.952
3 193.85.195.94 (GTS Czech s.r.o.,Prague, CZ) 17.065
4 *
5 4.69.154.200 ae-4-90.edge4.Frankfurt1.Level3.net 17.222
6 4.68.63.242 glbx-level3-10G.Frankfurt1.Level3.net 25.666
7 189.125.13.178 (Revo Telecomunicaç?es, Porto Alegre, BR) 248.358
8 177.39.185.10 (Revo Telecomunicaç?es, Guarulhos, BR) 251.24
9 177.39.190.8 (Gm Telecom Ltda, Palmitinho, BR) 251.609
a tak w trakcie jego trwania
trace from Warsaw, Poland to Revo Telecomunicaç?es at 17:10 Aug 06, 2014
1 *
2 217.153.202.161 (GTS Poland Sp. z o.o., Warsaw) 1.119ms
3 157.25.248.142 (GTS Poland Sp. z o.o., Warsaw) 0.397ms
4 185.1.4.2 inea-gw.pix.net.pl 5.407ms
5 62.21.99.161 rt1-owsiana-vlan503.core.icpnet.pl, Poznań, PL) 5.407ms
6 62.21.99.6 rt1-oswiecenia-vlan407.core.pl, Poznań, PL) 5.608ms
7 212.73.253.137 (Level 3, Frankfurt, DE) 27.76ms
8 4.69.153.69 ae-9-9.ebr4.Frankfurt1.Level3.net 27.74ms
9 4.69.163.22 ae-74-74.csw2.Frankfurt1.Level3.net 27.65ms
10 4.69.154.72 ae-2-70.edge4.Frankfurt1.Level3.net 27.743ms
11 4.68.63.242 glbx-level3-10G.Frankfurt1.Level3.net 27.854ms
12 189.125.13.178 (Revo Telecomunicaç?es, Porto Alegre, BR) 249.385ms
13 177.39.184.194 (Revo Telecomunicaç?es, Porto Alegre, BR) 248.138ms
14 *
Jak widać do trasy zostały dodane dodatkowe etapy, prowadzące przez sieć polskiego operatora. Czy mógł to być zwyczajny błąd pracownika? Jest to raczej mało prawdopodobne, ponieważ rozgłaszanie cudzych sieci ustało dopiero pod koniec sierpnia, a więc przez ok. 3 tygodnie INEA „kradła” ruch przeznaczony dla innego operatora. To jednak nie koniec historii.
Atak na amerykański Departament Obrony
10 września INEA zaczęła rozgłaszać prefiks należący do… amerykańskiego Departamentu Obrony ( 128.19.65.0/24) . Co ciekawe, po kilkunastu minutach ten prefiks został zdjęty, a w jego miejscu pojawił się ponownie prefiks sieci brazylijskiej ( 177.200.2.0/23). Tym razem atak trwał ponad dobę i ustał wczoraj. Wygląda na to, że przejęcie sieci naszych przyjaciół z USA było tylko testem przed właściwym atakiem.
Wizualizacja udziału polskiego operatora w kierowaniu ruchu brazylijskich adresów
W jaki sposób włamywacze mogli dostać się do sieci INEI? Tutaj ciekawym tropem jest inny nasz artykuł, poświęcony błędom w usłudze Looking Glass. Ich odkrywcy informowali, że na liście podatnych operatorów znalazły się również firmy z Polski, jednak nie wskazali ich nazw. Firma Renesys informuje, że była wśród nich właśnie INEA. Za pomocą zidentyfikowanych przez badaczy błędów można było w prosty sposób przejmować kontrolę nad kluczowymi ruterami w sieciach operatorów.
Jaki cel chcieli osiągnąć atakujący, przejmując ruch do brazylijskich sieci? Tego niestety nie udało się do tej pory ustalić.
PS. Jeśli czyta nas ktoś kto wie coś więcej o tym ataku i może się (anonimowo) podzielić szczegółami to zapraszamy do kontaktu.
Komentarze
Nie oceniam czy to ma związek ale ostatnio pewien oddział z południa kraju zaopatrywał się w nowe Junipery
Mam Inea, ale nie odczułem ataku. Mam IP publiczne, jestem podpięty do infrastruktury Inea, ale na speedtescie pokazuje mi Providera: HAWE TELEKOM SP. Z.O.O. na ich stronie, napisane jest iż dostarczają światłowody do Inei.
Mieszkasz w Kłodawie lub okolicach?
Ten atak zapewne nic nie mial na celu,po prostu odkryto taka mozliwosc w kolejnych sieciach i prawdopodobnie jest ona testowana i analizowana bez zadnego zastosowania.Druga opcja-takie ataki sa atakami na duza skale,moze chodzic po prostu o megapodsluch i zbieranie metadanych na duza skale przez jakis kolejny program typu Echelon.
Czy zmieniając dodatatecznie dużo tras da się „wyłączyć” internet, tak aby wiekśzość pakietów trafiało w „próźnię” ? To by było ciekawe gdyby na raz wszędzie na świeci zmienili i byłby tydzień bez neta :)
Mocno do propagacji ścieżek przyczynił się węzeł wymiany ruchu PIX, gdzie na mój stan więdzy nie ma żadnych automatycznych filtrów BGP (na podstawie RIPE jak w TPIX czy PLIX). Co zatem dalej idzie na załączonym przykładzie GTS łyknął bez weryfikacji, pozostali operatorzy podobnie i prefiksy rozeszły się dalej po kraju.
http://bgp.he.net/AS13110 – patrząc na listę łaczy które wykorzystuje INEA (+ IXy w których wiem, że są)
– Level3 – filtry
– Telia – filtry
– Retn – filtry
– ATM – filtry
– Hurricane – brak filtrów
– PIX – brak filtrów
– TPIX – filtry
– PLIX – filtry
mogę śmiało stwierdzić, że całe zdarzenie nie doszło by do skutku gdyby nie brak filtrów w PIX i Hurricane.
Ten słynny Waszi od ratowania Niebezpiecznika? :) Dzięki za tak rzadki w dzisiejszym świecie komentarz, który wnosi wiele ciekawego do tematu! Chyba czas napisać do PIXa :)
Waszi, po twoim odejsciu w tej firmie nie ma juz admina z prawdziwego zdarzenia, przyjmuja tylko jakis leszczy. Dlaczego nie dziwi mnie ta sytuacja?
Ciekawe to…
mimo, że ruch szedł przez Ineę, to i tak trafiał do właściwego celu i to jeszcze o kilka ms szybciej niż wcześniejsza trasa GTSu… Jakie to więc fałszywe rozgłaszanie? Może po prostu komuś coś cię omcknęło i zrobił z siebie tranzyt dla innych operatorów. :)
I tak mi się wysoki sądzie omsknęło kilka razy pod rząd i zawsze trafiało na ten sam kraj ;)
To ciekawe, co piszecie o Looking Glassie.
Szczególnie, że INEA nigdy nie dawała dostępu do LG.
To faktycznie ciekawe, bo albo kłamie Renesys albo autorzy pracy o LG. Napiszemy do obu w tej sprawie.
Możliwe, że któryś z klientów INEI mających z nią styk BGP, lub któraś sieć przez INEĘ przejęta (kupili wielu okolicznych lokalnych operatorów) ma lub miała podatnego LG. W przypadku wykorzystania takiej podatności jasne staje się również, że INEA nie do konca panuje nad prefixlistami…
Warto zwrócić uwagę na fakt, że od 6 sierpnia 2014 prefiks 177.39.184.0/23 (brazylijski REVO TEL) był rozgłaszany przez AS33868 (PERFEKT-NET-POLAND) – jednego z klientów INEA. Announce BGP ze względu na brak filtrów przeszły przez PIX i Hurricane Electric. HE akurat peer-uje się ze wszystkimi, ale najczęściej przez najniższe local-preference. PIX to stosunkowo niewielki polski IXP i gdyby nie obecność większego uczestnika, czyli GTS to ten incydent mógłby zostać niezauważony.
PERFEKT-NET-POLAND (AS33868) do niedawna oferował usługę looking glass pod adresem lg.net.perfekt.pl opartą na dziurawym skrypcie MRLG4PHP w wersji 1.0.7. Błąd umożliwiał zdalne wykonanie poleceń na routerze i mógł być wykorzystany przez włamywaczy. Obecnie usługa nie jest już dostępna.
Mylisz się. Inea jak najbardziej dawała dostęp do LG. Na przynajmniej jednym z routerów.
Hmmm… W AS 13110, czy w którymś z wielu innych?
W innym.
Ok, to się zgadzam.
Ja miałem na myśli AS 13110.
Operator taki jak GTS również powinien mieć filtry a nie ufać wszystkiemu co mu ktoś podeśle. Przecież można posiadać prosty filtr który wycina sieci z takiego np PIX gdy zwierają ASN któregoś z Tier1.
Można. A należy? Trend na trucie BGP jest znany, a u jego podstaw leżą błędy w konfiguracji i utrzymaniu, natomiast wczesniej to nie wyszło, bo nikt nie przyjrzał się im uważnie. Jeżeli ktoś bierze się za bycie ISP, jego obowiązkiem jest pilnować trendów i oczywistych podstaw, robienie czegokolwiek ponad standardowy, ogólny monitoring jest absurdalne, bo musieliby pilnować wielu rzeczy więcej. Na mniejszą skalę, jeżeli robię jakiś projekt w zespole to zakładam, że z grubsza wie co robi, i obsługuję ewentualnie rzeczy, których w miarę się spodziewam. Jeżeli system się wywali, bo zależna klasa podzieliła przez zero albo dropnęła bazę, to mimo że może i mógłbym temu zapobiec, ale tego nie zrobię, bo bym padł w mnogości double i triple checków każdego błędu, który mógłby się wydarzyć.
Co więcej – PIX posiada narzędzia chroniące jego użytkowników przed takimi sytuacjami. Ze strony ripe:
https://apps.db.ripe.net/search/lookup.html?source=ripe&key=AS44896&type=aut-num
cytuję:
remarks: All prefixes verified with as-set: AS-PIX are
remarks: marked with 44896:0
Wystarczy aby każdy z uczestników akceptował tylko prefiksy z tym community.
Najwyraźniej GTS i Hurricane tego nie zrobił.
A czy sama INEA w ogóle komentuje jakoś tą sytuację?