VPN for regular users. Real need or useless option?
Habré has many articles about virtual private networks (VPN): self-help guides, technology overview, usage examples. All of them, to one degree or another, are designed for advanced users who are well aware of the threats in the modern information space and purposefully choose one or another method of protection.
')
To answer these questions, it is enough to assemble a simple test bench with a Wi-Fi access point and a traffic analyzer. The result will be very entertaining.
As a hacker weapon, we take an ordinary computer with an integrated Wi-Fi adapter. Turn on the access point, I used
In this article, we will not use certificate substitution and HTTPS proxy traffic, but consider the simplest cases of HTTP interception. All personal data in the dumps below are changed.
Let's start with all the "beloved" VKontakte (vk.com). We look at the user traffic when connecting:
JavaScript on the client calculates a hash on behalf of the username and password and sends it in a GET request. After that, the server responds with a redirect and sets the cookie:
Then the client follows the link indicated in the redirect with the transfer of the set cookies.
This is enough to log in to the “hacker” under the login of this user. We take any plugin to set a cookie (I used Cookies Manager + for FF), register
Maybe the VKontakte application for iPhone / iPad uses a secure connection? No, it is not. The traffic analyzer displays HTTP POST API requests:
The
It turns out that VKontakte fans are reasonably only connected via HTTPS, but forced redirection from HTTP to HTTPS on VKontakte servers is not activated. The same application for Apple iOS uses HTTP, there is a constant threat. Without VPN, connecting to unknown networks is very risky.
We look further. LiveJournal (livejournal.com) is very popular among creative intellectuals, designers and oppositionists. For some blogging in LJ is the main means of earning. We go to the LiveJournal site from a mobile device under your account, watch the traffic on our “hacker” gateway.
That's all, all the data for unauthorized connections we have. It is enough to set cookies for
And so for almost all services that use HTTP during the user authorization process.
Facebook, Twitter, Github, LinkedIn - well done, on their resources authorization only through HTTPS. The same goes for the Gmail and Yandex mail systems. Serious companies are beginning to seriously think about the security of their users' data.
Although there is a problem with Yandex. We go to partner.yandex.ru from a mobile device. Look at the traffic on the gateway. During the login process, a transition to passport.yandex.ru takes place, authorization goes via HTTPS, a cookie is set, but then it is redirected to partner.yandex.ru/registered with the cookie already set.
Well, then everything is sad, we write
For such cases, the best option is to use a VPN on mobile devices. It is highly desirable to choose solutions with automatic connection to the VPN for any outgoing traffic. For iOS devices, this technology is called VPN-on-Demand, for Android devices - Always-on VPN.
For the "hacker" all VPN traffic looks very boring and monotonous, something like this:
An additional advantage of VPN is hiding the addresses that the user visited. For the listening side, any information, even just a history of visits, can be useful for further attack on the user. If the connection goes through a VPN, then this information is not available.
It is desirable for server administrators to place all authorization forms on HTTPS pages. Additionally, it is recommended to add a long-term Strict-Transport-Security header to the server responses. This will avoid the situation described above for partner.yandex.ru.
It turns out that the most common users absolutely need solutions based on VPN.
From my point of view, the use of solutions based on OpenVPN or IPSec is most convenient and justified. OpenVPN works on virtually all platforms, but requires the installation of a third-party application on a mobile device. IPSec support is built into the core functionality of the most popular mobile platforms. Apple iOS has support for configuration profiles, setting up a VPN comes down to installing a profile on a device. I wrote about this in a previous article .
My project ruVPN.net was specially created to protect against the threats described above. From June, the commercial operation of the VPN infrastructure for Apple iOS devices (iPhone, iPad) with support for automatic connection (VPN-on-Demand) began. Get involved , invite your friends. Do not neglect the security of your data!
How to be ordinary users? What threatens them? Do they even need a VPN?
')
To answer these questions, it is enough to assemble a simple test bench with a Wi-Fi access point and a traffic analyzer. The result will be very entertaining.
As a hacker weapon, we take an ordinary computer with an integrated Wi-Fi adapter. Turn on the access point, I used
hostapd and dhcp3 . There are a lot of descriptions of installation and configuration ( one , two , three ). We configure the gateway to the Internet. After that, install Wireshark , start capturing traffic on the wireless interface. We connect a mobile device to the access point, in my case, an iPad. We emulate a free access point in a cafe and a relaxed visitor with a mobile device.In this article, we will not use certificate substitution and HTTPS proxy traffic, but consider the simplest cases of HTTP interception. All personal data in the dumps below are changed.
Let's start with all the "beloved" VKontakte (vk.com). We look at the user traffic when connecting:
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 on the client calculates a hash on behalf of the username and password and sends it in a GET request. After that, the server responds with a redirect and sets the 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 Then the client follows the link indicated in the redirect with the transfer of the set 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= This is enough to log in to the “hacker” under the login of this user. We take any plugin to set a cookie (I used Cookies Manager + for FF), register
remixlang , remixstid , remixsid from the last dump for vk.com, follow the link vk.com/login?role=fast&to=&s=1&__q_hash=bd8b2282f344a97ebe12b0c485955 - you are in the user's feed.Maybe the VKontakte application for iPhone / iPad uses a secure connection? No, it is not. The traffic analyzer displays HTTP POST API requests:
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 The
access_token parameter is something that can be used for authorization under another name.It turns out that VKontakte fans are reasonably only connected via HTTPS, but forced redirection from HTTP to HTTPS on VKontakte servers is not activated. The same application for Apple iOS uses HTTP, there is a constant threat. Without VPN, connecting to unknown networks is very risky.
We look further. LiveJournal (livejournal.com) is very popular among creative intellectuals, designers and oppositionists. For some blogging in LJ is the main means of earning. We go to the LiveJournal site from a mobile device under your account, watch the traffic on our “hacker” gateway.
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) That's all, all the data for unauthorized connections we have. It is enough to set cookies for
ljuniq , ljmastersession , ljloggedin and ljsession . After this, boldly go to livejournal.com and write a post on behalf of the victim.And so for almost all services that use HTTP during the user authorization process.
Facebook, Twitter, Github, LinkedIn - well done, on their resources authorization only through HTTPS. The same goes for the Gmail and Yandex mail systems. Serious companies are beginning to seriously think about the security of their users' data.
Although there is a problem with Yandex. We go to partner.yandex.ru from a mobile device. Look at the traffic on the gateway. During the login process, a transition to passport.yandex.ru takes place, authorization goes via HTTPS, a cookie is set, but then it is redirected to partner.yandex.ru/registered with the cookie already set.
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 Well, then everything is sad, we write
yandexuid , ys , yp , yandex_login , my , L , Session_id , go to partner.yandex.ru/registered and see the admin console of the affiliate program. All other Yandex services are also available, including mail.For such cases, the best option is to use a VPN on mobile devices. It is highly desirable to choose solutions with automatic connection to the VPN for any outgoing traffic. For iOS devices, this technology is called VPN-on-Demand, for Android devices - Always-on VPN.
For the "hacker" all VPN traffic looks very boring and monotonous, something like this:
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 An additional advantage of VPN is hiding the addresses that the user visited. For the listening side, any information, even just a history of visits, can be useful for further attack on the user. If the connection goes through a VPN, then this information is not available.
It is desirable for server administrators to place all authorization forms on HTTPS pages. Additionally, it is recommended to add a long-term Strict-Transport-Security header to the server responses. This will avoid the situation described above for partner.yandex.ru.
It turns out that the most common users absolutely need solutions based on VPN.
From my point of view, the use of solutions based on OpenVPN or IPSec is most convenient and justified. OpenVPN works on virtually all platforms, but requires the installation of a third-party application on a mobile device. IPSec support is built into the core functionality of the most popular mobile platforms. Apple iOS has support for configuration profiles, setting up a VPN comes down to installing a profile on a device. I wrote about this in a previous article .
My project ruVPN.net was specially created to protect against the threats described above. From June, the commercial operation of the VPN infrastructure for Apple iOS devices (iPhone, iPad) with support for automatic connection (VPN-on-Demand) began. Get involved , invite your friends. Do not neglect the security of your data!
Source: https://habr.com/ru/post/182072/
All Articles