Preparing for the Cyber Risks of Tax Season

With the beginning of 2021 comes the start of 2020 tax season as well. While some people may wait until the middle of April to prepare their tax returns, cybercriminals are already gearing up to start targeting this sensitive data. Securing your tax data requires an understanding of the potential threats and best practices for protecting it.

The Value of Tax Return Data

Tax returns provide a wealth of valuable information for a cybercriminal. Obviously, access to a tax return from a previous year makes it possible to perform tax fraud for the current year. However, tax returns also contain a wealth of other data that can be used for fraudulent purposes, such as:

• Personal Data: A tax return contains your full name, address, social security number (SSN), and similar personal data. This information is enough to perform tax fraud or to open up a credit card or bank account.

• Spouse and Dependents: As part of filing joint taxes or claiming dependents, it is necessary to provide similar data for them as well. This potentially exposes them to the same tax and financial fraud. Additionally, this information can be used for spear phishing attacks or to try to guess your login passwords for online accounts (which hopefully aren’t based on kids’ names, birthdays, etc….)

• Financial Data: A tax return provides an in-depth look at your current financial status. This information could be used to inform ransomware attacks (how much are you able to pay in ransom?) or to help identify the banks that you use so that “you” can call after “forgetting” your password. Many of the answers to your security questions are also included in the return.

• Charitable Donations: Your tax returns may include information regarding charitable donations that you have made this year. This information may be used to impersonate you when communicating and scamming a charity.

The information contained within a tax return is highly sensitive and can be misused in a number of different ways. It is vital to ensure that this data is properly protected against unauthorized access and exposure to cybercriminals.

How Cybercriminals Get Your Tax Returns

The data contained within a tax return is extremely valuable to a cybercriminal. For this reason, they are willing to put in the effort to steal it using a variety of different techniques:

• Phishing Emails: Phishing is the most common type of cyberattack, and it works well for this type of scam. If a phisher impersonating the IRS, your bank, or a similar institution can convince you to hand over login credentials or a copy of your return, then the attacker has everything that they need.

• Vishing: Voice phishing or “vishing” is phishing over the phone. The same techniques apply here as well (and over social media, in person, etc.). The attacker will pretend to be someone in authority and try to talk you into providing sensitive data.

• Malware: Some forms of malware are specifically designed to search for and steal financial data from a computer. These malware can look for copies of tax returns on your computer and send the entire return or extracted high-value data to the attacker.

Anyone who contacts you and tries to get you to provide information about your tax return over the phone. Always verify the authenticity of a request by contacting the alleged requestor through official channels such as the email or phone number listed on an official site (like irs.gov).

Protecting Your Personal Data

Tax season is one of the times of highest activity for cybercriminals and scammers. To keep your data safe, take the following simple steps:

• Watch Out for Scammers: Social engineering (including phishing, vishing, and more) is a common way to steal tax return data. Always verify requests before providing any information.

• Use an Antivirus (AV): A malware infection can allow a cybercriminal to steal your personal data or cause other damage to your computer. Keep your AV up to date and run it regularly to help detect and remove malware from your computer.

• Use a File Encryption Solution: Files stored unencrypted on your computer can be stolen by malware and other means. A file encryption solution like GhostVolt ensures that an attacker can’t use the data in your tax return even if they steal the file.

How Your Passwords End Up for Sale on the Dark Web

Credential stuffing and similar attacks are made possible by cybercriminals with access to large lists of common and breached passwords. But how do these cybercriminals get these lists of passwords to try? Two of the main methods are via phishing attacks and data breaches.

Phishing Attacks

Phishing attacks are the easiest way for cybercriminals to gain access to account credentials. If a phishing page tricks you into entering your username and password, then these credentials are sent straight to the attacker. They can then add them to a list of credentials for sale on the Dark Web or keep them for their own personal use.

Inside a Data Breach

Data breaches have become a fact of daily life. In the US alone, 1,473 data breaches were reported in 2019. This averages to 4 breaches and over 450,000 breached records per day.

In many of these breaches, passwords are listed as part of the exposed data. However, most organizations don’t store their users’ passwords. This would make it far too easy for an attacker or a malicious insider to steal the master password file and use it to gain illegitimate access to user accounts.

Instead, when data breaches talk about passwords being breached, they are actually talking about leaked password hashes. Hash functions are cryptographic operations with a few useful properties:

• One-Way Function: It is impossible to calculate the input to a hash function from the corresponding output.

• Collision-Resistance: It is very difficult to find two inputs that produce the same output.

• Deterministic: Hashing the same input always produces the same output.

These properties make hashes an ideal way to store password data. Instead of storing a list of passwords (which can be abused), a list of hashes is stored instead. When verifying users, if the hash of the password that they provide matches the one on file, then they are likely to have provided the correct password. However, if the password hashes are leaked, then an attacker still doesn’t have the original password.

From Password Hashes to Breached Passwords

If password hashes are so secure, then how do data breaches lead to passwords being offered for sale on the Dark Web? This mainly happens when someone has made a mistake.

The less common reason for this is that the breached service is not storing passwords securely. If passwords are not appropriately hashed or are using a broken hash algorithm (like MD5 or SHA1), then an attacker may be able to break the hash and determine the user’s credentials. This isn’t the most common reason that passwords get broken, but it does happen.

More commonly, the fault is on the side of the user. An attacker can take a “guess and check” approach to breaking passwords by hashing potential passwords and comparing them to breached password hashes. If the hashes match, then the attacker has found the right password.

This is what makes the use of weak and reused passwords so dangerous. If a password is easily guessable (based off of a word, pattern, etc.), then password cracking tools will easily be able to identify it in a list of breached password hashes. Once this occurs, the attacker is able to sell the breached password rather than just the hash.

How The Good Guys Are Fighting Back

Most people don’t know when they’ve been the victim of a data breach. For this reason, many online services have incorporated breach notifications. This means that, if you try to log into an account that has been breached or using a breached password, the service will notify you and help you reset the password. In most cases, these breach notifications are driven by HaveIBeenPwned, a site that collates this data and allows people to determine if their data has been breached.

These services work because they use the same tools and techniques as malicious attackers. Cybersecurity researchers search the Dark Web for lists of credentials that have been publicly posted or offered for sale. Any password hashes that they collected can then be subjected to password cracking to determine whether or not they are likely to be broken by attackers. This is where the lists of the “most commonly used passwords” come from.

Applications like GhostVolt also use HaveIBeenPwned to help protect people from reusing breached passwords. When setting a password on GhostVolt, the password is automatically checked against HaveIBeenPwned’s list of breached passwords. If a match is found, GhostVolt will not allow the use of this weak password. While this may seem inconvenient, it is essential to protecting the security of your GhostVolt account.

Protecting Your Online Accounts

If you are notified about a breach of one of your online accounts, it is vital to change the affected password immediately. However, this may be too little too late since a breached account means that attackers already may have access to your account.

Being proactive about password security is a much better idea. Instead of waiting for passwords to be breached, replace any weak and reused passwords with unique, strong ones and store them in a password manager. This dramatically decreases the risk of cybercriminals compromising your account if an online service is breached and password hashes are leaked.

The Problem with Cloud Storage for Secure File Sharing

In the modern business, the ability to quickly and easily share documents and other files throughout the business is essential. Everyone works in teams, and sharing documents via email or shared file servers is inefficient.

Cloud-based document sharing services, like Dropbox and Google Drive, offer a tempting alternative to traditional methods of document sharing. Tools like Google Docs enable an entire team to edit a document in parallel and track the complete revision history of the document, making it easy to attribute and revert edits.

However, these cloud-based document sharing services also have their downsides. Employees using these services have to make a choice between efficiency and security, and many choose efficiency. As a result, a number of organizations have suffered data breaches caused by employee negligence in configuring and securing cloud-based services.

Security Challenges of Cloud-Based File Sharing

Cloud Service Providers (CSPs) provide built-in security configuration settings for their environments. While the details vary from CSP to CSP, many of them operate on a simple private/public access model.

A private cloud, as the name suggests, is private. In order to access the cloud-based resource, an employee needs to be explicitly invited to access the resource. On Google Drive, for example, this invitation comes in the form of the document owner (or other administrator) sending a sharing link to the person’s email address.

While this system is effective at securing access to the cloud-based resource, it also creates significant overhead for the document administrators. They must explicitly invite every user of the cloud-based resource and manually revoke permissions if access is abused. While Google Docs keeps an edit history, making it possible to detect such abuse, the document administrator would have to manually review this for anything suspicious.

The overhead associated with properly securing cloud-based resources drives many users to go to the opposite extreme. By marking the cloud-based resource as public, the employee can share access to the document simply by sharing the URL of the document with the desired recipient.

The primary benefit of this system is that anyone with access to the link has access to the resource, making it easy to invite new users. The primary downside of this system is that anyone with access to the link has access to the resource, making it easy for unauthorized users to discover and access the document.

Many people incorrectly believe that it is difficult to find the URL of a cloud-based resource if you are not an authorized user of the resource. Even ignoring the possible cases where an authorized user forwards the link to an unauthorized use, cloud URLs are relatively easy to discover. Hacking tools exist specifically for scanning the space of possible cloud URLs (they have a set scheme), checking if a given URL is valid, and checking if it is public. In fact, most known cloud data breaches were discovered in this way. An ethical hacker using these tools identified an unsecured cloud resource and notified the owner.

Beyond the access control issues associated with cloud resources set to “public,” there are also attribution issues. For example, Google Drive maintains a complete edit history for a document, making it possible to determine if a user has made unauthorized edits. However, knowing that “Anonymous Panda” was the one at fault doesn’t help much. Additionally, Google Drive doesn’t track access by anonymous users, so only those trying to modify the data (instead of just stealing it) would be detected.

Secure Document Sharing with GhostVolt

Cloud-based document storage, like Google Drive, has made significant strides toward making it possible to efficiently and effectively share documents within a team. However, these systems also have a ways to go.

However, more effective solutions for secure document sharing are available. GhostVolt Business takes the basic services that Google Drive (and similar services) provide and takes them a lot further.

Encryption of all files by default, whether on a user’s personal machine or in the cloud, with AES-256 ensures the security of business data. Access to these documents can be managed by defining specific user roles and managing permissions to files based off of these roles. This makes it easy to map a user’s access to documents within the organization to their job responsibilities.

However, where GhostVolt really stands out is in the visibility that it provides regarding shared documents. All user activity is logged, and GhostVolt has built-in reporting functionality to summarize raw data into readable reports. This, combined with Ghostvolt’s strong access controls, make it easy to maintain and demonstrate compliance with a wide (and growing) range of data protection regulations, such as the EU’s General Data Protection Regulation (GDPR), the Payment Card Industry Data Security Standard (PCI DSS), and HIPAA, SOX, CCPA, and more in the US.

The Importance of Secure Document Sharing

As more regulations like GDPR and CCPA come into effect, organizations are required to strongly protect the data in their possession and to be able to demonstrate that these security controls are in place. On the other hand, the ability to quickly share data throughout the organization is essential to enabling the organization to operate efficiently.

A secure document sharing solution, with built-in encryption and strong role-based access control, is essential to maintaining regulatory compliance. However, it also needs to be intuitive and efficient to use to meet core business needs. When choosing a document sharing solution, an organization should not need to compromise on security, usability, and performance.

The Hidden Costs of a Data Breach

The Growing Threat of Breaches

Companies are collecting and storing ever-increasing amounts of customer’s personal data. While some organizations are doing so to perform mass-scale data mining, the average business is collecting data simply to perform their core business practices. It’s pretty difficult to keep track of a user’s account without an email address or send a parcel without a shipping address.

Unfortunately, the troves of sensitive data that companies are collecting are a major target for hackers. An individual’s personal data can be used for a variety of malicious purposes (identity theft, spear phishing, and blackmail to name a few), so this information can fetch a pretty good price on the black market. The collections of sensitive data held by businesses are a treasure trove to any hacker who can access them.

As a result, data breaches are becoming increasingly common. In 2018, 5 billion records (or individual customers’ data collected by a business) were stolen by hackers. Since the cost of a data breach to the organization is often proportional to the number of records stolen, the impact of these breaches on the global economy is significant.

Hidden Costs of Data Breaches

Data breaches are expensive for the attacked organization. Some costs are directly related to managing the impacts of the breach (investigating the incident, paying fines, etc.), while some are more indirect. In 2019, a data breach costs a company an average of $8.19 million. These costs are spread over a variety of different impacts.

Investigation and Remediation

After a data breach has occurred, the organization needs to perform an investigation to determine the scope of the breach and remove any traces of the attacker from the network. This can be a complicated and expensive proposition since:

1. Many organizations don’t have the expertise in-house to investigate.

2. Attackers cover their tracks to make investigation more difficult.

Once the incident investigation has been completed, the organization needs to pay the costs of remediation. This not only includes the price of implementing all of the cybersecurity protections that were lacking in the first place (allowing the breach to occur) but also the price of fixing any damage caused by the attacker while they had access to the system. The need to perform these investigations and mitigations quickly can also add to the price tag.

Reputational Damage

One of the hardest costs of a breach to quantify is the damage to an organization’s reputation after a breach. Their customers have trusted them to properly protect the sensitive data entrusted to them and the organization has failed to do so. After a breach, an organization has to endure numerous news reports and articles dissecting what they did wrong and how their security processes were inadequate.

A great example of the impact of reputational damage to a company due to a breach is the general feelings of the American public towards Equifax. The Equifax breach was over a year ago, yet people are still annoyed with the company. The Equifax breach may be an extreme case since no-one gave their data directly to Equifax (so they’re not happy with it being lost) and the breach was caused by gross negligence by the company (failure to patch a vulnerability that was being actively exploited for months before the breach), but the current ill feelings toward the company demonstrate how an organization’s reputation can suffer after a breach.

Compliance Reporting and Penalties

In recent years, governments have been increasingly focused on protecting the personal data of their constituents. The EU’s General Data Protection Regulation (GDPR) is the most famous of these, but a variety of different nations and states have passed data privacy regulations to protect their citizens. These new regulations and standards are in addition to those already in effect, including PCI DSS, HIPAA, FISMA, SOX, and others.

As a result, the average organization may be required to achieve, maintain, and demonstrate compliance with several different regulations. In the event of a breach, this involves determining if the breach is reportable, whom to report it to, and how the report needs to be performed. Once a report is filed, the organization needs to cooperate with regulators and may be fined for negligence as a result of the breach. The manpower and fines associated with this can dramatically increase the cost of a breach. British Airways was fined $230 million by GDPR regulators for a 2018 data breach.

Notification and Compensations

After a data breach has occurred, the breach organization may be compelled to notify affected parties and provide compensation. While commonly these notifications are performed by email and have minimal cost to the organization, determining who needs to be notified can require significant effort.

Compensation costs can also be significant to an organization. Commonly breached businesses offer identity monitoring, but it is not uncommon for affected parties to file lawsuits against the organization for damages. The costs of litigation, settling, and/or any damages can be a significant cost to the organization.

Loss of Future Revenue

The impacts of a breach in terms of lost future revenue are difficult to determine. Multiple surveys have found that as many as 70% of customers will stop buying from a company after a breach. However, the fact that the #deletefacebook movement fizzled despite all of the missteps that Facebook has made regarding properly using and protecting customer data demonstrates that this may not be the case. If customers have no viable alternative, they may stick with a breached company, but many organizations will see a drop off in sales after reporting a breach.

Protecting Against a Breach

The simplest way to prevent data breaches is to ensure that the organization’s defenses are never breached by a hacker. However, this expectation is unrealistic. Every company is likely to suffer at least one successful cyberattack, and most companies will be the victim of several.

Protecting against data breaches requires ensuring that, even if a hacker can breach the organization’s defenses, that they can’t steal any valuable data. The best way to accomplish this is by encrypting data at rest.

Inside the Encryption Backdoor Debate

Encryption technology is designed to protect sensitive data from unauthorized access.  Communications applications with end-to-end encryption, like Telegram or Signal, are designed to ensure that an eavesdropper who intercepts the traffic en route doesn’t have the capability to read it.

Increasingly, government officials have been calling for backdoors to be built into all encryption algorithms.  The most famous and vocal proponent of it is the US Attorney General, William Barr; however, a meeting of representatives from Five Eyes countries (Australia, Canada, New Zealand, UK, and US) recently expressed support for the proposal. 

Despite the security concerns associated with it, encryption backdoors are required in some countries.  In December 2018, Australia ignored the advice of security and encryption experts and passed a law mandating backdoors in all encryption.

The Call for Backdoors

The argument for encryption backdoors essentially boils down to one of law enforcement.  Encryption is designed to keep all eavesdroppers out of a private conversation, including the police.  Encryption backdoor supporters, like Barr, believe that this ability to “go dark” has been causing an increase in unsolved criminal investigations.

As a result, enterprises may be required to install backdoors in encryption algorithm, regardless of the damage to personal privacy.  Barr has expressed the opinion that the general public doesn’t really need strong encryption since they’re only protecting personal emails and selfies and not the nuclear launch codes.

The problem with Barr’s justification for breaking encryption is that crime rates aren’t rising.  In fact, they’ve been steadily dropping since 1993.  While encryption denies law enforcement access to some forms of evidence, they still have all of the investigative techniques that existed before the rise of computers, and these techniques have consistently proven to be effective.

Backdoored Cryptography: Data Encryption Standard

This isn’t the first time that the US government has tried to weaken encryption for the purposes of law enforcement and/or national security.  In the past, the National Security Agency (NSA) was even successful in weakening one encryption algorithm: the Data Encryption Standard.

In 1973 and 1974, the National Board of Standards, the forerunner of the current National Institute of Standards and Technology (NIST), issued calls for an encryption algorithm that would become the official Data Encryption Standard of the US government.  One submission, developed by IBM, was eventually selected as the winner of the contest.

As part of the review process, the NSA had the ability to review and make suggestions regarding the encryption algorithm.  In the end, they made two major modifications that changed the substitution boxes (S-Boxes) used by the cipher and the key length.

The NSA’s change to DES’s S-Boxes was actually intended to improve the security of the cipher.  At the time, only the NSA knew about a particular method of cryptanalysis, called linear cryptanalysis.  The original S-Boxes of the proposed algorithm were vulnerable to this attack, and the NSA’s modifications corrected this.

The other main change that the NSA made to the cipher was a change to the length of the secret key from 64 to 56 bits (though the NSA wanted 48-bit keys).  This made the encryption keys 256 times weaker than the original cipher and led to its being broken in 1999. The original DES submission would have remained secure for a longer time.

The Challenge of “Secure” Backdoors

The main challenge with backdoors in encryption algorithms is that no-one knows how to do them in a secure way.  In his calls for encryption backdoors, Barr pointed to three previous proposals for accomplishing it:

1. Allowing law enforcement to silently enter as a participant in a conversation

2. A hardware chip in phones that stores encryption keys that only law enforcement can access

3. A multi-layer encryption algorithm that allows law enforcement access to the underlying data

These proposals are nothing new.  The first option has been tried in the past with unfortunate results since it is difficult to ensure that only law enforcement has access to a backdoor.  The problem with the other two options is that they seem like a good idea, but no-one knows how to implement them in a secure fashion.

The Bottom Line

The encryption backdoor debate is troubling since it involves lawmakers deliberately ignoring statements from security and cryptography experts that their requests are impossible to implement in a secure fashion.  If the backdoor proponents succeed, individual privacy could take a major hit.

And the crazy thing is that it won’t even work.  The primary difference between apps like Whatsapp and Telegram and messaging apps like Signal is that Whatsapp and Telegram are operated and maintained by companies and Signal is open-source.

This means that, if companies like Facebook and Telegram comply with the law, all of their users will have potential privacy violations.  However, the criminals that the law is designed to address (and who couldn’t care less about the law) will switch to Signal or other open-source apps where the backdoor can be removed from the code before using it.

The encryption backdoor law boils down to limiting people (and criminals) to only using certain apps on their phones and computers.  The number of jailbroken iPhones, rooted Androids, and unlicensed copies of Windows in use demonstrate that this is another problem that device manufacturers don’t know how to solve.

Threat Modeling for the Blockchain

Blockchain technology is an exciting new technology with a great deal of potential. With this potential comes the need to explore the security of this new technology. There has been a great deal of work in this space; however, no comprehensive threat model exists that classifies all potential threats and attack vectors within the blockchain ecosystem. When discussing potential security threats to a system and attempting to analyze whether a system is secure by design, it' is extremely useful to have a framework to use in classifying known attacks and pointing out ones that potentially have been overlooked. In this post, blockchain security threats are mapped to STRIDE, a well-known threat model developed by Microsoft, to create an effective threat model for the blockchain.

STRIDE and the Blockchain

The STRIDE framework was developed by Microsoft to help in threat modeling. Each letter in the STRIDE acronym is designed to refer to one of the most common threats in cybersecurity:

• Spoofing: Spoofing refers to the ability of the attacker to masquerade as another on the system.

• Tampering: Tampering attacks violate the integrity of the data stored on the protected system.

• Repudiation: Repudiation is the ability of a user to deny that they have taken a certain action.

• Information Disclosure: Breaches of confidentiality fall under information disclosure.

• Elevated Privileges: If a user manages to gain unauthorized levels of control over the system, this is a privilege escalation attack.

  • In the context of the blockchain, we can break up elevated privileges based upon whether the attacker has unauthorized access to a user’s account, an elevated level of control over the blockchain system (i.e. in a 51% attack), or unauthorized permissioned access to a smart contract.

The STRIDE framework is useful for defining the potential effects that certain vulnerabilities or attacks can have on the security of a system. However, blockchain systems are a complete environment, including everything from the cryptographic primitives that underpin their security to the smart contracts that extend the functionality of the blockchain system.

In order to have a meaningful discussion about a blockchain threat model, it’s useful to break up the blockchain ecosystem into its various levels. For the purposes of this post, the following breakdown is used:

• Fundamentals: The underlying components used to build the blockchain.

  • Cryptographic Primitives: The hash functions and public key cryptography used to ensure data integrity and provide user authentication.

  • Data Structures: The structure of the blocks used to store transaction data and the hash functions used to chain them together.

• Protocols: The definitions of how blockchain nodes should interact when working to maintain the shared distributed ledger.

  • Consensus:

  • Block Creation:

• Infrastructure: The nodes that work to maintain the distributed ledger and the network that they use to communicate.

  • Nodes: Computers running the blockchain software and maintaining a copy of the distributed ledger.

  • Network: The underlying network that the nodes use to communicate and the protocols that define how communications occur within the blockchain ecosystem.

• Advanced: Many blockchain solutions do not limit themselves to the basic blockchain protocol defined in the Bitcoin whitepaper. These advanced components are an important component of these blockchain’s security and their threat model.

  • Smart Contracts: Smart contracts allow third-party code to be uploaded to and executed on the distributed ledger.

  • Blockchain Extensions: The basic blockchain technology can be extended by systems built either on top of it (state channels, side chains, etc.) or through connections to external systems via APIs.

With the STRIDE threat model and the framework of the blockchain ecosystem, we have what we need to begin threat modeling for the blockchain.

Blockchain Threat Modeling

The blockchain threat model is presented in the table below. Using the STRIDE model and the levels of the blockchain ecosystem, it’s possible to classify each attack vector based upon its potential effects. Each cell shows the different attacks that can be used to affect a given component of the STRIDE model at a level of the blockchain ecosystem. Each attack vector includes mouse-over text that describes how the particular effect can be accomplished by that attack.

		Spoofing Authenticity	Tampering Integrity	Repudiation Non-Repudiation	Information Disclosure Confidentiality	Denial of Service Denial of Service	Elevated Privileges Privilege Escalation
							Account Attack has unauthorized access to blockchain account.	Blockchain Attacker has unauthorized level of control over blockchain.	Smart Contract Attacker has unauthorized access to protected smart contract functionality.
Fundamentals Blockchain is based upon cryptographic primitives and the block and chain data structures.	Cryptographic Primitives Hash functions and public key cryptography are essential to access control and data integrity on the blockchain.	Private Key Compromising a user's private key allows an attacker to generate transactions on their behalf. Phishing Phishing emails can be used to steal private keys, which allows the attacker to masquerade as a legitimate user. Shor's Algorithm Shor's algorithm breaks traditional asymmetric cryptography, allowing an attacker to forge digital signatures on transactions and blocks.	Grover's Algorithm Grover's algorithm decreases the security of hash functions, making it easier for an attacker to find collisions and break blockchain immutability.		Private Key Compromising a user's private key allows an attacker to read any encrypted data meant for them. Shor's Algorithm Shor's algorithm breaks traditional asymmetric cryptography, allowing an attacker to decrypt encrypted messages.		Private Key Compromising a user's private key gives an attacker unauthorized access to their account. Shor's Algorithm Shor's algorithm breaks traditional asymmetric cryptography, allowing an attacker to guess a user's private key and access their account.
	Data Structure Blockchain has defined formats for transactions and blocks. Vulnerabilities in these data structures or how they are processed can impact blockchain security.		Transaction Malleability The hash of a transaction depends upon the transaction's digital signature. This can be regenerated by the original signer, creating an identical transaction with a different hash.
Protocol Blockchain protocols like consensus algorithms and the block creation process codify how the network interacts and maintains a decentralized, distributed ledger.	Consensus The blockchain consensus algorithm defines how the blockchain is updated in a decentralized fashion.		51% A 51% attack allows the attacker to rewrite the history of the blockchain, breaking its integrity. Long-Range In a long-range attack, the attacker generates a conflicting version of a Proof of Stake blockchain and gets it accepted, breaking the integrity of the distributed ledger. Nothing at Stake In a Nothing at Stake attack, a Proof of Stake block forger signs two conflicting versions of the blockchain.	51% In a 51% attack, the attacker rewrites the history of the blockchain, allowing them to deny that past transactions are part of the official ledger. Long-Range In a long-range attack, the attacker rewrites the history of the blockchain, allowing them to deny that past transactions are part of the official ledger.		51% A 51% attacker controls the blockchain and can refuse to add transactions to it, performing a DoS attack against its users. Artificial Difficulty Increases If an attacker suddenly withdraws a large percentage of a Proof of Stake network's mining resources, the block difficulty target is too high for the remaining nodes. Since blocks cannot be found at the desired block rate, this implements a DoS attack. Long-Range A long-range attacker controls the blockchain and can refuse to add transactions to it, performing a DoS attack against its users.		51% A 51% attack gives the attacker control of the distributed ledger. Long-Range A long-range attack gives the attacker control of the distributed ledger. Selfish Mining Selfish mining allows the attacker to create more blocks than their percentage of mining power should allow. This increases their level of control over the distributed ledger. SPV Mining SPV mining allows the attacker to create more blocks than their percentage of mining power should allow. This increases their level of control over the distributed ledger.
	Block Creation The block creation process defines how the selected block creator creates new blocks and ensures their validity.		Frontrunning Blockchains publish transactions to the entire network before adding them to the distributed ledger. An attacker who sees a transaction can create a competing one with a higher transaction fee so that it is processed before the transaction that was created first.			Transaction Flooding By flooding the blockchain network with spam transactions, an attacker uses up the blockchain's capacity, delaying the addition of other blocks to the ledger. Also, any spam transactions that are included in the ledger are retained forever, consuming storage and processing resources on the nodes.		SPV Mining SPV mining allows the attacker to create more blocks than their percentage of mining power should allow. This increases their level of control over the distributed ledger.
Infrastructure Blockchain infrastructure consists of the endpoints running blockchain software and the network that connects them.	Nodes Exploitation of the computers running the blockchain software.	Malware Malware can be used to steal private keys, which allows the attacker to masquerade as a legitimate user.	Malware Malware can be used to perform eclipse and routing attacks. It can also be used to steal private keys, allowing the attacker to create fake transactions on the user's behalf.		Malware Malware can be used to intercept communications or steal private keys, allowing an attacker to view private or permissioned data without authorization.	Failure to Update Failing to update blockchain software could mean that a user does not follow a hard fork and cannot access the blockchain. Malware Malware on a user's computer can impede access to the blockchain at a variety of levels, including filtering or blocking traffic and terminating blockchain processes. This both denies access to them and degrades the efficiency of the blockchain since the user cannot contribute to block creation.		MSP Misconfig A misconfigured Membership Services Provider (MSP) could allow an attacker to grant themselves unauthorized permissions on the blockchain.
	Network The blockchain runs on traditional networking. Attacking this network can impact the security of the blockchain.		Eclipse/Routing Eclipse and routing attacks rely on isolating users, which can be accomplished by attacking the network level. An attacker can perform double-spend against users in different isolated pieces of an eclipsed network. Network Design A poorly designed network can enable an eclipse or routing attack by limiting the number of connections between different groups of users in the network. Overwhelming communication links can also essentially isolate different portions of the network.		Network Design If a private or permissioned blockchain relies on the security of the underlying network to manage access, an attacker may be able to gain visibility by compromising network components (routers, etc.).	Eclipse/Routing Eclipse and routing attacks can be performed at the network level by destroying or filtering communication links. Isolating portions of the network from one another decreases the block rate and causes the shorter chain to be discarded when the network reconnects. Network Design A poorly designed network may not be capable of managing the overhead necessary for a blockchain system, so bandwidth limitations could impact functionality. Physical Attacks An attacker physically severing communication links or tampering with devices (routers, etc.) could cause the functionality of the blockchain solution to be degraded. PoS DoS A Denial of Service attack against the legitimate block creator in a Proof of Stake blockchain means that an opportunity to create a block may be missed. This decreases the efficiency and capacity of the blockchain. MSP DoS A Denial of Service attack against a Membership Services Provider (MSP) may deny legitimate users access to the blockchain system.		Eclipse/Routing An eclipse or routing attack allows an attacker to corrupt a user's view of the blockchain and get them to act in the attacker's interests. This can give the attacker a level of control over the blockchain greater than they should have based on their percentage of the scarce resource (computational power, stake, etc.).
Advanced The basic blockchain protocol has been extended by the creation of smart contract platforms and allowing connections to external software and devices through APIs.	Smart Contracts Smart contracts extend the functionality of the basic blockchain protocol by allowing third-party code to run on the distributed ledger.	Delegatecall Delegatecall allows a smart contract to run in the scope of another smart contract. This can give the attacker unauthorized access to protected functionality within the smart contract.	Arithmetic Integer overflow and underflow vulnerabilities can be exploited to bypass checks on transactions and other protected operations, allowing the attacker to perform unauthorized actions. Bad Randomness Generating strong randomness is difficult in smart contracts, making it possible for attackers to cause smart contracts to take unanticipated actions. Reentrancy Reentrancy vulnerabilities allow malicious smart contracts to force vulnerable ones to take unauthorized actions. Short Addresses Short address vulnerabilities trick vulnerable smart contracts into performing transactions with a greater amount of value than was authorized. Timestamp Dependence Some smart contracts are designed to take action before or after a specific time. Since time on the blockchain is flexible and dependent on block creators, a malicious block creator can force unanticipated behavior. Unchecked Returns In Ethereum, some low-level functions throw an exception and others return false and continue running upon failure. Failing to check return values may cause a smart contract to continue executing after an unexpected failure.			Access Control Some smart contracts have protected kill switches. A failure in controlling access to these functions can allow a DoS attack against these contracts. Out of Gas Ethereum limits the amount of gas that a transaction can use. Forcing a smart contract into a state where it needs more gas than the limit to run can make it incapable of running.			Access Control Poor management of access control within a smart contract can give an attacker elevated privileges within the contract. Delegatecall The use of delegatecall allows a called smart contract to run code with the privileges of the calling smart contract.
	Blockchain Extensions Blockchain extensions build on top of the blockchain protocol (like state channels and side chains) or connect blockchains to external software via APIs.	Insecure APIs Exploitation of external software or hardware with access to a blockchain account may allow an attacker to perform actions masquerading as that account's owner.					Insecure APIs Exploitation of external software or hardware with access to a blockchain account may allow an attacker to gain access to protected functionality available to that account's owner.

This blockchain threat model represents my personal attempt to classify the currently known attack vectors against blockchain systems and is designed to be a constant work in progress as new attack vectors are discovered against blockchain systems. I plan to continue to update and refine this model and would appreciate any comments or input.

The Human Side of Security: Inside RSAC 2019

The annual RSA Conference in San Francisco, which typically draws over 50,000 attendees, and 750 exhibitors, is often seen as a chance for vendors to exhibit their solutions to a wide audience.  As a result, The Expo hall (Moscone Center) can be experienced as an overwhelming array of booths, and at peak times, a downright carnival atmosphere can take hold, complete with barkers promising that their product is the solution to all of your cybersecurity problems.

The real heart of the conference however, can be found in the topical sessions and talks taking place off the exhibitor halls, in the meeting rooms. These sessions tell a different story about the real need for a security conference of this size.  A wide array of different security topics are covered including nextgen technologies (blockchain, etc.), threat intelligence (newly discovered APTs and attack vectors, and the human side of cybersecurity.

The human side of security was a major focus at this year's RSA Conference.  An entire Monday track was devoted to the subject as well as numerous standalone talks, labs, and discussion sections.  Across many of these sessions, a theme and a message could be found: in the end security revolves around the human side of the machine. (The archives can be found here).

Securing Humans is a Challenge...

Cybersecurity practitioners and vendors love technology-focused attack vectors.  If a web application has a buffer overflow vulnerability, it can be detected, investigated, patched, and forgotten.  While attackers are constantly looking for new bugs and vulnerabilities to exploit, they operate completely within an environment that a defender can control, making prevention, mitigation, and remediation possible.

Dealing with the human threat surface is...more complicated.  Organizations spend millions of dollars teaching people not to click that link or open that attachment.  Users know the risks but fall for phishing attacks anyway.

The talks during the Monday session on Security, Privacy, and Human Behavior did a great job of explaining some of the reasons why this happens: security folk tales and economic decision-making.

To be perfectly honest, most cybersecurity awareness training is awful.  You have “death by PowerPoint” possibly with a voice over delivered quarterly at best.  Users don't internalize and relate to this information and it takes second place to what “everyone knows” or “Bob told me…”.  The disconnect between official training and “common knowledge” makes people act in ways not in accordance with best practice.

The other main issue is that good security is often hard, inefficient, and unusable.  The volume of emails that the average person receives means that they have to make a decision in seconds or risk falling behind.  However, “being secure” requires running through a complete checklist of possible threats, never clicking links, and verifying all suspicious attachments.  The commitment in time and decision-making is significant, so users fall into bad habits since the cost of being secure is perceived as higher than that of a potential breach.

We Don't Have It Figured Out Yet...

Unlike most of the exhibits on the Expo floor, there was an element of doom and gloom in the human security talks.  As security practitioners, we understand the problem but we don't know how to solve it.

This is apparent when you ask anyone about their cybersecurity awareness program.  People will be happy to brag about their employee security awareness programs but asking if click rates on unsafe communications have dropped to zero yields a universal answer: No.  Even organizations that tie bonuses to click rates still experience incidents.

A common message in the talks was that completely eliminating the threat of the human element is impossible.  People need to use email, share information, etc. in order to do their jobs.  Even skilled cybersecurity practitioners are fooled sometimes because a phishing email is just that convincing.

The main challenges in the industry are establishing good metrics, setting goals for acceptable levels of risk, and meeting those goals.  This is where the industry seems to suffer since management likes to see easily measurable achievements and most programs are evaluated based upon the percentage of employees that have received the training rather than its ability to protect against real-world threats.

But We Have Some Ideas...

While the problem of improving human security is far from solved, it's not for lack of trying.  Across several different talks, there were commonalities in the methods that demonstrated some successes, including making security awareness training accessible, human-centric, and incentivized.

Making training accessible is designed to close that gap between cybersecurity “common knowledge” and the content provided in awareness training.  Research has demonstrated that humans simply can’t absorb the amount of information provided during traditional cybersecurity awareness training in a single sitting.  Also, many cybersecurity awareness programs use scenarios that are so contrived and unrealistic that making the connection between a real-world threat and the training is impossible.  By redesigning training to be bite-sized and relatable, organizations are making progress in influencing user’s understanding of the cybersecurity threat landscape.

A human-centric approach is extremely powerful for cybersecurity awareness and is demonstrated by the fact that many organizations have cybersecurity “ambassador” programs.  These programs are designed to identify people with an interest in cybersecurity and provide them with the information necessary to help their peers.  This greatly extends the reach of the organization’s security team and creates the capability for just-in-time interventions.

Finally, organizations have made significant progress by incentivizing good cybersecurity behavior.  A survey presented at one of the RSA talks demonstrated that the emotion most commonly associated with cybersecurity is fear, which is bad for making good decisions.  Instead of being known only for punishing users who make cybersecurity blunders, awareness programs have made great strides by rewarding and acknowledging those who do the right thing.

Next Steps for Human-Focused Security

The 2019 RSA Conference seemed to consist of two very different worlds.  On one hand, the vendors at the Expo were full of enthusiasm, demonstrating how their product could help solve an organization’s most pressing cybersecurity problems.  On the other, speakers were discussing the difficulties of developing an effective cybersecurity awareness program and how humans can’t be “fixed” with a simple software solution.

While the human behavior tracks of the RSA Conference didn’t provide a solution to the cybersecurity awareness program, they did have some useful nuggets for organizations attempting to solve the human side of security.  By improving the human side of security and raising the bar for social engineers and phishers, we may be able to force hackers back to focusing on the technology side, where finding solutions to problems is easier.

Mapping the OWASP Top Ten to Blockchain

In my Blockchain Security course, I (unsurprisingly) get a lot of students with a background in cyber security. As a result, I have been asked several times how well the Open Web Application Security Project’s (OWASP) Top Ten list for web application vulnerabilities maps to the blockchain space. In this article, we’ll explore the OWASP Top Ten list and, where possible, point out areas where blockchain technology is potentially or actually vulnerable.

Injection

In an injection attack, an attacker takes advantage of poor sanitization of user input to attack a system. If the software developer did not appropriately handle the user input, it can be crafted in a way that allows it to run unauthorized commands. For example, failing to sanitize SQL input could allow a user to bypass authentication and run unauthorized queries against the database.

Poor input sanitization is definitely a potential issue in blockchain technology. Prior to the launch of the EOS mainnet, researchers at Qihoo 360 reported a vulnerability in the EOS smart contract parsing function that allowed a buffer-out-of-bounds write1. The researchers developed a proof of concept where the vulnerability allowed them to break out of the EOS sandbox and launch a reverse shell on the infected machine. If this vulnerability had been exploited on a running network, it could have allowed the attacker to compromise every node on the network as they ran the malicious smart contract once it was included in a valid block.

Broken Authentication

Broken authentication is a general vulnerability referring to any issues in the implementation of an authentication mechanism in an application. These issues could allow an attacker to masquerade as a legitimate user on a temporary or permanent basis.

Proper implementation of authentication functionality is vital to the proper function of the blockchain system, and the wide use of public key cryptography means that a large attack surface exists.

The LISK cryptocurrency is a good example of where design oversights allowed an attack on authentication in a blockchain. In LISK, a user’s address on the blockchain is achieved by hashing their public key and truncating the result to 64 bits2. This hash and truncation method of generating addresses is common; however, the short length of LISK addresses and the fact that addresses are not immediately tied to public keys makes LISK vulnerable to attack.

Addresses in LISK are only bound to public keys when a user initiates a transaction by either sending value out of the account or voting for a delegate. As a result, many accounts that had only received value were vulnerable to attack. An attacker only has to perform 264 key generation operations to find a private/public keypair that would map to a given address. Targeting any of M addresses decreases the complexity of finding any match by a factor of M. This attack is definitely feasible, and some vulnerable accounts held millions of dollars.

Sensitive Data Exposure

Sensitive data exposure is a self-explanatory vulnerability. If an application holds valuable data that must be kept secret, this data needs to be appropriately protected.

Blockchain technology is largely vulnerable to this vulnerability due to a lack of understanding around the technology. The blockchain is immutable, meaning that any data stored on it cannot be removed (without control of every node in the network). Most blockchains are also public, allowing anyone to download and store a complete copy of the data in the ledger.

In the short term, this combination makes blockchains vulnerable to data mining efforts. Many organizations specialize in mining the blockchain for public data that can aggregated into useful information. This data can be used for law enforcement, corporate espionage, and other purposes.

In the long term, all cryptography is breakable. Quantum computing is on the horizon and, while it won’t break blockchain technology, it will allow the decryption of any data stored on the blockchain that’s encrypted with public key cryptography. If data needs to be kept private forever (like personal data protected by privacy laws), don’t put it on a public blockchain.

XML External Entities (XXE)

XML External Entities (XXE) are vulnerabilities based upon external entity references inside XML documents. The risk of these is that sensitive internal files stored on the webserver may be accessible using these references. Since blockchain is not XML-based, this vulnerability does not really apply.

Broken Access Control

Broken access control is similar to but distinct from broken authentication. In broken authentication, an attacker pretends to be an unauthorized user, while, in broken access control, a malicious user gains unauthorized access to protected functionality.

Poorly implemented access control mechanisms are one of the major vulnerabilities seen in Ethereum smart contracts. The Parity smart contract-based multi-signature wallet is known for being exploited twice due to access control vulnerabilities. In both cases, Parity smart contracts had a function designed to let the owner call it and claim ownership of the contract but didn’t check that it was only called once.

In the first attack, an attacker called this function to take control of Parity wallet contracts and drain them of the stored funds. In the second, a similar function in a library contract used by all Parity wallets was attacked. The attacker took control and then self-destructed the function, making all Parity wallets unusable and causing about 1% of all Ether to be lost forever3.

Security Misconfiguration

Security misconfigurations is another general OWASP vulnerability. It refers to using insecure default configurations of software or using configurations that make the system vulnerable to attack. As such, it is one of the most commonly seen types of vulnerabilities.

Blockchains are implemented as software running on client’s machines in a peer-to-peer network, so it makes sense that security misconfigurations could impact security. In one case, users of an Ethereum wallet configured their wallets to listen and accept external commands via RPC (port 8545). Attackers taking advantage of this vulnerability were able to steal $20 million worth of Ether4.

Cross-Site Scripting (XSS)

A website is vulnerable to a cross-site scripting attack if it includes untrusted data within a webpage without validating and sanitizing it first. This vulnerability allows an attacker to run scripts within a victim’s browser.

Cross-site scripting vulnerabilities can affect blockchain systems in a couple of different ways. Cross-site scripting vulnerabilities have been exploited in other software to allow cryptomining malware to be run on the victim’s computer.

Cross-site scripting vulnerabilities can affect blockchain security more directly if they exist in blockchain explorers. Blockchain explorers have display transaction data, which is untrusted data potentially under an attacker’s control. If an XSS vulnerability exists in a combined blockchain explorer and wallet, exploitation of the explorer could allow access to a user’s private key and control over their account5.

Insecure Deserialization

Serialization is commonly used for transmission of sets of data across a network. If deserialization code is improperly implemented, a malicious transmission could allow an attacker to exploit a vulnerable machine.

While no reported attacks have taken advantage of deserialization vulnerabilities, blockchain systems commonly use serialization for transmission of transactions. Since transaction data is under the control of (potentially malicious) users, vulnerable deserialization code could lead to compromise of blockchain systems.

Using Components with Known Vulnerabilities

Most software is built on top of or reuses other software. If these dependencies contain vulnerabilities, the software using them may be exploited by attackers targeting these vulnerabilities. The Equifax hack is a great example of how vulnerable third-party code can have significant impacts on an organization’s security.

Code reuse in Ethereum smart contracts is even more common than non-blockchain applications. In fact, less than 10% of Ethereum smart contracts do not reuse code6. Since many smart contract programmers have limited experience with the technology and the associated risks, this means that many smart contracts on the Ethereum blockchain contain known vulnerabilities due to code reuse.

Insufficient Logging and Monitoring

While secure development processes are important, they’re only half the battle. Once a system has been deployed, it is also important to log and monitor events on the system for abnormalities that may signal an attack. Failure to do so may leave the system vulnerable to exploitation via attack vectors overlooked during the design process.

The blockchain creates an immutable ledger of actions taken on the system, making it ideal for logging purposes. However, while logging is great, it’s useless is no-one is looking at the logs. Many smart contracts on the blockchain are “fire and forget” and go unmonitored by their owners, making them potentially vulnerable to exploitation without detection.

Securing the Blockchain

The OWASP Top Ten is designed to inform developers of the most common security mistakes made in web development. While blockchain systems are not traditional web applications, many of the same vulnerabilities apply. Of the vulnerabilities listed in the Top Ten list, only XXE is not directly applicable to some component of the blockchain ecosystem.

While the OWASP Top Ten is a good starting point when developing blockchain systems and smart contracts, the blockchain ecosystem creates additional potential security issues. The Decentralized Application Security Project (DASP) maintains a similar Top Ten list geared toward educating smart contract developers about the most common mistakes made on the Ethereum platform. Understanding how the blockchain ecosystem works and the security assumptions made at each level are also a vital part of ensuring holistic distributed ledger security.

Sources

[1] https://thehackernews.com/2018/05/eos-blockchain-smart-contract.html
[2] https://research.kudelskisecurity.com/2018/01/16/blockchains-how-to-steal-millions-in-264-operations/
[3] https://www.theregister.co.uk/2017/11/10/parity_280m_ethereum_wallet_lockdown_hack/
[4] https://cointelegraph.com/news/report-misconfigured-ethereum-clients-have-resulted-in-hack-of-around-20-mln
[5] https://blockpath.com/r/Interesting/comments/1g/the_transaction_that_can_xss_attack_unprepared/
[6] http://www.ccs.neu.edu/home/amislove/publications/Ethereum-IMC.pdf