Diweddarwch RouterOS ar eich MikroTik

Diweddarwch RouterOS ar eich MikroTik
Ar noson Mawrth 10, dechreuodd gwasanaeth cymorth Mail.ru dderbyn cwynion gan ddefnyddwyr am yr anallu i gysylltu â gweinyddwyr IMAP/SMTP Mail.ru trwy raglenni e-bost. Ar yr un pryd, ni aeth rhai cysylltiadau drwodd, ac mae rhai yn dangos gwall tystysgrif. Achosir y gwall gan fod y "gweinydd" yn rhoi tystysgrif TLS hunan-lofnodedig.
 
Diweddarwch RouterOS ar eich MikroTik
Mewn dau ddiwrnod, daeth mwy na 10 o gwynion i mewn gan ddefnyddwyr ar amrywiaeth o rwydweithiau a chydag amrywiaeth o ddyfeisiau, gan ei gwneud yn annhebygol bod y broblem yn rhwydwaith unrhyw un darparwr. Datgelodd dadansoddiad manylach o'r broblem fod y gweinydd imap.mail.ru (yn ogystal â gweinyddwyr post a gwasanaethau eraill) yn cael ei ddisodli ar lefel DNS. Ymhellach, gyda chymorth gweithredol ein defnyddwyr, canfuom mai'r rheswm oedd cofnod anghywir yn storfa eu llwybrydd, sydd hefyd yn ddatryswr DNS lleol, ac mewn llawer o achosion (ond nid pob un) trodd allan i fod yn MikroTik dyfais, yn boblogaidd iawn mewn rhwydweithiau corfforaethol bach a chan ddarparwyr Rhyngrwyd bach.

Beth yw'r broblem

Ym mis Medi 2019, ymchwilwyr dod o hyd nifer o wendidau yn MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), a ganiataodd ymosodiad gwenwyno cache DNS, h.y. y gallu i ffugio cofnodion DNS yn storfa DNS y llwybrydd, ac mae CVE-2019-3978 yn caniatáu i'r ymosodwr beidio ag aros i rywun o'r rhwydwaith mewnol ofyn am gofnod ar ei weinydd DNS er mwyn gwenwyno'r storfa datryswr, ond i gychwyn o'r fath cais ei hun trwy'r porthladd 8291 (CDU a TCP). Sefydlogwyd y bregusrwydd gan MikroTik mewn fersiynau o RouterOS 6.45.7 (sefydlog) a 6.44.6 (tymor hir) ar Hydref 28, 2019, ond yn ôl ymchwil Nid yw'r rhan fwyaf o ddefnyddwyr wedi gosod clytiau ar hyn o bryd.

Mae’n amlwg bod y broblem hon bellach yn cael ei hecsbloetio “yn fyw”.

Pam ei fod yn beryglus?

Gall ymosodwr ffugio cofnod DNS unrhyw westeiwr y mae defnyddiwr yn ei gyrchu ar y rhwydwaith mewnol, a thrwy hynny atal traffig iddo. Os trosglwyddir gwybodaeth sensitif heb amgryptio (er enghraifft, dros http:// heb TLS) neu os yw'r defnyddiwr yn cytuno i dderbyn tystysgrif ffug, gall yr ymosodwr gael yr holl ddata a anfonir trwy'r cysylltiad, megis mewngofnodi neu gyfrinair. Yn anffodus, mae arfer yn dangos, os bydd defnyddiwr yn cael y cyfle i dderbyn tystysgrif ffug, bydd yn manteisio arni.

Pam gweinyddwyr SMTP ac IMAP, a beth arbedodd defnyddwyr

Pam ceisiodd yr ymosodwyr ryng-gipio traffig SMTP/IMAP o gymwysiadau e-bost, ac nid traffig gwe, er bod y rhan fwyaf o ddefnyddwyr yn cyrchu eu post trwy borwr HTTPS?

Nid yw pob rhaglen e-bost sy'n gweithio trwy SMTP ac IMAP / POP3 yn amddiffyn y defnyddiwr rhag gwallau, gan ei atal rhag anfon mewngofnodi a chyfrinair trwy gysylltiad heb ei warantu neu dan fygythiad, er yn unol â'r safon RFC 8314, a fabwysiadwyd yn ôl yn 2018 (a'i weithredu yn Mail.ru yn llawer cynharach), rhaid iddynt amddiffyn y defnyddiwr rhag rhyng-gipio cyfrinair trwy unrhyw gysylltiad heb ei sicrhau. Yn ogystal, anaml iawn y defnyddir protocol OAuth mewn cleientiaid e-bost (fe'i cefnogir gan weinyddion post Mail.ru), a hebddo, trosglwyddir y mewngofnodi a'r cyfrinair ym mhob sesiwn.

Efallai y bydd porwyr ychydig yn cael eu hamddiffyn yn well rhag ymosodiadau Dyn-yn-y-Canol. Ar bob parth hanfodol mail.ru, yn ogystal â HTTPS, mae polisi HSTS (diogelwch trafnidiaeth llym HTTP) wedi'i alluogi. Gyda HSTS wedi'i alluogi, nid yw porwr modern yn rhoi opsiwn hawdd i'r defnyddiwr dderbyn tystysgrif ffug, hyd yn oed os yw'r defnyddiwr eisiau gwneud hynny. Yn ogystal â HSTS, arbedwyd defnyddwyr gan y ffaith, ers 2017, bod gweinyddwyr SMTP, IMAP a POP3 Mail.ru yn gwahardd trosglwyddo cyfrineiriau dros gysylltiad heb ei warantu, bod ein holl ddefnyddwyr wedi defnyddio TLS i gael mynediad trwy SMTP, POP3 ac IMAP, a felly dim ond os yw'r defnyddiwr ei hun yn cytuno i dderbyn y dystysgrif ffug y gall mewngofnodi a chyfrinair ryng-gipio.

Ar gyfer defnyddwyr symudol, rydym bob amser yn argymell defnyddio cymwysiadau Mail.ru i gyrchu post, oherwydd ... mae gweithio gyda phost ynddynt yn fwy diogel nag mewn porwyr neu gleientiaid SMTP/IMAP adeiledig.

Beth ddylid ei wneud

Mae angen diweddaru cadarnwedd MikroTik RouterOS i fersiwn ddiogel. Os nad yw hyn yn bosibl am ryw reswm, mae angen hidlo traffig ar borthladd 8291 (tcp ac udp), bydd hyn yn cymhlethu ecsbloetio'r broblem, er na fydd yn dileu'r posibilrwydd o chwistrelliad goddefol i'r storfa DNS. Dylai ISPs hidlo'r porthladd hwn ar eu rhwydweithiau i amddiffyn defnyddwyr corfforaethol. 

Dylai pob defnyddiwr a dderbyniodd dystysgrif amnewidiol newid y cyfrinair ar gyfer e-bost a gwasanaethau eraill y derbyniwyd y dystysgrif hon ar eu cyfer ar fyrder. O'n rhan ni, byddwn yn hysbysu defnyddwyr sy'n cyrchu post trwy ddyfeisiau bregus.

P.S. Disgrifir gwendid cysylltiedig hefyd yn y post LukaSafonov "Mae Bregusrwydd Backport yn RouterOS yn Bygwth Cannoedd o Filoedd o Ddyfeisiadau".

Ffynhonnell: hab.com

Ychwanegu sylw