Pokusy o přihlášení na Mikrotiky

[iTomB]

Jedna se o verzi 6.36.4 a je tam i FW, vypada ze sel utok z vnitrni site, kde je mikrotik s tim samym FW, ale omezeni je u ip services.

Torch je ticho, ale on tam neni zadny prutok ted. Dal jsem pravidla na LOGovani uvidim. Vecer nahravame novejsi verzi.

[mrazek609]

Když bylo nastaveno IP services i FW správně, tak by mě zajímalo, zda nemohl jít útok přes L2 jak zde psal tuším pan Klíma? Třeba přes mac-telnet nebo mac-winbox.

[menicks]

Jedna se o verzi 6.36.4 a je tam i FW, vypada ze sel utok z vnitrni site, kde je mikrotik s tim samym FW, ale omezeni je u ip services.Torch je ticho, ale on tam neni zadny prutok ted. Dal jsem pravidla na LOGovani uvidim. Vecer nahravame novejsi verzi.

Omezení u IP services je na nic pokud je tam chyba. Protože port je pořád otevřený a až po pokusu o přihlášení na základě ip odmítá.

[mpcz]

No čekal jsem každou chvíli, až se vynoří tento katastrofický scénář. Protože doteď napadený stroj scanoval pouze 2 oct. do WANU, ale až se to začne šířit i v LANkách, popř. po MAC, pokud to samozřejmě jde, to bude teprve legrace. A půjde to asi i rychleji. mpcz, 22.5.2018

[ludvik]

@menicks: Jaký k tomu máš důkaz?

ip/services je služba typu superserver, inetd nebo něco podobného. Tedy spuštění programu na základě prvního požadavku z venku. Čili s vlastní chybnou službou to ještě nemá nic společného. Ta je spuštěna až po ověření IP. Mikrotik by byl i sám proti sobě, kdyby nevyužil možnost konfigurovat jen jednu službu místo osmi. Zároveň tento způsob trochu šetří prostředky, protože služba prostě neběží, pokud není potřeba.
Mimochodem proto tam jsou služby, co tam jsou a ne třeba DNS který takový způsob práce neumožňuje.

Kdyby byla chyba už v této fázi, tak je jedno na co se útočí - ftp, ssh, nebo klidně API. Což si myslím, že už by se provalilo.

Jediný rozdíl od seknutí firewallem (DROPem) je, že je to odmítnuté aktivně, čili útočník ví, že tam ta služba nejspíš je.

Musel by se dokázat šířit přes MAC-server, což jsem ovšem ještě neslyšel. Kromě toho to je broadcast, čili by takový virus musel hopkat z routeru na router.

https://forum.mikrotik.com/viewtopic.php?f=21&t=133533

[Dalibor Toman]

Jedna se o verzi 6.36.4 a je tam i FW, vypada ze sel utok z vnitrni site, kde je mikrotik s tim samym FW, ale omezeni je u ip services.Torch je ticho, ale on tam neni zadny prutok ted. Dal jsem pravidla na LOGovani uvidim. Vecer nahravame novejsi verzi.

Omezení u IP services je na nic pokud je tam chyba. Protože port je pořád otevřený a až po pokusu o přihlášení na základě ip odmítá.

to by bylo dost hloupe implementovane. Normalne se to dela tak, ze:
1) operacni system da vedet aplikaci, ze ma na socketu prichozi spojeni
2) aplikace si spojeni 'vyzvedne' z fronty cekajicich novych spojeni (Accept funkce), tim ziska informace o IP adrese zdroje (necte jeste zadna data poslana druhou stranou)
3) pokud se aplikace IP adresa puvodce spojeni nelibi tak spojeni ukonci

behem toho aplikace necte zadna data cili i kdyby v ni byla nejaka chyba pri zpracovani dat tak se nemuze aktivovat. Casto je dokonce ten kdo prijima od OS spojeni jedna aplikace (ta kontroluje nastaveni omezni IP apod) a pokud je vse v poradku preda rizeni dalsi aplikaci. dela se to tak bezne pokud aplikace neni volana prilis casto (nejedna se o vytizeny WWW server apod). Takze je mozne, ze pri odmitnuti na zaklade nepovoleneho IP se WWW server v mikrotiku vubec nespusti.

[Noxus28]

Tak som dnes od rána nasadil doma na FTTH od Orange log na pokusy na 8291. Nazbieralo sa pokusov zo zhruba 10 IP v rovnakom AS. A.B.0.0
Pozoroval niekto že si vie napadnutý RB zistiť IP za ktorú je NATnutý a následne testovať daný rozsah alebo testuje len rozsahy IP na interfacoch? Pýtam sa preto, lebo Orange u nás nedáva automaticky verejky klientom, tie končia na ONT a klientské zariadenie za ním je NATované.

[menicks]

Jedna se o verzi 6.36.4 a je tam i FW, vypada ze sel utok z vnitrni site, kde je mikrotik s tim samym FW, ale omezeni je u ip services.Torch je ticho, ale on tam neni zadny prutok ted. Dal jsem pravidla na LOGovani uvidim. Vecer nahravame novejsi verzi.

Omezení u IP services je na nic pokud je tam chyba. Protože port je pořád otevřený a až po pokusu o přihlášení na základě ip odmítá.

to by bylo dost hloupe implementovane. Normalne se to dela tak, ze:
1) operacni system da vedet aplikaci, ze ma na socketu prichozi spojeni
2) aplikace si spojeni 'vyzvedne' z fronty cekajicich novych spojeni (Accept funkce), tim ziska informace o IP adrese zdroje (necte jeste zadna data poslana druhou stranou)
3) pokud se aplikace IP adresa puvodce spojeni nelibi tak spojeni ukonci

behem toho aplikace necte zadna data cili i kdyby v ni byla nejaka chyba pri zpracovani dat tak se nemuze aktivovat. Casto je dokonce ten kdo prijima od OS spojeni jedna aplikace (ta kontroluje nastaveni omezni IP apod) a pokud je vse v poradku preda rizeni dalsi aplikaci. dela se to tak bezne pokud aplikace neni volana prilis casto (nejedna se o vytizeny WWW server apod). Takze je mozne, ze pri odmitnuti na zaklade nepovoleneho IP se WWW server v mikrotiku vubec nespusti.

Ano je to hloupě naprogramované Opravdu to prošlo i skrz omezení v ip services. Edit: Jinak tento problém asi není ve všech verzích...

[Dalibor Toman]

Ano je to hloupě naprogramované Opravdu to prošlo i skrz omezení v ip services. Edit: Jinak tento problém asi není ve všech verzích...

moc se mi to mu nechce verit. Spis prolezla nakaza z IP ktere to mely dovolene. Nekdo od MT tusim na forum tvrdil, ze aplikace z ip services se spousteji az po kontrole IPcek (cili standardnim logickym zpusobem z nejakeho centralniho demona, ktery jen nasloucha na portech a pak spousti ty aplikace).

Pokud mas nejake podezreni/dukaz tak doufam, ze support byl informovan, aby se to pro priste opravilo - protoze by to byl docela prusvih

[menicks]

Ano je to hloupě naprogramované Opravdu to prošlo i skrz omezení v ip services. Edit: Jinak tento problém asi není ve všech verzích...

moc se mi to mu nechce verit. Spis prolezla nakaza z IP ktere to mely dovolene. Nekdo od MT tusim na forum tvrdil, ze aplikace z ip services se spousteji az po kontrole IPcek (cili standardnim logickym zpusobem z nejakeho centralniho demona, ktery jen nasloucha na portech a pak spousti ty aplikace).

Pokud mas nejake podezreni/dukaz tak doufam, ze support byl informovan, aby se to pro priste opravilo - protoze by to byl docela prusvih

Ano dle monitoringu sítě to šlo z venku a ne z vnitřní adresy a nebyl jsem jediný kdo to reportoval.

Kód: Vybrat vše

apr/20 08:34:28 system,error,critical login failure for user admin from 103.1.221.
39 via winbox
apr/20 08:34:29 system,error,critical login failure for user admin from 103.1.221.
39 via winbox
apr/20 08:34:30 system,info,account user admin logged in from 103.1.221.39 via win
box
apr/20 08:34:37 system,info ip service changed by admin
apr/20 08:34:38 system,info ip service changed by admin
apr/20 08:34:54 system,info,account user admin logged in from 103.1.221.39 via ssh
 
apr/20 08:35:01 system,info,account user admin logged in from 103.1.221.39 via tel
net
apr/20 08:35:01 system,info,account user admin logged out from 103.1.221.39 via te
lnet
apr/20 08:35:04 system,info ip service changed by admin
apr/20 08:35:04 system,info ip service changed by admin
apr/20 08:35:05 system,info,account user admin logged out from 103.1.221.39 via wi
nbox
apr/20 08:35:05 system,info,account user admin logged out from 103.1.221.39 via ss


set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes port=8080
set ssh disabled=yes
set api disabled=yes
set winbox address=naseverejky,10.0.0.0/8,192.168.0.0/16
set api-ssl disabled=yes

edit: nelze mi přiložit soubor z vypisu monitoringu sítě, píšte to že je soubor moc velky ale má jen 150kB tak nevím. ale tam je jasně vidět odkud to šlo.

[pgb]

s takovouhle restrikcí se můžeš jít zahrabat ...

naseverejky,10.0.0.0/8,192.168.0.0/16

... stačí jeden neaktualizovanej, nezafirewallovany mk třeba u klienta na veřejce nebo i ve vnitřní síti s nat 1:1 a průnik je na světě .. .dyť ten vir první co zkoumá je jeho nejbližší okolí

[Dalibor Toman]

Ano dle monitoringu sítě to šlo z venku a ne z vnitřní adresy a nebyl jsem jediný kdo to reportoval.
....

no tak to je opravdu sila. Mas k tomu nejaky komentar od supportu?

[menicks]

s takovouhle restrikcí se můžeš jít zahrabat ...

naseverejky,10.0.0.0/8,192.168.0.0/16

... stačí jeden neaktualizovanej, nezafirewallovany mk třeba u klienta na veřejce nebo i ve vnitřní síti s nat 1:1 a průnik je na světě .. .dyť ten vir první co zkoumá je jeho nejbližší okolí

Z klientského routeru se nelze dostat na pateř to už si řeší hlavní FW. Ty rozsahy jsou tam pro sichr kdyby jsme změnili, zvětšili rozsahy pateřních/klientských routeru. Jinak toto byl klientský router.

[Dalibor Toman]

s takovouhle restrikcí se můžeš jít zahrabat ...

naseverejky,10.0.0.0/8,192.168.0.0/16

... stačí jeden neaktualizovanej, nezafirewallovany mk třeba u klienta na veřejce nebo i ve vnitřní síti s nat 1:1 a průnik je na světě .. .dyť ten vir první co zkoumá je jeho nejbližší okolí

no a ted si na chvilku predstavme, ze se objevi nejaka dira v mac-telnetu/mac-winboxu a muzes si vymejslet firewally treba s 'drop any any' na prvnim radku

[pgb]

a někteří mi říkají, že jsem jsem paranoidní, když zakazuji mac-telnet na bridgi kde se potkávají klientská data z portu do vpls

PS: ano v případě hypotetického napadení core infrastruktury bych měl i tak smůlu ... vím