sslstrip не всегда работает - только перед успешным входом в систему

Я анализирую приложение для iOS, написанное с помощью PhoneGap, которое сначала отображает HTTP-страницу. После нажатия «Войти» пользователь перенаправляется на HTTPS-страницу, где он может ввести данные для входа.

Если я настраиваю arpspoof/sslstrip ДО того, как пользователь войдет в систему в первый раз, все будет в порядке. Wireshark подтверждает, что данные для входа отправлены на HTTP-страницу, поэтому sslstrip выполнил свою работу.

Но если пользователь вошел в систему, например. за час ДО того, как я смог настроить arpspoof/sslstrip, второй запрос (= логин) отправляется через HTTPS, даже если приложение было полностью закрыто. Только если я установлю дату iPad в далеком будущем, она снова сработает. Затем, что раздражает, это также работает, если я устанавливаю дату на текущее время.

Если приложение удалить и установить новое, все снова работает как положено. Что произойдет, если пользователь вошел в систему раньше? Почему тогда sslstrip не может выполнять свою работу?

Моя установка: Kali Linux с помощью следующей команды:

#!/bin/bash
iptables -t nat --flush
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -i PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8008
arpspoof -i wlan0 -t SMARTPHONE-IP GATEWAY-IP

так же как

#!/bin/bash
sslstrip -k -f -l 8008 --write=sslstrip.log

ssl packet-sniffers
person swalkner    schedule 23.01.2014    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Похоже, приложение кэширует некоторую информацию. И если вы получите доступ к исходной странице со ссылкой/формой https внутри до того, как sslstrip активен, она будет кэширована и позже использована с неповрежденными ссылками https. Играя с датой системы, вы достигаете времени истечения срока действия кэшированной страницы, так что она будет игнорировать кэшированную запись и снова запрашивать страницу, на этот раз через sslstrip. Кроме того, если вы удалите приложение, кеш тоже будет удален, поэтому после переустановки ему нужно будет снова получить страницу.

person Steffen Ullrich    schedule 23.01.2014
comment
Есть ли способ предотвратить это? У вас есть идея, как я могу принудительно повторно загрузить страницу без физического доступа к iOS-устройству? - person swalkner; 24.01.2014
comment
Это зависит от приложения. Если он просто использует кешированную страницу без проверки на наличие более новой, у вас нет шансов, потому что вы ничего не можете перехватить. Но если приложение проверяет наличие более новой версии, запрашивая страницу с заголовком If-Modified-Since или If, вы можете удалить заголовки из запроса, чтобы сервер предоставил полную страницу. Но то, что возня с часами решает проблему, я предполагаю, что она просто использует кэшированную страницу без проверки на наличие новой. - person Steffen Ullrich; 24.01.2014
comment
Вы также можете попытаться отклонить прямой запрос SSL. Затем некоторые приложения попытаются обновить начальную страницу, используя незашифрованный HTTP. - person Steffen Ullrich; 24.01.2014
comment
В понедельник попробую, спасибо большое! Что меня раздражает, так это то, что в будущем мне всегда приходится использовать другое время; раньше хватило на два часа, сейчас в основном приходится использовать даты 2015 года... вернусь к этому в понедельник! - person swalkner; 24.01.2014
comment
Я только что нашел заголовок HSTS, установленный на один год, что, кажется, объясняет поведение. Кроме того, я думаю, что нет никаких шансов избежать этого... вы знаете дополнительную информацию об этом? Я имею в виду - где или как он хранится, выдерживает ли он перезагрузки и т.д.? - person swalkner; 27.01.2014
comment
Я предполагаю, что он переживет перезагрузки. Если у вас есть доступ к устройству, я бы предложил использовать SSL man-in-the-middle вместо ssltrip, например. используя mitmproxy, fiddler или подобные вещи, и добавьте на устройство свой собственный mitm-CA. - person Steffen Ullrich; 27.01.2014
comment
У меня НЕТ физического доступа к устройству при подтверждении утечки безопасности клиенту, у меня есть доступ только во время анализа происходящего. Я бы сказал, что не имеет значения, если это не работает каждый раз, мне просто нужно лучше понять это, то есть как и где эта информация хранится (внутри приложения или глобально на устройстве iOS) и сохраняется ли она после переустановки приложения, перезагрузки, удаление кеша и т.д. - person swalkner; 27.01.2014
comment
Возможно, вы даже сможете провести MITM-атаку без установки собственного MITM-CA. Существует множество приложений, которые не выполняют надлежащую проверку сертификатов. - person Steffen Ullrich; 27.01.2014
comment
к сожалению, iOS выполняет проверку — я попробовал MITM с Charles-Proxy: Kali используется для перенаправления трафика через мой Mac с запущенным Charles, но как только я пытаюсь перейти с HTTP на HTTPS в своем приложении, я вижу, что запрос заблокирован, так как сертификат недействителен. Таким образом, Phonegap/Safari, похоже, проверяет, действителен ли сертификат. Я думаю, с такими инструментами, как mitmproxy или fiddler, все так же? - person swalkner; 27.01.2014