Trusted users root

Атаки на трасты между доменами

Рано или поздно в ходе пентеста встает задача компрометации всего леса — при условии, что есть какие-либо права в одном из доменов. В такие моменты возникает куча вопросов о трастах, их свойствах и самих атаках. Попробуем во всем этом разобраться.

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

• деревья доменов;
• леса доменов.

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

• глобальный каталог;
• пространство имен;
• схему.

Деревья доменов могут объединяться в леса. При создании леса доменов устанавливаются транзитивные доверительные отношения, и все компьютеры в лесу имеют общие:

• глобальный каталог;
• схему.

Ниже представлена таблица с типами доверия между доменами и их свойствами.

Более наглядно типы доверий между доменами проиллюстрированы на картинке ниже.

Транзитивность (Transitivity)

Транзитивность нужна для определения доверия за пределами двух доменов, между которыми оно было сформировано, и используется для расширения отношений доверия с другими доменами. Если мы добавляем к домену дочерний домен, между родительским и дочерним доменами устанавливаются двусторонние доверительные отношения. Эти отношения транзитивны, т.е. если домен A доверяет домену D и домен D доверяет домену E, то домен A доверяет и домену E.

Нетранзитивное доверие можно использовать для отказа доверия с другими доменами.

Направление (Direction)

Путь доверительных отношений — это ряд доверительных отношений между доменами, к которому должны поступать запросы на проверку подлинности. Иными словами, прежде чем аутентифицировать пользователя, определяется доверие между доменами. Чтобы пользователи домена A могли получить доступ к ресурсам домена D, домен D должен доверять домену A.

Направление доверия бывает двух типов:

• одностороннее;
• двустороннее.

Одностороннее доверие — это однонаправленный путь проверки подлинности, который создается между двумя доменами. В однонаправленном доверии между доменом A и доменом B пользователи в домене B имеют доступ к ресурсам в домене A. Однако пользователи в домене A не имеют доступа к ресурсам в домене B. Такой тип доверия не транзитивен.

Двустороннее доверие — это комбинация двух однонаправленных доверительных отношений. В двунаправленном доверии между доменами A и B их пользователи имеют доступ к ресурсам обоих доменов. Такой тип доверия транзитивен.

Направление доверия всегда противоположно направлению доступа. Показательная схема от Microsoft ниже:

Ссылки для более глубокого ознакомления с типами доверий:

Kerberos между доверенными доменами

Рассмотрим пример. Client пытается получить доступ к Server.

С 1 по 3 пункты происходят стандартные действия при использовании протокола Kerberos.

• Пароль преобразуется в NTLM-хеш, временная метка шифруется хешем и отправляется на KDC в качестве аутентификатора в запросе TGT-тикета (AS-REQ). Контроллер домена (KDC) проверяет информацию пользователя и создает TGT-тикет.
• TGT-тикет шифруется, подписывается и отправляется пользователю (AS-REP). Только служба Kerberos (KRBTGT) может открыть и прочитать данные из TGT-тикета.
• Пользователь представляет TGT-тикет контроллеру домена при запросе TGS-тикета (TGS-REQ). Контроллер домена открывает TGT-тикет и проверяет контрольную сумму PAC.

Изменения начинаются с пункта 4: появляется inter-realm TGT-тикет, так называемый реферальный тикет, который шифруется/подписывается inter-realm ключом, создаваемым из доверенного пароля. Доверенный пароль задается при установке доверительных отношений и известен обоим контроллерам домена. Используя inter-realm TGT-тикет, пользователь домена 1 может запросить TGS-тикет для доступа к ресурсам домена 2.

NTLM между доверенными доменами

Google is in the process of removing CNNIC as a trusted root.

I wanted to make sure i don’t have them in my certificate store anyway. So i check certmgr.msc, and look for them. They are neither in my:

• Trusted Root Certificate Authorities, nor
• Third-party Root Certification Authorites

Then i browse to their site

Then i browse to https://www.cnnic.cn/, to confirm that their certificate is invalid. And while there are the usual warnings about css and images being unsecure (and warnings about using weak encryption), the certificate itself is valid!:

So I decide to view the certificate, so I can see its certification chain. Surely they must chain back to a trusted root that my computer does consider valid.

But the very act of viewing the certificate causes it to be added to my Trusted Root store:

I’m fairly certain that they’re not hacking Chrome on-the-fly like that. So how is this certificate ending up in my trusted roots list without my permission?

This also leads to the larger question:

• how do i prevent trusted root certificates from being added to my trusted root certificates list without my permission
• how do i locally revoke, or «untrust», a certificate

Bonus Chatter

China Internet Network Information Center

• Subject: CNNIC ROOT
• Issuer: CNNIC ROOT (it’s a self-signed of course)
• Valid From: ‎Monday, ‎April ‎16, ‎2007 3:09:14 AM
• Valid To: ‎Friday, ‎April ‎16, ‎2027 3:09:14 AM
• Thumbprint (sha): ‎8b af 4c 9b 1d f0 2a 92 f7 da 12 8e b9 1b ac f4 98 60 4b 6f

[root@arcade mail]# ls -l /etc/ | grep mail; ls -l /etc/mail; service sendmail start
drwxr-xr-x.  2 root root       4096 2011-01-27 20:06 mail
-rw-r--r--   1 root root        272 2009-11-17 21:13 mailcap
-rw-r--r--   1 root root       1968 2010-10-26 14:44 mail.rc
total 192
-rw-r--r--  1 root root   469 2007-08-27 11:25 access
-rw-r-----. 1 root root 12288 2011-01-27 20:06 access.db
-rw-r--r--. 1 root root     0 2010-09-30 14:25 aliasesdb-stamp
-rw-r--r--  1 root root   233 2007-04-12 15:35 domaintable
-rw-r-----. 1 root root 12288 2011-01-27 20:06 domaintable.db
-rw-r--r--  1 root root  5584 2010-03-27 21:10 helpfile
-rw-r--r--  1 root root    64 2007-04-12 15:35 local-host-names
-rw-r--r--  1 root root   997 2007-04-12 15:35 mailertable
-rw-r-----. 1 root root 12288 2011-01-27 20:06 mailertable.db
-rwxr-xr-x  1 root root  2700 2008-12-19 13:23 make
-rw-r--r--  1 root root    92 2008-12-03 18:29 Makefile
-rw-r--r--  1 root root 58439 2010-03-27 21:10 sendmail.cf
-rw-r--r--  1 root root  7202 2008-12-03 18:29 sendmail.mc
-rw-r--r--  1 root root 41521 2010-03-27 21:10 submit.cf
-rw-r--r--  1 root root   941 2010-03-27 21:09 submit.mc
-rw-r--r--  1 root root   127 2007-04-12 15:35 trusted-users
-rw-r--r--  1 root root  1847 2007-04-12 15:35 virtusertable
-rw-r-----. 1 root root 12288 2011-01-27 20:06 virtusertable.db
Starting sendmail: 451 4.0.0 /etc/mail/sendmail.cf: line 87: fileclass: cannot open '/etc/mail/local-host-names': Group writable directory
451 4.0.0 /etc/mail/sendmail.cf: line 596: fileclass: cannot open '/etc/mail/trusted-users': Group writable directory
                                                           [FAILED]

asked Sep 22, 2011 at 15:23

# chmod g-w /etc
# chown root:root /etc

answered Sep 22, 2011 at 16:54

Replacing line
Fw/etc/mail/local-host-names with Fw-o /etc/mail/local-host-names

in sendmail.cf and in submit.cf

answered Aug 18, 2015 at 17:57

Is there any way to add certificate to Local Computer’s Trusted Root Certification Authority using command line? I tried using certmgr.exe, it shows success but when i check root CA, i don’t see my certificate there.

http://msdn.microsoft.com/en-us/library/ms172241.aspx

Basically trying this command:

certmgr.exe -add -c mycertificate.cer -s -r localMachine root

The command works and shows success on command line, but i can not see the certificate in actual trusted root store through mmc, Is it the procedure for self signed certificate is different?
I have setup an IIS server with SSL Binding to this certificate which is originally placed in «MY» store. But im doing everything through autoamted scripts so i want to know how can i add this certificate to trusted root CA using cmd line option??

asked Aug 18, 2012 at 0:21

5 gold badges13 silver badges18 bronze badges

Did you try it manually (by double-clicking on the CER file)? If even manually it’s not working, you might be encountering a Vista bug.

Install a Root CA certificate from the command line (cmd. exe)

(This requires the Windows SDK. Visual Studio will install it for you and add it to the %PATH%.)

certmgr /add /c mycertificate.cer /s /r localMachine root

Note that no errors will be reported; the command will always return success (even when using a non-existing file for the certificate!). If the certificate doesn’t show up in the Certificate Manager (certmgr.msc) after running this command, repeat the process using the manual steps below to check if there is any error in your certificate file.

Manual steps to install a Root CA certificate

1. Double-click on the .cer file.
2. On the Certificate dialog box, click Install Certificate to start
   the Certificate Import Wizard.
3. On the Welcome page, click Next.
4. On the Certificate Store page, select Place all certificates in the
   following store and click Browse.
5. In the Select Certificate Store dialog box, select Show Physical
   Stores.
6. Double-click Trusted Root Certification Authorities, select Local
   Computer, and then click OK.
7. On the Certificate Store page, click Next.
8. On the summary page, review the details and click Finish.

Install a Root CA certificate from PowerShell

answered Aug 28, 2012 at 10:57

4 silver badges9 bronze badges

The PowerShell command
Import-Certificate
can be used to import a certificate:

Import-Certificate -FilePath "C:\path\Cert.Cer" -CertStoreLocation cert:\CurrentUser\Root

To run it through the Command Prompt (or batch) you may run it as:

powershell "Import-Certificate -FilePath ^"C:\path\Cert.Cer^" -CertStoreLocation cert:\CurrentUser\Root"

Note above the use of the ^ escape character.

To list all available certificate stores, start a PowerShell session and enter:

dir cert:\\LocalMachine\

answered Aug 25, 2020 at 12:52

30 gold badges521 silver badges908 bronze badges

Powershell «Import-Certificate -FilePath ‘C:\path\Cert.Cer’ -CertStoreLocation Cert:\LocalMachine\Root»

The path location needs to have the ‘ rather than the » for cmd

answered Jan 25, 2021 at 19:14

Earlier versions of Android keep their certs under /system/etc/security in an encrypted bundle named cacerts.bks which you can extract using Bouncy Castle and the keytool program. The summary is to first pull the bundle using adb (you need a root shell) then you can use Bouncy Castle to list the contents of the bundle:

shell~$ adb pull /system/etc/security/cacerts.bks`
shell~$ keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -v -list

We have a Win2k8 as a Domain Controller in a domain with workstations that run Windows XP. I would like to be able to install via GPO a new trusted root certificate authority certificate that I’ve generated myself.

Next, thought that maybe I can do better if I create an intermediate root certificate authority directly on the DC and deploy the intermediate root certificate authority via the GPO. Generated the certificate for the intermediate authority and imported it into the same GPO under Intermediate Certifications Authorities.

Again, ran the gpupdate /force (and rebooted) and checked the workstation. Couldn’t see anything either in the Imtermediate or the Root Authorities section.

After a bit of googling managed to find this MSI package Link, installed it on two workstations via a GPO and ran the gpupdate /force on the workstations and noticed that the intermediate authority certificate was installed on the workstations but the root CA wasn’t.

Does anyone have any ideas what I could try next?

LE. Forgot to mention the Root CA is on a standalone machine, not part of the domain and which I plan to keep offline.

This page pointed me to the right direction.

$ openssl x509 -inform der -in cacert.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ....
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = **, O = ***
        ...
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:TRUE
        ...

If CA:TRUE is not present under X509x3 Basic Constraints, your root certificate is likely not going to work on Android 11.

In order to generate a simple self-signed CA root certificate for Android 11, these minimal steps worked for me, and can be customized for your own certificate:

$ echo 'basicConstraints=CA:true' > android_options.txt
$ openssl genrsa -out priv_and_pub.key 2048
$ openssl req -new -days 3650 -key priv_and_pub.key -out CA.pem
$ openssl x509 -req -days 3650 -in CA.pem -signkey priv_and_pub.key -extfile ./android_options.txt -out CA.crt
$ openssl x509 -inform PEM -outform DER -in CA.crt -out CA.der.crt

The CA.der.crt or CA.crt files can be installed by going to Settings > Security > Encryption & credentials > Install a certficate.

This answer appears to build on the same foundations but is much more complete and will probably work on more platforms, but the one above should be a good minimal working example.

Windows Certificate MMC snapin shows that there’re two «root» certificate stores on Windows:

• Trusted Root Certification Authorities
• Third-Party Root Certification Authorities

I’m trying to setup mutual SSL for an application running in IIS and it looks like the client self-signed certificate must be added into either of the listed stores or otherwise IIS refuses to even pass the request to application code.

So to me they look identical. Both contain some certificates of well-known certificate authorities (such as VeriSign).

What’s the difference between the two? Suppose I decide to import the self-signed client certificate into either of them — which do I prefer and why?

asked Oct 19, 2016 at 13:24

The Third-Party Root Certification Authorities is a subset of Trusted Root Certification Authorities.

The Trusted Root are all the Microsoft certificates and the certificates for your organization plus the certificates in the Third-party Root.

The Third-party Root has all certificates that are not from either Microsoft or your organization.

answered Oct 19, 2016 at 14:12

25 silver badges29 bronze badges

«Сбер» для безопасного доступа к сайтам банка после перехода на российские TLS-сертификаты предлагает всем пользователям установить корневой сертификат Russian Trusted Root CA с сайта «Госуслуги» или использовать «Яндекс Браузер«.

«Сбер» пояснил, что скоро только российские сертификаты обеспечат защищённый доступ к сайтам и онлайн-сервисам «Сбера» с любых устройств пользователей. Для этого нужно или использовать браузеры с поддержкой российских сертификатов («Яндекс Браузер» или «Атом«) или установить сертификаты для своей операционной системы.

«Сбер» предупредил, что скоро большинство сайтов в рунете перейдут на российские TLS-сертификаты и пользователям всё равно придётся выбирать: установить корневой сертификат Russian Trusted Root CA или использовать «Яндекс.Браузер».

Национальный удостоверяющий центр выдаёт сертификаты на домены только тех организаций, которые явно это запросили. Полный список этих доменов публично доступен по адресу www.gosuslugi.ru/tls.

«Яндекс Браузер» применяет национальные сертификаты не для всего рунета, а только на тех сайтах, которые есть в списке на www.gosuslugi.ru/tls. Попытка применить сертификат на других доменах приведёт к стандартной ошибке и недоступности сайта для пользователя.

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

15 сентября Минцифры и «Сбер» сообщили, что онлайн-сервисы «Сбера» через несколько дней начнут переход на российские TLS-сертификаты. Фактически это означает, что облачные сервисы «Сбера» будут полноценно работать только в «Яндекс Браузере» и браузере «Атом» от VK. Также можно установить в системе сертификат Национального удостоверяющего центра Минцифры России — Russian Trusted Root CA.cer.

В марте 2022 года в условиях противодействия санкционной политике Минцифры организовало на базе НУЦ с использованием ЕПГУ выпуск для российских юридических лиц сертификатов безопасности (TLS-сертификатов) для сайтов. TLS-сертификаты необходимы для подтверждения легитимности сайтов и шифрования сетевого трафика между сайтом и браузером пользователя по протоколу HTTPS. Любое юридическое лицо или орган государственной власти может бесплатно получить один или несколько TLS-сертификатов и встроить их в свои информационные ресурсы. Получить сертификат можно через портал «Госуслуги».

В мае 2022 года пользователь Хабра ifap заметил, что Минцифры не имеет соответствующих полномочий по выдаче сертификата, а у якобы создавшего его НУЦ НИИ «Восход» прекращена аккредитация собственного УЦ.

Для ознакомления с проблемой установки и работой корневого сертификата Russian Trusted Root CA есть четыре публикации на Хабре по этой ситуации:

1. «Суверенный, сувенирный, самопровозглашенный«.
2. «Импортозамещение центров сертификации».
3. Про поддержку Certificate Transparency для национальных сертификатов.
4. Про поддержку сайтов с национальными сертификатами в «Яндекс Браузере».

Пояснение «Сбера» по этой ситуации: Мы первые в стране начали перевод своих сайтов на российские сертификаты удостоверяющих центров. Почему это важно? Чтобы вы никогда не потеряли доступ к личному кабинету и другим сервисам «Сбера». Объясняем. Сайты должны иметь сертификат удостоверяющего центра, чтобы гарантировать пользователем бесперебойный и безопасный доступ. Раньше такие «документы» выдавали только иностранные компании, но недавно появилась возможность установить сертификат, созданный Минцифры РФ.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы установите «Яндекс браузер» или Russian Trusted Root CA для работы с сервисами «Сбера»?

Russian Trusted Root CA

Еще не решил, но уже задумался

Установлю на одно отдельное устройство для работы только со «Сбером»

Пока (или вообще) ничего не буду ставить

Проголосовали 1988 пользователей.

Воздержались 243 пользователя.