A VPNFilter nagy számú routert fertőzött meg világszerte

Két hete az Ars Technica megírta, hogy körülbelül 500 ezer routert fertőztek meg az orosz kormánynak dolgozó hackerek egy VPNFilter nevű kártevővel. Akkor úgy gondolták, hogy a kártevő célja az, hogy az otthoni routereket és hasonló eszközöket botnetként használva támadásokat indíthassanak a valódi célpontok ellen.

Tegnap viszont kijött egy új cikk, ami azt írja, hogy a szituáció rosszabb, mint korábban gondolták.

A Cisco kutatói bejelentették, hogy a malware többet tud, mint ahogy korábban gondolták, és szélesebb az érintett eszközök köre.

Az egyik új funkció, amit az elmúlt két hétben fedeztek fel az az, hogy a malware a routeren futva man-in-the-middle módon belehallgat a kommunikációba, és meg is tudja változtatni azt, így pl. weboldalak által küldött adatok egy részét megváltoztathatja, ami aztán a felhasználó böngészőjében eredetinek tűnik.
Emellett persze a kártevő frissen felfedezett modulja igyekszik kigyűjteni az érzékeny adatokat a titkosított kommunikációból, pl. ha talál jelszavakat, azokat kimásolja és elküldi a gazdáinak. Hogy megkerülje a TLS titkosítást megpróbálja a HTTPS kapcsolatokat titkosítatlan HTTP-re lerontani.

Ezek alapján úgy tűnik, hogy a kártevő nem más célpontok támadására használja a megfertőzött eszközöket, hanem ezeknek az eszközöknek a használói, jellemzően a tulajdonosok és ezek családjai a célpontok.

És ugyan sok olyan szervezet van, amelyek megkövetelik a titkosított kapcsolatot, de Ukrajnában, ahol nagyon sok a fertőzött eszköz, ez nem jellemző, és az USA-ban és Európában is számos olyan weboldal van, amik a HTTPS-t nem támogató kliensek miatt hajlandóak titkosítatlan kommunikációra.

Az újabb Ars Technica cikk közepe felé van egy hosszú lista az kártevő által sikeresen támadható eszközökről. Az elmúlt két hétben fedezték fel, hogy az ASUS, D-Link, Huawei, Ubiquiti, UPVEL, és ZTE egyes eszközei is támadhatóak, a korábban felfedezett Linksys, MikroTik, Netgear, és TP-Link mellett.

A becslés szerint a korábbi 500 ezerhez képest még 200 ezer eszköz lehet kitéve a fertőzés veszélyének globálisan.

Az Index cikke szerint egyes eszközöket az Invitel és a Telekom használta, szóval Magyarországon is lehetnek fertőzött szolgáltatói routerek háztartásokban.

Jelenleg nem ismert, hogyan fertőzték meg a routereket, de feltételezhetően foltozatlan biztonsági hibák kihasználásával.

A másik probléma, hogy nem lehet egyszerűen megállapítani, hogy egy router fertőzött-e.

Hozzászólások

Nem teljesen világos, hogyan fertözi meg a router firmware-ét? Valaki leírhatná tömören...

Nálam egy Huawei GPON HG850a van, bridge módban. Gondolom azon csak átmegy a forgalom, nem érintett. Emögött van egy Zyxel router, ami -elvileg- ugyancsak nem érintett.

--
robyboy

Itt leírták részletesen pár hete, amikor először hírt adtak róla:
https://blog.talosintelligence.com/2018/05/VPNFilter.html

Ebben pedig van egy (igaz régi) lista, hogy melyik routereket gondolják érintettnek:
https://arstechnica.com/information-technology/2018/06/vpnfilter-malwar…

a digi zte f668as routert adott, amit sehol nem láttam eddig a listákban. és ettől még messze nem vagyok biztos abban, hogy nem érintett...

"I'd rather be hated for who I am, than loved for who I am not."

nekem nincs bridge módban, így akár érintett is lehet. de a "mi router 3g" már a spájzban van, csak időmnek kellene lennie, hogy életre leheljem. akár gyári, akár custom firmwarerel.

amit olvastam a problémáról, ott azt írták nem tisztázott, hogy mi a terjedési módszere. de feltételezem, ha bridge módban van és nincs saját ip címe, kvázi kintről nem érhető el, akkor talán nem fertőzhető. talán. de ami inkább a bridge mód és saját router irányba visz, hogy eddig nem frissült a firmware benne, közben a világban meg látható, hogy vannak újabb és újabb problémák. amit nem javítanak, így irány egy olyan eszköz ami a saját kezemben van.

"I'd rather be hated for who I am, than loved for who I am not."

forrás elérhető, padavannál pont onnan kell fordítani ahogy levettem, hát szépen átnézem. de láttam van hivatalos lede/openwrt is, mir3g néven, ha esetleg bennük bízol.

vagy kiben, melyik rendszerben bízzak? melyik országot támogassam az adataimmal?

"I'd rather be hated for who I am, than loved for who I am not."

A "manyeyeballs" nem kötelező, hanem opcionális. A baj inkább a zárt forrással van, ahol a kód karbantartója baszik rá és másnak nincs esélye belenézni - illetve van, akit nagyon érdekel, az bele is fog, de ez jellemzően csak a sebezhetőségék csendes kihasználását eredményezi.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Nem tudni, hogy véletlenül, vagy direkt maradt-e benne, de ha a bizalmad ezen múlik, akkor nyugodt életed van! :)
Egyébként meg már nincs benne, lehet ezt emlegetni még egy pár évig mint egyfajta mindent vivő érvet, csak most már picit uncsi..

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Nem te levelezétl a nagypofájú, bunkesztánból szalajtott főgányolóval... Ilyesmit ("egy ügyfél kérésére raktuk bele ideiglenesen - ja, csak az első megjelenése óta a log alapján egy refaktoring/kódtisztítás is volt) értelmes kódkarbantartó nem csinál, vagy ha igen, akkor nem úgy, ahogy ő(k). Ha ilyen látható disznóság ott virított a kódban, akkor mennyi olyan volt/van még, ami nem ennyire feltűnő...?

Mivel akkor volt más 3rd party firmware, ami ilyen orbitális disznósággal nem volt terhelve, azt választottam, később meg már maga a 3rd party firmware is okafogyottá válta z adott eszközzel együtt, de ha most kéne választanom, akkor sem választanám azt, amivel anno ilyen rossz tapasztalatot sikerült szerezni.

Ez világos, csak azóta eltelt x-év, kijött egy rakat update, a kódban nincs benne az inkriminált tűzfal szabály. Lehet ezen rugózni napestig, csak akkor ugyanígy lehetne rugózni mindenen, ami egyszer az életben kompromittalodott és akkor a végén meg lehet visszaterni a fakerékhez...

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Amikor kiderül a levelezésből, hogy a vezető fő-fő-főfütyi fejlesztőnek halovány fingja sincs, hogy ilyesmi mikor, miért (és miért úgy, ahogy) és hogy került be a kódba, miért került bele csak a vpn-es buildbe, máshova meg nem (ifdef-fel nem volt körbepakolva...), és hogyan élte túl az adott forrásfájl többszöri átírását/alakítgatását (amit elvileg ő tolt fel a repóba), az még a debian openssl karbantartójának a balf...ságán is túlmutat.
Gondolom, ha a normál buildben jelent volna meg, akkor jóval nagyobb felháborodás lett volna belőle - szerintem ez volt a szerencséjük...
Az, hogy "azóta már nincs benne" az nem jelenti azt, hogy más, hasonló disznóságot hasonlóan trehány módon nem lapátolt bele valaki - minden esetre ez egy dologra biztosan jó példa: a töb szem többet lát openszósz érv lophact sem ér a valóságban, illetve fals biztonságérzetet nyújt - gondolom az inkriminált vpn-es buildeket (volt egy rakat, mire rendesen kipiszkálták a szemetet belőle) nem csak én töltöttem le/akartam használni - csak épp más nem nézte meg parancssorból, hogy mit is mutat valójában az iptables parancs kimenete, hanem megelégedtek azzal, amit a webes felület mutatott - ott meg hogy, hogy nem, ezek a bedrótozott szabályok nem látszottak...

Nyilván az ellenőrzési policy erossegetol függően kisebb nagyobb mértékben előfordul mindenütt balfaszkodas, ez viszont nem jelenti azt, hogy folyamatosan ez van, illetve hogy a zárt forrás esetében nem állna fenn ez a lehetőség (utóbbiban kisebb a felfedezés, javitas eselye). Ilyen alapon viszont akkor mi az, amiben meg egyáltalán megbizol?!..

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ha évekig(!) ott volt, akkor szerintem nem nagyon van értelme arról beszélni hogy "kisebb-nagyobb balfaszkodás", mert ez nem az. Pláne egy ópenszósz motyónál, ahol elvileg csillióan látják a kódot - látják, de nem nézik, ergo ilyen szempontból tök mindegy, hogy ópenszósz vagy sem, lehet, hogy egy hiba csak nagyon sokára bukik ki.

Szóval csak annyit mondtam, hogy olyan kódot, ami ilyen fejlesztőtől (szakmai és emberi hozzáállás egyaránt) érkezik/köthető, azt köszi, de nem, plusz ez is egy eklatáns cáfolata annak, hogy az opensource kód amiatt, mert sokan látják a forráskódot, az így generálódó javítások miatt biztonságosabb lenne. És nem, nem egy elhide-olt, trükkösen megoldott, a forrásba tökéletesen beleillesztett/formázott részlet csinálta, hanem egy rondán odapasszintott, a kód többi részétől formázásban is eltérő pár sor, amit a viccbeli takarítónéni is kiszúrt volna. (Gépészmérnökök fejvakarva tanácskoznak egy bonyolult berendezés rajzai fölött azon, hogy mi lehet egy működési probléma oka, mire jöna takinéni, és rábök a rajzon valamire, hogy az ott miért olyan ronda, mire a vezető konstruktőr a homlokára csap, hogy igen, az az alkatrész sz@r...)

Ha évekig ott volt, akkor ez nyilván azt jelenti, hogy kurvára senkit nem érdekelt, mert mondjuk triviális a megoldása. Ha a Windowsban van húsz éve javítatlan bug, akkor ugyanezen az elven azt se használod? Csak mertaa hiba felfedezése, kijavitasanak eselye ott azért sokkal kisebb, mint az említett peldaban.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

"Ha évekig ott volt, akkor ez nyilván azt jelenti, hogy kurvára senkit nem érdekelt, mert mondjuk triviális a megoldása."

Milyen triviális megoldása van egy bedrótozott tűzfal szabálynak, amit sehol sem látsz? Lehet van, csak kérdezem.

"Ha a Windowsban van húsz éve javítatlan bug, akkor ugyanezen az elven azt se használod?"

Ott kevésbé van alternatíva, mint mondjuk router szinten. Ez a Linux/BSD vonal problémája, hogy sok dologra nincs élhető megoldás. Valami helyette van persze, de azért ott egy kis keserű szájíz marad az emberben használat közben. Routertől függ persze, de ha dd-wrt volt rá, akkor jó eséllyel openwrt is volt, meg lehet akár tomato, stb. Tehát ha nem tetszik a dd-wrt, bármi miatt, váltasz, válthatsz.

"I'd rather be hated for who I am, than loved for who I am not."

"Milyen triviális megoldása van egy bedrótozott tűzfal szabálynak, amit sehol sem látsz? Lehet van, csak kérdezem."
- "iptables -L"-re neked mit adott ki?

"Tehát ha nem tetszik a dd-wrt, bármi miatt, váltasz, válthatsz."
- persze, viszont garancia akkor sem lesz, csak legfeljebb hamis biztonsagerzet...

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

egy része tudja mi az iptables, más része még parancssoros módba sem megy bele, hisz pont az volt az előnye az openwrt vonallal szemben, amikor a luci pluszban telepítendő volt parancssorból, hogy szép grafikus felület van null kilométertől, ahol minden meg tudsz oldani. nekem semmit nem adott ki, mert nem néztem. én már ez a történés előtt léptem dd-wrt vonalról. de magamtól eszembe nem jutna az iptables kimenetének a nézése, hogy hátha valaki egy szabályt bedrótozott amit nem látok a saját web felületén. persze jó lecke volt, most már tudod. de ha például az iptables is kicsit mókolt, hogy szűrje ennek a szabálynak a kiírását?

ha garanciát keresel, akkor más iparágat kell nézned... elég csak azt nézned hány olyan cég került ebbe a problémakörbe, akit idáig mindenki ajnározott. ők kaptak biztonságot? hát azt ezek szerint nem. egyébként igazad van, a váltás hamis biztonságérzetet ad(hat). ahogy windowsról linuxra/bsdre/osxre váltás is.

"I'd rather be hated for who I am, than loved for who I am not."

Aki 3rd party firmware-t hákol a routerére, az feltételezhetően tudja, mit csinál - ergo az iptables nem ismeretlen fogalom a számára. Aki windowst hákol a gépére, na ott ez még nem feltétlenül van így. Ki van nagyobb veszélyben? Kinek van nagyobb esélye a rejtett giftek felfedezésére?
"...a váltás hamis biztonságérzetet ad(hat). ahogy windowsról linuxra/bsdre/osxre váltás is."
- fordítva pedig ez még inkább igaz.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

"Aki 3rd party firmware-t hákol a routerére, az feltételezhetően tudja, mit csinál - ergo az iptables nem ismeretlen fogalom a számára."

lehet régen igaz volt, de manapság már azért barátságosabb. jellemzően felmész a firmware oldalra, van két állomány, egyik a gyáriról átálláshoz, másik a custom firmware frissítéshez, utána weboldalakon minden más beállítás, iptables tudás közelben sincs. pont ez (lenne) a gui lényege.

"I'd rather be hated for who I am, than loved for who I am not."

A "barátságosabb" nem azonos a "felhasználóbarát" kifejezéssel! Mancika továbbra sem fog 3rd-party firmwaret hákolni a szappantartójára, mert nem is érti ezt az egész dolgot - ha van webui, ha nincs! Aki meg tudatos, az tudja hogy miért teszi, tudja hogy mi a tűzfal és a cli. Egyébként egy olyan problémán beszélgetünk, ami már évek óta nincs, és nem is valószínű, hogy ezek után valaha is előfordul mégegyszer..

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

A triviális megoldás az volt, hogy bejelentkezés, iptables-sel törlés (mert látszott), de hogy honnan került oda, az csak a forráskódból derült ki - ott volt ugyanis belegányolva az iptables meghívása(!) adott paraméterezéssel. Ja, és persze újraindulás után ismét...

Windows-ban nem látod, itt elvileg látta csilliom ember, mégsem lett javítva - mert senkinek nem fájt, vagy mert senki nem foglalkozott valójában azzal, hogy mi van a forráskódban? Mindegy, volt alternatív megoldás, úgyhogy ez a motyó ment anno a kukába, és azóta sem éreztem ingerenciát arra, hogy újabbe sélyt kapjon, mert semmivel nem ad többet, mint más 3rd party firmware, illetve az elvárásoknak a mostani "gyári" firmware-ek is megfelelnek, még akkor is, ha nem látom a forráskódot, hiszen ez gyakorlatilag mindegy.

zitevnek is írtam, sokan azt sem tudják mi az iptables, csak a szép web guit látja, akarja látni, fantasztikus grafikonokkal. ahogy a windowsnál sem érdekli, hogy egy checkbox hány registrybejegyzést változtat.

igen, probléma és gáz, hogy ilyen bent maradhat sokáig egy elérhető kódú programban. de ugye ilyenre sok példa volt. ezért említik sokan gondolom ironikusan a manyeyeballs-t ilyenkor.

"I'd rather be hated for who I am, than loved for who I am not."

Ja. elég sok idő kellett hozzá, hogy kiderüljön... Ráadásul azt is benyögte a főfütykös, hogy nem is kéne benne lennie, meg hogy csak egy projekt miatt volt egy teszt verzióban. Ahol ilyen szinten kezelik a forráskódot, a buldeket, az egyedi ügyféligényeket (meg milyen üf. már az, aki bedrótozott, felületen nem látható szabáylokat igényel), ott más bajok is várhatóak.

Megkulonboztetnem a kereskedelmi céllal készült terméket a free / shareware projektektől, utóbbinál bocsanatosnak tartom, ha nem megy minden olajozottan, pláne ha a cegek a pénzért adott termekeikben, szolgaltatasaikban is ugyanúgy elofordulnak ilyen jellegű blamazsok szép számmal, és még fizetsz is érte!

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ezért is fizetett valaki, ugyanis ezt egy fizetős ügyfél kérésére rakták bele korábban, aztán "úgy maradt"... Mindegy, te bocsánatosnak tartod, hogy a hobbiprojektek péhápépistike-szinten működnek - ami egy darabig nem gond - de itt nem egy ilyen hobbiprojektről volt szó - szerencsére volt helyette használható másik (meg harmadik, meg n-edik).

Akkor sem gondolnám, hogy egy kalap alá lehetne venni a szoftver monopoliumok fejlesztő laborjaiban beepitett bugokkal, amik javitatlanul húsz évig dekkolnak a rendszerben, hogy aztán hirtelen kiszereljek belole, amikor már a fél világot beszopatták, hogy a résen fel alá koslatnak a különféle kartevok és nemzetbiztonsagi hivatalok.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

időfaktor. az elmélet az, hogy több tízmillió ember láthatja, nézi a kódot és az ilyet kiszúrják gyorsan. de ezek szerint az elmélet hibázik, mert hasonlóan a zárt forráshoz időbe telik amíg megtalálják. és a kérdés nem az, hogy megtalálja-e a manyeyeballs, mert meg fogja persze találni, hanem az, hogy gyorsan vagy sem. és hát pár példa van rá, hogy sajnos lassan.

"I'd rather be hated for who I am, than loved for who I am not."

Nincs "időfaktor", egyáltalán nem kell, hogy gyorsabban kiderüljön, hiszen nincs garantálva a kód folyamatos ellenőrzése a közösség által - kevésbé népszerű projekteket kevésbé ellenoriznek - de az esély a feltárásra még így is nagyobb, mint a zárt forrás esetében. Ha téged személy szerint érdekel a dolog, akkor megteheted, hogy belenézel és átvizsgálod, csak rajtad múlik!

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

"és azóta sem éreztem ingerenciát arra, hogy újabbe sélyt kapjon, mert semmivel nem ad többet, mint más 3rd party firmware, illetve az elvárásoknak a mostani "gyári" firmware-ek is megfelelnek, még akkor is, ha nem látom a forráskódot, hiszen ez gyakorlatilag mindegy."
- tehát inkább használod a gyári, "előkezelt", sokszor bugos, elavult, biztonsági résekkel teli firmwarerel. Jó...

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

"gyári, "előkezelt", sokszor bugos, elavult, biztonsági résekkel teli firmwarerel" - széép, szokásos ópenszósz-huszár FUD, köszönjükemese. Gyári firmware, rendszeresen frissül, és hogy van benne bug? Lehet. De _szándékosan_ belerottyantott sz@rkupcac nem igazán vérható - gondolj bele, hoyg egy _szándékos_ any/any befelé szabályt hordozó gyári firmware mekkora hatással lenne egy ezzel foglalkozó cég reputációjára?
Szóval igen, használom a gyári firmware-t, használom az eszköz valamennyi funkcióját, kihasználom azt, hogy PPPoE mellett közel gigabitet képes NAT-olni, estébé, estébé, estébé... Mindezt OOB, mindenféle hákolás-tákolás-reszelgetés nélkül úgy, hogy nem egy hobbiprojekt produktuma a szoftver.

> De _szándékosan_ belerottyantott sz@rkupcac nem igazán vérható

De, pl.: Huawei HG8245 backdoor and remote access The backdoor is a web management account enabled by default and the password cannot be changed. In this version the default administrator password is: *6P0N4dm1nP4SS* - via

Egy ilyen jellegű "hiba" opensource esetén elég nehezen tudom elképzelni, hogy bennemaradt volna.

A gyakorlat azt mutatja, hogy a gyártók jelenleg nem tartják fontosnak a biztonságot: https://www.search-lab.hu/advisories/secadv-20150720

vagy

> Cisco recently fixed a bug I reported in ASA, see: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/c…
> The root cause of the issue: URLs under /+CSCOE+/ require authentication. URLs under /+CSCOU+/ don't.
> So how to access /+CSCOE+/ without authentication?
> GET /+CSCOU+/../+CSCOE+/ HTTP/1.1

"Gyári firmware, rendszeresen frissül, és hogy van benne bug? Lehet. De _szándékosan_ belerottyantott sz@rkupcac nem igazán vérható - gondolj bele, hoyg egy _szándékos_ any/any befelé szabályt hordozó gyári firmware mekkora hatással lenne egy ezzel foglalkozó cég reputációjára? "

- a teljesség igénye nélkül:
https://securityaffairs.co/wordpress/20941/hacking/netgear-linkys-route…
https://dfarq.homeip.net/another-day-another-router-backdoor/
https://forums.malwarebytes.com/topic/139631-critical-backdoor-in-links…
https://news.ycombinator.com/item?id=9124232

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Két MikroTik router van napi szinten a látókörömben, de az utóbbi 2-3 hónapban legalább 3-4 alkalommal jött ki rájuk frissítés. Legutóbb talán egy hete vagy 10 napja.
Jelenleg a 6.42.3 verzió van rajtuk.
A changelogs-ban viszont név szerint nem találok utalást a javításra.
https://mikrotik.com/download/changelogs
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

A felsorolt routerek típusán kívül mi még a támadási vektor további (ismert) összetevői? Az 1043nd V1 nincs a listán, és DD-WRT -m van.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

nagyon kodos az egesz.
Nem ertem, hogy ha a router nem hozzaferheto kivulrol (mert az osszes csilivili loszar ki van kapcsolva, mint upnp, http server, ftp server, blabla), akkor hogyan tornek be ra?

Egyik lehetőség: Nincs kikapcsolva kívülről a router admin felület elérhetősége. Rövid scan után nem volt nehéz ilyet találni Pl.: http://188.143.73.53/, http://84.236.44.189/, https://84.236.44.189:80/.

A másik lehetőség, hogy egy oldal megnyitása után pl. javascripten keresztül pl. ajax-al próbálkozik. Mivel ugyanabba a subnetben vagy, így a 192.168.1|0.1-el nagy valószínűséggel elérhető a router.
És mivel pl. a nálunk is eléggé népszerű videostreaming oldalak bármilyen third party javascriptet beinjektálnak, így nem nehéz jelentős mennyiségű gépre/mobilra eljuttatni egy ilyen scriptet.

Így lehet akár custom user/password is a routeren, ha bejelentkeztél a legutóbbi böngésző restart óta.
Most próbáltam és random weboldalon ezt a scriptet lefuttatva módosítani tudtam a routerem beállítását:
(new Image).src = "http://192.168.1.1/userRpm/SystemStatisticRpm.htm?Staton=Enable&interval=10&sortType=5&Num_per_page=5&Goto_page=1"

Úgy gondolom, hogy ha coinminer scriptet raknak az oldalba, akkor valószínű bármilyen más adnetwork (álcázott)hirdetéseit is engedni fogják.

Elég sok adnetwork enged custom javascriptet a hirdetésben illetve ezeken az oldalakon elég népszerű a popup dolog is, ahol még az esetleges iframe sandboxing se véd meg.

Csak próbából rákerestem a cikk által említett moovie.cc által használt egyik adnetworkre (onclasrv.com) és a google első találatként egy olyan reportot jelentett ahol egy olyan oldalra irányította az usert ami vírusírtónak álcázott appot telepített (volna) fel: https://android.stackexchange.com/questions/152402/pop-ups-in-chrome-tr…

> végül ez le lett redukálva egyetlen oldalra

A többit nem néztem (nem használok ilyen oldalakat), de feltételezem hasonló a helyzet.

A flash visszaszorulása után html/js/css-ben próbálják ugyanazt a hatást elérni, így a legtöbb adserver lehetőséget ad scriptek futtatására a befogadó oldalon. pl. a nálunk legnépszerűbb adverticum is

A másik lehetőség

Trükkös, de kicsi rá az esély szerencsére. Ez a router 1 perc inaktivitás után kiléptet. Kéne hozzá, hogy ugyanarról a gépről menjen a video streaming, mint amiről a routert piszkálom: ilyen sem nagyon történik szerencsére.

Esetleg harmadik lehetőségként el tudok képzelni egy remote code exec exploitot admin felület nélkül is.

https://www.shodan.io/search?query=port%3A80+country%3Ahu+org%3A%22DIGI…

Ez alapján 38,884 nyitott porttal rendelkező host van csak a digi hálózatán. Random végigkattingatva ennek 80+%-a Huawei HG8121H router configjára vezet.

(Amúgy akár lehetne keresni exakt sevezhetőség CVE alapján is, de 1USD/hónapos VPS-ek világában enélkül se lenne nagy kaland)

"Két hete az Ars Technica megírta, hogy körülbelül 500 ezer routert fertőztek meg az orosz kormánynak dolgozó hackerek egy VPNFilter nevű kártevővel. "

A felkover reszre megis hogyan jottek ra?

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

gyorsan kisakkozták, hogy kinek lehet a leginkább érdeke! :) viccet félretéve, a metódus és a scriptek felépítésének mintázata erősen hajaz korábbi, már egyértelműen az orosz állam által működtetett ciber-hadtest munkásságára.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

"A másik probléma, hogy nem lehet egyszerűen megállapítani, hogy egy router fertőzött-e."

Itt a csóka a következőt írja pl. az Asus esetében:

"This is the most technical article I could find

https://blog.talosintelligence.com/2018/05/VPNFilter.html

Quick Overview

1) Affects many router manufactures, ASUS included, but only a small subset.
Keep in mind that it is not confirmed if the listed ASUS subset is exhaustive

2) Method of infection is currently unknown

3) After infection malware can be found in

--Stage1 infection: cron task OR nvram variable
--Stage2 infection: /var/run/vpnfilterm or /var/run/vpnfilterw
--Stage3 infection: bricked router

--

TLDR

Check cron, nvram, and filesystem for potential inection

Infects many routers, but the attackers are choosing only high value targets for data interception/exploitation "

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

További adalék, hogy pl sokan nem frissítenek ubiquiti poe-s switchet/routert, mert a poe törött néhány upgrade-nél. Vagy működnek az eszközök, vagy biztonságosak. Sok helyen vajh visszakapcsolták-e ezek után az autoupdate-et...? Unifi NVR hasonszőrűen, de azt ideális esetben úgyis airgappeli az ember, ha lehet. Vajh hány helyen van normális, felügyelt upgrade, és hány helyen egyszerűen kikapcsolják a firmware autoupdate-et, más gyártók eszközein is, mert voltak problémák, és nincs erőforrás a kontrollált, rendszeres, elfogadható időn belüli upgrade-re. Egyébként pedig vajon mennyi delay elfogadható a gyártói upgrade tesztelésére...

Synology router és NAS. Szerencsére egyik sem érintett. A legutóbbi bakijukkor kb másfél éve megjelent update-et fel nem rakó közösség adatait kódolták le illetéktelenek. Azóta az xpenology is fejlődött.

Epp itt a HUP-on lettem par honapja kirohogve, amikor arrol lamentaltam, hogy mekkora baromsag, hogy a T-Home nem engedi a Home Gateway szabad kivalasztasat a szabvanynak megfelelo eszkozok kozul, hanem kapok egy outdated dzsunka fost (az eszkozfuggetlenseg Nemetorszagban pl. torvenyben rogzitett joga az elofizetonek).

Kivancsi lennek, hogy azok akik ennyire vakon biztak, akkor a T-ben, most mit tippelnek, mennyire reszletesen lesznek tajekoztatva az ugyfelek, hogy kitudja mennyi ideje vannak mar a spajzban az oroszok, es mikorra szuntetik meg ezt az aldatlan allapotot...

A szabadon választott eszköz is lehet zaccos ez az egyik. A másik, ami lényegesebb, az az, hogy a minőségi célértékek mérését a szolgáltatásátadási ponton kell garantálni (rendelkezésre állás, sávszélesség, stb.), ami _nem_ a homegw szolgáltató felőli interfészébe érkező kábel vége, hanem a gw ügyfél felőli oldala.
Ha a gw-t az ügyfél választaná/adná, akár egy "használható eszközök" listából, akkor bármilyen hiba esetén rá lehetne tolni a gw hibájára (konfig, sw-verzió, hardver) a problémát - az üf. meg hívhatna adott eszközhöz szerelőt saját maga, merthogy az már _nem_ a szolgáltató felelősségi köre, ami a pőre kábel végére van dugva.

Azért a listában szereplő Telekomos HG8245-n nem a default admin van (ezért figyel a DT_HUNGARY customization ;)) Még normális shell sincs rajta (vagyis valószínűleg csak tiltva van) :(


root@192.168.100.254's password:

WAP>su
success!
SU_WAP>shell

BusyBox v1.18.4 (2016-08-25 14:33:08 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

profile close core dump

WAP(Dopra Linux) # ?
exit
getcustominfo.sh
WAP(Dopra Linux) # exit

success!
SU_WAP>quit
success!
WAP>quit
success!
WAP>
Configuration console exit, please retry to log on
Connection to 192.168.100.254 closed.

Mondom: a 80 millios Nemetorszag elmukodik ilyen problemas viszonyok kozepette is. Milyen jo, hogy itt mi Magyarorszagon ilyen jol meg vagyunk vedve... Ne nevettess.

0. Egyreszt az egesz ervrendszered azon a hamis felvetesen alapul, hogy igy nem tudja a szolgaltato rad tolni a felelosseget, ha baj van. Mindig lesz egy pont, ahol az o felelosseguk veget er, es ha akarjak, akkor most is mondhatjak azt, hogy szar az en patch kabelem, az en switchem az en desktop gepem, az en os-em, vagy en vagyok segghulye.
1. A szabalyozasnak eppen az a lenyege, hogy rendes (allami intezmeny altal megadott) szabvanyok szerint kell szolgaltatni, ami azt jelenti, hogy nincs sunyulas. Csak egy pelda, a gazszolgaltato sem szabja meg nekem, hogy milyen kazant hasznalhatok, megmondja, hogy milyen nyomassal, milyen osszetetelu gaz jon, a gyartok meg epitenek megfelelo gepeket. A jelenlegi helyzet azzal lenne analog, ha a gazszolgaltato azt mondana, hogy csak akkor ad gazt, ha azt a 20 eves nyilt egesteru atfolyos FEG kazant hasznalom, amit o ad. Es az egesz biztonsagi kockazatat es koltseget meg viseljem en.
2. Nincs "hasznalhato eszkozok listaja". Az egyik oldalon a szolgaltato adjon egy standard szerint, a masik oldalon a keszulek meg ertse meg a standard-et (esetleg minosittesse az eszkozeit). Ha vita van, akkor gondolom a nemeteknel meg jon a "Bundesinstitut of Netszolgaltatas" es megmondja, hogy ki benazik.

De igazabol tenyleg teljesen felesleges a szajtepes: lenyegeben ugyanez a ceg 2 orszaggal arrebb kepes ertelmesen mukodni, itt csak azert allhat igy a dolgokhoz, mert egyreszt az allamnak valamiert nem fontos, hogy normalis infrastrukturat taposson ki a szolgaltatokbol. A szolgaltato meg magatol igenytelen, tohonya, nemhozzaerto.

A németeknél nem tudom, hogy van, amikor az ügyfél saját végberendezése sz@r, és amiatt pampog, amiatt nem megy neki valamilyen szolgáltatás - gondolom első körben nem a szolgáltatót, hanem a saját dobozának a szervízét hívja első körben. Vagy pedig nincs olyan szintű rendelkezésreállási célérték, mint idehaza.
A szolgáltató itthon mondhatja, hogy a gw-ig nem lát problémát, azon túl a te dolgod megoldani a problémát - a németeknél meg annyit tud mondani, hogy ő biza belevillogja az üvegbe a jelet, a többit meg kend a hajadra.
nagyon nagy esély van arra, hogy a vonatkozó jogszabályok jelentősen eltérnek a két országban, és emiatt _kell_ máshova rakni a szolgáltatásátadási pontot. A németeknél lemondtak a végberendezések központi felügyeletéről/menedzsmentjéről, cserébe az üf. veszi a dobozt (két legyet egy csapásra...), itthon meg a szolgáltató fizeti/fenntartja a központi felügyeletet, és ő veszi meg a gw-t is. Ha belegondolsz, a német megoldás üzletileg a szolgáltatónak olcsóbb, nehezen hihető, hogy ne lennének egyéb korlátozó tényezők,a mik miatt nem mennek ebbe az irányba.

"a gazszolgaltato sem szabja meg nekem, hogy milyen kazant hasznalhatok" - rossz példa, engedélyes mérnök tervezheti a hálózatodat/eszközödet, a szolgáltató által elfogadott tervet megfelelő jogosultsággal rendelkező kivitelező valósíthatja meg, amit aztán a szolgáltató műszakilag átvesz, és utána rakja fel a nyomásszabályzót és a mérőt.
A másik hiba ebben a példában az, hogy a gáz, mint energiahordozó az, amit eladnak neked, aminek a minőségét a szolgáltatói oldalon gyakorlatilag bárhol lehet vizsgálni - nyomásszabályzót és fogyasztásmérőt viszont nem hozhatsz a sarki épületgépész boltból, csak az kerülhet beépítésre, amit a szolgáltató ad, mert a hálózata a fogyasztásmérő ügyfél felőli kivezetéséig tart.

itthon meg a szolgáltató fizeti/fenntartja a központi felügyeletet, és ő veszi meg a gw-t is.

Központi felügyelet. XD


host cpemanagementt-comhu7003cwmpWebCPEMgt
Host cpemanagementt-comhu7003cwmpWebCPEMgt not found: 2(SERVFAIL)

A test username az meg mit ne mondjak , magában baromi komolynak tűnik ezen a szinten. :D

Ajanlott olvasmany: https://www.cio.com/article/3101864/consumer-electronics/new-law-lets-g…

"What are the advantages of using your own router?

There are many, here a few:

1. People can make a step forward to control their technology. The router is the gatekeeper of our homes, tunneling valuable information like emails, surfing behavior, phone calls or chats. It is important that users are able to choose a device that they can trust, that suits their requirements, has any features they need (and also not far too many). In this respect it is even more important that users are in a position of running free software on these critical devices.
2. Default routers had many security issues in the past and people weren't able to fix these themselves or to use another, more secure device. Now customers can choose devices that support modern security standards, have longer update cycles or hand out patches faster.
3. Up until now providers often just cared for cheap prices of their default routers. Now customers can also set other priorities like eco-friendliness or power cost savings.
"

En tudok egy negyediket is (ami 3.-nak volt a kovetkezmenye). Vannak olyan nemet router gyartok, akik nem a low-cost kategoriaban voltak erosek (AVM, Thompson, ...), nem akartak 100%-ban bebukni a legnagyobb europai piacot (ami raadasul hazai terep nekik) egy-ket balfasz tohonya ISP miatt. Es hidd el ezek a gyartok kezuket labukat torik, hogy az altaluk eladott routerek oob menjenek a nemet haztartasokban. A nemet magazinok fenereszletesen tesztelik ezeket a szarokat evrol-evre. Es a szolgaltato meg mindig adhat valami dzsunka szart, ha te dzsunka szarra vagysz, es az tutiezerszazalekra oob megy, megha szarul, bugosan, sechole-osan.

Lathatoan nem akarod megerteni a szituaciot. A gazos peldanal csak azert vannak ezek a megkotesek, mert a gaz maga veszelyes uzem. Az informatikai infrastruktura nem az. Barki fel tud szerelni egy routert. FYI: a Telekom is sok esetben csak kikuldi a dobozt egy A4-es beuzemelest segito lappal. Anyukam meg tudta csinalni magatol, pedig o aztan teljesen antitalentun. De hogy akkor en is hagy legyek ertetlen: letezik az egyszerusitett keszulekcsere, ahol a gazmuvektol senkit sem kell kihivni, csak egy jogosult szerelo elvegzi a keszulekcseret es mehet minden a maga utjan, csak egy lepecsetelt papirt kell bevinni hozzajuk.

Tovabba nem vagyok kisegitve a Telekom szakertelmevel. Fokeppen azert mert nincs nekik olyan. Mivel mindenre az a default munkamenet, hogy inditsuk ujra a routert, ha ugy sem megy a buli (esetek 99%-a), akkor kikuldenek egy kollegat (minek???). A masodszintu szupportost kellet gyozkodnom (alapjaban veve birkaturelmem van ezekkel, de majdnem elszakadt a cerna), hogy ne kuldjon ki kollegat, mert csak annyi a bajom, hogy megint NAT moge tettek es azert nem tudok haza SSH-zni. Szoval az, hogy le tud kerdezni "valamit" a HGW-bol, az lathatoan lofaszt sem er. Nagyon erdekelne, hogy milyen minosegu az a support dontesi fa, ahol a: van net kifele + Telekomon kivulrol nem pingelheto a HGW = hardveres problema. lol.

"A szolgáltató itthon mondhatja, hogy a gw-ig nem lát problémát, azon túl a te dolgod megoldani a problémát - a németeknél meg annyit tud mondani, hogy ő biza belevillogja az üvegbe a jelet, a többit meg kend a hajadra."
No ha a szolgaltato bevillogja a jelet a csobe, akkor maris lehet hivni egy szakit, aki megmondja, hogy az a jel megfelel-e az eloirt szabvanynak (es vegtelen lehet a sora azoknak az eszkozoknek, amik ezt merik es igazoljak). Amugy meg kenyelen vagyok elhinni a T remek szupportosanak (felkeszultsegi szintet lasd fent), hogy minden rendben van, de semmilyen komolyan veheto keresztprobat nem tehetek es nem ketelkedhetek.

"a gaz maga veszelyes uzem. Az informatikai infrastruktura nem az" - vagy inkább másképp veszélyes.

"letezik az egyszerusitett keszulekcsere, ahol a gazmuvektol senkit sem kell kihivni, csak egy jogosult szerelo elvegzi a keszulekcseret es mehet minden a maga utja" - tipusazonos berendezés/csilliom egy egyéb feltétel teljesülése esetén.

"Telekom szakertelmevel. Fokeppen azert mert nincs nekik olyan" - szerintem szívesen tanulnának tőled, add be a jelentkezésed szakértelmi főfőfőmufti posztra - de elég, ha munkautasításokat tudsz jót írni oyanoknak, akiknek tényleg semmiközül a szakmához, viszont CC-be beültetni be lehet őket.

"letezik az egyszerusitett keszulekcsere, ahol a gazmuvektol senkit sem kell kihivni, csak egy jogosult szerelo elvegzi a keszulekcseret es mehet minden a maga utja" - tipusazonos berendezés/csilliom egy egyéb feltétel teljesülése esetén.

15+ eves Ferolli nyilt egesteru kazant csereltek az alberletemben, vadiuj Ariston kondenzacios kazanra, ment az egyszerusitett keszulekcsere.

25+ eves FEG kazant csereltek, vadiuj Viessmann beepitett tarolos kondenzacios kazanra a lakasomban. En vittem be a papirokat a gazmuvekhez (nincs semmi ismerosom arrafele), semmi problemat nem okozott. Mindket helyen volt kemenybeleles is. Ennek ellenere se gazterv nem kellett, a gazmuvek nem akadekoskodott...

Maradjunk annyiban, hogy az a "csilliom egyeb feltetel" nagyjabol annyi (mielott elkezdenel rugozni, itt elorebocsatom, hogy egyszerusitessel elek), hogy kb. 30kW alatt maradsz (nekem 87nm-es nagy belmagassagu lakast vidaman kifut a 19kW-os Viessmann + csinalja a melegvizet) es nem alakitod at a vezeteket. Ez lefedi a lakossagi keszulekcserek jelentos reszet (egyedul az log ki, amikor lakasatepitesnel teljesen mas helyre kell vinni a gazorat vagy a kazant).

A tobbid az meg mero szemelyeskedes, kar vele foglalkozni, ervelj ha tudsz vagy passzolj. Ertsd meg, hogy a telekom (nem jar a nagybetu) jelenleg telepitett infrastrukturaja egy csomo problemat okoz nekem. Csak azert kell itthon tartanom egy debian + dnsmasq szervert, hogy a mindenfele eszkozok nevvel kepesek legyenek latni egymast. A dyndns tamogatas csapnivalo a HGW-n. A wifi minosege pocsek es nem tamogatja a wlan mesh-t (az AVM modememnek tavaly jart le az 5 eves garija es tudja ezeket!). A HGW webinterfesze valahol a 10 evvel ezelotti szinten ragadt. Nem a HGW hibaja, de idorol idore (1-2 havonta) bepakolnak NAT moge es az ugyfelszolgalaton baromi maceras elintezni, hogy visszategyenek (az elso szintu support nem tudja, hogy mi van, a masodik szintu volt, hogy letagadta, nekem kellett erolkodnom, hogy vegyen fel hibajegyet, hogy aztan napok mulva oldjak meg a helyzetet). Szerinted mi a helyes magatartas ilyenkor? Jaigen, nem valaszthatok mas ceget, mert itt csak telekom van (8. kerulet). Igenis minden lehetseges forumon ervelni probalok azert, hogy a ceg valtoztasson a gyakorlatan, mert ez az en szememben nagyjabol a monopolhelyzetbol fakado igenytelenseg/beleszaras minositett esete. Es ha nem kezd el hangoskodni az, akit ez zavar (es zavar masokat is tudom, te is lathatod a mindenfele forumokon ha kicsit utanaolvasol), akkor ez meg nagyon sokaig problemakat fog okozni.

Es ha lehetne egy javaslatom (ingyen adom, nem kell felvenniuk a fo-szakertoi statuszba). Torodjenek azzal, hogy az alkalmazottaik tanuljanak es fizessek meg oket. A tamogato munkatarsak ertsenek ahhoz, amit tamogatniuk kell vagy asap kapcsoljak az ugyfelet olyanhoz, aki tud segiteni. Sajnos jelenleg nagyon rosszul csinaljak, amit csinalnak. Es nem vagyok alapjaban veve elegedetlen tipus, legtobb telefonos ugyfelszolgalattal egesz jol szot szoktam erteni (bankok, biztositok, kozmuvesek, stb.). Valahogy a T-nel mindig belefutok a kesbe.

"A szolgáltató itthon mondhatja, hogy a gw-ig nem lát problémát, azon túl a te dolgod megoldani a problémát"

ez most is így van. tegnap egy L2 azzal hajtott el, hogy ő rámért a vonalra, az rendben van. úgy, hogy az eszköz az övé, se akarata, se ideje, se eszközkészlete (?) arra, hogy diagnosztikát futtasson, mi és miért hal meg a kommunikációban random időközönként. mivel zárt a router nekem sincs lehetőségem a debuggolásra.

arra jutottunk, hogy az ipv6ot kikapcsoltuk és most várjuk, hogy megint produkálja a hibát. nade ez így nem megoldás, hogy kikapcsoljuk a szolgáltatást, bízva abban, hogy attól majd jobb lesz. évek múlva a kötelező átálláskor/visszakapcsoláskor majd abban fogunk bízni, hogy a hiba magától megoldódott és minden jó lesz? nevetséges.

A német szabad eszközválasztás nem hülyeség, itthon is működhetne bizonyos megkötésekkel. Azt kellene megkövetelni a szolgáltatóktól kötelezően, hogy a kábel-netes és optikai-netes végponti eszközeik olyanok legyenek hogy bridge módba lehessen mindet állítani és működjön mellette az IPTV. Azaz legyen az eszközökön két külön hálózat, egy az IPTV-nek, egy pedig a netnek ez utóbbit pedig bridge módba lehessen kapcsolni, hogy az ügyfél a saját routerét használhassa mind kábel mind optikai netnél. Odáig szerintem nem kellene elmenni hogy az ügyfél maga válassza ki és szerezze be az optikai/kábel modemet, mert ez tényleg káoszhoz vezetne, de a kötelező bridge mód lehetőségének előírása, az IPTV működőképességének megtartása mellett, egy értelmes szabályozás lenne szerintem.

A zípétévét el kéne felejteni a 3.14csába: hány kereskedelmi forgalomban kapható vevőkészülék támogatja? Ja,hogy szolgáltatónként egyedi customized fos mind? ott van a DVB-C, azon is lehet _szabványosan_ hozzáérés-kontrollt csinálni - igaz, azt nem fogja látni a szolgáltató, hogy mikor, mint néztél.
Optikán beesik a net meg a DVB-C(+analóg) TV stream, net optikán tovább, a TV-be menő jelfolyam meg ott figyel egy F-csatin, amire olyan szabványos motyót kötsz, amilyet scak akarsz - nem lenne ez jobb...?

Természetesen életszerű törvényi szabályozás kell, amelyik szolgáltató jelenleg is nyújt dvb-c + bridge módot, annak nem kellene lecserélnie végponti eszközeit (Digi + néhány kisebb szolgáltató), amely szolgáltató csak Iptv vel rendelkezik és csak körülményesen vagy egyáltalán nem oldható meg a bridge mód, vagy csak úgy ha repül a tv szolgáltatás, (tipikusan a Telekom ilyen) azt a szolgáltatót bizony kötelezném törvényileg hogy olyanra cserélje a végponti eszközeit amelyen két külön hálózat van, egy az iptv-nek egy az internetnek, és ebből az internetest bridge módba lehessen rakni. Amennyiben esetleg a jövőben a digi is áttérne iptv-re akkor rá is vonatkozna ez a törvényi szabályozás. Persze el lehet gondolkodni olyan törvényen is amely a kábel/optikai szolgáltatókat dvb-c re kötelezi, de ez jóval költségesebb a szolgáltatóknak, és nem is biztos hogy keresztül lehetne rajtuk verni.

" a jövőben a digi is áttérne iptv-re " - szinte biztos, hogy nem fog, mert rengeteg plusz eszközre van hozzá szükség, mivel a végberendezést neki kellene adnia a szolgáltatáshoz, illetve az egész iptv infrastruktúrát összerakni sem két fillér. Sőt. Azt, hogy a DVB-C költségesebb lenne a szolgáltatóknak, azt nem igazán hiszem.