• Zarejestrowany: 2017-08-22
  • Posty: 64

Temat: Bug w AR724X/AR933X

Dawno temu miałem problem z bridgowaniem 2 vlanów: https://eko.one.pl/forum/viewtopic.php?id=19288 . Problemu nie rozwiązałem, ustawiłem nietagowane vlany i podmieniłem po prostu switcha na tp-linka. Niestety, dziś na moim Archerze d7 na Owrt musiałem ustawić coś bardzo podobnego, bridgowanie dwóch vlanowych sieci na tym samym switchu (gościnna i bezpieczna), co dało dokładnie takie same rezultaty jak na WR740: przez bridge przechodzą tylko ramki z dest mac broadcast. Jako, że w tym przypadku nie mogłem sobie pozwolić na zwykły nietagowany vlan (potrzebna mi była funkcjonalność ebtables) postanowiłem trochę problem pokopać i udało mi się dojść do jego źródła: wadliwa implementacja tablic arl w switchach atherosu.

Od początku:
Wyobraźmy sobie bardzo hipotetyczny router z 1 ifejsem sieciowym eth0 i jednym 3-portowym (do dyspozycji mamy 2) switechm switch0 z obsługą 802.11q podłączonym pod eth0. Chcemy, aby porty 1 i 2 działały w ramach L2, proste: nie robimy nic albo ustawiamy jeden globalny vlan. Natomiast teraz trochę komplikujemy: nadal chcemy switch L2, ale pomiędzy portami ma nie przechodzić jakiś dany adres mac. Teraz trzeba ustawić 2 różne vlany i je zbridgować na L2, jednocześnie ustawiając odpowiednią zasadę w ebtables. Też porste, prawda? No, jak się okazuje, nie do końca. Teraz z jakiegoś powodu pomiędzy sieciami nie przechodzi unicast. Ok, zepsuliśmy firewall, czyścimy tablicę z ebtables... nadal nic. Na wszelki wypadek czyścimy iptables... też nic. Czyli nie firewall.
Dla testów ustawiamy następującą sieć:

192.168.1.10 (eth10) <----Port 1 (eth0.10)----> router <----Port 2 (eth0.20)----> (eth20) 192.168.1.20

Dla łatwości uznajemy, że router ten nie bierze udziału w tej sieci, tj. albo kontrolujemy go z innej (wyimaginowanej w tej sytuacji), albo przez uart, na br0 nie ma żadnego adresu (unmanaged). Odpalamy sniffery na interfejsach: eth10, eth0.10, eth0, eth0.20, eth20 i otrzymujemy następujące rezultaty:
1. Przy zapytaniu arp o adres 192.168.1.20 z adresu 192.168.1.10 (zapytanie bcast, odpowiedź ucast):
    eth10:        zapytanie        brak odpowiedzi        |    x
    SWITCH                                |    x(?)
    eth0:        tagowane zapytanie    tagowana odpowiedź    v    ^
    eth0.10:    zapytanie        odpowiedź        |    | Droga pakietów
    br0                                |    |
    eth0.20:    zapytanie        odpowiedź        v    ^
    eth0:        tagowane zapytanie    tagowana odpowiedź    |    |
    SWITCH                                |    |
    eth20:        zapytanie        odpowiedź        ->----->-
Foto, gdyby się wszystko rozjechało:
https://www.dropbox.com/s/wkcqpv3adyrmtu5/trace.png?dl=1

Zauważmy, że pomiędzy eth0, eth0.10 i eth0.20 odpowiedzi są przekazywane prawidłowo, czyli problemów w softwarowym bridgu nie ma. Z resztą, jak zauważył @Cezary, gdyby były, to:

Cezary napisał/a:

[...]żaden router z openwrt by nie działał gdzie domyślnie robiony jest bridge z lanu i wifi.

Coś jest nie tak pomiędzy wysłaniem tagowanej ramki z eth0 (eth0.20) do eth20. Chyba nietrudno zauważyć, że jedyną rzeczą pomiędzy eth0 a eth20 jest SWITCH.

Dla pewności zprawdzamy config vlanów switcha switch0: swconfig dev switch0 show i przypadkiem zauważamy anomailę w sekcji arl_table:
    Port 0: MAC (mac eth0)
    Port 0: MAC (mac eth20)
    Port 0: MAC (mac eth10)

Na pierwszy rzut oka powinno być:
    Port 0: MAC (mac eth0)
    Port 2: MAC (mac eth20)
    Port 1: MAC (mac eth10)

Po chwili zastanowienia dochodzimy jednak do wniosku, że obecność macu eth20 na porcie 0 jest porządana i logiczna, gdyż router bridgując vlany 10 i 20 (interfejsy eth0.10 i eth0.20) bazując na swojej softwarowej tablicy arl, którą można podpatrzeć w brforward, otrzymawszy pakiet na 10 wysyła go na 20 i odwrotnie, spowrotem do switcha z takimi samymi adresami mac. Switch z kolei, widząc przychodzący tagowany pakiet z adresem eth10/eth20 na porcie 0 (tam, gdzie jest eth0), uznaje, że rzeczywiście jest on na porcie 0 i tak to ma działać, w przeciwnym wypadku switch nie wiedziałby gdzie przekierować odpowiedź. A więc poprawna tablica:
    Port 0: MAC (mac eth0)
    Port 0: MAC (mac eth20)
    Port 0: MAC (mac eth10)
    Port 2: MAC (mac eth20)
    Port 1: MAC (mac eth10)

Dlaczego więc arl_table tak nie wygląda? Moja teoria była taka, że z jakiegoś powodu arl nawet przy 2 oddzielnych vlanach jest nadal wspólny dla całego switcha, tj. nie ma oddzielnego arl dla vlanu 10 i 20. Byłoby to wyjaśnieniem dziwnego wyglądu arl: zastanówmy się co by było, gdyby switch miał wyłączoną obsługę vlan. Gdyby switch dostał 2 takie same pakiety z 2 takimi samymi adresami src na 2 różnych portach, to by zgłupiał: coś takiego w topologii ethernet nie powinno mieć miejsca. Jedynym *sensownym* wytłumaczeniem takiego zjawiska jest przepięcie komputera z jednego portu do drugiego. Z tego powodu, biorąc pod uwagę kolejność występowania naszych przesyłanych pakietów, lądują one w porcie 0 i nie są przekazywane do portów 1 i 2, bo switch uznał, że komputer został przepięty właśnie na port routera, gdy router z kolei po prosu wysyła forwardowany pakiet. Stąd brak komunikacji unicast. Broadcast nie potrzebuje mapowania, więc nie ma go w arl, bo wysyłany jest wszędzie.

Przy braku izolacji tablicy arl rodzi się więc zagrożenie. Co jeżeli (jak ja) mamy na takim niedopracowanym switchu sieć gościnną i własną? Po krótkim namyśle uznałem, że zgodnie z działaniem takiego switcha można spróbować przeprowadzić atak DoS z sieci gościnnej na własną i odwrotnie, aby sprawdzić, czy problemem jest właśnie to, o czym już tak bardzo się rozpisałem. Kluczem w takim wypadku jest tak częstę spamowanie switcha, aby co najmniej jeden pakiet z zespoofowanym adresem src ofiary od atakującego (nas) docierał do switcha POMIĘDZY wysłaniem przez switch pakietu od ofiary adresowanego gdzieś a otrzymaniem odpowiedzi przez switch z kądś adresowanego do ofiary (w przypadku naszego bridga wygląda to tak, że switch JUŻ UZNAŁ za port wychodzący port 0 ZANIM pakiet o zapytanie w ogóle dotarł do dest, więc gdy odpowiedź przychodzi, zgodnie z tablicą arp wyszłaby z tego samego portu, co jest głupie i podejrzewam, że logika switcha po prostu ten pakiet ignoruje, bo nie widzimy żadnych nietagowanych ramek w snifferze na eth0). Wtedy odpowiedź z sieci własnej na vlanie 10 powędruje na port sieci gościnnej o vlanie 20, gdzie zostanie odrzucona. Więc do dzieła!

Atakujący w kablowej sieci gościnnej obrał sobie za ofiarę bramę główną sieci własnej. Wtedy żaden klient w sieci własnej nie będzie mieć dostępu do WAN, bo odpowiedzi bramy głównej będą dropowane na poziome L2 w switchu. Zakładając, że zna adres mac tej bramy, a zna, bo jest jej adminem tongue, odpala to, jako atakujący, na PC wpiętym do sieci gościnnej:

nping -e eth0 -HNc0 --source-mac ad:re:so:fi:ar:y0 --dest-mac ad:re:so:fi:ar:y0 --delay 1ms --arp 0.0.0.0

(destmac można ustawić jakikolwiek, ja ustawiłem taki sam, żeby nie robić szumu w sieci.)
i, już jako admin, to na niedopracowanym switchu:

while : ; do sleep 1; clear; swconfig dev switch0 show | grep MAC; done

aby zobaczyć czy switch zgłupieje zgodnie z przewidywaniami (dany mac raz będzie na porcie atakującego, bo spamuje, a raz na porcie ofiary, która czasem wysyła jakieś inne pakiety). Jeżeli pakiet zwrotny trafi do switcha w czasie, gdy mac jest na porcie atakującego, mamy upragniony DoS.

Patrzymy na konsolkę i switch zdurniał, bo widać naprzemiennie:
    Port 0: MAC (mac eth0)
    Port 0: MAC (mac eth20)
i
    Port 0: MAC (mac eth0)
    Port 2: MAC (mac eth20)
a internetu w mojej sieci nie ma, chociażże tcpdump na bramie głównej mówi co innego smile



Piszę ten post z prośbą do forumowiczów, by sprawdzili to u siebie. Chyba najłatwiej będzie zbridgować 2 rózne vlany i na utworzonym bridgu postawić serwer dhcp. Niezależnie od lokacji, komunikacja klientów i routera (serwera dhcp) będzie działać ok, bo nie jest przekazywana do 2 portu, natomiast nie będą mogli wysyłać pakietów między sobą, chyba że na bcast. Jeżeli okaże się, że na waszym switchu też występuje ten problem, to napiszcie w poście model takiego switcha. Bo jeżeli nie ma problemu u nikogo, to nie zdurniał switch a ja.

Nie chcę dłużej szkodzić innym i zabierać cenny czas, tak więc dzięki za wytrwałość!
R.Ł.

2 Odpowiedź przez MrCiek4wski (edytowany przez MrCiek4wski 2020-07-10 13:49:50)

  • Zarejestrowany: 2017-08-22
  • Posty: 64

Odp: Bug w AR724X/AR933X

Update:
1. Sprawdziłem na Archerze D7 config, miałem zły, po porawie bridge działa, więc jego switch można wykluczyć.

2. swconfig w 18.06 nie zwraca arl_table, więc komenda z postu wyżej nie będzie działać (będzie pusty ekran), niemniej nie wpływa to na sam switch, który nadal jest podatny. Jeżeli załadujecie 19.07 z initramem, to zadziała.

3. Jeżeli znajdujecie się w br-guest albo br-lan stworzonego z vlanu i wlanu będąc podłączonym przez wlan atak nadal można wykonać ustawiając --dest-mac na bcast. Będzie to jednak dosyć głośne. Proszę jednak o sprawdzenie tego, gdyż mam urwaną antenę.

4. Atak działa tylko na elementy powiązane ze switchem, tj. tylko część kablową. Nie oddziałuje on na klientów wifi ani w br-lan, ani w br-guest.

5. Jeżeli atakujecie gateway, a interfejsy sieci lan i guest mają takie same MAC, to atak zadziała, ale sieć guest też nie będzie miała dostępu do wan.

PoC:
Aby przeprowadzić atak można wgrać sobie taką konfigurację:

root@OpenWrt:~# cat /etc/config/network 

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'

config interface 'lan'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ifname 'eth0.10'
    option delegate '0'

config interface 'guest'
    option proto 'static'
    option ipaddr '192.168.2.1'
    option netmask '255.255.255.0'
    option ifname 'eth0.20'
    option delegate '0'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option vid '10'
    option ports '0t 1 4'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option vid '20'
    option ports '0t 2 3'
root@OpenWrt:~# cat /etc/config/firewall 

config defaults
    option syn_flood '1'
    option input 'DROP'
    option forward 'DROP'
    option drop_invalid '1'
    option output 'DROP'

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option network 'lan'
    option family 'ipv4'

config zone                             
    option network 'guest'
    option input 'ACCEPT'
    option forward 'REJECT'
    option name 'guest'
    option output 'ACCEPT'
    option family 'ipv4'

config include
    option path '/etc/firewall.user'
root@OpenWrt:~# cat /etc/config/dhcp 

config dnsmasq
    option domainneeded '1'
    option boguspriv '1'
    option filterwin2k '0'
    option localise_queries '1'
    option rebind_protection '1'
    option rebind_localhost '1'
    option local '/lan/'
    option domain 'lan'
    option expandhosts '1'
    option nonegcache '0'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option resolvfile '/tmp/resolv.conf.auto'
    option nonwildcard '1'
    option localservice '1'

config odhcpd 'odhcpd'
    option maindhcp '0'
    option leasefile '/tmp/hosts/odhcpd'
    option leasetrigger '/usr/sbin/odhcpd-update'
    option loglevel '4'

config dhcp 'lan'
    option interface 'lan'
    option start '100'
    option limit '150'
    option leasetime '12h'
    option force '1'

config dhcp 'guest'
    option interface 'guest'
    option start '100'
    option limit '150'
    option leasetime '12h'
    option force '1"

config dhcp 'wan'
    option interface 'wan'
    option ignore '1'

Utworzy nam ona 2 interfejsy: lan na eth0.10 i guest na eth0.20. Następnie należy podłączyć po jednej karcie albo urządzeniu do każdej z nich. Po otrzymaniu IP dla kontroli połączenia trzebaby pingować router 192.168.{1,2}.1 z jednego z komputerów, a na drugim odpalić

nping -e <iface> -HNc0 --source-mac <routerMac> --dest-mac <routerMac> --delay 1ms --arp 0.0.0.0

Dopóki nie zabijecie programu urządzenie z odpalonym pingiem przestanie otrzymywać odpowiedzi, a jakikolwiek kontakt z routerem będzie zerwany.


Błąd raczej nie może zostać wykorzystany do niczego poza denerwowaniem innych, niemniej wypadałoby wspomnieć gdzieś na jakimś wiki, żeby nie korzystać z ar9331 do izolacji jakichś serwerów wymagających ciągły uptime w sieci lokalnej, np. dhcp albo właśnie gateway (czego raczej i tak nikt nie będzie robił na routerach z tym SoC), albo aby uważać przy konfiguracji w trybie AP.
Jak komuś się chce, to może to zgłosić, jeżeli nie - cóż, jak mówię, nie jest to w absolutnie żaden sposób bug zasługujący na cokolwiek innego niż krótką wzmiankę.

Przy okazji, @Cezary, czy mógłbyś proszę zmienić tytuł na 'Bug w AR724X/AR933X'?

Pozdrawiam,
R.Ł.

3 Odpowiedź przez Królik

  • Skąd: Warszawa
  • Zarejestrowany: 2015-07-10
  • Posty: 1,106

Odp: Bug w AR724X/AR933X

Rozważ sobie to wszystko na poziomie L2 a nie vlanów. Nie może być tak, że ruch  tego samego MAC wpada z kilku dziurek na raz. I na tym polega cały problem. Nie masz tablic w układach SOHO, które są przystosowane do takich cudów.

Ja bym tego bugiem nie nazwał, tylko cechą.

Mam i używam: Fujitsu Futro S720, Netgear R6220, Unielec U7621-06, TP-Linki 1043 V1, V2, Linksysy EA7500v2, AeroHive AP350, Linksys EA8500, ZTE MF286d.
Mam: D-Linki DWR-921, DWR-118, DWR-116, TP-Link WDR-4900 v1, Checkpoint L-50, Linksysy 1900ACS, LB-Link BL-W1200,

Królik's Strona

4 Odpowiedź przez MrCiek4wski

  • Zarejestrowany: 2017-08-22
  • Posty: 64

Odp: Bug w AR724X/AR933X

Królik napisał/a:

Nie może być tak, że ruch  tego samego MAC wpada z kilku dziurek na raz. I na tym polega cały problem.

Zgadzam się w 100%. Dokładnie ten fakt jest wykorzystywany w tym ataku, tyle że w przypadku utworzenia vlanów powinny być traktowane jak dwa oddzielne zbiory dziurek. Nie są, stąd problemy, brak możliwości bridgowania i możliwy DoS. Rozważenia poziomu l2 bez vlanów zajęły mi cały paragraf, nie wiem jak mogło Ci to umknąć...

MrCiek4wski napisał/a:

Byłoby to wyjaśnieniem dziwnego wyglądu arl: zastanówmy się co by było, gdyby switch miał wyłączoną obsługę vlan. Gdyby switch dostał 2 takie same pakiety z 2 takimi samymi adresami src na 2 różnych portach, to by zgłupiał: coś takiego w topologii ethernet nie powinno mieć miejsca. Jedynym *sensownym* wytłumaczeniem takiego zjawiska jest przepięcie komputera z jednego portu do drugiego. Z tego powodu, biorąc pod uwagę kolejność występowania naszych przesyłanych pakietów, lądują one w porcie 0 i nie są przekazywane do portów 1 i 2, bo switch uznał, że komputer został przepięty właśnie na port routera, gdy router z kolei po prosu wysyła forwardowany pakiet. Stąd brak komunikacji unicast. Broadcast nie potrzebuje mapowania, więc nie ma go w arl, bo wysyłany jest wszędzie.

Królik napisał/a:

Nie masz tablic w układach SOHO, które są przystosowane do takich cudów.

Czy mógłbym prosić o wyjaśnienie, bo nie rozumiem? W sensie nie przystosowane do tworzenia niezależnych tablic dla vlanów? Jeżeli tak, to jakim cudem Archer D7 (i zapewne multum innych urządzeń) właśnie w swconfig zwraca taką tablicę?

Nie rozumiem w jaki sposób jest to cecha gdy z jednego vlanu możesz spowodować zakłócenie działania drugiego vlanu właśnie na poziome l2... Przecież po to są vlany aby na tym poziome delikwentów izolować...

Jeżeli uważasz, że coś takiego nie jest możliwe, to w takim razie napisz swoje zdanie na ten temat, właśnie po to opisałem ten problem dogłębnie aby ktoś z większą wiedzą mógł to potwierdzić albo zaprzeczyć i wyjaśnić co ja zorbiłem źle, że coś takiego się dzieje.

5 Odpowiedź przez Królik (edytowany przez Królik 2020-07-10 12:58:10)

  • Skąd: Warszawa
  • Zarejestrowany: 2015-07-10
  • Posty: 1,106

Odp: Bug w AR724X/AR933X

Atherosy, które przytoczyłeś w temacie mają bardzo proste switche L2, które umożliwiają jedynie filtrowanie a nie izolowanie vlanów. Dlatego jest jedna tablica ARPów z informacją jaki MAC na jakim porcie siedzi i tablica vlanów z informacja które puszczać a które obcinać na danym porcie, ew. jaki tag dodawać lub usuwać. Opisałem właśnie większość jego możliwości. Dlatego nie możesz robić bridge na vlanach, bo switch nie rozumie co się stało z tym pakietem i dlaczego ten sam mac występuje jako źródłowy na innej dziurce. Rozpatrywanie takich scalaków powyżej L2 nie ma sensu.

Nie wiem za to co dokładnie siedzi w QCA9558, który jest układem w D7. Być może ma bardziej rozbudowane możliwości. W droższych rozwiązaniach można izolować porty i wtedy tablice są rozłączne.

Mam i używam: Fujitsu Futro S720, Netgear R6220, Unielec U7621-06, TP-Linki 1043 V1, V2, Linksysy EA7500v2, AeroHive AP350, Linksys EA8500, ZTE MF286d.
Mam: D-Linki DWR-921, DWR-118, DWR-116, TP-Link WDR-4900 v1, Checkpoint L-50, Linksysy 1900ACS, LB-Link BL-W1200,

Królik's Strona

6 Odpowiedź przez MrCiek4wski

  • Zarejestrowany: 2017-08-22
  • Posty: 64

Odp: Bug w AR724X/AR933X

Ok, dziękuję za wyjaśnienie. Czyli jednak to co napisałem jest prawdą, bo ten switch ma po prostu niekompletną implementację vlanów, co by oznaczało, że korzystanie z nich na tym switchu nijak ma się do bezpieczeństwa, co gorsza - włączenie tej funkcjonalności tylko bezpieczeństwo obniża (atak jw.). Tak więc, izolacja klientów kablowych w tym Atherosie bądź np. doprowadzanie dwóch sieci wlan przez tagowanie powinno być unikane, chyba że utrata połączenia nie jest problemem.

Ciekawe czy jeszcze jakieś modele low-end od Atheros czy Mediatek mają takie kwiatki...

R.Ł.