Payments is an industry ripe for disruption. Research suggests that anywhere between 30-50% of fintechs are developing payment technology. The reason for this is clear – payment networks are built on last century’s technology. A clean sheet design built on a modern stack will have many technological advantages.
However, as any investor knows, the challenge for a start-up isn’t the technology—it’s market need and industry readiness. In order for innovative payment technology to be widely adopted and succeed, the industry must overcome inertia and inch forward with security as a main priority.
Planning your security approach as you develop your payment apps? Here’s a starting point to guide your approach:
Six years ago, Apple added support for Bitcode with Xcode 7. Still, after all this time, there are many misconceptions about what it means for developers and their iOS apps. Here, we’ll discuss how “bitcode enabling” your app can affect its overall security.
What is Bitcode?
When a developer compiles code to upload into the AppStore, it must be converted from the human-readable source code to machine code. Bitcode is an Intermediate Representation (IR) of your code – somewhere between source code and machine code.
According to Apple, bitcode “allows the AppStore to compile your app optimized for the target devices and operating system versions, and may recompile it later to take advantage of specific hardware, software, or compiler changes.”
Essentially, this means that a bitcode enabled application can be optimized for the particular device it is being installed on. Not only that, but it will always be optimized with the latest and greatest compiler technology. Bitcode enabled applications guarantee that the end user will always have the best possible version of your app.
How Bitcode is Compiled
The compilers* built into Apple’s development environment, Xcode, take the source code and convert it to a format called LLVM IR. This step is performed by the compiler front end. Then, a compiler backend takes the LLVM IR and converts it into machine code—ready to execute on the device of choice.
For a bitcode enabled app, the LLVM IR is packaged with the application when it is published to the AppStore. The compiler backend is then executed by Apple as part of the AppStore infrastructure.
From a developer’s point of view, bitcode enabling an app is straightforward – it’s a single build option.
So why wouldn’t you take advantage of this targeted optimization offered by Apple? The answer is dependency chains – every component an app or framework consumes also needs to be bitcode enabled. If your app is integrating with older software libraries that aren’t bitcode enabled, you have two choices: You can either turn bitcode off or replace the libraries. Often, the easier option is simply to turn bitcode off. This is likely the reason Apple hasn’t yet mandated bitcode on all iOS apps.
However, bitcode is mandatory for tvOS and watchOS apps. Apple requires these to be published as bitcode enabled apps because the dependency chains of these newer operating systems have been fully bitcode enabled from day one. Unlike iOS, no migration is required for tvOS and watchOS apps.
Do You Trust Apple?
When it comes to security, the closer your code executes to hardware, the more difficult it is to reverse engineer. Thus, an intermediate format like bitcode is easier for an attacker to decipher and understand. For security’s sake, this is often a good reason to turn off bitcode.
However, it shouldn’t be a concern because bitcode is never installed on a device. In fact, it never even leaves Apple’s AppStore. As long as you trust Apple (and if you don’t, why are you publishing an app on their platform?) then bitcode should not be considered a security concern.
The Importance of Binary Integrity
Ensuring code executes exactly as the developer intends is key to its security. If an attacker can modify the code, it is easier to reverse engineer and easier to weaponize.
Anti-tamper technology checks the code to ensure it has not been modified. Enterprise-grade solutions will interweave a series of checks with your functional code. This creates a dynamic “check network” that constantly evaluates your code as it runs, making sure there are no differences between what is executing and what you intended.
Bitcode poses a challenge to anti-tamper technology since it enables Apple to change the executing code on a per device basis. The fact that the executing code can also change over time as Apple improve the compilers only adds to the security challenge. With the code changing, where does the anti-tamper get its reference picture so it can spot differences?
To solve this challenge and keep bitcode secure, Verimatrix launched Elastic Anti-Tamper technology. For the first time, bitcode enabled apps can be protected with enterprise-grade anti-tamper solutions. This adds to Verimatrix’s suite of proven Shielding products – giving our customers confidence in their iOS app security whether they bitcode enable their app or not.
*Clang for C, C++ and Objective-C, SwiftC for Swift
Nexoya Technologies is the partner of choice for many of the country’s leading bank, government organizations, enterprises, SMEs, and technology challengers. We help businesses elevate their value through custom Managed Services, IT & Business Consulting, Technology Solutions, Cybersecurity Training, and Full-Cycle Software & Mobile App Development. Nexoya Technologies is the authorized partner of Verimatrix.
“In total, just over $90 million in bitcoin ransom payments were made to DarkSide, originating from 47 distinct wallets,” blockchain analytics firm Elliptic said. “According to DarkTracer, 2,203 organizations have been infected with the DarkSide malware – suggesting that approximately 47% of victims paid a ransom, and that the average payment was $1.9 million.”
Elliptic was first to identify the Bitcoin wallet used by the DarkSide ransomware group to receive a 75 Bitcoin ransom payment from Colonial Pipeline.
Colonial was the victim of a ransomware attack on May 7, 2021, which led to a voluntary shutdown of the main pipeline supplying 45% of fuel to the East Coast of the United States. The attack was described as the worst cyberattack to date on U.S. critical infrastructure.
In this new report, we expand our original analysis to examine all of the wallets used by DarkSide to receive Bitcoin ransoms from victims over the past nine months.
This relies on Elliptic’s sophisticated blockchain analysis platform, combined with open-source intelligence gathered by our team of analysts. To our knowledge, this analysis includes all payments made to DarkSide, however further transactions may yet be uncovered, and the figures here should be considered a lower bound.
Over $90 million extracted from 47 victims
In total, just over $90 million in Bitcoin ransom payments were made to DarkSide, originating from 47 distinct wallets. According to DarkTracer, 99 organisations have been infected with the DarkSide malware – suggesting that approximately 47% of victims paid a ransom and that the average payment was $1.9 million.
The chart below shows the total value and number of ransom payments made to DarkSide over the past nine months. May was set to be a record month, until DarkSide reportedly shut down its operations on May 13, and its Bitcoin wallet was emptied.
Sharing the spoils
DarkSide is an example of “Ransomware as a Service” (RaaS). In this operating model, the malware is created by the ransomware developer, while the ransomware affiliate is responsible for infecting the target computer system and negotiating the ransom payment with the victim organization. This new business model has revolutionized ransomware, opening it up to those who do not have the technical capability to create malware but are willing and able to infiltrate a target organization.
Any ransom payment made by a victim is then split between the affiliate and the developer. In the case of DarkSide, the developer reportedly takes 25% for ransoms less than $500,000, but this decreases to 10% for ransoms greater than $5 million. This split of the ransom payment is very clear to see on the blockchain, with the different shares going to separate Bitcoin wallets controlled by the affiliate and developer. In total, the DarkSide developer has received bitcoins worth $15.5 million (17%), with the remaining $74.7 million (83%) going to the various affiliates.
In fact the affiliate’s share of both the Colonial Pipeline and Brenntag ransom payments were sent to the same Bitcoin wallet, suggesting that the same party was responsible for infecting both of these businesses.
Following the money
Using Elliptic’s blockchain analytics we can follow the ransom payments and see where the bitcoins are being spent or exchanged. What we find is that the majority of the funds are being sent to crypto-asset exchanges, where they can be swapped for other crypto assets or fiat currency.
The majority of crypto-asset exchanges comply with anti-money laundering regulations. They verify their customers’ identities and report suspicious activity. They also use blockchain analytics tools such as those offered by Elliptic, to check customer deposits for links to illicit activity such as ransomware.
However some jurisdictions do not enforce these regulations, and it is to exchanges in these locations that much of the DarkSide ransomware proceeds are being sent. Regulated crypto-asset businesses should perform careful due diligence on the virtual asset service providers (VASPs) that they transact with. Elliptic Discovery provides risk profiles of all major global VASPs – enabling you to take a risk-based approach to your crypto counterparties.
Disclaimer
This blog is provided for general informational purposes only. By using the blog, you agree that the information on this blog does not constitute legal, financial or any other form of professional advice. No relationship is created with you, nor any duty of care assumed to you, when you use this blog. The blog is not a substitute for obtaining any legal, financial or any other form of professional advice from a suitably qualified and licensed advisor. The information on this blog may be changed without notice and is not guaranteed to be complete, accurate, correct or up-to-date.
