In this article, we will discuss the security issues faced by blockchain projects originating from the realm of Web 2.0. Due to the absence of established practices in this domain, there is limited public information available on the protective measures implemented by these projects. The article serves as a more comprehensive account of the report presented at the previous Positive Hack Days 12 cyber festival, which focused on the same subject.
This article covers several aspects and we will:
- examine how attackers executed network-level attacks, reconstructing numerous attack steps using open data, down to the minute details
- decompile the smart contracts employed by the attackers
- explore the protective measures implemented by the affected projects, identifying their shortcomings
- endeavor to enhance the detection mechanisms for these specific attacks and devise safeguards against them.
We will also delve into blockchain explorers, discovering methods to identify attacker’s contracts within the blockchain based on knowledge of just one contract.
Lastly, we will provide guidance on the necessary steps that cryptocurrency holders should take to avoid falling victim to these attacks.
Introduction
In 2022, a minimum of 20 distinct blockchain projects fell victim to DNS hijacking and BGP hijacking attacks. These malicious attacks manipulated the flow of traffic from users of projects such as Allbrigde, Celer Network, Ribbon Finance, Convex Finance, and several others, diverting it towards servers controlled by the attackers. According to data provided by SlowMist, a blockchain security company, the financial losses resulting from these incidents exceeded $3 million in 2022 (when searching for the DNS keyword). In certain instances, the affected users were compensated by the DeFi companies themselves, as a means to mitigate any negative impact on their reputation.
Regardless of the specific details, all the DNS hijacking and BGP hijacking attacks under consideration share certain common characteristics.
In all of these cases:
- Unauthorized SSL certificates were issued
- The contract addresses of legitimate projects were manipulated, leading users to unknowingly transfer funds to fraudulent websites impersonating the targeted projects
- The funds stored within the actual project contracts were not affected
- The contract addresses that users interact with are specified within the code of the web application.
To facilitate address spoofing, the attackers duplicated websites and modified the contract addresses on them.
In certain instances, users affected by the replicated projects were required to grant permission to the attackers’ contracts in order for them to manipulate their cryptocurrency assets. You can learn more about why these permissions are necessary here.
Several factors contributed to the success of these attacks:
- Crypto wallets, such as MetaMask, had poor user experience (UX) and user interface (UI) design
- There were instances where legitimate projects and attackers had contract addresses with similar spellings
- The companies targeted in the attacks responded slowly to the incidents
- The attackers achieved site similarity by employing address generators based on vanity address technology.
These generators enabled them to create contract addresses that matched the desired pattern in the first and last characters.
We will focus on the browser version of MetaMask, which is one of the most widely used browser-based crypto wallets. From this point forward, we will refer specifically to the MetaMask plugin for browsers.
Due to the inadequate UX and UI quality, MetaMask only displayed a portion of the address. Let’s examine the example of the MetaMask version that was relevant during the attacks (version 10.25.0). The image below (refer to Figure 2) illustrates that the field shows only a few of the first and last characters of the address. Considering that attackers could generate a desired address when creating a contract, this window would appear identical to when using a legitimate address.
Simultaneously, the user has the option to access additional information within the window prior to confirming their transaction. By clicking on the button (refer to Figure 3) adjacent to the address fragment, the user can open the website in the blockchain browser. This will display the complete address and provide clarification regarding its association with the respective project (refer to Figure 4).
However, when the user clicks on the “View full transaction details” button in the MetaMask window (refer to Figure 2), it has the opposite effect and confuses the user even further. Once again, the complete contract address is not displayed, making it impossible to ascertain whether the addresses of the legitimate and malicious contracts are a match.
The project owners became aware of the attacks targeting project users through the victims themselves. This enabled the attackers to deceive users who agreed to grant permission for the fraudulent contract’s use of cryptocurrency.
Analysis of Attack Methods and Implications for Domain Security
In the majority of cases under consideration, the attacks succeeded by manipulating DNS records, which resulted in redirecting the traffic of users accessing the targeted domain name (website) to an IP address controlled by the attacker. However, there were certain exceptions where the attacks utilized the BGP hijacking technique. In these instances, the actual IP address did not change, but rather the route to it was altered.
By controlling the traffic associated with DNS records, the attackers were able to issue an unauthorized certificate through certificate authorities. One of the verification procedures conducted by such authorities involves confirming the domain name’s ownership by the user who requested the certificate. Since the certificate was issued in this manner, it appeared legitimate to web browsers, thereby not triggering any warnings for users when they visited the attacked project’s website.
There is limited public information available regarding the actions taken by the affected projects to safeguard against these attacks and prevent their recurrence. As a result, it is challenging to evaluate the effectiveness of these measures. Additionally, some of the measures that I did find information about appear to be ineffective.
In the following sections, we will examine several of the impacted projects and provide recommendations to enhance the efficacy of their protective measures.
Celer Network (cBridge)
Five days prior to the attack on August 12, 2022, the attacker created contracts on various blockchain networks. The addresses of these contracts were later shared on the attacked company’s Telegram channel. Below are links to the contracts on the respective blockchain browsers:
Ethereum: 0x2A2aA50450811Ae589847D670cB913dF763318E8 _ _
BSC: 0x5895da888Cbf3656D8f51E5Df9FD26E8E131e7CF
Fantom: 0x458f4d7ef4fb1a0e56b36bf7a403df830cfdf972
Polygon: 0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9
Avalanche: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9
Arbitrum: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9
Astar: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9
Aurora: 0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9
Optimism: 0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9
Metis: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9
It is important to note that the addresses of the contracts used by the attacker bear no resemblance to the addresses used by the attacked project.
On August 17, 2022, at approximately 19:25 (as indicated in UTC time), an incident occurred involving the use of the BGP hijacking technique. The incident’s timing was recorded in the bgplay service (refer to Fig. 5). This service provides a visualization of the propagation and removal of routes through the BGP protocol, as well as changes in this information over time. The BGP hijacking exposure lasted for approximately four hours, ending around 23:13 (see Fig. 6).
Detailed technical information about the utilization of BGP hijacking in this incident can be found in a report published by SlowMist, a company specializing in blockchain security solutions.
The alteration in routing caused by the incident enabled the attacker to generate a certificate. By utilizing the crt.sh service, it was determined that the certificate for the cbridge-prod2.celer.network domain was issued on August 17, 2022, at 19:42:27 and subsequently revoked on August 18, 2022, at 09:10:12. As a result of the BGP hijacking, the attacker redirected visitors of the site to their own web server. Due to the certificate issued by the attacker, web browsers did not display any security warning to users (such warnings are typically issued when there are grounds to distrust a site’s certificate).
Between August 17, 2022, at 22:33:30 and August 18, 2022, at 01:17:22, on the Ethereum network, the attacker executed a series of 15 transactions to withdraw the available funds to the Tornado Cash cryptomixer. Afterward, they ceased using the wallet associated with the address 0xb0f5fa0cd2726844526e3f70e76f54c6d91530dd. The utilization of a cryptomixer allows the attacker to create a new cryptocurrency wallet, which can receive funds from the cryptomixer against the previously provided funds. (For more information on how the Tornado Cash cryptomixer operates, please refer to its documentation.)
Analysis of Attacker’s Contract and Protective Measures Implemented by Celer Network
By accessing the Etherscan browser, it is possible to decompile the bytecode of the attacker’s contract located on the Ethereum blockchain by clicking on the corresponding button. In this case, the decompiled code will be presented in Vyper language syntax. However, I personally prefer the Solidity syntax, so I decompiled the code using dedaub.com. Upon examination, it can be observed that the attacker’s contract possesses identical functions with the same number and type of parameters as the cBridge project’s contract, which can be found in the project’s documentation. Specifically, the functions “send()” and “sendNative()” are present. The decompiled contract does not explicitly display the value of the “_addNativeLiquidity” variable, as it was established within the constructor during the contract deployment. However, this value can be viewed by inspecting the state changes after the transaction in the Tenderly service or in the Etherscan browser. The value aligns with the address of the individual who created the contract: 0xb0f5fa0cd2726844526e3f70e76f54c6d91530dd.
Hence, in the decompiled bytecode of the contract, line 12 reveals that when the “sendNative()” function is invoked, the native cryptocurrency of the blockchain (in this case, ETH) is transferred to the attacker’s address. Line 37 and line 62 demonstrate that tokens were transferred using the “send()” function.
Moreover, the decompiled contract of the attacker includes the function “0x9c307de6()”. This function is utilized to transfer tokens from the victim’s address when the victim mistakenly grants permission to the attacker’s contract through the “Approve” function. According to the Etherscan browser, the attacker called this function three times (one, two, three). Prior to these transactions, the affected users had performed an “Approve” action to the address of the attacker’s contract (one, two). The initial call to “0x9c307de6()” took place before the attack on the project, merely two minutes after the contract was deployed. It appears that the attacker aimed to verify the contract’s functionality.
On August 19, 2022, Celer Network announced that protective measures had been implemented, but specific details were not disclosed. The statement mentioned the addition of active frontend and DNS integrity checks to prevent such attacks.
According to SlowMist’s estimation, the damage amounted to 128.4 ETH (as of the record dated August 18, 2022). The SlowMist report indicates that many projects are no longer vulnerable to such attacks, but there are still some projects that remain at risk. However, no specific information is provided regarding the basis for this conclusion or the recommended protective measures to be taken.
Mad Meerkat Finance
In the case of Mad Meerkat Finance, the attacker successfully gained access to the DNS settings of the service provider and substituted the IP address of the website’s domain name with an address under their control. The company estimated the damage caused by the attack to be $2,000,000. According to the company’s report, the incident occurred on May 4, 2022, at 19:28. However, it is worth noting that the attack actually began slightly earlier, as the issuance of a certificate for the mm.finance domain was recorded on May 4, 2022, at 19:25, in the crt.sh service. The certificate remained valid until its expiration date on August 2, 2022, and was not revoked during that time.
The company’s initial mention of the attack on Twitter came 3.5 hours after the incident, on May 4, 2022, at 10:51. The incident report was also published on rekt.news. According to the report, the attack persisted for approximately three hours before the company shut down the frontend. While the report does not explicitly state the frontend shutdown, there was a tweet indicating readiness to do so. Nevertheless, transaction records indicate that users actively engaged with the attacker’s contract on May 4 and 5, with the last two transactions taking place on May 6 and 11. Despite Mad Meerkat Finance’s claim in their report on May 5, 2022, that steps had been taken to prevent the attack’s progression, these transactions serve as evidence of the ineffectiveness of those measures. The lack of certificate revocation issued by the attacker and the inherent delay in updating DNS records contribute to this ineffectiveness (for further details, please refer to the “Recommendations for strengthening the effectiveness of protection” section).
I decompiled the bytecode of the attacker’s contract using dedaub.com and discovered identical functions with the same number and type of parameters as the project contract. However, the decompiled contract does not reveal the value of the “__addLiquidityETH” variable, as it was set in the constructor during contract deployment. The state change upon deployment cannot be observed in the Cronoscan browser. To access this value, one must examine the state change after the transaction using the Tenderly service, specifically at the address 0xb3065fe2125c413e973829108f23e872e1db9a6b.
The measures taken by the company to enhance protection against such attacks remain unclear.
Allbridge
The incident involving Allbridge occurred due to unauthorized access to the DNS records of the service provider, Namecheap, which was utilized by Allbridge. Following the incident, Namecheap CEO Richard Kirkendall acknowledged the problem and confirmed that the compromised customer service agent responsible for the breach had been identified and had their authority to modify DNS records revoked. Allbridge did not disclose specific damage figures but mentioned that a significant number of users were affected. Nonetheless, from a technical perspective, this incident is noteworthy.
Using the сrt.sh service, it was discovered that on June 23, 2022, at 08:09, the attacker issued a certificate for the app.allbridge.io domain. The certificate remained valid until its expiration date on September 21, 2022, as it was not revoked during that period.
The affected company announced on Twitter that they became aware of the attack at 12:00, approximately four hours after the attacker had issued the certificate (indicating that the company was not initially aware of this particular step taken by the attacker).
The attacker created contracts on different blockchains (Ethereum, Binance Smart Chain, Polygon) with addresses that were deliberately designed to resemble the addresses of Allbridge’s contracts. Some of the attacker’s addresses were shared in a post on the official telegram channel of the project.
It is evident that the addresses of the attacker’s contracts were generated purposefully so that the first and last characters matched those of the project’s contract addresses.
On June 20, 2022, a contract with the address 0xbbbd2ed360dac9f6e005fc6a4398d7d6beabe884 was created on the Ethereum blockchain. Considering the similarity of this address to the address of the attacked project, it can be speculated that the attacker initiated preparations for the attack from that day.
The team of the affected project stated that they had changed their DNS provider and implemented new security protocols, but they did not provide specific details about these measures.
A user in the official telegram channel of the Allbridge project mentioned a transaction on the Binance Smart Chain network that occurred on the day of the incident, approximately 2.5 hours after the attacker issued the certificate. The transaction involved granting permission through the “Approve” function to an address that closely resembled the project’s contract address: 0xbbbde5d09e0ac4c32938efa3cbc0cb55d5c7e884. However, there are currently no transactions visible in the browser at this address. It is possible that the attacker made a mistake and inputted the wrong address on the frontend during the attack. It would be interesting to determine the actual address specified by the attacker on the frontend, perhaps by utilizing the WayBackMachine website snapshot archive service. Unfortunately, no snapshots are available for the specific date of interest (06/23/2022).
What makes this situation particularly intriguing is that the “Approve” action was not revoked. This can be confirmed by accessing the allowance function in the browser at the address of the USDC token. Consequently, if the address 0xbbbde5d09e0ac4c32938efa3cbc0cb55d5c7e884 is owned by someone in the future, theoretically they would be able to withdraw all USDC tokens from the address 0x32ac4fd012f0d455e5bb9394d0355e571d86f022 (refer to Fig. 7). However, in order to do so, they would need to determine the specific token for which the “Approve” was issued, as ERC20 and BEP20 tokens do not provide any notifications to the recipient regarding the authority granted through “Approve”.
A similar situation occurred for the user with the address 0x624301090700ea1e3c5b5224f89adfae405412c1. On 06/23/2022, the user granted “Approve” to the attacker’s contract. Almost a day later, the attacker exploited this permission and seized all the available ABR tokens at that time. However, the victim has not yet revoked the “Approve” action. This implies that the user could potentially become a target of another attack if they still possess ABR tokens in their account. To confirm this, one can access the allowance function in the browser at the address of the ABR token (refer to Figure 8).
Exploring the Challenges in Determining Attacker’s IP Address Changes: Insights from IP History Search Services
I was unable to determine the specific IP address to which the attacker changed the domain name (app.allbridge.io) or how long the change remained in effect. This information was not available through IP address change history search services such as DNS History, SecurityTrails, RiskIQ, VirusTotal, and Censys during the specified interval in the second half of June 2022. It is possible that these services follow a similar mechanism for recording historical data as SafeDNS, where entries for domain names may not appear on a daily basis. SafeDNS employs its own technology for automatic categorization of internet resources and detection of botnets and malicious sites. They also gather DNS requests through their cloud service, processing over 1 billion requests daily. Currently, SafeDNS has an index of 180 million domains in their web crawler and 1.2 billion records of passive DNS data, contributing to the accuracy of their threat intelligence system.
Ribbon Finance
This incident occurred as a result of unauthorized access to the DNS records of Namecheap, the provider used by Ribbon Finance. The company has stated that the number of affected users is small, with one user losing 16.5 BTC.
By using the crt.sh service, it is possible to determine that on 06/23/2022 at 06:28, the attacker issued a certificate for the domain app.ribbon.finance. This certificate remained valid until its expiration date on 09/21/2022. The attacker also created a contract with an address that closely resembles the address of the project’s contract. The address of the attacker’s contract was discovered through a tweet from SlowMist, which mentioned the attacker’s transaction. The attacker proceeded to withdraw funds after the victim granted approval to their contract.
Convex Finance
This incident occurred as a result of unauthorized access to the DNS records of Namecheap, the provider used by Convex Finance. The company reported significant losses from the attack, totaling 15,968 cvxCRV tokens and 433 CRV tokens. Convex Finance stated that the DNS hijacking attack affected the convexfinance.com domain, as well as the www.convexfinance.com domain. Through the crt.sh service, it was discovered that the attacker issued certificates for both domains on June 23, 2022, at 00:58 and 01:15 respectively.
Surprisingly, these certificates were not revoked and remained trusted until their expiration dates (September 20 and 21, 2022). One user even pointed out in the comments on a Convex Finance tweet about the incident that the certificate had not been revoked.
According to the Convex Finance report, the company became aware of the attacker’s contract, which had an address similar to the project’s contract, through a user’s tweet on June 23, 2022, at 23:00. This discovery occurred 10 hours after the attacker issued the certificate.
The attacker created the contract three days prior to the attack, on June 20, 2022. Considering the similarity of the contract’s address to that of the targeted project, it suggests that the attacker had been preparing for the attack since that day.
In response to the incident, the company stated that they have initiated “active monitoring of DNS changes,” likely in an effort to promptly detect any unauthorized alterations in the future.
Coincidences in Allbridge, Ribbon Finance and Convex Finance Attacks
These attacks on Allbridge, Ribbon Finance, and Convex Finance share common features, aside from the involvement of the Namecheap registrar. During my investigation, I decided to search for contracts with similar bytecodes on the Etherscan browser. Starting with one of the known contracts used by the attacker in the Allbridge attack (0xbbbd2ed360dac9f6e005fc6a4398d7d6beabe884), I discovered an additional 15 contracts with identical bytecodes. These contracts were all created between June 20, 2022, and June 22, 2022.
The list includes contracts that have address fragments resembling the contract involved in the attack on Ribbon Finance. However, these contracts exhibit significant differences in their code compared to the contract used in the same attack. Interestingly, the transactions involving these contracts occurred before the issuance of the certificates. It is possible that the attacker was practicing or preparing for a future attack using these contracts.
Uncovering Patterns and Funds Transfer Mechanisms in Cryptocurrency Attacks: Insights from Contract Analysis
Some contracts, such as 0x8014ae6574cace1f2435a86d4ea0472f466786ae and 0x8014fb4882b1f99a3e60aece1d39400560d986ae, share a common characteristic: their first and last characters are identical. These contracts were not previously mentioned in this article, as they seem to have been used in similar attacks on other cryptocurrency projects that also utilized the services of the Namecheap registrar. These specific attacks are not covered in this article.
To gain further insights, I decompiled the code of the attacker’s contract using the Dedaub online tool. Analyzing the decompiled code revealed that the funds from the malicious contract were transferred to the address 0xcdc0f019f0ec0a903ca689e2bced3996efc53939 via the deposit() function (refer to Figure 9).
The assets that were transferred were those that became accessible due to the carelessness of users who granted permission to the attacker’s contract to manage their funds in MetaMask. This information cannot be discerned in transaction explorers like the Ethereum Blockchain Explorer when examining the address of a malicious contract. Browsers only reveal the withdrawal of funds from the contract, which the attacker was able to accomplish solely because of the granted permission to utilize the funds.
The attacker successfully withdrew a majority of the funds (201 ETH) from wallet 0xcdc0f019f0ec0a903ca689e2bced3996efc53939 on the Ethereum blockchain on 06/24/2022, transferring them to Tornado Cash in three separate transactions. The most recent transaction, dated 06/27/2022, moved 17.39 ETH through the Multichain bridge to the same wallet address, but this time on the Binance Smart Chain blockchain. Subsequently, the funds from the Binance Smart Chain wallet were again transferred to Tornado Cash before the attacker ceased using the wallets.
In relation to the attack on Allbridge on 06/23/2022, a contract was created on the Polygon blockchain (0xbbbd2139ed16a4075df7c303d8d69e6413f3e884), which is not an exact byte-by-byte match with the aforementioned contracts. However, during decompilation, the only difference observed was the presence of one unused variable (refer to Fig. 11).
However, due to this minor change, this contract does not appear in the list of 15 previously found.
Disadvantages of Public Security Methods
I could only find one solution to the problem. Alexey Smirnov, the CEO of deBridge Finance, provided developers with two bash scripts to monitor changes in frontend code and DNS records. Due to the challenges faced in accessing Twitter in the Russian Federation, I will now publish the code of the scripts:
#!/bin/bash cd /tmp wget -r -k -l 7 -p -E -nc -nv https://$1/ 1>&2 2>/dev/null || true find $1 -type f | grep -v robots.txt | xargs md5sum | md5sum | cut -d -f1
#!/bin/bash date >> /tmp/dns_$1.log host $1 | grep address | awk ‘{print $NF}’ | sort | uniq | xargs echo | tee -a /tmp/dns_$1.log > /tmp/dns_new_$1 if [ $? -eq 0 ] then cp /tmp/dns_new_$1 /tmp/dns_$1 else echo ‘Resolve ERROR’ >> /tmp/dns_$1.log fi cat /tmp/dns_$1
This configuration may not be effective against a BGP hijacking attack as it does not modify DNS records, and the frontend monitoring script does not consider the default IPv6 priority over IPv4 in many operating systems. If the frontend is hosted on a targeted domain with both IPv6 and IPv4 addresses, and the server running the script also has both IPv6 and IPv4 addresses, the verification will always be conducted against the IPv6 address (if it is accessible). However, during a BGP hijacking attack, the routing could be manipulated specifically for IPv4 addresses while leaving IPv6 unaffected.
Using only the frontend change monitoring script may lead to overlooking both BGP hijacking and DNS hijacking. There are two main reasons for this. Firstly, if only the DNS records for IPv4 are altered in a DNS hijacking scenario, the priority of IPv6 over IPv4 can cause the monitoring script to miss the changes (refer to Figure 12). Secondly, without the –no-dns-cache option, the script may access cached DNS records that have become stale, potentially leading to inaccurate monitoring results.
How to Enhance Protection Effectiveness?
Monitor new certificate releases, changes to DNS records, and integrity of frontend files regarding contract addresses. It’s important to consider the priority of IPv6 over IPv4. This can be achieved by using separate scripts—one for IPv6 and another for IPv4. For instance, for wget, you can utilize the –inet4-only and –inet6-only options.
Choose a DNS registrar that supports the CAA (Certification Authority Authorization) record. If the SSL certificate provider offers this capability, make use of the account CAA record as specified in RFC6844. This measure prevents unauthorized certificate issuance unless the attacker can modify the CAA record. It provides protection against BGP hijacking attacks.
Opt for a DNS registrar that offers advanced domain security features. Some registrars have their own Security Operations Center (SOC) commands that actively monitor various attacks, including attempts of BGP hijacking and unauthorized DNS record modifications. When any suspicious activity is detected, the registrar initiates communication with the domain owner through multiple channels.
Take immediate action to revoke any unauthorized certificates. Delaying the revocation process provides the attacker with additional time to carry out their malicious activities. It’s important to note that DNS records are cached in browsers, routers (including home routers), and DNS servers. Revocation is crucial to prevent further exploitation. For example, the caching duration for the itnan.ru domain, as observed from the Yandex DNS server (77.88.8.8) using the dig utility, is approximately 20 hours (refer to Figure 13).
Furthermore, even when using short TTL (Time-to-Live) values for DNS cache entry update times, significant delays can occur in propagating DNS record updates, sometimes taking several days.
Mitigating Risks of DNS Hijacking Attacks: Implications, Impersonation, and Countermeasures
Let’s consider a scenario where domain owners fall victim to a DNS hijacking attack, wherein the attackers issue a certificate for the targeted domain. At some point, the domain owners become aware of the attack and restore the DNS records, but fail to revoke the certificate issued by the attacker. Consequently, some users may be directed to the attacker’s site for a few hours or even several days.
The browser will not alert them about the presence of an untrusted certificate. Merely clearing the local DNS cache on the user’s operating system will not resolve this issue. Even if the initial TTL value for the DNS entry was set to a few minutes, it is still imperative to revoke the certificate. Moreover, attackers who gain control over the DNS records control panel can manipulate and increase the TTL value parameter.
There are attacks that can spoof the DNS system, such as DNS cache poisoning. Periodically, there are reports of vulnerabilities of this nature in network equipment. For instance, in 2019, a similar vulnerability was discovered in the RouterOS 6.45.6 operating system, commonly used in MikroTik routers. Additionally, a man-in-the-middle attack is possible against users who do not utilize DNSSEC.
To verify the issuance of new certificates, you can follow these steps: First, obtain the current hash sum of the certificate records for the specific domain (replace “DOMAIN” with your actual domain name). It is advisable to use the JSON format to minimize the amount of data received.
wget -O DOMAIN -nv “https://crt.sh/?CN=DOMAIN&output=json” 1>&2 2>/dev/null | md5sum DOMAIN >DOMAIN.md5
Next, you need to compare the values u200bu200bwith the standard:
wget -O DOMAIN -nv “https://crt.sh/?CN=DOMAIN&output=json” 1>&2 2>/dev/null | md5sum DOMAIN|md5sum -c DOMAIN.md5
This approach has its nuances. Firstly, there may be instances when the crt.sh service is temporarily unavailable. Secondly, it has been observed that when a new certificate is issued, two records appear on the website. Initially, a precertificate entry is generated, and only after some time, a new entry in the form of a leaf certificate is added. Therefore, it may be more reliable to independently monitor the records in CT Logs.
Ensuring Server Software Security: Importance of Timely Updates and Certificate Revocation
It is crucial to keep server software up to date to mitigate the risks of unauthorized modifications to front-end data or unauthorized access to HTTPS certificates. It is also important to revoke certificates promptly when there are potential threats to their compromise. This necessitates the involvement of specialists who possess the necessary skills to assess the server software being used and analyze potential exploitation vulnerabilities.
For instance, vulnerabilities like CVE-2014-0160 and CVE-2019-9621 can lead to certificate compromise, as the former allows access to process memory and the latter provides access to server files. While updating the software to address these vulnerabilities is important, it does not eliminate the possibility of certificate leakage. If an attack does not require certificate reissuance due to compromise, the task for the attacker becomes easier.
Additionally, methods for monitoring the issuance of new certificates may overlook such an attack. It is crucial for specialists to revoke certificates in such cases without fail. For the same reason, it is advisable to set a relatively short validity period for certificates, typically a few months.
Source: habr.com
