Rdp вход по личному сертификату. RemoteApp и Remote Desktop вход на терминальный сервер без ввода логина и пароля. Этапы подготовки соединения с использованием программы Rohos Logon Key
В этой статье мы рассмотрим с тобой атаки типа Man-in-the-Middle, а точнее метод
перенапраления SSH- и HTTP- трафика с помощью атаки Man in the Middle. Не будем тянуть кота за хвост, а перейдем к делу.
Man in the Middle (в кратце MitM, с русского языка просто - "атака посредника" или "человек
посередине") - это такой вид атаки, основанный на перенаправлении трафика между двумя машинами для перехвата информации - дальнейшего ее изучения, уничтожения или модификации. Итак, первое, что нам нужно - пакет dsniff (ссылку на пакет ты увидишь в конце статьи). Почему именно он? Да потому, что этот пакет имеет в себе все необходимые утилиты, включая sshmitm (перенаправление SSH-трафика) и httpmitm (перенаправление HTTP-трафика), которые умеют обходить следующую следующую схему безопасности: насколько тебе известно, протоколы с шифрованием данных довольно-таки "секурны" (шифрация в помощь:)) и не позволяют проводить атаки "поверх" сетевого уровня. Ключ шифрования хакеру неизвестен - данные расшифровать невозможно и вставить команду тоже. Все бы вроде ничего, да вот как
раз таки программы MitM-атак (sshmitm и httpmitm) из пакета dsniff способны обойти данную систему безопасности (обойти можно практически все). Делается это все по следующему принципу:
промежуточный хост получает запрос от клиента, "сказав" ему, что он и есть сервер, затем подключаясь к реальному серверу.
Второе, что нам понадобится - прямые руки, четвертое - самое главное - желание, ну и, конечно, жертва, то есть компьютер, который будем атаковать.
Перенаправление SSH-трафика
После подготовки инструментария, ты понял, что к чему и почему:). Доставай sshmitm - сейчас мы будем перенаправлять SSH-трафик (все, что не понял с теоретической частью - читай выше)
с помощью нее, используя недостатки сегодняшнего PKI (public key infrastructure - схема управления ключами, основанная на
методах несимметричной криптографии). Давай рассмотрим синтаксис
sshmitm:
sshmitm [-d] [-I] [-p port] host
D
разрешить отладочный вывод (то есть более расширенный режим)
I
перехват сеансов
P port
порт для прослушивания
host
адрес удаленного хоста, сеансы которого будут перехватываться
port
порт на удаленном хосте
Все вроде просто и со вкусом - ничего сложного нет:). Начнем реализовать атаку!
# sshmitm server.target.gov // указываем свой SSH-сервер
sshmitm: relaying to server server.target.gov
Так как мы не имеем реального SSH-ключа, то командный интерпретатор атакованного
выведет запрос о проверке host-ключа, все это будет выглядить примерно так:
clientmachine$ server.target.gov
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
Please contact your system administrator.
И тогда пользователь будет решать - подключаться или нет. Если да - то мы получим полный контроль над SSH-сеансом.
НО! Если юзверь ни разу не подключался к той тачке, может быть выдано следующее сообщение:
The authenticity of host "server.target.gov" can"t be established
RSA key fingerprint is
bla:bla:bla;bla;bla........
Are you sure you want ti continue connecting (yes/no)?
Тут у юзверя тоже есть два выбора - коннектиться или нет. Если да - то мы перехватили сеанс, если нет - то увы... :(.
В общем-то, атака прошла успешно, если пользователь приконнектился, а sshmitm в свою очередь запишет все пассы и логины, причем очень читабельно 🙂
Естественно, это не единственный перехватчик SSH-сеансов, но познакомившись с этим, ты без проблем освоишь и другой 🙂
Перенаправление HTTP-трафика
Сейчас мы будем перенаправлять HTTP-трафик. Опять таки, нам понадобится уже раннее подобранный инструмент: httpmitm, который прослушивает 80- (HTTP -) и 443- (HTTPS -) порты, перехватывает WEB-запросы, потом подключается к серверу и пересылает запросы компьютеру-клиенту. Также программа генерирует SSL-ключи и SSL-сертификаты с помощью OpenSSL. Затем, после попытки
приконнектится к сайту (target.gov), браузер проверит SSL-сертификат. Так как сертификаты совпадать не будут, то браузер юзверя предупредит о
неправильном SSL-сертификате. Со стороны взломщика это будет выглядеть примерно так:
#webmitm -d
webmitm: relaying transparently
webmitm: new connection from
GET [ссылка]/uzerz.php?user=hellknights&password=neskaju1qwerty HTTP/[версия]
Connection: [тип]
Host: www.target.gov
User-Agent: [информация о системе, браузере]
[итд, итд, итд]
Cookie: [кукисы]
Вот так все это выглядит со стороны -
перехватывается SSL-коннект, схватив незашифрованные данные.
Заключение
В этой статье мы рассмотрели с тобой перенаправление SSH- и HTTP- трафика, с помощью атаки Man in the Middle - четко, подробно, коротко. Другие программы перенаправления HTTP- и SSH-
трафика с помощью MitM ты освоишь быстро, если освоил и эти:)). Если, что-то было непонятно - то.
В этой статье мы рассмотрим проксификацию трафика iOS-приложений, использующих native web sockets для взаимодействия с сервером. Статья будет полезна тем пентестерам, которые сталкиваются в своей работе с перехватом конфиденциальной информации, посылаемой iOS-приложениями нестандартными способами. Эти методы являются актуальными, поскольку использование стандартных настроек прокси сервера на устройстве для перехвата трафика некоторых приложений может оказаться недостаточным.
Недавно, во время очередного пентеста, я столкнулся с приложением, которое отсылало информацию на порт 20хх веб-сервера. Трафик этого приложения не поддавался перехвату путем изменения стандартных настроек (Settings -> Wi-Fi -> HTTP Proxy -> Manual) и перенаправления трафика на прокси. Одна из причин, почему этот метод не работает, - для взаимодействия с сервером используются нативные веб сокеты (native websockets) вместо класса UIWebView. Более подробно о том, как настраиваются веб сокеты, рассказывается в этой статье .
Однако есть обходной маневр для решения этой проблемы. Мы можем реализовать DNS-спуфинг и перенаправить весь HTTP-трафик со всех портов через прокси наподобие Burp. Данная статья состоит из частей:
- Сниффинг трафика при помощи Wireshark для нахождения IP-адреса и порта сервера.
- Спуфинг DNS и пересылка всего трафика на машину, где установлен прокси.
- Перехват трафика при помощи прокси сервера после выполнения DNS-спуфинга.
Ниже показана пошаговая схема для реализации перехвата трафика iOS-приложений, использующих Native Web Socket.
1. Создаем беспроводную точку доступа и подключаем к ней устройство. [Примечание: машина должна быть подключена к Ethernet или любым другим способом подключена к интернету, поскольку Wi-Fi интерфейс будет использоваться для точки доступа. В этой статье рассказывается о том, как настроить точку доступа на Windows-машине]
2. Запускаем сетевой сниффер (например, Wireshark) и ищем трафик, проходящий через нестандартные порты.
a. Фильтруем трафик, оставляя только тот, который идет на нужный нам IP-адрес (ip.dst== ip.ip.ip.ip)
b. Находим номер порта, на который посылается трафик.
Рисунок 1: Нахождение нестандартного порта, на который приложение отсылает трафик
3. Запускаем консоль Metasploit для DNS-спуфинга и вводим следующие команды:
c. set SRVHOST = (IP беспроводной точки доступа)
d. set SRVPORT = 53, set TARGETACTION = BYPASS, set TARGETDOMAIN = www.apple.com (Примечание: выставляя TARGETDOMAIN= www.apple.com, мы будем перехватывать весь трафик, кроме идущего с apple.com).
e. set targethost = (IP беспроводной точки доступа)
Рисунок 2: Настройка DNS сервера при помощи модуля fakedns (в Metasploit )
4. Конфигурируем Burp на прослушивание входящего трафика устройства на определенных портах и перенаправляем его на найденный ранее порт.
a. Заходим в Proxy->Options->Add; устанавливаем в "bind port" тот порт, на который приложение должно пересылать трафик (примечание: это один из тех нестандартных tcp-портов, который был найден при помощи Wireshark).
b. Слушаем все интерфейсы.
c. Во вкладке Request Handling задаем домен сервера (поле Redirect to host).
d. В той же вкладке выставляем соответствующий номер порта (поле Redirect to port).
e. Если трафик посылается через https, выставляем принудительное использование SSL.
f. Кликаем ок и повторяем все вышеперечисленные операции для всех портов, на которые приложение посылает трафик. Другими словами, для каждого порта нужен отдельно сконфигурированный Proxy listener.
Рисунок 3: Настройка прослушивания и перенаправления трафика
5. Конфигурируем настройки прокси на устройстве:
a. Заходим в раздел Wi-Fi->DHCP и выставляем DNS = IP-адресу точки доступа.
b. В настройках HTTP-прокси ставим IP-адрес точки доступа и соответствующий порт, на который настроен burp (эти настройки используются для проксирования стандартного HTTP-трафика).
Рисунок 4: Конфигурирование IP и DNS forwarding на устройстве
6. Введите в консоли Metasploit «exploit», и вы увидите весь перехваченных трафик с нестандартных портов.
Описанный метод можно использовать для обхода проблем с перехватом трафика iOS-приложений, передающих его нестандартными способами.