Simplified version: https://www.cnblogs.com/index-html/p/mitm-cookie-crack.html

Preface

The previous article explained how to build a tool higher than sslstrip with the help of front-end technology.

Today, we use this set of tactics again, through the combination of inside and outside at the front and back ends, to achieve a killer mace level attack scheme - Cookie data eruption.

Traditional sniffing

In the past, the stealing of cookies was mostly realized by sniffing traffic.

This method has a strong concealment, which is almost imperceptible. However, because of this, there is also a huge drawback: too slow.

The middleman can only sniff the page that the user is visiting, and can only wait for the expected website. In the stable network environment such as home and office, long-term waiting may still get the desired results, but for users in public places, it is not so easy.

In the public network, people keep some vigilance and seldom visit some important websites. Moreover, the temporary network users will not stay too long. Therefore, pure traffic sniffing is difficult to capture more meaningful data.

Front end attack

Since users don't play our game, our front-end tactics will come in handy - as long as we can control the page, everything can be up to us. Even if the user is not trapped, our script can also force a jump in the past, so as to easily take the desired cookie data.

But the way to force a jump is too violent. Although we use the high-profile way of hijacking pages, we still need to keep our actions hidden.

You may say that you can replace it by hiding frame pages, which can greatly improve the concealment. It's a good way. It's a step closer to our goal, but it's still not perfect. Why do you have to access the page to get cookies? It's too expensive.

In fact, the sending of cookies has nothing to do with the type of request. As long as the target URL matches the path of the cookie database, whether it is page access or third-party resource loading, the matching records will be brought eventually. Maybe you don't notice this, but we can verify it right away.

First, we start a third-party resource request on the page:

If you catch the request package, you will get the cookie:

But are these data complete and can they be used directly? Without much guessing, let's try to paste it into other browsers:

When we refresh the page again, a miracle happens:

Through cookies, we successfully restored our previous login status. And all this, only from a third-party image request!

Therefore, the middleman can use a very lightweight way to obtain cookies under a site, without the user's active access to the site.

We can collect a large number of website addresses in advance, and let the front-end spies spy one by one, so that we can sniff a considerable part of the accounts:

Scheme optimization

The combination of front and rear tactics is shown here again. But in order to give full play to it, we need to make full optimization.

Path marking

Although we can load the third-party resources to send the cookies of the target site to the traffic. But what should the middleman do after receiving the request? Return to blank content or proxy normal page?

It would be a waste to walk through the agency. Now that we've got cookies, we can return anything we like; but if we return empty content, if the user just opens the website, it's a white screen.

In order not to affect the sending of cookies, and to let the middleman understand that the request is our own, we add a special tag in the URL of the request.

When the middleman finds that the request has this code, he will naturally understand - record the information carried in it, and then return to the blank safely.

Because the path property of the cookie does not include query, adding this token does not affect the carrying of the cookie. What used to be is still the same now.

Path

In addition, changing the path has another advantage: even if the detective is cached, it can generate request traffic. So as to better than any goal!

DNS acceleration

Solved the proxy problem, sending cookies now requires minimal traffic.

At this time, the bottleneck is not only HTTP traffic. Because we have prepared a large number of websites in advance, they all have their own domain names, so DNS query has become a part that can not be ignored.

In order to shorten the query time, we can forward all packets sent to UDP / 53 to the DNS service of the middleman and resolve them to our own IP. This not only speeds up the process of domain name query, but also saves a lot of bandwidth for the middleman.

Of course, today's browsers do a lot of optimization on domain name resolution. So on the front end, the speed increase may not be obvious.

But this way still has great significance - we hijacked DNS and HTTP at the same time, which means that the whole scheme can not rely on the Internet for offline attacks! This is especially suitable for outdoor environment with high cost of Internet access.

Trace collection

Of course, not all accounts have to be successfully restored through cookies. For websites that pay a little attention to security, their login sessions are bound with IP address segments. If there is a big difference between the Internet IP when restoring and the previous one used by the user, this cookie is likely to fail.

But most of the time, we hijack users nearby, or even the same intranet, so there are still many that can be restored.

However, with the improvement of security level, some websites are not only bound with IP address, but also associated with user agent and other information. In the future, even more traces of users will be bound, such as screen resolution, plug-in version, drawing algorithm, etc., to identify users more accurately.

In order to improve the success rate of restore, we also collect as much user information as possible. In addition to user agent, we can also consider collecting more detailed browser feature information through front-end code. When the account is restored, the information is simulated into a sandbox, and the disguise is seamless.

Attack demonstration

Demo: https://github.com/EtherDream/cookie_hijack_demo

When the victim enters our hijacking environment and opens any page, the XSS script can be triggered. (of course, for the sake of simplicity, the whole page has been replaced here. In actual combat, you can refer to the injection method of the previous article.)

Our log successfully records cookies of various accounts:

So, in this moment - although nothing has been done, many accounts have been controlled by hackers:

Of course, only the most basic functions are shown here, and the sniffed cookies are saved in the file. As for how to restore, there are countless ways, which will not be introduced here.