Перехват HTTPS трафика, как способ борьбы с инсайдерами

[alert style=»alert-error»]©2014 Лаборатория сетецентрических технологий. Внимание! Все материалы сайта охраняются авторским правом. Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала без письменного разрешения автора не допускается. Любое нарушение прав автора будет преследоваться на основе Российского и международного законодательства. Установка гиперссылок на статью не рассматривается как нарушение авторских прав.[/alert]

Введение

При построении современной системы обеспечении информационной безопасности организации следует обратить особое внимание не только на внешние угрозы, но и на защиту от внутренних угроз. С внутренними угрозами по статистике связано более 70% процентов всех инцидентов безопасности. По данным исследования, проведенного компанией InfoWatch [1], 77,6% руководителей ИТ- и ИБ-служб заявили, что основная опасность для бизнеса их работодателя связана с внутренними угрозами, а именно с утечкой информации ограниченного доступа, нелояльным или преступным поведением сотрудников. Средства защиты от несанкционированного доступа здесь оказывают практически бесполезными, поскольку в качестве основного источника угрозы выступает «инсайдер» — пользователь информационной системы, имеющий вполне легальный доступ к конфиденциальной информации и применяющий весь арсенал доступных ему средств для того, чтобы использовать конфиденциальную информацию в своих интересах.

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

Существует несколько способов перехвата и сохранения https трафика в файл. К таким способам относятся:

  • использование утилиты BEAST;
  • использование обнаруженной недавно уязвимости OpenSSL — Heartbleed;
  • применение атаки типа Man-In-The-Middle;

Каждый из перечисленных способов имеет свои достоинства и недостатки.

Использование утилиты BEAST

Утилита BEAST не позволяет прослушать весь HTTPS трафик, но позволяет перехватить секретные кукисы с идентификатором сессии пользователя. Программа состоит из двух элементов: снифера, который анализирует HTTPS-трафик, и специального агента, написанного на JavaScript и Java, который должен быть подгружен в браузере жертвы (для этого, к примеру, необходимо заставить пользователя открыть страницу с нужным кодом). Агент нужен для того, чтобы особым образом внедрять данные в тот же безопасный канал связи, который используется для передачи секретных кукисов [2].

Утилита BEAST применима только для шифрования симметричным ключом использующим блочные шифры.  Для реализации атаки с использованием утилиты BEAST используются устаревшие уязвимости, которые давно уже закрыты. И более того, реализация такой атаки существует только в виде рабочего proof-of-concept, показанного на конференции Ekoparty в Буэнос-Айросе. Видеокаст выступления доступен на Youtube по ссылке: https://www.youtube.com/watch?v=BTqAIDVUvrU

Использование уязвимости Heartbleed

7 апреля 2014 года сотрудниками The OpenSSL Project выпустили бюллетень безопасности, в котором сообщается о критической уязвимости CVE-2014-0160 (https://www.openssl.org/news/secadv_20140407.txt) в библиотеке OpenSSL. Уязвимость связана с отсутствием необходимой проверки границ в одной из процедур расширения Heartbeat (RFC6520) для протокола TLS/DTLS [3]. Используя данную уязвимость злоумышленник получает прямой доступ к оперативной памяти, в том числе, злоумышленник получает доступ к секретным ключам, именам и паролям пользователей и всему содержимому, которое должно передаваться в зашифрованном виде. При этом не остается никаких следов проникновения в систему.

Готовые эксплойты можно скачать на Github. Многие сайты закрыли уязвимости обновлением библиотеки OpenSSL до версии 1.0.2-beta2.

Понимание MITM атаки

MITM атака (атака “человек посередине”) представляет собой ситуацию, когда злоумышленник (атакующий) способен читать и изменять сообщения, которыми обмениваются корреспонденты, причем ни один из последних не догадывается о присутствии злоумышленника в канале [4].

Взаимодействие веб-браузера клиента и WEB-сервера с использованием протокола HTTPS выглядит следующим образом (рисунок 1):

1. Веб-браузер клиента запрашивает у WEB-сервера страницу используя метод GET по HTTPS протоколу, например:

https://gmail.com

2. В ответ WEB-сервер отправляет веб-браузеру клиента открытый ключ и свой сертификат.

3. Веб-браузер клиента выполняет проверку сертификата по сроку действия, отзыву сертификата, используя протокол OCSP (Online Certificate Status Protocol) и список отозванных сертификатов CRL (Certificate Revocation List), доверию сертификату сервера, совпадению значению поля Common Name в сертификате сервера с запрашиваемым доменным именем.

4. В случае прохождения проверок веб-браузер генерирует симметричный ключ, шифрует его открытым ключом WEB-сервера и передает WEB-серверу.

5. WEB-сервер расшифровывает симметричный ключ используя свой закрытый ключ.

6. Далее WEB-сервер отправляет WEB-страницу зашифрованную симметричным ключом.

7. Веб-браузер клиента расшифровывает содержимое WEB-страницы используя симметричный ключ и отображает содержимое.

_https-3

Рисунок 1 — Схема взаимодействия по HTTPS протоколу

При реализации MITM атаки все запросы веб-браузера перенаправляются на прозрачный TLS/SSL прокси-сервер, который, как правило, устанавливается на шлюз, реализущий сервис NAT (рисунок 2). В таком случае, схема атаки на протокол HTTPS выглядит следующим образом:

1. GET запрос веб-браузера клиента перенаправляется на прозрачный TLS/SSL прокси-сервер.

2. TLS/SSL прокси-сервер отправляет GET запрос WEB-серверу по протоколу HTTPS.

3. В ответ WEB-сервер отправляет TLS/SSL прокси серверу открытый ключ и свой сертификат.

4. TLS/SSL прокси-сервер генерирует симметричный ключ, зашифровывает его открытым ключом сервера и отправляет его WEB-серверу.

5. WEB-сервер расшифровывает симметричный ключ используя свой закрытый ключ.

6. Далее WEB-сервер отправляет TLS/SSL прокси-серверу WEB-страницу зашифрованную симметричным ключом.

7. TLS/SSL прокси-сервер расшифровывает содержимое WEB-страницы симметричным ключом и сохраняет содержимое в файл.

8. TLS/SSL прокси-сервер формирует закрытый ключ и сертификат для доменного имени (в поле Common Name содержится запрашиваемое доменное имя), запрашиваемого веб-браузером клиента и подписывает заранее сформированным сертификатом доверенного этому клиенту центру сертификации.

9. TLS/SSL прокси-сервер отправляет клиенту открытый ключ и сформированный сертификат запрашиваемого WEB-сервера.

10. Веб-браузер клиента выполняет проверку ложного сертификата, и, в случае прохождения проверок, веб-браузер генерирует симметричный ключ, шифрует его полученным открытым ключом и передает TLS/SSL прокси-серверу.

11. TLS/SSL прокси-сервер расшифровывает симметричный ключ, используя сформированный закрытый ключ.

12. Далее TLS/SSL прокси-сервер отправляет клиенту WEB-страницу, зашифрованную симметричным ключом.

13. Веб-браузер клиента расшифровывает содержимое WEB-страницы, используя симметричный ключ и отображает содержимое.

_https

Рисунок 2 — Схема атаки Man In The Middle на протокол HTTPS

Представленное взаимодействие клиента с TLS/SSL прокси-сервером называется прозрачным. Для перенаправления трафика клиента на прозрачный TLS/SSL прокси-сервер используются следующие способы:

  • использование ARP спуфинга (использование особенности протокола ARP: перехватив на атакующем узле внутри данного сегмента сети широковещательный ARP-запрос можно послать ложный ARP-ответ, в котором объявить себя искомым узлом (например — маршрутизатором) и в дальнейшем активно контролировать сетевой трафик дезинформированного узла. Не требует действий на стороне клиента);
  • прописать IP адрес прозрачного TLS/SSL прокси-сервера в качестве шлюза по-умолчанию на стороне клиента. Требует действий на стороне клиента;
  • отравление DNS кэша ( повреждение целостности данных в системе DNS путем заполнения кэша DNS-сервера данными, не исходящими от авторитетного DNS-источника);
  • перенаправление трафика путем модификации файла hosts на стороне клиента.

Таким образом, прозрачный TLS/SSL прокси-сервер представляет собой центр сертифкации, но необходимо решить проблему доверия веб-браузером клиента сформированным сертификатам.

Реализация MITM атаки

Для реализации MITM атаки существует программа с открытым исходным текстом SSLsplit. SSLsplit представляет собой прозрачный TLS/SSL прокси-сервер для всего семейства TLS/SSL протоколов. Последнюю версию программы можно скачать по адресу: https://www.roe.ch/SSLsplit. SSLsplit поддерживает HTTP и HTTPS соединения с использованием IPv4 и IPv6. Для HTTPS соединений SSLsplit формирует и подписывает сертификаты стандарта X509v3 на основе сертификата сервера DN и расширения subjectAltName. SSLsplit полностью поддерживает SNI (Server Name Indication), а также работает с RSA, DSA и ECDSA ключами. В SSLsplit имеется возможность использовать реально существующие сретификаты и закрытые ключи при их наличии вместо формирования поддельных. SSLsplit поддерживает NULL-префикс [5] в поле CN сертификата и блокирует OCSP запросы проверки статуса сертификата. Дополнительно SSLsplit удаляет заголовки HPKP из ответа сервера для предотвращения атаки PKP [6] (Public Key Pinning [6]).
Текущая версия SSLsplit поддерживает следующие операционные системы и методы преобразования NAT:

  • ОС семейства FreeBSD: pf rdr и drivert-to, ipfw fwd, ipfilter rdr;
  • ОС семейства OpenBSD: pf rdr и drivert-to;
  • ОС семейства Linux: netfilter (iptables) REDIRECT и TPROXY;
  • OSX: ipfw fwd и pf rdr.

Для реализации MITM атаки необходимо:

1. Установить SSLsplit на отдельно выделенном компьютере с двумя сетевыми интерфейсами, один из которых подключен к LAN, а другой соответственно к WAN или к роутеру.

2. Сформировать закрытый ключ и самоподписанный корневой сертификат CA сервера, которыми SSLsplit будет подписывать формируемые сертификаты запрашиваемых доменов.

3. Включить поддержку IP forwarding и NAT используя iptables.

4. Установить поддельный корневой сертификат CA сервера в хранилище доверенных центров сертификаций на стороне клиента.

Установка SSLsplit

В данной статье рассмотрена  установка SSLsplit на компьютер с операционной системой Ubuntu Server 12.04 LTS. В общем случае, для всех операционных систем семейства Linux, установка SSLsplit будет аналогичной. На рисунке 3 приведена структурная схема рассматриваемой сети.

test-2

Рисунок 3 — Структурная схема рассматриваемой сети

Для сборки SSLsplit требуются:

  • установленные библиотеки OpenSSL;
  • установленные библиотеки libevent 2.x.

Установка SSLsplit выполняется в следующей последовательности:

1. Скачать исходные тексты SSLsplit, выполнив команду

wget http://mirror.roe.ch/rel/sslsplit/sslsplit-0.4.8.tar.bz2

2. Распаковать скаченный архив, выполнив команды

bunzip2 sslsplit-0.4.8.tar.bz2

tar xvf sslsplit-0.4.8.tar

3. Перейти в каталог с исходными текстами, выполнив команду:

cd sslsplit-0.4.7

4. Установить библиотеки OpenSSL и libevent 2.x, выполнив команды:

sudo apt-get update
sudo apt-get install libssl-dev libevent-dev

5. Собрать программу SSLsplit из исходных текстов и установить, выполнив команды:

make
make install

6. Создать каталог для файлов протокола соединений и дампа сетевого трафика, выполнив команду:

mkdir /tmp/sslsplit

Формирование самоподписанного корневого сертификата CA сервера

Далее необходимо сформировать закрытый ключ и самоподписанный корневой сертификат CA сервера, которыми программа SSLsplit будет подписывать формируемые “на лету” сертификаты запрашиваемых доменов. Для этого необходимо выполнить следующие команды:

openssl genrsa -out server.key 4096

На запрос ввода пароля “Enter pass phrase for server.key:” необходимо ввести пароль для ограничения доступа к ключу.

openssl req -new -x509 -days 1826 -key server.key -out server.crt

Далее необходимо ввести пароль и заполнить запрашиваемые поля формируемого сертификата. В результате сформируется файл server.crt содержащий самоподписанный корневой сертификат CA сервера.

Включение поддержки IP forwarding и NAT

Для включения поддержки NAT необходимы права суперпользователя. Для получения прав суперпользователя необходимо выполнить команду:

sudo su

после чего необходимо ввести пароль текущего пользователя.

Далее необходимо настроить сетевые интерфейсы, для чего выполнить команду:

nano /etc/network/interfaces

Интерфейс eth0 подключен к роутеру с включенным DHCP сервером, поэтому настройки для интерфейса eth0 в файле interfaces будут выглядеть следующим образом:

auto eth0
iface eth0 inet dhcp

К сетевому интерфейсу eth1 подключен клиент, IP адрес назначен статически. Таким образом, настройки IP адреса для сетевого интерфейса eth1 будут выглядеть:

auto eth1
iface eth1 inet static
address 172.16.73.10
netmask 255.255.255.0

В результате проведенных действий файл interfaces должен содержать следующие строки:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet static
address 172.16.73.10
netmask 255.255.255.0

Для применения настроек необходимо перезапустить сетевые сервисы, выполнив команду:

/etc/init.d/networking restart

Далее необходимо установить пакет dnsmasq, предназначенный для перенаправления DNS запросов вышестоящим DNS серверам, выполнив команду:

apt-get install dnsmasq

После установки пакета необходимо проверить работу DNS выполнив команду:

nslookup gmail.com

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

Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   gmail.com
Address: 173.194.32.149
Name:   gmail.com
Address: 173.194.32.150

Далее необходимо настроить маршрутизацию пакетов (IP forwarding), для чего выполнить следующие команды:

nano /etc/sysctl.conf

найти строку и снять с нее комментарий:

net.ipv4.ip_forward=1

сохранить изменения в файле и выйти. Открыть файл стартовых скриптов rc.local выполнив команду:

nano /etc/rc.local

Перед строкой exit0 добавить следующие строки:

iptables -F
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o eth0 -j REJECT
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443

Сохранить изменения и выйти. Далее необходимо перезапустить сервер. После перезапуска сервера запустить программу SSLsplit, выполнив команду:

sudo sslsplit  -D  -l /tmp/sslsplit/connections.log  -j /tmp/sslsplit/  -S logfile/  -k serts/server.key  -c serts/server.crt  -L /tmp/sslsplit/data.log  https 172.16.73.10 8443

В таблице 1 приведен список параметров, передаваемых при запуске программы SSLsplit.

Таблица 1 — Параметры, передаваемые программе SSLsplit при запуске

Обозначение Назначение параметра
-c [путь к файлу сертификата] корневой сертификат CA центра сертификации, которым будут подписаны формируемые сертификаты запрашиваемых доменов
[путь к файлу закрытого ключа] используемый закрытый ключ для подписания формируемых сертификатов запрашиваемых доменов
-C [путь к файлу сертификата] используемый файл сертификата содержащий цепочку центров сертификации (промежуточные центры сертификации и корневой центр сертификации)
-K [путь к файлу закрытого ключа] используемый закрытый ключ для полписания генерируемых сертификатов запрашиваемых доменов при использовании файла сертификата содержащего цепочку центров сертификации (по-умолчанию: generate)
-t [каталог с файлами сертификатов] каталог с файлами сертификатов+цепочки+закрытые ключи для запрашиваемых доменов (сравнение с полем Common Name). В случае несовпадения сертификат запрашиваемого домена формируется и подписывается корневым сертификатом CA.
-O блокировать все OCSP запросы проверки сертификатов
-P пропускать SSL соединения, в случае аутентификации клиента клиентским сертификатом и отсутствием CA (по-умолчанию: такие SSL соединения блокируются)
-g [путь к файлу сертификата] использовать параметры группы DH из указанного файла сертификата
-G [обозначение ECDH] используемое обозначение ECDH в случае использования алгоритмов шифрования на эллиптических кривых (значение по-умолчанию: secp160r2 для не RSA ключей)
-Z отключение SSL/TLS сжатия для всех соединений
-s [значение шифра] использовать указанный OpenSSL шифр (по-умолчанию: ALL: -aNull)
-e [обозначение метода NAT] указывается используемый метод NAT (по-умолчанию: ipfw)
-E выводит список доступных методов NAT
-u [имя пользователя] пользователь, с чьими привилегиями запускается процесс (по-умолчанию: если процесс запущен суперпользователем, привелегии опускаются до пользователя nobody)
-j [путь к каталогу с файлами протоколов] указывается каталог к которому допущен запускаемый процесс, к этому каталогу применяется команда chroot() (по-умолчанию: если программа запущена суперпользователем значение: /var/empty)
-p [имя PID файла] в случае запуска в режиме демона, записывает PID процесса в файл с указанным именем
-l [путь к файлу протокола соединений] указывается путь к файлу протокола соединений (сокращенный вариант записи протокола соединений: в одной строке указывается суммарное количество соединений)
-L [путь к файлу протокола содержимого пакетов] указывается путь к файлу протокола содержимого перехваченных пакетов. Содержимое перехваченных пакетов записывается в один файл через разделитель (взаимоисключен с параметром -S)
-S [путь к каталогу содержащему перехваченные пакеты] указывается путь к каталогу, в котором будут содержаться файлы с перехваченными пакетами (взаимоисключен с параметром -L)
-d запуск в режиме демона (сетевой службы, сообщения записываются в syslog)
-D запуск в режиме отладки (отладочные сообщения и сообщения об ошибках передаются в stout и stderr соответственно)
-V выводит версию программы
-h выводит параметры запуска программы

Ниже приведен пример вывода запуска SSLsplit в режиме отладки при успешном запуске:

Generated RSA key for leaf certs.
SSLsplit 0.4.8 (built 2014-04-16)
Copyright (c) 2009-2014, Daniel Roethlisberger <daniel@roe.ch>
http://www.roe.ch/SSLsplit
Features: -DDISABLE_SSLV2_SESSION_CACHE -DHAVE_NETFILTER
NAT engines: netfilter* tproxy
netfilter:  IP_TRANSPARENT SOL_IPV6 !IPV6_ORIGINAL_DST
compiled against OpenSSL 1.0.1 14 Mar 2012 (1000100f)
rtlinked against OpenSSL 1.0.1 14 Mar 2012 (1000100f)
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
Using SSL_MODE_RELEASE_BUFFERS
SSL/TLS algorithm availability: RSA DSA ECDSA DH ECDH EC
OpenSSL option availability: SSL_OP_NO_COMPRESSION SSL_OP_NO_TICKET SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION SSL_OP_TLS_ROLLBACK_BUG
compiled against libevent 2.0.16-stable
rtlinked against libevent 2.0.16-stable
2 CPU cores detected
proxyspecs:
- [0.0.0.0]:8443 ssl http netfilter
Loaded CA: '/C=RU/ST=Moscow State/L=Serpuhov/O=IIF/OU=netcentriclab/CN=notlie.ru/emailAddress=info@notlie.ru'
Using libevent backend 'epoll'
Event base supports: edge yes, O(1) yes, anyfd no
Inserted events:
0x90c6e18 [fd 8] Read Persist
0x90c6f64 [fd 9] Read Persist
0x90c6d10 [fd 7] Read Persist
0x90c6fb0 [fd 3] Signal Persist
0x90c7228 [fd 1] Signal Persist
0x90c7308 [fd 2] Signal Persist
0x90c73e8 [fd 13] Signal Persist
Initialized 4 connection handling threads
Started 4 connection handling threads
Starting main event loop.

Установка поддельного корневого сертификата CA сервера в хранилище доверенных центров сертификаций на стороне клиента

Для прохождения проверок сформированных программой SSLsplit сертификатов запрашиваемых доменов, веб-браузер клиента должен иметь корневой сертификат CA атакующего в своем хранилище доверенных центров сертификации.

Внедрение сертификата СА администратором безопасности в веб-браузер IE не вызывает трудностей, но c альтернативными веб-браузерами (например: Mozilla FireFox) дело обстоит несколько иначе.

    Mozilla FireFox осуществляет хранение сертификатов в своем локальном хранилище. Для доступа к данному хранилищу необходимо использовать дополнительные компоненты:

  • Netscape Portable Runtim (NSPR) — предоставляет независимый от платформы API для системного уровня.
  • Network Security Services (NSS) — это набор библиотек, разработанных для поддержки кросс-платформенной разработки защищенных клиентских и серверных приложений. Приложения построенные с использование NSS могут использовать SSL v2 и v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, сертификаты X.509 v3 и другие стандарты обеспечения безопасности.

Все указанные компоненты распространяются с открытым исходным кодом.

Для компиляции компонентов под ОС Windows необходимо иметь установленную интегрированную среду разработки Microsoft Visual Studio (2010 — 2013) и MozillaBuild — пакет, содержащий дополнительные инструменты для сборки.

Процесс компиляции компонентов NSPR и NSS осуществляется в два этапа. На первом этапе осуществляется компиляция компонентов NSPR, на втором зависящих от библиотек NSPR, компонентов NSS. Для успешной компиляции необходимо, чтобы каталоги с исходниками NSPR и NSS находились в одном корневом каталоге.

Для компиляции необходимо из каталога, куда установлен пакет MozillaBuild, запустить shell в соответствии с установленной версией Microsoft Visual Studio (например, если версия 2012 года, то запустить файл start-shell-msvc2012.bat).

В открывшейся командной строке перейти к каталогу с исходниками NSPR. Затем последовательно выполнить команды ./configure и make. Скомпилированные библиотеки будут находиться в подкаталогах dist/lib и dist/bin.

Для компиляции компонентов NSS осуществить переход в каталог с исходниками NSS. В командной строке выполнить команду make nss_build_all. Скомпилированные компоненты будут находится в каталоге ../dist/WIN954.0.OBJ. Название конечного каталога может несколько отличаться, но обязательно будет содержать в наименование WIN95.

После осуществления успешной компиляции компонентов NSPR и NSS необходимо собрать все библиотеки, а также файл certutil.exe (получился в результате компиляции компонетов NSS) в одном каталоге. Перечень файлов приведен в таблице.

№ п/п Имя файла
1 certutil.exe
2 fort32.dll
3 libnspr4.dll
4 nspr4.dll
5 nss3.dll (или libnss3.dll)
6 nssckbi.dll (или libnssckbi.dll)
7 plc4.dll (или libplc4.dll)
8 plds4.dll (или libplds4.dll)
9 smime3.dll (или libsmime3.dll)
10 softokn3.dll
11 ssl3.dll (или libssl3.dll)
12 swft32.dll

В каталог с библиотеками помещается сертификат. Далее в каталоге создается командный сценарий (имя.cmd) следующего содержания:

for /D /R "%APPDATA%\Mozilla\Firefox\Profiles" %%f in (*.default) do certutil.exe -A -n server -t "TCu,Cu,Tuw" -d "%%f" -i c:\cadd\server.crt

После выполнения такого сценария для текущего пользователя в веб-браузер MozillaFireFox будет добавлен сертификат server.crt.

Если при выполнении командного сценария возникли ошибки типа: отсутсвует файл <имя файла>.dll, то необходимо просто найти такой файл в каталоге с префиксом lib<имя файла>.dll и переименовать его вручную, удалив префикс lib.
Чтобы обеспечить добавление сертификата всем пользователям необходимо с помощью System Center Configuration Manager (продукт для управления ИТ-инфраструктурой на основе Microsoft Windows и смежных устройств) создать соответствующий пакет с запуском от имени текущего вошедшего на рабочую станцию пользователя.

Список использованных источников

  1. Аналитический центр InfoWatch. Безопасность информации в корпоративных информационных системах. Внутренние угрозы
  2. Хабрахабр. Первая работающая атака на SSL/TLS-протокол.
  3. Хабрахабр. Критическая уязвимость в OpenSSL 1.0.1 и 1.0.2-beta.
  4. Википедия. Человек посередине
  5. Moxie Marlinspike. Null prefix attacks against SSL/TLS certificates
  6. SSLsplit — transparent and scalable SSL/TLS interception

1 комментарий к “Перехват HTTPS трафика, как способ борьбы с инсайдерами”

  1. Пингбэк: Перехват HTTPS трафика, как способ борьбы с инсайдерами | Лаборатория Сетецентрических Технологий

Добавить комментарий