Competency, Mitigation, and the Value of Time: Network Attack Case Study on CoinPayments.net
What follows is a summary by Path’s Emergency Response Team as experienced from the front lines. It describes the attack on CoinPayments in detail, how it was remedied, and pertinent discussion.
CoinPayments is a digital currency payment solution that allows merchants to accept Bitcoin, alongside over differing 1350 “altcoins”, in their store through the use of easy-to-use plugins, API’s, and POS interfaces. Encompassing over 2,000,000 users across 182 countries, CoinPayments.net is the most comprehensive multi-cryptocurrency platform in the world. CoinPayments offers an industry low transaction fee of only 0.5%, which is the source of its rapid growth in relevance. Additionally, the CoinPayments gateway leads the crypto-payment industry by being the first and largest cryptocurrency payment processor; available on all major e-commerce platforms in the world including:
· WooCommerce
· Shopify
· Magento
· Prestashop
· Opencart
All of the reasons listed above, not counting myriad others, are why CoinPayments would be (and has been) a prime target for network attacks by malevolent actor(s); high visibility within a subculture frequented by “hacktivists”, monetary incentive, and ineffective network defenses.
CoinPayments and other vulnerable institutions may not survive continued attacks that occur in the manner to be described, or may survive with heavy losses due to excessive downtime; the experiences of those previously impacted should serve as a warning call for any online entity that isn't already serious about network protection to take notice.
What follows is a summary by Path’s Emergency Response Team as experienced from the front lines. It describes the attack on CoinPayments in detail, how it was remedied, and pertinent discussion.
The Network Attack on CoinPayments: A Timeline
I. As previously described, CoinPayments is a digital currency payment processor with around 2,464,500 unique vendors across 182 different countries. Each of these millions of unique vendors relies upon CoinPayments API (Application Programming Interface) and access to it to perform any functional payment processing. This API reliance and the details inherent will play a major role in the story to come, the story of CoinPayments and CloudFlare.
II. CloudFlare.com is one of the 10 largest “DDoS Vendors”, the closest thing to a household name in the space and its namesake is "free DDoS mitigation provider.” This “free” option is quite enticing to a vast amount of users; CloudFlare even plainly states “Every day, more than 10,000 new customers sign-up for [our] service.” So this enormous success begs the question of how exactly they accomplish their stated mission of being the “free DDoS mitigation provider” in an industry not particularly known for being inexpensive. Note: CloudFlare does indeed have a $200USD/month “Business” plan, but that will be discussed further.
III. Before we move forward, the functionality of traditional DDoS (Distributed Denial of Service) mitigation must be understood. Traditional DDoS mitigation services work by analyzing the packets coming in, spotting unusual patterns, and (temporarily) blocking the origin of that traffic. They never need to know exactly what the traffic contains; they only need to care about the patterns in which it is received. This means that you can tunnel TLS-encrypted traffic (Transport Layer Security) through a DDoS mitigation service just fine, without the mitigation service ever seeing the plaintext traffic and you will still be fully protected.
IV. In juxtaposition to the traditional mitigation functionality outlined above, CloudFlare uses a reverse proxy with a very fast connection. Furthermore, Layer 3 & Layer 4 attacks (those aimed at the underlying network infrastructure, rather than the application or protocol itself) will only ever reach up to the point where it's handled by a server rather than fully passing through, and in a "reverse proxy"-type setup, that server is CloudFlare. They're not actually “mitigating” anything, it just is configured so that they are on the other side of the connection and due to their large capacity, can “take the brunt of the hit.”
V. To further delineate their methodology; in their mitigation procedure, CloudFlare uses an invasive method of “browser vs. bot” detection called a “JavaScript challenge.” This identification process relies imperatively upon the fact that browsers have JavaScript engines and can parse and subsequently solve mathematical problems using JavaScript. Importantly, most attack scripts (Distributed Denial of Service scripts) cannot parse and solve these problems due to the fact that they don’t have a full JavaScript engine, nor the components that full-on browsers do. Essentially, CloudFlare’s detection method is testing for malevolent traffic by utilizing this “JavaScript challenge.” The problem – and the problem that must now be discussed and remedied – is that API automation usually does not include the components to pass this “JavaScript challenge” either.
VI. Recently, there was a network attack on CoinPayments API; on schedule, CloudFlare’s mitigation procedure began running – still utilizing the “JavaScript challenge” as described earlier. However this attack unfolded quite differently. With CoinPayments servicing over 2 million different vendors across over 170 countries, it would be an understatement to say that their global network presence is noticeable. This presence would soon be altered.
VII. Upon realizing the attack, CoinPayments contacted CloudFlare to mitigate the mal traffic that was pouring into their network. CloudFlare responded with a "fix" that actually made the situation significantly worse. To understand the cause of the fallout that would ensue, it is important to know that those vendors mentioned by CoinPayments (“over 2 million unique vendors”) connect to the CoinPayments service via a script written to leverage the CoinPayments API – notably scripts not browsers. Additionally, Most of this script traffic cannot pass CoinFlare's JavaScript.
VIII. Upon the implementation of CloudFlare’s “fix”, all websites that utilized the CoinPayments API went offline due to the fact that the scripts couldn’t pass the CloudFlare-imposed “JavaScript challenge.” Both good and bad traffic was being blocked upon the implementation of this measure and thusly all clients connected to the CoinPayments API went down (over 2 million vendors); none of their automated scripts could pass the CloudFlare “JavaScript challenge.” Needless to say, accessibility was dramatically harmed for an incredibly large amount of users, with access being irregular or non-existent for days.
IX. The amount of revenue lost by all vendors associated with CoinPayments during this downtime is incalculable, and should be one of the many reasons why more attention is paid to network security in all facets by any firm in any industry with an online presence.
Discussion
CoinPayments and the situation surrounding them is but one clear example of the major flaws in the methodology of one the “leaders” in the DDoS mitigation industry. This problem is not isolated, as we see comments to Customer Support such as “Cloudflare blocks all requests to my API, thinking it’s a DDoS attack” among other similar issues, are common. As script based API traffic is on the rise, it's important to realize that the JavaScript Challenge/Reverse Proxy method for mitigating bad traffic has a shelf life to its effectiveness. The cybersecurity landscape is a constantly shifting and evolving series of threats. Our methods (as an industry) for confronting these threats need to be flexible and scalable. Granular filtering and detailed packet analysis are necessary, not optional, for true network stability and DDoS mitigation.