HTTPS man-in-the-middle attack practice (principle·practice)
I have seen the introduction of HTTPS very early, and I have learned about the details of TLS. I also believe that using HTTPS is relatively safe and reliable. Until the previous time when verifying the https proxy channel connection, I found out that the fact is not what I thought. Because some application developers ignore the verification of certificates or improperly handle illegal certificates, our web sessions are almost exposed to attackers.
The following will show you the MITM attacks on two common applications on the IOS system to obtain or tamper with user data.
A basic introduction to man-in-the-middle attacks may be seen here (
). Roughly speaking, an attack scheme that hijacks a session in a network. If only the listening traffic is called a passive network attack, how the attacker actively modifies the data stream is called an active network attack.
Fortunately, Https appeared 20 years ago, and it is also good at defending the middle man attack while ensuring session security (although elegant application developers can always ignore this protection inadvertently)
There are quite a few introductions to man-in-the-middle attacks on the Internet, but there are relatively few specific implementations (here is a pointer to https man-in-the-middle attack practice)
The above diagram simply describes the main process of man-in-the-middle attacks (the upper part is normal https traffic and the lower part is hijacked https traffic), and we can implement our own man-in-the-middle attack against this figure later.
Need to prepare some simple common tools in advance:
1: Fiddler (Note that although the actual principle of Fiddler fetching HTTPS messages is MITM, of course, this is not a Fiddler implementation of man-in-the-middle attacks. Because Fiddler is auto-completed, there is no practical meaning, and Fiddler needs to be imported by the attacker himself. And trust the root certificate)
2: A domain name that has already applied for an SSL certificate (requires a domain name also means that you need a nginx server that proxyes the domain name. The reason why you choose a real domain name here is to restore the reality as much as possible. If you don’t have a domain name, Can be replaced with ip, but the certificate should be prepared in advance)
Here is a legally issued DV certificate (it is easy to find a free certificate on the Internet). When a browser or client verifies a certificate, it will first check whether the certificate is issued by a “trusted root certificate authority”. Check the certificate revocation list in the SSL certificate, check whether the SSL certificate expires, and check whether the domain name of the SSL certificate website is consistent with the current access domain name. If you use a legally issued certificate, you can actually pass most of the verification.
The initiation of an HTTPS session requires the establishment of an SSL channel.
We use Fiddler to direct all HTTPS traffic to our own server [lulianqi.com]
To guide the traffic, you need to use the FreeHttp plugin . After the plugin is installed, you can directly configure it by following the screenshot (FreeHttp itself) Powerful custom message tampering ability.
Open Fiddler into the FreeHttp plugin tab as shown above, add a request modification rule, click OK, add the rule to the rule list and check the rule to make it available. (If you don’t have a domain name, you can use ip instead, change http://xxx.com:443 to http://your server’s ip:443) (note the red line mark in the picture, such as the above Set the enable rule)
Here is a brief description of the HTTPS request using the proxy will use the Connect request to establish the SSL channel, we can modify the Connect connection target (because the SSL channel has not been established at this time, the target address is still plain text, we can directly modify, so that the operation can simulate the network Existing attack)
FreeHttp skips connect tunnels by default, so here we need to set is skip connect tunnels in the settings item (do as prompted in the figure)
Then Fiddler’s own settings
As shown above, configuring only the Captures in Options, it also mentioned that we don’t need Fiddler for man-in-the-middle attacks, so we don’t need to decrypt them, and we don’t need to import certificates on the client.
Finally, we need to configure nginx on our server (of course, before this, your nginx needs to install and configure the network on the server first)
As shown above, we add a server directly in nginx for hijacking the session (our own domain name is to be resolved), and the certificate uses a dv certificate from lulianqi.com.
This nginx is actually a middleman. Now our middleman only hijacks traffic (ie passive network attack), but once traffic reaches our server and the SSL channel is established with our server, it means we can handle this traffic arbitrarily. Active network attacks are available at any time.
Implement man-in-the-middle attacks
After all the preparations are done, we can see the effect of the man-in-the-middle attack.
TLS defense against man-in-the-middle attacks
Of course, under normal circumstances, our network security will certainly not be so fragile, so for the time being we see below is how to see how the browser can defend against man-in-the-middle attacks with HTTPS (LTS) under normal circumstances.
Use a browser to access https://www.baidu.com
Thanks to the TLS certificate system, although we can launch a man-in-the-middle attack, the browser is aware of the certificate exception (this time I am afraid you will continue to browse)
How does the browser know that the current channel is at risk? The browser knows that the host that needs to be connected is www.baidu.com. We use the network hijacking method to let the browser think that our middleman server is www.baidu.com. However, our middleman server does not have the certificate of www.baidu.com, so we still use the certificate of lulianqi.com. We also mentioned that the client such as browser will check the “trusted root certificate authority”. Certificate revocation list, whether the SSL certificate expires, and the domain name issued by the certificate. Finally, the browser finds that the domain name issued by our certificate is not www.baidu.com, naturally knows the risk of the current network, then stops sending real business requests and prompts or asks the user.
(Certificate verification depends on CA, and CA is generally a more authoritative organization, we choose to trust them)
If the user insists on accessing, the error shown in the certificate above will appear, but it also means that you may be under attack (in fact it is)
Then we and my server perfectly hijacked the user’s session, all the information is exposed (so it is better to encounter such a prompt or not to confirm)
The following picture and the similar pictures below are the access logs of the middleman server nginx. If the corresponding request message appears in the log, it means that the man-in-the-middle attack is successfully implemented.
Look at the performance of Chrome here.
Chrome is clearly better at handling HSTS. Because for the www.baidu.com that has opened the strict secure transmission HSTS, the browser finds the certificate error, Chrome’s approach is to directly prohibit access, and Edge can still continue to access by asking.
The above example demonstrates the basic process of a man-in-the-middle attack and how the browser protects against man-in-the-middle attacks through a certificate system. (HTTPS defense against man-in-the-middle attacks)
Another point to note is that the traffic or conversations mentioned above and below refer to HTTPS, and if you are using http then the risks are always there.
Unable to defend against instances of man-in-the-middle attacks (know, 360 browser)
In reality, we spend more time with our mobile phones. Let’s see if mobile apps on mobile phones can resist such man-in-the-middle attacks.
Many applications use HTTPS to communicate with the backend, which is common in system programs, websites, and mobile applications. Unfortunately, application developers often do not properly validate certificates, so the system is actually open to attackers.
The QA process should include tests for certificate verification.
First we connect the phone to the Fiddler agent (note that we don’t need to have the phone installed or trust any third party certificate)
We try to use the phone like everyday life (note that the test is using the IOS app)
Most applications have inaccessible, pop-up security tips, etc.
But unfortunately there are still some applications that ignore the protection of the certificate, directly establish a connection with the dangerous intermediary server, and display the page and other data to the user.
Here are a few representative strong APPs to explain (this is not specifically selected these apps, but I just installed them in my mobile phone, and I personally think that these apps are more common)
1: Know (IOS version 4.34.1 (1228))
It can be clearly seen that the error is completely ignored, and the performance is the same as that of the MITM. Normal access and normal submission of data. But the fact is that all traffic is forwarded through the middleman server, the intermediate server decrypts all traffic and can tamper with it. Worse, when this happened, the user was completely unaware of it. To put it simply, when you use the app to browse or post, anyone with ulterior motives in the network node can get the content you are browsing and modify it. (This description is not exaggerated. It will be explained later that in actual MITM, you will not need your phone to connect to the Fiddler agent in advance. There are many feasible and more secret ways to introduce traffic to the middleman server. If the application does not recognize the share, Will be the same as described above)
2:360 browser (IOS version 360 browser 4.0.10)
In fact, a certain APP can not resist MITM due to its own security problems, and it will only affect its own APP and its own users. However, if this problem occurs in the browser, it will affect all the websites that users browse.
Especially 360, which is a big selling point of security, the security policy of its own browser is incomprehensible.
The screenshot above comes from the use of 360 browser to browse baidu and apple respectively. You can see that using 360 mobile browser to browse the webpage (the website that starts https), there is only one unremarkable change when it is received by MITM, which should be green. The small shield became gray, and no inquiries were made to the user, and an insecure SSL channel was established directly. The latter situation was very alarming. All the content viewed using the 360 mobile browser was hijacked by the middleman server.
At first, I didn’t believe that the 360 mobile browser would ignore the certificate error directly and would not ask the user. Deliberately found another mobile phone (iphone6) that has not installed 360 mobile phone browser, downloaded a new version of 360 mobile phone browser test in AppStore, the result is the same, except that the humble gray small shield completely ignores the certificate. The domain name does not match the error. (By the way, the above knowledge is the same, all tested with new mobile phones, there are indeed security issues)
3: Other APP
Of course, I have not only found the above two APP problems in my mobile phone, but also many similar problems exist in APP, including individual financial applications, and some of the APP part of the module traffic is hijacked. It is not listed here.
Through the above practice, we can see that the network we usually use is not safe. Some developers ignore the certificate verification, or improperly handle the certificate exception, which leads to the very effective LTS losing its original defense capability.
Under the emphasis, the individual is not malicious for the two App mentioned above (know, 360 browser), just to illustrate some of the security risks that exist in the current network environment.
It is also hoped that the relevant developers of the two APPs will be able to improve in time to provide users with a safer environment.
The above practice test environment (you can re-do the above effect)
Mobile: iphone6 (10.3.3), iphone6s (11.3.1), iphone8 plus (11.2.1)
Server: CentOS (7.3) nginx (1.10.3)
The two apps tested above are Apple app
360 mobile browser (4.0.10)
The above-mentioned man-in-the-middle attack practice uses the Fiddler and FreeHttp plug-ins only to facilitate the control and debugging of the man-in-the-middle attack state. Fiddler is not needed in the actual operation, which means that your mobile phone does not need to connect any proxy, because the traffic hijacking often occurs. In a more subtle network node, for example, a network device in a link can forward its own traffic to a middleman server without feeling, or the hijacking may be caused by DNS resolution. You can try to modify the host file. The simulated dns hijacking can also get the above result by pointing the target domain name to the middleman server.
In fact, ARP spoofing, WPAD hijacking, DNS hijacking, and BGP route hijacking will all create conditions for such man-in-the-middle attacks. It is easier to implement as a controller of network devices, so don’t connect wifi hotspots that you don’t know, of course, for network operations. We can only choose to believe)
As long as the developer correctly opens the certificate verification in the underlying TLS library of the platform and handles the exception certificate properly, HTTPS is relatively safe.
The above content is only for communication, please do not use it for actual network attacks.