Pokud je uvnitr routeru treba linuxovy kernel, tak i po osekani je to sakra komplexni vec.
Spis jde o to jak je vyvoj kontrolovan,sledovan a testovan. Jakym zpusobem se hlida komplexita. U kritickych veci uz s americkym result oriented pristupem nepochodite. A neni tam ani mozne plne aplikovat agilni metodiky. Tam je i lepsi kdyz se to trochu zdrzi, nebot sankce za dodani spatneho reseni byvaji vyssi nez za nedodani k terminu. Jsou totiz na to navazane dalsi veci - pojisteni - audity - spadle letadlo/mrtvy pacient/satelit na kasi.
Ja kdyz vidim jak se vyviji software ve vetsine firem, tak na mne jdou mrakoty. A u low cost zarizeni jako je router to nebude lepsi.
Zjistil jsem ze narozdil od sysadministratoru programatori proste miluji bordel a mysli si ze podle jejich bordelu pujde zbytek projektu. Manazeri jim svou neznalosti jeste prizvukuji. Ten bordel je na vsech urovnich. Od dodavatele devkitu po final assembly.
0) Chybejici standardizovane build prostredi, nejsou maintaineri jednotlivych komponent. Nikdo nekontroluje aktualizace jednotlivych casti. Manazer spokojenej ze "to funguje".
1) Tragicka dokumentace devkitu
Potrebujes nekolik devkitu k desce tveho zarizeni ale kazdy jde nastavit ruzne a z jednoho webu stahnes dve ruzne sady podle toho jak se maintainer vyspal. Zadny check, zadne checksumy souboru devkitu v buildu. Kazdej progros developi s jinym. Neudelas nic. Deska je sice draha ale devkit je zadarmo nebo za male penize. Strategicka volba dodavatele nemela jako metriku determinismus a dokumentaci devkitu.
2) U mne to jde prelozit / u mne to funguje
Kazdej progros jine prostredi a jinak nastavenej devkit. Souvisi s 1 Je to na palici vysvetlovat lidem kteri by mne mohli ucit dulezitost jednotneho prostredi
3) Progrosi neradi aktualizuji komponenty protoze by si podelali prostredi a nedodali v terminu
Souvisi to s podem 1. a tim ze update devkitu a vsech knihoven okolo neni bezproblemovy. Vsechny devkity(ten nejlevnejsi) delali asocialove kteri si mysli ze kazdej premysli stejne jako on
4) Programatori dost casto doufaji v x
Komplexita veci je tak velika, ze jim staci jen aby to nejak behalo a slo prelozit. Ze celou dobu s sebou taha starou deravou knihovnu ho netoci.
5) Release jde pokazdy od nekoho jineho
Neexistuje zodpovedna osoba za releasy. Pokazdy je dela nekdo jinej v zavislosti na tom jestli je dostupny. Jednou to dela John a podruhy Eric, potreti nove nastupujici kolega ktery nema ani info z internich dokumentu. No hlavne ze muze videt roadmap projektu.
6) Security veci vetsinu progrosu netoci pokud se to netyka zrovna primo jejich prace
7) Dulezite je dodat vcas a ne bezpecne. Stejne desku za chvilku obsoletnem. A update udelame jen kdyby nekdo rval
8) Patch na starou verzi muze hodne bolet
Progros co delal posledni release samozrejmne nedokumentoval se kterym devkitem to delal a zbyly jen tagy v SVN. Jen contractor ktery udela a odejde. Takze se stalo to ze
Vyvoj pro letecky prumysl na vas ovadi programatorsky! Kazdy radek kodu musi byt zduvodnen. A ne ze tady vezmem nakej kernel+nakou newlibc+libovolny bordel z sdk s ruznym datem a je hotovo
https://chess.eecs.berkeley.edu/hcssas/papers/Sha%20Avionics%202.0%20doc.pdf
 
> Zarážející na tom je, že podle Check Pointu překvapivé množství poskytovatelů
> pro komunikaci s routery stále používá nešifrované spojení. 
Co jiného jim zbývá? když to zkusí, v horším případě bude port 80 úplně nedostupný, uživatel se dočká varování od prohlížeče, že certifikát je neplatný (určitě alespoň hostname, za autoritu asi taky platit nebudou a časem nejspíš propadne i datum platnosti) a že na takový web fakt raději nemá chodit. tedy do návodu je třeba přidat, že je to normální stav a uživatel se nemá bát varování neposlechnout, protože jinak modem/krabičku nenastaví. a on to příště udělá i v bance či emailu - vždyť nedávno mu to doporučili v jakémsi návodu!
Tohle opravdu není zrovna domyšleno..
To si nemyslim. Myslenky a principy by zustaly zachovany, jen by se to muselo udelat znovu a tentokrat s dokumentaci, testovanim a overenim.
Jasne, ze by to nebylo ze dne na den a neco to stalo. Ale zrovna treba software routeru snad neni az tak slozita vec jako software treba letadla.
Server chip.cz dal zdroj zprávy pod miničlánek a tam jsem se dozvěděl víc.
lidi na odkazu najdete modely kterých se to týká:
http://mis.fortunecook.ie/misfortune-cookie-suspected-vulnerable.pdf
RomPager není žádný "servisní software", ale embedded web server. Skrz něj se dělají ty webovky pro konfiguraci routeru. A tenhle RomPager je typicky použitý na zařízeních, ve kterých je ZyNOS. Ti výrobci routerů jsou v tom tak trošku nevinně. Oni si od Allegro Software koupili hotové řešení, ve kterém je bohužel bug. Pokud je firmware routeru založený nikoli na ZyNOSu, ale např. na Linuxu, tak tam RomPager nebude. Netuším, jaký webserver je ve firmware založeném na VxWorks (např. některé routery Linksys). Takový jsem ještě nezkoumal.
Funguje to cez TR-069 čo je protokol ktorý ISP používajú na správu CPE. Beží to defaultne na porte 7547. Takže ak je aj zakázaný port 80 z WAN je dosť dobrá šanca, že to bude fungovať tu pretože celé TR-69 je prenos XML cez HTTP a teda spravuje to ten istý webserver. A ako sa ukázalo niektoré routre aj keď sa vypne TR-69 z administrácie, nechajú to bežať.
Stale casteji mam pocit, ze ve firmach, co delaji takoveto masove vyrobky, by meli jednou za par let vsechno co maji smazat a zacit odznova. Protoze kombinace neustaleho recyklovani neceho, v cem se uz nikdo nevyzna a bezohledne ignorace bezpecnosti je primo smrtici. Pokud by se takto vyrabela auta, jejich samovolne exploze by byly na dennim poradku.
Evidentně naivně předpokládáte, že administrace z WAN strany je zakázaná a případně je aspoň zaheslovaná?
Když se podívám kolem sebe, tak u řady ISPíků tak není a často je přihlášení v defualt nebo i úplně bez hesla. A to se bavím i o hodně velkých ISPích. Zkrátka tam, kde vychází uživatelům vstříc a ty jejich domácí TPlinky a spol mají pod správou a nastavují je. A aby to šlo dobře, tak to dělají přes WAN vzdáleně a často bez té změny hesla. Asi vychází z toho, že zákazníci jsou za NATem a nejde se zvenčí na router spojit. Což je pravda, ale dá se spojovat vzájemně mezi sebou. Což se občas hodí, že můžu přenastavit wifiny sousedů tak, aby nerušily tu moji...
Uprime receno, nevim, co je uvnitr routeru, ale ta flash pamet tam ma sotva par mega (co koukam na tema OpenWRT), takze se tam moc kodu vejit nemuze. A alespon nejaka zakladni bezpecnost by mela byt dodrzovana, jako laikovy mi staci videt defaultne zapnute nastavovani pres WAN, sit bez hesla nebo WPS a vstavaji mi vlasy na hlave.
 
Bohužel trolíci mají smulů, protože první co po zapnutí nebo hardresetu je vynucováno v administračním rozhraní je změna hesla! Kterou nepřeskočíte a správa z WAN se musí zapnout . Takže nepleďte chybu routeru s Frantou z Hornídolní co fušuje do Interfernetu.
Dobrý pokus jak obhájit předvánoční PR jedné bezpečnostní firmy.
Jak který router. Pokud bereme za Frantu i SPíka, který třeba pokrývá 3 kraje České republiky, tak ano.
Problém je jinde, popisovaná chyba (a řada dalších) je blbá. Ale v realitě jsou hromady routerů probvozovány tak, že i když se tato chyba odstraní, tak to na špatný stav nemá vliv. A to pomíjím, že kolikrát ISPíci u těchto routerů, co dávají lidem, mají schválně starý firmware, který jim umožňuje pohodlenější dálkové ovládání (protože novější firmware třeba komplikuje ovládání přes WAN stranu nebo ji má v základu vypnutou). Vysvětlovat, že je hezká představa, že to nejde zneužít, když je většina klientů za NATem je zbytečná. Pochopit, že jde dělat také útok z vnitřku sítě na ostantí zcela přesuhuje představivost subjektů. A to je řevu, že si tam dám vlastní router, který si nastavím jak chci já a jim do toho nic není a nepustím je do něj...
Je třeba si uvědomit, že laická veřejnost do toho nevidí a je za takový přístup ráda, že ISPík jim to dodá i s tím nejlevnějším routeremznaček nějak nastavneým (pokud vůbec mají router a ne, že router je realizován až něke dál na infrastuktuře ISP), človíček ocení, že při problému zavolá, ISPík na dálku něco postaví a zase mu to jede. To lidi oceňují.:-)
A mlůžu říci, že toto nní jen případ Česka, musím se potkávat s pěknou řadou subjketů, kdy připojujeme na dálkový monitoring/management v rámci servisu nějakou technologii, co dodáváme, jaké exoty i v podobě velkých subjektů potkáváme