Предупреждение: статья не для гуру компьютерной безопасности, а для тех, кто не до конца понимает, как работает авторизация на различных сайтах и какие дополнительные моменты появляются при работе в wifi сетях. Попытаюсь объяснить «на пальцах».
Начнём с мат части.
Как обычно происходит авторизация на различных вёб ресурсах? Точнее как это происходит чаще всего.
Вы вводите логин и пароль в форме логина, нажимаете кнопку и данные отправляется по каналу с безопасностью A, после чего сервер присылает ответ с сеансовым ключом, и этот сеансовый ключ в дальнейшем используется для обмена сообщениями по каналу с безопасностью B.
И если:
- A и B — оба https. В этом случае всё хорошо, ну или почти всё. Практически спокойно можно пользоваться сервисом в любой сети. Хотя некоторые ограничения остаются, которые не будет рассматриваться сейчас.
- A и B — https и http. Самое интересное.
- A и B — обычный http. Очень грустно. Можно надеятся только на недоступность сети другим. Не интересно.
Так когда и в каком случае ваша личная информация может стать доступной ещё кому-либо? Об этом читайте далее.
https+http самая распространённая схема, которая как раз применяется во вконтактике.
Итак. Безопасность https обеспечивается системой сертификатов. Там много своих тонкостей, но если в них не вдаваться, то если ваш браузер НЕ показывает картинку вроде:
то всё хорошо, и данные передаваемые по такому каналу хорошо защищены. Итого: пароль от vk.com спереть довольно трудно.
Полученный по безопасному каналу сеансовый ключ далее передаётся в незашифрованном виде по обычному http. И как он позволяет совершать какие-либо действия с вашим профилем вам, также и всем остальным, кто его знает.
Что же он из себя представляет? Посмотрим на http запрос картинки подарка(да, некоторые параметры изменены):
|
1 2 3 4 5 6 7 8 9 10 11 12 |
GET /images/gifts/48/237.png HTTP/1.1 Host: vk.com Connection: keep-alive Cache-Control: max-age=0 If-Modified-Since: Mon, 06 Aug 2012 18:11:28 GMT User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/10.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19 Accept: */* Referer: http://vk.com/id123 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-GB,en-US;q=0.8,en;q=0.6 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: remixchk=0; remixdt=0; audio_vol=0; remixlang=0; remixsid=02c46e693532b1eb57c8cc559dbaf05f48db7fe5c4d591c429c39904572b; remixreg_sid=; remixrec_sid=; remixseenads=1; remixflash=11.2.202 |
Здесь ключом является «remixsid». И чтобы «залогинится» достаточно выполнить команды в javascript консоле Chrome.
|
1 |
setCookie("remixsid", "02c46e693532b1eb57c8cc559dbaf05f48db7fe5c4d591c429c39904572b", 1); |
Обновить страничку и можно считать себя полноправным владельцем профиля.
Так как же его получить? Поснифать сеть.
Инструменты:
1) wireshark
Но! Он может показать только те пакеты, которые пришли вам. Вот не знаю как это объяснить это нормально. Но суть в том, что скорее всего удасться поймать ответы, но не запросы с куками.
Для решения этой проблемы может использоваться утилита airmon-ng. Она переключает адаптер в monitoring mode, который позволяет собирать все пакеты на определённом канале даже не зависимо от точки доступа(ну видимо только для не шифрованных сетей).
Запасаемся терпением и ждём запросов. Как они выглядит вы уже видели выше. Дальше остаётся ввести 1 команду.
Практические реультаты:
За 1 пару было наснифано куков с 6 аккаунтов. Было написано предупреждение на стене И НИЧЕГО БОЛЬШЕ.
Так кто виноват? Админы(которые построили такую сеть) да и мы(те кто пользуется такими ресурсами в открытых сетях).
Что делать? Возможно скоро напишу.
Планируемые статьи:
- Spoofing и Men-in-the-middle атаки.
- Как защититься от атак в wifi сетях.
p.s. это не рецепт как атаковать, а всего лишь попытка показать как это просто и доступно, и расшевелить тех, кто думает, что это никто никогда не сделает.
p.p.s. ну если сразу наспавниться много Скрипт-кидди, то я предупредил, что нужно быть осторожнее.
p.p.p.s. да, у меня не всё хорошо с русский языком.
