Շտապ թարմացրեք Exim-ը 4.92-ի - կա ակտիվ վարակ

Գործընկերներ, ովքեր օգտագործում են Exim 4.87...4.91 տարբերակները իրենց փոստի սերվերների վրա, շտապ թարմացնեն 4.92 տարբերակին, քանի որ նախկինում դադարեցրել են Exim-ը՝ CVE-2019-10149-ի միջոցով կոտրելուց խուսափելու համար:

Մի քանի միլիոն սերվերներ ամբողջ աշխարհում պոտենցիալ խոցելի են, խոցելիությունը գնահատվում է որպես կրիտիկական (CVSS 3.0 բազային միավոր = 9.8/10): Հարձակվողները կարող են կամայական հրամաններ գործարկել ձեր սերվերի վրա, շատ դեպքերում արմատից:

Խնդրում ենք համոզվել, որ դուք օգտագործում եք ֆիքսված տարբերակ (4.92) կամ այն, որն արդեն կարկատել է:
Կամ կարկատել եղածը, տես շարանը անբասիր մեկնաբանություն.

Թարմացնել համար centos 6: սմ. մեկնաբանությունը Թեոդորի կողմից — centos 7-ի համար այն նույնպես աշխատում է, եթե այն դեռ չի հասել անմիջապես epel-ից։

UPD. Ubuntu-ն ազդել է 18.04 եւ 18.10, նրանց համար թողարկվել է թարմացում։ 16.04 և 19.04 տարբերակները չեն ազդում, քանի դեռ դրանց վրա հատուկ ընտրանքներ չեն տեղադրվել: Ավելի մանրամասն իրենց պաշտոնական կայքում.

Խնդրի մասին տեղեկություն Opennet-ում
Տեղեկատվություն Exim կայքում

Այժմ այնտեղ նկարագրված խնդիրը ակտիվորեն շահագործվում է (ենթադրաբար բոտի կողմից), որոշ սերվերների վրա վարակ եմ նկատել (4.91-ով աշխատող):

Հետագա ընթերցումը տեղին է միայն նրանց համար, ովքեր արդեն «ստացել են այն», դուք պետք է կամ ամեն ինչ տեղափոխեք մաքուր VPS թարմ ծրագրաշարով, կամ լուծում փնտրեք: Փորձե՞նք։ Գրեք, եթե որևէ մեկը կարող է հաղթահարել այս չարամիտ ծրագիրը:

Եթե ​​դուք, լինելով Exim-ի օգտատեր և կարդում եք սա, դեռ չեք թարմացրել (չեք համոզվել, որ 4.92 կամ կարկատված տարբերակը հասանելի է), խնդրում ենք կանգ առեք և աշխատեք թարմացնելու համար:

Նրանց համար, ովքեր արդեն հասել են այնտեղ, եկեք շարունակենք...

UPS: supersmile2009-ը մեկ այլ տեսակի չարամիտ ծրագիր է գտել և տալիս է ճիշտ խորհուրդ.

Չարամիտ ծրագրերի մեծ տեսականի կարող է լինել: Գործարկելով դեղը սխալ բանի համար և մաքրելով հերթը, օգտվողը չի բուժվի և կարող է չիմանալ, թե ինչից պետք է բուժվի:

Վարակը նկատելի է այսպես. [kthrotlds] բեռնում է պրոցեսորը; թույլ VDS-ի վրա 100% է, սերվերների վրա ավելի թույլ է, բայց նկատելի։

Վարակվելուց հետո չարամիտ ծրագիրը ջնջում է cron գրառումները՝ գրանցելով միայն ինքն այնտեղ՝ յուրաքանչյուր 4 րոպեն մեկ գործարկելու համար՝ միաժամանակ դարձնելով crontab ֆայլը անփոփոխ: Crontab -e չի կարող պահպանել փոփոխությունները, տալիս է սխալ:

Immutable-ը կարող է հեռացվել, օրինակ, այսպես, այնուհետև ջնջել հրամանի տողը (1.5 կբ).

chattr -i /var/spool/cron/root
crontab -e

Հաջորդը, crontab խմբագրիչում (vim), ջնջեք տողը և պահպանեք.dd
:wq

Այնուամենայնիվ, որոշ ակտիվ գործընթացներ կրկին վերագրվում են, ես դա պարզում եմ:

Միևնույն ժամանակ, տեղադրիչի սկրիպտից (տես ստորև) հասցեների վրա կախված են ակտիվ wgets (կամ գանգուրներ) մի փունջ, ես առայժմ դրանք տապալում եմ այսպես, բայց դրանք նորից սկսում են.

ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Stopping..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`

Ես գտա Trojan installer-ի սկրիպտը այստեղ (centos).

Ես կավելացնեմ, քանի որ տեղեկատվությունը թարմացվում է:

UPD 1. ֆայլերի ջնջումը (նախնական chattr -i-ով) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root չօգնեց, ոչ էլ ծառայությունը դադարեցնելը, ես ստիպված էի: crontab-ն առայժմ ամբողջությամբ պոկել այն (վերանվանել bin ֆայլը):

UPD 2. Տրոյական տեղադրողը երբեմն նաև այլ վայրերում էր պառկած, ըստ չափի որոնումն օգնեց.
գտնել / -չափ 19825c

UPD 3/XNUMX/XNUMX: Զգուշացում! Բացի selinux-ն անջատելուց, Trojan-ն ավելացնում է նաև իրը SSH բանալի ${sshdir}/authorized_keys-ով: Եվ ակտիվացնում է հետևյալ դաշտերը /etc/ssh/sshd_config-ում, եթե դրանք դեռ սահմանված չեն YES-ում.
PermitRootLogin այո
RSAA նույնականացում այո
Pubkey Նույնականացում այո
echo UsePAM այո
Գաղտնաբառի վավերացում այո

UPD 4. Առայժմ ամփոփելու համար. անջատել Exim, cron (արմատներով), շտապ հեռացնել Trojan ստեղնը ssh-ից և խմբագրել sshd կոնֆիգուրը, վերագործարկել sshd-ը: Եվ դեռ պարզ չէ, որ դա կօգնի, բայց առանց դրա խնդիր կա:

Կարծիքների/թարմացումների մասին մեկնաբանություններից կարևոր տեղեկությունը տեղափոխեցի գրառման սկիզբ, որպեսզի ընթերցողները սկսեն դրանից։

UPD 5/XNUMX/XNUMX: AnotherDenny-ը գրում է որ չարամիտ ծրագիրը փոխել է գաղտնաբառերը WordPress-ում։

UPD 6/XNUMX/XNUMX: Փոլմանը պատրաստեց ժամանակավոր բուժում, եկեք փորձարկենք։ Վերագործարկումից կամ անջատումից հետո դեղը կարծես անհետանում է, բայց առայժմ գոնե այդպես է:

Ով կայուն լուծում է տալիս (կամ գտնում է), խնդրում եմ գրեք, շատերին կօգնեք։

UPD 7/XNUMX/XNUMX: Օգտվողի clsv գրում է.

Եթե ​​դեռ չեք ասել, որ վիրուսը հարություն է առել Exim-ում չուղարկված նամակի շնորհիվ, երբ նորից փորձում եք նամակն ուղարկել, այն վերականգնվում է, նայեք /var/spool/exim4:

Դուք կարող եք մաքրել ամբողջ Exim հերթը այսպես.
էքսպիկ -ի | xargs exim -Mrm
Ստուգելով հերթում առկա մուտքերի քանակը.
exim -bpc

UPD 8: Կրկին շնորհակալություն AnotherDenny տեղեկատվության համարFirstVDS-ն առաջարկեց բուժման սցենարի իրենց տարբերակը, եկեք փորձարկենք այն:

UPD 9. Կարծես աշխատանքներ, շնորհակալություն Կիրիլ սցենարի համար!

Հիմնական բանը չպետք է մոռանալ, որ սերվերն արդեն վտանգված էր, և հարձակվողներին կարող էին հաջողվել տնկել ավելի անտիպիկ տհաճ բաներ (թվարկված չէ կաթիլային):

Հետևաբար, ավելի լավ է տեղափոխվել ամբողջովին տեղադրված սերվեր (vds), կամ գոնե շարունակել վերահսկել թեման. եթե որևէ նոր բան կա, գրեք այստեղ մեկնաբանություններում, քանի որ ակնհայտորեն ոչ բոլորը կանցնեն թարմ տեղադրման...

UPD 10. Կրկին շնորհակալություն clsvայն հիշեցնում է, որ վարակված են ոչ միայն սերվերները, այլև Raspberry Pi, և բոլոր տեսակի վիրտուալ մեքենաներ... Այսպիսով, սերվերները պահելուց հետո մի մոռացեք պահպանել ձեր վիդեո կոնսուլները, ռոբոտները և այլն:

UPD 11: Սկսած բուժիչ սցենարի հեղինակ Կարևոր նշում ձեռքով բուժողների համար.
(այս չարամիտ ծրագրի դեմ պայքարի այս կամ այն ​​մեթոդն օգտագործելուց հետո)

Դուք անպայման պետք է վերագործարկեք. չարամիտ ծրագիրը գտնվում է ինչ-որ տեղ բաց գործընթացներում և, համապատասխանաբար, հիշողության մեջ, և ինքն իրեն նորը գրում է ամեն 30 վայրկյանը մեկ փակելու համար:

UPD 12/XNUMX/XNUMX: Գտնվել է supersmile2009-ը Exim-ն իր հերթում ունի ևս մեկ (՞) չարամիտ ծրագիր և խորհուրդ է տալիս նախ ուսումնասիրել ձեր կոնկրետ խնդիրը նախքան բուժումը սկսելը:

UPD 13/XNUMX/XNUMX: Լորքը խորհուրդ է տալիս ավելի շուտ անցեք մաքուր համակարգ և ֆայլերը չափազանց զգույշ փոխանցեք, քանի որ Չարամիտ ծրագիրն արդեն հասանելի է հանրությանը և կարող է օգտագործվել այլ, ոչ այնքան ակնհայտ և ավելի վտանգավոր ձևերով:

UPD 14. վստահեցնել ինքներս մեզ, որ խելացի մարդիկ արմատից չեն փախչում, ևս մեկ բան հրատապ հաղորդագրություն clsv-ից:

Նույնիսկ եթե այն չի աշխատում root-ից, կոտրելը տեղի է ունենում... Ես ունեմ debian jessie UPD՝ ձգվել իմ OrangePi-ի վրա, Exim-ը աշխատում է Debian-exim-ից և դեռ կոտրվել է, կորցրել են պսակները և այլն:

UPD 15. երբ տեղափոխվում եք մաքուր սերվեր վտանգված սերվերից, մի մոռացեք հիգիենայի մասին, օգտակար հիշեցում w0den-ից:

Տվյալներ փոխանցելիս ուշադրություն դարձրեք ոչ միայն գործարկվող կամ կազմաձևման ֆայլերին, այլև այն ամենին, որը կարող է վնասակար հրամաններ պարունակել (օրինակ, MySQL-ում սա կարող է լինել CREATE TRIGGER կամ CREATE EVENT): Մի մոռացեք նաև .html, .js, .php, .py և այլ հանրային ֆայլերի մասին (իդեալականում այս ֆայլերը, ինչպես մյուս տվյալները, պետք է վերականգնվեն տեղական կամ այլ վստահելի պահեստից):

UPD 16/XNUMX/XNUMX: daykkin и savage_me հանդիպեց մեկ այլ խնդրիՀամակարգն ուներ Exim-ի մեկ տարբերակ տեղադրված պորտերում, բայց իրականում այն ​​աշխատում էր մեկ այլ տարբերակով:

Այսպիսով, բոլորը թարմացումից հետո դուք պետք է համոզվեք որ դուք օգտագործում եք նոր տարբերակը:

exim --version

Մենք միասին պարզեցինք նրանց կոնկրետ իրավիճակը:

Սերվերն օգտագործում էր DirectAdmin-ը և նրա հին da_exim փաթեթը (հին տարբերակ, առանց խոցելիության):

Միևնույն ժամանակ, DirectAdmin-ի custombuild փաթեթների մենեջերի օգնությամբ, փաստորեն, այնուհետև տեղադրվեց Exim-ի ավելի նոր տարբերակը, որն արդեն խոցելի էր։

Այս կոնկրետ իրավիճակում օգնեց նաև custombuild-ի միջոցով թարմացումը:

Մի մոռացեք նման փորձարկումներից առաջ կրկնօրինակումներ անել, ինչպես նաև համոզվել, որ թարմացումից առաջ/հետո բոլոր Exim գործընթացները հին տարբերակից են։ կանգնեցվել են և ոչ թե «խրված» հիշողության մեջ:

Source: www.habr.com