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.

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.

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.

Table of Contents

Cyber-Attack Strategies in the Blockchain Era – A Framework for Categorizing the Emerging Threats to the Crypto Economy

Market attacks

Rely on the mass-manipulation of investors through asymmetric information

Pump-and-dump

Parties conspire to artificially inflate (pump) the price of an asset using various manipulation tactics (spoofing, wash selling, layering), in advance of selling (dumping) their stake. The reverse technique can be used to acquire an asset below fair value in a short-selling strategy.

Exit scam

A project such as an ICO or DAO raises substantial capital from investors, before unexpectedly terminating all operations. Rather than returning the capital to investors, the founders disappear with all the funds.

Rug-pull

A common DeFi exit scam, whereby creators of a token pair it with a legitimate coin (BTC, ETH) on a DEX. Having attracted a large amount of liquidity (through hype and the promise of high returns) they exchange their own token for the legitimate currency and so drain the reserves.

Investment scam

A classic example is the Ponzi scheme, where investors are led to hand over funds in return for impossible returns. DeFi provides a fertile ground for re-using old investment scams as it provides a new set of terminologies (APY, Rewards) to give the appearance of novelty.

Front running

Unconfirmed transactions are visible in the “mempool” prior to execution, providing an opportunity for ‘front-runners’ (typically miners or full-nodes) to trade on this information, placing their order ahead in the queue.

Economic attacks

Cons that operate to extract funds from individuals by threat or trickery

Phishing

Hackers send out a mass email (‘casting the net’) purporting to originate from a legitimate company, directing users to a fake website that mimics the company brand. The fake website harvests personal information such as passwords and bank information.

Spear phishing

Unlike ‘net fishing’, this strategy targets a specific person. Hackers conduct research on the individual to provide sufficient background to convincingly impersonate a colleague or senior, and make a fraudulent request (sending private data, wire transfer).

Extortion

Victims receive an email claiming that the attacker has acquired compromising information or graphic material (e.g. via the victim’s webcam), which they will send to the victim’s contacts or release publicly unless the victim sends payment or shares private keys.

Ransomware

Hackers gain access to a system and encrypt the files. They demand a ransom from the owner in return for sharing the decryption key. RaaS (Ransomware-as-a-Service) providers offer fraudsters the opportunity to ‘partner’ in return for share of the takings.

Churning

Excessive trading of securities in an investor’s portfolio by a broker with the sole aim of generating commission revenue. On top of unnecessary fees, the client may be liable for additional capital gains taxes.

Celebrity-based scams

A celebrity (e.g. Elon Musk) is represented as making a general offer. E.g. to double the money of any investor who sends funds to their account before a specified date and time. This could be done via a hacked account, faked account, doctored tweet, or fake online event.

Consensus attacks

Blockchains work by nodes agreeing on what transactions have been made. This system can be bypassed, exploited, and hijacked in numerous ways to favor individuals or cartels.

Finney attack

An attacker mines a block as usual, including a transaction that sends coins to his account. Before broadcasting it, he sends the same coins to a merchant and receives a service. When the originally mined block is broadcast, the transaction to the merchant is erased. (PoW)

Race attack

The attacker creates two conflicting transactions, one sending payment to the victim, and another returning an identical amount to the attacker. The second transaction invalidates the first transaction, leaving the victim out of pocket. (PoW)

Vector76

Combination of Finney and Race attacks: attacker broadcasts two transactions to his own account, one high-value and one low-value. The high amount is deposited, but the network accepts and records the low amount. Very hard to achieve in practice. (PoW)

51% majority attack

A miner or group of miners gains control of 51% control of the network, and is able to reverse transactions (e.g. double-spend), creating a new branch of the blockchain. Smaller blockchains are at a higher risk of this attack, as well as chains with mining pools (PoW / PoS).

Nothing-at-stake

Also known as costless simulation. An adversary may create an alternative branch to the main chain of a POS-based blockchain starting at any point that he wants without incurring any actual cost. (PoS)

Weak subjectivity

A new node (or node that has been offline for an extended period) will not immediately be able to discern the main branch of the chain. It can be tricked into accepting a malicious one. (PoS)

Liveness denial

Also known as BDos (Blockchain Denial of Service). Some or all validators decide to stop publishing blocks, thus bringing the network to a halt. (PoS)

Censorship

Because validators have the power to confirm or deny transactions, it is in their power to ‘blacklist’ certain addresses, leading to delays or ‘time-outs’. (PoS)

Precomputation attack

A validator exploits the selection mechanism to increase the frequency of being chosen as a slot leader (i.e. the ability to create a new block). Also called a Grinding Attack. (PoS)

Mining Pool attacks

Collusion between actors to bypass the consensus mechanism by creating forks in the chain is an alternative to the ‘legitimate’ means of consensus hacking by gathering a majority or critical mass of voting power.

Selfish mining

Malicious miners/validators deliberately delay the broadcast of mined blocks to the network, and then broadcast them simultaneously to create a new main chain. This wastes the energy of the other miners (PoW) and accumulates rewards for the attacker nodes (PoW, PoS).

Bribery attacks

The attacker persuades or bribes miners/validators to create a new branch by confirming dishonest transactions, increasing the risk of double-spending. Also called Short-Range attack. (PoW, PoS (lower cost)).

Long-range PoS attacks

The hacker generates a complete alternative history of the blockchain (going back to the genesis block). (PoS)

Simple

The attacker secretly creates a rival chain, forging the timestamps on the blocks so that it is not possible for nodes to tell the difference between the forged chain and the real main chain.

Posterior Corruption

Where timestamp-forging is not an option, the attacker can use the private keys of a retired validator (either by theft or with their consent) to sign valid blocks.

Stake Bleeding

When the attacker is given their turn as slot leader, they forfeit their turn (slowing the growth of the main chain), thus steadily ceding their stake to the other validators. Meanwhile, they publish blocks constantly on the rival chain, and so eventually catch up with the main chain.

Network-level attacks

Communication between the nodes is the lifeblood of the blockchain network. Blocking or manipulating these communications is a way to subvert or pervert the proper functioning of the chain.

Routing attacks

Attackers conspire to block or delay transactions emanating from a particular node, rendering the mined blocks temporarily or permanently unrecognized by the wider network. This disconnect can be exploited to cause damage to a miner and/or carry out double-spending.

Sybil attacks

A node creates several fake identities, which it uses to absorb the transactions of the victim node, enabling double-spending. Blockchain-based systems (PoW and PoS) are in general well-protected against such attacks.

DDoS (Distributed Denial of Service)

By flooding the mempool with spam transactions, attackers can cause network congestions, software crashes, and node failures, as well as bloat the ledger with blocks that are full of fake events, while legitimate transactions are stalled.

Eclipse attacks

A form of DDoS attack: the perpetrator takes control of a large number of IP addresses, induces the victim node to restart, and then redirects all outgoing connections to the attacker-controlled IP addresses.

Transaction Malleability

A victim makes a legitimate transaction by sending funds to the attacker. The attacker creates a copy of the transaction, altering the transaction ID to make it appear that the transaction has failed, and then broadcasts it to the network. The victim can thus be tricked into paying twice.

Timejacking

A hacker adds a number of fake peers to the network with inaccurate timestamps to alter the time counter on the victim node. The victim node will reject transactions from the rest of the network, becoming isolated and vulnerable to exploits such as double-spending.

Wallet attacks

Since wallets are where cryptocurrency is stored, finding ways to bypass wallet security is a prime vector for cybercriminals.

Seizure of Private Keys (Hot Wallets)

Centralized exchange platforms (as opposed to DEXes) store the private keys of their users in databases. Attackers who gain access to these databases can take ownership of the wallets and their contents.

Cold wallet hacks

While more secure than Hot Wallets, hardware-based Cold Wallets have been found to contain exploitable bugs (e.g. Nano S Ledger) that can give hackers access to private data. In some cases, a breach happens prior to delivery (by intercepting & programming the wallet en route).

Fake Wallets

Attackers use Google Ads to direct consumers searching for legitimate hot wallets (e.g. Metamask) to sites that mimic the genuine interface. Users enter their details which are copied by the attacker, or are maneuvered into sending funds to the attacker’s wallet.

SIM-Swap

In order to bypass 2-factor authentication security, a hacker impersonates the user in order to convince their phone company to transfer their number to a new SIM controlled by the hacker. The hacker can now gain access to their wallet and lock the user out.

Security phrase handling

Users are at risk of leaving vulnerable seed/passphrases accessible to hackers in an attempt to make them easily accessible to themselves (e.g. storing it on their computer), or being tricked into revealing them (e.g. to a fake customer service representative).

Dictionary attacks

The attacker attempts to break a victim’s password by converting common passwords (e.g. password123) into cryptographic hashes, and then searching for similar combinations to identify hackable wallets.

Vulnerable signatures

Private keys are generated by cryptographic algorithms, and are intended to be unbreakable due to their random nature. ECDSA (used in Bitcoin cryptography) has been found to have insufficient entropy and hence ‘weak’ randomness, leaving it vulnerable to decryption strategies.

Smart contract attacks

Smart contracts are immutable, transparent, and capable of holding value. These properties also make them a liability if errors or exploits exist in the code.

Reentrance

The targeted contract makes an external call to the attacker contract, which utilizes a fallback function to interrupt the process and carry out additional actions, potentially draining the victim contract of all funds.

Flash loan exploit

Flash loans are a cheap, fast way to get hold of large sums of money (and hence have a large impact when misused). A smart contract may contain bugs that can be specifically targeted by attackers using flash loans to drain large amounts of funds or heavily influence market prices.

Transaction Order Dependence

When a smart contract is invoked by two transactions, it can be left to the miner to decide the order in which the transactions are recognized. This situation opens the possibility of manipulation, particularly where the outcome concerns price (e.g. front-running).

Timestamp Dependence

When the outcome of a smart contract is dependent on the timestamp of a block, the miner has some discretion to assign a timestamp (provided it is within 10-15 seconds of the time of actual validation) that gives them an unfair advantage.

Blockhash usage

For the same reasons as Timestamp Dependence, making any critical element of the smart contract dependent on the blockhash function (e.g. as a source of randomness) can create an opportunity for a miner to alter the blockhash – and the outcome – in their favor.

Arithmetic Exploit

An example of an exploitable arithmetic error would be Over/Underflow. When a number is greater / lower than the maximum/minimum range, a parameter can be reduced to zero (e.g. neutralizing contract locktimes).

Short Address Attack

A bug in the ERC20 protocol allows a hacker who deliberately omits the final two zeroes from an address to withdraw 256 times the number of tokens that the victim (likely an exchange) believes are being withdrawn.

DelegateCall

The Delegatecall function is a way to leverage the code from an external contract to perform a common operation. Because it gives the external contract power over its own storage, a malicious contract could be used to cause harm or remove value.

Default visibilities

Some contract functions (for example conditions for the release of funds) should be private. However, functions within a smart contract are publicly visible by default. Developers may forget to disable visibility for key functions, leaving the contract open to exploitation.

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 Security Threats to Blockchain Networks – 1 – Cyber Attacks Taxonomy appeared first on Cryptosec.

The situation is like a military leader trying to fight different enemies on different fronts. While those enemies remain in different fronts, it makes sense to send separate defense forces against them, each focused on fighting only the enemy assigned to it. But what if those enemies merge and launch joint attacks? A smart military leader would merge his forces against the joint attacks.

That’s not happening in financial institutions, though. Rather than having financial crime and cybercrime teams work together against this merged threat, institutions most often maintain them as separate entities. That’s as ridiculous as a military leader sending two separate units against an attacking force, but telling them not to coordinate their attacks, to fight only certain attackers and to ignore the other attackers.

That is the environment that currently threatens financial institutions in their war against financial crimes, fraud and cyberattack. Financial crime and cybercrime increasingly merge. Yet counter-financial crime teams and cybersecurity teams largely remain unconnected. How have we gotten here? And what can be done to meet this new challenge?

The growing convergence of financial crime and cybercrime

With our increased dependence on technology, money – which once was strictly a physical entity – has increasingly become 1s and 0s stored and processed on information systems and transferred through cyberspace. Vast amounts of money now reside in this ungoverned space where no government has full jurisdiction, making it a safe haven for criminals to operate with less detection.

It is only natural, then, that criminals increasingly move their efforts there. On one hand, the cyber world offers traditional perpetrators of financial crimes inviting access to amounts of money that would be almost impossible to obtain elsewhere. On the other hand, it offers a lucrative environment for skilled cyberattackers to monetize their skills.

This confluence of opportunity and anonymity facilitates crimes on a scale that otherwise would be beyond criminals’ reach. Such was the theft of US$45 million through a complex scheme that a large network of cybercriminals, common street criminals, and money launderers pulled off in a matter of hours at ATMs across the globe.

Even more staggering was the US$81 million theft from a Bangladesh bank (with similar attacks on additional banks, whose losses have not been publicly reported). This complex theft was accomplished by combining the skills of cybercriminals and fraudsters to subvert the bank’s SWIFT account, thus co-opting the global interbank transfer system over which billions of dollars move from bank to bank daily.

Other than their scope, these are not isolated incidents. Cybercriminals, perpetrators of financial crime – and even rogue governments like North Korea – collaborate to commit complex thefts. In fact, cybercrime has now become more profitable than the drug trade.

The continuing separation of financial crimes defense and cyber defense

Defense against these conjoined attacks is hampered when defense systems operate in separate silos. Criminal attacks on both systems are growing increasingly complex.

What drives financial crime defense into isolation

In the financial crime arena, it is important to realize that the term “financial crime” forms a broad umbrella over a variety of crimes, from fraud to money laundering to terrorist funding to sanctions violations and much, much more (learn more here).

Fraud – just one of the types of crimes that falls under the umbrella – comes in many forms, with each form often combated by specialized teams such as first-party fraud team, credit card acquiring fraud team, credit card issuing fraud team, online banking fraud team, etc. Even more, fraud teams are often divided into fraud strategy teams, fraud monitoring, fraud investigations, and more. Similar situation happens often for other types of financial crimes as well.

Regulations for each type of financial crime grow constantly – and often in isolation from regulations for related crimes. That motivates institutions to focus on each type in isolation, as does the tendency for an institution to dive deeper into preventing recurrences of whatever type of financial crime has most recently stung it, while paying less attention to other types. Thus, defenses become fragmented even within the financial crime arena.

On top of that, fraud defense systems are not designed to detect the cyberattack component of cyber-enabled financial crime. They typically are not capable of detecting the crimes until the cyberattacks have already compromised the institutions and perpetrators are seeking to monetize the data they acquired or launder the funds they illegally obtained.

What drives cybercrime defense into isolation

Meanwhile, in the cybercrime defense arena, the complexity involved in detecting the financial crime component of cyber-enabled financial crime is far more sophisticated than what is typically involved in traditional cybersecurity. Cybersecurity systems are vulnerable when falsified identities rather than cyberattack methods are used to breach defenses, such as in the 2015 IRS breach of its Get Transcript application that was used to obtain sensitive information of hundreds of thousands of U.S. taxpayers.

In contrast to financial crime defense, cybersecurity systems are not nearly as adept in detecting suspicious patterns of activity from various sources as fraud detection systems are. They, thus, are less likely to take swift action on patterns that, while not necessarily immediately compromising the system, nevertheless represent activity that could damage the institution.

The human factor that drives isolation

Add to that the human tendency to compartmentalize. When faced with regulations that treat different types of threats in isolation, the tendency is to keep them isolated. When dealing with hierarchies that are already separate, the tendency is to maintain the status quo. When dealing with increasing complexity in the types of threats, the tendency is to not add even more complexity by trying to navigate a solution that would require a shakeup of existing structures and systems.

The knee-jerk reaction, then, to the growing complexity – and merging – of both kinds of attacks is to continue investing in each defense function separately – hire more people, invest in more technology solutions – without seeing the many synergies between the different functions. For example, I know a bank that has over 20 different financial crime teams and more than 40 different analytics tools and teams supporting them, all doing the same thing – analyzing transactions and other data to detect malicious behavior – with only slightly different goals.

The evolution of cybersecurity

In the past, our cybersecurity approaches focused primarily on the first few steps of the cyberattack life cycle – preventing attackers from gaining access to our systems. We – cybersecurity practitioners – hardened our systems, installed antivirus solutions, patched software vulnerabilities and blocked blacklisted IPs and URLs. Cybersecurity used to be focused on perimeter security.

We found that merely protecting the perimeter wasn’t enough, though. We also encountered internal malicious activities on our networks. So, we started gathering insights from our networks, servers and endpoints. We started collecting logs and network flows and increasingly focused on analyzing those to detect anything suspicious.

Over time, though, cybercriminals devised many ways to circumvent traditional perimeter-focused security measures, as well as our initial attempts at using analytics to detect malicious activities. And those criminals became very successful at it. They distribute their attacks across many IPs. They act slowly and patiently to avoid triggering alarms. They take the time and effort to mimic normal transactions.

As a result, they often appear as a regular employee to initial defense systems and successfully maintain access to victims’ systems without detection for long periods of time. A 2016 report on security breaches shows that the median time before companies discover attackers in their networks is 146 days globally, and a startling 520 days in the Asia-Pacific region.

With cybercriminals so good at mimicking regular insiders, we started monitoring more and more of the whole technology stack, looking for changes to files and systems that might indicate something suspicious. We increasingly correlated all that information. Instead of just checking whether a user has logged in with the right password, we started verifying whether the user has also logged in from a regular device and IP.

We started applying analytics on even more data. Improved solutions allowed us to check whether a user logged in at regular times, from which location, how much data they uploaded or downloaded and whether their actions deviated from their usual activity pattern.

We check whether the user’s recent login location and time matches their previous one. If it doesn’t, our system can tell us whether it is even realistic that the user traveled the distance between the two locations in the time between the two logins.

We automatically check the user’s behavior pattern is usual for their business group or demographic peers. We use advanced analytics approaches to establish behavioral baselines and patterns, and employ UEBA – User and Entity Behavior Analytics – to build statistical models that alert us if a device or a user tries to execute an action that statistically deviates from their pattern or the pattern of their business or peer groups.

In addition, we even have solutions that monitor internal user communication (e.g., emails or phone calls) and perform sentiment analysis to help identify disgruntled employees.

By collecting threat intelligence information, we better understand cyber attacker modus operandi and build those illicit behavior patterns into our detection system to improve our chances of detection.

In short, we found, that cybersecurity in today’s threat environment requires far more than the perimeter protection that was our original focus. We found, by analyzing system logs and networks over time, that it also requires using advanced analytics across as much data as possible, spanning everything from device data to user business transactions to the context in which users execute transactions, and supplementing that with threat intelligence.

The evolution of financial crime detection

Meanwhile, in the Counter-Financial Crime space, we took a slightly different approach. Initial analytics solutions there monitored financial transactions to detect fraudulent activity. We looked at how fraudsters, money launderers and terrorist financiers behave and built rules into our analytics solutions to help us detect those patterns of illicit activities. For example, if a new customer tried to transfer a large amount of money to countries flagged for terrorism support or to offshore tax havens, we received an alert.

Our financial crime/fraud detection solutions kept getting smarter. In financial crime, we started looking at the time and location from which transactions initiated. We started automatically checking whether travel time between two different ATM withdrawals was realistic. We started learning more about our customers, as well as parties they interact with in financial transactions, and started building patterns of behavior and using statistical models to detect anomalous behavior.

We realized our analytics could become even better if we knew more about the devices our consumers use. If we see the same device try to execute numerous online payments with numerous different credit cards, we should investigate. The same device used to apply for different cards or loans under different names also indicates something suspicious. So, we started building patterns of behaviors for devices as well as users.

We then went further down into technology stack. Some fraud detection solutions monitored device behavior even when the device was not connected to financial institution. For example, if a device visited a website known for distributing malware, the next time that user connected to online banking, the institution received an alert that the device might be at risk (although without identifying the specific site visited).

A growing confluence

Thus, even as cybersecurity and financial crime defense systems remain independent of each other, the best practices that each uses increasingly move toward the initial approaches of the other.

Cybersecurity started from monitoring technology systems and comparing activity on them to known cyberattack methods. We then combined that over time with advanced analytics about users, their business groups, and transactions, moving up the technology stack as an additional way to detect malicious activity from user behavior.

In the financial crime/fraud space, we traveled in the opposite direction. We started from analyzing user behavior and comparing it to behaviors common to financial crime efforts. We then combined that over time with information coming from technology, moving down the technology stack as an additional way to detect financial crime attempts by analyzing user and device interaction with financial systems.

Thus, cybersecurity detection solutions and financial crime detection solutions, which were completely separate in the past, increasingly overlap today.

Taking steps toward combining the silos

The first step toward combining the silos could be to look at the technology. When financial institutions decide to refresh their technology, they could seek a single set of solutions to use for both cybercrime and financial crime detection as a single, unified team. Even if combining the teams is not immediately feasible, working to improve communication between separate teams and separate solutions would still help the institution better combat what remains a unified threat. With more comprehensive data flowing between teams, more threats could be detected.

Many banks currently check the location of ATM withdrawals. If a user makes one withdrawal in Hong Kong and another one an hour later in Moscow, most systems flag the withdrawals because of the impossibility of a user traveling that distance in an hour.

With more comprehensive data available, this safeguard could be extended across all channels. For example, if a user logs in to online banking from Hong Kong and then tries to make an ATM withdrawal in Moscow one hour later, the financial institution should similarly be alerted. Surprisingly, though, because of lack of communication between teams in most banks, very few today do even these kinds of simple checks across the two payments channels. Let alone correlating data across all the channels and all potential data sources.

Thankfully, this is beginning to change. Some more advanced financial institutions started combining those different detection teams under one organization and a single executive to benefit from the detection across the silos. Increasingly, financial institutions are also building cyber-fusion centers – a single place in which all different detection solutions are brought together and monitored by a combined team.

Wrap-up

The environment in which the war against financial crime and cybercrime is fought continues to change, and the ways we fight it must continue to change, as well, for financial institutions to stay ahead. Regulations need to reflect this new reality, and the separate forces defending separate towers in the battlements against this frequently merged enemy need to recognize the common cause they fight and the benefits of working together.

Financial crime teams and cybersecurity teams each have unique skills and tools that, used jointly, can protect their institutions more effectively. The more these teams work together, the better they can identify and frustrate the efforts of criminal elements that seek to compromise their institutions.

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 Financial Crime and Cybersecurity Need to Team up appeared first on Cryptosec.