Written by: Haotian
In fact, before the legal responsibilities are clearly defined, there will be voices from different angles questioning the professional ethics of "white hats" and the vulnerability disclosure mechanism and vulnerability bounty mechanism of centralized exchanges. However, this issue is not "new" at all in the security circle:
1) A standardized vulnerability disclosure mechanism is actually a process in which the security company and the client coordinate on issues such as vulnerability discovery, vulnerability repair, and vulnerability bounty. After that, everyone is happy to see the vulnerability being repaired and disclosed. It is obvious that there was a problem in the coordination process between Certik and Kraken:
1. Discover vulnerabilities and report them to customers in a timely manner, describing the type of vulnerability, the degree of harm, and how to reproduce it. If a "white hat" discovers a vulnerability but does not disclose it, it directly becomes a hacker. Since they choose to disclose it to customers, it means that their subjective intention is not to attack.
2. Confirm the vulnerability and assess the risk. The security company and the customer confirm the existence of the vulnerability, as well as the severity of the vulnerability, the scope of impact, and the design of the repair plan. This process will determine how to divide the work and collaborate on vulnerability repair, how to formulate the vulnerability bounty, etc. Otherwise, it is easy for the customer to refuse to pay the corresponding vulnerability bounty on the grounds that the vulnerability is a "reported" vulnerability, which may make the white hat work in vain.
3. Develop a repair plan and retest to ensure that the vulnerability is successfully fixed. This process is generally agreed upon by the customer development team and the security company's technical staff, and the code repair is implemented in a unified manner. Generally, if this step can be advanced to this step, it means that both parties have reached an agreement on the "vulnerability hazard level and the vulnerability bounty to be paid". Therefore, the common goal of both parties is to repair the vulnerability in a timely manner, and then issue a press release to publicize and disclose the vulnerability, making public the entire process of discovering the vulnerability and jointly repairing it.
2) Whether Certik is a security company with a good reputation or bad reputation is difficult to judge simply from a moral point of view, so I will not comment on it here. I just want to say that if a security company is often involved in trouble, it must be because the interests involved are too complicated and not handled properly.
I talked to some friends from security companies and they thought the process might be:
1. Certik did discover and report the vulnerability to Kraken, which means that it was not a "hacker" behavior. However, it has become a major scandal in the security industry, and the causes and consequences behind it need to be clarified.
2. The account marked as Certik staff KYC only had 4 USD added, which means that the vulnerability test was within reasonable limits at the beginning. After that, no matter what the reason is, the evidence of both parties will prevail. However, it seems that it has indeed exceeded the boundaries of professional ethics.
3. The two parties probably failed to reach an agreement on the bug bounty and the division of labor for bug fixes. It is possible that Kraken Exchange refused to pay the corresponding bounty on the grounds that the bug was reported. Therefore, Certik conducted a larger-scale "test" during the repair period, either out of "personal" revenge or intentional behavior by the company.
There are many possibilities for disputes in this process, but it is essentially a conflict of interest. The vulnerability disclosure of the Kraken centralized exchange is inefficient and opaque, and the degree of intervention of Certik's security vulnerabilities lacks regulations and standards.
Conclusion: The above is only a reasonable speculation, and the specific results will be disclosed in the future. However, the "slow treatment" of the security white hats in submitting bugs and the opaque process of the centralized organization in the vulnerability disclosure and repair process are the key to the "disputes and frictions" between the two parties. This is the focus of everyone's attention.
This is also the fundamental reason why I wrote an article before praising @GoPlusSecurity for building an open, non-negotiable, user-driven modular security layer. There are various possibilities of black boxes in purely centralized security disputes. A decentralized security service solution can play a role in the entire security protection life cycle (especially the uncontrollable factors caused by human factors). Although this road is long and difficult, it is imperative.
In the past few years, security audit services have evolved from a one-by-one business cooperation model. The endorsement scandal that occurred during this process, the Rug scandal after the audit, and the current quarrels between Party A and Party B are all closely related to the information opacity of security services and the complexity of the audit business itself in terms of sensitive information interests. It is hoped that the security industry will be able to further develop more standardized standards, more optimized processes, and more professional services as the problems are exposed.
In any case, the status of some security companies can be replaced, but the sacred image of security guardians must not collapse. At the same time, the contributions of security white hats should also be respected by the market.
