In many ways, Security Operations Center (SOC) analysts and node operators face similar blockchain-related security challenges. The scale of SOC operations brings with it unique security challenges. Reduced telemetry from decentralized infrastructure hinders SOC detection, but additional information available on-chain could drive new ways of detecting security-related events.

The effectiveness of a SOC that is focused on detecting and responding to blockchain, crypto, and DeFi threats might be significantly improved if it took a “fusion” approach that combines various fraud detection methods with the most effective cybersecurity methods, all adapted for blockchains and decentralized networks.

To illustrate the differences, this article examines the scenario in which a corporate SOC monitors and detects threats to assets and solutions deployed on a permissionless, immutable, public blockchain. Other blockchain types, such as Hybrid, Consortium, or Private, that give an organization more control over the blockchain would have more similarities with traditional IT SOCs.

The Role of the SOC

The SOC is responsible for securing an enterprise against attack. This includes operating and monitoring security solutions, investigating potential attacks, and performing incident remediation and response.

Corporate digital transformation efforts have increased the complexity of the environments that SOC teams are responsible for securing. In recent years SOC functions are becoming accountable for securing increasingly heterogeneous, complex environments of on-prem systems, data centers, cloud deployments, Internet of Things (IoT) and other IT and Operational Technology (OT) infrastructure.

Corporate SOCs may face the most significant challenge yet with the adoption of blockchains and decentralized networks, as they are given the responsibility to monitor and mitigate threats to solutions they might have no control over.

SOC Operations for Traditional IT vs Blockchain-Based Decentralized Networks

Growing institutional investment in blockchain technology means that SOC teams will increasingly become responsible for assets and solutions deployed on blockchain-based decentralized networks. However, blockchain environments differ significantly from traditional IT systems, and security solutions designed for conventional IT may not map cleanly to blockchain ecosystems.

Node Telemetry

SOC analysts are accustomed to having access to a great deal of data — and often too much data — regarding the systems under their care. For example, a SOC commonly has access to log files, network traffic (various network flows), other data from their endpoints, contextual information, etc. This information can then be used to identify potential threats to the organization and its systems.

With blockchain-based systems, the amount of data available to SOC analysts depends on their involvement in the blockchain network. A SOC for an organization that operates a full blockchain node would have complete visibility into all operations performed on the blockchain, including those with very limited or no relevance to the company’s addresses and smart contracts.

On the other hand, a company that doesn’t operate a node can be more deliberate about the information it collects and processes. However, this comes at the cost of relying on one or more node operators for accurate telemetry.

In many cases, a SOC might not have access to any node telemetry at all.

Infrastructure Management

Over time, SOC analysts have been slowly relinquishing control over their IT infrastructure stack. With on-prem IT architecture, an organization has complete control over its IT systems and networks. This allows the SOC to appropriately configure security controls and use a wide range of tools to monitor and protect its IT infrastructure.

With the adoption of cloud computing, security teams have given up a certain amount of control over their IT infrastructure stack. Cloud service providers manage, maintain, and secure leased services’ infrastructure. As a result, security teams are more limited in the security solutions they can use to monitor and protect their cloud deployments.

With decentralized networks and public blockchain technology, companies give up even more control over their IT infrastructure. Blockchains are hosted by networks of distributed nodes, which are not under an organization’s control (unless it is a private, internal blockchain network). As a result, SOC teams may have limited visibility into their underlying architecture and be unable to enforce secure configurations for nodes in the blockchain network.

If their business solutions are deployed to or utilize public blockchains, SOC teams have to operate under the assumption that they have zero control over the underlying decentralized infrastructure.

Threat Detection

Threat management is one of the core responsibilities of a SOC team. In a traditional IT environment, SOC analysts are often tasked with triaging and investigating alerts to identify ongoing attacks and threats to the organization. Usually, this results in a mix of threat prevention — blocking attacks before they pose a threat — and threat detection and response.

In a traditional IT environment, a SOC has multiple tools at its disposal for detecting, and stopping, potentially malicious activity at every step of a cyber kill chain – from reconnaissance to maintenance or exfiltration. It gives a SOC multiple opportunities to stop a threat actor before they execute on their objectives.

On the blockchain, threat detection and prevention stakes are much higher.

Due to potentially very limited visibility, a SOC might not be able to observe any useful signals from any steps in a cyber kill chain until the final step – “Actions on Objectives” (in Lockheed Martin Cyber Kill Chain).

Blockchain immutability means that attacks cannot be reversed, so they must be prevented. Or detected and stopped very quickly to limit the losses.

When the visibility is reduced to potentially only the final step in a cyber kill chain, and the reaction time for containment is reduced to potentially minutes, SOC’s Mean Time To Detect (MTTD) and Mean Time To Respond (MTTR) objectives are compressed to a small fraction of what they would be in a traditional IT SOC.

Forensic Operations

In traditional IT, one of the most significant challenges of post-incident digital forensics is collecting complete, trustworthy evidence. Data stored in volatile and mutable memory may be overwritten or modified by an attacker. Additionally, the tools used to collect various types of evidence can cause other evidence to be corrupted or missed entirely.

One advantage of the blockchain for security is that all forensic evidence of on-chain activities is preserved and readily available. All transactions performed on the blockchain are recorded on its immutable digital ledger. This makes it easy for SOC analysts — and anyone else — to conduct an in-depth investigation of a cyberattack. This visibility can be invaluable for tracking the parties behind an attack and, ideally, regaining stolen assets.

However, the same access to evidence doesn’t extend to attacks against the nodes that host the blockchain network. Since these nodes are globally distributed and outside the organization’s control, a company may have very limited or no visibility into attacks targeting the blockchain’s nodes and networks. As a result, eclipse attacks and similar infrastructure-level exploits may be difficult or impossible to investigate.

Incident Response

Incident response and remediation is an integral duty of the corporate SOC or incident response team (IRT). After thoroughly investigating a security incident and collecting any necessary digital evidence, the IRT and SOC are responsible for restoring corporate systems to normal operations and, ideally, preventing a similar attack from occurring again.

For blockchain-based systems, a SOC’s ability to remediate a security incident is limited. The blockchain’s digital ledger is immutable, so it is impossible to reverse an attack after it has occurred. In most cases, incident response boils down to damage control and developing a plan to compensate affected parties for lost assets.

Developing Security Operations Approaches for Corporate Blockchains

SOC teams are responsible for developing and implementing security plans to cover their organization’s IT infrastructure. With expansion into blockchain-based technologies come unique risks and security challenges. Blockchain architecture works very differently from traditional systems, and security incidents are much more difficult to detect or manage after the fact.

As a result, SOC teams must develop security plans tailored to the unique needs and constraints of their blockchain-based systems.

Shift Left Security

Shift left refers to moving security sooner in the development process. A tighter integration of security throughout the software development and deployment processes leads to better security outcomes. With limited options for threat detection and monitoring in production, this becomes even more critical. And a SOC should have a role to play in this.

The SOC model is already changing. In many organizations, it is becoming the function that helps merge development, security and operations teams into a unified model and drive efficiencies by applying its automation skills to this new DevSecOps model. In addition to driving security-related processes such as static application security testing (SAST); dynamic application security testing (DAST); container scans; compliance scans; dependency scans; etc. a blockchain SOC should also integrate Smart Contract audits, penetration tests and other smart contract-specific preventative steps in order to help identify as many vulnerabilities as possible before deployment.

Blockchain Network Layer Detection

Blockchain security based on consensus mechanisms is highly dependent on the security of the underlying blockchain network. Blockchain network nodes must be capable of reliably exchanging ledger state information. Through network layer attacks, e.g., large-scale eclipse attacks, DDoS attacks, Sybil and Erebus attacks, the attacked nodes or subnets could become isolated from the blockchain main network and start generating different ledger copies. An attacker could capture unlawful interests and undermine the stability and security of the entire blockchain system.

For example, in an eclipse attack, an attacker could take over control of a number of IP addresses (through e.g. routing table poisoning). This would allow the attacker to monopolize all connections with the victim blockchain network nodes and isolate them from the master network, which could then allow the attacker to, for example, present a different state of the ledger to the victim.

A blockchain-focused SOC should understand these blockchain-specific network layer attack methods and implement detection rules tuned for features present in specific attack traffic.

“Fusion” Approach

While a blockchain SOC might have significantly reduced telemetry from networks and nodes compared to traditional IT, on-chain data provides a powerful new security-relevant source of information.

By expanding its scope to include signals traditionally belonging to fraud or financial crime monitoring, a SOC could significantly improve its detection correlation effectiveness.  Monitoring on-chain activity and correlating it with off-chain signals and contextual information allows it to detect threats and anomalies in blockchain, DeFi, NFT, governance, bridges and other Web3 systems in real-time. Where exploits require multiple transactions over multiple chains and bridges, as was the case in many of the largest recent attacks, a “fusion” approach offers the opportunity for early detection and mitigation before the exploit is complete.

For example, traditional node and network security monitoring signals could be correlated with blockchain-specific cybersecurity-focused monitoring such as smart/proxy contract upgrades, ownership transfers, admin address changes, calls to administrative smart contract methods; which could be further correlated with fincrime-focused and business signals such as protocol executing out of bounds, transactions with unusually high gas prices, transactions from high-risk addresses, transactions that significantly affect liquidity, etc. Such “fusion” approach could significantly increase detection rates.

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post How Blockchain Security Differs From Traditional Cybersecurity – 4 – Security Operations (SOC) appeared first on Cryptosec.

This article explores how user security differs between traditional IT and blockchain environments.  While identical products and services may be hosted in traditional IT and blockchain environments, the differences between these ecosystems can have significant security implications for their users.

IT vs. Blockchain Security for Users

Traditional IT and the blockchain operate under very different philosophies.  Many traditional IT systems are centralized and try to control every aspect of the user experience.  In contrast, the ethos of distributed ledger technology focuses on decentralization and self-custody.

These different philosophies have resulted in very different infrastructures and ways of doing things.  These differences have significant impacts on the user experience and user security.  Some of the biggest differences between IT and blockchain security for users include the following.

Account Security

Traditionally, access to user accounts has been managed based on passwords.  Ideally, a user will have a unique, strong, and random password for each account, but this is not always true.  As a result, biometrics, multi-factor authentication (MFA), and other techniques have emerged to improve account security.

On the blockchain, control over an account is managed via private keys.  Creating an account requires generating a private key from which a public key and account address can be derived.  Every distributed ledger transaction made using that account must be digitally signed with the appropriate private key.

While a private key is more secure than a password, it is also more difficult for users to remember and manage.  A lost private key is a significant threat for users.  If a key is lost, then access to the account is lost forever without the option to reset it like there is with a password.

Like with passwords, private key security is also a significant risk on the blockchain.  Attackers have developed numerous means for stealing keys, including phishing, malware, and other threats.  Also, the structure of private keys and mnemonic phrases makes them easier for an attacker to search for them in a computer’s memory.

Credential Management

In traditional IT systems, users have two main options for credential management.  One is to use weak credentials that they can easily remember and input into their accounts.  The other is to rely upon password managers, single sign-on, and similar tools that make the use of strong credentials possible and scalable.  In general, many of the leading solutions are well-established and have undergone thorough security audits.

One of the main selling points of blockchain technology is self-custody or the fact that a user has full control over their account and the value that it contains.  However, private keys are random, which makes them difficult to recall.  As a result, many blockchain users rely on various tools — software wallets, hardware wallets, third-party key management services, etc. — to store and manage their private keys.

These key management solutions introduce new risks for blockchain users.  If the solution is compromised, malicious, or goes out of business, then an attacker may perform transactions on the user’s behalf or access to their account may be lost forever.  Also, the security of these various platforms and tools can vary greatly, and users may struggle to determine which ones are legitimate and secure.

Incident Recovery

Security incidents can happen to any organization, and after a breach happens companies take action to remediate the incident.  In traditional IT environments, organizations can often restore systems from backups, apply updates, reset passwords, and take other actions to reverse the effects of a security incident.

On the blockchain, the immutability of the blockchain’s digital ledger makes this more difficult.  Once a security incident occurs, no means exists for reversing it.  Additionally, fully decentralized blockchain platforms lack the ability to freeze transactions to block further exploitation of identified vulnerabilities.

As a result, a hack against a blockchain-based project can have a much larger impact on users than a similar incident for a traditional organization.  Any funds stolen by the attacker are lost forever, and the project may lack the resources necessary to compensate users.  Additionally, the design of the blockchain makes recovery actions such as password resets infeasible as private keys are irrevocably tied to a particular blockchain account.

User Privacy

User privacy and data security have become a growing concern for organizations in recent years.  Data protection laws such as the EU’s General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) have placed strict limits on how companies can collect and use data and laid out requirements on how that data must be protected.

On the blockchain, all actions taken by a user are recorded on a public, immutable digital ledger.  While blockchain accounts are pseudonymous, it is possible to determine the identity of the person behind an account via analysis of blockchain transactions.

As a result, users of blockchain-based platforms have limited privacy unless they actively take actions to protect that privacy, such as the use of single-use accounts and addresses.  On a public blockchain, anyone can determine the balance in a particular account and every action taken by that account to date.

Additionally, blockchain immutability and decentralization mean that this data can never be deleted.  This contributes to the risk that an attacker could collect and correlate multiple pieces of non-sensitive data to derive more sensitive information.  For example, the combination of age, birthday, and zip code is enough to uniquely identify 87.1% of US citizens.  Preserving privacy requires being very careful about what information is posted to public blockchains.

Encryption and Data Privacy

Encryption is one of the most effective means of ensuring data privacy and security.  Modern encryption algorithms are designed to be secure against known attacks and can’t be broken with currently available technology.

However, this will not always be true.  Encryption algorithms commonly used in the past have been broken, and modern algorithms will be breakable in the future.  For example, common public key encryption algorithms such as RSA will be broken as soon as a sufficiently large quantum computer is created.  Even without quantum computers, the length of RSA keys needed for security continues to grow as computers become faster.

Data stored by traditional IT systems can be updated as needed if an encryption algorithm is broken.  However, the same is not true of data stored on the blockchain’s digital ledger.  Blockchain ledgers are immutable and distributed, meaning that data can’t be deleted from them.  As a result, any data stored encrypted on the ledger will most likely become public at some point.  If this includes a user’s personal data, their privacy may be at risk depending on how soon the encryption algorithm is broken.

Corporate Anonymity and Authenticity

In traditional IT environments, the people behind a product or service are publicly known.  For example, the leadership team of Microsoft, Google, Meta, and other companies is well known.  While companies may use shell corporations and similar tools to obfuscate their paper trails, these may not hold up to in-depth investigation.

The design of blockchain environments makes it possible and not uncommon for the team behind a project to be anonymous.  A project team can write and launch code and public marketing materials with most or all of the team anonymous or operating under a pseudonym.

This anonymity makes it much more difficult for a user to determine if a particular project is authentic or a fraud.  While scams are common in traditional IT as well, large rug pulls have become a common occurrence in the crypto space.

Using Blockchain Solutions Securely

Blockchain technology offers users unique solutions and the opportunity for greater ownership and control over their accounts and data.  However, this ownership and the design of the blockchain also create new security challenges.  Blockchain users must also take ownership of their security and intentionally take steps to protect it, such as the use of hardware wallets to protect high-value blockchain accounts and performing their own research before investing in a DeFi project.

This article is the third in a four-part series discussing the differences in security between IT and blockchain environments.  If you haven’t already, check out the first two instalments in the series discussing the differences in security for node operators and application developers.  Also, watch for an upcoming article discussing how blockchain security and IT security differ for Security Operations Centers (SOCs).

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post How Blockchain Security Differs From Traditional Cybersecurity – 3 – User Security appeared first on Cryptosec.

This article focuses on the differences between application security (AppSec) for traditional applications and smart contracts.  While the first blockchains, like Bitcoin, were not designed to support smart contracts, their invention dramatically expanded the capabilities of blockchain platforms.  The ability to deploy code on top of the blockchain has been one of the main drivers of blockchain’s widespread adoption and success.

Traditional Development vs. Smart Contract Development

Traditional applications and smart contracts can implement much of the same functionality.  Smart contract platforms are Turing complete, and, on some of them, developers can use the same programming languages as for traditional application development.

However, traditional applications and smart contracts operate in very different environments.  Some of the big differences include the following:

• Infrastructure Stack: Most applications run directly on top of the operating system.  Smart contracts are more like web applications, code that runs within the context of another application.  This design places constraints on the smart contract’s capabilities and the increased complexity creates more opportunities for exploitable vulnerabilities.
• Immutable Ledger: Traditional applications have mutable code and data that are stored on a private server.  Smart contract code and data are stored on an immutable digital ledger that is publicly visible.
• Languages and Ecosystems: Traditional application development is often performed with well-established languages on stable platforms.  Many smart contract platforms use programming languages and virtual machines designed specifically for them that are relatively new.

The same program can be written as a traditional application or a smart contract.  However, the differences between the two programs’ operating environments mean that they face very different security risks and secure coding best practices can vary greatly.

Traditional vs. Blockchain AppSec

Application security (AppSec) is a priority in both IT and blockchain environments. In fact, AppSec is even more vital on the blockchain due to the multiple layers of application code that can exist, including the blockchain software itself and smart contract code that runs on top of blockchain platforms.

However, the challenges of securing applications differ significantly between IT and blockchain environments. Some common AppSec techniques in the traditional IT space include the following.

Technological Maturity

Most of the IT systems and protocols that we rely on today have been around for decades and have undergone extensive security research.  While new vulnerabilities are discovered on a regular basis, many of these are simply new iterations of well-known programming errors.  The fact that the OWASP Top Ten list has changed very little since its initial introduction makes this evident.

Blockchain and smart contract platforms, on the other hand, are much newer.  Bitcoin, the first blockchain, was introduced in 2008, and Ethereum pioneered smart contracts in 2015.  Smart contracts and decentralized finance are reliant on technologies that are less than a decade old, and many Ethereum competitors are much younger.

The relative immaturity of smart contract platforms means that many of the top platforms have received limited security research and entire classes of vulnerabilities may not have been discovered yet.  Additionally, most smart contract platforms are still under development, meaning that new types of vulnerabilities may be introduced over time.  As a result, ensuring that an application is secure is much more difficult in the blockchain space.

Ecosystem Fragmentation and Stability

Application developers write code for a variety of environments, including desktop OSes, mobile devices, and browsers.  However, only a few platforms of each type exist (especially when considering *nix platforms as a single group), and the platforms are relatively stable.  As a result, developers know how various platforms work and best practices for developing secure code for them.

The smart contract ecosystem is much more fragmented and unstable.  While some platforms, such as Ethereum, have developed an early lead and a strong community, technological changes may eventually render them obsolete.  At the same time, new platforms are being developed and are competing for dominance.

The lack of ecosystem stability in smart contract environments makes it more difficult for developers to create secure, stable applications.  Changes to a platform’s design could undermine the security of deployed code, or a smart contract platform could lose the fight for dominance, bringing down the contracts that it hosts with it.  Additionally, the youth and lack of stability in the smart contract ecosystem means that contracts may be written by developers with limited experience with a platform and its secure coding best practices.

Proprietary vs. Public Code

Organizations commonly take extensive measures to keep their application code and intellectual property secret. Applications are commonly closed-source and use obfuscation and legal protections to attempt to deter reverse engineering and attempted exploitation.  By making vulnerabilities more difficult to find, these organizations raise the bar for attackers looking to exploit these vulnerabilities.

Smart contract code is deployed on the blockchain, making the compiled code publicly accessible, and disassemblers are available for some platforms.  Additionally, the source code of many contracts is posted and linked on GitHub

The open-source nature of smart contract code makes it easy for other developers to reuse existing code, which may contain exploitable vulnerabilities.  It also makes it easier for attackers to find vulnerabilities to exploit.  Source code is easier to read and comprehend, and many of the smart contract security tools are designed for static code analysis, which requires source code access.

Operating Environment Privacy

Traditionally, applications run on a server that is under an organization’s control.  Managing access to this server is a core component of a corporate security policy.  By doing so, an organization limits the information available to an attacker, including the code and data used by the application.

Smart contracts run on top of the blockchain, and all of their code and data are recorded in the blockchain’s digital ledger. As a result, all information available to the smart contract is also visible to a potential attacker or malicious contracts.

Writing code that runs in a public environment is very different from writing code for a private server, and secure coding best practices differ for each.  For example, in traditional IT, seeding a cryptographically secure pseudorandom number generator (CSPRNG) with a random value to generate secure random numbers is best practice.  For a smart contract, this is a classic example of a weak randomness vulnerability as the “secret” seed would be publicly visible on the blockchain and anyone could generate the same series of values, breaking the contract’s security.

Access Management

Many of the applications that an organization uses are not designed to be exposed to the public Internet. Firewalls are commonly used to limit access to internal applications by restricting the types of traffic that can cross a network boundary.  By limiting access to their applications, companies make it more difficult for attackers to gain the access and permissions required to exploit any vulnerabilities that may exist.

In contrast, most smart contract platforms are public, permissionless blockchains. Anyone can create an account on the blockchain and interact with any deployed contract.  Additionally, smart contracts can interact with one another, allowing a malicious smart contract to exploit vulnerabilities in other smart contracts.

Without any external access control, smart contracts must implement access management internally.  Smart contract functions must include access controls that restrict access to privileged functionality as an attacker can execute any publicly accessible function.

Reactive vs. Preventative Security

In traditional IT, application security management is often focused on threat detection and response rather than prevention. In many cases, applications and systems can be restored to a secure state after an attack has occurred.  Additionally, vulnerabilities are often handled via updates and patches to code deployed in production.

Blockchain immutability means that smart contract exploits cannot be easily reversed, and deploying updates to code is difficult unless the code is designed to be updatable. Additionally, all security features must be built into smart contract code since no equivalent to a web application firewall (WAF) or intrusion prevention system (IPS) exists for smart contract environments. As a result, smart contract threat management must focus on prevention rather than detection and response.

Security Tool Availability

As mentioned previously, traditional IT applications operate in relatively stable ecosystems, and many of the common vulnerabilities have already been identified.  As a result, numerous solutions exist to help identify vulnerabilities and protect against exploitation.

Smart contract environments’ relative immaturity means that smart contract developers and blockchain security specialists have fewer tools available.  While solutions exist for established platforms such as Ethereum, they still fall short of the available solutions for web application developers.  For developers on newer and less established platforms, vulnerabilities may be totally unknown and solutions non-existent.

Without tools to automate the vulnerability discovery process, securing smart contracts becomes more reliant on individual knowledge and manual effort.  As a result, security audits are even more important in the blockchain space than they are for traditional IT environments.

Regulations and Best Practices

For traditional IT security, regulations, standards, best practices, and guidelines are often readily available.  For example, web application developers can use the OWASP Top Ten List, CWE Top 25, and applicable regulations, such as PCI DSS for sites processing payment card data, as references for common vulnerabilities and security best practices.  While regulatory compliance requirements can be a headache, they are also a valuable resource for ensuring that common vulnerabilities are covered.

Blockchain developers, on the other hand, have much less access to security guides and resources.  While some platforms, such as Ethereum, provide listings of known vulnerabilities, this is not true of all platforms.  Additionally, no universal regulation or standard exists for blockchain and smart contract security.  As a result, it can be more difficult for developers to validate that their code is actually secure and compliant with best practices.

Developing Secure Smart Contracts

Smart contract development is very different from traditional application development.  These contracts operate in a unique environment and face very different security risks.  At the same time, security research and tools have not caught up, making it more difficult to identify and fix vulnerabilities in these contracts.

The high risks associated with smart contract vulnerabilities make secure coding and threat prevention more important than ever.  Adoption of DevSecOps best practices can help smart contract developers to identify and remediate potential security risks in their code before it is deployed to the immutable digital ledger.  Additionally, all smart contracts should undergo security audits before launch to help identify and remediate potentially exploitable vulnerabilities.

This article is the second in a four-part series exploring how security differs between traditional IT and blockchain environments.  Check out the first article in the series here, and keep an eye out for upcoming articles discussing how blockchain security differs for users and Security Operations Centers (SOCs).

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post How Blockchain Security Differs From Traditional Cybersecurity – 2 – Smart Contract Developers appeared first on Cryptosec.

What are Merkle Trees and Proofs?

Proof of Reserves and Proof of Liabilities can use Merkle trees to prove certain facts while keeping data anonymous.  To understand how these schemes work, it is useful to understand Merkle trees first.

A Merkle tree is designed to securely summarize a set of data.  This means that, given the root value of the tree and some internal node values, it is possible to prove that a particular piece of data is included in the tree.  One application of Merkle trees is to prove that a set of transactions are included in a particular block in the digital ledger.

The image above shows a Merkle tree that summarizes the various transactions that are included within a block.  Each internal node within the tree contains the hash of its children.  For example, the node labeled Hash 0 contains the hash of Transaction 0, and the node labeled Hash 0-1 contains the hash of the concatenated values of nodes Hash 0 and Hash 1.

Merkle trees are able to securely summarize data because of hash function collision resistance.  With a secure, cryptographic hash function, it is infeasible to find two different inputs that produce the same hash output.  Since Merkle trees are built of hash functions, it’s infeasible to find two Merkle trees of the same size with the same root value.

This property makes it possible to prove that a particular piece of data exists within a Merkle tree without the need to reveal any of the other values.  For example, it is possible to prove that Transaction 0 is included in the tree above given the values of Hash 1, Hash 2-3, and the root hash via the following process:

1. Calculate Hash 0 as the hash of Transaction 0
2. Calculate Hash 0-1 by concatenating the values of Hash 0 and Hash 1 and hashing the result
3. Calculate the root hash by concatenating the values of Hash 0-1 and Hash 2-3 and hashing the result
4. Validate that the calculated root hash value matches the provided root hash value

By following this process, a user can verify that Transaction 0 was included in the block as long as the provided root hash is correct.  Since root hashes are included in block headers and are protected by blockchain immutability, this is a safe assumption.

For Proof of Reserves and Proof of Liability, another important feature of hash functions is that they are one-way functions.  This means that, given the value of Hash 1, it is impossible to calculate the value of Transaction 1.  This is a useful feature when the set of data being proven is sensitive and shouldn’t be disclosed.

What is Proof of Reserves?

Many of the failed custodial cryptocurrency platforms maintained fractional reserves, meaning that they only retained enough assets to cover a fraction of user deposits.  This is problematic because a bank run on the platform could quickly drain these reserves, leaving users unable to withdraw their deposits.

A Proof of Reserves (PoR) audit is performed by a third-party auditor and provides an anonymized cryptographic proof that a custodian holds adequate reserves to cover deposits and that an individual’s deposit is covered by those reserves.  Proof of Reserves uses a Merkle tree like the one described above to prove the set of user balances deposited in the protocol.

This starts by snapshotting the set of user balances at a particular point in time and then anonymizing that list of balances.  This anonymization can be accomplished by concatenating the balance with a unique identifier known to the exchange and the user.  From this set of anonymized balances, the auditor builds a Merkle tree like the one above.

Once the tree has been generated, the auditor or custodial platform can publish the tree without the associated balances — i.e. publishing only the values labeled as Hash X in the tree above.  With knowledge of their own balance and unique identifier, a user can easily determine that their deposit was correctly recorded in the Proof of Reserves audit.  If many users individually validate that their balance is correct and attest to this, then the Merkle Tree is likely accurate and the platform has revealed all of the balances that it has received to the auditor.

If the auditor knows the complete deposited value and users have validated that this value is correct, the other half of a Proof of Reserves audit is the custodian proving that they have sufficient assets to cover these deposits.  This can be accomplished by digitally signing messages using private keys associated with accounts that hold sufficient reserves.  Since anyone can verify the value of an account on the blockchain, this is also a publicly verifiable proof.

This approach to a Proof of Reserves scheme relies on an auditor to tabulate and publish the total balance of user deposits.  Alternatively, a Proof of Reserves audit could use a Merkle sum tree, in which each node contains both the hash of its children and the sum of their values.  However, publishing such a tree either leaks information about users’ balances or provides imperfect information.  The use of zero-knowledge proofs for Proof of Reserves audits is an area of research that could address these issues.

What is Proof of Liabilities?

Proof of Reserves is a useful tool for proving that a custodian holds enough assets to cover its deposits; however, it isn’t enough.  A custodian could easily take out a loan to accumulate sufficient assets to pass a PoR audit.  However, the custodian may then lack enough assets to repay both the loan and the user deposits.

A Proof of Liabilities (PoL) is an audit of a custodial platform’s debts and liabilities.  Essentially, this involves a third-party auditor creating a complete list of a custodial platform’s liabilities just like a Proof of Reserves audit tabulates assets and user deposits.  If the total number of assets exceeds the total amount of user deposits and liabilities, then the company is solvent.

It is also common to verify that depositors have precedence over creditors in the event of a bankruptcy declaration.  This would ensure that, if a custodian lacked the resources needed to cover both user deposits and loans, depositors would be paid back before creditors.

What is Proof of Solvency?

Proof of Solvency (PoS) is an all-in-one audit that combines Proof of Reserves and Proof of Solvency audits.  Users of a custodial platform should look for a PoS audit performed by a third-party auditor.  Proof of Reserves is not enough on its own because it lacks visibility into a custodian’s debts, and a third-party audit is essential to prove that all deposits and liabilities were included in the audit.

However, a PoS audit, like any security audit, is only a snapshot.  A company that undergoes an audit one day could invest and lose assets the next.  This is why some platforms are working to provide users with ongoing visibility into the state of their deposits.

Proving the Solvency of Custodial Platforms

Operating at a fractional reserve can be appealing for custodial platforms and is not necessarily a bad thing.  Many traditional financial institutions hold only a fractional reserve, freeing up capital to use for investments that offer the potential for either rewards or losses.  However, these institutions may also be bailed out by the government if something goes wrong.

Cryptocurrency custodians likely lack the same guarantees, so users should know whether or not their assets are secure and whether the platform holds full reserves.  A Proof of Solvency audit can provide valuable information for users’ risk calculations.

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post Proof of Reserves vs. Proof of Liability vs. Proof of Solvency appeared first on Cryptosec.

As blockchain increasingly underpins major systems, blockchain security becomes increasingly vital.  Financial systems built on the blockchain can suffer significant losses due to exploited blockchain security vulnerabilities.  The use of blockchain for supply chain tracking and audit logging relies on the blockchain being immutable.

However, the widespread adoption of blockchain technology is relatively recent, and blockchain security has not always kept up with the technology.  In many cases, traditional IT security best practices do not work for the blockchain security, leaving the potential for security gaps and additional breaches.

This article is the first in a four-part series exploring how blockchain security differs from IT security or “traditional” cybersecurity.  In this article, we explore the differences for node operators, followed by smart contract developers and the blockchain’s users.

The Transition from IT to Blockchain Security

Blockchains such as Bitcoin, Ethereum, and others are built on top of traditional IT systems. A blockchain node is a computer that processes transactions, builds and validates blocks, and stores a copy of the blockchain in memory. The blockchain’s peer-to-peer network operates on top of a corporate network or the public Internet.

Since blockchain technology runs on top of traditional IT systems, many traditional IT security risks and best practices apply for blockchain security. Some of the overlaps between IT and blockchain security include the following:

• Node Security: The blockchain runs on nodes, which are traditional computers. Malware, data exfiltration, Denial of Service (DoS) attacks, and other threats to traditional IT computer systems also apply to blockchain nodes.
• Network Security: The blockchain’s peer-to-peer network runs over traditional IT networks. Distributed DoS (DDoS) attacks against blockchain nodes, border gateway protocol (BGP) hijacking, and other network-level threats can impact the performance and security of a blockchain-based system.
• Application Security: Blockchain systems are implemented as software that runs on a distributed network of blockchain nodes. This blockchain software may contain exploitable vulnerabilities or be vulnerable to DoS attacks that restrict access to CPU, memory, or network connections.
• Web Security: Many DeFi projects have their backends hosted as smart contracts on the blockchain but interact with users via traditional websites. Cross-site scripting (XSS), injection, and other web security threats are common attack vectors for these Web2 frontends.

Blockchain’s reliance on traditional IT systems means that many IT security threats and best practices still apply. If the computers, networks, and websites that make blockchain-based projects operate are attacked, this impacts the blockchain security as well.

However, the blockchain infrastructure stack does not end at the application level. Blockchain software creates a new ecosystem on top of IT nodes and networks that includes:

• Consensus algorithms
• Smart contract platforms
• Layer 2 protocols
• Cross-chain bridges

Traditional IT security controls and best practices only go so far toward securing blockchain platforms. Blockchain accounts, smart contracts, and applications (DeFi, NFTs, etc.) need blockchain security controls and best practices designed for them as well.

Blockchain Security vs. IT Security

Blockchain ecosystems and traditional IT environments are very different. As a result, many of the security challenges and best practices differ significantly between IT Security and Blockchain Security. Here are some of the main ways in which blockchain security and IT security diverge for node operators.

Perimeter Security

Historically, IT security has primarily been focused on perimeter security. Based on the assumption that most threats originate from outside of the network, organizations deploy security solutions such as firewalls, intrusion prevention systems (IPS), and other tools at the boundary of the corporate network. By blocking potential threats at the network perimeter, they reduce the probability and costs of a security incident.

While the perimeter is dissolving in corporate IT with the growth of the cloud, it never existed in blockchain technology in the first place. Most blockchains are public blockchains that anyone can join and participate in. Transaction processing and storage are distributed, and anyone can operate a blockchain node. As a result, many of the traditional IT security solutions and controls used to protect the corporate network perimeter do not apply in the blockchain space.

Vulnerability and Patch Management

All software can have bugs, and some of these bugs are exploitable vulnerabilities.  The blockchain implements multiple different layers of software (the blockchain software, smart contracts, cross-chain bridges, etc.), creating multiple opportunities for vulnerabilities.

In traditional IT, vulnerability management processes are often centralized and well-defined.  After a vulnerability has been reported to a software manufacturer, the company develops and releases a patch for the issue.  While some patches may be applied manually, other updates are automatically pushed to the manufacturer’s software.

In the blockchain space, node operators can run any software that does its job and complies with the current version of the blockchain protocol.  As a result, blockchain networks can be composed of multiple blockchain software with operators running varying versions of each.

The heterogeneity and decentralization of blockchain networks make vulnerability and patch management more complex than for traditional IT systems.  The responsibility lies with node operators to identify if a patch is needed and available, and no central authority has the ability to compel operators to patch their systems.  As a result, unless an update includes a hard fork that breaks backward compatibility, nodes may continue to run versions of the blockchain software that place themselves and the health of the blockchain network at risk.

Identity Management

Identity and access management (IAM) is a complex process in traditional IT systems. Some of the main challenges of IAM in traditional IT include the following:

• Verifying User Identities: User authentication is essential to effective access control. Many organizations are turning to multi-factor authentication (MFA) and password authentication to ensure that users are who they claim to be.
• Managing Access: After the identity of an employee, customer, or other user is validated, they are granted limited access based on their role. Implementing effective access management is the goal of the zero-trust security movement.
• Digital Signature Validation: Digital signatures are commonly used to validate the integrity and authenticity of data and to authenticate users. Companies commonly implement public key infrastructure (PKI) to create, distribute, and validate digital certificates to support the use of digital signatures.

In the blockchain space, identity and access management operates very differently from traditional IT. Some of the main differences include the following:

• User Identity Verification: Most public blockchains are designed to provide anonymity to users. Instead, identity management is based on blockchain accounts. If someone has access to the private key associated with a blockchain account, they can generate digital signatures and transactions on its behalf.
• Access Management: Most public blockchains are permissionless, allowing anyone to participate in the blockchain, creating transactions and operating nodes. Access management is primarily performed at the smart contract level with these applications limiting access to privileged functionality. Private blockchains may be either permissionless or permissioned, allowing an organization to implement traditional security controls.
• Digital Signature Management: In traditional IT, validating the authenticity of a public key is one of the largest challenges of digital signature management and PKI. On the blockchain, blockchain addresses are derived from public keys, making it easy to determine if a digital signature is valid for a particular blockchain account.

Traditional IAM solutions may be necessary for managing the nodes that host a private blockchain. However, for most public blockchains, identity is managed at the blockchain account level, and access controls must be implemented in the blockchain software or smart contract code itself.

Data Security

Data security is a primary concern for traditional IT security. Companies have a responsibility to protect sensitive customer data from unauthorized access and exposure, especially if it is protected by data privacy laws. Additionally, companies have intellectual property and other internal data that must be kept secret to protect competitive advantage.

On most blockchains, all data is public. Transactions added to the distributed ledger are broadcast to all blockchain nodes, making it impossible to delete or redact data after the fact. The contents of the blockchain’s distributed ledger are publicly visible and searchable on multiple block explorers.

Data security on the blockchain boils down to not posting sensitive data on the blockchain. Unless an organization is using a private, permissioned blockchain, anything added to the digital ledger should be considered publicly visible. Data classification and blockchain security controls must be performed before data is included in a transaction and posted to the ledger.

Monitoring and Visibility

Security visibility and monitoring are essential to an effective threat management program. Security personnel can’t manage or respond to vulnerabilities and threats that they do not use exist.

In traditional IT environments, security personnel often struggle to maintain effective visibility. They are responsible for monitoring and managing numerous, diverse environments and security solutions that are often not designed to work together. Security information and event management (SIEM) solutions can help with this, but they can be difficult to configure and manage.

Visibility is one of the few areas where blockchain environments may be easier to manage than traditional IT ones. On the blockchain, everything is publicly visible, and transactions stored on the ledger — which constitutes the audit log of all actions performed on the blockchain — are often searchable on block explorers. Blockchain data can also be integrated into SIEM solutions to converge visibility across traditional IT and blockchain environments.

However, blockchain nodes also often send out less telemetry than traditional IT solutions.  As a result, the data that is available to a node operator may be insufficient to diagnose an issue or determine if an attack has taken place.

Designing Blockchain Security

Blockchain environments differ significantly from traditional IT systems. While they are dependent on the functionality of computers and networks, they built a complex ecosystem on top of them.

Within these blockchain environments, traditional IT security tools and best practices do not always apply. This article focused on how the blockchain security differs from that of traditional IT systems.  Keep an eye out for the other articles in this blockchain security series, which will explore the security differences for smart contract developers and blockchain users.

Cryptosec is a leading provider of blockchain security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post How Blockchain Security Differs From Traditional Cybersecurity – 1 – Node Operators appeared first on Cryptosec.

It wasn’t easy digging through the entire history of cybercrime involving cryptocurrencies, but we wanted to get to the bottom of which crypto hacks were the biggest in terms of total value of the stolen digital assets at the time of the incident. Two of the entries occurred while we were conducting our research; that’s how we know this will be the most accurate and up-to-date list of the top 12 hacking incidents in crypto’s history.

Crypto Hack 1. Poly Network: $611M

At $611M, the Poly Network exploit of August 10, 2021 ranks as the largest crypto hack to date in terms of mark-to-market value. Using a series of data manipulation techniques in the high-level code of the Ethereum smart contract, the attacker was able to steal around $274M in crypto assets from the Poly network’s Ethereum wallet, around $253M from the BNB Chain wallet, and another roughly $85M from the Polygon wallet. All the stolen funds were returned, but the identity of the hacker is still unknown. Read an in-depth analysis of the Poly Network Hack.

Crypto Hack 2. Binance Bridge: $556M

The largest crypto exchange in the world today by market volume suffered the second largest crypto hack incident in the history of crypto on October 6, 2022.  On that day, an attacker used the BSC Token Hub smart contract in a way that allowed them to print 2M BNB tokens (the native token on the BNB Smart Chain), valued around $566M at the time. Learn why the Binance Bridge hack will change the way people view web3.

Crypto Hack 3. Ronin Bridge: $551M

The Ronin chain was built for Sky Mavis’ play-to-earn blockchain game, Axie Infinity. On March 23, 2022, a 51% attack against 5 of Ronin’s 9 validators led to the theft of 173,600 ETH and 25.5M USDC from the Ronin bridge, valued around $551M at the time. It’s widely believed that state-sponsored North Korean APT (advanced persistent threat) cybercrime organization Lazarus Group was behind the attack. Continue reading about the Ronin Bride Hack.

Crypto Hack 4. CoinCheck Exchange: $534M

The largest in history at the time it occurred on January 25, 2018, the crypto hack of Tokyo-based exchange CoinCheck ultimately cost the company $534M worth of their native exchange token, NEM. While the funds were never recovered, CoinCheck received praise from the community for using their own capital to return 90% of the funds to affected users. Read the full story.

Crypto Hack 5. MtGox Exchange: $473M

The first major crypto hack in crypto exchange history, MtGox was never able to recover from the 850,000 BTC lost via multiple mishandling of funds and thefts that went undetected for years, despite finding 200,000 BTC in an old wallet shortly after reporting their insolvency. Due to the lack of clarity and transparency, along with the long timeframes that the attacks occurred within, it’s impossible to know exactly how much the total value in USD was at the time of each incident, but at the time of their bankruptcy filing on February 28, 2014, 850,000 BTC was worth $473M. Read the full breakdown and timeline.

Crypto Hack 6. Wormhole Bridge: $320M

The incident that led to the draining of the Wormhole Bridge occurred on February 2, 2022. The attacker used advanced techniques to manipulate on-chain messages and transactions into allowing themselves to mint 120,000 wETH (Wrapped Ether) valued around $320M at the time. The stolen crypto assets remain in the wallets they were initially transferred to after the 120k wETH was exchanged for various other tokens. Find out who replaced them to save the Solana ecosystem.

Crypto Hack 7. KuCoin Exchange: $285M

The $285M hack of Singapore-based crypto exchange KuCoin occurred on September 25, 2020. More than 150 different cryptocurrencies made up the loot, which was stolen by an attacker who had gotten access to their hot wallets via leaked private keys. In the end, $222M (78%) was recovered through cooperation with exchange and project partners, $17.45M (6%) was recovered by law enforcement and security institutions using blockchain forensics and global investigations, and the remaining 16% ($45.55M) was covered by KuCoin and their insurance fund. Find out how they were able to track down and recover the stolen digital assets.

Crypto Hack 8. BitMart Exchange: $200M

Also the result of leaked private keys, this time for two different hot wallets, the December 4, 2021 crypto hack of the BitMart exchange lost the company around $200M. A long list of altcoins, including SAFEMOON, BabyDoge, SHIB, SAITAMA, ELON, CRO, GALA and many more, valued around $200M at the time, were involved in the attack. Ultimately BitMart was able to restore functionality to their exchange and resume operations, including user withdrawals, but some controversy still exists around what happened to some of the investors holding SAFEMOON. Learn more about the controversy and the timeline of the attack.

Crypto Hack 9. Nomad Bridge: $190M

The Nomad Bridge crypto hack is a story of exploitable smart contracts, a $190 million liquidity pool, and simple human nature. One attacker and hundreds of copycats looted the Nomad bridge; few did the right thing in the end. However, some did ultimately return much of the stolen crypto and received a whitehat bounty for their good deed. Read the full story behind the Nomad Bridge Hack of August, 2022.

Crypto Hack 10. Beanstalk Farms: $182M

On April 16, 2022, a $1B flash loan from the Aave protocol allowed an attacker to exploit the Beanstalk Farms liquidity ecosystem to ultimately drain $182M from their pools. The attack involved taking a supermajority of the governance tokens used in the Beanstalk DAO to manage the ecosystem, which was then used to execute malicious transactions to drain all the pools. Learn the full story about where the stolen cryptocurrency ended up.

Crypto Hack 11. BitGrail Exchange: $170M

Around $170M worth of cryptocurrency was allegedly stolen from an obscure Italian crypto exchange called BitGrail sometime in 2018; it’s still unclear exactly how or by whom. This story involves a public beef between the BitGrail exchange owner/operator and the dev team of NANO, and it ends with the exchange owner facing charges and having his assets seized to pay off what he could to users of his platform. Read the full wild and mysterious story.

Crypto Hack 12. Wintermute AMM: $160M

Wintermute is an automated market maker (AMM) that was drained for $160M worth of liquidity in Wrapped Ethere, Wrapped Bitcoin, and a handful of stablecoins. The attack occurred on September 20, 2022, but the exploit that was used to steal the funds was identified by the 1inch network 5 days before it occurred. While the stolen digital assets have yet to be recovered, Wintermute remained solvent through the incident and has continued to operate without any serious pause in their protocol, so no users lost any funds. Read the full story here and learn about AMMs.

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post The 12 Biggest DeFi and Crypto Hacks in the History of Crypto appeared first on Cryptosec.

In open source communities such as the blockchain and crypto community, code reuse is even more strongly encouraged.  Open-source code released with permissive licenses is intended to be reused in other projects.

However, this can also create security risks.  Smart contracts and other software that reuses existing, open-source code can inherit vulnerabilities from these dependencies or introduce new ones.  These are the four most significant supply chain security risks for blockchain smart contracts.

1. Reuse of Insecure Smart Contract Code

Few smart contracts deployed on any blockchain are developed entirely from scratch.  Even projects as simple as defining a new ERC-20 token commonly depend on templates or reuse existing code.  This makes deploying a new token as simple as changing a few parameters within the sample code and deploying the contract to the blockchain.

However, not all of the publicly available smart contract sample code is high-quality or secure.  Open source code — including the code of smart contracts currently active on a blockchain — may contain fundamental vulnerabilities such as integer overflows, reentrancy, or price oracle manipulation.

Smart contracts copying or reusing this vulnerable code inherit these same vulnerabilities.  This dramatically expands the opportunities for an attacker to exploit the vulnerable code as the same exploit can be copy-pasted to target multiple different smart contracts.

Case Study: Synapse and Nerve Bridge

Synapse and Nerve Bridge are two smart contracts hosted on Binance Smart Chain (BSC), which has rebranded as BNB Chain.  Both contracts forked code from another project called Saddle.Finance.

This forked code contained a price calculation error in two functions, named swap and swapUnderlying.  In swap, the value of the LP token included a virtual price, but the same was not true of swapUnderlying.  As a result, the value used by swapUnderlying would always be lower than the one used by swap.

The attacker used a flashloan attack to exploit this vulnerability.  The different price calculations caused significant slippage, allowing the attacker to drain $537,000 from the Nerve project.  An earlier attempt to steal $8 million from Synapse failed due to an error made by the attacker.

2. Insecurely Modifying Secure Code

While some sample smart contract code might be insecure, other examples are of higher quality.  These code samples have been developed in accordance with best practices and have undergone testing and auditing to validate their functionality and security.  For example, OpenZeppelin publishes high-quality sample code for multiple Ethereum token standards.

Copying or reusing these code samples is best practice.  However, these code samples should be reused as-is.  Modifications to the example code can introduce new vulnerabilities.  For example, changing which underlying function is used to perform certain actions — such as using transfer or send instead of call — can leave the function vulnerable to exploitation.

Case Study: Qubit Finance

In January 2022, the cross-chain bridge between Ethereum and BSC/BNB Chain operated by Qubit Finance was exploited for $80 million in tokens.  The attackers took advantage of vulnerabilities introduced with a modified version of a library function published by OpenZeppelin.

Cross-chain bridges allow a user to deposit value into an address on one blockchain and receive an equivalent amount on another chain.  In this case, a vulnerability in the project’s implementation of safeTransferFrom allowed the attacker to extract tokens without depositing anything.

The safeTransferFrom function created by OpenZeppelin is designed to transfer ERC20 tokens from one address to another.  When calling the token contract to transfer the tokens, it uses address.functionCall.  If there is no smart contract code at the address — i.e. it is an externally owned address (EOA) — functionCall will return false.

The Qubit contract used a modified version of safeTransferFrom, which used address.call instead.  This function does not return false when no code exists at the indicated address.

The attacker exploited this vulnerability by using the whitelisted 0x0 address as address.  Combined with other vulnerabilities, this allowed them to make fake deposits that allowed real withdrawals at the other end of the bridge.

3. Failing to Apply Security Updates

Any piece of software can contain errors, and some of these errors are exploitable bugs.  This is especially true in the smart contract space where both smart contracts and the infrastructure that they run on are in a state of constant evolution.  Code that may be considered secure one way may be vulnerable the next when a new attack is discovered or a change to the underlying blockchain violates a core security assumption.

Software developers address these new security issues by pushing out updates to vulnerable code.  Even on the blockchain, it is possible to update code and apply security patches, preventing future exploitation of a vulnerable smart contract.

If a smart contract copies the code of a vulnerable smart contract, updates to the original contract are not automatically applied to the child contract.  The contract’s developers need to track updates to the original code and apply any required security updates to their own codebase.

Often, after one smart contract is attacked or publicizes a patch for a security vulnerability, attackers look for other contracts that are vulnerable to the same exploit.  A failure to apply security updates for copied code leaves a smart contract vulnerable to attack.

Case Study: Fei Protocol/Rari Capital

In April 2022, the Fei Protocol — before its merge with Rari Capital — was the victim of an $80 million hack.  The attacker exploited a reentrancy vulnerability in the protocol’s smart contracts.

These contracts were forked from Compound, a project whose unaudited smart contracts were hacked for $147 million the previous September.  These contracts were known not to follow the check-effect-interaction pattern that protects against reentrancy attacks.

The vulnerable code used call.value when making calls to functions in other contracts.  This Ethereum function makes it possible for the fallback function of the target contract to perform another call.  By calling back into the vulnerable function, a malicious contract could perform a reentrancy attack.

The vulnerability in the Compound code was fixed long before the attack by switching from call.value to transfer, which doesn’t provide enough gas for a reentrancy attack.  However, the Fei Protocol changed the code back to call.value, allowing the attacker to exploit the project for $80 million.

4. Mismatched Security Assumptions

Smart contracts may use code from a variety of different sources.  For example, a project may write some code internally and use third-party code from a few different projects to implement the desired functionality.

Done properly, this code reuse can speed development and improve the security of the problem.  However, it must be done carefully to avoid introducing vulnerabilities.

Different smart contracts and functions may make certain assumptions about their inputs, outputs, and the other functions that they interact with.  If parts of a smart contract’s code make different and incompatible assumptions, this can leave the contract vulnerable to attack.

Case Study: xFORCE

The xFORCE vault contracts were a fork of the xSUSHI contracts.  The project was the victim of a hack in April 2021 in which approximately $367,000 in FORCE tokens were stolen.

The attackers took advantage of a mismatch in how different parts of the xFORCE ecosystem handled errors in ERC20 tokens.  A failed token transfer could either revert — causing the entire transaction to roll back — or return false, requiring testing and error handling in the calling function.

The xFORCE token vault exploited in the attack was an xSUSHI fork that assumed that all failed token transfers would cause reversion, so no error handling was included.  However, one of the tokens used — an Aragon Minime token — returns false upon reversion.

This combination means that if a deposit into the contract fails, the user retains their tokens.  However, the vault contract assumes that the deposit was successful — since no reversion occurred — and transfers xFORCE tokens to the depositor.

The attackers exploited this vulnerability by making deposits that would intentionally fail.  This allowed them to collect xFORCE tokens.  These tokens could then be deposited in exchange for FORCE tokens held by the vault contract.

DevSecOps Best Practices for Smart Contract Supply Chain Security

Many of the supply chain vulnerabilities impacting smart contract security arise from a failure to apply DevSecOps best practices.  Some best practices that can help DeFi projects to secure their supply chains include:

1. Use audited libraries: When possible, use libraries or sample code from a reputable source that has undergone proper testing and auditing.  Reusing high-quality third-party code both reduces the time and cost of development and decreases the probability of an expensive cyberattack.
2. Maintain an SBOM: A software bill of materials (SBOM) lists an application’s library dependencies and the source of any copied code.  This makes it easier to scan for security updates that need to be applied to a smart contract’s code.
3. Perform vulnerability scanning often: Many common smart contract vulnerabilities can be detected using automated tools, such as slither.  Running automated tests throughout the development process enables vulnerabilities to be caught early, minimizing their impact on release timelines and smart contract security.
4. Audit before launch: The value of smart contract security audits is clear from the fact that all but a couple of the top 20 most expensive DeFi hacks were of unaudited projects.  Engage a reputable smart contract security auditor before launching any code (including updates) to the blockchain.

This article is the second in a series discussing how to improve smart contract security.  Check out the first article in the series and learn more about the importance of DevSecOps for smart contract security.

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post The Top 4 Supply Chain Security Risks of Blockchain Smart Contracts appeared first on Cryptosec.

However, this approach doesn’t work as well on the blockchain, where everything stored on the digital ledger is publicly visible.  Any password or other secret included within a blockchain transaction would be revealed to all nodes and users of the blockchain.  This is where zero-knowledge proofs (ZKPs) come into play.

What is a Zero-Knowledge Proof?

A Zero-Knowledge Proof allows a prover to demonstrate knowledge of some secret without revealing that secret.  For example, a ZKP could be used to prove to an authentication server that a user knows a particular password without the authentication server learning the password as part of the process.

An effective Zero-Knowledge Proof must meet three requirements:

• Completeness: After the proof is completed, the thing being proven — such as knowledge of the password — is indisputably true.
• Soundness: It is statistically implausible for a prover to trick a verifier with a fake proof.
• Zero-Knowledge: The ZKP doesn’t reveal the secret, only that the claim is true.

One example of a ZKP is proving to a color-blind person that two otherwise identical balls are different colors without revealing the color of either ball.  This can be accomplished via the following steps:

1. The verifier shows one of the balls to the prover and then conceals it again.
2. The verifier repeats step 1.
3. The prover states whether the balls from steps 1 and 2 are the same ball or different ones.

Assuming that the balls are actually different colors, the prover can answer the question in step three with 100% accuracy.  If they are lying, then they have a 50-50 chance of guessing correctly.  By performing the proof multiple times, the verifier can make it nearly impossible for the prover to be lying and guess correctly every time.

However, iterating this proof multiple times doesn’t provide the verifier with any information about the colors of the two balls.  They know for certain that the two balls are different colors but the prover never provides any information about the color of either ball.

ZK-SNARK and ZK-STARK

The zero-knowledge proofs used in blockchain are more sophisticated than this example.  However, the basic principles are the same.  The goal is to demonstrate that something is true without revealing some sensitive information.

In the blockchain space, there are two main forms of zero-knowledge proofs that are in use and under active development.  These are zk-SNARK and zk-STARK.

ZK-SNARK

zk-SNARK stands for Zero-Knowledge Succinct Non-Interactive Argument of Knowledge.  Breaking this down:

• Zero-Knowledge: The proof is a zero-knowledge proof that meets the three criteria of completeness, soundness, and zero knowledge.
• Succinct: The size of the resulting proof is relatively small, which is important on the blockchain where space is limited.
• Non-Interactive: A zk-SNARK proof can be verified without direct interaction between the prover and the verifier. For example, it can be posted to the blockchain and verified by anyone.
• Argument of Knowledge: A zk-SNARK proves that the prover knows secret information (the witness).

A zk-SNARK proof can be used to prove that a user knows a secret or that a transaction is valid without revealing the contents of the transaction.

A major limitation of zk-SNARKs is that they require a trusted setup, and an attacker with access to the random values used to generate a set of public parameters — the Common Reference String (CRS) — could generate fake proofs.  However, this issue can be overcome using multi-party computation (MPC) where multiple parties collaborate to complete the trusted setup and no party has complete information about the random values used.

ZK-STARK

zk-STARK stands for Zero-Knowledge Scalable Transparent Argument of Knowledge.  The two terms that differ from zk-SNARK are the following:

• Scalable: With zk-STARK proofs, the time required to generate and validate the proof grows more slowly as the size of the witness grows. zk-SNARKs are better for small witnesses, while zk-STARKs are better for large ones.
• Transparent: The random information used to set up a zk-STARKs proof is public, eliminating the need for a trusted setup.

zk-STARK proofs are generally less efficient in terms of storage and the computation required for verification than zk-SNARKs.  However, the lack of a trusted setup has positive implications for security, and zk-STARKs is better for large witnesses.

Blockchain Applications of Zero-Knowledge Proofs

Zero-Knowledge Proofs use mathematics and cryptography to prove that something is true while keeping secrets or eliminating unnecessary information.  These capabilities make ZKPs ideally suited to blockchain applications where the transparent, distributed digital ledger creates significant privacy concerns.

ZKPs have numerous potential applications within the blockchain ecosystem.  Some of the most significant include the following:

• Anonymous Transactions: On the blockchain, the details of all transactions are publicly visible, which makes it possible for blockchain nodes to validate them before adding them to the ledger. ZKPs allow transactions to be validated without revealing the details of the transaction.
• Identity Verification: Verifying users’ identities on the blockchain may reveal sensitive information on the immutable, distributed ledger. ZKPs can be used to prove a user’s identity without revealing that information on the blockchain.
• Authentication: As mentioned above, ZKPs can be used to prove knowledge of a secret, such as a password. This allows ZKPs to be used to authenticate a user as a member of a group or a legitimate user of a system on the blockchain.
• Verifiable Computation: ZKPs can be used to prove that the results of performing some computation are correct. This has the potential to improve blockchain scalability by allowing computation to be outsourced with only the result and the proof of its correctness recorded on the blockchain.

Security Considerations of ZKPs

ZKPs have the potential to dramatically improve the privacy, security, and scalability of blockchain systems.  The ability to prove the correctness of unknown information eliminates the need to place potentially sensitive information on the blockchain and allows computations to be outsourced to a third party without requiring trust in that third party.

However, along with their benefits, ZKPs also present significant security concerns.  Some security considerations for ZKPs include the following:

• Trusted Setup: zk-SNARKs requires a trusted setup where the initial randomness must be kept secret and destroyed. However, this can be addressed with MPC, and zk-STARK proofs do not require trusted setups.
• Costly Verification: Verifying a zero-knowledge proof can require significant resources. As a result, users may choose not to run and verify the proof, creating the potential that a malicious user could slip a forged proof through.
• Cryptographic Security: zk-SNARKs rely on elliptic curve cryptography, which can be broken by a sufficiently large quantum computer. While zk-STARKs rely on quantum-resistant hash functions, these algorithms may be broken at some point, which would undermine the security of the generated proofs.

At the moment, zk-STARK proofs are considered trustworthy and secure but often require more resources than zk-SNARK ones.  As a result, significant tradeoffs exist between ZKP usability and security.

ZKPs and the Blockchain

ZKPs are part of the future roadmap of many blockchain protocols; however, they are also in use today. For example, the zCash cryptocurrency gets its name from the fact that it uses zk-SNARKs to protect the privacy of transactions from z-addresses.

However, the main push for ZKPs in blockchain at the moment is for verifiable computing.  As blockchains like Ethereum work to improve the scalability of their protocols, the ability to offload computation and validate the results has the potential to dramatically increase the ability of these blockchains to process transactions and support the growth of Web3.

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post Introduction to Zero-Knowledge Proofs appeared first on Cryptosec.

A blockchain is a complex, multi-layered system.  Bitcoin, the original blockchain, maintained a distributed and decentralized digital ledger on top of a peer-to-peer network.  Later blockchains, like Ethereum, added complexity by integrating smart contract functionality and the technology needed to support these programs that run on top of the blockchain.

In addition to these various blockchain layers, there is now the concept of Layer 0, 1, and 2 blockchain solutions.  Each of these “blockchain layers” is intended to describe a particular function that has been added to or abstracted from the blockchain.

Blockchain Layers – In the Beginning, There Was Only Layer 1

When Bitcoin — and many other blockchain platforms — was created, there was no concept of Layer 0 or Layer 2 solutions.  Bitcoin, Ethereum, and similar blockchains are examples of what would today be called a Layer 1 blockchain.

Layer 1 blockchains are standalone solutions designed to maintain a distributed and decentralized digital ledger and potentially support smart contracts.  To varying degrees, blockchains are based on the design of Bitcoin.  Blockchains use a peer-to-peer network to communicate, organize transactions into blocks, use a consensus algorithm to achieve agreement on the contents of a particular block, and “chain” blocks together by including the hash of the previous block in the header of the next.  The details of the various blockchains can differ significantly, but they all clearly have a common ancestor.

Blockchain Layers – Layer 2 Solutions Address Layer 1 Limitations

The leading blockchain platforms, such as Bitcoin and Ethereum, are good at their jobs.  However, they are far from perfect solutions and have their limitations.  For example, Bitcoin has significant energy consumption and a slow block rate.  Ethereum, in its current form, has a low transaction bandwidth that can lead to the blockchain being overwhelmed.

Layer 2 blockchain solutions are designed to address some of the limitations of blockchain platforms without replacing these platforms entirely.  Instead, Layer 2 blockchain solutions perform off-chain activities that are then recorded on-chain.  Two common examples of Layer 2 blockchain solutions are state channels and sidechains.

State Channels

A state channel is established via an on-chain transaction that funds the channel with cryptocurrency from one or both participants.  After the channel is established, the participants can perform off-chain transactions by changing the balance of the allocated assets in the channel.  The channel can be closed by either participant with an on-chain transaction that records the current balance of cryptocurrency in the channel and releases the locked cryptocurrency accordingly.

State channels provide the ability to make instantaneous transactions with near-infinite scalability.  Since only the opening and closing transactions are recorded on-chain, there is no need to wait for intermediate transactions to be recorded in blocks, and the blockchain is not bloated with these transactions.  State channels also enable indirect transactions by allowing value transfers between multiple point-to-point state channels.

Sidechains

A blockchain like Bitcoin has the benefit of being well-established with strong security.  However, it lacks support for smart contracts, has a relatively slow block rate, and has other limitations.

Sidechains address these limitations by linking a blockchain like Bitcoin to another blockchain (called a sidechain).  This is commonly accomplished using bridges like Binance Bridge, cBridge, or AnySwap.  To transfer assets between chains, a user sends them to a particular address on one chain, and, after the transaction is approved, the corresponding assets are unlocked on the other chain.

Sidechains offer the potential to dramatically increase the scalability of a blockchain system by allowing transactions to be recorded on another chain.  It also interconnects the ecosystem of blockchains, allowing blockchain users to take advantage of the various benefits of different blockchains by transferring their assets between them using blockchain bridges.  For example, a user may store assets on Bitcoin for greater security but transfer them to other chains to use smart contracts deployed on those blockchains.

Blockchain Layers – Layer 0 Increases Blockchain Interoperability

Blockchains like Bitcoin, Ethereum, and many others were built largely independently of one another.  While modern blockchains are all based on the design of Bitcoin, the implementation details vary dramatically.  Also, many blockchains introduce new functionality or new takes on existing functions, such as the introduction of smart contract support in Ethereum or the creation of new consensus algorithms such as Proof of Stake.

The problem with the creation of completely independent blockchain systems is interoperability.  In the beginning, all smart contract platforms wanted to be “Ethereum killers”.  Now, Ethereum’s longevity and market share have made interoperability the major goal.  Other smart contract platforms are linking via Layer 2 solutions as well as attempting to develop support for the Ethereum Virtual Machine (EVM) to enable smart contracts developed for Ethereum to run on other platforms and vice versa.

Layer 0 blockchain platforms are intended to make it easier to build and integrate blockchains by providing the building blocks needed to do so.  Layer 0 protocols like Cosmos and Polkadot provide tools for developing Layer 1 blockchains and enable integration and communication between various blockchains within their ecosystems.  For example, blockchains built within the Polkadot Ecosystems (called parachains) can communicate internally via the Polkadot Relay Chain or use the Layer 2 protocol’s bridges to connect to non-Polkadot blockchains (such as Bitcoin or Ethereum).

Introduction to Blockchain Layers 0, 1, and 2 Blockchain Security

The introduction of Blockchain Layers 0 and 2 concepts to the blockchain ecosystem increases the complexity of discussing blockchain security.  For example, blockchains like Bitcoin and Ethereum have no Layer 0; all of the functionality of the blockchain is implemented at Layer 1.  In contrast, blockchains built on Polkadot or Cosmos have split core functionality between blockchain layers 0 and 1.

Regardless of whether a blockchain is implemented independently (like Bitcoin) or via a Layer 0 protocol, certain security risks exist, including:

• Cryptography: Blockchain security is heavily dependent on the security of hash functions and digital signatures.  If a blockchain uses an insecure hash or digital signature algorithm or the algorithm that it uses is broken in the future, then the security of the entire blockchain ecosystem falls apart.
• Consensus: Blockchain consensus algorithms are designed to ensure that all nodes in the blockchain network agree on the current state of the digital ledger while protecting against cheating.  The relative security of different blockchain consensus algorithms (such as Proof of Work vs. Proof of Stake) is hotly debated.
• Node Security: Blockchains are implemented as software running on a computer.  If the blockchain software contains vulnerabilities or the host node is infected with malware, then these security risks can affect both the node and the blockchain network as a whole.
• Network Security: Blockchain nodes communicate over a peer-to-peer network that is sparsely connected.  If an attacker can intercept or block communications between nodes, they can perform a Denial of Service (DoS) attack on the blockchain or threaten consensus security.
• Smart Contract Security: Many modern blockchains are designed to support the execution of Turing-complete programs on top of the blockchain (i.e. smart contracts).  These smart contracts could have design errors or implementation flaws that place them and their users at risk.  Most cyberattacks against the blockchain occur at the smart contract level.

Many of these security risks could be considered as Layer 1 security risks since they exist in independent blockchains like Bitcoin and Ethereum as well as blockchains created using Layer 0 protocols.  However, the introduction of Layer 0 and Layer 2 protocols can create additional threats to blockchain security across all blockchain layers.

Layer 0 Security

Layer 0 protocols are designed to abstract away the details of implementing a blockchain by exposing pre-built modules to a blockchain developer.  They also provide the ability to communicate with other blockchains within the Layer 0 ecosystem.

By using a Layer 0 protocol, blockchains accept certain security risks, such as:

• Centralization: Blockchains implemented using Cosmos, Polkadot, or other Layer 0 protocols all depend on shared modules, infrastructure, etc.  This centralizes significant power in the hands of the team behind the Layer 0 protocols, creating the potential for supply chain attacks, targeting by cyber threat actors, or internal abuse of this power.
• Vulnerable Code: With a Layer 0 platform, many blockchains may be implemented using the same modules.  If these modules contain design errors, implementation flaws, or exploitable vulnerabilities, they can affect multiple different blockchains.  For example, an error in CosmWasm’s implementation of the Bech32 specification impacted the security of smart contracts hosted on 20+ blockchains.
• Complexity: Layer 0 protocols are designed to create a complex ecosystem of interoperable blockchains.  This makes security analysis more difficult and creates the potential for attacks that take advantage of undesirable and unintentional interactions between the various blockchains within the Layer 0 ecosystem.
• Ease of Use: Layer 0 platforms make it possible to implement a blockchain with much less knowledge and understanding of the technology than is required to write one from scratch.  This is good for expanding access to blockchain technology and encourages the use of well-tested, more secure modules rather than custom code.  However, it also creates the potential that blockchain code will be cobbled together without a full understanding of how it actually works, resulting in code that insecure, inefficient, or otherwise less functional.

Layer 2 Security

Layer 2 protocols such as state channels and sidechains are designed to improve the scalability, throughput, and other aspects of a blockchain.  However, they can also introduce security risks.

Some of the security risks associated with state channels include:

• Off-Chain Transactions: The transactions performed between the parties in a state channel are not recorded on the blockchain’s digital ledger.  This means that they are only indirectly protected by blockchain immutability.
• Denial of Service Attacks: A transaction can only be made between two parties if there is a path between them via state channels that have enough capacity for the transfer.  An attacker that refuses transactions or sufficiently unbalances state channels could render a transaction impossible.
• Blocked Disputes: When a state channel is closed by a single party, the other has the opportunity to dispute the final state of the channel.  A DoS attack against that account could prevent a dispute transaction from being registed within the dispute window, allowing theft of some of the value stored within the channel.

Sidechains, implemented using blockchain bridges, can also create security risks, such as:

• Centralization: Often, a blockchain bridge is implemented and managed by a small number of parties that approve transactions between chains.  This centralization can be exploited by an attacker.  For example, the Ronin Network was the victim of the largest hack in DeFi history to date due to an attacker compromising 5 of the bridge’s 9 validating nodes and using this power to approve fake transactions.
• Cross-Bridge Effects: Blockchain bridges enable integration of multiple different blockchains, which can amplify the effects of an attack.  For example, Hundred Finance lost $3.3 million when an attack on the Meter.io blockchain bridge locally depreciated BNB.bsc on Binance Smart Chain. Attackers acquired the tokens at a low price and use them as collateral for loans with Hundred Finance — which used the higher global Chainlink price — to extract more valuable assets.
• Bridge-Focused Exploits: Bridges must be properly integrated into multiple blockchains to correctly read deposits on one blockchain and release funds on another.  If an attacker can trick a bridge into accepting a fake deposit, they can drain value from the bridge contract.  This occurred in the Wormhole hack where the attacker created a transaction that exploited a flaw in signature validation by the bridge to drain $326 million from the bridge with a fake deposit.

Taking a Holistic Approach to Blockchain Layers Security

Often, security audits of blockchain systems focus on the smart contract level where many attacks against the blockchain occur.  However, the various levels of the blockchain ecosystem can impact the security of smart contracts running on a platform or the blockchain as a whole.  For example, Layer 2 exploits against blockchain bridges commonly have an impact on DeFi protocols due to their effects on the value of tokens on different blockchains.

Securing the blockchain requires considering all blockchain layers and their security.  This includes taking into account the effects that Layer 0 and Layer 2 protocols can have on the security of a blockchain system.

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post Introduction to Blockchain Layers 0, 1, and 2 Security appeared first on Cryptosec.

One of the main shortcomings of most DevOps programs is that they overlook security, focusing on getting software released as quickly as possible.  As a result, tens of thousands of vulnerabilities reach production each year, putting customers at risk.  Additionally, fixing vulnerabilities in production is costlier than in the development and steals resources away from developing new software.

With the rise of smart contracts and decentralized finance (DeFi), software development is increasingly moving to the blockchain.  However, traditional development practices – with security treated as an afterthought – do not work for blockchain environments.  Blockchain developers must adopt DevSecOps practices and tools to ensure the usability and security of their projects.

Blockchain Development is Different From Traditional Development and Requires DevSecOps

Vulnerability management and secure coding are important for both traditional and blockchain development.  In both cases, vulnerable code exploited by an attacker can have a dramatic impact on a company and its customers.

However, the environments where traditional software and smart contracts operate are very different.  Traditional software is designed to run on a computer, while smart contracts run on top of the blockchain.  The differences between these two ecosystems create significant challenges for smart contract developers and amplify the potential impacts of attacks against software hosted on the blockchain.

Why DevSecOps – The Blockchain Ecosystem is Fragmented

For traditional software development, there are only a few environments that software developers work in.  Computer operating systems are largely broken up into Windows and *nix (Linux, Mac, etc.).  While differences exist between Windows versions or Linux flavors, the overall consolidation of the ecosystem makes it easier for developers to understand how a platform works and how to write secure, effective code for it.

The blockchain ecosystem is much more fragmented.  Smart contract platforms are still in their early stages of development with new contenders trying to unseat more established platforms, such as Ethereum.  As a result, there are many more smart contract platforms than there are types of OSes.

Most smart contract platforms use their own virtual machines (VMs) to run smart contracts.  Some of these are developed in-house, while others use existing systems (such as the Java Virtual Machine).  Each VM has its own quirks and idiosyncrasies, making it more difficult for developers to create functional and secure code that runs in different smart contract environments.

Why DevSecOps – Blockchain is Relatively New

Modern digital computers have been around since the 1940s, and the concept originated over a century before.  Since then, computer usage and the development of computer programs have grown rapidly and dramatically.  Despite this, vulnerabilities are still common, and the same programming errors appear again and again.

Compared to computers, smart contract platforms are relative newborns.  Ethereum, the oldest smart contract platform, launched in July 2016, and its competitors are even younger.  This means that developers lack the same level of experience with smart contract programming languages and virtual machines that they have with more established languages and environments.  Smart contract programming is riskier because many developers lack the experience to do it properly, and the environments themselves lack the maturity and level of security testing of traditional computers.

Why DevSecOps – Everything is “Open Source”

Exploiting vulnerable software is always easier with access to the source code.  With the ability to read the code, a potential attacker can use static code analysis tools and more easily understand the intended function and flow of code and where vulnerabilities may exist.  For this and other reasons, many organizations do not publish their source code.

On the blockchain, all smart contract code is essentially open-source.  Many blockchain projects publish their source code, and decompilers exist for those that do not.  While decompiled code is not as readable as the original, it is good enough for most attackers’ purposes.

The open-source ecosystem of the blockchain makes it far easier for potential attackers.  The ability to read the source code and understand the developers’ logic (and the potential flaws it contains) makes smart contract exploitation easier in general than with traditional, closed source code.

Why DevSecOps – Software Updates Aren’t Easy

Traditional software development processes are heavily dependent on the ability to update the software when needed.  The many vulnerabilities that reach production can be easily addressed by sending out an update with better, more secure code.  This upgradeability is the foundation of agile development as well because it allows the software to be built and deployed in segments.

On the blockchain, software updates, while possible, are not as easy to perform.  The blockchain is designed to maintain an immutable digital ledger, meaning that any transactions performed on the blockchain cannot be changed after they have been added into a block that is validated and accepted by the network.

Smart contract code is deployed as a blockchain transaction and stored on the immutable digital ledger.  If vulnerable code is pushed to the blockchain, it cannot be easily overwritten with better, more secure code as is possible for traditional software.  While smart contracts can (and should) be written to allow updates, this must be an intentional feature of the design and implementation and is not supported by default.

Why DevSecOps – Exploitation is Easy

It’s a cliche that a criminal needs means, motive, and opportunity.  For smart contract exploitation, the means is a vulnerability and the motive is the fact that many smart contracts (especially in the DeFi space) store massive amounts of value.  Smart contract hackers have plenty of motivation and weak development practices provide the means needed to exploit them.

The design of the blockchain also provides ample opportunity for an attacker to exploit smart contracts.  Most major blockchains are designed to be open, permissionless platforms, meaning that anyone can create an account and perform transactions on them.  While a particular smart contract may require privileged access to certain functions or data, most smart contracts are designed to have functions that are publicly accessible.

This means that smart contract attackers can easily gain the access needed to exploit a vulnerable smart contract.  The blockchain makes it easy to create an account and send transactions to vulnerable software running on top of it.  Additionally, the pseudo-anonymity of the blockchain also makes smart contract exploitation relatively low-risk because it is extremely difficult to attribute a particular account and the attacks performed by it to its real owner.

Why DevSecOps – Attacks Are Not Easily Reversible

In traditional IT, many of the biggest types of cyberattacks are reversible given the right resources.  An attack by ransomware or wiper malware can be fixed by restoring any encrypted or deleted data from backups.  Financial fraud can sometimes be reversed if a financial institution is contacted in time.  An infected computer can always be restored to operation by reinstalling its operating system.

The blockchain, on the other hand, is designed to implement an immutable digital ledger.  Once a transaction is performed on the blockchain, it is relatively permanent.  This means that, except in very rare cases (such as the Ethereum DAO hack), a successful attack is not reversible.

This fact dramatically raises the stakes of smart contract security.  Without the ability to undo a successful hack, smart contract developers need to ensure that the hack cannot happen in the first place, which requires strong code security.

Blockchain Development Requires Strong DevSecOps Practices

Traditional development practices often focus on time to release instead of security.  This is also true of many blockchain projects as developers try to release new projects as quickly as possible to beat the competition or take advantage of the hype.

Integration of security into the development process or “DevSecOps” is vital for traditional development.  The massive and growing number of vulnerabilities discovered in production software each year is unsustainable and places customers at risk.

However, strong DevSecOps is arguably even more important for blockchain projects due to the unique nature of the blockchain ecosystem.  Many smart contract-based projects are high-profile and valuable, making them tempting targets for attackers.  At the same time, it is more difficult to write secure code and to fix any issues that are discovered after a project is released to the blockchain.  Additionally, smart contract hackers have significant advantages because they can often read a project’s source code, they can easily gain the access needed to perform their attacks, and a successful attack is not easily reversed.

Managing the threat of insecure code on the blockchain requires developers to embrace the DevSecOps movement and update their development pipelines to better integrate security.  Tools exist for detecting vulnerabilities in smart contract code, and many of these can be integrated into automated development pipelines.  By taking advantage of these solutions and auditing all code before launching it on the blockchain, smart contract developers can minimize the threat that vulnerable code poses to them and their users.

This article is the first in a series on improving smart contract security.  Keep an eye out for future articles on smart contract security auditing tools, security best practices, and other key aspects of smart contract security.

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post Why DevSecOps is Essential for the Secure Blockchain Ecosystem appeared first on Cryptosec.