VPN для обычных пользователей. Реальная необходимость или бесполезная опция?

На Хабре много статей про виртуальные частные сети (VPN): руководства по самостоятельной настройке, обзор технологии, примеры использования. Все они в той или иной степени рассчитаны на продвинутых пользователей, которые прекрасно осознают угрозы в современном информационном пространстве и целенаправленно выбирают тот или иной способ защиты.

Как же быть обычным пользователям? Что им угрожает? Нужен ли им вообще VPN?

Для ответа на эти вопросы достаточно собрать простейший тестовый стенд с точкой доступа Wi-Fi и анализатором трафика. Результат окажется очень занимательным.

В качестве хакерского оружия берем обычный компьютер со встроенным Wi-Fi адаптером. Включаем точку доступа, я использовал hostapd и dhcp3. Описаний по установке и настройке очень много (раз, два, три). Настраиваем шлюз в интернет. После этого устанавливаем Wireshark, запускаем захват трафика на беспроводном интерфейсе. К точке доступа подключаем мобильное устройство, в моем случае iPad. Эмулируем бесплатную точку доступа в кафе и расслабленного посетителя с мобильным устройством.

В данной статье мы не будем использовать подмену сертификатов и проксирование HTTPS трафика, а рассмотрим простейшие случаи прослушки HTTP. Все персональные данные в нижеприведенных дампах изменены.

Начнем со всеми «любимого» ВКонтактика (vk.com). Смотрим трафик пользователя при подключении:

GET /login?role=fast&to=&s=1&__q_hash=bd8b2282f344a97ebe12b0c485952a6f HTTP/1.1
Host: m.vk.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://m.vk.com/login?role=fast&to=&s=1&m=1&email=mail%40yandex.ru
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: remixlang=0; remixmdevice=768/1024/2/!!!!!!; remixstid=267699470; remixmid=; remixsid=; remixsid6=; remixgid=; remixemail=; remixpass=; remixapi_sid=; remixpermit=; remixsslsid=

JavaScript на клиенте вычисляет хэш от имени и пароля и шлет его в GET запросе. После этого сервер отвечает перенаправлением и устанавливает cookie:

HTTP/1.1 302 Found
Server: nginx/1.2.4
Date: Mon, 03 Jun 2013 16:56:02 GMT
Content-Type: text/html; charset=windows-1251
Content-Length: 20
Connection: keep-alive
X-Powered-By: PHP/3.332
Pragma: no-cache
Cache-control: no-store
P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Set-Cookie: remixsid=c04f7b2295b3b54405205a4306d6511c6cd9857f33249c004121c; expires=Wed, 11-Jun-2014 05:01:34 GMT; path=/; domain=.vk.com
Set-Cookie: remixtemp_sid=; expires=Sun, 25-May-2014 15:48:33 GMT; path=/; domain=.vk.com
Location: /
Content-Encoding: gzip

Затем клиент переходит по указанной в редиректе ссылке с передачей установленных cookies

GET / HTTP/1.1
Host: m.vk.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://m.vk.com/login?role=fast&to=&s=1&m=1&email=mail%40yandex.ru
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: remixlang=0; remixmdevice=768/1024/2/!!!!!!; remixstid=267699470; remixmid=; remixsid6=; remixgid=; remixemail=; remixpass=; remixapi_sid=; remixpermit=; remixsslsid=; remixsid=c04f7b5995b3b54405205a4306d6511c6cd9558f33249c004121c; remixtemp_sid=

Этого достаточно, чтобы зайти «хакеру» под логином этого пользователя. Берем любой плагин для установки cookie (я использовал Cookies Manager+ для FF), прописываем remixlang, remixstid, remixsid из последнего дампа для сайта vk.com, переходим по ссылке vk.com/login?role=fast&to=&s=1&__q_hash=bd8b2282f344a97ebe12b0c485952a6f и все — вы в ленте пользователя.

Может быть приложение «ВКонтакте» для iPhone/iPad использует защищенное соединение? Нет, это не так. Анализатор трафика показывает HTTP POST запросы к API:

POST /method/execute HTTP/1.1
Host: api.vk.com
Accept-Encoding: gzip
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 266
Connection: keep-alive
Cookie: remixdt=-10800; remixrt=1; remixlang=3
User-Agent:  2.3.11 rv:10037 (iPad; iPhone OS 6.1.3; nb_NO)

code=var%20messages%20%3D%20API.messages.get%28%7Bfilters%3A1%7D%29%3B%20return%20%7Bunread%3Amessages%5B0%5D%7D%3B&api_id=2753915&access_token=ac43d874bd29351e2e2b20b0c671029edc84a48a715f97721111568443b5ba42f00a349b95f692e5727ec&sig=cb7ac6c6346bd26b762929efe0f711d1

Параметр access_token – это то, что можно использовать для авторизации под чужим именем.

Получается, что поклонникам «ВКонтакте» разумно подключаться только по HTTPS, но принудительное перенаправление с HTTP на HTTPS на серверах «ВКонтакте» не активировано. Так же приложение для Apple iOS использует HTTP, тут угроза постоянна. Без VPN подключаться к неизвестным сетям очень рискованно.

Смотрим дальше. «Живой Журнал» (livejournal.com) очень популярен среди творческой интеллигенции, дизайнеров и оппозиционеров. Для некоторых ведение блога в ЖЖ является основным средством заработка. Заходим на сайт ЖЖ с мобильного устройства под своим аккаунтом, смотрим трафик на нашем «хакерском» шлюзе.

GET / HTTP/1.1
Host: www.livejournal.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: ljuniq=EQwqgJzEJVk0mqr%3A1370276381%3Apgstats0; ljmastersession=v2:u12213803:s119:a68UFciy4PP:g398155211a6adc80bc47746a28dbcb9146b6a257//1; ljloggedin=v2:u12213003:s119:t1370286730:gb4fd54e13950d47f0940aa78f3de73582ebd4c64; BMLschemepref=horizon; langpref=ru/1370272950; ljsession=v1:u12213803:s119:t1370275200:gf1c7f737342bcb5759c70a257cbf97acc9512731//1; PRUM_EPISODES=s=1370747384764&r=http%3A//www.livejournal.com/; __utma=48425145.515596637.1370276682.1370276682.1370281850.2; __utmb=48425145.1.10.1370281850; __utmc=48425145; __utmz=48425145.1370276682.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

Вот и все, все данные для несанкционированного подключения у нас есть. Достаточно прописать в браузере cookies для ljuniq, ljmastersession, ljloggedin и ljsession. После этого смело заходим на livejournal.com и пишем пост от имени жертвы.

И так практически для всех сервисов, использующих HTTP во время процесса авторизации пользователя.

Facebook, Twitter, Github, LinkedIn – молодцы, на их ресурсах авторизация только через HTTPS. То же самое касается почтовых систем Gmail и Yandex. Серьезные компании начинают всерьез задумываться о безопасности данных своих пользователей.

Хотя с Яндексом есть проблема. Заходим на partner.yandex.ru с мобильного устройства. Смотрим трафик на шлюзе. В процессе логина происходит переход на passport.yandex.ru, авторизация идет через HTTPS, устанавливаются cookie, но потом происходит перенаправление на partner.yandex.ru/registered с уже установленными cookie.

GET /registered HTTP/1.1
Host: partner.yandex.ru
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: yandexuid=9257588111370282489; _ym_visorc=b; ys=udn.bXRzLZ1heA%3D%3D; yp=1685643738.udn.bXRzLW1heA%3D%3D; yandex_login=mail; my=YzYBSQA=; L=X3MKVQFiRwt/Ql9afF5hfnZBbwBCeHkXUypkHiQcHkwyOwFcRjh9JnMzKT0GXD0NSDVcdEMCUUB4XyEDqhpbNQ==.1620283888.9752.254668.6b58de4c285c135c1273a411170dba5c; Session_id=2:1685643738.-875.0.1121887.8:1370283888922:1422936785:15.0.1.1.0.73736.1393.a9075755a24d0d44ef3f216256625665

Ну и далее все печально, прописываем yandexuid, ys, yp,yandex_login, my, L, Session_id, заходим на partner.yandex.ru/registered и видим консоль администратора партнерской программы. Все остальные сервисы Яндекса тоже доступны, включая почту.

Для таких случаев оптимальным вариантом является использование VPN на мобильных устройствах. Крайне желательно выбирать решения с автоматическим подключением к VPN при любом исходящем трафике. Для iOS устройств такая технология называется VPN-on-Demand, для Android устройств – Always-on VPN.



Для «хакера» весь VPN трафик выглядит очень скучно и однообразно, примерно вот так:

No.     Time        Source                Destination           Protocol Info
     95 7.372487    10.0.1.200            109.233.59.108        ESP      ESP (SPI=0xc6ed086f)

Frame 95 (126 bytes on wire, 126 bytes captured)
Ethernet II, Src: 7c:fa:df:cb:d3:89 (7c:fa:df:cb:d3:89), Dst: HonHaiPr_23:f0:9a (0c:60:76:23:f0:9a)
Internet Protocol, Src: 10.0.1.200 (10.0.1.200), Dst: 109.233.59.108 (109.233.59.108)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 112
    Identification: 0x38cd (14541)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0x8c93 [correct]
        [Good: True]
        [Bad : False]
    Source: 10.0.1.200 (10.0.1.200)
    Destination: 109.233.59.108 (109.233.59.108)
User Datagram Protocol, Src Port: ipsec-nat-t (4500), Dst Port: ipsec-nat-t (4500)
    Source port: ipsec-nat-t (4500)
    Destination port: ipsec-nat-t (4500)
    Length: 92
    Checksum: 0x0000 (none)
        Good Checksum: False
        Bad Checksum: False
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
    ESP SPI: 0xc6ed086f
    ESP Sequence: 54

Дополнительным преимуществом VPN является сокрытие адресов, которые посещал пользователь. Для прослушивающей стороны любая информация, даже просто история посещений, может быть полезна для дальнейшей атаки на пользователя. Если соединение идет через VPN, то подобная информация недоступна.

Администраторам серверов желательно все формы авторизации размещать на HTTPS страницах. Дополнительно рекомендуется добавлять заголовок Strict-Transport-Security с длительным сроком действия в ответы сервера. Это позволит избежать ситуации, описанной выше для partner.yandex.ru.

Получается, что самым обычным пользователям совершенно необходимы решения на базе VPN.

С моей точки зрения, наиболее удобно и оправдано использование решений на базе OpenVPN или IPSec. OpenVPN работает практически на всех платформах, но требует установки стороннего приложения на мобильное устройство. Поддержка IPSec встроена в базовую функциональность наиболее популярных мобильных платформ. В Apple iOS есть поддержка конфигурационных профилей, настройка VPN сводится к установке профиля на устройство. Об этом я писал в предыдущей статье.

Мой проект ruVPN.net был специально создан для защиты от описанных выше угроз. С июня началась коммерческая эксплуатация инфраструктуры VPN для Apple iOS устройств (iPhone, iPad) с поддержкой автоматического подключения (VPN-on-Demand). Подключайтесь, приглашайте друзей. Не пренебрегайте безопасностью ваших данных!