1. Въведение
Компании, които не организираха системи за отдалечен достъп, спешно ги разгръщаха преди няколко месеца. Не всички администратори бяха готови за такова "горещо" време; в резултат на това наложи проблеми със сигурността: неправилна конфигурация на услугите или дори инсталиране на остарели версии на софтуер с открити предишни уязвимости. Някои от тези пропуски вече се върнаха към тях, а на другите им провървя повече, но изводите определено трябва да бъдат направени от всички. Лоялността към дистанционната работа се увеличи многократно и все повече компании приемат дистанционната работа като допустим формат на постоянно ниво.
И така, варианти за обезпечаване на отдалечен достъп има много: различни VPN, RDS и VNC, TeamViewer и други. Администраторите имат от какво да изберат, основавайки се на спецификата на корпоративната мрежа и устройствата в нея. Най-популярни остават VPN решенията, обаче много малки компании избират RDS (Remote Desktop Services), тъй като те са по-прости и бързи за разгръщане.
В тази статия ще говорим по-подробно за сигурността на RDS. Ще направим кратък преглед на известните уязвимости и ще разгледаме няколко сценария за нападение върху мрежовата инфраструктура, основана на Active Directory. Надяваме се, че нашата статия ще помогне на някого да направи работа върху грешките и да повиши сигурността.
2. Наскоро открити уязвимости RDS/RDP
Всяко ПО съдържа грешки и уязвимости, които се експлоатират от злонамерени лица, и RDS не е изключение. В последно време Microsoft често съобщава за нови уязвимости, затова решихме да направим кратък преглед на тях:
Тази уязвимост поставя под заплаха потребителите, които се свързват с компрометирани сървъри. Злонамеренец може да получи контрол над потребителското устройство или да се закрепи в системата, за да има постоянен отдалечен достъп.
- / /
Тази група уязвимости позволява на неотрейтиран злонамеренец дистанционно да изпълнява произволен код на 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. Препоръки и заключение
Както виждаме, дори в ограничена среда има пространство за развитие на атаката. Въпреки това, можем да направим живота на атакуващия труден. Предоставяме общи препоръки, които ще бъдат полезни както за обсъдените случаи, така и за други ситуации.
- Ограничете стартирането на програми с черни/бели списъци, използвайки групови политики.
В повечето случаи остава възможност за стартиране на код. Препоръчваме да се запознаете с проекта , за да имате представа за недокументираните методи за манипулация на файлове и изпълнение на код в системата.
Препоръчваме да комбинирате двата типа ограничения: например, можете да разрешите стартиране на изпълними файлове, подписани от Microsoft, но да ограничите стартирането на cmd.exe. - Изключете разделите с настройки на Internet Explorer (може да стане локално в системния регистър).
- Изключете чрез regedit извикването на вградената помощ на Windows.
- Изключете възможността за монтиране на локални дискове за отдалечени свързвания, ако такова ограничение не е критично за потребителите.
- Ограничете достъпа до локалните дискове на отдалечената машина, оставяйки достъп само до потребителските папки.
Надяваме се, че ви е било поне интересно, а в най-добрия случай — тази статия ще помогне за осигуряване на по-безопасна отдалечена работа на вашата компания.
Източник: habr.com
