Завершение истории

А история, начатая в первой части, завершилась прозаично – пароль от почтового ящика N был добыт и изменён, также как и контрольный вопрос. Со вторым ящиком на Mail.ru и с аккаунтом ВКонтакте было сделано то же самое. Я планировал вернуть все пароли через сутки, но на следующее утро обнаружил отсутствие аккумулятора в ноутбуке. Времени разбираться не было, меня ждал поезд, так что отдал пароли в обмен на свой аккумулятор.

• http

• , https

• , ssl

• , mitm

• , python

• , twisted

• , proxy

• , transparent

• , cool story

+90

12 января 2011, 12:54

113

z12312 января 2011, 14:26#↑

потому что открытые ключи центров сертификации прописаны прямо в недрах браузера и для проверки достоверности сертификата сайта сеть не используется

0

WGH12 января 2011, 19:28#↑

Браузер может проверять сертификат по списку отозванных. Это, впрочем, явно не упрощает задачу :-)

0

bolk13 января 2011, 01:19#↑

Сертификаты центров сертификации установлены в вашей системе (или браузере), заранее.

+3

burdakovd12 января 2011, 14:04#

Подделать-то можно. Но чтобы был толк надо чтобы пользователь скачал сертификат (подсунуть ему можно любой), и установилего в браузере или на компьютере. То есть нужно активное действие пользователя для этого. Но устанавливать сертификат может понадобиться 0.1% пользователей. И они достаточно осторожны чтобы проверить его отпечаток по другому каналу. Более правдоподобно подменить какой-нибудь скачивамый по http инсталлятор на свой, с подарком. А запущенный бинарник уже что хочешь сделает.

0

RReverser12 января 2011, 14:05#↑

Если мы говорим об обычных пользователях, то вряд ли так часто они будут скачивать инсталяторы, чтобы можно было что-либо подменить.

+1

amc12 января 2011, 16:23#↑

Да, классический вариант сети доверия. Есть несколько [не связанных друг с другом] Центров Сертификации. Есть принципиальное решение считать их доверенными (в ОС/Браузере). Есть сертификаты сайтов, подписанные этими ЦС. И поскольку мы доверяем этим ЦС, то доверяем и этим сайтам, при прохождении проверки подлинности сертификата, есстествено. Т.е. проще говоря — «друг моего друга — мой друг».

philpirj12 января 2011, 19:21#

Замечетельная статья, наталкивающая на много мыслей. Жаль только, что вы сразу отмели вариант MITM, потому что автор статьи, на которую вы ссылаетесь, как раз описывает реальную возможность это сделать, используя свой конечный сертификат для подписания сертификата на атакуемый сайт, используя свой конечный в качестве промежуточного. Автор утверждает, что многие браузеры не проверяют, что является ужасной дырой. Ну, и ещё в оригинальной статье понравился забавный трюк с установлением в качестве favicon.ico значка «замка».

+1

burdakovd12 января 2011, 20:11#↑

Ну MITM, связанный с тем, что браузеры не проверяют (не проверяли?) BasicConstraints я не рассматривал по следующим причинам: 1) Для этого нужно иметь и использовать какой-нибудь завалящий, но валидный сертификат. А цепочки сертификатов — это не только средство проверки подлинности сайта, но и средство в случае чего найти виноватого. То есть, используя свой сертификат для подписи чего попало, мы, во-первых, рискуем, что по этой цепочке что-то восстановят, во-вторых если сертификат отзовут — то придётся предпринимать дополнительные действия. 2) Некоторые браузеры не проверяют, а некоторые — проверяют. А мы выяснили, что negative feedback намного хуже, чем отсутствие positive feedback. Поэтому метод strip более надёжен, так как он никогда не вызовет negative feedback. А насчёт фавиконки — я всё же не перевод делал, хоть и много взял оттуда. Мне показалось, что лучше добиваться не «ощущения безопасности», а «ощущения обыденности». Не знаю как в Firefox, но в Chrome favicon отображается в заголовке вкладки, в значок SSL в адресной строке. То есть замочек был бы не там, где должен быть и являлся бы дополнительным отличием от привычного вида при использовании настоящего SSL.

0

burdakovd12 января 2011, 21:34#↑

Принудительное использование ssl? В настройках GMail? Спешу обрадовать, что это хорошо, но не защищает от описанной схемы, так как в ней взаимодействие с сервером идёт именно по SSL. Для защиты нужно контролировать или форсировать SSL на стороне клиента. Например изменив закладку в браузере с gmail.com/наgmail.com/.

0

or10n12 января 2011, 21:46#↑

переадресация на https идет на уровне сервера gmail'a, а не у меня в браузере. даже когда я ввожу просто http:// gmail меня переадресовывает на https://

0

burdakovd12 января 2011, 21:53#↑

Я понимаю. И именно на это рассчитана описанная в статье атака. Пользователь рассчитывает, что сервер его перенаправит на https. Но! Сам акт перенаправления происходит по http, который никак не защищён. Поэтому man-in-the-middle может эту переадресацию вырезать из потока данных, идущих от сервера к вам, и вы так и останетесь на http. Защититься от этого можно было бы не надеясь на перенаправление (которого может и не быть, т.к. MITM) а заходя напрямую по https. Если вы зашли по прямой ссылке https://, то man-in-the-middle (почти) ничего не сможет сделать.

0

or10n12 января 2011, 22:03#↑

я говорю о том, что неважно откуда пришел запрос на gmail (http или https), если в gmail'e стоит только https то он его переадресует в любом случае, что бы вы не делали. похожую технику я использую для сайта авторизации в локальной сети: сайт описан в vhoste который слушает 443 порт (ssl), а vhost для 80 порта (http) просто делает жесткий редирект на https:\\sitename ( Redirect permanent / sitename). Т.е. что ты не делай, в любом случае тебя отправят на https. (примерно так-же работает и принудительный ssl на gmail'e)

0

burdakovd12 января 2011, 22:19#↑

Взгляните на картинку: Сервер тут видит, что к нему кто-то подключается через https (он не может знать, что где-то там есть клиент и атакующий, и они соединены по http), поэтому он никаких перенаправлений делать не будет, и спокойно покажет всю секретную инфу.Этот почти пруфпикпоказывает, как клиент прекрасно открыл по http форму авторизации Google (не интерфейс GMail, но ситуация аналогичная). Сервер в этот момент считает, что соединение происходит через https. Без MITM клиент не смог бы открыть такой адрес по http, так как сервер, действительно, перенаправил бы его на https. Принудительный SSL со стороны сервера способен бороться только против пассивного прослушивания (что тоже хорошо, но недостаточно). Чтобы защититься от MITM за качеством и наличием шифрованияобязанследить клиент. Если я непонятно объясняю, то почитайтепервоисточник.

+1

pento13 января 2011, 00:45#

Перехватывать https путём выкусывания из http всех ссылок на https — это всё равно, что описывать в очередной раз арп спуффинг и взлом wi-fi с wep.

0

burdakovd13 января 2011, 18:31#↑

Да, действительно боянисто получилось. Статью писал как историю из жизни, которой хотелось поделиться с обществом. Подробнее остановился на тех местах, которые для меня показались интересными и нетривиальными, в частности идея sslstrip, не думал, что все её уже знают. Как видно по дискуссии выше, действительно не все.

0

stasmat16 января 2011, 22:53#

Если цель — получить пароль от гмейла и сделать это незаметно для пользователя, то можно вообще на змаорачиваться с заменой https на http, а просто выдавать фейковую http страницу с формой ввода, а после ввода пароля — логинить пользователя на настоящем сервере и уже никак не препятствовать трафику между жертвой и сервером. В этом случае заподозрит неладное только тот, кто заметит http вместо https на странице входа в гмейл. А когда залогинится, то всё будет как обычно.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.