Furious in silence-Cookie burst

Source: Internet
Author: User

Furious in silence-Cookie burst
Preface

Today, we use this tactic again to implement a killer attack solution-Cookie data explosion through internal and external integration.

Traditional sniffing

In the past, Cookie Theft was mostly achieved through sniffing traffic.

This method is highly concealed and hardly noticeable. However, because of this, there is also a huge defect: the speed is too slow.

Man-in-the-middle can only sniff the pages that users are visiting, and wait slowly for the expected websites. In a stable network environment such as home and office sites, long waits may still produce the desired results. However, it is not that easy for users who access the Internet in public areas.

In public networks, everyone is always vigilant and seldom visits important websites. Moreover, temporary network users will not stay too long. Therefore, pure traffic sniffing makes it difficult to capture more meaningful data.

Frontend attack

Since users do not play cards as we do, our front-end tactics have to come in handy-as long as we can control the page, everything is up to us. Even if the user is not trapped, our script can force jump to the past to easily win the desired Cookie data.

However, the force redirect method is too violent. Although we use the high-profile method of page hijacking, what we do later still needs to be hidden.

You may say that you can hide the framework page to greatly improve concealment. This method is really good. It is a step closer to our goal, but it is still not perfect. Why is it too costly to access the page to obtain cookies.

In fact, the sending and request types of cookies are irrelevant. Whether it is page access or third-party resource loading, as long as the target URL matches the path of the Cookie database, the matching records will eventually be carried. Maybe you didn't notice this at ordinary times, but we can immediately verify it.

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

When a request packet is caught, the Cookie is obtained:

But is the data complete? Can it be used directly? We don't have to guess much. Stick it to other browsers and try:

When we refresh the page again, a miracle occurs:

 

Through cookies, we successfully restored the previous logon status. All of this is obtained only from a third-party image request!

Therefore, a man-in-the-middle can use a very lightweight method to obtain the Cookie of a website, without requiring the user to access the site.

We can collect a large number of website addresses in advance so that front-end spies can find a considerable number of accounts one by one:

Solution Optimization

The front-end and back-end combined tactics are presented again here. However, in order to give full play to it, we still need to make full optimization.

Path tag

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

It would be a waste of time to go through the proxy. Now that we have obtained the Cookie, we can return anything we like. But if we return NULL content, if the user just opens the website, it will be white.

In order not to affect the sending of cookies, and to make the man-in-the-middle understand that this request is from our own people, we add a special flag to the request URL.

When a man-in-the-middle finds that the request carries this dark sign, the man-in-the-middle naturally understands that the information contained in the request is recorded, and then the man-in-the-middle can safely return the blank space.

Because the Path attribute of the Cookie does not include Query, adding this mark does not affect the carrying of the Cookie. Which of the following are the same.

In addition, modifying the PATH also has another advantage: even if the site is cached by the detective, it can generate request traffic. This is a better choice than any other goal!

DNS Acceleration

The proxy problem is solved. Sending cookies now requires only a small amount of traffic.

At this time, the bottleneck is not just HTTP traffic. Because we have prepared a large number of websites in advance and all of them have their own domain names, DNS queries have become a part of the review.

To shorten the query time, We can forward all the packets sent to UDP/53 to the man-in-the-middle DNS service and resolve them to their own IP addresses. This not only accelerates the domain name query process, but also saves a lot of bandwidth for middlemen.

Of course, today's browsers have greatly optimized domain name resolution. Therefore, the speed improvement on the front end may not be obvious.

However, this method is still of great significance-we hijack DNS and HTTP at the same time, which means that the entire solution can launch offline attacks without relying on the Internet! This is especially suitable for outdoor environments with high Internet access costs.

Trace collection

Of course, not all accounts have to be restored through cookies. For websites with a little emphasis on security, their logon sessions are all bound to IP address segments. If there is a big difference between the restored Internet IP address and the user's previous use, this Cookie may become invalid.

 

But most of the time, we hijack users nearby, or even the same Intranet, so there are still a lot of restoration capabilities.

 

However, as the security level increases, some websites not only bind IP addresses, but also User-Agent information. In the future, more traces will be bound to users, such as screen resolution, plug-in version, and drawing algorithm, to more accurately identify users.

To improve the restoration success rate, we also collect as much user information as possible. In addition to the User-Agent, we can also consider using front-end code to collect more detailed browser feature information. When the account is restored, all the information is simulated into the sandbox to pretend to be seamless.

Attack demonstration

When the victim enters our Hijacking environment and opens any page, the XSS script can be triggered. (Of course, the whole page is replaced to make the demo simple. In practice, you can refer to the injection method in the previous article)

Our logs successfully record the cookies of various accounts:

So, at this moment-despite having not done anything, many accounts have been controlled by hackers:

Of course, only the most basic functions are demonstrated here, And the Cookie that is sniffed is saved in the file. There are several methods to restore data.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.