Why a closed source SDK is essential when fighting fraud
Why eliminate a problem, when you can keep customers hooked on the solution?
While upsetting, this statement illustrates the general business approach big companies can have towards their customers. Some businesses could often take an approach that would refrain from providing a permanent solution that would make a problem go away, and would generally prefer to provide a temporary fix that would either decrease the problem’s short term impact, and will maintain the customer’s dependence on their solution in the long term.
This is perhaps a very cynical approach to business, and does not apply to all companies and businesses, but it does make some economic sense.
When examining today’s economy, multi-billion dollar, publicly traded companies are obligated to show profit and growth, many of which offer solutions and services to “problems”. Whether this problem is brewing the perfect cup of coffee or driving optimal ROI out of your marketing campaigns.
Setting aside specific industries, one couldn’t help but apply this logic to the online advertising industry and perhaps its biggest concern or “problem” – mobile ad fraud. Recent years have shown not only growth in fraud scheme scales and ease of operating such scams, but also a growing awareness of fraud and its implications on advertisers and publishers alike.
When examining today’s economy, multi-billion dollar, publicly traded companies are obligated to show profit and growth, many of which offer solutions and services to “problems” and “diseases” of modern life.
Setting aside specific industries, one couldn’t help but apply this logic to the online advertising industry and the “disease” plaguing it – mobile ad fraud. Recent years have shown not only growth in fraud scheme scales and ease of operating such scams, but also a growing awareness of fraud and its implications on advertisers and publishers alike.
Going back to basic economics – when there’s growth in demand, growth in supply will usually follow; with the growth in awareness to fraud, new companies rose to the occasion and started offering first-party and third-party solutions to battle fraud.
As financial entities, these companies may differ in pricing, messaging, perception, and type of solution, but the same questions still apply to all: Would they really do everything in their power to eliminate their main source of income? Is there demand for fraud prevention solutions in a world without fraud?
When examining the cat-and-mouse game of fraud prevention to answer the question above, try looking for the loopholes one party would leave for the other to keep the game going. They may be small, but they’re there. This could be as simple as offering paid services to interested parties from both ends (advertisers and partners) – potentially harming the unbiased nature required for eliminating fraudulent sources.
For example: Fraud solution providers could be dependent on business generated by a certain party or entity (on either side) which in turn could damage their reasoning and intentions when faced with a business decision regarding a fraud case potentially affecting their mutual business.
On that note, it’s also important to examine where your fraud solution provider is placed in the ad delivery chain, even when it is unbiased.
A more important red flag I’d like to discuss is the reliance on an open-source SDK solution at the foundation of one’s fraud prevention suite.
Why open-source doesn’t belong in your fraud solution
Some fraud solution providers could go as far as to take pride in their use of open-source technology as part of their fraud prevention setup. Indeed, many online tools use open-source code to provide a better solution, as this fits the vision and operation of their solution.
Wikipedia, Google, and Adobe are just a few of the big names that use open-source to take advantage of the many benefits allowed by the community’s drive to improve and develop better products together.
Open-source solutions are indeed great, however, alongside their many benefits, a major flaw becomes apparent when discussing security and protection in regards to fraud.
While an open-source solution makes it transparent and available for reviews and improvements, it also makes more susceptible to reverse engineering and manipulations. This is the equivalent of investing in the most advanced security system for your house but then leaving the front door unlocked.
More prone to security breaches of different kinds, attribution solutions relying on open-source SDKs gave birth to a new type of fraud: SDK spoofing.
SDK spoofing refers to legitimate-looking installs that are generated by fraudsters without any real installs occurring. This translates into drained advertising budgets and misleading targeting data, causing long term effects on future activity and budget allocation.
A fraudster who’s looking to spoof an SDK’s activity with the purpose of hijacking attribution for advertising funds would only need to take a look at the code, invest in a bit of reverse engineering, and just like that access is granted. The fraudster can now understand the HTTP messaging logic much easier, see how each field value is collected, and then use the HTTP request to their benefit.
Most of the discussion around SDK spoofing centers on network attacks like MITM (Man in the Middle) or Replay attacks, but that is only one point where the SDK’s data can be spoofed. Data can be collected, manipulated, and spoofed even before it is sent over the network.
There are many tools for dynamic analysis and instrumentation making it possible to monitor and manipulate any data in the attacked application before it is dispatched to the back-end (during the application’s run-time).
Using these tools correctly allows fraudsters to manipulate whatever data they want while leaving the network’s “protection” mechanisms intact (read: the back-end data appears as legit and “signed”).
It’s important to note that any software (open-source or not) can be reverse-engineered; software providers claiming otherwise are either unaware of the risks they’re facing, naive, or both.
The question is: What are these companies doing to protect their software from attempted attacks?
How this relates to open-source
- Open-source makes the hacking process faster and cheaper – fraudsters know exactly how the data is collected and packaged inside the SDK which makes it significantly easier for them to find the place where data can easily be faked and create “quality fraud”.
- Any protection mechanism against this type of fraud is clearly visible and can be bypassed. Keeping the SDK logic unknown means fraudsters will require investment in a lot more resources for reverse engineering.
- In open-source solutions cryptographic mechanisms implemented in the code are exposed and can be studied or easily reversed.
- When dealing with open-source, the responsibility for securing the software falls largely on the client – if the client does not take all necessary steps to secure their source code it will be inherently easier to understand, reverse, and manipulate.
Protection against MITM, if implemented in the right way, can indeed prevent personal data theft over remote networks (a scenario where hackers attempt to steal private information delivered over the network from a remote location).
But this case is different. How one secures their SDK and authenticates it on the server is crucial as fraudsters want to generate traffic that appears to be legit. In this case, all they need is access to the application they want to generate traffic for and the right tool-set. The application code can then be modified, even on the OS level, in order to generate fake traffic to fit the fraudster’s needs.
MITM protection is rendered completely meaningless.
Each of these breaches can be solved when spotted, but will require urgent SDK updates by the app owner, regardless of their original update or feature release schedule.
This means app owners are at risk of entering a frustrating, expensive, time-consuming loop of investing additional engineering resources, while their SDK is still out in the open for the next scheme to take place… and so the cycle continues.
Get the latest marketing news and expert insights delivered to your inbox
Key takeaways
Fraud is no laughing matter.
It drains advertising budgets and fuels illegitimate sources that will do whatever they can to find the next loophole or security breach. As responsible marketers, we’re expected to take a more careful approach and evaluate the benefits of whatever fraud protection solutions we’re using.
Simply signing up with a solution provider and believing that we’re covered just doesn’t cut it.
When discussing fraud, no solution is perfect, the work towards eradicating the landscape of fraudsters is long and complex. The more companies taking part in the good fight, the better, but we must stop and ask if we’re all in it with the right intentions and the right arsenal.
Here at AppsFlyer we believe in driving a highly efficient prevention solution for anything from attribution hijacking to bot-generated fake users.
As a part of AppsFlyer’s commitment to cure mobile ad fraud, the AppsFlyer SDK applies the best tools in the market to protect its code from reverse engineering. Protect360, AppsFlyer’s fraud protection solution, uses sophisticated obfuscation and encryption on its code sources and is the most advanced mobile ad fraud protection suite available.
