Долой userlevel: повышаем привилегии до NT AUTHORITYSYSTEM в любой версии Windows. Доступ к сетевой папке под NT AUTHORITY\NetworkService Как разрешить доступ к другому компьютеры под учеткой NetworkService

ВНИМАНИЕ!!! ВНИМАНИЕ!!! ВНИМАНИЕ!!!
ОПАСНЫЙ ЧЕРВЬ!!!

Симптомы: При работе в сети внезапно выскакивает мессадж, сообщающий о том, что необходимо завершить все программы с сохранениями данных т.к. через 60 сек. произойдет перезагрузка.

Диагноз: Сетевой червь w32.Blaster.worm.Червь эксплуатирует найденную 16 июля уязвимость в сервисе RPC DCOM, присутствующую во всех операционных системах семейств Windows 2000, Windows XP и Windows 2003. Эта уязвимость - переполнение буфера, которое вызывается соответствующим образом составленным TCP/IP пакетом, пришедшим на порт 135, 139 или 445 атакуемого компьютера. Она позволяет как минимум провести DoS-атаку (DoS означает "Denial of Service", или "отказ в обслуживании", в данном случае - атакуемый компьютер перезагружается), а как максимум - выполнить в памяти атакуемого компьютера любой код. Новый червь при своем распространении проводит атаку на 135-й порт, и, в случае успеха, запускает программу TFTP.exe, с помощью которой скачивает на атакуемый компьютер свой исполняемый файл. При этом пользователю выдается сообщение об остановке сервиса RPC и последующей перезагрузке. После перезагрузки червь автоматически запускается и начинает сканировать доступные с компьютера сети на предмет компьютеров с открытым 135-м портом. При обнаружении таковых червь проводит атаку, и все повторяется сначала. Причем, судя по темпам распространения на данный момент, скоро червь выйдет на первое место в списках антивирусных компаний.

Лекарство: Существуют три способа защиты от червя. Во-первых, в бюллетене Microsoft приведены ссылки на патчи для всех уязвимых версий Windows, закрывающие брешь в RPC (эти патчи были выпущены еще 16 июля, поэтому тем, кто регулярно обновляет систему, беспокоиться не стоит). Во-вторых, если 135-й порт закрыт файрволлом - червь не сможет проникнуть на компьютер. В-третьих, в качестве крайней меры помогает отключение DCOM (подробно эта процедура описана в бюллетене от Microsoft). Таким образом, если вы еще не подверглись атаке червя - настоятельно рекомендуется как можно скорее скачать патч для вашей ОС с сервера Microsoft (например, воспользуйтесь службами Windows Update), либо настроить блокировку портов 135, 139 и 445 в файрволле. Если же ваш компьютер уже заражен (а появление сообщения об ошибке RPC однозначно означает, что он заражен), то необходимо выключить DCOM (иначе каждая следующая атака будет вызывать перезагрузку), после чего скачать и установить патч. Для уничтожения червя необходимо удалить из ключа реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run запись "windows auto update"="msblast.exe", после чего найти и стереть файл msblast.exe - это и есть тело червя. Более подробно о процедуре удаления червя можно прочитать на сайте Symantec.

На данный момент не все антивирусы обнаруживают червя - надеяться на защиту с их стороны можно будет только после выхода обновлений.

Если такое сообщение у вас пока не появлялось качайте патчи от Дяди Билла:

Тут линки на лекарство для NT 4.0 и 2000, 2003 Server

Недавно, точнее недельку назад хватанул червя, причем сроду такого не было за все мое чайничество! Время ночь - мастера не вызовешь, да и деньги только на карточке - в кормане рублей 200. Что делать, комп нужен до зарезу!

Через телефон лезу в поисковики и забиваю написанное в заголовке темы название - мама моя, что я узнаю - эта тварь живет в инете с 1993 года, причем корпорация microsoft знает о ней, создатель проинформировал их специально. На сегодняшний день этот червь попадая в ваш комп приобретает права админа и способен вытворять любые фокусы.

Исследовав несколько десятков форумов, перечитав за сутки сотни советов я не зная сна лезу в недра своей системы и трясущимися руками начинаю открывать папки и файлы, о которых прочитал.С упорством голодного волка я ищу причину, но... я слишком малоопытен для этого.Опять через телефон я лезу к нам на сайт и пишу одному из наших модераторов... Проблема очень каверзная и чтобы не мучить меня человек советует снести систему и установить новую, но я никогда самостоятельно этого не делал! Он рассказывает мне по телефону (не жалея денег на междугородние переговоры) как шаг за шагом это сделать, а я сижу и записываю. После этого он ждет результата, а я сижу и понимаю, что мне очень жаль накопленной информации... и я принимаю решение, если сносить - успею всегда, а сейчас поборюсь своими силами.

В любом случае я знал, что со мной рядом наши гуру и они посоветуют что сделать и как. Пока же на свой страх и риск я делаю следующее:

1) Баннер отключает комп на перезагрузку через 60 секунд - значит надо это время увеличить и я по совету одного форумчанина успеваю перевести часы на год назад !

2) уже спокойно и не торопясь просматриваю весь реестр и программы через AnvirTaskManager - он единственный спрашивал о появлении новой программы, но я как лох разрешил пропустить.

3) ничего не поняв там, я запускаю полное сканирование AVASTом, предварительно установив в настройках все расширения.

через 3,5 часа он выдал мне 6 зараженных файлов - вот они

win32 malware-gen(2 штуки)

Fakeinst-T (2шт)

Этих вредителей я просто удаляю, даже не пытаясь лечить.

4)Затем иду в Revo Unystailer и удаляю все что устанавливал за последние несколько дней, вместе с AnvirTaskManager и Reg Organizier.

5) Гружу AVZ и запускаю.

И тут возникает проблема - у меня диск разделен на два С и Н. С сканируется нормально и ничего не находит, только начинает сканировать Н весь комп впадает в ступор. Перезагружаю- баннер уже не выскакивает и я успокаиваюсь, инет работает, но не открывается мозила, иду через гуглхром.

Проверяю Н в on-line режиме. Чисто! Открываю Н, пытаюсь выделить папку - опять комп зависает намертво! После нескольких попыток открыть, сканирую еще раз AVASTом и не найдя ничего решаю - копировать все на С.

После копирования на С очищаю весь Н и лезу в копию - все работает!!!

Час назад скачал и обновил Мозилу теперь Радуюсь жизни. Проверил все и теперь обновлю доктора W curellt и поставлю на ночь -уже для успокоения совести! Так что имейте ввиду дорогие коллеги - не все так страшно. Для безопасности ваших компов сделайте как указано в прикрепленном файле!!!

Да будет здоровье у наших PCюков!!!

С уважением ко всем читателям Алексей!

One only has to "Run as administrator" a program to see in the Task Manager that its user is oneself and not Administrator, and this miracle is achieved just by the modification of the access token, not by replacing the SID.

Second, NT-AUTHORITY and SYSTEM are neither accounts nor groups, in spite of what say various other sources (even inside Microsoft). An SID usually has a name that is displayed whenever required. A user account will contribute its SID as principal SID to the access token, which will also determine the name displayed by various utilities. But the access token may contain additional SIDs, for example for all the groups to which belongs that user account. When checking permissions, Windows will look for any SID in the access token that has that permission.

Some well-known Windows SIDs will have names reported by Windows, although they do not really belong to any account.

The LocalSystem account is a predefined local account used by the service control manager. [...] Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs; these accounts have access to most system objects.

One can already see in the above text the confusion that reigns even in Microsoft documentation as regarding system SIDs, which are not exactly accounts nor groups - which are just a set of permissions. This confusion further extends to other utilities and articles, so any returned information should be carefully examined.

The Microsoft article Well-known security identifiers in Windows operating systems details all system SIDs, some of whom I include below:

Conclusion : NT-AUTHORITY\SYSTEM is the name of a Security ID, which is neither a group nor an account. It is displayed in Task Manager as SYSTEM when it is the principal SID of a program. The most I would call it is "a pseudo account".

Буквально за несколько дней перед сдачей номера в печать Metasploit обзавелся
свеженьким модулем, про который мы просто не могли не рассказать. Благодаря
новой команде getsystem, на скомпрометированной системе стало возможно перейти
из User Level в ring0, получив права NT AUTHORITY\SYSTEM! И это - в любых
версиях винды.

19 января 2010 года стала публичной 0-day уязвимость, позволяющая выполнить
повышение привилегий в любой версии Windows, начиная от NT 3.1, выпущенной в еще
в 1993 году, и заканчивая новомодной "семеркой". На exploit-db.com хакером Tavis
Ormandy были опубликованы как исходники сплоита KiTrap0d, так и скомпилированный
бинарник, готовый к применению. Опробовать оригинальный сплоит может любой
желающий. Для этого нужно лишь извлечь из архива vdmexploit.dll и vdmallowed.exe,
каким-либо образом передать на машину-жертву, и там запустить exe-шник. В
результате, независимо от того, под аккаунтом какого пользователя выполнен
запуск, появится консоль с привилегиями системного пользователя, то есть NT
AUTHORITY\SYSTEM. Проверки ради можно запустить сплоит на своей машине,
предварительно залогинившись в систему под обычным пользователем. После запуска
сплоита откроется новое окно cmd.exe с максимальными привилегиями.

Что это дает? Представь ситуацию, что сплоит пробивает некоторое приложение и
получает шелл на удаленном компьютере. Пускай это будет сплоит для Internet
Explorer - в этом случае у взломщика на руках будет доступ к системе с правами
того пользователя, под учеткой которого был запущен браузер. Не спорю, очень
часто это будет аккаунт с правами администратора (пользователь сам виноват), но
если нет? Вот здесь-то и можно заюзать KiTrap0d, чтобы поднять свои привилегии
до NT AUTHORITY\SYSTEM! Мало того, даже те пользователи, которые входят в группу
администратора, не могут обращаться к некоторым участкам системы, например, для
чтения хешей паролей пользователей (об этом ниже). А NT системный акаунт -
может! При всем этом, на момент публикации статьи ни одного патча со стороны
Microsoft, закрывающего уязвимость, выпущено не было.

Операция "Захват системы"

Демонстрировать в действии оригинальный сплоит мы не будем, потому как 25
января в Metasploit был добавлен новый скрипт, благодаря которому использовать
KiTrap0d стало еще удобнее. Первоначально попавший в базы модулей вариант был
нестабилен и срабатывал не всегда, но не прошло и полдня, как все ошибки были
устранены. Сейчас модуль закачивается вместе со всеми остальными обновлениями,
так что для установки достаточно выбрать пункт в меню "Metasploit update".
Теперь, имея доступ к удаленной системе, можно набрать "run kitrap0d" и привести
сплоит в действие. "Но раз пошла такая пьянка, реализуем-ка мы для этого дела
специальную команду", - подумали разработчики Metasploit. В результате
получилась замечательная такая команда "повысить привилегии", доступная через
расширение meterpreter, - нам она очень нравится:).

Итак, у нас есть доступ к удаленной системе (наглядный пример
эксплуатирования приведен в статье "Операция "Аврора") и мы находимся в консоли
метасплоита. Посмотрим, как у нас обстоят дела с правами:

meterpreter > getuid

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

meterpreter > use priv
Loading extension priv...success.
meterpreter > getsystem -h
Usage: getsystem
Attempt to elevate your privilege to that of local system.
OPTIONS:

H Help Banner.
-t The technique to use. (Default to "0").
0: All techniques available
1: Service - Named Pipe Impersonation (In Memory/Admin)
2: Service - Named Pipe Impersonation (Dropper/Admin)
3: Service - Token Duplication (In Memory/Admin)
4: Exploit - KiTrap0D (In Memory/User)

Как видно, сплоит KiTrap0D реализует лишь часть функциональности команды.
Если тебе удалось отхватить шелл с пользователем, у которого уже есть права
администратора, то для поднятия до уровня NT AUTHORITY\SYSTEM можно использовать
три другие техники (выбрать нужную позволяет ключ -t). Так или иначе, не указав
вообще никаких параметров, мы укажем метасплоиту, что тот может использовать
любой из подходов. В том числе и KiTrap0D, что повысит наши привилегии до уровня
"Система", какими бы правами мы сейчас ни обладали.

meterpreter > getsystem
...got system (via technique 4).

Ага, получили сообщение об успешном повышении привилегий, причем для атаки
использовался именно KiTrap0D - видимо, у него приоритет. Действительно ли мы
поднялись в системе? Проверим наш текущий UID (идентификатор пользователя):

meterpreter > getuid

Есть! Всего одна команда в консоли метасплоита и права NT AUTHORITY\SYSTEM у
нас в кармане. Далее, вообще говоря, можно все. При этом напомню, ни одного
патча от Microsoft на момент выхода журнала еще не было.

Дампим пароли

Раз уж на руках есть доступ к системному аккаунту, то надо извлечь из этого
что-нибудь полезное. В арсенале Metasploit есть замечательная команда hashdump -
более продвинутая версия известной утилиты pwdump. Более того, в последней
версии метасплоита включен переработанный вариант скрипта, который использует
модернизированный принцип извлечения LANMAN/NTLM хешей и пока не детектируется
антивирусами. Но смысл не в этом. Важно, что для выполнения команды hashdump
необходимы права NT AUTHORITY\SYSTEM. В противном случае программа выдаст ошибку
"[-] priv_passwd_get_sam_hashes: Operation failed: 87". Происходит это потому,
что LANMAN/NTLM-хеши паролей пользователей хранит в специальных ветвях реестра
HKEY_LOCAL_MACHINE\SAM и HKEY_LOCAL_MACHINE\SECURITY, которые недоступны даже
администраторам. Их можно прочитать только с привилегиями системного аккаунта.
Вообще говоря, использовать сплоит и затем команду hashdump для того, чтобы
локально извлечь из реестра хеша, совсем не обязательно. Но если такая
возможность есть, почему бы и нет?

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

meterpreter > run hashdump
[*] Obtaining the boot key...
[*] Calculating the hboot key using SYSKEY 3ed7[...]
[*] Obtaining the user list and keys...
[*] Decrypting user keys...
[*] Dumping password hashes...

Administrator:500:aad3b435b51404eeaad3b435b51404ee:...
Guest:501:aad3b435b51404eeaad3b435b51404ee:...
HelpAssistant:1000:ce909bd50f46021bf4aa40680422f646:...

Хеши получены. Остается скормить их какому-нибудь из брутфорсеров, например,
l0phtcrack .

Как вернуть привилегии?

Забавная ситуация произошла, когда я попытался вернуть права обычного
пользователя обратно. Найденная команда rev2self не срабатывала, и я по-прежнему
оставался "NT AUTHORITY\SYSTEM": видимо, она предназначена для работы с тремя
другими подходами, реализованными в getsystem. Оказалось, чтобы вернуть
привилегии, необходимо "украсть" токен процесса, запущенного тем пользователем,
который нам нужен. Поэтому отображаем все процессы командой ps и выбираем из них
подходящий:

meterpreter > ps
Process list
============
PID Name Arch User Path
--- ---- ---- ---- ----
0
4 System x86 NT AUTHORITY\SYSTEM
370 smss.exe x86 NT AUTHORITY\SYSTEM \SystemRoot\System32\smss.exe
...
1558 explorer.exe x86 WINXPSP3\user C:\WINDOWS\Explorer.EXE
...

Как мы видим, explorer.exe запущен как раз под обычным пользовательским
аккаунтом и имеет PID=1560. Теперь, собственно, можно и "украть токен", заюзав
команду steal_token. В качестве единственного параметра ей передается PID
нужного процесса:

meterpreter > steal_token 1558
Stolen token with username: WINXPSP3\user
meterpreter > getuid
Server username: WINXPSP3\user

Судя по полю "Server username", операция выполнилась успешно.

Как это работает?

Напоследок стоит рассказать о природе уязвимости, приведшей к появлению
сплоита. Брешь в защите возникает по вине ошибки в обработчике системного
прерывания #GP (который называется, nt!KiTrap). Из-за нее с привилегиями ядра
может быть выполнен произвольный код. Это происходит, потому что система
неправильно проверяет некоторые вызовы BIOS"а, когда на 32-битной x86-платформе
выполняется 16-битное приложение. Для эксплуатации уязвимости сплоит создает
16-битное приложение (%windir% \twunk_16.exe), манипулирует с некоторыми
системными структурами и вызывает функцию NtVdmControl(), чтобы стартовать
Windows Virtual DOS Machine (aka подсистма NTVDM), что в результате предыдущих
манипуляций приводит к вызову обработчика системного прерывания #GP и
срабатыванию сплоита. Кстати говоря, отсюда вытекает и единственное ограничение
сплоита, который срабатывает только на 32-битных системах. В 64-битных
операционках банально нет эмулятора для запуска 16-битных приложений.

Почему информация с готовым сплоитом попала в публичный доступ? О наличии
уязвимости автор сплоита информировал Microsoft еще в начале прошлого года и
даже получил подтверждение, что его отчет был принят к рассмотрению. Только воз
и ныне там. За год официального патча от компании не последовало, и автор решил
опубликовать информацию публично, надеясь, что дело пойдет быстрее. Посмотрим,
выйдет ли заплатка к моменту появления журнала в продаже:)?

Как обезопасить себя от сплоита

Поскольку полноценного обновления для решения уязвимости пока нет,
придется воспользоваться обходными путями. Самый надежный вариант -
отключить MSDOS и WOWEXEC подсистемы, что сразу лишит сплоит
функциональности, т.к. он больше не сможет вызывать функцию NtVdmControl()
для запуска NTVDM-системы. В старых версиях Windows это реализуется через
реестр, в котором нужно найти ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW
и добавить какой-нибудь символ к ее названию. Для современных ОС
устанавливать ограничение на запуск 16-битных приложений надо через
групповые политики. Для этого вызываем GPEDIT.MSC, далее переходим в раздел
"Конфигурация пользователя/Административные шаблоны/Компоненты Windows/Совместимость
приложений" и активируем опцию "Запрещение доступа к 16-разрядным
приложениям".

WWW

Описание уязвимости от автора сплоита:

http://archives.neohapsis.com/archives/fulldisclosure/2010-01/0346.html

Временное решение для устранения проблемы от Microsoft:

http://support.microsoft.com/kb/979682

WARNING

Информация представлена в образовательных целях. Использование ее в
противозаконных целях может повлечь за собой уголовную ответственность.

В рамках одного из проектов пришлось настраивать приложение, которое должно было выполнять резервное копирование базы данных на удаленном сервере MS SQL в файловое хранилище на другом сервере. Для доступа к удаленному хранилищу используется аккаунт, под которым работает MS SQL. В нашем случае MS SQL был запущен под локальной учетной записью Network Service (NT AUTHORITY\NetworkService). Естественно, у этой локальной учетной записи нет никаких полномочий на удаленной шаре. Можно кончено было переключить MS SQL на работу под доменной учетной записью (или ), однако можно настроить удаленный доступ к шаре и под NT AUTHORITY\NetworkService.

Как разрешить доступ к другому компьютеры под учеткой NetworkService

Если нужно предоставить доступ нескольким компьютерам, проще всего объединить их одной группой и предоставлять доступ уже группе. Создайте новую группу в AD и добавьте в нее все учетные записи компьютеров, которые должны обращаться к сетевому ресурсу с правами Network Service. В свойствах папки предоставьте необходимые разрешения группе.

А что с другими локальными аккаунтами?

При предоставлении доступа к ресурсу через учетную запись компьютера, предоставляется ли доступ всем остальным локальным учетным записям? Нет – доступ будет возможен только для учетных записей System и Network Service . Всем локальным учетным записям, которыми нужно разрешить доступ к сетевому ресурсу, придется предоставлять доступ индивидуально.