Original author:Original author:cosine

, Founder of SlowMist Technology

DNS Hijacking (hijacking) should be familiar to everyone. In history, MyEtherWallet, PancakeSwap, SpiritSwap, KLAYswap, Convex Finance, etc., as well as today’s CurveFinance, have encountered more than a dozen well-known cryptocurrency projects. But many people may not necessarily know the root cause of the hijacking, and more importantly, how to defend (from the perspective of the project party and the perspective of users), I will briefly share it here.

Domain -> IP_REAL

DNS allows us to find the corresponding IP when accessing the target domain name:

Domain ->If this pointing relationship is replaced by an attacker:

IP_BAD (Controlled by Attacker)

Then the attacker can forge the content of the response from the server where the IP_BAD is located. Ultimately for the user, anything under the target domain in the browser may be problematic.

• DNS hijacking is actually divided into several possibilities. For example, there are two common types:

• The domain name console is hacked, the attacker can arbitrarily modify the DNS A record (point the IP to the IP_BAD controlled by the attacker), or directly modify the Nameservers to the DNS server controlled by the attacker;

Do rough man-in-the-middle hijacking on the network, and force the target domain name to point to IP_BAD.

The first point of hijacking can be done silently, that is, there will be no security prompts on the user’s browser side, because at this time, the attacker can issue another legitimate HTTPS certificate.

The hijacking of point 2 cannot be hijacked silently if the domain name adopts HTTPS, and an HTTPS certificate error prompt will appear, but the user can force to continue accessing, unless the target domain name is configured with the HSTS security mechanism.

Emphasis: If the domain name of the Crypto/Web3 project does not enforce HTTPS (meaning that HTTP can still be accessed), and HTTPS does not force HSTS (HTTP Strict Transport Security) to be enabled, then for the hijacking scenario of point 2 It is very risky. Keep your eyes open, everyone, and be vigilant.

• For the project side, in addition to the complete configuration of HTTPS + HSTS for their domain name, the following security checks can be done routinely:

• Check whether the DNS records (A and NS) related to the domain name are normal;

• Check whether the certificate display of the domain name in the browser is configured by yourself;

• Check whether the relevant platform of domain name management has enabled two-factor authentication;

Check whether the web service request log and related logs are normal.

For users, there are several defense points, and I will explain them one by one.

http://example[.]com

For key domain names, resolutely do not access them in the form of HTTP, such as:

https://example[.]com

Instead it should always be of the HTTPS form:

If the HTTPS form, the browser has an HTTPS certificate error, then resolutely do not continue. This prevents non-silent DNS hijacking attacks.

Regarding the situation of silent hijacking, whether it is DNS hijacking, or project server being hacked, internal evil, project front-end code being poisoned by supply chain attacks, etc., in fact, from the perspective of users, the final manifestation is the same. There will be no abnormalities on the browser side, until a user's assets are stolen.

So how can users defend in this case?

In addition to keeping vigilance in every step of the operation (especially the moment when the wallet needs to be signed and confirmed), the user should be vigilant.

I recommend a very well-known browser security extension in the Web2 era: @noscript (although Twitter has not been updated for a long time, but I was pleasantly surprised to find that the official website has been updated, and the extension has also been updated), which is the work of @ma1.

NoScript blocks embedded JavaScript files by default.

But NoScript has a little getting used to the threshold, and sometimes it may be annoying. My suggestion is that important domain name access can be performed on a browser with NoScript installed (such as Firefox), and other browsers (such as Chrome).

It is good security practice to operate in isolation. Many things you may find cumbersome, after driving and getting used to them, everything will be fine.

https://curve[.]fi/js/app.ca2e5d81.js

But this is not a perfect defense (there has never been a perfect defense). For example, in this @CurveFinance attack, the attacker changed its DNS A record to point to an IP_BAD, and then polluted the front-end page:

Malicious code related to coin theft was implanted.

If we trusted Curve with NoScript before, we may be tricked this time too.

Original link

Original link