What it takes to secure your SDK: An interview with Abdullah, Adjust's Mobile Security Specialist
Jul 26, 2018
We sat down with Abdullah Joseph, Mobile Security Specialist at Adjust, to talk SDK spoofing. A relatively new player in the fraud cat-and-mouse game, SDK spoofing is a sophisticated and frustratingly hard to detect method of ad fraud - and it’s conning marketers out of a huge amount of their campaign budgets.
As soon as we discovered this method of fraud, we began developing ways to prevent it from reaching clients’ datasets. Today, we’re the only attribution provider on the market with a strong, effective solution against SDK spoofing. Read on to learn exactly how we’re fighting it.
SDK spoofing is the latest method of fraud to hit the mobile ecosystem. Can you tell us a bit more about the problem, and what it involves?
We’ve seen a dramatic increase in fraud rates over the past 12 months - in fact, they’ve almost doubled in that time. This is partly explained by a big rise in SDK spoofing.
Put simply, SDK spoofing is the ability to masquerade as a legitimate device. Fraudsters will collect real device data and, by learning which URL parameters represent specific actions within an app, they can figure out a URL set up that allows them to create installs out of thin air. Crucially, the install never actually happened - but everything else, including the device and device data, is real. That makes SDK spoofing incredibly hard to spot, and we see that it now accounts for 37% of all rejected installs.
Why do we as an industry need to be concerned about SDK spoofing?
First, SDK spoofing means advertisers are wasting a huge amount of their budget on fake installs. In some cases, we’ve seen it be responsible for as much as 80% of an app’s installs. That’s potentially a lot of money that could be spent acquiring real users.
Secondly, fraud rates dramatically skew clients’ data, and that will go on to affect how they spend their budget. Marketers might think a particular campaign is performing especially well, and will then invest more money in these channels - but really, this “success” is simply down to fraudulent installs.
For ourselves, as an attribution provider, tracking is our bread and butter. Our entire business is built on providing clients with data that’s as legitimate as possible. And if we’re not verifying attribution properly, then that’s a problem.
How do you begin to solve such a widespread problem?
We believe the first step of prevention is always education, so we started out by doing a huge amount of research on the issue. That included launching a big investigation into how apps were exploiting the system. Because SDK spoofing relies on grabbing real users’ data to fake URL setups, we realized that fraudsters must have access to this data either through their own apps or by leveraging apps they have access to.
We knew that the key to fighting this method of fraud relied on securing our SDK from the perpetrators. When an app install comes through to us, the first thing we need to verify is that the tracked event really occurred. With SDK spoofing, the hard part is that these credentials are easy to fake - you’re basically trusting what the messenger is saying. And that’s where the issue comes from: we need a better way to verify things.
Can you tell us more about how our solution works?
The fraud team worked hand-in-hand with the SDK team to come up with a reliable solution: a cryptographically secure signature hash that signs SDK communication packages. We introduced a new dynamic parameter to the install URL, which can’t be guessed or stolen, and is only ever used once. Our backend verifies the traffic coming from the SDK through the signature, making sure the request is coming from a trusted device, and if there’s a match, we will accept the install. Essentially, we’re equipping the SDK to verify the install as extensively as possible. This system essentially makes it so a fraudster won’t find it so easy to break in.
Alongside integrating the signature hash, our backend also conducts some parameter processing and filtering in order to detect anomalies in the request. The SDK sends the request in a very structured and organized manner, which fraudsters sometimes neglect. For example, a fraudster could randomly send out a request coming from iOS 10.2.2 - when actually, there was never an iOS 10.2.2. Many less sophisticated attackers don't do their homework.
It’s challenging, as SDK spoofing has become so widespread in such a short space of time. Fraudsters are constantly finding new workarounds to steal from marketers’ advertising budget. They’re not standing still, which means we can’t either. That’s why we’re always working on updates to our solution, and adding more levels of increasingly complex security to protect our clients.