Уязвимост “Ghost-Sender”, засягаща хибридни Exchange Onprem

“Ghost-Sender” е уязвимост която се изразява в широко разпространена грешка в конфигурацията, която позволява фалшифициране на имейли към организации използващи Exchange online тенанти или хибридни Exchange Onprem -> Еxchange Online конфигурации. При определени конфигурации в този сценарий е възможно която позволява изпращане на фишинг email, който да заобиколи стандартните протоколи за верификация (SPF, DKIM и DMARC) и да бъде доставен като легитимен до крайната потребителска кутия. Една организация е уязвима към тази техника за фалшиви имейли при следните обстоятелства: Конфигурация на имейл трафика – Организацията използва Exchange Online или хибридна версия на Exchange. Външни MX записи- MX записите на домейна не са насочени към Microsoft (*.mail.protection.outlook.com), а към “email gateway” на трета страна, спам филтър или локален имейл сървър. Липса на допълнителна конфигурация на “Partner Organization” конектор със строго зададен IP адрес или сертификат, който е базиран на рестрикции. Друга мярка за сигурност може да се счита правило тип “priority-0 transport” за отхвърляне/карантиниране на поща, пристигаща извън разрешения път. Защитите срещу „spoofing“ често се базират на проверка за това дали съобщението минава през удостоверяване. При Ghost-Sender фокуса се измества към това дали неуспешното удостоверяване се прилага преди да бъде доставянето на съобщението, което ще попречи неговото блокиране. Когато организация препраща своите MX записи през Secure Email Gateway (SEG), който се предоставя от трета страна, но е оставен клиента на Exchange Online отворен за директни външни връзки, зловредни актьори могат да заобиколят системата за Secure Email Gateway. Това може да бъде постигнато чрез доставяне на имейли директно към Exchange, посредством powershell, или чрез персонализирани SMTP транспортни команди. Така се постига заобикаляне на правилата за проверка на SPF, DKIM, DMARC и позволява на нападателите да изпращат фалшиви имейли, които могат да изглеждат като произхождащи от човек на организацията, включително използване на актуални снимки на корпоративни профили. По подразбиране Exchange Online приема всички имейли, адресирани до неговите пощенски кутии, които са изпратени директно до крайно устройство. Нападателите могат да отгатнат крайното устройство на даден наемател и да използват обикновен SMTP клиент или PowerShell скрипт, за да „доставят лично“ фалшиви писма, като по този начин ефективно заобикалят всички филтри за сигурност на трети страни, които организацията е внедрила. При вътрешни изпращачи, Outlook извлича профилната снимка на изпращача, което допълнително легитимира фалшивата самоличност. Това може да послужи за целенасочени атаки към високопоставени лица в компанията. Нападателите могат да изготвят съобщения, съобразени с конкретна информация за ролята, отговорностите или личните интереси на получателя, за да повишат възприеманата легитимност. Така се цели заблуда на потребителя и разкриване на сензитивна или класифицирана информация. Зловредните актьори нямат главен фокус към ръководителите, като често се представят за обикновени служители, за да проникнат във вътрешни отдели като „Човешки ресурси“ и „Финанси“. Измамниците се представят за легитимни служители и се свързват с персонала от отдела по заплатите или човешките ресурси, за да „актуализират“ данните за паричните преводи. Това води до пренасочване на следващите плащания по заплатите към сметката на хакера. Също така нападателите могат да се представям за системен администратор, за да убедят потребителят да инсталира злонамерен софтуер тип „RAT“ с цел шпиониране и събиране да данни за вход, както и подканване за достъпване на злонамерен сайт отново създадени с цел събиране на потребителски имена и пароли. Съществуват 3 главни стъпки, които могат да смекчат риска и да отстранят грешката в конфигурацията: - Деактивиране на функцията „Direct Send“ (осигурява частично отстраняване на проблема) - Конфигуриране на “Partner organization” конектор, „* wildcard“, ограничаване чрез сертификат или IP адрес. (Microsoft recommended mitigation) - Конфигуриране на правило тип “Transport rule (priority 0)”, което да карантинира имейли от всички IP адреси извън листа на одобрените или съдържащи в тях “AuthAs: Internal| – |”. (Microsoft recommended mitigation)