Pokusy o přihlášení na Mikrotiky

[Dalibor Toman]

to DT: dík, třeba toto. Z toho je nejdůležitější poznatek, že průnik není zalogován. Vůbec nijak? A co mi není jasné, je stav, kdy před vypuknutím aféry BYLA verze 6.35, pak jsem dal 6.4x. Dá se spolehlivě určit, jestli byl před upgrade RB nebo X86 napaden/prolomen, jestli upgrade ROSu všechny skryté úpravy "virem" zlikvidoval, popř. jak spolehlivě identifikovat pozůstatky z "viru" v systému po upgrade, popř. jeho stále aktivní části. A je už někomu známo/tuší, co vlastně má "vir" za cíl? Jak řeší upgrade ROS ti, co mají veřejku na RB 532 atd., pro kteréžto RB není pokračování ROS? Je toho hodně, že .. Děkuji, mpcz, 8.may.2018

spolehlive nebudes vedet nic. Pokud mas pochynosti, pak by mel pomoci netinstall. Breberky snad format flashky neprezijou a do BIOSu se snad Mikrotikum zatim take nic nedostalo (doufam). Osobne ale celkem verim prohlaseni MIkrotiku, ze nove ROSy pri instalaci zlikviduji vsechno, co neznaji. To se da snadno zaridit seznamem souboru, ktere jsou soucasti instalace a jejich kontrolnimi soucty. Asi budou jeste nejake soubory, ktere nejsou schopni zverifikovat (konfigurace apod) ale spustitelne binarky by meli byt schopni pohlidat

'Hacknul' jsem si asi 3 MT pomoci https://github.com/BigNerd95/Chimay-Red a v logu se neobjevilo vubec nic. Ani sestreleni WWW serveru se nezalogovalo (Content-Length: -1 chyba v obsluze HTTP requestu je skolacka). Lze tak ziskat soubor s hesly a v tom exploitu je hned i dekodovaci utilita, ktera vyzradi plain text hesla.
Bohuzel zadny zakaznicky MT WiFi router, ktery uz je prokazatelne skrz WWW napadeny se mi nepodarilo hacknout (abych ho upgradem prelecil aniz bych musel konkatovat zakaznika). Asi se ta breberka brani nasobnemu hacku.

Stare ROSy (5.x) jsou proti tomuto utoku asi v bezpeci (i kdyby ne staci zastavit WWW service). Ale verejku na MT by mel chranit firewall. Problem je, ze nove je potreba ten MT chranit jeste pred zakaznikem, co je k nemu pripojeny. Coz netusim jak bezpecne vyresit aniz bych ustrihl moznost managementu toho MT nasim technikem po eth

[mpcz]

Aha, no nevím, jestli to chápu dobře, ale pokud se někdo spokojí pouze s upgrade, má problém, protože útočník již zná heslo do přihlášení. Pak se může dostat do MKT kdy se mu zachce. Takový vlom by už byl logován? Dík, mpcz, 8.may.2018

[Dalibor Toman]

Aha, no nevím, jestli to chápu dobře, ale pokud se někdo spokojí pouze s upgrade, má problém, protože útočník již zná heslo do přihlášení. Pak se může dostat do MKT kdy se mu zachce. Takový vlom by už byl logován? Dík, mpcz, 8.may.2018

samozrejme hesla jsou potencialne prozrazena. Ja nel na mysli spis to, zda neni mozne, aby po upgradu zustal ten virus aktivni.
Prihlaseni beznym zpusobem se loguje.

[mpcz]

OK a co tak v době, když je vlomen do systému, upravit si nějaký soubor s konfigurací? Třeba si přidat další účet a heslo "pro příště". Upgradem se to asi neovlivní a možnost se kdykoliv vlomit je tu. Přidaného účtu si málokdo bez upozornění všimne. A odborník by určitě přišel i na dokonalejší věci. mpcz, 8.may.2018

[rsaf]

Hele co pořád řešíš? Hesla jsou poteniálně prozrazena, V zařízení potenciálně běžel škodlivý kód, který mohl dělat cokoliv, teoreticky vč. ovlivnění procesu upgrade na novou verzi tak, aby zůstal žít. Neříkám že se to dělo nebo děje, ale potenciálně možné to je. Potenciálně mohl být napaden i BIOS. Netinstall je tak o něco jistější než klasický upgrade, ovšem 100% by byl asi až JTAG.
Za poslední rok nebo dva byly minimálně dvě zásadní bezpečnostní chyby v managementu jak v ROS tak v UBNT. Každý kdo si má všech 5 pohromadě musí nezbytně dojít k tomu, že 100% managementu jeho zařízení prostě musí zmizet z internetu (u ISP i ze zákaznické sítě).

[Myghael]

A RB600, na který se mi nikdy nepodařilo instalovat/provozovat ROS 6.xx bez problémů? A co RB532 u klienta s věřejkou? Není to to stejné? Dík, mpcz 9.may.2018

To je zvláštní, mě na RB600A tohle chodí. Ale řešit tento problém, tak to rovnou spojím s upgradem na RBM33G, který je výkonnější a má výrazně menší spotřebu - a stojí krucinál míň než 900 Kč. Samozřejmě do něj nenaperu 4 ks miniPCI karet, ale tohle už dnes řeší málokdo, takže počet slotů na RB M33G je dostatečný, případně rozhodím na jeden či víc RB M11G (nebo RB433AH/RB411AH pokud nutně musím mít miniPCI a ne miniPCI-E). U RB532 lze říct totéž, samozřejmě pokud nepotřebuji nutně jednu z těch nástaveb (jedna měla 16x ethernet, druhá 4x miniPCI).

Sám jsem příznivec starých věcí a mám doma krabici plnou historických routerboardů (od RB112 a RB133 dále, i ty RB532, RB600 a RB433UAH bych našel) i jiných síťových zařízení, která mnohdy ještě k něčemu využiju, ale provozovat to 24/7 na síti či jako bránu do internetu? "Problém" s upgradem RB532 a podobných "vykopávek" bych doporučil řešit přechodem na novější board. Každý kdo si domů schválně koupí mikrotik jako router může oželet těch pár stokorun za novější výbavičku, i kdyby jetou z bazaru. Třeba něco ze série hEX nebo hAP.

[Selič]

​Stare ROSy (5.x) jsou proti tomuto utoku asi v bezpeci (i kdyby ne staci zastavit WWW service). Ale verejku na MT by mel chranit firewall. Problem je, ze nove je potreba ten MT chranit jeste pred zakaznikem, co je k nemu pripojeny. Coz netusim jak bezpecne vyresit aniz bych ustrihl moznost managementu toho MT nasim technikem po eth

Ze strany zákazníka jsme to vyřešili povolením SSH a Winboxu pouze z jedné konkrétní IP adresy mimo rozsah DHCP "zákazníka". Technik holt musí nastavit IP ručně.

[Dalibor Toman]

​Stare ROSy (5.x) jsou proti tomuto utoku asi v bezpeci (i kdyby ne staci zastavit WWW service). Ale verejku na MT by mel chranit firewall. Problem je, ze nove je potreba ten MT chranit jeste pred zakaznikem, co je k nemu pripojeny. Coz netusim jak bezpecne vyresit aniz bych ustrihl moznost managementu toho MT nasim technikem po eth

Ze strany zákazníka jsme to vyřešili povolením SSH a Winboxu pouze z jedné konkrétní IP adresy mimo rozsah DHCP "zákazníka". Technik holt musí nastavit IP ručně.

mac-winbox/mac-telnet zakazany? Neighbor discovery smerm k zakaznikovi take?

[mpcz]

Aha, no nevím, jestli to chápu dobře, ale pokud se někdo spokojí pouze s upgrade, má problém, protože útočník již zná heslo do přihlášení. Pak se může dostat do MKT kdy se mu zachce. Takový vlom by už byl logován? Dík, mpcz, 8.may.2018

Prihlaseni beznym zpusobem se loguje.

Zdravím, nastražil jsem jeden plonkový MKT s veřejkou a starým 6.35, netrvalo dlouho a v logu toto:

may/11 06:38:17 system,info sntp change time May/11/2018 06:38:15 => May/11/2018 06:38:17
may/11 06:53:19 system,info sntp change time May/11/2018 06:53:17 => May/11/2018 06:53:19
may/11 07:05:13 system,error,critical login failure for user admin from 123.249.42.98 via web
may/11 07:05:15 system,error,critical login failure for user admin from 123.249.42.98 via web
may/11 07:05:16 system,info,account user admin logged in from 123.249.42.98 via web
may/11 07:06:41 system,info,account user admin logged out from 123.249.42.98 via web
may/11 07:08:22 system,info sntp change time May/11/2018 07:08:19 => May/11/2018 07:08:22
may/11 07:23:24 system,info sntp change time May/11/2018 07:23:22 => May/11/2018 07:23:24

may/11 09:38:45 system,info sntp change time May/11/2018 09:38:42 => May/11/2018 09:38:45
may/11 09:42:35 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:38 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:39 system,info,account user admin logged in from 47.52.63.226 via web
may/11 09:44:10 system,info,account user admin logged out from 47.52.63.226 via web
may/11 09:53:47 system,info sntp change time May/11/2018 09:53:45 => May/11/2018 09:53:47
may/11 10:08:49 system,info sntp change time May/11/2018 10:08:47 => May/11/2018 10:08:49

may/11 09:23:42 system,info sntp change time May/11/2018 09:23:40 => May/11/2018 09:23:42
may/11 09:38:45 system,info sntp change time May/11/2018 09:38:42 => May/11/2018 09:38:45
may/11 09:42:35 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:38 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:39 system,info,account user admin logged in from 47.52.63.226 via web
may/11 09:44:10 system,info,account user admin logged out from 47.52.63.226 via web
may/11 09:53:47 system,info sntp change time May/11/2018 09:53:45 => May/11/2018 09:53:47

Kdo se tím podrobněji zabývá: jedná se o opakované prolamování do přihlášení z několika různých zdrojů? Někdo tady psal, že po prolomení se už další nepodaří. A někdo také to, že haknutí není logováno. Je nebo není? Děkuji, mpcz, 13.may.2018

[Selič]

Zdravím, nastražil jsem jeden plonkový MKT s veřejkou a starým 6.35, netrvalo dlouho a v logu toto:

may/11 06:38:17 system,info sntp change time May/11/2018 06:38:15 => May/11/2018 06:38:17
may/11 06:53:19 system,info sntp change time May/11/2018 06:53:17 => May/11/2018 06:53:19
may/11 07:05:13 system,error,critical login failure for user admin from 123.249.42.98 via web
may/11 07:05:15 system,error,critical login failure for user admin from 123.249.42.98 via web
may/11 07:05:16 system,info,account user admin logged in from 123.249.42.98 via web
may/11 07:06:41 system,info,account user admin logged out from 123.249.42.98 via web
may/11 07:08:22 system,info sntp change time May/11/2018 07:08:19 => May/11/2018 07:08:22
may/11 07:23:24 system,info sntp change time May/11/2018 07:23:22 => May/11/2018 07:23:24

may/11 09:38:45 system,info sntp change time May/11/2018 09:38:42 => May/11/2018 09:38:45
may/11 09:42:35 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:38 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:39 system,info,account user admin logged in from 47.52.63.226 via web
may/11 09:44:10 system,info,account user admin logged out from 47.52.63.226 via web
may/11 09:53:47 system,info sntp change time May/11/2018 09:53:45 => May/11/2018 09:53:47
may/11 10:08:49 system,info sntp change time May/11/2018 10:08:47 => May/11/2018 10:08:49

may/11 09:23:42 system,info sntp change time May/11/2018 09:23:40 => May/11/2018 09:23:42
may/11 09:38:45 system,info sntp change time May/11/2018 09:38:42 => May/11/2018 09:38:45
may/11 09:42:35 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:38 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:39 system,info,account user admin logged in from 47.52.63.226 via web
may/11 09:44:10 system,info,account user admin logged out from 47.52.63.226 via web
may/11 09:53:47 system,info sntp change time May/11/2018 09:53:45 => May/11/2018 09:53:47

Kdo se tím podrobněji zabývá: jedná se o opakované prolamování do přihlášení z několika různých zdrojů? Někdo tady psal, že po prolomení se už další nepodaří. A někdo také to, že haknutí není logováno. Je nebo není? Děkuji, mpcz, 13.may.2018

Tohle je využití díry ve web serveru - více než rok známý problém - pokud máš na mikrotiku vypnutý web server nebo verzi novější než 6.39, tak se tě to netýká.
Kritická je díra ve winboxu, tam se objevuje 2x chybné přihlášení via winbox a po několika minutách úspěšné přihlášení přes ssh.

[Selič]

Selič píše:

​Stare ROSy (5.x) jsou proti tomuto utoku asi v bezpeci (i kdyby ne staci zastavit WWW service). Ale verejku na MT by mel chranit firewall. Problem je, ze nove je potreba ten MT chranit jeste pred zakaznikem, co je k nemu pripojeny. Coz netusim jak bezpecne vyresit aniz bych ustrihl moznost managementu toho MT nasim technikem po eth


Ze strany zákazníka jsme to vyřešili povolením SSH a Winboxu pouze z jedné konkrétní IP adresy mimo rozsah DHCP "zákazníka". Technik holt musí nastavit IP ručně.



mac-winbox/mac-telnet zakazany? Neighbor discovery smerm k zakaznikovi take?

Ano zakázané je všechno. Mac-winbox používáme pouze na prvotní konfiguraci nově vybaleného routeru a nevím o tom, že by to bylo někdy nutné použít na něco jiného. Zase ale na tom nemám běžné domácí uživatele - většinou nam tom sedí NVR a soukromé notebooky sekuriťáků

[Dalibor Toman]

Zdravím, nastražil jsem jeden plonkový MKT s veřejkou a starým 6.35, netrvalo dlouho a v logu toto:

may/11 06:38:17 system,info sntp change time May/11/2018 06:38:15 => May/11/2018 06:38:17
may/11 06:53:19 system,info sntp change time May/11/2018 06:53:17 => May/11/2018 06:53:19
may/11 07:05:13 system,error,critical login failure for user admin from 123.249.42.98 via web
may/11 07:05:15 system,error,critical login failure for user admin from 123.249.42.98 via web
may/11 07:05:16 system,info,account user admin logged in from 123.249.42.98 via web
may/11 07:06:41 system,info,account user admin logged out from 123.249.42.98 via web
may/11 07:08:22 system,info sntp change time May/11/2018 07:08:19 => May/11/2018 07:08:22
may/11 07:23:24 system,info sntp change time May/11/2018 07:23:22 => May/11/2018 07:23:24

may/11 09:38:45 system,info sntp change time May/11/2018 09:38:42 => May/11/2018 09:38:45
may/11 09:42:35 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:38 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:39 system,info,account user admin logged in from 47.52.63.226 via web
may/11 09:44:10 system,info,account user admin logged out from 47.52.63.226 via web
may/11 09:53:47 system,info sntp change time May/11/2018 09:53:45 => May/11/2018 09:53:47
may/11 10:08:49 system,info sntp change time May/11/2018 10:08:47 => May/11/2018 10:08:49

may/11 09:23:42 system,info sntp change time May/11/2018 09:23:40 => May/11/2018 09:23:42
may/11 09:38:45 system,info sntp change time May/11/2018 09:38:42 => May/11/2018 09:38:45
may/11 09:42:35 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:38 system,error,critical login failure for user admin from 47.52.63.226 via web
may/11 09:42:39 system,info,account user admin logged in from 47.52.63.226 via web
may/11 09:44:10 system,info,account user admin logged out from 47.52.63.226 via web
may/11 09:53:47 system,info sntp change time May/11/2018 09:53:45 => May/11/2018 09:53:47

Kdo se tím podrobněji zabývá: jedná se o opakované prolamování do přihlášení z několika různých zdrojů? Někdo tady psal, že po prolomení se už další nepodaří. A někdo také to, že haknutí není logováno. Je nebo není? Děkuji, mpcz, 13.may.2018

Tohle je využití díry ve web serveru - více než rok známý problém - pokud máš na mikrotiku vypnutý web server nebo verzi novější než 6.39, tak se tě to netýká.
Kritická je díra ve winboxu, tam se objevuje 2x chybné přihlášení via winbox a po několika minutách úspěšné přihlášení přes ssh.

Ano mohlo se stat, ze si pomoci diry ve WWW stahl seznam uzivatelu s hesly a pak se pomoci WWW normalne prihlasil. Ale klidne to take mohlo byt prihlaseni uhodnotym heslem. Divne je, ze se opakuji vzdy 2 neuspesne a 2 uspesne pokusy. Asi nejaka novota nebo jen nekdo sbira udaje a overuje, ze funguji. NEbo chce aby si uzivatele tech prihlaseni vsiml. Klasicke zneuziti Chimay-red s vlozenim infikovane binarky IMHO nenecha v logu vubec nic

Stacilo pred ten MT (nebo zapnout primo na nem) vrazit nejaky sniffer a z packetu by pak bylo videt o co slo.

A ten MT ma zrejme nejaky problem s hodinama - kdyz jsou schopne za 15minut utect o 2 sekundy.

[mpcz]

Díval jsem se na několik RB a ten posun o sekundy se všude. Je to vůbec chyba?
Možná náhoda, ale ty adresy jsou všechny z Číny. Takže buď jsou z Číny nebo se někdo snaží jako číňan vypadat. mpcz, 13.may.2018

[Dalibor Toman]

Díval jsem se na několik RB a ten posun o sekundy se všude. Je to vůbec chyba?
Možná náhoda, ale ty adresy jsou všechny z Číny. Takže buď jsou z Číny nebo se někdo snaží jako číňan vypadat. mpcz, 13.may.2018

zkusil bych pouzit nejaky jiny NTP server. Mozna jdou hodiny podle plotu na nem.

[krystofklima]

Vážení zákazníci, absolventi školení,

Dnes se mi již ozvalo 7 operátorů se zablokovaným přístupem na své stroje MikroTik.
Virus je nyní velmi systematický, napadá stroje po SSH čímž si testuje přístup. Dále využije chybu přetečení bufferu NetBiosu (tedy blokace IP protokolu nepomůže) a lokálně po L2 vrstvě napadá okolní stroje.
Tato chyba je popsána cca rok zpět, MikroTik prohlašuje, že definitvně je opravena ve verzi 6.41.3, viz zde https://www.coresecurity.com/advisories ... r-overflow

Jediná výhoda je v PPPoE či routovaných sítích, že šíření tam trvá podstatně déle než na transparentních sítích, kde je šíření přímo lavinové.
Virus si nahraje script do MikroTiku, ten Vám zahesluje a zároveň si vytvoří NOVOU PARTITION – TAKŽE FYZICKÝ NETINSTALL NUTNÝ !!! PŘÍPADNĚ U PC PŘEINSTALACE Z CD !!!
Pokud stroj pouze vyresetujete, použije svou vytvořenou partition a znovu se spustí, virus je velmi rychlý

Problém Vašich PC a notebooků :
DÁLE SE INFIKUJÍ DLL knihovny, které si stahujete jakýmkoli starším WinBoxem než 3.11 (nejedná se o verzi software MikroTik ale o verzi Winboxu, kterou najdete nahoře v řádku po spuštění WinBoxu před zalogováním kamkoli)
!!! TYTO POZMĚNĚNÉ KNIHOVNY SI STÁHNETE DO VAŠICH PC A TAKTO SNADNĚ SE PAK VIRUS ŠÍŘÍ NA DALŠÍ STROJE, KTERÉ JENOM WINBOXEM NAVŠTÍVÍTE !!!!
!! JE TŘEBA ve Vašich PC -> TEDY SMAZAT VŠECHNY STAŽENÉ DLL V ADRESÁŘI /User/AppData/Roaming/MikroTik/Winbox !!!

Postup pro dezinfekci PC : (tím začít, jinak si to šíříte sami)
Upgrade Winbox na 3.13 z MikroTik.com (nebo stačí při spuštění WinBoxu nahoře tlačítko Check for Update v Advanced Mode)
SMAZAT VŠECHNY STAŽENÉ DLL V ADRESÁŘI /User/AppData/Roaming/MikroTik/Winbox !!!
Dále raději reinstalaci PC – antivir toto nepovažuje za vir, je to útok cílený jen na administrátory sítí, takže to virové společnosti ještě nezachytily

Postup pro dezinfekci routerů co jsou napadené :

Provést NEINSTALL na RB, případně instalaci z CD na PC verze, je to nutnost, pro smazání virové partition (viditelné jedině při použití OpenWRT v-instalované do flashky jako druhý systém – návody jsou na netu)
Instalaci provést s verzí 6.41.3 a výš, kde je dle MikroTiku chyba odstraněna. Dokonce na verzích TILE pro CCR je změněno DH šifrování SSH klíčování – nebude pak fungovat ani automatizované připojování skrze SSH z jiných systémů

Postup pro zamezení šíření na zdravých strojích :

Povýšit verzi nad 6.41.3. která je MikroTikem vyhlášena již za bezpečnou !!!
Změnit přístup v IP SERVICES – zakázat WWW, API (použít API-SSL s certifikátem), FTP, TELNET – změnit port na SSH
SSH a WINBOX omezit přístup jen na lokální sítě, vzdáleně jen přes VPN
POZOR vir se šíří chybou SMB overflow popsanou výše, tedy blokace IP protokolu ve firewallu nepomůže !!!

Hodně štěstí všem postiženým, silné nervy a funčkní auta