Nt authority system что за пользователь. Доступ к сетевой папке под NT AUTHORITY\NetworkService

NT AUTHORITY/SYSTEM ERROR,
сообщение XP - как удалить вирус

Если у Вас русская версия - то прежде чем качать обязательно смените язык.

Немного о самом вирусе:

Вчерашним вечером, примерно после 23 часов по Москве, во многих форумах стали появляться сообщения о странном поведении Windows 2000 и Windows XP при заходе в Сеть: система выдала сообщение об ошибке сервиса RPC и необходимости перезагрузки. После перезагрузки сообщение повторялось максимум через несколько минут, и этому не было конца.

Проведенное расследование показало, что виной всему начавшаяся сегодня эпидемия нового сетевого червя 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\Curr
entVersion\Run запись "windows auto update"="msblast.exe", после чего найти и стереть файл msblast.exe - это и есть тело червя. Более подробно о процедуре удаления червя можно прочитать на сайте Symantec.

На данный момент не все антивирусы обнаруживают червя - надеяться на защиту с их стороны можно будет только после выхода обновлений.
Помещено AHTOH 17-08-2003 в 23:29:

ОПАСНЫЙ ЧЕРВЬ! Nt Authority / System Error

__________________
Причиняю добро, наношу пользу...

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

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

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

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

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

Встроенные логины SQL Server 2005, BUILTIN\Администраторы , , NT AUTHORITY\SYSTEM , sa

Сразу же после установки SQL Server 2005 в контейнере Logins появляется набор логинов, которые создаются автоматически. Скорее всего, для подключения пользователей вы не будете их использовать. Тем не менее, возникают ситуации, в которых знание встроенных логинов может пригодиться (например, если будет нечаянно заблокирован ваш административный логин).

q BUILTIN\Администраторы (или BUILTIN\Administrators , в зависимости от языка операционной системы) - логину для этой группы Windows автоматически предоставляются права системного администратора SQL Server . Обратите внимание, что, если компьютер входит в домен, в эту группу автоматически попадает группа Domain Admins (Администраторы домена), и, таким образом, администраторы домена по умолчанию обладают полными правами на SQL Server . Если такая ситуация нежелательна, то этот логин можно удалить. Но и в этом случае администраторам домена получить доступ к данным SQL Server будет несложно.

q Имя_сервера 2005MSFTEUser$Имя_сервера $Имя_экземпляра , Имя_сервера 2005MSSQLUser$Имя_сервера $Имя_экземпляра ,Имя_сервера 2005SQLAgentUser$Имя_сервера $Имя_экземпляра - эти три логина для групп Windows используются для подключения соответствующих служб к SQL Server 2005. На уровне SQL Server 2005 с ними нет необходимости производить какие-то операции, поскольку все необходимые права уже предоставлены. В редких ситуациях вам может потребоваться добавить в эти группы на уровне Windows учетные записи, от имени которых работают службы SQL Server .

q NT AUTHORITY\NETWORK SERVICE - от имени этой учетной записи в Windows Server 2003 работают приложения ASP .NET , в том числе и службы Reporting Services (в Windows 2000 для этой цели используется учетная запись ASPNET ). Этот логин Windows используется для подключения к SQL Server Reporting Services . Ему автоматически предоставляются необходимые права на базы данных m aster , m sdb и на базы данных, используемые Reporting Services .

q NT AUTHORITY\SYSTEM - это локальная системная учетная запись операционной системы. Такой логин появляется в тех ситуациях, когда вы при установке настроили работу службы SQL Server от имени локальной системной учетной записи. Можно сказать, что при помощи этого логина SQL Server обращается к самому себе. Конечно же, этот логин обладает правами системного администратора SQL Server .

q sa (от System Administrator )- это единственный логин типа SQL Server , который создается по умолчанию. Он обладает правами системного администратора SQL Server , и отобрать эти права у него нельзя. Удалить этот логин также не получится. Зато его можно переименовать или отключить. Если для SQL Server 2005 будет настроена аутентификация только средствами Windows , то использовать этот логин для подключения к серверу не удастся.

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

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