1. Въведение

Компаниите, които не бяха организирали системи за отдалечен достъп, спешно ги развихриха преди няколко месеца. Не всички администратори бяха готови за такава "жега", в следствие на което настъпиха пропуски в сигурността: неправилна конфигурация на услугите или дори инсталиране на остарели версии на софтуер, с открити преди това уязвимости. На едни тези пропуски вече им се върнаха като бумеранг, а на други им провървя повече, но определено всички трябва да си извадят изводи. Лоялността към дистанционната работа нарасна многократно, и все повече компании приемат дистанционната работа като допустим формат на постоянна основа.

Така, има многобройни варианти за осигуряване на отдалечен достъп: различни VPN, RDS и VNC, TeamViewer и други. Администраторите имат от какво да избират, основавайки се на спецификата на изграждане на корпоративната мрежа и устройствата в нея. Най-популярни остават VPN решенията, обаче, много малки компании избират RDS (Remote Desktop Services), тъй като те са по-прости и бързи за развързване.

В тази статия ще говорим по-подробно за безопасността на RDS. Ще направим кратък обзор на известни уязвимости, както и ще разгледаме няколко сценария за стартиране на атака срещу мрежовата инфраструктура, основана на Active Directory. Надяваме се, че нашата статия ще помогне на някого да проведе работа над грешките и да повиши сигурността.

2. Нrecent vulnerabilities RDS/RDP

Всеки софтуер съдържа грешки и уязвимости, които се експлоатират от злонамерени лица, а RDS не е изключение. В последно време Microsoft често съобщаваше за нови уязвимости; решихме да направим кратък обзор на тях:

• CVE-2019-0787

Тази уязвимост поставя под риск потребителите, които се свързват с компрометиран сървър. Злонамеренецът може да получи контрол над потребителското устройство или да се закрепи в системата, за да има постоянен отдалечен достъп.

• CVE-2019-1181 / CVE-2019-1182 / CVE-2020-0609

Тази група уязвимости позволява на неразрешен злонамеренец дистанционно да изпълни произволен код на сървър с RDS чрез специално формулиран запрос. Също така, те могат да се използват за създаване на червеи — зловреден софтуер, който самостоятелно заразява съседни устройства в мрежата. По този начин, тези уязвимости могат да поставят под удар цялата мрежа на компанията, и само навременното обновление ще ги спаси.

Софтуерът за отдалечен достъп получи повишено внимание от страна на изследователите, както и от злонамерени лица, така че скоро можем да чуем за нови подобни уязвимости.

Добрата новина е, че не всички уязвимости имат публично достъпни експлойти. Лошата новина е, че на злонамеренец с експертиза не би му било трудно да напише експлоит за уязвимост, базирайки се на описание или използвайки техники като Patch Diffing (за която нашите колеги писаха в статията). Затова препоръчваме регулярно да обновявате софтуера и да следите за нови информация относно откритите уязвимости.

3. Атаки

Преминаваме към втората част на статията, в която ще покажем как започват атаките върху мрежовата инфраструктура, основана на Active Directory.

Описаните методи са приложими за следния модел на нарушител: злонамеренец с потребителска сметка, притежаващ достъп до Remote Desktop Gateway — терминален сървър (обикновено е достъпен, например, от външната мрежа). Приложили тези методи, злонамеренецът ще може да продължи атаката върху инфраструктурата и да утвърди присъствието си в мрежата.

Конфигурацията на мрежата в конкретния случай може да варира, но описаните техники са доста универсални.

Примери за излизане от ограничена среда и повишаване на привилегиите

При достъп до Remote Desktop Gateway, злонамеренецът вероятно ще се сблъска с ограничена среда. При свързване към терминалния сървър се стартира приложение: прозорец за свързване по протокол Remote Desktop за вътрешни ресурси, файлов мениджър, офис пакети или всякакъв друг софтуер.

Целта на нападателя ще бъде да получи достъп до изпълнението на команди, тоест до стартиране на cmd или powershell. В това могат да помогнат няколко класически техники за избягване от "пясъчник" на Windows. Нека разгледаме по-подробно.

Вариант 1. Злонамеренецът има достъп до прозореца за свързване на Remote Desktop в рамките на Remote Desktop Gateway:

Разкрива се менюто "Show Options". Появяват се опции за манипулиране на конфигурационните файлове за свързване:

От този прозорец може безпрепятствено да се влезе в Файловия мениджър, като се натисне някой от бутоните "Open" или "Save":

Отваря се Проводника. Неговата „адресна лента“ дава възможност за стартиране на разрешени изпълними файлове, както и за преглед на файловата система. Това може да бъде полезно на атакуващия в случаи, когато системните дискове са скрити и достъпът до тях директно не е възможен:

→ Демо-видео

Подобен сценарий може да бъде възпроизведен, например, при използване на Excel от пакета Microsoft Office като отдалечен софтуер.

→ Демо-видео

Освен това, не трябва да забравяме за макросите, използвани в този офис пакет. Нашите колеги разгледаха проблема с безопасността на макросите в тази статията.

Вариант 2. Използвайки същите входни данни, както в предишния вариант, атакуващият създава няколко свързвания с отдалечения работен плот под един и същ акаунт. При повторно свързване, първото ще бъде затворено, а на екрана ще се покаже прозорец с уведомление за грешка. Бутонът за помощ в този прозорец ще извика Internet Explorer на сървъра, след което атакуващият може да премине в Проводника.

→ Демо-видео

Вариант 3. При настроени ограничения за стартиране на изпълними файлове, атакуващият може да се сблъска с ситуация, при която груповите политики забраняват стартиране на cmd.exe от администратора.

Съществува начин за заобикаляне на това чрез стартиране на bat файл на отдалечения работен плот с съдържание от вида cmd.exe /K . Грешката при стартиране на cmd и успешен пример за изпълнение на bat файла са показани на изображението по-долу.

Вариант 4. Забраната за стартиране на приложения чрез черни списъци по името на изпълнимите файлове не е панацея, те могат да бъдат заобиколени.

Нека да разгледаме следния сценарий: забранили сме достъпа до командния ред, забранили сме стартиране на Internet Explorer и PowerShell чрез групови политики. Атакуващият се опитва да извика помощ — никакъв отговор. Опитва се да стартира PowerShell през контекстното меню на модалния прозорец, извикан с натисната клавиша Shift — съобщение за забрана на стартиране от администратора. Опитва се да стартира PowerShell през адресната лента — отново никакъв отговор. Как да заобиколим ограничението?

Достатъчно е да копирате powershell.exe от папката C:WindowsSystem32WindowsPowerShellv1.0 в потребителската папка, да промените името на различно от powershell.exe и възможността за стартиране ще се появи.

По подразбиране, при свързване с отдалечения работен плот, се предоставя достъп до локалните дискове на клиента, от които атакуващият може да копира powershell.exe и след преименуването да го стартира.

→ Демо-видео

Предоставили сме само няколко начина за заобикаляне на ограниченията, но сценариите, които могат да бъдат измислени, са много. Всички те обединява изходът в Windows Explorer. Има множество приложения, които използват стандартните средства на Windows за работа с файлове, и когато ги поставим в ограничена среда, можем да прилагаме подобни техники.

4. Препоръки и заключение

Както виждаме, дори в ограничена среда има пространство за развитие на атаките. Въпреки това, можем да усложним живота на атакуващия. Предоставяме общи препоръки, които ще бъдат полезни както в разгледаните варианти, така и в други случаи.

• Ограничете стартирането на програми чрез черни/бели списъци, използвайки групови политики.
  В повечето случаи обаче остава възможността за стартиране на код. Препоръчваме да се запознаете с проекта LOLBAS, за да имате представа за недокументираните начини за манипулиране на файлове и изпълнение на код в системата.
  Препоръчваме да комбинирате двата типа ограничения: например, можете да разрешите стартирането на изпълними файлове, подписани от Microsoft, но да ограничите стартирането на cmd.exe.
• Изключете разделите с настройки на Internet Explorer (може да се направи локално в регистъра).
• Изключете чрез regedit извикването на вградената помощ на Windows.
• Ограничете възможността за монтиране на локални дискове за отдалечени връзки, ако това ограничение не е критично за потребителите.
• Ограничете достъпа до локалните дискове на отдалечената машина, оставяйки достъп само до потребителските папки.

Надяваме се, че ви е било поне интересно, а в най-добрия случай – тази статия ще помогне да направите отдалечената работа на вашата компания по-безопасна.

Източник: habr.com