Podatności Arista EOS

Na platformach z Arista EOS z włączonym IGMP snooping (domyślnie na wszystkich VLAN-ach) sąsiadujący sieciowo nieuwierzytelniony atakujący może wysłać zniekształcone pakiety sieciowe do dotkniętego VLAN-u, powodując nieoczekiwane zakończenie agenta IGMP snooping. Prowadzi to do tymczasowego zakłócenia zarządzania ruchem multicast, co może spowodować zalanie ruchem multicast wszystkich portów dotkniętego VLAN-u do czasu przywrócenia usługi.

W pewnych okolicznościach na platformach z Arista EOS z włączonym gRPC Network Packet Sampling Interface (gNPSI) poświadczenia klienta gNPSI mogą być rejestrowane w postaci jawnej w lokalnych lub zdalnych dziennikach rozliczeniowych dostępnych dla uwierzytelnionych użytkowników.

W systemie Arista EOS z skonfigurowanym uwierzytelnianiem VRRPv2 IP-AH nieuwierzytelniony atakujący znajdujący się w tym samym segmencie sieci warstwy 2 może przechwycić prawidłowy uwierzytelniony komunikat ogłoszenia VRRP i odtwarzać go w nieskończoność. Odtworzone komunikaty mogą być użyte do rozgłaszania nieaktualnego stanu VRRP, na przykład aby uniemożliwić routerowi zapasowemu przejęcie wirtualnej bramy po awarii oryginalnego routera głównego.

W systemie Arista EOS z włączonym VRRP dane uwierzytelniające VRRP urządzenia partnerskiego są zapisywane w logach w postaci jawnej. Użytkownik z odpowiednimi uprawnieniami może odczytać te dane z logów śledzenia agenta lub z systemu odbierającego przekazywane logi, bez dostępu do segmentu sieci, w którym działa VRRP.

Na platformach z Arista EOS nieuwierzytelniony atakujący w sąsiedztwie sieciowym przełącznika, mogący połączyć się z urządzeniem z włączonym PIM Sparse Mode i MLAG, może wysłać zniekształcone komunikaty powodujące nieoczekiwane zakończenie agenta Pimsm. Agent jest automatycznie restartowany, ale powtarzane ataki mogą prowadzić do ciągłych restartów i trwałej odmowy usługi.

Arista EOS w wersjach przed 4.11.12, 4.12 przed 4.12.11, 4.13 przed 4.13.14M, 4.14 przed 4.14.5FX.5 oraz 4.15 przed 4.15.0FX1.1 umożliwia zdalnym atakującym wykonanie dowolnego kodu jako root poprzez wykorzystanie dostępu do płaszczyzny zarządzania.

W pewnych warunkach na platformach z systemem Arista EOS z włączonym interfejsem gRPC Network Packet Sampling Interface (gNPSI) nieuwierzytelniony klient gNPSI może spreparować złośliwe żądanie umożliwiające wykonanie dowolnego kodu. Daje to atakującemu pełną kontrolę administracyjną nad przejętym przełącznikiem.

Nieuwierzytelniony atakujący z dostępem sieciowym do prywatnego łącza HA może wywołać wrażliwe funkcje rówieżników HA bez weryfikacji. Może to prowadzić do podniesienia uprawnień i wykonania poleceń na urządzeniach Edge z włączonym HA.

Nieuwierzytelniony klient P4Runtime może uzyskać zdalne wykonanie kodu na platformach Arista EOS z włączonym P4Runtime (domyślnie wyłączony). Wykorzystanie złośliwego pakietu podczas inicjacji sesji P4Runtime pozwala na pełną kontrolę administracyjną nad przełącznikiem.

Uwierzytelniony atakujący z uprzywilejowanym dostępem może wykorzystać usługę gNSI Certz na produktach Arista EOS, aby eskalować uprawnienia i wykonywać dowolne polecenia systemowe z uprawnieniami roota. Usługa Bootz również jest dotknięta.

Na platformach z systemem Arista EOS skonfigurowanym jako przekaźnik DHCP nieuwierzytelniony atakujący z dostępem sieciowym może wysłać spreparowany pakiet odpowiedzi DHCP z adresu IP, który nie jest skonfigurowany jako adres pomocniczy. Agent przekaźnika przekazuje taki pakiet klientom bez weryfikacji źródła.

Na platformach Arista EOS z włączonym OpenConfig, żądanie gNMI Set może zostać wykonane, mimo że powinno zostać odrzucone. Może to prowadzić do zastosowania nieoczekiwanej konfiguracji na przełączniku.

Platformy z systemem Arista EOS z włączonym OpenConfig mogą akceptować żądania gNMI Set, które powinny być odrzucone. Może to prowadzić do nieoczekiwanej konfiguracji przełącznika.

Na niektórych platformach z Arista EOS i luźną konfiguracją Unicast Reverse Path Forwarding (uRPF) określony ruch może nie podlegać zamierzonemu odrzuceniu weryfikacyjnemu. W rezultacie ruch, który powinien zostać odrzucony na podstawie tych tras, może być nadal przetwarzany i przekazywany przez urządzenie.

Specjalnie spreparowany pakiet może spowodować przedwczesne wygaśnięcie stanu przekazywania multicast na dotkniętych interfejsach. Może to prowadzić do tymczasowej utraty ruchu multicast w okresie objętym problemem.

Na platformach Arista EOS z skonfigurowanym OSPFv3, specjalnie spreparowany pakiet może spowodować nieoczekiwane ponowne uruchomienie agenta OSPFv3.

Na dotkniętych platformach z Arista EOS i skonfigurowanym SNMP poświadczenia użytkowników lokalnych lub zdalnych SNMPv3 mogą być ujawnione jako jednokierunkowa, zahaszowana, zlokalizowana wartość klucza w konfiguracji urządzenia (running i sanitized). Uwierzytelniony użytkownik z dostępem do tych informacji może wykorzystać je do nieautoryzowanych operacji odczytu tabel SNMP lub wysyłania fałszywych powiadomień trap do systemu NMS.

Na dotkniętych platformach z Arista EOS i skonfigurowanym OSPFv3 nieuwierzytelniony atakujący w tej samej domenie rozgłoszeniowej OSPFv3 może wysłać specjalnie spreparowany zestaw pakietów powodujący nieoczekiwany restart agenta Ospf3. Awaria powoduje utratę wszystkich sąsiedztw OSPFv3 na urządzeniu i może zakłócić routing w całej domenie OSPF do czasu odzyskania agenta.

Na dotkniętych platformach z Arista EOS i skonfigurowanym OSPFv2 oraz segment routing OSPFv2 specjalnie spreparowany pakiet OSPFv2 od sąsiedniego routera OSPF może spowodować nieoczekiwany restart OSPF.

Na platformach Arista EOS z skonfigurowanym OSPFv2, specjalnie spreparowany pakiet OSPFv2 od nieuwierzytelnionego atakującego w tym samym segmencie rozgłoszeniowym, przy skonfigurowanym uwierzytelnianiu OSPFv2, może powodować flapping sąsiedztwa i utratę pakietów. Zakłócenia mogą wpływać na routing w całej domenie OSPF.

Na dotkniętych platformach z Arista EOS uwierzytelniony użytkownik z dostępem do gNMI (gRPC Network Management Interface) może otrzymać nieprawidłowe wyniki autoryzacji, co potencjalnie pozwala na dostęp wykraczający poza aktualnie przypisane uprawnienia.

Na platformach Arista EOS z włączonym gRPC Network Management Interface (gNMI), specjalnie spreparowane żądanie może pozwolić złośliwemu uwierzytelnionemu klientowi z dostępem gNMI na wykonanie dowolnego kodu z uprawnieniami roota na przełączniku.

Na platformach Arista EOS, gdy skonfigurowano wiele transportów gRPC Network Security Interface (gNSI), występuje wyścig w usłudze gNSI Authz, który może spowodować ciche niepowodzenie rotacji polityk. Uwierzytelniony użytkownik, którego dostęp został cofnięty przez nową politykę, może zachować nieautoryzowany dostęp do interfejsów gRPC. Problem nie dotyczy Bootz. Został wykryty wewnętrznie przez Arista, brak doniesień o złośliwym wykorzystaniu.

Na platformach EOS z włączoną autoryzacją gRPC opartą na AAA dla OpenConfig, żądania gRPC uwierzytelnionego użytkownika do OpenConfig mogą używać niewłaściwego poziomu uprawnień, co skutkuje autoryzacją przy użyciu niewłaściwej listy metod AAA. Nie wpływa to na żądania OpenConfig inne niż gRPC, takie jak NETCONF.

Na platformach Arista EOS z skonfigurowanym gRPC Network Security Interface (gNSI) Credentialz, specjalnie spreparowane żądanie może spowodować niezamierzone modyfikacje właściwości konta docelowego. Może to skutkować przyznaniem kontu podwyższonych uprawnień lub dostępu wykraczającego poza zamierzenia administratora.

Na platformach Arista EOS problem z gRPC Network Security Interface (gNSI) Authz Rotate RPC może spowodować, że nieprawidłowa polityka Authz przesłana w trwającym strumieniu RPC stanie się aktywna. Problem nie dotyczy Bootz. Został odkryty wewnętrznie przez Arista, a firma nie zna żadnych złośliwych wykorzystań tego problemu w sieciach klientów.

Na platformach Arista EOS z włączonym OpenConfig i serwerem gNMI, gdy skonfigurowano gNSI Pathz z polityką zawierającą zarówno regułę grupową, jak i regułę użytkownika dla tej samej ścieżki, gNMI może nieprawidłowo egzekwować reguły polityki. W pewnych warunkach uwierzytelniony użytkownik może uzyskać nieautoryzowany dostęp do odczytu lub zapisu ścieżek gNMI, które polityka Pathz miała ograniczać.

Na platformach Arista EOS z usługami związanymi z OpenConfig (gNMI, gNSI, RESTCONF, NETCONF) wrażliwe żądania i odpowiedzi mogą być przypadkowo rejestrowane w logach. Mogą być przechowywane lokalnie na urządzeniu EOS lub wysyłane do zdalnych serwerów księgujących. Przykłady wrażliwych informacji to poufne polecenia CLI (np. 'username bob secret myPass') oraz wrażliwe liście YANG OpenConfig (np. 'system/aaa/global/tacacs/config/secret-key').

Na platformach z Arista EOS z skonfigurowanym MLAG Dual Primary Detection nieuwierzytelniony atakujący z dostępem do segmentu sieci Dual Primary Detection może wysyłać specjalnie spreparowane pakiety zakłócające stan dual-primary. Jeśli przełącznik MLAG primary ulegnie awarii w obecności tych pakietów, przełącznik secondary błędnie uzna, że jest w stanie dual-primary i wyłączy swoje interfejsy, powodując przerwę w ruchu.

Na platformach z Arista EOS z włączonym IS-IS graceful restart nieuwierzytelniony atakujący, który może wstrzyknąć zniekształcony pakiet IS-IS LSP PDU, może spowodować przedwczesne zakończenie procedury IS-IS graceful restart. Może to skutkować utratą ruchu po zdarzeniu restartu.

Na platformach z systemem Arista EOS i skonfigurowanym protokołem IS-IS nieuwierzytelniony atakujący może wstrzyknąć specjalnie spreparowany pakiet IS-IS LSP PDU, powodując nieoczekiwane usunięcie prawidłowego LSP z bazy stanu łącza IS-IS. Może to skutkować utratą ruchu.

Na platformach z systemem Arista EOS, na których IS-IS jest skonfigurowany na interfejsie broadcast, nieuwierzytelniony atakujący może wysłać spreparowany pakiet IS-IS Hello PDU, powodując zerwanie ustanowionego sąsiedztwa IS-IS. Może to skutkować zakłóceniem ruchu i utratą osiągalności IP dla prefiksów ogłaszanych przez to sąsiedztwo.

Na platformach z systemem Arista EOS, na których skonfigurowano uwierzytelnianie VRRPv2 IP Authentication Header (IP-AH), nieuwierzytelniony atakujący z dostępem do segmentu sieci warstwy 2, w którym działa VRRP, może obejść uwierzytelnianie VRRP i przejąć rolę master wirtualnego routera. Umożliwia to atakującemu przechwytywanie, modyfikowanie lub odrzucanie ruchu wysyłanego przez hosty w segmencie na adres bramy wirtualnej.

Na platformach Arista EOS z włączonym DHCP relay/snooping i opcją informacyjną (Option 82) lub serwerem DHCP z kryteriami dopasowania opartymi na tej opcji, nieuwierzytelniony atakujący podłączony do VLAN-u klienckiego może wysłać specjalnie spreparowany pakiet powodujący restart usługi DHCP Relay.

Na platformach z systemem Arista EOS, na których skonfigurowano uwierzytelnione sesje Bidirectional Forwarding Detection (BFD), specjalnie spreparowany pakiet może spowodować spadek sesji BFD. Może to prowadzić do niepożądanych zmian w sieci, ponieważ różne protokoły routingu monitorują stan sesji BFD.

W systemie Arista EOS, w pewnych okolicznościach, hasła współdzielone (shared secrets) dla skonfigurowanych serwerów TACACS+ mogą być przechowywane lub ujawniane w postaci jawnej. Problem dotyczy platform z tym systemem.

W systemie Arista EOS, w pewnych okolicznościach, hasła użytkowników mogą być zapisywane w postaci jawnej w plikach logów, gdy specjalistyczne, niestandardowe poziomy śledzenia debugowania są wyraźnie włączone. Wykorzystanie wymaga już posiadania uwierzytelnionego lokalnego dostępu administracyjnego do powłoki urządzenia.

W systemie Arista EOS, w pewnych okolicznościach, prywatne klucze mogą być zapisywane w postaci jawnej w plikach logów, gdy specjalistyczne, niestandardowe poziomy śledzenia debugowania są wyraźnie włączone. Wykorzystanie wymaga już posiadania uwierzytelnionego lokalnego dostępu administracyjnego do powłoki urządzenia.

W systemie Arista EOS na platformach z podwójnymi kartami przełącznika i skonfigurowanymi przychodzącymi listami ACL Security na przełączanych interfejsach wirtualnych (SVI) w trybie współdzielonym, restart agenta przekazywania pomocniczej karty przełącznika lub włożenie pomocniczej karty przełącznika może spowodować, że listy ACL Security na współdzielonych SVI przestaną działać. Może to skutkować nieprawidłowym zachowaniem zezwalania/odrzucania pakietów.

Na platformach Arista EOS z skonfigurowanym uwierzytelnianiem hasłem specjalnie spreparowane hasło może tworzyć osierocone sesje uwierzytelniania. Powtarzane wykorzystanie może wyczerpać zasoby uwierzytelniania, uniemożliwiając legalnym użytkownikom logowanie się do urządzenia.

Na platformach Arista EOS z skonfigurowanym uwierzytelnianiem portów 802.1X oraz funkcją RADIUS proxy z dynamiczną autoryzacją, atakujący o niskich uprawnieniach w sąsiednim segmencie sieci może wywołać pakiet RADIUS przez klienta proxy, aby uniemożliwić zastosowanie komunikatów dynamicznej autoryzacji RADIUS (CoA i Disconnect-Requests wg RFC 5176) do lokalnie uwierzytelnionych sesji 802.1X. Pozwala to na pozostanie sesji endpointu w sieci mimo polecenia rozłączenia z serwera RADIUS lub systemu NAC.

Podatność w systemie Arista EOS z skonfigurowanym IPsec. Specjalnie spreparowany pakiet może zatrzymać przetwarzanie całego ruchu IPsec w warstwie danych. Po resecie ruch może nie zostać wznowiony. Ruch nie-IPsec nie jest dotknięty.

Na dotkniętych platformach z systemem Arista EOS, gdzie skonfigurowano MACsec i reguły ACL dla ruchu wychodzącego na tych samych interfejsach, polityki ACL mogą nie być egzekwowane dla pakietów wychodzących na tych portach.

Na platformach z systemem Arista EOS, gdzie skonfigurowano uwierzytelnianie 802.1x na portach dostępowych/trunkowych oraz włączono routing w sieci VLAN dostępu, złośliwy supplicant może ominąć wymóg uwierzytelniania 802.1x.

W Arista EOS w trybie 802.1X, nieuwierzytelnione hosty multi-auth mogą uzyskać dostęp do portu przełącznika, jeśli w sieci VLAN rezerwowej istnieje urządzenie obsługujące EAPOL.

Na dotkniętych platformach działających na Arista EOS, skonfigurowanych do mirroringu do wielu miejsc docelowych, wewnętrzny błąd systemowy może spowodować panikę jądra i wymusić ponowne uruchomienie systemu.