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.

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

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

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

Let’s go through this in order.

How the BSC Token Hub was Hacked

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

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

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

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

How the Binance Bridge Hack was Stopped

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

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

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

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

It all comes back to decentralization.

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

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

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

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

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

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

The post How the Big Binance Bridge Hack Will Change the way People View Web3 appeared first on Cryptosec.

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

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

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

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

How the Attack was Executed

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

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

That’s exactly what happened.

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

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

Timeline of the Beanstalk Farms Hack

April 16, 2022:

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

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

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

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

April 17, 2022:

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

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

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

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

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

April 18, 2022:

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

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

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

The post How a $1B Flash Loan Led to the $182M Beanstalk Farms Exploit appeared first on Cryptosec.

Decentralization is a hot-button topic in 2022.

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

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

The Nomad Bridge Hack Timeline

August 1, 2022:

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

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

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

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

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

Needless to say, pandemonium ensued.

Aug 2, 2022:

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

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

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

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

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

Aug 3, 2022:

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

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

Aug 4, 2022:

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

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

Aug 5, 2022:

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

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

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

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

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

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

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

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

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

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

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

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

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

The post How the Nomad Bridge Hack can Help Us Explore the Potential Downsides of Decentralization appeared first on Cryptosec.

Dubbed “Mr. White Hat” by the Poly Network security team, the anonymous perpetrator of the biggest crypto hack to date gave all the stolen crypto assets back within 15 days of the incident.

But how was the Poly Network hack carried out? Why did they return the funds? And how did they manage to remain anonymous? We’ll explore these questions, but first…

What is the Poly Network?

The Poly Network is a DeFi platform that enhances blockchain interoperability by enabling users to transfer information and cryptocurrencies between various blockchains. Using the Poly Chain consortium blockchain as its framework, the Poly Network deploys a series of smart contracts to establish bridges between Bitcoin, Ethereum, BNB Smart Chain, and more than 20 other blockchains.

In simplified terms, Poly Network lets blockchains talk to each other using smart contracts.

How the Poly Network Hack Happened

A comprehensive Poly Network hack technical report by Kraken Security Labs less than 2 months after the incident revealed the mechanics of the attack. Through a series of data manipulation techniques in the high-level code of the Ethereum smart contract, the attacker was able to grant himself the necessary permissions to transfer all Poly Network funds on the Ethereum blockchain into his own wallet, which included 2,528 ETH valued at $267M at the time.

The same method was used to extract 6,610 BNB valued at $252M to the attacker’s BNB Smart Chain wallet, and again it was used to transfer roughly $85M worth of USDC into the attacker’s wallet on the Polygon network.

The stolen assets also included several million dollars worth of Shiba Inu, DAI, USDT, and BUSD, for a grand total of around $611M at the time of the attack and making the Poly Network hack the biggest crypto hack as of October 2022.

The Axie Infinity Ronin Bridge Attack wasn’t the biggest crypto hack of all time.

Why did they Return the Funds?

Oftentimes “white hat” security experts will reveal vulnerabilities in networks by exploiting them first and answering questions later. This is how they ensure they’ll get paid for finding the bug, but it’s also risky because they could technically be breaking various laws. In the case of the Poly Network hack, countless international finance and cybercrime laws were broken, so it was imperative that the attacker remained anonymous.

In short, the Poly Network hack attackers claim it was done with the intention of returning the funds the whole time. The attacker said:

“You don’t know me. Money means little to me, some people are paid to hack, I would rather pay for the fun. I am considering taking the bounty as a bonus for public hackers if they can hack the Poly Network. (They can win double if they feel the current plan is awkward).

If the Poly don’t give the imaginary bounty, as everybody expects, I have well enough budget to let the show go on. Just some funny thoughts but I may probably make them come true. If you are still confused, ask some richer friends, what is money for? I trust some of their code, I would praise the overall design of the project, but I never trust the whole poly team. My only guilt was triggered from the refugees.

All of my actions were determined since I made the final decision to be eternal. I am a little bit surprised that you call them professional negotiators, just look at their tense and repetitive words. If the Poly really got my initial idea, they could be less embarrassed. I published their request so that they got the chance to be a winner. Who do you think is dominating the game?”

However, many in the cybersecurity community are skeptical of this claim, especially in light of the fact that the hacker started moving the funds around between various smart contracts and wallets immediately after the incident.

In a series of messages left by the hacker via Ethereum transaction notes, they said they had done the attack for fun, and also asked “I know it hurts when people are attacked, but shouldn’t they learn something from those hacks?”

It’s worth noting that the Poly Network hack hacker was only able to return $340M worth of crypto initially, as the rest was frozen by Tether and other blockchain security firms, or locked in DeFi contracts, and the total amount was finally moved back into the Poly Network’s possession on Aug 25, 15 days after the attack.

Blockchain-based security firm SlowMist also announced hours after the attack that they had identified the attacker’s email, IP address, and device fingerprints. This all drew speculation that they only decided to return the funds once they realized how difficult it would be to launder them.

The bug bounty offered to “Mr. White Hat” by Poly Network was a $500,000 reward, plus an offer to become their chief security advisor. It’s still unknown if they took the position. Poly Network also stated that it has no intention of holding Mr. White Hat legally responsible.

How the Poly Network Hack Attacker Managed to Remain Anonymous

While SlowMist did say they had identified the attacker’s email, IP address, and device fingerprint, a sophisticated hacker knows how to mask those properties and shield their true identity. It’s unlikely that any of these identifiers would reveal the precise location or true identity of the attacker. However, the smartest thing the attacker did was not try to reach any cashout points or make any withdrawals of the funds, because that’s the point at which digital identities collide with reality.

The attacker was able to remain anonymous by letting their pseudonymous digital identity be found, but never revealing any personal information through it. They would not have been able to cash out the funds without revealing their true identity.

This is yet another lesson taught to us by “Mr. White Hat”, which is that despite the headlines about massive smart contract exploits like this one, cryptocurrencies aren’t as private or as easily laundered as people think.

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 Poly Network Hack – How Crypto’s Biggest Hacker was Found but Never Identified appeared first on Cryptosec.

In order to understand the $160M Wintermute hack, we first need to understand algorithmic market makers and how they work in DeFi (decentralized finance), since that’s what Wintermute is.

Imagine you’re the developer of a crypto project and you expect to get your token listed on a large exchange, even a top 10 such as Kraken or Binance. It sounds great, but now you have a new problem because you’ll need to constantly ensure the exchange always has enough liquidity to maintain trading, especially in DeFi markets where liquidity is a primary target for exploiters to attempt malicious activities and try to drain the funds. It would be great if you could deploy an algorithm to perform this constant liquidity observation and management for you – that’s essentially what an algorithmic market maker does.

Wintermute offers this service on both centralized and decentralized exchanges, among other services such as OTC trading and early-stage start up investments. They incentivize users to provide liquidity into their protocol, and then their protocol manages the markets and liquidity pools across the project’s various partners’ and clients’ exchanges. Wintermute solves two of the tallest hurdles for projects in crypto – lack of liquidity and inefficient markets.

This is the full story behind the Wintermute hack of 2022.

$160M Wintermute Hack Timeline

September 15, 2022:

The 1inch Network finds a vulnerability in an Ethereum vanity address tool called Profanity. They publish a technical breakdown of the bug and how it could potentially be exploited if not patched, adding a notice that states “Your money is NOT SAFU if your wallet address was generated with the Profanity tool. Transfer all of your assets to a different wallet ASAP! Moreover, if you used Profanity to get a vanity smart contract address, make sure to change the owners of that smart contract.”

This is relevant to the Wintermute hack because Wintermute had generated a vanity wallet with Profanity and it was an admin to their vault, which means it could execute withdrawals.

September 20, 2022:

This transaction initiates the attack at 05:11 UTC, calling Wintermute’s vault contract to transfer various amounts of several different cryptocurrencies into the hacker’s contract.

The assets include:

• 6,919 wrapped Ether (WETH), valued around $9,410,159
• 10,895,735 Dai Stablecoin (DAI), valued at $10,895,735
• 61,350,986 USD Coin (USDC), valued at $61,350,986
• 29,461,553 Tether (USDT), valued at $29,461,553
• 3,246,604 TrueUSD (TUSD), valued at $3,246,604
• 9,470,755 Binance USD (BUSD), valued at $9,470,755
• 3,250,807 Pax Dollar (USPD), valued at $3,250,807
• 671.247 Wrapped BTC (WBTC), valued around $14,341,194
• And various amounts of 62 other altcoins, almost all with values under $1M

How the Wintermute Hack was Executed

Polygon’s Chief Information Security Officer, Mudit Gupta, published this post-mortem on September 20th, correctly identifying the Profanity-built hot wallet as the attack vector.

While the Wintermute team had clearly been aware of the Profanity vulnerability, evidenced by the fact that they transferred all the ETH from the compromised hot wallet shortly after 1inch exposed it, they had simply forgotten to revoke admin permissions that the wallet had pertaining to Wintermute’s vault.

Through the Profanity vulnerability, the attacker was able to access the hot wallet with admin permissions and simply ask the vault to send them $160M worth of tokens.

While the Wintermute hack 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.

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 Famous $160M Wintermute Hack: Inside Job or Profanity Bug? appeared first on Cryptosec.