Login
Cybercriminals are often seen as having the upper hand over the “white hat” community. After all, they’re anonymous, can launch attacks from virtually anywhere in the world, and usually have the element of surprise. But there’s one secret weapon the good guys have: Collaboration. That’s why Trend Micro has always prioritized its partnerships with law enforcement, academia, governments and other cybersecurity businesses.
We’re proud to have contributed to yet another successful collaborative operation with INTERPOL Global Complex for Innovation (IGCI) in Singapore that’s helped to reduce the number of users infected by cryptomining malware by 78%.
Cryptomining On The Rise
Also known as cryptojacking, these attacks have become an increasingly popular way for cybercriminals to make money.
Why?
Because victims don’t know they’ve been infected. The malware sits on their machine in the background mining for digital currency 24/7/365. Increasingly, hackers have taken to launching sophisticated attacks against enterprise IT systems and cloud servers to increase their mining and earning potential. But many still target home computer systems like routers, as these are often left relatively unprotected. Stitch enough of these devices together in a botnet and they have a ready-made cash cow.
That’s why cryptojacking remained the most detected threat in the first half of 2019 in terms of file-based threat components, according to our data.
Unlike serious data breaches, phishing attacks, ransomware and banking Trojans, cryptojacking doesn’t have major impact on the victim. They don’t lose sensitive personal data, there’s no risk of follow-on identity fraud and they’re not extorted for funds by being locked out of their PC.
However, it’s not without consequences: Cryptomining malware can slow your home network to a crawl while running up serious energy bills. It may even bring your home computers to a premature end. Also, there’s always the risk with any kind of malware infection that hackers may switch tactics and use their footprint on your home machines to launch other attacks in the future.
Enter Operation Goldfish Alpha
That’s why we were keen to offer our assistance to INTERPOL during this year’s Operation Goldfish Alpha. Thanks to our broad global visibility into attack trends and infection rates, we were able to articulate the scale of the cryptojacking threat and key mitigation steps, at a pre-operation meeting with ASEAN law enforcement officers in June.
A few months later, we developed and disseminated a key Cryptojacking Mitigation and Prevention guidance document. It details how a vulnerability in MikroTik routers had exposed countless users in the region to the risk of compromise by cryptomining malware. The document explains how to scan for this flaw using Trend Micro HouseCall for Home Networks, and how HouseCall can be used to detect and delete the Coinhive JavaScript that hackers were using to mine for digital currency on infected PCs.
Spectacular Success
Over the five months of Operation Goldfish Alpha, experts from national Computer Emergency Response Teams (CERTs) and police across 10 countries in the region worked to locate the infected routers, notify the victims and use our guidance document to patch the bugs and kick out the hackers.
Having helped to identify over 20,000 routers in the region that were hacked in this way, we’re delighted to say that by November, the number had reduced by at least 78%.
That’s the value of partnerships between law enforcement and private cybersecurity companies: They combine the power of investigative policing with the detailed subject matter expertise, visibility and resources of industry experts like us. We’ll continue to lend a hand wherever we can to make our connected, digital world a safer place.
The post INTERPOL Collaboration Reduces Cryptojacking by 78% appeared first on .
Trend Micro Research has developed a go-to resource for all things related to cybercriminal underground hosting and infrastructure. Today we released the second in this three-part series of reports which detail the what, how, and why of cybercriminal hosting (see the first part here).
As part of this report, we dive into the common life cycle of a compromised server from initial compromise to the different stages of monetization preferred by criminals. It’s also important to note that regardless of whether a company’s server is on-premise or cloud-based, criminals don’t care what kind of server they compromise.
To a criminal, any server that is exposed or vulnerable is fair game.
Cloud vs. On-Premise Servers
Cybercriminals don’t care where servers are located. They can leverage the storage space, computation resources, or steal data no matter what type of server they access. Whatever is most exposed will most likely be abused.
As digital transformation continues and potentially picks up to allow for continued remote working, cloud servers are more likely to be exposed. Many enterprise IT teams, unfortunately, are not arranged to provide the same protection for cloud as on-premise servers.
As a side note, we want to emphasize that this scenario applies only to cloud instances replicating the storage or processing power of an on-premise server. Containers or serverless functions won’t fall victim to this same type of compromise. Additionally, if the attacker compromises the cloud account, as opposed to a single running instance, then there is an entirely different attack life cycle as they can spin up computing resources at will. Although this is possible, however, it is not our focus here.
Attack Red Flags
Many IT and security teams might not look for earlier stages of abuse. Before getting hit by ransomware, however, there are other red flags that could alert teams to the breach.
If a server is compromised and used for cryptocurrency mining (also known as cryptomining), this can be one of the biggest red flags for a security team. The discovery of cryptomining malware running on any server should result in the company taking immediate action and initiating an incident response to lock down that server.
This indicator of compromise (IOC) is significant because while cryptomining malware is often seen as less serious compared to other malware types, it is also used as a monetization tactic that can run in the background while server access is being sold for further malicious activity. For example, access could be sold for use as a server for underground hosting. Meanwhile, the data could be exfiltrated and sold as personally identifiable information (PII) or for industrial espionage, or it could be sold for a targeted ransomware attack. It’s possible to think of the presence of cryptomining malware as the proverbial canary in a coal mine: This is the case, at least, for several access-as-a-service (AaaS) criminals who use this as part of their business model.
Attack Life Cycle
Attacks on compromised servers follow a common path:
|
|
The monetization lifecycle of a compromised server
Often, targeted ransomware is the final stage. In most cases, asset categorization reveals data that is valuable to the business but not necessarily valuable for espionage.
A deep understanding of the servers and network allows criminals behind a targeted ransomware attack to hit the company where it hurts the most. These criminals would know the dataset, where they live, whether there are backups of the data, and more. With such a detailed blueprint of the organization in their hands, cybercriminals can lock down critical systems and demand higher ransom, as we saw in our 2020 midyear security roundup report.
In addition, while a ransomware attack would be the visible urgent issue for the defender to solve in such an incident, the same attack could also indicate that something far more serious has likely already taken place: the theft of company data, which should be factored into the company’s response planning. More importantly, it should be noted that once a company finds an IOC for cryptocurrency, stopping the attacker right then and there could save them considerable time and money in the future.
Ultimately, no matter where a company’s data is stored, hybrid cloud security is critical to preventing this life cycle.
The post The Life Cycle of a Compromised (Cloud) Server appeared first on .
How public-key cryptography works Public-key or asymmetric cryptography is one of the two main types of encryption algorithms. Its names come from the fact that it uses two different encryption keys: a public one and a private one. Public and private keys The private key used in public-key cryptography is a random number with certain […]
The post Public-Key Cryptography in Blockchain appeared first on Infosec Resources.
Introduction In cryptography, a key is a very important piece of information used to combine with an algorithm (a cipher) to transform plaintext into ciphertext (encryption). The first step of preventive security is not encryption; however, the proper management of a cryptographic key is essential. Key management includes the generating, using, storing, archiving and deleting […]
The post The ultimate guide to encryption key management appeared first on Infosec Resources.
This is the first in a multi-part blog series on cryptography and the Domain Name System (DNS).
As one of the earliest protocols in the internet, the DNS emerged in an era in which today’s global network was still an experiment. Security was not a primary consideration then, and the design of the DNS, like other parts of the internet of the day, did not have cryptography built in.
Today, cryptography is part of almost every protocol, including the DNS. And from a cryptographer’s perspective, as I described in my talk at last year’s International Cryptographic Module Conference (ICMC20), there’s so much more to the story than just encryption.
The first broad-scale deployment of cryptography in the DNS was not for confidentiality but for data integrity, through the Domain Name System Security Extensions (DNSSEC), introduced in 2005.
The story begins with the usual occurrence that happens millions of times a second around the world: a client asks a DNS resolver a query like “What is example.com’s Internet Protocol (IP) address?” The resolver in this case answers: “example.com’s IP address is 93.184.216.34”. (This is the correct answer.)
If the resolver doesn’t already know the answer to the request, then the process to find the answer goes something like this:
But how does the resolver know that the answer it ultimately receives is correct? The process defined by DNSSEC follows the same “delegation” model from root to TLD to SLD as I’ve described above.
Indeed, DNSSEC provides a way for the resolver to check that the answer is correct by validating a chain of digital signatures, by examining digital signatures at each level of the DNS hierarchy (or technically, at each “zone” in the delegation process). These digital signatures are generated using public key cryptography, a well-understood process that involves encryption using key pairs, one public and one private.
In a typical DNSSEC deployment, there are two active public keys per zone: a Key Signing Key (KSK) public key and a Zone Signing Key (ZSK) public key. (The reason for having two keys is so that one key can be changed locally, without the other key being changed.)
The responses returned to the resolver include digital signatures generated by either the corresponding KSK private key or the corresponding ZSK private key.
Using mathematical operations, the resolver checks all the digital signatures it receives in association with a given query. If they are valid, the resolver returns the “Digital Signature Validated” indicator to the client that initiated the query.
A convenient way to visualize the collection of digital signatures is as a “trust chain” from a “trust anchor” to the DNS record of interest, as shown in the figure above. The chain includes “chain links” at each level of the DNS hierarchy. Here’s how the “chain links” work:
The root KSK public key is the “trust anchor.” This key is widely distributed in resolvers so that they can independently authenticate digital signatures on records in the root zone, and thus authenticate everything else in the chain.
The root zone chain links consist of three parts:
The TLD zone chain links also consist of three parts:
The SLD zone chain links once more consist of three parts:
A resolver (or anyone else) can thereby verify the signature on any set of DNS records given the chain of public keys leading up to the trust anchor.
Note that this is a simplified view, and there are other details in practice. For instance, the various KSK public keys are also signed by their own private KSK, but I’ve omitted these signatures for brevity. The DNSViz tool provides a very nice interactive interface for browsing DNSSEC trust chains in detail, including the trust chain for example.com discussed here.
The effort to update the root KSK public key, the aforementioned “trust anchor” was one of the challenging and successful projects by the DNS community over the past couple of years. This initiative – the so-called “root KSK rollover” – was challenging because there was no easy way to determine whether resolvers actually had been updated to use the latest root KSK — remember that cryptography and security was added on rather than built into the DNS. There are many resolvers that needed to be updated, each independently managed.
The research paper “Roll, Roll, Roll your Root: A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover” details the process of updating the root KSK. The paper, co-authored by Verisign researchers and external colleagues, received the distinguished paper award at the 2019 Internet Measurement Conference.
I’ve focused here on how a resolver validates correctness when the response to a query has a “positive” answer — i.e., when the DNS record exists. Checking correctness when the answer doesn’t exist gets even more interesting from a cryptographer’s perspective. I’ll cover this topic in my next post.
Read the complete six blog series:
The post The Domain Name System: A Cryptographer’s Perspective appeared first on Verisign Blog.
This is the second in a multi-part blog series on cryptography and the Domain Name System (DNS).
In my previous post, I described the first broad scale deployment of cryptography in the DNS, known as the Domain Name System Security Extensions (DNSSEC). I described how a name server can enable a requester to validate the correctness of a “positive” response to a query — when a queried domain name exists — by adding a digital signature to the DNS response returned.
The designers of DNSSEC, as well as academic researchers, have separately considered the answer of “negative” responses – when the domain name doesn’t exist. In this case, as I’ll explain, responding with a signed “does not exist” is not the best design. This makes the non-existence case interesting from a cryptographer’s perspective as well.
Consider a domain name like example.arpa that doesn’t exist.
If it did exist, then as I described in my previous post, the second-level domain (SLD) server for example.arpa would return a response signed by example.arpa’s zone signing key (ZSK).
So a first try for the case that the domain name doesn’t exist is for the SLD server to return the response “example.arpa doesn’t exist,” signed by example.arpa’s ZSK.
However, if example.arpa doesn’t exist, then example.arpa won’t have either an SLD server or a ZSK to sign with. So, this approach won’t work.
A second try is for the parent name server — the .arpa top-level domain (TLD) server in the example — to return the response “example.arpa doesn’t exist,” signed by the parent’s ZSK.
This could work if the .arpa DNS server knows the ZSK for .arpa. However, for security and performance reasons, the design preference for DNSSEC has been to keep private keys offline, within the zone’s provisioning system.
The provisioning system can precompute statements about domain names that do exist — but not about every possible individual domain name that doesn’t exist. So, this won’t work either, at least not for the servers that keep their private keys offline.
The third try is the design that DNSSEC settled on. The parent name server returns a “range statement,” previously signed with the ZSK, that states that there are no domain names in an ordered sequence between two “endpoints” where the endpoints depend on domain names that do exist. The range statements can therefore be signed offline, and yet the name server can still choose an appropriate signed response to return, based on the (non-existent) domain name in the query.
The DNS community has considered several approaches to constructing range statements, and they have varying cryptographic properties. Below I’ve described two such approaches. For simplicity, I’ve focused just on the basics in the discussion that follows. The astute reader will recognize that there are many more details involved both in the specification and the implementation of these techniques.
The first approach, called NSEC, involved no additional cryptography beyond the DNSSEC signature on the range statement. In NSEC, the endpoints are actual domain names that exist. NSEC stands for “Next Secure,” referring to the fact that the second endpoint in the range is the “next” existing domain name following the first endpoint.
The NSEC resource record is documented in one of the original DNSSEC specifications, RFC4033, which was co-authored by Verisign.
The .arpa zone implements NSEC. When the .arpa server receives the request “What is the IP address of example.arpa,” it returns the response “There are no names between e164.arpa and home.arpa.” This exchange is shown in the figure below and is analyzed in the associated DNSviz graph. (The response is accurate as of the writing of this post; it could be different in the future if names were added to or removed from the .arpa zone.)
NSEC has a side effect: responses immediately reveal unqueried domain names in the zone. Depending on the sensitivity of the zone, this may be undesirable from the perspective of the minimum disclosure principle.
A second approach, called NSEC3 reduces the disclosure risk somewhat by defining the endpoints as hashes of existing domain names. (NSEC3 is documented in RFC 5155, which was also co-authored by Verisign.)
An example of NSEC3 can be seen with example.name, another domain that doesn’t exist. Here, the .name TLD server returns a range statement that “There are no domain names with hashes between 5SU9… and 5T48…”. Because the hash of example.name is “5SVV…” the response implies that “example.name” doesn’t exist.
This statement is shown in the figure below and in another DNSviz graph. (As above, the actual response could change if the .name zone changes.)
To find out which domain name corresponds to one of the hashed endpoints, an adversary would have to do a trial-and-error or “dictionary” attack across multiple guesses of domain names, to see if any has a matching hash value. Such a search could be performed “offline,” i.e., without further interaction with the name server, which is why the disclosure risk is only somewhat reduced.
NSEC and NSEC3 are mutually exclusive. Nearly all TLDs, including all TLDs operated by Verisign, implement NSEC3. In addition to .arpa, the root zone also implements NSEC.
In my next post, I’ll describe NSEC5, an approach still in the experimental stage, that replaces the hash function in NSEC3 with a verifiable random function (VRF) to protect against offline dictionary attacks. I’ll also share some research Verisign Labs has done on a complementary approach that helps protect a client’s queries for non-existent domain names from disclosure.
Read the complete six blog series:
The post Cryptographic Tools for Non-Existence in the Domain Name System: NSEC and NSEC3 appeared first on Verisign Blog.
This is the third in a multi-part blog series on cryptography and the Domain Name System (DNS).
In my last post, I looked at what happens when a DNS query renders a “negative” response – i.e., when a domain name doesn’t exist. I then examined two cryptographic approaches to handling negative responses: NSEC and NSEC3. In this post, I will examine a third approach, NSEC5, and a related concept that protects client information, tokenized queries.
The concepts I discuss below are topics we’ve studied in our long-term research program as we evaluate new technologies. They do not necessarily represent Verisign’s plans or position on a new product or service. Concepts developed in our research program may be subject to U.S. and international patents and patent applications.
NSEC5 is a result of research by cryptographers at Boston University and the Weizmann Institute. In this approach, which is still in an experimental stage, the endpoints are the outputs of a verifiable random function (VRF), a cryptographic primitive that has been gaining interest in recent years. NSEC5 is documented in an Internet Draft (currently expired) and in several research papers.
A VRF is like a hash function but with two important differences:
So, it’s not only hard for an adversary to reverse the VRF – which is also a property the hash function has – but it’s also hard for the adversary to compute the VRF in the forward direction, thus preventing dictionary attacks. And yet a relying party can still confirm that the VRF output for a given input is correct, because of the proof.
How does this work in practice? As in NSEC and NSEC3, range statements are prepared in advance and signed with the zone signing key (ZSK). With NSEC5, however, the range endpoints are two consecutive tokens.
When a domain name doesn’t exist, the name server applies the VRF to the domain name to obtain a token and a proof. The name sever then returns a range statement where the token falls within the range, as well as the proof, as shown in the figure below. Note that the token values are for illustration only.
Because the range statement reveals only tokenized versions of other domain names in a zone, an adversary who doesn’t know the private key doesn’t learn any new existing domain names from the response. Indeed, to find out which domain name corresponds to one of the tokenized endpoints, the adversary would need access to the VRF itself to see if a candidate domain name has a matching hash value, which would involve an online dictionary attack. This significantly reduces disclosure risk.
The name server needs a copy of the zone’s NSEC5 private key so that it can generate proofs for non-existent domain names. The ZSK itself can stay in the provisioning system. As the designers of NSEC5 have pointed out, if the NSEC5 private key does happen to be compromised, this only makes it possible to do a dictionary attack offline— not to generate signatures on new range statements, or on new positive responses.
NSEC5 is interesting from a cryptographer’s perspective because it uses a less common cryptographic technique, a VRF, to achieve a design goal that was at best partially met by previous approaches. As with other new technologies, DNS operators will need to consider whether NSEC5’s benefits are sufficient to justify its cost and complexity. Verisign doesn’t have any plans to implement NSEC5, as we consider NSEC and NSEC3 adequate for the name servers we currently operate. However, we will continue to track NSEC5 and related developments as part of our long-term research program.
A few years before NSEC5 was published, Verisign Labs had started some research on an opposite application of tokenization to the DNS, to protect a client’s information from disclosure.
In our approach, instead of asking the resolver “What is <name>’s IP address,” the client would ask “What is token 3141…’s IP address,” where 3141… is the tokenization of <name>.
(More precisely, the client would specify both the token and the parent zone that the token relates to, e.g., the TLD of the domain name. Only the portion of the domain name below the parent would be obscured, just as in NSEC5. I’ve omitted the zone information for simplicity in this discussion.)
Suppose now that the domain name corresponding to token 3141… does exist. Then the resolver would respond with the domain name’s IP address as usual, as shown in the next figure.
In this case, the resolver would know that the domain name associated with the token does exist, because it would have a mapping between the token and the DNS record, i.e., the IP address. Thus, the resolver would effectively “know” the domain name as well for practical purposes. (We’ve developed another approach that can protect both the domain name and the DNS record from disclosure to the resolver in this case, but that’s perhaps a topic for another post.)
Now, consider a domain name that doesn’t exist and suppose that its token is 2718… .
In this case, the resolver would respond that the domain name doesn’t exist, as usual, as shown below.
But because the domain name is tokenized and no other information about the domain name is returned, the resolver would only learn the token 2718… (and the parent zone), not the actual domain name that the client is interested in.
The resolver could potentially know that the name doesn’t exist via a range statement from the parent zone, as in NSEC5.
How does the client tokenize the domain name, if it doesn’t have the private key for the VRF? The name server would offer a public interface to the tokenization function. This can be done in what cryptographers call an “oblivious” VRF protocol, where the name server doesn’t see the actual domain name during the protocol, yet the client still gets the token.
To keep the resolver itself from using this interface to do an online dictionary attack that matches candidate domain names with tokens, the name server could rate-limit access, or restrict it only to authorized requesters.
Additional details on this technology may be found in U.S. Patent 9,202,079B2, entitled “Privacy preserving data querying,” and related patents.
It’s interesting from a cryptographer’s perspective that there’s a way for a client to find out whether a DNS record exists, without necessarily revealing the domain name of interest. However, as before, the benefits of this new technology will be weighed against its operational cost and complexity and compared to other approaches. Because this technique focuses on client-to-resolver interactions, it’s already one step removed from the name servers that Verisign currently operates, so it is not as relevant to our business today in a way it might have been when we started the research. This one will stay under our long-term tracking as well.
The examples I’ve shared in these last two blog posts make it clear that cryptography has the potential to bring interesting new capabilities to the DNS. While the particular examples I’ve shared here do not meet the criteria for our product roadmap, researching advances in cryptography and other techniques remains important because new events can sometimes change the calculus. That point will become even more evident in my next post, where I’ll consider the kinds of cryptography that may be needed in the event that one or more of today’s algorithms is compromised, possibly through the introduction of a quantum computer.
Read the complete six blog series:
The post Newer Cryptographic Advances for the Domain Name System: NSEC5 and Tokenized Queries appeared first on Verisign Blog.
This is the fourth in a multi-part series on cryptography and the Domain Name System (DNS).
One of the “key” questions cryptographers have been asking for the past decade or more is what to do about the potential future development of a large-scale quantum computer.
If theory holds, a quantum computer could break established public-key algorithms including RSA and elliptic curve cryptography (ECC), building on Peter Shor’s groundbreaking result from 1994.
This prospect has motivated research into new so-called “post-quantum” algorithms that are less vulnerable to quantum computing advances. These algorithms, once standardized, may well be added into the Domain Name System Security Extensions (DNSSEC) — thus also adding another dimension to a cryptographer’s perspective on the DNS.
(Caveat: Once again, the concepts I’m discussing in this post are topics we’re studying in our long-term research program as we evaluate potential future applications of technology. They do not necessarily represent Verisign’s plans or position on possible new products or services.)
The National Institute of Standards and Technology (NIST) started a Post-Quantum Cryptography project in 2016 to “specify one or more additional unclassified, publicly disclosed digital signature, public-key encryption, and key-establishment algorithms that are capable of protecting sensitive government information well into the foreseeable future, including after the advent of quantum computers.”
Security protocols that NIST is targeting for these algorithms, according to its 2019 status report (Section 2.2.1), include: “Transport Layer Security (TLS), Secure Shell (SSH), Internet Key Exchange (IKE), Internet Protocol Security (IPsec), and Domain Name System Security Extensions (DNSSEC).”
The project is now in its third round, with seven finalists, including three digital signature algorithms, and eight alternates.
NIST’s project timeline anticipates that the draft standards for the new post-quantum algorithms will be available between 2022 and 2024.
It will likely take several additional years for standards bodies such as the Internet Engineering Task (IETF) to incorporate the new algorithms into security protocols. Broad deployments of the upgraded protocols will likely take several years more.
Post-quantum algorithms can therefore be considered a long-term issue, not a near-term one. However, as with other long-term research, it’s appropriate to draw attention to factors that need to be taken into account well ahead of time.
The three candidate digital signature algorithms in NIST’s third round have one common characteristic: all of them have a key size or signature size (or both) that is much larger than for current algorithms.
Key and signature sizes are important operational considerations for DNSSEC because most of the DNS traffic exchanged with authoritative data servers is sent and received via the User Datagram Protocol (UDP), which has a limited response size.
Response size concerns were evident during the expansion of the root zone signing key (ZSK) from 1024-bit to 2048-bit RSA in 2016, and in the rollover of the root key signing key (KSK) in 2018. In the latter case, although the signature and key sizes didn’t change, total response size was still an issue because responses during the rollover sometimes carried as many as four keys rather than the usual two.
Thanks to careful design and implementation, response sizes during these transitions generally stayed within typical UDP limits. Equally important, response sizes also appeared to have stayed within the Maximum Transmission Unit (MTU) of most networks involved, thereby also avoiding the risk of packet fragmentation. (You can check how well your network handles various DNSSEC response sizes with this tool developed by Verisign Labs.)
The larger sizes associated with certain post-quantum algorithms do not appear to be a significant issue either for TLS, according to one benchmarking study, or for public-key infrastructures, according to another report. However, a recently published study of post-quantum algorithms and DNSSEC observes that “DNSSEC is particularly challenging to transition” to the new algorithms.
Verisign Labs offers the following observations about DNSSEC-related queries that may help researchers to model DNSSEC impact:
A typical resolver that implements both DNSSEC validation and qname minimization will send a combination of queries to Verisign’s root and top-level domain (TLD) servers.
Because the resolver is a validating resolver, these queries will all have the “DNSSEC OK” bit set, indicating that the resolver wants the DNSSEC signatures on the records.
The content of typical responses by Verisign’s root and TLD servers to these queries are given in Table 1 below. (In the table, <SLD>.<TLD> are the final two labels of a domain name of interest, including the TLD and the second-level domain (SLD); record types involved include A, Name Server (NS), and DNSKEY.)
| Name Server | Resolver Query Scenario | Typical Response Content from Verisign’s Servers |
| Root | DNSKEY record set for root zone | • DNSKEY record set including root KSK RSA-2048 public key and root ZSK RSA-2048 public key • Root KSK RSA-2048 signature on DNSKEY record set |
| A or NS record set for <TLD> — when <TLD> exists | • NS referral to <TLD> name server • DS record set for <TLD> zone • Root ZSK RSA-2048 signature on DS record set |
|
| A or NS record set for <TLD> — when <TLD> doesn’t exist | • Up to two NSEC records for non-existence of <TLD> • Root ZSK RSA-2048 signatures on NSEC records |
|
| .com / .net | DNSKEY record set for <TLD> zone | • DNSKEY record set including <TLD> KSK RSA-2048 public key and <TLD> ZSK RSA-1280 public key • <TLD> KSK RSA-2048 signature on DNSKEY record set |
| A or NS record set for <SLD>.<TLD> — when <SLD>.<TLD> exists | • NS referral to <SLD>.<TLD> name server • DS record set for <SLD>.<TLD> zone (if <SLD>.<TLD> supports DNSSEC) • <TLD> ZSK RSA-1280 signature on DS record set (if present) |
|
| A or NS record set for <SLD>.<TLD> — when <SLD>.<TLD> doesn’t exist | • Up to three NSEC3 records for non-existence of <SLD>.<TLD> • <TLD> ZSK RSA-1280 signatures on NSEC3 records |
For an A or NS query, the typical response, when the domain of interest exists, includes a referral to another name server. If the domain supports DNSSEC, the response also includes a set of Delegation Signer (DS) records providing the hashes of each of the referred zone’s KSKs — the next link in the DNSSEC trust chain. When the domain of interest doesn’t exist, the response includes one or more Next Secure (NSEC) or Next Secure 3 (NSEC3) records.
Researchers can estimate the effect of post-quantum algorithms on response size by replacing the sizes of the various RSA keys and signatures with those for their post-quantum counterparts. As discussed above, it is important to keep in mind that the number of keys returned may be larger during key rollovers.
Most of the queries from qname-minimizing, validating resolvers to the root and TLD name servers will be for A or NS records (the choice depends on the implementation of qname minimization, and has recently trended toward A). The signature size for a post-quantum algorithm, which affects all DNSSEC-related responses, will therefore generally have a much larger impact on average response size than will the key size, which affects only the DNSKEY responses.
Post-quantum algorithms are among the newest developments in cryptography. They add another dimension to a cryptographer’s perspective on the DNS because of the possibility that these algorithms, or other variants, may be added to DNSSEC in the long term.
In my next post, I’ll make the case for why the oldest post-quantum algorithm, hash-based signatures, could be a particularly good match for DNSSEC. I’ll also share the results of some research at Verisign Labs into how the large signature sizes of hash-based signatures could potentially be overcome.
Read the complete six blog series:
The post Securing the DNS in a Post-Quantum World: New DNSSEC Algorithms on the Horizon appeared first on Verisign Blog.
This is the fifth in a multi-part series on cryptography and the Domain Name System (DNS).
In my last article, I described efforts underway to standardize new cryptographic algorithms that are designed to be less vulnerable to potential future advances in quantum computing. I also reviewed operational challenges to be considered when adding new algorithms to the DNS Security Extensions (DNSSEC).
In this post, I’ll look at hash-based signatures, a family of post-quantum algorithms that could be a good match for DNSSEC from the perspective of infrastructure stability.
I’ll also describe Verisign Labs research into a new concept called synthesized zone signing keys that could mitigate the impact of the large signature size for hash-based signatures, while still maintaining this family’s protections against quantum computing.
(Caveat: The concepts reviewed in this post are part of Verisign’s long-term research program and do not necessarily represent Verisign’s plans or positions on new products or services. Concepts developed in our research program may be subject to U.S. and/or international patents and/or patent applications.)
The DNS community’s root key signing key (KSK) rollover illustrates how complicated a change to DNSSEC infrastructure can be. Although successfully accomplished, this change was delayed by ICANN to ensure that enough resolvers had the public key required to validate signatures generated with the new root KSK private key.
Now imagine the complications if the DNS community also had to ensure that enough resolvers not only had a new key but also had a brand-new algorithm.
Imagine further what might happen if a weakness in this new algorithm were to be found after it was deployed. While there are procedures for emergency key rollovers, emergency algorithm rollovers would be more complicated, and perhaps controversial as well if a clear successor algorithm were not available.
I’m not suggesting that any of the post-quantum algorithms that might be standardized by NIST will be found to have a weakness. But confidence in cryptographic algorithms can be gained and lost over many years, sometimes decades.
From the perspective of infrastructure stability, therefore, it may make sense for DNSSEC to have a backup post-quantum algorithm built in from the start — one for which cryptographers already have significant confidence and experience. This algorithm might not be as efficient as other candidates, but there is less of a chance that it would ever need to be changed. This means that the more efficient candidates could be deployed in DNSSEC with the confidence that they have a stable fallback. It’s also important to keep in mind that the prospect of quantum computing is not the only reason system developers need to be considering new algorithms from time to time. As public-key cryptography pioneer Martin Hellman wisely cautioned, new classical (non-quantum) attacks could also emerge, whether or not a quantum computer is realized.
The 1970s were a foundational time for public-key cryptography, producing not only the RSA algorithm and the Diffie-Hellman algorithm (which also provided the basic model for elliptic curve cryptography), but also hash-based signatures, invented in 1979 by another public-key cryptography founder, Ralph Merkle.
Hash-based signatures are interesting because their security depends only on the security of an underlying hash function.
It turns out that hash functions, as a concept, hold up very well against quantum computing advances — much better than currently established public-key algorithms do.
This means that Merkle’s hash-based signatures, now more than 40 years old, can rightly be considered the oldest post-quantum digital signature algorithm.
If it turns out that an individual hash function doesn’t hold up — whether against a quantum computer or a classical computer — then the hash function itself can be replaced, as cryptographers have been doing for years. That will likely be easier than changing to an entirely different post-quantum algorithm, especially one that involves very different concepts.
The conceptual stability of hash-based signatures is a reason that interoperable specifications are already being developed for variants of Merkle’s original algorithm. Two approaches are described in RFC 8391, “XMSS: eXtended Merkle Signature Scheme” and RFC 8554, “Leighton-Micali Hash-Based Signatures.” Another approach, SPHINCS+, is an alternate in NIST’s post-quantum project.
Hash-based signatures can potentially be applied to any part of the DNSSEC trust chain. For example, in Figure 1, the DNS record sets can be signed with a zone signing key (ZSK) that employs a hash-based signature algorithm.
The main challenge with hash-based signatures is that the signature size is large, on the order of tens or even hundreds of thousands of bits. This is perhaps why they haven’t seen significant adoption in security protocols over the past four decades.
Verisign Labs has been exploring how to mitigate the size impact of hash-based signatures on DNSSEC, while still basing security on hash functions only in the interest of stable post-quantum protections.
One of the ideas we’ve come up with uses another of Merkle’s foundational contributions: Merkle trees.
Merkle trees authenticate multiple records by hashing them together in a tree structure. The records are the “leaves” of the tree. Pairs of leaves are hashed together to form a branch, then pairs of branches are hashed together to form a larger branch, and so on. The hash of the largest branches is the tree’s “root.” (This is a data-structure root, unrelated to the DNS root.)
Each individual leaf of a Merkle tree can be authenticated by retracing the “path” from the leaf to the root. The path consists of the hashes of each of the adjacent branches encountered along the way.
Authentication paths can be much shorter than typical hash-based signatures. For instance, with a tree depth of 20 and a 256-bit hash value, the authentication path for a leaf would only be 5,120 bits long, yet a single tree could authenticate more than a million leaves.
Returning to the example above, suppose that instead of signing each DNS record set with a hash-based signature, each record set were considered a leaf of a Merkle tree. Suppose further that the root of this tree were to be published as the ZSK public key (see Figure 2). The authentication path to the leaf could then serve as the record set’s signature.
The validation logic at a resolver would be the same as in ordinary DNSSEC:
The only difference on the resolver’s side would be that signature validation would involve retracing the authentication path to the ZSK public key, rather than a conventional signature validation operation.
The ZSK public key produced by the Merkle tree approach would be a “synthesized” public key, in that it is obtained from the records being signed. This is noteworthy from a cryptographer’s perspective, because the public key wouldn’t have a corresponding private key, yet the DNS records would still, in effect, be “signed by the ZSK!”
In this type of DNSSEC implementation, the Merkle tree approach only applies to the ZSK level. Hash-based signatures would still be applied at the KSK level, although their overhead would now be “amortized” across all records in the zone.
In addition, each new ZSK would need to be signed “on demand,” rather than in advance, as in current operational practice.
This leads to tradeoffs, such as how many changes to accumulate before constructing and publishing a new tree. Fewer changes and the tree will be available sooner. More changes and the tree will be larger, so the per-record overhead of the signatures at the KSK level will be lower.
My last few posts have discussed cryptographic techniques that could potentially be applied to the DNS in the long term — or that might not even be applied at all. In my next post, I’ll return to more conventional subjects, and explain how Verisign sees cryptography fitting into the DNS today, as well as some important non-cryptographic techniques that are part of our vision for a secure, stable and resilient DNS.
Read the complete six blog series:
The post Securing the DNS in a Post-Quantum World: Hash-Based Signatures and Synthesized Zone Signing Keys appeared first on Verisign Blog.
This is the final in a multi-part series on cryptography and the Domain Name System (DNS).
In previous posts in this series, I’ve discussed a number of applications of cryptography to the DNS, many of them related to the Domain Name System Security Extensions (DNSSEC).
In this final blog post, I’ll turn attention to another application that may appear at first to be the most natural, though as it turns out, may not always be the most necessary: DNS encryption. (I’ve also written about DNS encryption as well as minimization in a separate post on DNS information protection.)
In 2014, the Internet Engineering Task Force (IETF) chartered the DNS PRIVate Exchange (dprive) working group to start work on encrypting DNS queries and responses exchanged between clients and resolvers.
That work resulted in RFC 7858, published in 2016, which describes how to run the DNS protocol over the Transport Layer Security (TLS) protocol, also known as DNS over TLS, or DoT.
DNS encryption between clients and resolvers has since gained further momentum, with multiple browsers and resolvers supporting DNS over Hypertext Transport Protocol Security (HTTPS), or DoH, with the formation of the Encrypted DNS Deployment Initiative, and with further enhancements such as oblivious DoH.
The dprive working group turned its attention to the resolver-to-authoritative exchange during its rechartering in 2018. And in October of last year, ICANN’s Office of the CTO published its strategy recommendations for the ICANN-managed Root Server (IMRS, i.e., the L-Root Server), an effort motivated in part by concern about potential “confidentiality attacks” on the resolver-to-root connection.
From a cryptographer’s perspective the prospect of adding encryption to the DNS protocol is naturally quite interesting. But this perspective isn’t the only one that matters, as I’ve observed numerous times in previous posts.
A common theme in this series on cryptography and the DNS has been the question of whether the benefits of a technology are sufficient to justify its cost and complexity.
This question came up not only in my review of two newer cryptographic advances, but also in my remarks on the motivation for two established tools for providing evidence that a domain name doesn’t exist.
Recall that the two tools — the Next Secure (NSEC) and Next Secure 3 (NSEC3) records — were developed because a simpler approach didn’t have an acceptable risk / benefit tradeoff. In the simpler approach, to provide a relying party assurance that a domain name doesn’t exist, a name server would return a response, signed with its private key, “<name> doesn’t exist.”
From a cryptographic perspective, the simpler approach would meet its goal: a relying party could then validate the response with the corresponding public key. However, the approach would introduce new operational risks, because the name server would now have to perform online cryptographic operations.
The name server would not only have to protect its private key from compromise, but would also have to protect the cryptographic operations from overuse by attackers. That could open another avenue for denial-of-service attacks that could prevent the name server from responding to legitimate requests.
The designers of DNSSEC mitigated these operational risks by developing NSEC and NSEC3, which gave the option of moving the private key and the cryptographic operations offline, into the name server’s provisioning system. Cryptography and operations were balanced by this better solution. The theme is now returning to view through the recent efforts around DNS encryption.
Like the simpler initial approach for authentication, DNS encryption may meet its goal from a cryptographic perspective. But the operational perspective is important as well. As designers again consider where and how to deploy private keys and cryptographic operations across the DNS ecosystem, alternatives with a better balance are a desirable goal.
In addition to encryption, there has been research into other, possibly lower-risk alternatives that can be used in place of or in addition to encryption at various levels of the DNS.
We call these techniques collectively minimization techniques.
In “textbook” DNS resolution, a resolver sends the same full domain name to a root server, a top-level domain (TLD) server, a second-level domain (SLD) server, and any other server in the chain of referrals, until it ultimately receives an authoritative answer to a DNS query.
This is the way that DNS resolution has been practiced for decades, and it’s also one of the reasons for the recent interest in protecting information on the resolver-to-authoritative exchange: The full domain name is more information than all but the last name server needs to know.
One such minimization technique, known as qname minimization, was identified by Verisign researchers in 2011 and documented in RFC 7816 in 2016. (In 2015, Verisign announced a royalty-free license to its qname minimization patents.)
With qname minimization, instead of sending the full domain name to each name server, the resolver sends only as much as the name server needs either to answer the query or to refer the resolver to a name server at the next level. This follows the principle of minimum disclosure: the resolver sends only as much information as the name server needs to “do its job.” As Matt Thomas described in his recent blog post on the topic, nearly half of all .com and .net queries received by Verisign’s .com TLD servers were in a minimized form as of August 2020.
Other techniques that are part of this new chapter in DNS protocol evolution include NXDOMAIN cut processing [RFC 8020] and aggressive DNSSEC caching [RFC 8198]. Both leverage information present in the DNS to reduce the amount and sensitivity of DNS information exchanged with authoritative name servers. In aggressive DNSSEC caching, for example, the resolver analyzes NSEC and NSEC3 range proofs obtained in response to previous queries to determine on its own whether a domain name doesn’t exist. This means that the resolver doesn’t always have to ask the authoritative server system about a domain name it hasn’t seen before.
All of these techniques, as well as additional minimization alternatives I haven’t mentioned, have one important common characteristic: they only change how the resolver operates during the resolver-authoritative exchange. They have no impact on the authoritative name server or on other parties during the exchange itself. They thereby mitigate disclosure risk while also minimizing operational risk.
The resolver’s exchanges with authoritative name servers, prior to minimization, were already relatively less sensitive because they represented aggregate interests of the resolver’s many clients1. Minimization techniques lower the sensitivity even further at the root and TLD levels: the resolver sends only its aggregate interests in TLDs to root servers, and only its interests in SLDs to TLD servers. The resolver still sends the aggregate interests in full domain names at the SLD level and below2, and may also include certain client-related information at these levels, such as the client-subnet extension. The lower levels therefore may have different protection objectives than the upper levels.
Minimization techniques and encryption together give DNS designers additional tools for protecting DNS information — tools that when deployed carefully can balance between cryptographic and operational perspectives.
These tools complement those I’ve described in previous posts in this series. Some have already been deployed at scale, such as a DNSSEC with its NSEC and NSEC3 non-existence proofs. Others are at various earlier stages, like NSEC5 and tokenized queries, and still others contemplate “post-quantum” scenarios and how to address them. (And there are yet other tools that I haven’t covered in this series, such as authenticated resolution and adaptive resolution.)
Modern cryptography is just about as old as the DNS. Both have matured since their introduction in the late 1970s and early 1980s respectively. Both bring fundamental capabilities to our connected world. Both continue to evolve to support new applications and to meet new security objectives. While they’ve often moved forward separately, as this blog series has shown, there are also opportunities for them to advance together. I look forward to sharing more insights from Verisign’s research in future blog posts.
Read the complete six blog series:
1. This argument obviously holds more weight for large resolvers than for small ones — and doesn’t apply for the less common case of individual clients running their own resolvers. However, small resolvers and individual clients seeking additional protection retain the option of sending sensitive queries through a large, trusted resolver, or through a privacy-enhancing proxy. The focus in our discussion is primarily on large resolvers.
2. In namespaces where domain names are registered at the SLD level, i.e., under an effective TLD, the statements in this note about “root and TLD” and “SLD level and below” should be “root through effective TLD” and “below effective TLD level.” For simplicity, I’ve placed the “zone cut” between TLD and SLD in this note.
The post Information Protection for the Domain Name System: Encryption and Minimization appeared first on Verisign Blog.
Cryptocurrency enthusiasts are flocking to the Wild West of Bitcoin and Monero to cash in on the recent gold rush. Bitcoin’s meteoric rise in value is making coin mining an appealing hobby or even a whole new career. Coin mining software is the main tool in a prospector’s belt.
Some coin miners, also known as cryptocurrency miners, are tempted by the dark side of the industry and resort to nefarious means to harness the immense computing power needed for cryptocurrency profits. Greedy cryptocurrency criminals employ a practice called cryptojacking, stealing the computer power of unsuspecting devices to help them mine faster. Your device could be at risk at being recruited to their efforts.
Let’s dig into how coin mining programs work, why they turn malicious, and how you can stay safe from cryptojackers.
Mining cryptocurrency takes a lot of time and computer processing power. A coin mining home setup requires a graphics processing unit (GPU) or an application-specific integrated circuit (ASIC). Coin mining software then runs off the GPU or ASIC. Each central processing unit (CPU), or the brain of the computer, plus the GPU or ASIC is referred to as a mining rig.
Once the software is installed, the rig is ready to mine, running mathematical calculations to verify and collect new cryptocurrency transactions. Each calculation is known as a hash, and hash rates are the number of calculations that can be run per second.
From there, casual miners may choose to join a mining pool, which is a club of miners who agree to consolidate their computing power and split the profits based on how much work each miner contributed to the output.
Bitcoin rewards miners every 10 minutes for their efforts. Each time miners solve a string of mathematical puzzles, they validate a chain of transactions, thus helping make the entire Bitcoin system more secure. Miners are paid in bitcoin and they also receive a transactional fee.
While coin mining typically starts off as a casual hobby, coin mining programs can turn malicious when cryptocurrency miners want to earn more without investing in boosting their own computing power. Instead, they reroute their targets’ computing power without asking. This is called cryptojacking.
Mining requires incredible amounts of electricity and the more rigs involved; the more cryptocurrency can be mined. Usually, the utility bills and the cost of running coin mining software negates any profit. For example, a casual miner may have one rig devoted to mining. An average rig processes approximately 500 hashes per second on the Monero network (a type of cryptocurrency). However, 500 hashes per second translates to less than a dollar per week in traditional, or fiat, currency.
Greedy cryptocurrency criminals recruit CPU soldiers to their mining army to improve their hash rate. To do so, criminals download coin mining software to a device and then program it to report back to their server. The device’s thinking power is diverted from the owner and funneled straight to the criminal’s server that now controls it. Compromised devices run considerably slower and can overheat, and the strain on the device can eventually destroy it.
Cryptojackers are not your everyday thieves. Their target is your CPU power, and they employ devious methods to funnel it for their own use. Luckily, there are a few easy ways to thwart their efforts:
Personal devices are often infected through phishing within emails and texts. There are many tell-tale signs of a phishing message. For example, they are often poorly written and use language that indicates that the sender wants a hasty response. Also, phishing attempts often charade as official organizations, like banks and credit card companies. If you are ever suspicious of an email or text, do not open any of the links and do not reply. Instead, contact the organization’s customer support to verify the legitimacy of the message.
Another way miners gain access to personal devices is by camouflaging malicious code in pop-up ads. An easy way to avoid being cryptojacked is to simply never click on these ads. Or even better, install an ad blocker to help eliminate the risk.
Public wi-fi and poorly protected networks present a vulnerable entry point for cybercriminals to hack into your devices. Cybercriminals often attempt to download software remotely to your laptop, desktop, or mobile device to reroute its computing power for their own selfish gains. Always connect to a VPN like McAfee Safe Connect VPN to safely surf unsecure networks.
Cryptojacking code is inconspicuous and generally hidden in legitimate code. Antivirus software, such as McAfee Total Protection, is a recommended way to proactively scan for malware and even identify fraudulent websites. McAfee WebAdvisor has a Chrome extension that specifically blocks cryptojackers.
Be aware of the signs your devices have been cryptojacked. For example, monitor any changes in the speed of your devices and check out your utility bills for dramatic spikes. By remaining vigilant with these tips, you will keep your devices safe from cryptocurrency miners gone rogue.
To stay updated on all things McAfee and on top of the latest consumer and mobile security threats, follow @McAfee_Home on Twitter, subscribe to our email, listen to our podcast Hackable?, and ‘Like’ us on Facebook.
The post Why Coin Miners Go Bad & How to Protect Your Tech When They Do appeared first on McAfee Blogs.
Something you’ll want to know about all those movies, mp3s, eBooks, air miles, and hotel points you’ve accrued over the years: they’re digital assets that can factor into a divorce settlement.
Understandably, several factors determine the distribution of assets in a divorce. However, when it comes to dividing digital assets, divorce settlements and proceedings are charting new territory. The rate of digital innovation and adoption in recent years has filled our phones, tablets, and computers with all manner of digital assets. What’s more, there are also the funds sitting in our payment apps or possibly further monies kept in the form of cryptocurrencies like bitcoin. Put plainly, the law is catching up with regards to the distribution of these and other digital assets like them.
Yet one thing that the law recognizes is that digital assets can have value and thus can be considered property subject to distribution in a divorce.
In light of this, the following is a checklist of considerations that can help prepare you or someone you know for the distribution of digital assets in a fair and just way.
Nothing offered in this article is legal advice, nor should it be construed as such. For legal advice, you can and should turn to your legal professional for counsel on the best approach for you and the laws in your area.
For starters, let’s get an understanding as to what actually constitutes a digital asset.
Because laws regarding digital assets vary (and continue to evolve), the best answer you can get to this question will come from your legal counsel. However, for purposes of discussion, a digital asset is any text or media in digital form that has value and offers the bearer the right to use it.
To put that in practical terms, let’s look at some real-world examples of what could constitute a digital asset. That list includes, but is not limited to:
However, digital assets can readily expand to further include:
And like any other asset in the case of a divorce, a value will be ascribed to each digital asset and then distributed per the conditions or orders of the settlement.
Arriving at the value of specific digital assets begins with an inventory—listing all the digital assets and accounts you own, just as you would with any other monetary or physical assets like bank accounts, properties, and cars. When you go through this process, chances are you’ll quickly find that you have hundreds if not thousands of dollars of digital assets.
For example, we can look at the research we conducted in 2011 which found that people placed an average value of $37,438 on the digital assets they owned at the time. Now, with the growth of streaming services, digital currency, cloud storage, and more in the past ten years, that figure feels conservative.
Above and beyond preparing for a divorce settlement, taking such an inventory of your digital assets is a wise move. One, it provides you with a clearer vision of the things you own and their worth; two, maintaining such a list gives you a basis for estate planning and determining who you would like to see receive those assets. Likewise, maintain that list on a regular basis and keep it safe. It’s good digital hygiene to do so.
With this inventory, each asset can then have an assessed value ascribed to it. In some instances, a value will easily present itself, such as the cost of a subscription or how much money is sitting in a PayPal account. In other cases, the value will be sentimental, such as the case is with digital photos and videos. Ideally, you and your spouse will simply be able to duplicate and share those photos and videos amicably, yet it is important that you articulate any such agreement to do so. This way, a settlement can call out what is to be shared, how it will be shared, and when.
Not all digital assets are transferrable. Certain digital assets are owned solely in your name. In other words, you may have access to certain digital assets that cannot transfer to someone else because you do not have the rights to do so per your user agreement. This can be the case with things such as digital books, digital music, and digital shows and movies.
In such circumstances, there may be grounds for negotiation and a “limited transfer” in the settlement, where one party exchanges one asset for another rather than splitting it equally. A case in point might be a sizeable eBook library on a device that’s in the name of one spouse. While that library can’t be split or transferred, one spouse may keep the eBook library while another spouse keeps a similarly valued asset or group of assets in return—like say a collection of physical books.
Streaming services will need to be addressed too. Be prepared to either terminate your accounts or simply have them assigned to the person in whose name they are kept. In the case of family accounts, the settlement should determine how that is handled, whether it gets terminated or similarly turned over to one spouse or the other. In all, your settlement will want to specify who takes over what streaming service and when that must occur.
Like dividing up investment accounts where the value of the account can vary daily, digital currencies can present challenges when spouses look to divide the holdings. Cryptocurrency valuation can be quite volatile, thus it can be a challenging asset to settle from a strict dollar standpoint.
What’s more, given the nature of digital currencies, there are instances where an unscrupulous spouse may seek to hide worth in such currency—which is an evolving issue in of itself. This recent article, “Cryptocurrency: What to Know Before and During Divorce,” covers the additional challenges of cryptocurrency in detail, along with an excellent primer on what cryptocurrency is and how it works.
Ultimately, cryptocurrency is indeed an asset, one that your attorney and settlement process will need to address, specifically so that there are no complications later with the transfer or valuation of the awarded currency.
With accounts changing hands, now’s the time to start fresh with a new set of passwords. What’s more, we have a tendency to reuse the same passwords over and over again, which may be known to an ex-spouse and is an inherent security risk in of itself. Change them. Even better, take this opportunity to use a password manager. A password manager can create and securely store strong, unique passwords for you, thus saving you the headache of maintaining dozens of them yourself—not to mention making you far more secure than before.
Again, keep in mind that nothing here is legal advice. Yet, do keep these things in mind when consulting with an attorney. The reality is that we likely have thousands of dollars of what could be considered digital assets. Inventorying them and ascribing a fair market value to them along with your legal professional is the first step in a fair and just settlement.
The post Digital Divorce: Who Gets the Airline Miles and Music Files? appeared first on McAfee Blogs.
What do Burger King and the popular “Doge” meme have in common? They both have cryptocurrencies named after their likeliness. WhopperCoin and Dogecoin are just two examples of the thousands of types of cryptocurrencies that have caught users’ attention over the past few years. Cryptocurrencies are digital tokens generated by a computer after solving complex mathematical functions. These functions are used to verify the authenticity of a ledger, or blockchain.
Bitcoin is the most popular cryptocurrency today, increasing its value by almost 300% in 2020. Today, almost 46 million Americans own at least one share of Bitcoin, illustrating how these cryptocurrencies are the future of tomorrow’s digital payment system — or are they? The same benefits that make them a popular choice with online users have also made them popular amongst online thieves, sparking a wave of ransomware attacks and other cyberattacks more recently. This begs the question: do the benefits of Bitcoin outweigh the risks?
Every rose has its thorn, and several Bitcoin benefits seem to be hitched to online security risks. Here are some cryptocurrency characteristics that may seem appealing to users, but also provide cybercriminals with an opportunity to exploit:
As previously mentioned, cryptocurrency exchanges take place on an online public ledger, or blockchain, to secure online transactions. This means that anybody can observe the exchange online. However, the parties making the transactions are anonymous, disguised with a random number. Bitcoin users can make purchases that are never associated with their identity, similar to a cash transaction.
While the purchase discretion provided by Bitcoin may be appealing to users who want to remain private, this characteristic could also aid cybercriminals in malicious activity. Due to the anonymity of Bitcoin transactions, there is no way for someone to associate a person with a certain cryptocurrency wallet. Furthermore, a user could have multiple wallets, allowing them to spread their currency from one address to another.
For a cybercriminal looking to target an individual with ransomware, the purchase discretion and anonymity of Bitcoin provide a favorable solution. In fact, Bitcoin accounts for approximately 98% of ransomware payments today. Say a hacker carries out a ransomware attack and demands that the user pay a large sum in Bitcoin. If the user completes the payment, the hacker can keep moving the currency from one anonymous account to another. That makes it very difficult — though not impossible — to trace if the individual decides to investigate the case and tries to get their money back.
Another characteristic that Bitcoin users find appealing is the autonomy offered by digital currencies. In theory, they allow users more autonomy over their own money than government-regulated currencies do. With Bitcoin, users can control how they spend their money without dealing with an intermediary authority like a bank or government.
This lack of intermediary authority also opens a door for hackers to exploit. Say a user decides that they want to manage their finances using Bitcoin to bypass banking fees and send money to friends and family in different parts of the world. As previously mentioned, a Bitcoin user is assigned an anonymous private key that acts as their security credential. This key is generated and maintained by the user instead of a third-party agency. But what happens if the key isn’t random enough? An attacker could steal the user’s private key, and they will not be able to recover it since the Bitcoin blockchain is not dependent on any centralized third-party institutions. Therefore, it will be very difficult to track the attacker’s behaviors and recover lost funds.
It is safe to say that Bitcoin has caused a lot of buzz. But do the benefits outweigh the risks? Due to the nature of Bitcoin and most other public blockchains, anyone in the world can perform transactions or cryptographic computations — including cybercriminals. That’s why it is crucial for current cryptocurrency users and those considering cryptocurrency investment to do their research and know what vulnerabilities lie within the world of Bitcoin.
Follow these tips to help protect yourself from common threats that leverage cryptocurrency:
With blockchain, cryptocurrency, and any new and emerging technology, make sure you always remain a bit skeptical. Do your homework before you embrace the technology — research your options and make note of any known security issues and what you can do to mitigate known risks.
If a hacker does target you with ransomware demanding Bitcoin payment, it’s best not to pay the ransom. Although you may feel in the moment that this is the only way to get your encrypted files back, there is no guarantee that the ransomware developers will send a decryption tool once they receive the payment. Paying the ransom also contributes to the development of more ransomware families, so it is best to hold off on making any payments. Furthermore, a recent study found that 80% of businesses that choose to pay a ransom experience a subsequent ransomware attack. While it may feel like your only option in the moment, paying a ransom could show attackers that you’re willing to make the payment, therefore positioning you as an ideal target for yet another attack.
If you are targeted with ransomware, it’s crucial that you always have backup copies of your files, preferably in the cloud and on an external hard drive. This way, if you do get a ransomware infection, you can wipe your computer or device and reinstall your files from the backup. Backups protect your data, and you won’t be tempted to reward the hackers by paying a ransom. Backups won’t prevent ransomware, but they can mitigate the risks.
Large organizations often fall prey to ransomware attacks, so take necessary precautions if a company you’ve interacted with becomes compromised from a data leak or a ransomware attack. Immediately change your passwords for all your accounts, ensuring they are strong and unique. You can also employ a password manager to keep track of your credentials and generate secure login keys.
Add an extra layer of security with a solution such as McAfee® Total Protection, which includes Ransom Guard, to help protect your devices from these cyberthreats and ensure your digital wellness online.
The emergence of Bitcoin has indeed facilitated a wave of cybercrime that was previously difficult to perceive. In this new age of digital payments, blockchain, and cryptocurrencies, make sure that you do your research and stay vigilant when it comes to protecting your online safety. Remember: Bitcoin worth will continue to fluctuate, but your personal security will always remain invaluable.
To stay updated on all things McAfee and on top of the latest consumer and mobile security threats, follow @McAfee_Home on Twitter, subscribe to our newsletter, listen to our podcast Hackable?, and ‘Like’ us on Facebook.
The post Do the Benefits of Bitcoin Outweigh the Risks? appeared first on McAfee Blogs.
ns-1200-logo-podcast-with-mic-and-rodent-emoji
Cryptocurrency has boomed in the last several years, with beginners and experts alike jumping into the industry. It’s proven now to be more than a passing hobby or trend. Cryptocurrency is a way of conducting business and making money for people around the world.
As the intrigue and interaction with crypto grows, cybercriminals are finding new ways to exploit the system. According to CNBC, a recent crypto hack resulted in the loss of over $320 million across two major blockchain networks. Here’s what you need to know about this latest breach, plus some tips on how you can protect your crypto assets.
There’s more than one kind of cryptocurrency, and many users spread out their investments across various currencies and blockchain ecosystems. To link their activities, some crypto users employ a type of bridging software that can easily connect their different accounts. Wormhole is a popular bridge that allows users to freely move their tokens and NFTs between the Solana and Ethereum blockchains.
In this recent crypto hack, a cybercriminal installed a bug that minted 120,000 fake currency on the Solana side of the Wormhole bridge. Then, the criminal transferred 120,000 counterfeit currency to the Ethereum side to claim Ethereum tokens. This resulted in the hacker gaining at least $251 million worth of Ethereum, nearly $47 million in Solana, and upwards of $4 million in USDC, a third type of cryptocurrency.
The Wormhole team offered the hacker $10 million to return the stolen currency and explain how they executed the hack. Wormhole has since tweeted that they’ve restored all stolen funds and that the system is now back to normal. Experts think they have successfully reverse-engineered the exploit and suspect that the attacker gained access through bypassing the verify signature process.
As cryptocurrencies continue to take the world by storm, it’s key that users learn how to engage with this emerging industry safely. Even though the Wormhole breach affected the crypto platforms and not individual users, this incident is a reminder to be diligent about your crypto safety. Check out these tips to help you protect your crypto investments:
Like with any process that involves investing your own, hard-earned money, you should be diligent about researching every cryptocurrency, blockchain, and accompanying software you use. Never trust your money to a product or service that you’re not completely confident in their security protocols. Keep up with national and world news and crypto-specific news outlets to stay on top of the latest security breaches and to gather tips on which system may be the safest option for you. When jumping into cryptocurrency, make sure that any benefits outweigh the risks.
As with all your online accounts, protect your cryptocurrency logins with secure, unique passwords and two-factor authentication. Never reuse passwords, since it’s possible for wily cybercriminals to buy lists of login and password combinations on the dark web. Two-factor authentication often makes it impossible for anyone to break into your account, as it requires a randomly generated passcode for entry. Passcodes are often sent by text or through a smartphone application. Sometimes it’s difficult to remember all your passwords, so consider trusting them to a password manager, such as McAfee True Key. An online account locked behind a secure password and two-factor authentication will likely frustrate a cybercriminal and cause them to move along, keeping your account safe.
Add an extra layer of protection to your crypto assets with a hardware wallet. A hardware wallet stores private keys that are necessary to unlock your blockchain accounts. This device is compatible with various blockchains and helps back up and protect your investments, even if your device is compromised by malware or a phishing attack. Hardware wallets are often protected by PINs and a passphrase, so even if the device is lost or stolen, you can feel confident in the safety of your crypto accounts.
Make it part of your weekly routine to check in on your crypto account to ensure that there are no suspicious transactions. Keep the pulse on the news, so that whenever there’s a breach, you can make a timely report of any losses you may have experienced. Also, consider changing your login credentials to be on the safe side.
The only way to enjoy your cryptocurrency experience is to be confident in it. While the Wormhole loophole was almost impossible for a casual everyday user to predict, as long as you have a contingency plan and safeguards in place, you can be confident in your crypto activities.
The post Latest Crypto Vulnerability Leaks $320 Million: 3 Tips to Boost Your Crypto Confidence appeared first on McAfee Blog.
It’s fun to jump on our favorite social media sites such as Facebook, Instagram, or LinkedIn and know we can quickly check in with friends and family, discover interesting content, and instantly connect with colleagues worldwide. The last thing on most of our minds when tapping our way into these familiar online communities is being the target of cybercrime.
But it’s happening more and more.
Last month, The Federal Trade Commission (FTC) described popular social media sites as “goldmines” for malicious attacks. The FTC revealed that more than one in four people who reported losing money to fraud in 2021 said it started on social media with an ad, a post, or a message. More than 95,000 people reported about $770 million in losses to fraud initiated on social media platforms in 2021. According to the FTC, those losses account for about 25 percent of all reported losses to fraud in 2021 and represent a stunning eighteenfold increase over 2017 reported losses.
The social environment is a magnet for bad actors because people of every age and country flock there each day. The constant flow of conversation and content—and more importantly, the climate of trust—makes social networks juicy targets for cybercrime.
The biggest motivation? The emerging digital security threat of cryptojacking (aka illegal cryptomining). Cryptojacking is illegally accessing another person’s computer power to mine cryptocurrency. Cybercriminals do this by getting a victim to click on a malicious link delivered via direct message, a news story, or an ad. Once clicked, that link loads crypto mining code on the victim’s computer or leads them to an infected website or online ad with JavaScript code that auto-executes once it’s loaded in the victim’s browser. Often the malware goes undetected, and the only way a victim might know their system has been compromised is that it may start performing more slowly.
While bad actors use social media platforms to distribute cryptomining malware, they also spread other malware types such as advertisements, faulty plug-ins, and apps that draw users in by offering “too good to be true” deals. Once clicked on, the malware allows cybercriminals to access data, create keyloggers, release ransomware, and monitor social media accounts for future scamming opportunities.
Be sure your kids understand the risks and responsibilities associated with device ownership. Consider putting time aside each week to discuss crucial digital literacy topics and ongoing threats such as cryptomining malware. Consider a “device check-in” that requires each person in your family to “check off” the following security guidelines.
To help protect your family devices from viruses, malware, spyware, and other digital threats entering social media sites, consider adding extra security to your family devices with McAfee Total Protection.
Avoid posting home addresses, full birth dates, employer information, school information, as well as exact location details of where you are.
Install software updates so that attackers cannot take advantage of the latest security loopholes.
Select passwords that will be difficult for bad actors to guess and use different passwords for different programs and devices.
For a virus to solve cryptographic calculations required to mine cryptocurrency requires an enormous amount of computer processing power (CPUs). Cryptojacking secretly consumes a victim’s processing power, battery life, and computer or device memory. Look out for a decline in device processing speed.
Be careful when accepting friend requests, direct messages, or clicking on links sent by someone you don’t know personally. This is one of the most popular ways cybercriminals gain access.
Be discerning even when a known friend sends you a second friend request claiming they’ve been hacked. Search known names on the platform for multiple accounts. Cybercriminals have been known to gather personal details of individuals, pose as that person, then connect with friend lists using familiar information to build trust with more potential victims.
Be sure to report any fraudulent activity you encounter on social platforms to help stop the threat from spreading to other accounts, including friends and family who may be connected back to you.
New scams and more sophisticated ways to steal data—and computer processing power for illegal cryptomining—surface daily. Staying in front of those threats and folding them into your family dynamic is one of the most powerful ways to give your kids the skills and security habits they will need to thrive in today’s digital world.
The post Social Media: How to Steer Your Family Clear of Cryptomining Malware appeared first on McAfee Blog.
A-list celebrities and social media influencers are now adding their voices to the roar of other cryptocurrency fans asking you to join them in the investments of the future. It’s impossible to deny the grip cryptocurrencies have on the world today, for better or worse. In some industries, they speed the pace of business and for some, it’s a viable way to make ends meet and set up long-term investments. The cryptocurrency realm has also proven to be vulnerable to cybercriminals. For example, the Wormhole hack leaked $320 million, and cybercriminals have targeted crypto platforms with ransomware and mining app scams.
Whether you’re already in the cryptocurrency game or are thinking about taking the plunge, here’s what you need to know about crypto wallets and tips on how to keep yours safe from cybercriminals.
A cryptocurrency wallet, or crypto wallet, is a software product or a physical device that stores the public and private keys to your cryptocurrency accounts. Keys are strings of numbers and letters that encrypt and decrypt crypto transactions and secure crypto accounts. You can think of public keys as the routing and account numbers that appear at the bottom of paper checks. There’s not much a nefarious character can do with that information, and it’s totally normal to give that information to an acquaintance with whom you’re doing business. Private keys are like your online banking password or debit PIN. Those you must guard very closely because in the wrong hands, your hard-earned bank balance could disappear. A crypto wallet also allows you to transfer funds between crypto types and make transactions.
Here are a few basic types of crypto wallets to help you decide which type is right for you.
A non-custodial wallet means that you are the sole keeper of the keys to your crypto assets. If you forget your password, there’s no “forgot your password?” prompt to let you back in. While not having this safety net is a little nerve wracking, noncustodial wallets are considered the more secure option. You don’t have to worry about a security breach of a major corporation leaking your private key. If you’re responsible and confident that you’re prepared to look after your assets by yourself, this may be the best option for you.
A custodial wallet is a little less secure, but you have a third party helping you log in and manage your crypto accounts. Custodial wallets are often web-based, and the biggest tick in their pro column is that they’re generally very easy to use. While reputable custodial wallets take security very seriously, the threat of a breach is always a possibility, especially as crypto accounts are appealing targets to cybercriminals.
Hardware wallets, also known as cold wallets, are devices you can fit in the palm of your hand. Most models are Bluetooth-enabled devices that look like small remote controls or are flash drives. The device is secured by a PIN that you should never write down or share with anyone else. Also, you should designate a safe and private spot to store your hardware wallet. Similar to a noncustodial wallet, you are solely responsible for keeping track of the device and remembering the PIN. If you lose it, your crypto accounts are locked, and there’s no locksmith to open them for you. As long as you keep track of it, hardware wallets are very secure. Most models are equipped with malware- and virus-proofing security features.
Software wallets are downloaded and internet-connected mobile or desktop apps. They allow you to make transactions on the run, as you can access your crypto accounts from your phone. In that sense, they’re more convenient than hardware wallets. Additionally, software wallets have the same safety net as custodial wallets: if you lose your phone, forget your password, or require login assistance, the maker of the software can help you access your accounts. Software wallets are very secure when you enable their two-factor authentication login settings; however, since they connect to the internet, there’s always a chance a cybercriminal could break-in. Thus, hardware wallets are considered more secure than the software variety.
Check out these tips to ensure your assets are safe and secure in your crypto wallet:
Cryptocurrency value is reaching galactic heights like the spaceships depicted in prime-time ads. Don’t feel pressured to hop aboard the crypto rocket, but if you do decide to jump on, make sure you do your research carefully and make the best decisions for your crypto goals.
The post What Is a Crypto Wallet and How to Keep Your Wallet Secure? appeared first on McAfee Blog.
If you’re thinking about crypto, one of the first things you’ll want to do is get yourself a good wallet.
Topping the several important things a new cryptocurrency investor needs to think about is security. Rightfully so. Cryptocurrency is indeed subject to all kinds of fraud, theft, and phishing attacks, just like the credentials and accounts we keep online.
But here’s the catch. Lost or stolen cryptocurrency is terrifically difficult to recover. By and large, it doesn’t enjoy the same protections and regulations as traditional currency and financial transactions. For example, you can always call your bank or credit card company to report theft or contest a fraudulent charge. Not the case with crypto. With that, you’ll absolutely need a safe place to secure it. Likewise, in the U.S. many banks are FDIC insured, which protects depositors if the bank fails. Again, not so with crypto.
So, when it comes to cryptocurrency, security is everything.
Cryptocurrency theft offers hackers an immediate payoff. It’s altogether different from, say, hacking the database of a Fortune 500 company. With a data breach, a hacker may round up armloads of personal data and information, yet it takes additional steps for them to translate those stolen records into money. With cryptocurrency theft, the dollars shift from the victim to the crook in milliseconds. It’s like digital pickpocketing. As you can guess, that makes cryptocurrency a big target.
And that’s where your wallet will come in, a place where you store the digital credentials associated with the cryptocurrency you own. The issue is doing it securely. Let’s take a look at the different wallets out there and then talk about how you can secure them.
Broadly, there are two general categories of wallets. First, let’s look at what these wallets store.
A wallet contains public and private “keys” that are used to conduct transactions. The public key often takes the form of an address, one that anyone can see and then use to send cryptocurrency. The private key is exactly that. Highly complex and taking many forms that range from multi-word phrases to strings of code, it’s your unique key that proves your ownership of your cryptocurrency and that allows you to spend and send crypto. Needless to say, never share your private key.
With that, there are two ways to store your keys—in a hot wallet or a cold wallet.
Hot Wallets:
|
Cold Wallets:
|
As you can see, the benefit of a hot wallet is that you can load it up with cryptocurrency, ready for spending. However, it’s the riskiest place to store cryptocurrency because it’s connected to the internet, making it a target for hacks and attacks.
In addition to that, a hot wallet is connected to a cryptocurrency exchange, which makes the transfer of cryptocurrencies possible. The issue with that is all cryptocurrency exchanges are not created equal, particularly when it comes to security. Some of the lesser-established exchanges may not utilize strong protocols, likely making a target for attack. Even the more established and trusted exchanges have fallen victim to attacks—where crooks have walked away with millions or even hundreds of millions of dollars.
While the funds in cold wallets are far less liquid, they’re far more secure because they’re not connected to the internet. In this way, cold wallets are more vault-like and suitable for long-term storage of larger sums of funds. But cold wallets place a great deal of responsibility on the holder. They must be stored in a physically secure place, and be backed up, because if you lose that one device or printout that contains your cryptocurrency info, you lose the cryptocurrency altogether. Within the cold wallet category, there are a few different types:
Several manufacturers make storage devices specifically designed to store cryptocurrency, complete with specific features for security, durability, and compatibility with many (yet not always all) of the different cryptocurrencies on the market. An online search will turn up several options, so doing your homework here will be very important—such as which devices have the best track record for security, which devices are the most reliable overall, and which ones are compatible with the crypto you wish to keep.
Storing cryptocurrency information on a computer or laptop that’s disconnected from the internet (also known as “air-gapped”) is a storage method that’s been in place for some time. However, because computers and laptops are complex devices, they may be less secure than a simpler, purpose-built cryptocurrency device. In short, there are more ways to compromise a computer or laptop with malware that a determined hacker can use to steal information in some rather surprising ways. (Like noise from a compromised computer fan passing information in a sort of Morse Code or generating electromagnetic signals on a compromised computer that nearby devices can use to skim information.)
Ah, good old paper. Write down a code and keep it secure. Simple, right? In truth, creating a paper wallet can be one of the most involved methods of all the cold storage options out there. Bitcoin offers a step-by-step walkthrough of the process that you can see for yourself. Once done, though, you’ll have a piece of paper with a public address for loading cryptocurrency into your paper cold wallet, along with a private key. One note: Bitcoin and others recommend never reusing a paper cold wallet once it’s connected to a hot wallet. You should go through the process of creating a new cold paper wallet each time.
Physical coins are a special case and are relatively new on the scene. They’re a physical coin minted with a tamper-resistant sticker that indicates the actual value of the coin. Like other methods of cold wallet storage, this calls for keeping it in a safe place, because it’s pretty much like a wad of cash. And like cash, if it’s stolen, it’s gone for good. Also note that a cryptocurrency holder must work with a third party to mint and deliver the coin, which has its own costs and risks involved.
With that look at wallets, let’s see what it takes to secure them. It may seem like there’s plenty to do here. That’s because there is, which goes to show just how much responsibility falls on the shoulders of the cryptocurrency holder. Of course, this is your money we’re talking about, so let’s dive into the details.
Whatever form your storage takes, back it up. And back it up again. Cryptocurrency holders should make multiple copies just in case one is lost, destroyed, or otherwise inaccessible. For example, one story that’s made the rounds is of a IT engineer in the UK who accidentally threw away an old hard drive with his cryptocurrency key on it, one that held 7,500 bitcoins, worth millions of dollars. Redundancy is key. Back up the entire wallet right away and then often after that.
With redundant backups in place, store them in places that are physically secure. It’s not uncommon for crypto holders to use fireproof safes and safe deposit boxes at banks for this purpose, which only highlights the earlier point that a wallet is as good as cash in many ways.
This will help prevent malware from stealing crypto, whether or not your device is connected to the internet. Comprehensive online protection software will give you plenty of other benefits as well, including identity theft monitoring and strong password management, two things that can help you protect your investments, and yourself, even further.
Updates often address security issues, ones that hackers will of course try to exploit. Keep everything current and set automatic updates wherever they are available so that you have the latest and greatest.
Just as your bank and other financial accounts offer MFA, do the same here with your crypto. Some extra security-conscious crypto investors will purchase a device for this specific purpose for yet greater protection, such as a separate phone with texting capability. This keeps their crypto transactions separate from the multitude of other things they do on their everyday smartphone, effectively putting up a wall between these two different digital worlds.
Two things fall under this category. One, the less you say about the crypto investments you make, the less word gets around, which can help keep hackers out of the loop. Particularly on social media! Two, consider setting up a unique email account that you only use for crypto. The less you associate your crypto accounts with other financial accounts like your banking and online payment apps, the more difficult it is to compromise several accounts in one fell swoop.
Just like hackers send phishing emails with an eye on accessing your bank accounts, credit cards, and so on, they’ll do much the same to get at your crypto accounts. The target may be different, that being your crypto, but the attack is very much the same. An email will direct you to a hacker’s website, using some sort of phony pretense, get-rich-quick-scheme, or scare tactic. Once there, they’ll ask for private key information and then simply steal the funds. And it’s not just email. Hackers have used online ads to phish for victims as well.
As you can see, these security measures rely almost exclusively on you. If something happens to you, that could make recovering your funds a real problem. Consider reaching out to someone you trust and let them know where you’re storing your wallets and information. That way, you’ll have some assistance ready in the event of an emergency or issue.
The very things that define cryptocurrency—the anonymity of ownership, the lack of banking institutions, the light or non-existent regulation—all have major security implications. Add in the fact that you’re your own safety net here and it’s easy to see that crypto is something that requires plenty of planning and careful through before diving into. Getting knowledgeable about security, how you’ll protect your crypto, should absolutely top your list before investing.
The post Cold Wallets, Hot Wallets: The Basics of Storing Your Crypto Securely appeared first on McAfee Blog.
cat-1200
Cryptocurrency is all the rage these days and it doesn’t seem to be slowing down any time soon. As more people dive into the nitty-gritty of what blockchain is, how NFTs are traded, and the difference between Bitcoin and Ethereum, digital currency developers are finding new ways for people to engage with crypto. But as crypto continues to grow and become more profitable, hackers are simultaneously trying to find ways to get their hands on the coins.
According to Markets Insider, one of the biggest crypto heists in history took place recently, resulting in roughly $625 million stolen.1 Here’s what you need to know about this crypto theft, and how you can stay protected when investing in digital assets.
Ronin, the blockchain underlying the play-to-earn crypto game Axie Infinity, revealed that a hacker stole 173,600 Ethereum (currently worth around $600 million) and 25.2 million USDC (a cryptocurrency pegged to the U.S. dollar), resulting in a loss of about $625 million in cryptocurrency.
On March 29th, Ronin and Axie Infinity operator Sky Mavis revealed the breach and froze transactions on the Ronin bridge, which allows depositing and withdrawing funds from the company’s blockchain. This “side chain” contained nine validator nodes, or proof-of-stake tools, that confirmed and approved each transaction. At least five validator nodes are needed to approve each transaction. Sky Mavis oversaw five, and Axie Decentralized Autonomous Organization (or DAO) controlled four. However, Sky Mavis discontinued its agreement with the DAO in December but failed to revoke the DAO’s permissions. Due to this oversight, the hacker was able to take over the necessary amount of validator nodes to enable access to the cryptocurrency and make a break with it.
According to experts, the use of these side chains rather than native blockchains leads to a rise in cryptocurrency vulnerabilities. Had Sky Mavis abandoned the side chains and stuck to the blockchains, it is likely that an attack of this magnitude could have been avoided. Rather than a cryptocurrency issue, this is more of a cybersecurity issue.
If you are interested in getting into crypto, don’t let cyberattacks like this deter you! As a fairly new phenomenon, there are still many ways in which the crypto world needs to grow, adjust, and adapt to ensure that users can interact with it safely. In the meantime, if you are wanting to dive into the crypto economy but still have reservations, here are some tips to help you stay protected:
Whenever you decide to dive into something new, it’s always important to make sure you are knowledgeable about that thing, especially if it involves investing your money. Before jumping right into the crypto world, research each cryptocurrency, each blockchain, and any software you may use. Keep up with the news to stay informed on security breaches and pick up tips for which system you may want to engage in. Knowing the ins and outs of the crypto economy and its security protocols will solidify your decision of whether you want to join the crypto community and whether the benefits outweigh the risks.
As with all online accounts, it’s important to use secure, unique passwords and two-factor authentication when creating and maintaining cryptocurrency logins. Hackers can access lists of passwords and logins via the dark web, so never reuse your passwords. Two-factor authentication requires a randomly generated passcode for entry that is only accessible to you, so cybercriminals will not be able to access your accounts. If your accounts are a pain for a hacker to try to get through, they will likely move on, keeping your account, your information, and your assets safe.
For some added protection, store your assets in a crypto wallet. A crypto wallet is a software product or physical device that stores the keys to your cryptocurrency accounts. Crypto wallets allow you to transfer funds between crypto types and make transactions while keeping your investments protected. There are various types of cryptocurrency wallets, so do your research to find which one is best for you and your accounts.
Develop a routine of checking in on your crypto accounts to keep an eye on any suspicious transactions. Keep up with news outlets so that if there does happen to be a breach, you can make a timely report of any losses you may have had. For some added security and protection, consider changing your login credentials.
Hackers often use social engineering to enact cyberattacks like these. This includes targeting users’ emails or using phishing to gain access to these accounts. When receiving emails, be wary of addresses that seem slightly off, odd spelling and grammar mistakes, and any links or attachments added to the message. Being cautious and alert when you are online is an important step to ensuring your account safety.
As the world of crypto continues to evolve and more people get involved, cybercriminals are itching to take advantage. However, that is no reason to avoid getting into the crypto economy. If you decide to try your hand at digital currencies, make sure you are doing your research, staying up to date on what is happening in the crypto news, and remaining vigilant when it comes to your online safety.
The post $625 Million Stolen in Latest Crypto Attack: 5 Tips on How to Use Digital Currency Safely appeared first on McAfee Blog.
By Oliver Devane
Editors note: In the past 24 hours (from time of publication) McAfee has identified 15 more scam sites bringing the total to 26. The combined value of the wallets shared on these sites is over $1,300,000 which is an increase of roughly $1,000,000 since this blog was last published. This highlights the scale of this current scam campaign. The table within this blog has been updated to include the new sites and crypto-wallets.
McAfee has identified several Youtube channels which were live-streaming a modified version of a live stream called ‘The B Word’ where Elon Musk, Cathie Wood, and Jack Dorsey discuss various aspects of cryptocurrency.
The modified live streams make the original video smaller and put a frame around it advertising malicious sites that it claims will double the amount of cryptocurrency you send them. As the topic of the video is on cryptocurrency it adds some legitimacy to the websites being advertised.
The original video is shown below on the left and a modified one which includes a reference to a scam site is shown on the right.
We identified several different streams occurring at a similar same time. The images of some are shown below:
The YouTube streams advertised several sites which shared a similar theme. They claim to send cryptocurrency worth double the value which they’ve received. For example, if you send 1BTC you will receive 2BTC in return. One of the site‘s frequently asked questions (FAQ) is shown below:
Here are some more examples of the scam sites we discovered:
The sites attempt to trick the visitors into thinking that others are sending cryptocurrency to it by showing a table with recent transactions. This is fake and is generated by JavaScript which creates random crypto wallets and amounts and then adds these to the table.
The wallets associated with the malicious sites have received a large number of transactions with a combined value of $280,000 as of 5 PM UTC on the 5th of May 2022
| Scam Site | Crypto Type | Wallet | Value as on 5PM UTC 5th May 2022 |
| 22ark-invest[.]org | ETH | 0x820a78D8e0518fcE090A9D16297924dB7941FD4f | $25,726.46 |
| 22ark-invest[.]org | BTC | 1Q3r1TzwCwQbd1dZzVM9mdFKPALFNmt2WE | $29,863.78 |
| 2xEther[.]com | ETH | 0x5081d1eC9a1624711061C75dB9438f207823E694 | $2,748.50 |
| 2x-musk[.]net | ETH | 0x18E860308309f2Ab23b5ab861087cBd0b65d250A | $10,409.13 |
| 2x-musk[.]net | BTC | 17XfgcHCfpyYMFdtAWYX2QcksA77GnbHN9 | $4,779.47 |
| arkinvest22[.]net | ETH | 0x2605dF183743587594A3DBC5D99F12BB4F19ac74 | $11,810.57 |
| arkinvest22[.]net | BTC | 1GLRZZHK2fRrywVUEF83UkqafNV3GnBLha | $5,976.80 |
| doublecrypto22[.]com | ETH | 0x12357A8e2e6B36dd6D98A2aed874D39c960eC174 | $0.00 |
| doublecrypto22[.]com | BTC | 1NKajgogVrRYQjJEQY2BcvZmGn4bXyEqdY | $0.00 |
| elonnew[.]com | ETH | 0xAC9275b867DAb0650432429c73509A9d156922Dd | $0.00 |
| elonnew[.]com | BTC | 1DU2H3dWXbUA9mKWuZjbqqHuGfed7JyqXu | $0.00 |
| elontoday[.]org | ETH | 0xBD73d147970BcbccdDe3Dd9340827b679e70d9d4 | $18,442.96 |
| elontoday[.]org | BTC | bc1qas66cgckep3lrkdrav7gy8xvn7cg4fh4d7gmw5 | $0.00 |
| Teslabtc22[.]com | ETH | 0x9B857C44C500eAf7fAfE9ed1af31523d84CB5bB0 | $27,386.69 |
| Teslabtc22[.]com | BTC | 18wJeJiu4MxDT2Ts8XJS665vsstiSv6CNK | $17,609.62 |
| tesla-eth[.]org | ETH | 0x436F1f89c00f546bFEf42F8C8d964f1206140c64 | $5,841.84 |
| tesla-eth[.]org | BTC | 1CHRtrHVB74y8Za39X16qxPGZQ12JHG6TW | $132.22 |
| teslaswell[.]com | ETH | 0x7007Fa3e7dB99686D337C87982a07Baf165a3C1D | $9.43 |
| teslaswell[.]com | BTC | bc1qdjma5kjqlf7l6fcug097s9mgukelmtdf6nm20v | $0.00 |
| twittergive[.]net | ETH | 0xB8e257C18BbEC93A596438171e7E1E77d18671E5 | $25,918.90 |
| twittergive[.]net | BTC | 1EX3dG9GUNVxoz6yiPqqoYMQw6SwQUpa4T | $99,123.42 |
Scammers have been using social media sites such as Twitter and Youtube to attempt to trick users into parting ways with their cryptocurrency for the past few years. McAfee urges its customers to be vigilant and if something sounds too good to be true then it is most likely not legitimate.
Our customers are protected against the malicious sites detailed in this blog as they are blocked with McAfee Web Advisor
| Type | Value | Product | Blocked |
| URL – Crypto Scam | twittergive[.]net | McAfee WebAdvisor | YES |
| URL – Crypto Scam | tesla-eth[.]org | McAfee WebAdvisor | YES |
| URL – Crypto Scam | 22ark-invest[.]org | McAfee WebAdvisor | YES |
| URL – Crypto Scam | 2xEther[.]com | McAfee WebAdvisor | YES |
| URL – Crypto Scam | Teslabtc22[.]com | McAfee WebAdvisor | YES |
| URL – Crypto Scam | elontoday[.]org | McAfee WebAdvisor | YES |
| URL – Crypto Scam | elonnew[.]com | McAfee WebAdvisor | YES |
| URL – Crypto Scam | teslaswell[.]com | McAfee WebAdvisor | YES |
| URL – Crypto Scam | 2x-musk[.]net | McAfee WebAdvisor | YES |
| URL – Crypto Scam | doublecrypto22[.]com | McAfee WebAdvisor | YES |
| URL – Crypto Scam | arkinvest22[.]net | McAfee WebAdvisor | YES |
The post Crypto Scammers Exploit: Elon Musk Speaks on Cryptocurrency appeared first on McAfee Blog.
FreshRSS 