The principle and practice of man-in-the-middle attack

Preface

I have read the introduction of HTTPS TLS the relevant details of 061a739a1a4cca, and I believe that using HTTPS is relatively safe and reliable. It wasn't until a while ago that MITM https proxy channel, and I found that the fact is not what I thought. Because some application developers ignore the verification of certificates, or improperly handle illegal certificates, our network sessions are almost exposed to attackers.

The following will show you the man-in-the-middle attack ( Man-in-the-MiddleAttack , referred to as " MITM IOS , 360 browser) on the 061a739a1a4cf1 system to obtain or tamper with user data.

basic introduction

A man-in-the-middle attack ( Man-in-the-MiddleAttack , referred to as " MITM attack") means that the attacker creates independent connections with both ends of the communication, and exchanges the data they receive, so that both ends of the communication think they are communicating with each other through a private connection Direct conversation, but in fact the entire conversation is completely controlled by the attacker. In an attack in the middle, the attacker can intercept the conversation between the communicating parties and insert new content. A man-in-the-middle attack is a (lack of) mutual authentication attack. Most encryption protocols have specially added some special authentication methods to prevent man-in-the-middle attacks. For example, the SSL protocol can verify whether the certificate used by one or both parties involved in the communication is issued by an authoritative trusted digital certificate certification authority, and can perform two-way identity authentication.

There are quite a lot of introductions to man-in-the-middle attacks on the Internet, but there are a lot less specific to practice (here is the practice of man-in-the-middle attacks https

The above figure simply describes the main process of a man-in-the-middle attack (the upper part is the normal https traffic, and the lower part is the hijacked https traffic). Later, we can use this chart to implement our own man-in-the-middle attack.

Prepare for a man-in-the-middle attack

Some simple and common tools need to be prepared in advance:

1: Fiddler (Note that although Fiddler crawl HTTPS actual principle message is that MITM , but certainly not here with Fiddler . Implement middle attack because Fiddler is done automatically, there is no practical significance, and Fiddler need to be ahead of their own import attacker And trust the root certificate)

2: A domain name that has applied for a SSL (needing a domain name also means that a nginx server is required to proxy the domain name. The reason for choosing a real domain name here is to restore the real scene as much as possible. If you don’t have a domain name, You can use ip instead, but the certificate must be prepared in advance)

Here is a legally issued DV certificate (in fact, it is easy to find a free certificate on the Internet). Generally, when a browser or client verifies the certificate, it will first check whether the certificate is issued by a "trusted root certification authority". then check SSL certificate certificate revocation list, and then check to check this SSL certificate is expired, then check SSL whether the site's domain name certificates consistent with the current access domain. If you use a legally issued certificate, you can actually pass most of the checks.

HTTPS session requires the establishment of the SSL channel first.

We use Fiddler direct all HTTPS to our own server [ lulianqi.com ]

You need to use the FreeHttp plug-in ( https://www.cnblogs.com/lulianqi/p/10428551.html#_label0_1 can download the plug-in here) to guide traffic. After the plug-in is installed, just follow the screenshot below to configure it ( FreeHttp It has a strong ability to tamper with custom messages. If you are interested, you can check the details at the previous link).

Fiddler as shown in the figure above and enter the FreeHttp plug-in tab, add a request to modify the rule, click OK, add the rule to the rule list and check the rule to make it available. (If you do not have a domain can also be used ip instead, the http://lulianqi.com:443 replaced http:// your server ip:443 to) (Note that the figure places the red frame mark, such as the above settings enable the rule)

Here is a brief description that the HTTPS request using the proxy will use the Connect request to establish the SSL channel, we can modify the Connect connection target (because at this time the SSL channel has not been established, the target address is still plaintext, we can modify it directly, so that the operation can simulate the network Existential attack)

FreeHttp default skip connect tunnels , so here we need to set in settings where is skip connect tunnels NO (according to the figure prompts)

Then Fiddler own settings

As shown in the Options above, the configuration in 061a739a1a5057 is configured to capture only Connects . It is also mentioned above that we actually do not need Fiddler for man-in-the-middle attacks, so there is no need for decryption and no need to import certificates on the client side.

Finally, we need to configure our server [ lulianqi.com on] nginx (Of course, before your nginx need to install and configure the network on the server)

In the above chart we directly nginx add one server used to hijack sessions (our own domain name to be resolved over), a certificate using lulianqi.com one dv certificate.

This nginx actually a middleman. Now our middleman only hijacks traffic (ie passive network attack), but once the traffic reaches our server and the SSL channel is established with our server, it means that we can handle the traffic arbitrarily. Active cyber attacks can be carried out at any time.

Perform a man-in-the-middle attack

After all the preparations are done, we can see the effect of the man-in-the-middle attack

TLS to man-in-the-middle attacks

Of course, under normal circumstances, our network security will certainly not be so fragile, so for the time being, what we see below is to see how the browser uses HTTPS（LTS） resist man-in-the-middle attacks when everything is normal.

https://www.baidu.com with a browser

TLS to the 061a739a1a51ad certificate system, although we can launch a man-in-the-middle attack, the browser has noticed an abnormality in the certificate (this time I’m afraid you click to continue browsing)

How does the browser know that the current channel is at risk? From the beginning, the browser knows that the host it needs to connect to is www.baidu.com . Although we use network hijacking to make the browser think that our middleman server is www.baidu.com , our middleman server does not have www.baidu.com The certificate, so we still use the lulianqi.com . We mentioned earlier that the browser and other clients will check the "Trusted Root Certification Authority", the certificate revocation list, SSL certificate has expired, and the domain name of the certificate. Finally, the browser found that the domain name issued by our certificate was not www.baidu.com , so it naturally knew the risks of the current network, and then stopped sending real business requests, and prompted or asked the user.

(The verification of the certificate depends on CA , and CA are generally more authoritative organizations, we choose to trust them)

If the user insists on accessing, there will be an error as shown in the certificate above, but it also means that you may be under attack (in fact, this is the case)

Then our server hijacked the user's session perfectly, and all the information was exposed (so if you encounter such a prompt, it is better not to confirm it)

Supplementary explanation The above picture below and the similar pictures below are all nginx . If the corresponding request message appears in the log, it means that the man-in-the-middle attack has been successfully implemented.

Here, by the way, look at the performance of Chrome

Chrome obviously better for HSTS . Because for secure transmission has been turned on strict HSTS of www.baidu.com , the browser sees a certificate error, Chrome practice is prohibited direct access, but Edge can still continue to access by asking the way

The above example demonstrates the basic process of a man-in-the-middle attack, and how the browser uses the certificate system to resist the man-in-the-middle attack. ( HTTPS 's resistance to man-in-the-middle attacks)

One more thing to note is that the traffic or conversations mentioned above and below refer to HTTPS . If you are using http then the risk is always there.

Unable to defend against man-in-the-middle attacks (Zhihu, 360 browser)

In reality, we spend more time with mobile phones. Let’s see if mobile applications on mobile phones can resist this kind of man-in-the-middle attack.

Many applications use HTTPS to communicate with the backend, which is very common in system programs, websites and mobile applications. Unfortunately, application developers often fail to verify the certificate correctly, so the system actually opens its arms to attackers.

QA process should include certification verification tests.

First, we connect the phone to the Fiddler proxy (note that we don’t need to let the phone install or trust any third-party certificates)

We try to use mobile phones as we do in our daily life (note that the tests here are all on IOS on APP )

Most applications are inaccessible, pop-up security prompts and other reactions

Unfortunately, there are still some applications that ignore the protection of the certificate, directly establish a connection with the dangerous middleman server, and display the page and other data to the user normally.

A few representative APP are listed below for explanation (this is not a deliberate selection of these APP , but my phone happens to be installed, and personally think that these APP are also commonly used by everyone)

1: Zhihu (IOS version 4.34.1 (1228)) #

MITM completely ignored the certificate mismatch error, and behaved the same as when it was not received by 061a739a1a546b. Normal access and normal submission of data. But the fact is that all traffic is forwarded to Zhihu through the middleman server, which decrypts all traffic and can tamper with it. What's worse is that when all this happens, the user is completely unaware of it. Simply put, when you use APP browse or post, any person with ulterior motives in the network node can obtain the content you are browsing and modify it. (This description is not an exaggeration. It will be explained later that in the actual MITM , your phone will not need to be connected to the Fiddler proxy in advance. There are many feasible and more secret ways to introduce traffic to the middleman server. If the application cannot recognize the sharing, Will be the same as described above)

2: 360 browser ( IOS version 360 browser 4.0.10)

In fact, a section specific APP due to their own security problems can not resist MITM , most will only affect their own APP and their users, but the browser if this problem will have an impact on all users browse websites

Especially 360, where security is a big selling point, its own browser’s security policy is incomprehensible

The screenshot above is from the case of using the 360 browser to browse baidu and apple respectively. You can see that using the 360 mobile browser to browse the web (open the website of https MITM is only one inconspicuous change when it is subjected to 061a739a1b34a4, which should be green originally. The small shield turned gray, and without any inquiry to the user, the insecure SSL directly established. The following situation was terrifying. All the content browsed using the 360 mobile browser was hijacked by the middleman server.

At the beginning, I did not believe that the 360 mobile browser would directly ignore the certificate error and would not ask the user. iphone6 ) that has not installed the 360 mobile browser, AppStore . The result is the same, except that the small gray shield completely ignores the certificate. Mismatched domain name error. (By the way, the above Zhihu is also the same. They have been tested with new phones, and there are indeed security issues.)

3: Other APP

Of course, I found on my mobile phone that not only the above two APP models have the above problems, but also many APP have similar problems, including individual financial applications, and some APP module traffic is at risk of being hijacked. I will not list them all here.

Through the above practice, we can see that the network we usually use is not secure. Some developers ignore certificate verification or improperly handle certificate exceptions, which causes the originally very effective LTS lose its original defense capabilities.

Improve

I would like to emphasize that the individual is App (Zhihu, 360 browsers) mentioned above, just to illustrate some of the security risks that do exist in the current network environment.

I also hope that APP models can improve in time and provide users with a safer environment.

The above practice test environment (you can review the above effect here)

• Mobile phone: 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 both Apple's version APP
• Knowing (4.34.1)
• 360 mobile browser (4.0.10)

Fiddler and FreeHttp plug-ins are used in the above-mentioned man-in-the-middle attack practice only to facilitate the control and debugging of the state of the man-in-the-middle attack. In actual operation, Fiddler is not required, which means that your mobile phone does not need to connect to any proxy, because traffic hijacking often occurs In more concealed network nodes, for example, the network devices in the link can forward their own traffic to the middleman server first without feeling, or this hijacking may also be caused by the DNS , you can try to modify the host file Simulating dns hijacking and directing the target domain name to the middleman server can also get the above result.

In fact ARP deception, WPAD hijacking, DNS hijacking, BGP route hijacking, it will create the conditions for such a man in the middle attacks (as controlled by network devices easier to implement, so do not connect do not know wifi hot, of course, for network operators We can only choose to believe in business)

ssltrip2 by arp response spoofing tampered page content, will https downgraded to http do hijacking, Quxianjiuguo. This attack uses many websites that do not turn off the http access, but jump the http https on the server side, giving the attacker a http response as a breakthrough. However, this kind of attack can also be defended by enabling hsts and pre load , so that the attacker cannot find any opportunities for http

As long as the developer correctly TLS library at the bottom of the platform, and handles the abnormal certificate reasonably, HTTPS is relatively safe.

above 161a739a1b3a31 is for communication only and should not be used for actual network attacks.