Что такое креды в it

IT-шный слэнг. Расширяем словарный запас.

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

IT-шный слэнг. Расширяем словарный запас.

Когда я привык, возникли новые проблемы. Моя жена стала просто шарахаться от новых словечек, которыми я раскидывался направо и налево. Естественно, и она скоро привыкла, но проблема не исчезла. Подчас непонимание снова возникает, если мне приходится общаться с новыми людьми. Не исключение и коллектив 7bloggers. Чтобы избежать непонимания и с вами, дорогие читатели, я решил приподать вам парочку уроков словообразования.

Вот несеолько слов, которыми я пользуюсь время от времени:

Баг, бага — ошибка, неисправность в программе. Это слово, наверняка, знакомо многим пользователям Windows. Вариант использования в повседневной жизни: «Что-то у тебя мотор стучит, наверное какая-то бага с клапанами…» (автолюбительское).

Фиксить — исправлять, чинить багу. Возможные варианты использования в повседневной жизни: «Пофиксить банкира в его же автомобиле» (киллерское), «Фиксим телевизоры, ноутбуки и другую электронную технику. Цена договорная» (предпринимательское).

Факапить — ломать, совершать ошибку, имеющую нехорошие последствия. Варианты: «опять зафакапил экзамен по химии» (студенческое), «‘Кто зафакапил мой стул?’ — вскричал младший из медведей» (сказочное).

Креды — совокупность логина и пароля для какого-либо сервиса. Например, креды от аськи или от мыла. Очень удобное слово, краткое и лаконичное.

Хардкорить — дествие, нарушающее динамичность системы. Например, креды (это слово вы должны уже знать) заранее зашитые в код программы. Пример: «семь раз отмерь, один раз захардкорь» (житейское).

Апрувить — соглашаться, давать согласие. Например: «Уважаемые молодожены, заапрувьте ваш брак подписями в брачном контракте» (семейное).

Имплементить — реализовывать функционал, проще говоря, что-то делать. Пример: «Пионер заимлементил скворешник за полчаса» (социалистическое).

Таска — задание, некая работа. Пример: «Моя таска на этот семестр — написать диссертацию» (научное).

Фича — то же что и бага, только заказчику доказывают, что это удобно и специально так задумано. Пример: «Посмотрите на этот диван еврокнижку. Вот та дырка посередине — это специальная фича, разработанная ведущими дизайнерами» (от продавцов).

Манагер — не путайте с менеджером. Хотя понятия схожие. Манагер — это неквалифицированный в определенной области менеджер, который требует от программистов, чтобы программа умела варить кофе или убирать кабинет, а от инженеров требует сверхпроводимости и идеального белого шума.

Ну вот, пользуйтесь на здоровье! Было бы очень интересно узнать, какой профессиональный слэнг используете вы.

Краткий^2 словарь IT ⁠ ⁠

Краткий^2 словарь IT Сленг, IT, Словарь, Длиннопост

Вот несеолько слов, которыми я пользуюсь время от времени:

Таска — задание, некая работа. Пример: «Моя таска на этот семестр — написать диссертацию» (научное).

Cred: Pluggable Authentication¶

Cred is a pluggable authentication system for servers. It allows any number of network protocols to connect and authenticate to a system, and communicate to those aspects of the system which are meaningful to the specific protocol. For example, Twisted’s POP3 support passes a “username and password” set of credentials to get back a mailbox for the specified email account. IMAP does the same, but retrieves a slightly different view of the same mailbox, enabling those features specific to IMAP which are not available in other mail protocols.

Cred is designed to allow both the backend implementation of the business logic — called the avatar — and the authentication database — called the credential checker — to be decided during deployment. For example, the same POP3 server should be able to authenticate against the local UNIX password database or an LDAP server without having to know anything about how or where mail is stored.

To sketch out how this works — a “Realm” corresponds to an application domain and is in charge of avatars, which are network-accessible business logic objects. To connect this to an authentication database, a top-level object called a Portal stores a realm, and a number of credential checkers. Something that wishes to log in, such as a Protocol , stores a reference to the portal. Login consists of passing credentials and a request interface (e.g. POP3’s IMailbox ) to the portal. The portal passes the credentials to the appropriate credential checker, which returns an avatar ID. The ID is passed to the realm, which returns the appropriate avatar. For a Portal that has a realm that creates mailbox objects and a credential checker that checks /etc/passwd, login consists of passing in a username/password and the IMailbox interface to the portal. The portal passes this to the /etc/passwd credential checker, gets back a avatar ID corresponding to an email account, passes that to the realm and gets back a mailbox object for that email account.

Putting all this together, here’s how a login request will typically be processed:

../../_images/cred-login.png

Cred objects¶

The Portal¶

This is the core of login, the point of integration between all the objects in the cred system. There is one concrete implementation of Portal, and no interface — it does a very simple task. A Portal associates one (1) Realm with a collection of CredentialChecker instances. (More on those later.)

If you are writing a protocol that needs to authenticate against something, you will need a reference to a Portal, and to nothing else. This has only 2 methods —

The docstring is quite expansive (see twisted.cred.portal ), but in brief, this is what you call when you need to call in order to connect a user to the system. Typically you only pass in one interface, and the mind is None . The interfaces are the possible interfaces the returned avatar is expected to implement, in order of preference. The result is a deferred which fires a tuple of:

interface the avatar implements (which was one of the interfaces passed in the *interfaces tuple)
an object that implements that interface (an avatar)
logout, a 0-argument callable which disconnects the connection that was established by this call to login

The logout method has to be called when the avatar is logged out. For POP3 this means when the protocol is disconnected or logged out, etc..

which adds a CredentialChecker to the portal. The optional list of interfaces are interfaces of credentials that the checker is able to check.

The CredentialChecker¶

This is an object implementing ICredentialsChecker which resolves some credentials to an avatar ID.

Whether the credentials are stored in an in-memory data structure, an Apache-style htaccess file, a UNIX password database, an SSH key database, or any other form, an implementation of ICredentialsChecker is how this data is connected to cred.

A credential checker stipulates some requirements of the credentials it can check by specifying a credentialInterfaces attribute, which is a list of interfaces. Credentials passed to its requestAvatarId method must implement one of those interfaces.

For the most part, these things will just check usernames and passwords and produce the username as the result, but hopefully we will be seeing some public-key, challenge-response, and certificate based credential checker mechanisms soon.

A credential checker should raise an error if it cannot authenticate the user, and return twisted.cred.checkers.ANONYMOUS for anonymous access.

The Credentials¶

Oddly enough, this represents some credentials that the user presents. Usually this will just be a small static blob of data, but in some cases it will actually be an object connected to a network protocol. For example, a username/password pair is static, but a challenge/response server is an active state-machine that will require several method calls in order to determine a result.

Twisted comes with a number of credentials interfaces and implementations in the twisted.cred.credentials module, such as IUsernamePassword and IUsernameHashedPassword .

The Realm¶

A realm is an interface which connects your universe of “business objects” to the authentication system.

IRealm is another one-method interface:

requestAvatar (avatarId, mind, *interfaces)

This method will typically be called from ‘Portal.login’. The avatarId is the one returned by a CredentialChecker.

Note that avatarId must always be a string. In particular, do not use unicode strings. If internationalized support is needed, it is recommended to use UTF-8, and take care of decoding in the realm.

The important thing to realize about this method is that if it is being called, the user has already authenticated . Therefore, if possible, the Realm should create a new user if one does not already exist whenever possible. Of course, sometimes this will be impossible without more information, and that is the case that the interfaces argument is for.

Since requestAvatar should be called from a Deferred callback, it may return a Deferred or a synchronous result.

The Avatar¶

An avatar is a business logic object for a specific user. For POP3, it’s a mailbox, for a first-person-shooter it’s the object that interacts with the game, the actor as it were. Avatars are specific to an application, and each avatar represents a single “user” .

The Mind¶

As mentioned before, the mind is usually None , so you can skip this bit if you want.

Masters of Perspective Broker already know this object as the ill-named “client object” . There is no “mind” class, or even interface, but it is an object which serves an important role — any notifications which are to be relayed to an authenticated client are passed through a ‘mind’. In addition, it allows passing more information to the realm during login in addition to the avatar ID.

The name may seem rather unusual, but considering that a Mind is representative of the entity on the “other end” of a network connection that is both receiving updates and issuing commands, I believe it is appropriate.

Although many protocols will not use this, it serves an important role. It is provided as an argument both to the Portal and to the Realm, although a CredentialChecker should interact with a client program exclusively through a Credentials instance.

Unlike the original Perspective Broker “client object” , a Mind’s implementation is most often dictated by the protocol that is connecting rather than the Realm. A Realm which requires a particular interface to issue notifications will need to wrap the Protocol’s mind implementation with an adapter in order to get one that conforms to its expected interface — however, Perspective Broker will likely continue to use the model where the client object has a pre-specified remote interface.

(If you don’t quite understand this, it’s fine. It’s hard to explain, and it’s not used in simple usages of cred, so feel free to pass None until you find yourself requiring something like this.)

Responsibilities¶

Server protocol implementation¶

The protocol implementor should define the interface the avatar should implement, and design the protocol to have a portal attached. When a user logs in using the protocol, a credential object is created, passed to the portal, and an avatar with the appropriate interface is requested. When the user logs out or the protocol is disconnected, the avatar should be logged out.

The protocol designer should not hardcode how users are authenticated or the realm implemented. For example, a POP3 protocol implementation would require a portal whose realm returns avatars implementing IMailbox and whose credential checker accepts username/password credentials, but that is all. Here’s a sketch of how the code might look — note that USER and PASS are the protocol commands used to login, and the DELE command can only be used after you are logged in:

Application implementation¶

The application developer can implement realms and credential checkers. For example, they might implement a realm that returns IMailbox implementing avatars, using MySQL for storage, or perhaps a credential checker that uses LDAP for authentication. In the following example, the Realm for a simple remote object service (using Twisted’s Perspective Broker protocol) is implemented:

Deployment¶

Deployment involves tying together a protocol, an appropriate realm and a credential checker. For example, a POP3 server can be constructed by attaching to it a portal that wraps the MySQL-based realm and an /etc/passwd credential checker, or perhaps the LDAP credential checker if that is more useful. The following example shows how the SimpleRealm in the previous example is deployed using an in-memory credential checker:

Cred plugins¶

Authentication with cred plugins¶

Cred offers a plugin architecture for authentication methods. The primary API for this architecture is the command-line; the plugins are meant to be specified by the end-user when deploying a TAP (twistd plugin).

For more information on writing a twistd plugin and using cred plugins for your application, please refer to the Writing a twistd plugin document.

Building a cred plugin¶

To build a plugin for cred, you should first define an authType , a short one-word string that defines your plugin to the command-line. Once you have this, the convention is to create a file named myapp_plugins.py in the twisted.plugins module path.

Below is an example file structure for an application that defines such a plugin:

MyApplication/
- setup.py
- myapp/
  - __init__.py
  - cred.py
  - server.py
  - plugins/
    - myapp_plugins.py
    Once you have created this structure within your application, you can create the code for your cred plugin by building a factory class which implements ICheckerFactory . These factory classes should not consist of a tremendous amount of code. Most of the real application logic should reside in the cred checker itself. (For help on building those, scroll up.)
    
    The core purpose of the CheckerFactory is to translate an argstring , which is passed on the command line, into a suitable set of initialization parameters for a Checker class. In most cases this should be little more than constructing a dictionary or a tuple of arguments, then passing them along to a new checker instance.
    
    For more information on how your plugin can be used in your application (and by other application developers), please see the Writing a twistd plugin document.
    
    Делегируй меня полностью, или Новый взгляд на RBCD-атаки в AD
    
    «Злоупотребление ограниченным делегированием Kerberos на основе ресурсов» — как много в этом звуке!
    
    Точнее уже не просто звуке и даже не словосочетании, а целом классе наступательных техник в доменной среде Active Directory. Вот уже как больше трех лет, казалось бы, вполне себе легитимный механизм, помогающий трехголовому псу стоять на страже даже там, где нет этих ваших «тикетов», служит грозным оружием всех пенетраторов Windows-сетей. Не знаю никого, кто использовал бы RBCD по назначению, честно.
    
    В этой статье хотелось бы остановиться на таком интересном пограничном случае применения этой атаки, как RBCD с UPN-ами, но не SPN-ами.
    
    1. Сферическое RBCD в вакууме
    
    Ограниченное делегирование на основе ресурсов (Resource-Based Constrained Delegation, RBCD) появилось в ОС Windows Server 2012 и представляет из себя концепцию олицетворения пользователей сервером (то есть сервисной учетной записью) в ситуации, когда пользователь проходит проверку подлинности по паролю, а серверу нужно выполнить то или иное действие от его имени по Kerberos-билету в информационной системе по соседству.
    
    Классический пример, который приводится для объяснения, зачем вообще нужны разные виде делегирования в AD — это пример с веб-сервером и базой данных. Не будем отходить от этой традиции и мы, поэтому посмотрим на рисунок ниже.
    
    Сферическое делегирование в вакууме
    
    Что здесь происходит:
    
    Пользователь snovvcrash проходит проверку подлинности на веб-сервере WEB01 , предоставляя в качестве «доказательства аутентичности» свой пароль. Аутентификация проходит по протоколу NTLM, потому что snovvcrash находится за пределами доменной сети и не обладает возможностью передать билет Kerberos.
    
    Веб-сервер видит, что ему не дали тикета в ходе аутентификации, поэтому в игру вступает транзитное расширение протокола Kerberos S4U2self (Service for User to Self), предназначенное для получения «пробрасываемого» (Forwardable, билет с правом передачи) TGS-билета на самого себя у контроллера домена от имени целевого пользователя. Это позволит веб-серверу запросить следующий TGS-билет на службу БД SQL01 в шаге 3.
    
    Активация следующей фазы транзитного расширения Kerberos – S4U2proxy (Service for User to Proxy). В ходе этой процедуры веб-сервер может предоставить в качестве доказательства TGS-билет из шага 2 для получения TGS-билета на службу SQL01 от имени целевого пользователя snovvcrash .
    
    Веб-сервер получает возможность получения доступа к базе данных SQL01 , олицетворяя пользователя snovvcrash .
    
    Важно отметить, что в концепции RBCD-делегирования право получения доступа к службе SQL01 веб-сервером WEB01 с олицетворением других пользователей определяет сама служба SQL01 . Данный процесс происходит путем записи в свойство с непроизносимым называнием msDS-AllowedToActOnBehalfOfOtherIdentity объекта службы (компьютера) SQL01 значения SID-а учетной записи WEB01$ . Это отличает ограниченное делегирование на основе ресурсов от классического ограниченного делегирования (Kerberos Constrained Delegation, KCD).
    
    2. Злоупотребление сферическим RBCD в вакууме
    
    — «Круто, и что со всем этим делать?», — спросил системный администратор.
    
    — «Злоупотребл#ть, разумеется», — ответил пентестер.
    
    В 2019 году исследователь Элад Шамир (@elad_shamir) опубликовал пугающий своими размерами ресерч Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory, ставший краеугольным камнем в развитии методов злоупотребления механизмом ограниченного делегирования на основе ресурсов.
    
    В этом пункте я не буду подробно останавливаться на теоретической части эксплуатации RBCD Abuse, так как материалов на просторах Интернета хватает (в конце оставлю ссылки). Вместо этого давайте лучше вместе проведем эту атаку «вживую», чтобы более плавно подойти к тем самым нововведениям, которые недавно были открыты специалистом Джеймсом Форшоу (@tiraniddo). Нетерпеливые могут сразу прыгать в пункт 3.
    
    2.1 Эксплуатация RBCD Abuse с Windows
    
    С данной атакой я впервые познакомился в момент прохождения лаборатории Hades на Hack The Box, и в тот момент это казалось самым сложным, что вообще бывает в AD-эксплуатации (как же я ошибался, да?). Классический вариант абьюза RBCD проводится с Windows с помощью тройки благородных инструментов: Powermad, PowerView, Rubeus.
    
    Допустим, мы скомпрометировали доменного пользователя TINYCORP\AngaraUser , обладающего правом на запись в объект машины MOSCOW.tinycorp.net . В этом случае для получения административного доступа к службам MOSCOW нам понадобится вспомогательный машинный аккаунт (или любая другая УЗ с записью SPN) для того, чтобы вписать значение его SID-а в свойство msDS-AllowedToActOnBehalfOfOtherIdentity объекта MOSCOW и далее делегировать этой вспомогательной машине право олицетворения привилегированных (или других) пользователей в отношении атакуемого хоста MOSCOW .
    
    Машинный аккаунт (или, другими словами, сервисную учетку с записями SPN) атакующий может создать в домене Active Directory, обладая минимальным аутентифицированным доступом. Свойство ms-DS-MachineAccountQuota , по умолчанию равное 10, определяет количество компьютеров, разрешенных для ввода в домен обычными пользователями одновременно. Этим и пользуется инструмент Powermad.
    
    Создаем вспомогательную машинную учетку (Windows)
    
    Теперь, обладая подконтрольной УЗ TINYCORP\AngaraMachine$ , мы можем скрафтить дескриптор безопасности DACL, разрешающий доступ (Allow) AngaraMachine$ , и присвоить его свойству msDS-AllowedToActOnBehalfOfOtherIdentity машинного объекта MOSCOW . Сделать это можно, например, с помощью PowerView, если нет возможности использовать стандартный модуль ActiveDirectory.
    
    Изменяем свойство msDS-AllowedToActOnBehalfOfOtherIdentity (Windows) Смотрим DACL внутри msDS-AllowedToActOnBehalfOfOtherIdentity
    
    Ну а теперь мы просто используем Rubeus для проведения полной цепочки атаки S4U, в ходе которой, как было описано раньше, будут выполнены задействованы процедуры S4U2self & S4U2proxy для получения TGS-билета Kerberos и олицетворения привилегированной УЗ TINYCORP\Administrator в отношении служб HOST и HTTP (целимся в WinRM) компьютера MOSCOW .
    
    Проводим атаку S4U (Windows)
    
    Если лень делать все вышеописанное вручную, можно воспользоваться актуальным форком PowerView, где появился командлет Set-DomainRBCD , частично автоматизирующий процесс, описанный выше. Пример использования можно подсмотреть в моем прохождении другой лабы RPG с Hack The Box.
    
    2.2 Эксплуатация RBCD Abuse с Linux
    
    То же самое может быть легко проделано с Linux-хоста благодаря коллекции скриптов Impacket. Покажем это.
    
    Создаем машинную учетку с помощью addcomputer.py.
    
    Создаем вспомогательную машинную учетку (Linux)
    
    Навешиваем ее на атакуемый хост MOSCOW , как разрешенную для делегирования S4U с помощью rbcd.py.
    
    Изменяем свойство msDS-AllowedToActOnBehalfOfOtherIdentity (Linux)
    
    Запрашиваем тикет с олицетворением администратора домена в отношении службы CIFS (целимся в DCE/RPC) компьютера MOSCOW с помощью getST.py.
    
    Проводим атаку S4U (Linux)
    
    Это всего лишь один пример, как можно злоупотреблять механизмом RBCD «в лоб». В связке с другими цепочками атак такое злоупотребление мутирует, превращаясь в очень опасные формы повышения привилегий — от локальных атак для LPE (например, в связке с относительно новой атакой Kerberos Relay) до получения прав администратора домена в несколько команд (говорили об этом в этой статье).
    
    Интересное чтиво по теме
    
    3. Атакуем конфигурации RBCD без вспомогательной машинной УЗ
    
    «Итак, а в чем же новый взгляд, snovvcrash?» — спросите вы.
    
    Так вот. Несколько месяцев назад исследователь команды Google Project Zero Джеймс Форшоу в треде обсуждения недавнего на тот момент вторника обновлений Microsoft в Твиттере выдвинул поистине гениальное в своей простоте предположение о том, что нам по сути-то и не нужна машинная учетная запись для делегирования ей привилегий — для этого хватит и учетки простого пользователя. В последствии это предположение было подтверждено им же в небольшой заметке, легшей в основу этой публикации.
    
    Почему вообще это важно? Все чаще и чаще на проектах мы сталкиваемся с тем, что свойство ms-DS-MachineAccountQuota в AD равно 0 (как мы и рекомендуем в своих отчетах). Таким образом, у низкопривилегированных пользователей больше нет прав для создания сервисных учеток, а ввод новых компьютеров в домен делегирован системным администраторам. Но продолжать ломать же нужно �� Поэтому предлагаю рассмотреть новый вектор абьюза RBCD с единственной подконтрольной УЗ обычного пользователя. Но для начала постараемся понять, а для чего вообще нам была нужна машинная учетка?
    
    Все просто. Для того, чтобы служба KDC (Key Distribution Center) контроллера домена могла зашифровать TGS-билеты, выдаваемые нам в процессе взаимодействий S4U, она должна знать, какой ключ для этого использовать. В случае с машинной УЗ это не вызывает проблем, так как ее долговременный ключ ищется KDC по значению записей SPN (Service Principal Name), по умолчанию создаваемых для нового хоста.
    
    Service Principal Name
    
    Однако, если я укажу другую (свою же) пользовательскую учетку для записи в дескриптор свойства msDS-AllowedToActOnBehalfOfOtherIdentity , цепочка S4U сфейлится, не пройдя фазу S4U2self. Ошибка KDC_ERR_S_PRINCIPAL_UNKNOWN непрозрачно намекает на свою природу: KDC не может найти ключ по значению SPN в силу его отсутствия.
    
    Никаких тебе S4U с УЗ пользователя
    
    Но! Мы не должны забывать, что у пользовательских УЗ также есть принципиал, однозначно их характеризующий — это UPN (User Principal Name).
    
    User Principal Name
    
    Из исследования Элада Шамира о злоупотреблении механизмом Shadow Credentials мы знаем о существовании механизма U2U (User to User), подобного S4Uself, однако применяемого к пользовательским учетным записям. Будучи используемым как составляющая протокола PKINIT, U2U позволяет пользователю получить доступ к своему же долговременному ключу (хешированному паролю) для того, чтобы использовать его в ходе NTLM-аутентификации в приложениях, не поддерживающих Kerberos-аутентификацию.
    
    В ходе процедуры U2U пользователь запрашивает у KDC билет TGS, содержащий NT-хеш пользователя в структуре PAC_CREDENTIAL_INFO , зашифрованной на кратковременном сессионном ключе. Таким образом пользователь может расшифровать эту структуру и извлечь свой NT-хеш.
    
    Атака на PKINIT (изображение – posts.specterops.io)
    
    В Rubeus есть возможность запроса TGS-билета, используя U2U. Поэтому почему бы нам с этим не поиграть? Для начала я запрошу самый обычный TGT-билет.
    
    Запрашиваем TGT-билет
    
    Запомним его сессионный ключ, он понадобится нам позже. Далее, согласно схеме выше, я запрошу TGS-билет по протоколу U2U, предоставляя в качестве «доказательства» свой TGT-билет. Согласно документации Rubeus мы можем отправить этот же TGT-билет вместе с аргументом /tgs (этого требует PKINIT), а также указать опцию /targetuser для того, чтобы в структуре PAC_CREDENTIAL_INFO оказался аутентификатор пользователя, которого мы хотим олицетворить (например, администратора).
    
    Запрашиваем TGS-билет по протоколу U2U
    
    Теперь я могу использовать этот TGS в роли доказательства того, что я прошел этап S4Uself, и таким образом пропустить его инициирование в модуле s4u . Однако нас ждет новая сложность.
    
    И снова никаких тебе S4U с УЗ пользователя
    
    Ошибка KDC_ERR_BADOPTION , по словам автора оригинального исследования, может означать, что KDC не смог расшифровать TGS-билет, отправленный ему на шаге S4U2proxy. Почему так произошло? В силу того, что мы «считерили» на этапе S4Uself, оправив собственный TGS-билет, полученный в результате U2U, контроллер домена не смог его расшифровать, так как попытался это сделать с помощью долговременного ключа (NT-хеша) пользователя AngaraUser . Но этот билет зашифрован на сессионном ключе, а не на долговременном! Что если сменить пароль пользователю AngaraUser на значение кратковременного сессионного ключа его TGT? Возможно, в этом случае, KDC пойдет в NTDS, извлечет NT-хеш AngaraUser (уже совпадающий с сессионным ключом билета TGT) и сумеет успешно расшифровать тикет? Спойлер: да.
    
    Как мы можем изменить NT-хеш пароля AngaraUser , а не само значение пароля? Некоторое время назад я портировал скрипт NTLMInjector.ps1 на Python для Impacket (см. smbpasswd.py), где использовал вызов мало документированной функции SamrSetInformationUser, принимающей в качестве одного из аргументов структуру SamrSetInformationUser.Buffer . Внутри этой структуры мы можем указать новую пару LM:NT хешей, которые будут установлены для целевого пользователя.
    
    Этично ли менять пароли пользователей в «боевой» ситуации на проекте?
    
    Однозначно нет. Однако почти всегда при проведении атак Password Spraying (T1110.003) мы обнаруживаем ~~Богом~~ заказчиком забытые учетки, пароли которых давно просрочены. Это может означать, что ими уже давно никто не пользуется и что смена их пароля не принесет вреда бизнес-процессам / рабочим процессам сотрудников компании. После согласования такого вмешательства мы можем это сделать, ведь у реальных злоумышленников не будет этических ограничений ��
    
    Я использую тот сессионный ключ, который мы запомнили, для смены долговременного ключа пользователя AngaraUser с помощью smbpasswd.py.
    
    Примечание № 1: в ходе тестирования я использую креды доменадмина для инжекта NTLM-хешей, однако чуть позже мы сделаем так, чтобы такую смену «пароля» (хешей) мог проворачивать сам низкопривилегированный пользователь AngaraUser .
    
    Примечание № 2: прежде чем менять хеш УЗ, из-под которой вы работаете в текущем сеансе, рекомендую убедиться, что парольная политика в домене впоследствии позволит сменить его еще раз на такое значение, для которого вы знаете пароль в открытом виде (другими словами, что максимальный срок действия пароля > 0). В противном случае, придется довольствоваться лишь аутентификацией по техникам Pass-the-Hash / Overpass-the-Hash.
    
    Устанавливаем новые хеши для AngaraUser
    
    И теперь я снова попробую провести атаку S4U.
    
    Now we’re rocking!
    
    Вот и все, мы провели классическую RBCD-атаку без вспомогательной УЗ с записью SPN!
    
    4. Автоматизация
    
    Все это, конечно, круто, но у нас есть одна неразрешенная проблема: пароль пользовательской УЗ мы поменяли с Linux-тачки, кустарным методом, да еще и заюзали для этого привилегированные креды. На наше счастье рядом со скриптом NTLMInjector.ps1 лежит SetNTLM.ps1, еще и писанный на C#. Он позволит нам изменить пароль целевой УЗ с ее же привилегиями через вызов недокументированной функции SamiChangePasswordUser .
    
    В smbpasswd.py тоже есть реализация этого API, но почему-то мне не удалось завести это дело так, чтобы хеш не помечался как STATUS_PASSWORD_EXPIRED после его установки через Impacket. Это даже к лучшему, потому что было решено допилить функционал Рубеуса для полной автоматизации описанного процесса.
    
    4.1 Rubeus
    
    Как говорит автор изначального ресерча, в Рубеусе уже все готово для проведения атаки, просто в CLI модуля s4u нет нужных аргументов. Чтобы исправить это, достаточно «протащить» флаг bool u2u = true до функции NewTGSReq класса Rubeus/lib/krb_structures/TGS_REQ.cs , вызываемой в Rubeus/lib/S4U.cs .
    
    Rubeus/lib/S4U.cs
    
    Ну и, разумеется, позаимствовать сам код установки NTLM-хешей из скрипта, указанного выше.
    
    Rubeus/lib/Samr.cs
    
    Компилируем, и вуаля — у нас готов кастомный Рубеус с новым флагом /u2u для модуля s4u, умеющий проводить S4U-атаку с пользюковой учеткой!
    
    Мой PR доступен на Гитхабе, однако не думаю, что мы увидим его в «мастере», так как @exploitph отчетливо дал понять, что этот функционал слишком инвазивный, чтобы быть в апстриме утилиты.
    
    4.2 KrbRelayUp
    
    Но и это еще не все! ~~Заказывая у нас пентест, вы получите~~ Я также решил форкнуть нашумевший недавно KrbRelayUp, чтобы вооружить модуль RELAY для проведения этого подвида RBCD-атаки, что привело к появлению в нем опции -u2u .
    
    Там было совсем немного изменений, но если кто-то захочет посмотреть — вам сюда.
    
    5. Вместо заключения
    
    Следуя хорошей традиции усложнения себе, как пентестерам, жизни, приведем перечень рекомендаций для снижения риска от подобных атак:
    
    Первое и, пожалуй, самое главное — включаем механизмы защиты служб LDAP (LDAP Signing) и LDAPS (LDAP Channel Binding). Нет релея на LDAP(S) — нет львиной доли злонамеренных изменений свойства msDS-AllowedToActOnBehalfOfOtherIdentity у объектов машин в Active Directory.
    
    Второе и почти не менее важное — запрещаем олицетворение критически важных УЗ (например, администраторов домена) при делегировании привилегий путем включения их в группу «Защищенные пользователи» или установкой флага AccountNotDelegated в UAC.
    
    Третье — если в вашем домене ms-DS-MachineAccountQuota все еще равна 10, пора задуматься о ~~пентесте~~ безопасности и срочно сбросить его до нуля.
    
    Четвертое — мониторить попытки эксплуатации RBCD Abuse и Kerberos Relay. Для этого рекомендуем обратить внимание на следующие события ИБ: 4741, 4673, 5156, 5136, 4768 и 4769.
    
    Пятое и заключительное — убедиться в активности сильного антивирусного решения на всех сетевых узлах, до которых могут дотянуться обычные пользователи (рабочие станции, терминальники).
    Похожие публикации: