You are watching news of Coinbase. Go back to all news.
-
View all news of Coinbase
Posted on August 16, 2019Post Mortem: A closer look at a password storage issue affecting 3,420 customers
We recently began emailing 3,420 Coinbase customers to let them know that a bug on our signup page resulted in some registration details being stored in clear text in our internal web server logs. While we are confident that we’ve fixed the root cause and that the logged information was not improperly accessed, misused, or compromised, we are requiring those customers to change their passwords as a best-practice precaution.
Here’s what happened
Under a very specific and rare error condition, the registration form on our signup page wouldn’t load correctly, which meant that any attempt to create a new Coinbase account under those conditions would fail. Unfortunately, it also meant that the individual’s name, email address, and proposed password (and state of residence, if in the US) would be sent to our internal logs.
If the individual reloaded the page and then submitted the form for a successful registration, their registration information would (correctly) not be logged, and the password would be securely hashed. However, in the 3,420 instances referenced above, the user successfully registered using a password with a hash that matched the one previously logged.
Here’s how we responded
After we identified and fixed the bug, we traced back all the places where these logs might have ended up. We have an internal logging system hosted in AWS, as well as a small number of log analysis service providers. Access to all of these systems is tightly restricted and audited. A thorough review of access to these logging systems did not reveal any unauthorized access to this data. Additionally, we triggered a password reset for impacted customers, even though a password alone is not sufficient to access a Coinbase account — our device verification emails and mandatory 2FA mechanisms would both have been triggered and blocked any unauthorized login attempts.
The technical details
The Coinbase front-end web app is built using the React.js framework and leverages React’s Server Side Rendering (SSR) for key pages (including /signup). SSR means that, instead of sending a barebones HTML page and depending on React to fully populate it in the browser, we send a partly rendered page from the server and let React put the finishing touches on in the browser. We use SSR in order to give searchable content to search engine crawlers, which generally don’t run Javascript. Any user attempting to register needs to have JavaScript enabled, and needs to have that JavaScript load correctly. In virtually all circumstances, both of these things are true, and React handles form validation and submission to the server. However, if a user had JavaScript disabled or their browser received a React.js error when loading, there was enough pre-rendered HTML that a user could fill out and attempt to submit our registration form.
The HTML form itself was extremely basic, since we expected that the details would be filled in by React: <form>[list of fields]</form>. This had two implications for default behavior:
- Because no “action” attribute was set, the official behavior defined in the W3C specification was “undefined”. In practice, however, some browsers will set “action” to the current URI and make a best effort to submit the form.
- Because the “method” was not set, per W3C specification the browser defaulted to GET, which meant that, all form variables were URL encoded and appended as a query string to submit data to the server, e.g in the pattern /signup?first_name=Alice&last_name=Smith&email=alice%40example.com&password=password
This query string then ended up in our logs. The fix itself was simple and straightforward: we changed the default form method to POST, as data submitted in the request body (instead of a query string) is not logged: <form method=”POST”>[list of fields]</form>. We also searched the rest of our repository for any other forms with that problematic behavior, and did not identify any. We’re also in the process of implementing additional mechanisms to detect and prevent the inadvertent introduction of this sort of bug in the future.
Conclusion
We maintain incredibly high standards for securing the Coinbase platform, and any time we fall even slightly short of those standards, we mobilize a team to figure out what went wrong, and how we prevent it from happening again. We also believe in being transparent with our customers, which is why we’re sharing the results of our investigation today.
As a reminder, Coinbase also maintains an active bug bounty program on HackerOne, which has paid out over a quarter of a million dollars to date: https://hackerone.com/coinbase. While this particular bug was discovered internally, we welcome security researchers to submit reports any time they believe they may have uncovered a flaw in one of our systems.
Post Mortem: A closer look at a password storage issue affecting 3,420 customers was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on August 15, 2019Coinbase Custody acquires Xapo’s institutional business, becoming the world’s largest crypto…
Coinbase Custody acquires Xapo’s institutional business, becoming the world’s largest crypto custodian
Crossing $7 billion in assets under custody, Coinbase Custody is now the most popular and trusted choice for institutions to store cryptocurrency.
Today, we are announcing that Coinbase Custody has completed an acquisition of Xapo’s institutional businesses. This acquisition caps off a tremendous period of growth and innovation for Coinbase Custody. In just over one year since launch, Coinbase Custody has grown to over $7 billion in Assets Under Custody (AUC) stored on behalf of more than 120 clients in 14 different countries, making it the largest, most globally recognized and most trusted institutional custodian in the world. From the start, our goal has been to build the trusted foundation for institutional investment in Bitcoin (BTC) and crypto assets in general. We’re thrilled to help enable some of the tremendous demand for this emerging asset class.
Xapo has long been a pioneer in the storage of crypto assets, leading the industry in the creation of security techniques that have kept their customers’ cryptocurrency safe since 2014. Xapo was founded with the mission of making Bitcoin more secure and accessible. Coinbase will extend Xapo’s legacy and bring it yet another step closer to achieving its mission.
Since 2012, Coinbase has served as the world’s onramp to Bitcoin and many other cryptocurrencies. Through our consumer products, Coinbase has helped more people experience their first crypto transactions than any other company. Like Xapo, we share the goal of making Bitcoin and other cryptocurrencies accessible in a way that’s secure, safe and compliant with local laws. Through the acquisition of Xapo’s institutional businesses, we’re now proud to act not only as the gateway for millions of people to cryptocurrency, but also as the world’s largest and most trusted steward of digital assets. Xapo has been a tremendous flagbearer for Bitcoin and the economic equality it can offer to billions across the globe. We’re honored to carry this flag onward.
Looking forward, our focus will stay on our clients. We work every day to provide them true peace-of-mind in knowing that their assets are safe and accessible. In addition to custody, we’re excited to explore new ways to monetize and leverage crypto assets such as staking, borrowing against crypto portfolios and lending crypto to trusted counterparties.
Coinbase is committed to serving a wide spectrum of institutional clients including hedge funds, family offices, endowments and proprietary trading desks as they decide to onboard crypto. Our institutional range of products provides a seamless, powerful and compliant ecosystem for our clients to trade, store and interact with their crypto. The suite combines access to the world’s largest pool of regulated, verified crypto liquidity through Coinbase Pro with high performance APIs and a high-touch coverage team. Paired with access to our global OTC trading desk and Coinbase Custody’s highly secure and insured storage platform, Coinbase delivers the trust, security, and performance needed by investors to trade with confidence.
It’s with huge pride that we welcome Xapo’s Institutional customers to Coinbase. Their legacy, knowledge and experience will help to make our mission of creating an open financial system for the world a reality.
About Xapo: Xapo is a New York DFS-regulated entity (NY Bitlicense holder) and a Gibraltar-licensed E-money institution, that offers a multi-currency digital wallet and card that operates in the global market. Their mission is to give users from all over the world the ability to send, receive, spend and store their money, globally and safely. Their team value proposition ‘Impact Globally, Work Remotely’ is represented by a workforce of over 250 team members, who are globally distributed across more than 50 countries.
This website may contain links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.
Unless otherwise noted, all images provided herein are by Coinbase.
Coinbase Custody acquires Xapo’s institutional business, becoming the world’s largest crypto… was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on August 14, 2019USDC payment processing in Coinbase Commerce
Using non-custodial smart contracts to process ERC20 payments at scale
Table of Contents
— Intro
— How Coinbase Commerce works — 30k foot overview
— Non-custodial by design
— Naïve solution — Forwarding contracts
— Reducing transaction sizes
— Optimizing for off-chain whenever possible
— Minimizing deployment costs
— ConclusionCoinbase Commerce’s mission is to be the easiest way for businesses to accept cryptocurrencies. We launched in February of 2018 supporting BTC, ETH, LTC, and BCH, making it simple for anyone to start accepting cryptocurrencies in a couple of minutes. While our merchants love the ability to instantly transact with customers anywhere in the world, many have expressed concerns with the volatility of cryptocurrencies given fiat-denominated business costs.
Unlike traditional cryptocurrencies, stablecoins such as USD Coin (USDC) are explicitly designed to avoid this volatility. We released USDC support a couple months ago, enabling a volatility-free way for our merchants to accept cryptocurrencies. USDC is backed one-to-one by US dollars, giving it a stable price and making it a great option for commerce. USDC is implemented as an ERC20 token, living on the Ethereum blockchain. Here, I will discuss the approach we took to support USDC on our platform. This post is aimed for anyone who is interested in the internals of Coinbase Commerce. It is particularly useful for dapp developers that might find the ideas and implementations around create2 and minimal proxy contracts relevant to their work.
A customer paying with USDC using Coinbase Commerce’s point of sale How Coinbase Commerce works — 30k foot overview
When a customer wants to pay to a Coinbase Commerce merchant, we create a charge object that keeps track of what the customer wants to buy, how much it costs, the blockchain address they need to pay to, and other metadata. We generate a unique blockchain address for each charge, which serves as a canonical identifier for the charge and the payments made to it. When a customer pays a charge, they do so by sending funds from any wallet or exchange to one of those addresses. By continuously monitoring the blockchain for payments to these addresses, we know if the customer paid the charge and how much they paid, which drives the charge’s completion and the sending of the appropriate webhooks and emails.
This chart represents the life-cycle of a charge where Coinbase Commerce generates unique addresses for each charge. Once a payment is detected on the blockchain, Coinbase Commerce detects it and sends the appropriate notifications. Our workflow — generating a unique address, having the customer pay to that address, and having our system detect that payment on the blockchain — is only one way a blockchain payments processor can be engineered. Other workflows are based on the JSON Payment Protocol, where the customer’s wallet sends an RPC call to the processor’s servers and exchange the necessary info to conduct the payment. Yet another approach would be to use the ETH’s Web3 interface to ask the customer to sign a custom, non-standard transaction. While these approaches have unique benefits, for us it was very important to keep the simple, address-only interface. A vast majority of our customers use an exchange or a hosted wallet, and therefore can only send funds to an address — they do not have the option to initiate RPC calls or sign custom transactions. It was therefore paramount for us that our solution cannot require anything but simple address that everyone can use and send their payments to.
Non-custodial by design
Part of Coinbase Commerce’s value proposition is that we operate as a non-custodial service, meaning that we do not act as a middle man and that all transactions are directly between the customers and our merchants. Being non-custodial means that no one (including Coinbase Commerce) can prevent the movement of funds once a payment has been initiated. We never let any private keys hit our servers, and therefore we do not have the ability to censor or revert a transaction. There are some tradeoffs that come with being a non-custodial solution. On the positive side, this means that:
- It increases the decentralization
- It increases interoperability with other wallets and tools
- It lowers the risks of using the service
However, there are some downsides that we’ve tried to mitigate:
- Accidental loss of private keys (recoverable if you use the encrypted backup feature)
- Hard to automate certain activities such as refunds or scheduled withdrawals
The Coinbase Commerce servers never have access to the private keys (ie. mnemonic). All sensitive actions are performed locally on the merchant’s device. Only signed transactions are sent back to the servers for broadcasting to the blockchain. Given this context on how Coinbase Commerce works, let’s dive into the design and implementation of our USDC solution. I will start with a naïve solution that conveys the general idea, and iteratively address its short-comings, ultimately getting to the production version we use today at Coinbase Commerce. I’ll introduce a couple of techniques — factory pattern, create2 opcode, minimal proxy contracts — which make deploying ETH contracts feasible at scale. These techniques could be used in a variety of business settings.
Naïve solution — Forwarding contracts
Our solution is based on the following idea: We create smart contracts that can accept funds as if they were ordinary accounts, with the sole functionality of forwarding the accepted funds to a fixed, predetermined address that belongs to the merchant. That way, the customers can still use the simple address-only interface to pay, and the merchants can be certain that their funds cannot be misused by anyone. In fact, both the customers and the merchants might not be aware that a smart contract logic is involved at all! Here is one such Forwarder contract:
While the contract achieves our requirements, creating a production system out of these Forwarders is infeasible. For each merchant who has enabled USDC payments, we would need to preemptively deploy multiple forwarders to the blockchain to ensure that there is an available pool of addresses when a customer initiates a payment flow. After we detect a payment to one of the deployed contracts, we (or the merchant) can call the flush function to forward the tokens to the merchant’s destination and finalize the movement of funds.
The life-cycle of a naïve ERC20-based payment flow. We eagerly deploy Forwarders that can later be used in charges. Once a Forwarder receives tokens, anyone (in this case Coinbase Commerce) can call its flush function to move the funds to the final destination and finalize the funds movement. However, managing these pools is quite expensive (each contract creation requires gas fees to be published on the blockchain), very cumbersome and causes unnecessary congestion of the network, making them a non-starter for any production setting.
Reducing transaction sizes
The cost of an Ethereum transaction is primarily tied with the complexity of the logic executed in that transaction — the more CPU time a transaction needs to process its logic, the more gas the transaction will consume. However, for contracts that perform repetitive, simple tasks, the transaction costs are dominated by the space used by the transaction, rather than its runtime logic.
The factory pattern significantly helps reduce the cost of these transactions. Instead of encoding the same logic multiple times when deploying a new Forwarder, we can deploy a single ForwarderFactory that knows how to instantiate new Forwarders. We no longer need to duplicate the full source code every time we deploy a Forwarder — instead we can encode only a pointer to the already deployed code. This results in 47% reduction of gas cost; and indeed, the naïve transaction with its full implementation weighs 1783 bytes, where the factory transaction that contains only the function arguments weighs only 175 bytes.
Optimizing for off-chain whenever possible
A byproduct of the factory that deploys the Forwarders is that we are now able to compute the addresses of the Forwarders before we deploy them to the blockchain. This enables the same user experience as preemptively deploying a forwarding contract for each merchant, without incurring the expense of deploying these contracts on the blockchain.
In Ethereum, the addresses of the created contracts are deterministic — they can be computed from the sender’s address (i.e. the account that created the contract, in our case the factory) and the sender’s nonce (a counter tracking how many transactions originated from that account). However this does not work well in practice because the nonce is an ever increasing global counter. If a customer pays to the 100th generated address, we’d still need to deploy the initial 99 contracts so we can deploy the expected, 100th Forwarder, and we’d need to do that in a determined order. Gaps like these, when we’d need to deploy contracts just to get to the expected nonce, are inevitable because customers might create a charge but never pay a charge.
This is a problem that has plagued the Ethereum community for a long time and has been on the wishlist for many dapp developers. Fortunately, the introduction of the create2 opcode in the Constantinople network upgrade addressed this issue. Unlike create, which uses the ever-increasing sender’s nonce, create2 uses an argument-specified salt. This enables a number of workflows that were impossible or impractical before — we can now simulate complex workflows completely off-chain; without needing to track any state beyond the self-generated salt. We can safely interact with the blockchain only when we need to do an on-chain settlement. Here is how we can use the create2 opcode to deploy a Forwarder.
Note that now initForwarder takes additional salt where before its functionality was performed by the implicit nonce. This allows us to explicitly decide which contracts to deploy on the blockchain, so if the 100th customer pays but the initial 99 do not, we can deploy the 100th forwarder in the sequence without needing to deploy the initial 99 first.
It’s informative to see the code that calculates the addresses:
In addition to the use of a salt, a crucial safety feature in the address generation algorithm is the use of the bytecode. Having the bytecode as one of the arguments ensures that it is impossible to deploy the “wrong” contract at the indicated address. For our example, this implies that there is exactly one combination of destination and salt that can lead to a contract being deployed at a computed address. It is impossible for a malicious attacker to deploy a contract of their own logic or their destination to an address we already computed. Therefore, we can present these non-deployed addresses to the customers and be certain that an attacker could not out-race us by deploying a contract of their own choosing to that particular address.
This enables novel workflows like the one we use at Commerce. It is now possible to create and simulate immutable workflows fully off-chain, and only do the “settlement” stage on the blockchain, after the customer has already paid for their invoice.
Minimizing deployment costs
We can further reduce the cost of our solution by using another novel technique called minimal proxy contracts. The minimal proxy contracts allow the deployment of a contract that is an exact copy of another existing contract, but is extremely light-weight to deploy. They represent the symlinks of the Ethereum blockchain — they have their own address, but they defer all of their functionality to the original contract they point to. These proxy contracts include carefully crafted, “magic” bytecode that changes the execution stack and uses the delegatecall opcode to delegate the implementation to the target contract. In our case, instead of deploying a new Forwarder whenever a customer pays to the same merchant, we can deploy a single Forwarder for that merchant and use its clones from that point onwards. Using clones reduces the gas cost by further 61% over the factory solution.
You can see the contracts we use in production here. The link hints at a couple of the downsides of the approach we have taken:
- Reduced privacy due to the singleton factory
- Increasing the minimal settlement time due to the extra flush call
This chart shows the final architecture of the forwarding contracts. Each merchant has their dedicated Forwarder (initialized with their destination), and a number of Forwarder clones (each clone associated with a particular charge). The contracts can be deployed (blue) or not deployed (yellow), but we can still safely calculate and use their addresses. The factory, create2 opcode, and the minimal proxy contracts are patterns that can be applied for a wide range of circumstances. At Coinbase Commerce, we applied these patterns to make the movement of funds as simple and cheap as possible, but any other workflow that needs to simulate interactions with a number of contracts while only deploying a subset could benefit from them.
A lot of patterns in blockchain engineering enable novel workflows, but these patterns come with their own gotchas and surprises. As a young ecosystem, its documentation and best practices lag behind the advancements made at the protocol level.
The USDC forwarding is a great example of our daily work on crypto technologies as well as the interesting challenges of building complex, production systems. If you enjoy working in a fun, high energy environment and want to work on making accepting cryptocurrencies easy, then checkout all open positions here. We’d love to hear from you.
This website contains links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.
All images provided herein are by Coinbase.
USDC payment processing in Coinbase Commerce was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on August 9, 2019Algorand (ALGO) is launching on Coinbase Pro
On Wednesday, August 14 after 10am PT, transfer ALGO into your Coinbase Pro account ahead of trading. Support for ALGO will be available in Coinbase’s supported jurisdictions, with the exception of New York State. Additional regions may be added at a later date. Per previous launches, transfers will open during business hours, Pacific time.
On Wednesday, August 14, 2019 after 10am PT, we will begin accepting inbound transfers of ALGO to Coinbase Pro. We will accept deposits for at least 12 hours prior to enabling full trading, which will occur during business hours, Pacific time.
Once sufficient supply of ALGO is established on the platform, trading on the ALGO/USD order book will start in phases, beginning with post-only mode and proceeding to full trading should our metrics for a healthy market be met. Support for ALGO will be immediately available in Coinbase’s supported jurisdictions, with the exception of New York State. Additional jurisdictions may be added at a later date.
Founded by cryptographer and Turing award winner Silvio Micali, Algorand aims to solve some of the technical barriers of existing blockchain infrastructure. In particular, the project seeks to improve decentralization, scalability and security. Launched in June 2019, Algorand provides a foundation for existing businesses and new projects to operate globally in the emerging decentralized economy. Algorand’s permissionless, pure proof-of-stake protocol supports the scale, open participation, and transaction finality required to build scalable blockchain projects.
Please note that ALGO is not yet available on Coinbase.com or via our consumer mobile apps. We will make a separate announcement if and when this functionality is added.
The Stages of the ALGO Launch
There will be four stages to the launch as outlined below. We will follow each of these stages independently for each new order book. If at any point one of the new order books does not meet our assessment for a healthy and orderly market, we may keep the book in one state for a longer period of time or suspend trading as per our Trading Rules.
We will send tweets from our Coinbase Pro Twitter account as each order book moves through the following phases:
- Transfer-only. Starting on Wednesday, August 14, customers will be able to transfer ALGO into their Coinbase Pro account. Customers will not yet be able to place orders and no orders will be filled on these order books. Order books will be in transfer-only mode for approximately 12 hours. We will communicate the exact timing for this phase via Twitter closer to the date.
- Post-only. In the second stage, customers can post limit orders but there will be no matches (completed orders). Order books will be in post-only mode for a minimum of one minute.
- Limit-only. In the third stage, limit orders will start matching but customers are unable to submit market orders. Order books will be in limit-only mode for a minimum of ten minutes.
- Full trading. In the final stage, full trading services will be available, including limit, market, and stop orders.
One of the most common requests we receive from customers is to be able to trade more assets on our platform. Per the terms of our listing process, we anticipate supporting more assets that meet our standards over time.
You can sign up for a Coinbase Pro account here to start trading. For more information on trading ALGO on Coinbase Pro, visit our support page.
Algorand (ALGO) is launching on Coinbase Pro was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on August 8, 2019Responding to Firefox 0-days in the wild
On Thursday, May 30, over a dozen Coinbase employees received an email purporting to be from Gregory Harris, a Research Grants Administrator at the University of Cambridge. This email came from the legitimate Cambridge domain, contained no malicious elements, passed spam detection, and referenced the backgrounds of the recipients. Over the next couple weeks, similar emails were received. Nothing seemed amiss.
On June 17 at 6:31am, Gregory Harris sent another email, but this one was different. It contained a URL that, when opened in Firefox, would install malware capable of taking over someone’s machine.
Coinbase Security quickly discovered that these emails were anything but ordinary — they were all part of a sophisticated, highly targeted, thought out attack that used spear phishing/social engineering tactics and, most importantly, two Firefox 0-day vulnerabilities.
Within a matter of hours, Coinbase Security detected and blocked the attack. Here’s how it unfolded.
The exploit
There were two separate 0-days chained together in this attack, one that allowed an attacker to escalate privileges from JavaScript on a page to the browser (CVE-2019–11707) and one that allowed the attacker to escape the browser sandbox and execute code on the host computer (CVE-2019–11708). CVE-2019–11707 was simultaneously discovered by Samuel Groß of Google’s Project Zero and the attacker. Based on significant differences in the way the attacker, a group we track as CRYPTO-3 and is also referred to as HYDSEVEN, chose to trigger the vulnerability versus the trigger used by the Project Zero PoC, we do not believe that the attacker acquired the exploit from either Mozilla or Google but independently discovered the vulnerability. Samuel Groß goes into more detail about why this is the case here.
The second exploit, CVE-2019–11708, is also very interesting. While the core vulnerability has been present in Firefox for quite a while, the way this attacker chose to trigger the vulnerability has only been possible since May 12. This indicates a very rapid discovery-to-weaponization cycle on the part of the attacker (or whoever the attacker acquired the 0-day from). When reviewing the actual exploit code, there are a number of notable features. First, while the delivery of the 0-day was highly targeted (it was only delivered to about 5 individuals out of the 200 initially targeted), there was no effort to obfuscate the JavaScript itself. When reviewing the code, we noted that it was well structured.
Functions and variables have descriptive names, and the code is broken into reasonable functional units. Overall, it feels like the work of a group that has significant experience developing exploits.
The setup
Once the attackers had this initial capability, they turned their attention to the delivery method. They compromised or created two email accounts and created a landing page at the University of Cambridge, and on May 28 registered the domain used to deliver the exploit. We don’t know when the attackers first gained access to the Cambridge accounts, or whether the accounts were taken over or created. As others have noted, the identities associated with the email accounts have almost no online presence and the LinkedIn profiles are almost certainly fake. Cambridge provides its staff with the ability to host personal files under the Cambridge domain. Once the attackers had access to the accounts in question, they prepared a series of pages by cloning and modifying existing Cambridge University pages and making them available in the personal storage directories of the attacker-controlled accounts.
The attack
The first phishing emails began on May 30. The first emails to go out contained no malicious elements (the link in the below screenshot did not contain any malicious code).
The attackers went through a qualification process and multiple rounds of emails with potential victims, making sure they were high-payoff targets before they directed victims to the page containing the exploit payload. This process commonly spanned weeks and only about 2.5% of the people who received the initial emails ended up receiving a link to the page hosting the 0-day. The attackers did a good job of creating a sense that the victims were talking to legitimate people using several techniques. Compromised academic emails allowed them to avoid any email filtering or common spam detection, and by spreading the communication out, the attackers modeled normal human behavior. The contents of the email referenced real academic events and were narrowly targeted at the backgrounds of the individuals being phished.
Once the attackers had qualified a target, they sent a separate link containing the exploit payload. Stage one of this attack first identified the operating system and browser, and displayed a convincing error to macOS users who were not currently using Firefox, instructing them to install the latest version from Mozilla. After visiting the page in Firefox, the exploit code was delivered from a separate domain, analyticsfit[.]com, which was registered on May 28. The exploit payload used CVE-2019–11707 and CVE-2019–11708 to gain arbitrary code execution as the user. The attacker’s shellcode then shelled out a curl command to download and run a stage 1 implant. The stage 1 implant (07a4e04ee8b4c8dc0f7507f56dc24db00537d4637afee43dbb9357d4d54f6ff4) pulled down by the shellcode was 32-bit, which causes macOS to pop up a warning that 32-bit execution is being deprecated. The stage 1 binary was a variant of the Netwire family. While this implant is capable of acting as a fully-featured RAT, the attackers seem to use it mostly as an initial recon and credential theft payload. We detected the attacker at this stage, based on a number of behaviors (e.g. Firefox shouldn’t spawn a shell). After exfiltration of recon data and a basic pillage of obvious credential stores (.ssh, .aws, .gpg, keychain, etc) and document formats, followed by a delay indicative of human involvement, the stage 1 payload is used to bootstrap a stage 2 payload (97200b2b005e60a1c6077eea56fc4bb3e08196f14ed692b9422c96686fbfc3ad). The stage 2 payload is a variant of the Mokes family. The attackers seem to use this implant as a full-fledged RAT. We’ve observed activity of the stage 2 implant consistent with direct human control. Our assumption is that stage 1 only advances to stage 2 where the attackers believe they have landed on a host of value. We have also observed the attackers specifically target cloud services, e.g. gmail and others, via browser session token theft via direct access to browser datastores. This activity also offers the opportunity for behavior-based detection, as relatively few processes should be directly accessing those files.
Our response
We began investigating this incident based on both a report from an employee and automated alerts. First, we examined the employee’s machine in our endpoint detection and response tooling. Looking at recent process activity, Firefox shelling out to curl stood out immediately. The response team spun up an incident and first tried to determine the scope of the attack. We collected IOCs from the host in question and started hunting broadly in our network. We did not see any of the IOCs anywhere else in our environment, and blacklisted all the IOCs that we had at that time. Simultaneously, we collected samples, including capturing the 0-day, from the phishing site while it was still live and the attackers were likely unaware of our response. We also revoked all credentials that were on the machine, and locked all the accounts belonging to the affected employee. Once we were comfortable that we had achieved containment in our environment, we reached out to the Mozilla security team and shared the exploit code used in this attack. The Mozilla security team was highly responsive and was able to have a patch out for CVE-2019–11707 by the next day and CVE-2019–11708 in the same week.
We also reached out to Cambridge University to assist in securing their infrastructure and to collect more information about the attacker’s behavior. As a result, we were able to quickly degrade the attacker’s ability to continue their campaign and learn more about the scope of the campaign. We learned that over 200 individuals were targeted by this attacker, and identified the organizations employing these individuals so that we could reach out and give their security teams the information they needed to secure their infrastructure and protect their employees.
We were able to defend ourselves from this attack due to our security-first culture at Coinbase, complete deployment of our detection and response tooling, clear and well-practiced playbooks, and the ability to rapidly revoke access. The cryptocurrency industry has to expect attacks of this sophistication to continue, and by building infrastructure with excellent defensive posture, and working with each other to share information about the attacks we’re seeing, we’ll be able to defend ourselves and our customers, support the cryptoeconomy, and build the open financial system of the future.
Coinbase will continue to face tough security challenges in the future and meet them head on. If you’re interested in being a part of the security team here at Coinbase, check out some of the available positions on our careers page.
This website contains links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.
Responding to Firefox 0-days in the wild was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on August 8, 2019Tezos (XTZ) is now available on Coinbase
Starting today, Coinbase supports Tezos (XTZ) at Coinbase.com and in the Coinbase Android and iOS apps. Coinbase customers can now buy, sell, convert, send, receive, or store XTZ. XTZ will be available for customers in all Coinbase-supported regions, with the exception of New York State. Additional jurisdictions may be added at a later date.
Tezos is a cryptocurrency and decentralized computing platform. Its features include proof of stake consensus, formal verification (which lets developers verify the accuracy of their code), and the ability to let stakeholders vote on changes to the protocol.
One of the most common requests we hear from customers is to be able to buy and sell more cryptocurrencies on Coinbase. Last year we announced a new process for listing assets, designed in part to accelerate the addition of more cryptocurrencies. We are also investing in new tools to help people understand and explore cryptocurrencies. We launched informational asset pages (see XTZ here), as well as a new section of the Coinbase website to answer common questions about crypto.
You can sign up for a Coinbase account here to buy, sell, convert, send, receive, or store XTZ today.
Tezos (XTZ) is now available on Coinbase was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on August 7, 2019Coinbase Custody Trust Co.
Coinbase Custody Trust Appoints New York Banking Regulatory Veterans Richard Neiman and Robert Easton to its Board of Directors
Today we’re announcing two new additions to the board of Coinbase Custody Trust Company, Richard Neiman and Robert Easton. Both bring decades of experience in financial services, public policy and banking operations. Their combined knowledge and judgment will help guide Coinbase Custody on its mission to be the most trusted and secure crypto custodian in the world.
Neiman and Easton’s experience is particularly important because Coinbase Custody is regulated by the New York Department of Financial Services (NYDFS). NYDFS regulates many trust companies, including the Depository Trust & Clearing Corporation, ICE Trust, and many other leading financial institutions. New York also was the first state to regulate crypto firms, starting in 2015 with the Bitlicense. NYDFS now regulates more than 20 crypto firms — more than any other state.
Given the critical role that NYDFS plays in regulating leading crypto companies, we’re honored to have Richard and Robert join our board. Both bring decades of experience at the highest levels of financial services operations and regulation.
Richard Neiman is one of the nation’s foremost experts on banks and banking regulation. He served from 2007 to 2011 as Superintendent of the New York State Banking Department (predecessor agency to NYDFS). He also served alongside now-Sen. Elizabeth Warren and others as a member of the Congressional Oversight Panel for the Troubled Asset Relief Program. His private sector leadership includes service as President of TD Bank USA, Vice Chairman of PwC’s global financial regulatory practice, and his current role as Head of Public Policy at LendingClub. Earlier in his career, Richard served as general counsel of the global equities division of Citibank and as an attorney at the Office of the Comptroller of the Currency.
Robert Easton is a nationally known figure in risk management and compliance who also brings senior regulatory leadership experience to Coinbase Custody. He spent nearly 15 years in various leadership positions in the New York State financial regulatory system, rising to the role of Executive Deputy Superintendent for the Insurance Division at the New York Department of Financial Services. Rob currently serves as Deputy General Counsel and Chief Compliance Officer of Marsh LLC, the largest operating company of Marsh & McLennan Companies (MMC), a global professional services firm with business in risk management, insurance and investment advising. In this role, Easton oversees the company’s global compliance programs and risk management functions. Prior to joining Marsh, Easton was Senior Vice President and Chief Compliance Officer at McGraw Hill Financial, where he was responsible for corporate compliance across the company’s broad range of credit rating services, financial instruments and analytics products.
Please join us in welcoming Richard and Robert to our board. We look forward to benefiting from their guidance and knowledge as we continue on our journey to becoming the world’s most trusted and secure institutional-grade crypto custodian.
Coinbase Custody Trust Co. was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on August 6, 2019“Capture the Coin” at Defcon and you could win big
Do you enjoy solving puzzles? Are you into cryptography, learning the nitty gritty details of various blockchain implementations, smart contracts, and cryptocurrency wallets? If you answered “yes” to any of these questions then you might have what it takes to Capture the Coin, a capture-the-flag-style competition by the Coinbase Security team.
Tackle various challenges at the intersection of cryptocurrency and security fields including blockchain investigations, crypto-stealing malware, smart contract and bitcoin script exploitation, various cryptography puzzles, and plenty of trivia.
We invite everyone to join us to have some fun, solve challenges, and win a very unique prize!
The Capture the Coin competition will open on August 9 at 10am PST. You can play online and at Defcon’s Blockchain Village. Also join us for the contest kick off talk on August 9 at 11:40am PST.
Awards will be given in two rounds:
- First round is for Defcon 27 attendees who scored the most points by 10am PST on Sunday, August 11. Five prizes will be awarded and handed out during the Blockchain Village award ceremony on Sunday August 11 at 2pm PST.
- Second round is for everyone, including online players, who scored the most points by 10am PST on Monday, September 9. Five prizes will be awarded and shipped to players.
Check out the Capture the Coin website for more information and join us at the Blockchain Village during Defcon 27.
PS: The Coinbase Security deals with the real life ramifications of Blockchain Security on a daily basis. From protocol level attacks to end user targeting campaigns, we work to ensure a safe and open financial system. Come visit our Careers page and find out how you can help!
This website may contain links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.
Unless otherwise noted, all images provided herein are by Coinbase.
“Capture the Coin” at Defcon and you could win big was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on August 6, 2019Phishing attacks and how to not fall victim
As the price action in crypto markets has intensified over the past three months, so has the interest of online attackers who employ ever-evolving tactics to steal funds. Whether you store your crypto in a Coinbase Vault or on a hardware wallet, we recommend that everyone take the time to understand common online threats and how to protect themselves. In this article, we’ll discuss one of the most persistent attacks we see against our customers — phishing.
Phishing is an extremely common type of online attack, and with good reason — once an attacker tricks a user into providing their login information, they can fully impersonate that individual. The Coinbase User Trust team investigates multiple reports of phishing every day and is constantly working to neutralize these attacks as quickly as possible. However, some hosting providers respond slowly (or not at all) to abuse reports regarding the misuse of their platforms. That’s why it’s important to be able to recognize signs that you’re being phished, even if you don’t see a warning from your browser.
Recent Phishing Trends
To help you recognize the signs that you’re on the verge of getting phished, we’ve provided you with some examples of the most common phishing techniques and trends being used to target Coinbase customers. If you see any phishing messages or sites like these in the wild, please report them to security@coinbase.com immediately.
New Device Confirmation Phishing
When you attempt to log into your Coinbase account from a device and location we don’t recognize, we will send you a device verification email that contains a unique, hard-to-guess authorization link. If you don’t click that link, the login attempt will fail. As a result, some phishing sites may ask you to copy and paste the device verification link in an attempt to bypass this security measure. The real Coinbase login page will never ask you to copy and paste that link.
Email Password Phishing
Here an attacker is attempting to trick potential victims into sharing the password to their email account so that the attacker can access the email and complete new device confirmation. Coinbase will never ask you to enter the password to your email address.
Phishing via Text Message
Do not let a phishing message like this play with your emotions. Always check your deposits by going directly to www.coinbase.com, or by using the Coinbase app.
Phishing via Email
Note the sense of urgency to entice people to click on the link. Hovering your mouse pointer over the link in this email will reveal this link is actually directing to the phishing domain: https://coenbase[.]com instead of https://coinbase.com. Again, please go directly to www.coinbase.com if you are ever unsure about an email you have received.
Coinbase Login Page Clone
In this example, pay special attention to the URL bar at the top of the browser: coinbase.pro-mrq[.]com is not a legitimate Coinbase domain and it does not have HTTPS (the green lock) enabled. The legitimate Coinbase domain secures all connections over HTTPS, and will always end in “coinbase.com”
Internationalized Domain Names
This phishing domain uses an Internationalized Domain Name (IDN) which closely resembles www.coinbase.com. However, looking closer will reveal that the domain is actually www.coįnbase[.]com (note the character accent below the “i”).
Also, even though the site has HTTPS (the green lock) enabled, the green lock does not mean you are on a legitimate website, only that you’re securely communicating with *some* website. This is a common point of confusion with browsing the web.
Protecting Your Account
Currently, the only known way to reliably avoid being phished is to use security keys (also referred to as U2F) with your online accounts. Not only can you use a security key to lock down your Coinbase account, but you can also use it with any other online services that integrate with them such as Gmail, Facebook, Dropbox, Instagram, Twitter, YouTube, and more. If you want to know more about security keys, you can learn more in our blog post here.
This website may contain links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.
Unless otherwise noted, all images provided herein are by Coinbase.
Phishing attacks and how to not fall victim was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on August 5, 2019Coinbase continues to explore support for new digital assets
We are continuing to explore the addition of new assets for customers around the world.
Coinbase’s goal is to offer support for all assets that meet our technical standards and which comply with applicable laws. Over time we expect our customers around the world will have access through Coinbase to at least 90% of the aggregate market cap of all digital assets in circulation. To make this vision a reality, we evaluate prospective assets against our Digital Asset Framework to assess factors like security, compliance, and the project’s alignment with our mission of creating an open financial system for the world.
Digital Assets Under Review
Today we’re announcing that we are exploring the addition of a range of new assets. As part of the exploratory process, customers may see public-facing APIs and other signs that we are conducting engineering work to potentially support these assets.
These new assets include, in alphabetical order: Algorand, Cosmos, Dash, Decred, Matic, Harmony, Ontology, and Waves.
Our decision to support any asset requires significant technical and compliance review and may be subject to regulatory approval in some jurisdictions. We therefore cannot guarantee whether or when any above-listed asset will be listed on a Coinbase product in any jurisdiction.
As per our listing process, we will add new assets on a jurisdiction-by-jurisdiction basis, subject to applicable review and authorizations. The omission of assets from this publication does not disqualify any asset from active review and potential listing.
Our customers can expect Coinbase to make future, similar announcements as we continue to explore the addition of numerous assets across the platform.
Coinbase continues to explore support for new digital assets was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
