Друзья, столкнулся с такой проблемой: mitmproxy отлично работает, если 1) Он задан как прокси в сетевых настройках, либо настройках браузера 2) Он задан как Default Gateway 3) Произведен ARP-Spoofing Однако, в моем случае ни один из этих трех вариантов не подходит, но у меня есть доступ к роутеру жертвы, на котором установлен openwrt. При попытке перенаправить трафик через iptables, например iptables -t nat -A PREROUTING -p tcp -j DNAT --to IPORT mitmproxy выдает ошибку и отказывается работать. Однако, tinyproxy, например, в этом же самом случае работает нормально. Почему mitmproxy отказывается работать? И есть ли какие-то варианты решить данную проблему?
Наткнулся тут на твою писанину... Ну, так ты разобрался, где и в чём твои ошибки? Или ты забил? Ладно, отвечу, лучше поздно, чем никогда! Вот ты пишешь: Перенаправить его откуда? Куда? Зачем? И что в итоге должно произойти после этой "твоей команды"? Я плохо понимаю... Неудивительно, что mitmproxy шокирован, вот его я понимаю! Для более эффективного пробрасывания трафика, мы должны взять и пробросить этот самый трафик! А делается это так: 1. Включаем форвардинг пакетов. echo "1" > /proc/sys/net/ipv4/ip_forward 2. Настраиваем IPtables для перенаправления интернет трафика. Для http с 80 порта на 8080. iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080 3. Настраиваем IPtables для перенаправления интернет трафика. Для https c 443 порта на 8080. iptables -t nat -A PREROUTING -p tcp --destination-port 443 -j REDIRECT --to-port 8080 4. Запускаем mitmproxy. mitmproxy -T --host 5. Проводим arp-spoofing атаку. arpspoof -i wlan0 -t 192.168.X.X 192.168.Y.Y - где -i wlan0 - твой сетевой адаптер, -t 192.168.X.X - IP адрес жертвы, 192.168.Y.Y - IP адрес шлюза (AP) Да, сразу оговорюсь, что, когда жертва полезет на эти Ваши всякие ВК (на самом деле везде, где жОстко блюдётся https и проверка сертификатов), она может заподозрить неладное! И это ещё мягко сказано... Особенно если жертва не ТП и пользуется не каким-то пошлым IE, а самым распоследним, защищённым и опасным Google Chrome (на самом деле Mozilla), тут то у них и посыплются всякого рода alert' ы, сообщения-денжеры, предупреждения об ОПАСНОСТЕ и другие нехорошие окошки! Все дело в том, что mitmproxy подсовывает свой палевный сертификат... Вот же он! Spoiler Spoiler: Или такой... Spoiler: Или даже вот Такой! Zertifikat! :) Но даже если %username% его одобряе, ситуация не всегда меняется в нашу пользу, тк кроме %username%'a такой сертификат больше никто не одобрит ! Короче всё более менее "гладко", если victim ТП с IE и тыкает куда зря "ой, лишь бы это окошко убралось и чтоб ничего не сломалось!" , да и тот такое... Но вообще попробовать стоит!
Ты меня не понял: с арпспуфом то все работает, как надо, и REDIRECT используется только для редиректа трафика внутри машины. Я же пытался маршрутизатором жертвы перенаправить трафик на свой mitmproxy, который находится на другой машине. А это уже совсем другая история! Там фишка в том, что трафик то редиректится, но mitmproxy, насколько я понял, не может понять домен, т. к. он то проверяется при https соединениях и, соответственно, ничего и не будет работать. А все то, что ты описал выше, я уже давно знаю.
SSLStrip в данном случае не прокатит. Вопрос был решен следующим образом: поднят apache с правильно настроенным виртуальным хостом и https, а так же dns серв, на котором была выполнена подмена адреса для необходимого сайта. Т. е. при заходе на сайт у юзверя вылезает предупреждение о несоответствии сертификата (тут уж никуда не денешься), однако он это игнорирует и попадает на фейк, где ему даже ничего вводить не нужно, т. к. кукисы уже у нас (домен то ведь настоящий).
не забываем про другие фреймворки под mitm вполне достойный вариант: https://www.bettercap.org/ через dns'ку пробросить можно тулзой https://github.com/singe/dns2proxy/
