vi

vi
Quay lại tất cả tin tức

Ontology’s EVM TestNet Officially Deployed, Now Opening EVM-Compatible Public Beta to Developers


Ontology has now officially deployed its EVM TestNet and is opening its EVM-compatible public beta for developers! Developers can use the Ontology Bridge to convert Ontology’s native OEP-4 tokens to ORC-20 tokens and add them to their MetaMask wallets and then deploy dApps. The Ontology Blockchain Explorer, Developer Documentation Center and Ontology EVM-supported Web3 API is also being upgraded, incentivizing Ethereum developers to deploy dApps on TestNet.


In collaboration with code auditor, SlowMist, Ontology is setting up a bug bounty where developers can win thousands of dollars in rewards! The Ontology Security Vulnerabilities and Threat Intelligence Bounty Programme is designed to help improve the security and performance of the Ontology network and support its EVM development, with a top prize of $12,000 in ONG rewards.  


Below, you can find a breakdown of the different types of vulnerabilities and their corresponding rewards, along with descriptions of how we aim to address vulnerabilities based on their severity.


Scope of Business    


1. Ontology Blockchain (GitHub)


General Security


  • General design or implementation flaws


Network Security


  • Message serialization/deserialization security
  • Network connection management security
  • Message buffer management security


Protocol Security

  

Conceptual or implementation security issues in the following Ontology protocols:


  • VBFT Consensus Protocol Security
  • Block Propagation Protocol Security
  • Transaction Propagation Protocol Security
  • P2P Communication Protocol Security


Cryptographic Primitives Security


Incorrect implementation or usage of the following cryptographic algorithms:


  • ECDSA
  • EdDSA
  • ECIES
  • SM2
  • SM3
  • SM4
  • AES
  • VRS


Smart Contract & Virtual Machine Security


  • NeoVM implementation flaws
  • WasmVM implementation flaws
  • EVM implementation flaws
  • Transaction execution
  • Ledger access control
  • Transaction result notification security


Native Smart Contract Security


  • ONT Native contract security
  • ONG Native contract security
  • ONT ID Native contract security
  • Governance Native contract security
  • Authorization manager Native contract security
  • Cross-chain Native contract security


2. Ontology Wallets


Processing Flow


Reporting Stage                                


The reporter visits the “SlowMist Zone” website and goes to “Submit Bug Bounty” page to submit a vulnerability report (Status: Under Review).


Processing Stage

  1. Within 1 working day, the SlowMist Security Team will confirm the vulnerability report from the “SlowMist Zone”, follow up, evaluate the problem, and send the threat intelligence back to the Ontology contact person (Status: Under Review).
  2. Within 3–10 working days, the Ontology technical team will address the bug, draw conclusions and record points (Status: Confirmed/Ignored). They will communicate with the reporter if necessary, and ask the reporter for assistance.

Fixing Stage

  1. The Ontology team shall fix the security bugs identified by the vulnerability report and provide updates online (Status: Fixed). The fixing time frame depends on the bug’s severity and the repair difficulty. Generally speaking, it is within 24 hours for critical and high risk bugs, within 3 working days for medium risk bugs, and within 7 working days for low risk bugs. The app security issue is limited by the version release, and the repairing timeframe is determined on a case-by-case basis.
  2. The reporter will review whether the security bug has been fixed (Status: Reviewed/Reviewed With Objection).
  3. After the reporter confirms that the security bug is fixed, the Ontology technical team will inform the SlowMist Security Team of the conclusion and the vulnerability score. They will issue rewards to the SlowMist Security Team (Status: Completed).

Vulnerability Level and Reward Standards



Note: The final award depends on the severity and true impact of the vulnerability. The values in the table are the highest rewards for each level. Critical vulnerabilities reward will be in the form of ONG at the price of ONG/USDT the day before the issue.


SLOWMIST is an Ethereum ERC-20 token, the ecosystem incentive token for the SlowMist Zone.

Critical Vulnerabilities


A critical vulnerability refers to a vulnerability that occurs in the core business system (the core control system, field control, business distribution system, fortress machine and other control systems that can manage a large number of systems). It can cause a severe impact, gain business system control access (depending on the situation), gain core system management staff access, and even control the core system.


Critical vulnerabilities include but are not limited to:


  • Smart contract overflows, conditional competition loopholes, etc. will cause serious data problems on the MainNet
  • Arbitrary command execution on node host
  • Destruction of data consistency across the network
  • Transaction, block or consensus message signature forgery, replay or valid data tampering
  • Access control flaws
  • Private key disclosure or unauthorized call to signed API
  • Large amounts of additional issuance or overspending of assets, large amounts of theft or excessive spending
  • The entire network crashes, no response or consensus is stalled, and legal transactions cannot be executed

High Risk Vulnerabilities


High risk vulnerabilities include but are not limited to:


  • Involving the unauthorized operation of the token, bypassing the payment logic (required to be successfully used)
  • The permission control defects in the smart contract
  • Node host crashes or becomes unresponsive
  • Node program crashes or becomes unresponsive, unable to receive, process, and forward legal transactions or blocks
  • Large losses or freezing of other people’s assets
  • Leakage of sensitive information, such as unauthorized access to private data, decipherable cipher text, etc.

Medium Risk Vulnerabilities


Medium risk vulnerabilities include but are not limited to:


  • The leakage of locally-stored sensitive authentication key information, which needs to be able to be used effectively
  • Invalid transaction, block or consensus message data tampering
  • Small additional issuance or overspending of assets, theft or excessive spending
  • Small loss or freezing of other people’s assets
  • RPC service crashes or becomes unresponsive

Low Risk Vulnerabilities


Low risk vulnerabilities include but are not limited to:


  • Local denial-of-service vulnerabilities. It includes but is not limited to the client local denial-of-service (parsing file formats, crashes generated by network protocols), problems that are caused by Android component permission exposure, general application access, etc.
  • Node response has dropped significantly
  • Significantly reduce the difficulty of other attacks
  • Other vulnerabilities that are less harmful and cannot be proven to be harmful (such as CORS vulnerability that cannot access sensitive information)

Vulnerabilities That Are Not Accepted (even if such a vulnerability is submitted, it will be ignored)


  • SPF mail forgery vulnerability
  • Interface brute force blasting of registered username vulnerabilities
  • Self-XSS
  • CSRF issues for non-sensitive operations
  • A separate issue about Android app android:allowBackup=”true” , and the service is denied locally, etc. (unless in-depth use)
  • Some problems such as slow requests caused by changing the size of the image etc.
  • Version leak issues such as Nginx/Tomcat, etc.
  • Some functional bugs that do not pose a security risk issue

Prohibited Behaviors


  • It is forbidden to conduct social engineering and phishing
  • It is forbidden to leak the details of the vulnerability
  • Vulnerability tests are limited to PoC (proof of concept), and destructive tests are strictly prohibited. If harms are caused inadvertently during testing, they should be reported immediately. Meanwhile, sensitive operations performed in a test, such as deletion, modification, and other operations, are required to be explained in the report
  • It is forbidden to use a scanner for large-scale scanning. If the business system or network becomes unavailable, it will be handled according to relevant laws
  • Those who test the vulnerability should try to avoid modifying the page directly, continuing popping up the message box (dnslog is recommended for xss verification), stealing cookies, and obtaining aggressive payload such as the user information (for blind xss testing, please use dnslog). If you accidentally used a more aggressive payload, please delete it immediately. Otherwise, we have the right to pursue related legal action


Special thanks to the xianzhi and cnvd vulnerability classification criteria referred to here.