HTB Sharp. Потрошим сервис на .NET через .NET Remoting Services

Разведка

Сканирование портов

Ад­рес нашей машины — 10.10.10.219, закиды­вай его в /etc/hosts, что­бы мож­но было обра­щать­ся к хос­ту по име­ни.

Пер­вый шаг любой ата­ки — ска­ниро­вание пор­тов. Я обыч­но выпол­няю его вот таким неболь­шим скрип­том. Он дела­ет два про­хода: сна­чала по всем пор­там, затем с исполь­зовани­ем скрип­тов (опция -A) — по тем, где что‑то обна­ружи­лось. Это поз­воля­ет получить под­робный спи­сок сер­висов, работа­ющих на уда­лен­ном хос­те.

Как это обыч­но быва­ет на машинах с Windows, в резуль­тате ска­ниро­вания име­ем мно­го откры­тых пор­тов:

• 135 — MSRPC, служ­ба уда­лен­ного вызова про­цедур;
• 139 — служ­ба имен NetBIOS;
• 445 — SMB;
• 5985 — WinRM, служ­ба уда­лен­ного управле­ния;
• 8888 и 8889 — спе­цифи­кация .NET Message Framing.

Как видишь, здесь нет веб‑сер­вера или каких‑то дру­гих сер­висов, которые бы пре­дос­тавля­ли широкое поле для про­верок и поис­ка учет­ных дан­ных. А зна­чит, у нас все­го два даль­нейших век­тора: тест без учет­ных дан­ных (через ано­ним­ный дос­туп) и, если ничего не получит­ся, брут­форс учет­ки.

Перебор SMB

Пер­вым делом про­веря­ем, что мож­но най­ти на шаре SMB. Находим общую дирек­торию kanban, которая дос­тупна без авто­риза­ции. С помощью SMBMap сра­зу прос­матри­ваем рекур­сивно все содер­жимое (опция -R):

Фай­лов очень мно­го, и удоб­нее ана­лизи­ровать их локаль­но, поэто­му я под­клю­чил­ся к обще­му ресур­су через про­вод­ник и ско­пиро­вал все содер­жимое катало­га на локаль­ный хост.

По­хоже, перед нами какое‑то при­ложе­ние для Windows. Сре­ди фай­лов наш­лось руководс­тво поль­зовате­ля, это нам на руку. А в фай­ле PortableKanban.pk3 находим учет­ные дан­ные двух поль­зовате­лей. Их пароли ока­зались зашиф­рованы. Для прос­мотра фай­лов в фор­мате JSON в тер­минале советую исполь­зовать ути­литу jq, которая поз­воля­ет в два сче­та пар­сить раз­метку и вытяги­вать нуж­ные дан­ные.

Точка входа

Пе­рей­дем на машину с Windows (я обыч­но работаю в Linux) и пос­мотрим, что нам даст запуск при­ложе­ния. Пер­вым делом оно нас про­информи­рует, что по умол­чанию пароль для адми­нис­тра­тора пус­той.

Тут приш­ла идея изме­нить сами фай­лы кон­фигура­ции прог­раммы, так как циф­ровая под­пись отсутс­тву­ет и при­ложе­ние не смо­жет про­верить целос­тность содер­жащих­ся в кон­фиге дан­ных. Сох­раним фай­лы кон­фигура­ции перед их изме­нени­ем.

Сна­чала уда­лим файл с раз­решени­ем md5, а потом убе­рем в двух оставших­ся фай­лах кон­фигура­ции пароль адми­нис­тра­тора по клю­чу EncryptedPassword. Теперь мы можем успешно авто­ризо­вать­ся как Administrator с пус­тым паролем.

Сто­ит хорошень­ко изу­чить при­ложе­ние, так как в нем могут най­тись записи с кри­тичес­кими дан­ными или еще какая‑нибудь полез­ная информа­ция. К при­меру, перей­дя в нас­трой­ки, мы видим спи­сок всех зарегис­три­рован­ных в прог­рамме поль­зовате­лей (те же, что и в кон­фиге). Что еще более важ­но, мы можем пос­мотреть пароль в откры­том виде, прос­то сняв галоч­ку. Пус­тое поле пароля у адми­нис­тра­тора сви­детель­ству­ет о том, что это рас­шифро­ван­ный пароль из кон­фига. Так мы узна­ем пароль поль­зовате­ля lars.

По­луча­ется, мы можем рас­шифро­вать пароли из кон­фига. Давай вос­ста­новим и пароль адми­на — он еще может при­годить­ся. Вос­ста­нав­лива­ем сох­ранен­ные кон­фиги и меня­ем роль (ключ Role) извес­тно­го нам поль­зовате­ля lars c User на Admin. Успешно авто­ризу­емся (ведь пароль мы уже зна­ем) и уже зна­комым нам спо­собом получа­ем пасс адми­нис­тра­тора.

Те­перь у нас уже есть кое‑какие учет­ные дан­ные, и мы можем поп­робовать под­клю­чить­ся к извес­тным нам служ­бам. Сно­ва начина­ем с SMB и узна­ем, что от име­ни поль­зовате­ля lars нам дос­тупна новая дирек­тория — dev. Сра­зу рекур­сивно прос­мотрим все содер­жимое.

В най­ден­ной дирек­тории видим запис­ку и три исполня­емых фай­ла, один из которых — биб­лиоте­ка с говоря­щим наз­вани­ем RemotingLibrary.dll. Я сно­ва под­клю­чил­ся через про­вод­ник и сох­ранил все содер­жимое на локаль­ный хост. В запис­ке содер­жится спи­сок задач, где ска­зано о гря­дущем перено­се .NET на WCF и добав­лении валида­ции вход­ных дан­ных.

По­доб­ные упо­мина­ния очень полез­ны, так как теперь мы зна­ем, что ввод не филь­тру­ется, и в этом зак­люча­ется даль­нейший век­тор ата­ки. Что очень важ­но, при­ложе­ние написа­но на C#, поэто­му перено­сим фай­лы на машину с Windows и деком­пилиру­ем с помощью dnSpy, начиная, конеч­но же, с кли­ента. Как вид­но в стро­ке 15 деком­пилиро­ван­ного кода, при­ложе­ние отве­чает на пор­те 8888. А стро­ки 16 и 17 содер­жат учет­ные дан­ные для под­клю­чения, которое обес­печива­ется за счет исполь­зования System.Runtime.Remoting.Channels.Tcp.

У меня уже был подоб­ный опыт, поэто­му я догады­вал­ся, какую уяз­вимость при­дет­ся экс­плу­ати­ровать. Речь о багах CVE-2014-1806 (недос­таточ­ное огра­ниче­ние на дос­туп к памяти) и CVE-2014-4149 (отсутс­твие про­вер­ки TypeFilterLevel). В экс­плу­ата­ции нам поможет экс­пло­ит Джей­мса Фор­шоу.

Закрепление

Прис­тупим к экс­плу­ата­ции. Сна­чала сге­нери­руем наг­рузку‑дроп­пер, которая будет выпол­нять основную наг­рузку. В качес­тве наг­рузки дроп­пера исполь­зуем однос­троч­ник на PowerShell, который заг­рузит c нашего хос­та код на PowerShell и выпол­нит его.