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.

Decentralization is a hot button topic in web3, and Binance is (at the time of writing) the biggest crypto exchange by trading volume in the world.

The recent Binance bridge hack – hack of Binance’s native cross-chain bridge BSC Token Hub, revealed to the world what many early adopters of blockchain technology already knew: The BNB Smart Chain (formerly Binance Smart Chain) is not very “decentralized”.

How did the BNB Smart Chain bridge get hacked, how did Binance stop it, and what does the Binance bridge hack have to do with decentralization?

Let’s go through this in order.

How the BSC Token Hub was Hacked

The BSC Token Hub is a cross-chain bridge native to Binance that allows users to transfer tokens between the BNB Beacon Chain (BEP2) and BNB Smart Chain (BEP20 or BSC).

On October 6, 2022, an attacker interacted with the BSC Token Hub smart contract in a way that allowed them to print two million BNB tokens (the native token on the BNB Smart Chain), worth approximately $566 million at the time. This was achieved using falsified transactions that convinced the bridge that the attacker had deposited the BNB previously, and was therefore eligible to withdraw that much.

According to Binance’s official response, “the exploit was through a sophisticated forging of the low level proof into one common library,” and an anonymous blockchain researcher who goes by @samczsun on Twitter shared an in-depth breakdown of the technicalities involved in the forgery.

Source: https://twitter.com/samczsun/status/1578167198203289600?s=20&t=pd2TogOJt1dnOX9aq9Epqg

How the Binance Bridge Hack was Stopped

The short version is that the Binance team was able to respond quickly to rally all the validators on the network to halt the BNB Smart Chain and freeze the majority of the stolen funds before they could be fed through mixers and taken off-chain.

At the time of BNB Smart Chain’s network suspension, around $430M worth of crypto in the attacker’s wallet was frozen, while another ~$110M had already been transferred to various other blockchains. Here’s a snapshot of where the extra funds went:

Tether had begun blacklisting ill-gotten USDT in the hacker’s Ethereum wallet, and Circle will likely do the same with their USDC as soon as an attempt is made to put it through a mixing service or send it to an exchange for withdrawal. For now, tracking any potential movement of the funds provides further insight for cybersecurity experts and law enforcement to continue their investigation and attempt to uncover the attacker’s identity.

So how does Binance Bridge Hack Change the way People View Web3?

It all comes back to decentralization.

A network can be considered “decentralized” if it has a sufficient number of distributed nodes that all share equally in the functions of running the network and keeping it secure. What exactly the “sufficient” number is is up for debate, but it largely comes down to how easy it is for one centralized authority to control what happens to the entire network.

For example, there are nearly 15,000 Bitcoin nodes, over 8,000 Ethereum nodes, and only 26 active BNB Smart Chain nodes at the time of writing. BNB Smart Chain technically is a network of distributed nodes, but it’s not very many nodes comparatively, and the ones that do exist are influenced by Binance’s team to a high degree. It’s this high degree of centralized authority which prompted the BNB Smart Chain node operators to rapidly halt the blockchain and implement a software upgrade which froze the remaining stolen BNB.

When we consider the infamous “blockchain trilemma” (the commonly held belief that a blockchain can only have 2/3 in regard to decentralization, security, and scalability), it’s clear that the BNB Smart Chain sacrifices decentralization for better security and scalability. That’s why their transactions are so fast and cheap, and why they are able to respond to cyber attacks so effectively, but at the end of the day how much different is it from using a normal bank when there’s just a small team of validators who control the entire network?

The answer is that it’s actually quite different. The Binance ecosystem taken as a whole (the exchange, the team, the token and the blockchain) is a bit like web3 lite for users who want a more simple experience of digital asset trading and use. It’s like an introductory on-ramp for crypto and NFTs. While the promises of ETH 2.0, layer 2s and ZK rollups, as well as competing blockchains are all good alternatives that might solve the blockchain trilemma in the future, the BNB Smart Chain in its current form has shown that it can withstand major exploits and mitigate some of the risks inherent to the early adoption of this disruptive technology.

The CEO of Binance, Changpeng Zhao, shared his thoughts on decentralization in the wake of the Binance bridge hack, stating “it is also important to remember that decentralization is a means to the goal, not the goal itself. The goal is freedom, security, and ease of use.”

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 the Big Binance Bridge Hack Will Change the way People View Web3 appeared first on Cryptosec.

The only way to understand how the Beanstalk Farms decentralized credit-based stablecoin protocol exploit happened is to first understand flash loans, which are a little known financial tool unique to the DeFi (decentralized finance) space, as well as governance. Beanstalk Farms Hack is a great example of DeFi hacks.

A flash loan is, like it sounds, a very fast loan. It happens within a single blockchain transaction and no collateral is needed. Instead, the borrower needs to set up a series of trades using smart contracts that can all be executed at once, and they must yield a profit. If the trade doesn’t yield a profit, the transaction is cancelled and the loan is not approved. On the other hand, if it does yield a profit then a fee is paid to the platform issuing the loan, such as Aave for example, and the remainder is kept by the trader.

If that all sounds too good to be true, it’s because it kind of is. You’ll pay a lot in gas fees, even for failed transactions, and the vast majority of your transactions will probably fail. There are programs to help you organize the trades and find arbitrage opportunities, but it’s still incredibly difficult. Only deeply experienced traders should attempt to use flash loans.

As exciting as they are, flash loans also present unique security risks to DeFi protocols. The $182M exploit of the Beanstalk Farms ecosystem is a perfect example.

How the Attack was Executed

So we know about flash loans, but we also need to briefly discuss governance, particularly in relation to DAOs (decentralized autonomous organizations). With a decentralized project like Beanstalk Farms, a governance protocol is needed to take various actions, such as software updates, changing yield and protocol details, or proposing and voting on solutions to problems that might arise.

What’s important to know about the DAO in this case is that proposals need a supermajority (more than 2/3) in order to pass, and the platform’s BEAN stablecoin can be used to generate Stalk and Seed tokens, which represent voting power – so if a bad actor could take control of >67% of the governance tokens, they would be able to attack the network and pass malicious proposals.

That’s exactly what happened.

A series of fast transactions involving a $1B flash loan from the Aave protocol along with what must have been the longest 24h wait in the attacker’s life allowed them to take control of a massive pile of BEAN, then use them to generate enough Seed and Stalk tokens to give their wallet 70% of the supply, and then transfer all the funds from Beanstalk’s wallet to their own, ultimately making off with around $76M worth of stolen cryptocurrency, but leaving Beanstalk Farms out $182M in liquidity.

Cybersecurity firm DeFiSafety released a post-mortem with all the technical details.

Timeline of the Beanstalk Farms Hack

April 16, 2022:

At 08:38 UTC, this address (referred to as the ‘Beanstalk Flashloan Exploiter’ address) swaps 73 ETH for 212,858 BEAN. Nothing suspicious here, but now that we know to look we can see that the wallet was initially funded through the crypto mixer Tornado Cash.

Nine minutes later, at 08:47 UTC, this transaction shows the same address depositing the 212K BEAN into the Beanstalk ‘Silo’, which is the mechanism used for generating Seed and Stalk governance tokens. With this deposit, a proportionate amount of governance tokens were generated to allow the address to make a governance proposal.

At 10:54 UTC, the attacker made the first of two proposals. Notably, the first proposal was seemingly blank while the second proposal was a $250,000 donation to Ukrainian crypto exchange KUNA, which was passed but promptly returned with a message from the exchange’s founder. The first proposal contained hidden code which connected it to a malicious smart contract that, if passed, would drain the Beanstalk liquidity into the attacker’s wallet.

However, proposals require a 7-day period before they execute (if they obtain a supermajority vote), but there’s a backdoor called the emergencyCommit() function, which allows a proposal to pass in just 24 hours. All that’s needed is >67% of governance tokens to execute emergencyCommit().

April 17, 2022:

At 12:24 UTC, more than 24 hours after the two proposals were made in the Beanstalk DAO, the attacker initiates the $1B flash loan which includes 350M DAI, 500M USDC, and 150M USDT.

A flurry of swaps occur within the single transaction which allow the attacker to borrow over 32M BEAN and several million more in various Beanstalk whitelisted stablecoins. All this led to the generation of a 70% supply of the governance tokens, which allowed the attacker to execute emergencyCommit() on their two proposals.

As mentioned above, the first proposal passing actually transferred all of Beanstalk’s liquidity to the attacker’s wallet. With the stolen funds, the attacker paid off the flash loan and walked away with around $76M worth of stolen ETH, while Beanstalk Farms had lost $182M.

BeanStalk Farms releases the first public statement confirming the attack at 17:36 UTC via a tweet saying “Beanstalk suffered an exploit today. The Beanstalk Farms team is investigating the attack and will make an announcement to the community as soon as possible.“

They also paused the protocol using ownership privileges right before making the announcement. An update in Discord shortly after confirmed the Beanstalk team had contacted the FBI.

April 18, 2022:

The primary Beanstalk dev, who went by Publius, revealed to the community in a Discord announcement they were actually 3 people and publicly doxxed themselves to help reassure users they were not involved in the attack.

The attacker sent the funds through Tornado Cash and they have still not been recovered as of October, 2022.

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 a $1B Flash Loan Led to the $182M Beanstalk Farms Exploit 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.

Decentralization is a hot-button topic in 2022.

To some, it seems like the solution to a variety of issues plaguing the so-called web2 ecosystem, such as the monopolization of social media, the centralized control over the flow of information, and bad data privacy and data monetization practices. Proponents of distributed blockchain technology offer web3 as the decentralized solution to these problems, but web3 has some kinks to work out before it can replace the established infrastructure of web2.

One of those kinks involves exploitable smart contracts, a $190 million liquidity pool, and simple human nature. This is the full story behind one of the largest DeFi hacks, the Nomad Bridge Hack of August, 2022.

The Nomad Bridge Hack Timeline

August 1, 2022:

Source: https://twitter.com/nomadxyz_/status/1554246853348036608?s=20&t=bbAzgxq95hczZKUsXIabgw

Ethereum block 15259101 at 21:32:31 UTC contains four transactions at indices 0, 1, 3, and 124.

Each transaction is a fraudulent withdrawal from the Nomad bridge for 100 WBTC (~$2.3M at the time).

An attacker has found a bug in the smart contract that verifies Ethereum transactions on the bridge, and it’s as easy as copy/pasting the fraudulent transaction details and replacing the receiving wallet address with one’s own to replicate the attack.

Here’s Nomad’s post-mortem for the technical details about the exploit method.

Needless to say, pandemonium ensued.

Aug 2, 2022:

Within hours of the initial attack, hundreds of similar attacks occurred for a total of 960 transactions with 1,175 individual withdrawals from the bridge, according to an after-the-fact Twitter thread by Nomad.

The liquidity in the Nomad Ethereum bridge wallet was drained from ~$190M to $16,573.

Since it was so easy to replicate, you can imagine the dilemma some people were in when they realized they could copy the attack; others did, however, realize they could take the funds for safekeeping and then return them when the exploit was patched. This was a very risky move because, regardless of intent, they still committed theft and broke multiple cybercrime laws.

Only experts in digital asset recovery and cybersecurity professionals who know what they’re doing should take these kinds of actions.

Source: https://twitter.com/0xPaladinSec/status/1554252732365668362?s=20&t=A0hYTf2pz48Qi4FLt1JMsw

Aug 3, 2022:

Nomad begins the funds recovery process and shares an address for white hats to return stolen funds to.

Source: https://twitter.com/nomadxyz_/status/1554679735006859264?s=20&t=bbAzgxq95hczZKUsXIabgw

Aug 4, 2022:

Within 24 hours, Nomad has already recovered $16.6M, and they publish the addresses of some of the white hats who contributed to the asset recovery efforts alongside the amount of crypto each wallet was safeguarding.

Source: https://twitter.com/nomadxyz_/status/1555045760588140544?s=20&t=bbAzgxq95hczZKUsXIabgw

Aug 5, 2022:

Nomad announces they’re working with the TRM Labs cybersecurity team, and states that many of the attackers used traceable addresses with identifying information attached.

Source: https://twitter.com/nomadxyz_/status/1555559853795540992?s=20&t=yJuc3V_5xPj91l2uL3Aaew

They also announce a 10% bounty on the return of stolen funds, and promise not to pursue legal action against those who cooperate.

Source: https://twitter.com/nomadxyz_/status/1555559855217410051?s=20&t=yJuc3V_5xPj91l2uL3Aaew

After one white hat returned $9.4 million worth of crypto, Nomad made another update announcing they had collected $31.8M so far.

From August 5th onward, Nomad would pursue the rest of the assets by working with crypto investigators, law enforcement, and the crypto community at large to entice copycat hackers to return the funds they took and to track down the ones who don’t cooperate.

They announced on August 30th they had engaged the Chainalysis Crypto Incident Response team for advanced blockchain tracing and to help identify the hackers.

Unsurprisingly, white hats who returned 90%+ of the stolen funds were awarded with a free NFT from Metagame, and also 100 FF tokens from Forefront.

Source: https://twitter.com/nomadxyz_/status/1562097378445836292?s=20&t=bbAzgxq95hczZKUsXIabgw

This was a nice gesture and a unique incentive to offer, but clearly it didn’t work as well as they’d hoped.

As of their most recent update on September 27th, they had recovered just $34.1 million (not adjusted to reflect the cost of the assets at the time of the attack).

That number is however expected to rise through future legal action and recovery processes based on their investigations and working with law enforcement.

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 the Nomad Bridge Hack can Help Us Explore the Potential Downsides of Decentralization appeared first on Cryptosec.