В сегод­няшней статье мы раз­берем прин­цип работы это­го инс­тру­мен­та, а так­же про­бежим­ся по всем пяти режимам, которые поз­воля­ют:

• до­бавить при­виле­гии локаль­ному акка­унту с помощью вызова лишь одной фун­кции. Рань­ше это мож­но было сде­лать толь­ко через GPO и, если мне не изме­няет память, еще тре­бова­лась перезаг­рузка хос­та, что не очень удоб­но;
  


• за­пус­тить про­цесс, добавив в его токен кон­крет­ную при­виле­гию;
  


• уда­лить при­виле­гию у акка­унта. Опять же рань­ше это выпол­нялось с помощью GPO — сей­час исполь­зует­ся вызов фун­кции;
  


• об­наружить акка­унт с нуж­ной при­виле­гией на какой‑нибудь машине;
  


• об­наружить при­виле­гии у акка­унта на какой‑нибудь машине.
  

Добавляем привилегии аккаунту

Итак, все, как и в любом дру­гом про­екте на язы­ке С, начина­ется с фун­кции main(), в которую при­лета­ют все нуж­ные парамет­ры. Пос­ле чего для обес­печения кор­рек­тно­го вывода кирил­личес­ких (и иных) сим­волов дер­гаем setlocale(), выводим прек­расный ASCII-бан­нер и прис­тупа­ем к валида­ции вход­ных дан­ных.

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

• 1 — режим работы;
  


• имя поль­зовате­ля — кому навеши­вать при­виле­гию;
  


• прог­рам­мное имя при­виле­гии — какую при­виле­гию добав­лять.
  

Прог­рам­мное имя при­виле­гии — это, собс­твен­но, само имя при­виле­гии. Есть еще так называ­емое дру­жес­твен­ное имя — это ее опи­сание. Нап­ример, прог­рам­мное имя SeDebugPrivilege, а дру­жес­твен­ное — Отладка программ.

Итак, обра­щаем­ся к Privileger.

Я пре­дус­мотрел про­вер­ку на валид­ность име­ни поль­зовате­ля, а так­же име­ни при­виле­гии, что­бы пре­дот­вра­тить оче­пят­ки. Про­вер­ка реали­зует­ся фун­кци­ей ValidateAccInfo(), которая при­нима­ет имя поль­зовате­ля, а так­же прог­рам­мное имя при­виле­гии.

Про­вер­ку име­ни поль­зовате­ля я сде­лал с помощью фун­кции LookupAccountName(). Сама по себе она слу­жит для получе­ния SID (security identifier) поль­зовате­ля по его име­ни, но нам нич­то не меша­ет исполь­зовать ее прос­то для про­вер­ки име­ни поль­зовате­ля, ведь если компь­ютер не обна­ружит поль­зовате­ля с таким име­нем, то и вызов фун­кции при­ведет к ошиб­ке.

Про­вер­ку прог­рам­мно­го име­ни при­виле­гии я так­же вынес в отдель­ную фун­кцию.

Здесь алго­ритм схож: дер­гаем LookupPrivilegeValue(), если при­виле­гия есть — все ок, если нет — ошиб­ка.

Убе­див­шись, что пре­дос­тавлен­ные дан­ные вер­ны, инс­тру­мент вызыва­ет InitMode1(), которо­му так­же переда­ет имя поль­зовате­ля и имя при­виле­гии. Внут­ри этой фун­кции мы получа­ем хендл на LSA текуще­го компь­юте­ра (так как работа­ем с при­виле­гиями локаль­ного акка­унта) вызовом фун­кции GetPolicy().

По­луча­ют хендл на полити­ку через фун­кцию LsaOpenPolicy. Единс­твен­ная осо­бен­ность работы с LSA сос­тоит в том, что у нее свои коды оши­бок, которые прос­то через GetLastError() не пой­мать. Нуж­но получать зна­чение NTSTATUS, которое воз­вра­щает каж­дая фун­кция, работа­ющая с LSA, а затем переда­вать это зна­чение в LsaNtStatusToWinError() для пре­обра­зова­ния в понят­ный челове­чес­кому гла­зу код ошиб­ки.

По коду ошиб­ки мож­но понять, что сло­малось, — заг­лядывай в офи­циаль­ную докумен­тацию.

Ес­ли сис­тема выдала нам кор­рек­тный хендл и мы не получи­ли ERROR_ACCESS_DENIED, перехо­дим к навеши­ванию при­виле­гии поль­зовате­лю, к фун­кции AddUserPrivilege().

Теги: CSS