Является ли SSLsplit правильным инструментом для перехвата и повторного шифрования трафика HTTPS на маршрутизаторе Wi-Fi?
Я собираюсь провести исследование уязвимости продуктов, работающих на различных устройствах, путем перехвата их HTTPS-трафика, но я не хочу изменять устройства помимо установки пользовательского сертификата.
Кажется, SSLsplit делает то, что я хочу, так как он позволяет "прозрачно перехватывать соединения через механизм трансляции сетевых адресов и перенаправлять их на SSLsplit". Из того, что я понимаю, эти правила NAT не нужно определять на устройстве, на котором выполняется приложение, которое является MITM-редактором, и я могу настроить iptables для перенаправления трафика маршрутизатора через SSLsplit на устройстве с Fruity Wifi или OpenWRT.
Является ли SSLsplit с измененными правилами iptables достаточным и разумным способом для этого, или мне придется изменить и другие части сетевой системы Linux?
ПРИМЕЧАНИЕ. Система, которую я пытаюсь создать, требует, чтобы на устройствах был установлен сертификат в доверенном корневом хранилище, чтобы "включить" этот перехват. Я не пытаюсь создать систему для перехвата произвольного трафика с нежелательных устройств.
3 ответа
Здесь есть две части: SSLsplit, который действует как клиент веб-сервера, и NAT, который меняет адреса назначения в пакетах, чтобы перенаправить их на сервер SSLsplit.
NAT должен быть настроен на маршрутизаторе, который используют клиентские устройства, изменяя адрес назначения пакетов с фактического сервера назначения на сервер SSLsplit.
Затем SSLsplit может установить соединение и выполнить свою задачу: подключиться к внешнему хосту (доступно в рукопожатии TLS) и переслать ответ.
Таким образом, единственное, что с точки зрения работы с сетью, это то, что вам нужно убедиться, что клиенты получают такие параметры сети, что их шлюз по умолчанию указывает на маршрутизатор, выполняющий NAT.
Короче говоря, да, это может быть правильный инструмент, но на самом деле он не дает никаких шансов, если вы используете SSLStrip, SSLSplit, mitmproxy или любой другой инструмент, который может выполнять вашу работу, вы должны только остерегаться того, как он работает.
Как упоминалось в @Quantim, это невозможно без установки / наличия настраиваемого сертификата /CA на устройстве за маршрутизатором, так как для этого требуется собственный CA, который будет действовать как посредник для SSL-соединений, и он должен иметь возможность генерировать и подписывать сертификаты, которым доверяет жертва. Таким образом, жертва должна иметь сертификат корневого CA атакующего в своем хранилище доверенных сертификатов. Объяснение того, как работают центры сертификации и как вы можете достичь желаемого результата, используя упомянутые инструменты, выходит за рамки этого ответа, но в зависимости от типа клиента - настольного браузера или мобильного телефона - вы должны заметить, что установка корневых сертификатов немного отличается.
SSLsplit работает очень похоже на другие прозрачные инструменты прокси SSL - как mitmproxy, который имеет больше функций и является более сложным. Он действует как посредник между клиентом и реальным сервером. При условии, что трафик перенаправляется на сервер, на котором SSLsplit работает и прослушивается, путем изменения шлюза по умолчанию, подмены ARP, подделки записей DNS или любых других средств. Другими словами, как вы уже догадались, SSLsplit выбирает SSL-соединения таким образом, что выдает себя за реальный сервер, к которому клиент подключается и с которым он хочет общаться. Фактически он динамически генерирует сертификат и подписывает его закрытым ключом сертификата CA, которому клиент должен - будет доверять.
Итак, чтобы ответить на ваш вопрос " Является ли SSLsplit правильным инструментом для перехвата и повторного шифрования трафика HTTPS на маршрутизаторе Wi-Fi? ", Да, это может быть, но знаете ли вы достаточно для этого? Если да, то иди и выиграй джекпот в своем исследовании.
И чтобы ответить " Является ли SSLsplit с измененными правилами iptables достаточным и разумным путем для этого, или мне придется изменить и другие части сетевой системы Linux? ", Я должен сказать, что если вы правильно настроили свои IPTables наборы правил и правила NAT/DNAT, и если ваши клиенты могут считать сертификат ЦС доверенным, да, этого будет достаточно - с измененными наборами правил iptables и перенаправлением трафика клиентов на сервер, который вы собираетесь перехватывать клиенты "движение на, как упоминалось ранее. Кстати, вы должны заметить, что слово " прозрачный " в вычислительном средстве означает (процесс или интерфейс) функционирование без уведомления пользователя о его присутствии.
Выдержка из оригинальной документации:
SSLsplit поддерживает обычные соединения TCP, SSL, HTTP и HTTPS как по IPv4, так и по IPv6. Для соединений SSL и HTTPS SSLsplit генерирует и подписывает поддельные сертификаты X509v3 на лету, основываясь на исходном DN субъекта сертификата сервера и расширении subjectAltName. SSLsplit полностью поддерживает индикацию имени сервера (SNI) и может работать с ключами RSA, DSA и ECDSA и комплектами шифров DHE и ECDHE. В зависимости от версии OpenSSL, SSLsplit поддерживает SSL 3.0, TLS 1.0, TLS 1.1 и TLS 1.2, а также дополнительно SSL 2.0. SSLsplit также может использовать существующие сертификаты, для которых доступен закрытый ключ, вместо генерации поддельных. SSLsplit поддерживает сертификаты CN с префиксом NULL и может отклонять запросы OCSP в общем виде. Для соединений HTTP и HTTPS SSLsplit удаляет заголовки ответа для HPKP, чтобы предотвратить закрепление открытого ключа, для HSTS, чтобы позволить пользователю принимать ненадежные сертификаты, и Альтернативные протоколы, чтобы предотвратить переключение на QUIC/SPDY. В качестве экспериментальной функции SSLsplit поддерживает механизмы STARTTLS в общем виде.
Перенаправление
Поскольку OP должен знать, как перенаправлять запросы в SSLsplit, но не хочет устанавливать прокси-сервер - как упоминалось в комментариях - я собираюсь дать краткое представление об этом, и я надеюсь, что это поможет:
Scenario 1 : If SSLsplit is on the OpenWRT which you are using - i.e. if SSLsplit is set on the GateWay which victims (clients) are connecting to :
|
VICTIMS | ATTACKER
|
+-------~+ | (GATEWAY) If SSLsplit is set on the Gateway users are gonna connect to, you only need to redirect some ports to those SSLsplit is listening on
| | | SSLsplit will be running on two ports: 8080 for non-SSL TCP connections and 8443 for SSL connections.
| | ---> |
| | | sysctl -w net.ipv4.ip_forward=1
+~~~~~~~~+ | iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
| \ iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443 (HTTPS)
+-------~+ | \ +~~~~~~~~+ iptables -t nat -A PREROUTING -p tcp --dport 636 -j REDIRECT --to-ports 8443 (LDAPS)
| | | \ | | iptables -t nat -A PREROUTING -p tcp --dport 587 -j REDIRECT --to-ports 8443 (MSA) Encryption = StartTLS
| | ---> | ===➤ | | iptables -t nat -A PREROUTING -p tcp --dport 465 -j REDIRECT --to-ports 8443 (SMTPS) Encryption = SSL
| | | / | | iptables -t nat -A PREROUTING -p tcp --dport 993 -j REDIRECT --to-ports 8443 (IMAPS) Encryption = StartTLS
+~~~~~~~~+ | / +~~~~~~~~+ iptables -t nat -A PREROUTING -p tcp --dport 5222 -j REDIRECT --to-ports 8080 (XMPP)
| / ...
+-------~+ |
| | |
| | ---> |
| | |
+~~~~~~~~+ |
|
|
Scenario 2 : AND IF SSLsplit is not set on the GateWay whic clients are connecting to - You will be in need of setting DNAT as the following :
VICTIMS | GATEWAY
|
+-------~+ |
| | |
| | ---> | IPTables will be like this :
| | |
+~~~~~~~~+ | SSLsplit iptables -t nat -A PREROUTING -d x.x.x.x/CIDR -p tcp -m tcp --dport 443 -j DNAT --to-destination z.z.z.z:8443
| \ iptables -t nat -A PREROUTING -d x.x.x.x/CIDR -p tcp -m tcp --dport 465 -j DNAT --to-destination z.z.z.z:8443
+-------~+ | \ +~~~~~~~~+ +~~~~~~~~+ ...
| | | \ | | | |
| | ---> | ===➤ | | ---------> | | In this scenario, all packets arriving on the router with a destination of x.x.x.x/CIDR will
| | | / | | | | depart from the router with a destination of z.z.z.z
+~~~~~~~~+ | / +~~~~~~~~+ +~~~~~~~~+
| /
+-------~+ | Redirects desired connection from somewhere
| | | to somewhere else to desired ports.
| | ---> |
| | |
+~~~~~~~~+ |
|
|
Обратите внимание на настройку значения net.ipv4.ip_forward 1. Команда, которую я использовал выше, используя sysctl -w не является постоянным Если вы хотите установить его постоянно, вы должны отредактировать файл /etc/sysctl.conf где вы можете добавить строку, содержащую net.ipv4.ip_forward = 1,
По умолчанию в большинстве дистрибутивов Linux переадресация IP отключена. И ИМХО, это хорошая идея, так как большинству людей ее не нужно будет использовать, но, поскольку вы настраиваете маршрутизатор / шлюз Linux - что также полезно для VPN-сервера (pptp или ipsec) - вам необходимо включить пересылку. Это можно сделать несколькими способами, как я вам уже показал.
Это невозможно без установки настраиваемого сертификата /CA на устройстве за маршрутизатором. В противном случае вы сможете выступать в качестве любого сетевого сервиса. SSLsplit генерирует только собственный сертификат или использует тот, для которого вы предоставляете закрытый ключ
SSLsplit также может использовать существующие сертификаты, для которых доступен закрытый ключ, вместо генерации поддельных. SSLsplit поддерживает сертификаты CN с префиксом NULL и может отклонять запросы OCSP в общем виде
В обоих случаях клиент без вашего пользовательского сертификата /CA получает недопустимую ошибку издателя сертификата
Прозрачный перехват означает, что вам не нужно указывать каждый хост, который вы хотите перехватить, и вы можете перехватывать весь трафик, но это все еще MitM-атака на SSL