Before apps and app stores, before Facebook on mobile or YouTube on your phone, there was WAP: wireless application protocol. Developed in 1999 to web-enable dumbphones of the day, WAP was a low-bandwidth way to get news, stock quotes, and other tidbits of information. (This was the “baby web” that Steve Jobs mocked when he introduced the iPhone, which had a full relatively modern web browser, in 2007.)
Like terrestrial radio and dead-tree newspapers, however, old tech rarely dies.
Rather, it slowly fades out of sight and out of awareness, only popping up in our semi-stunned awareness when, for example, stimulus checks need to be delivered for tens of millions of people and aging mainframes running 50-year-old operating systems can’t handle the load.
Unbeknownst to most, WAP has, like COBOL, never completely died. And to the credit (or debit) of mobile programmers of the early 2000s, WAP included protocols for billing. Let’s pick debit, because one of the billing mechanisms was to charge items directly to your phone bill.
Which of course is perfect for hackers, because you won’t see that for a month.
Or, perhaps for most of us, ever.
At least until we find out that our regular $200 bill is now magically $700 and we have a heart attack.
The threat, dubbed wapSiphone, was recently discovered by ad security company Confiant and ad fraud fighting company Protected Media. And it exists for four reasons: image ads can carry a payload of Javascript code which can execute silently on your phone; WAP provides a billing mechanism via your unique MSISDN, or Mobile Station International Subscriber Directory Number, that does not require registration, username, or password; some mobile carriers are happy to hand out your MSISDN to anyone who asks via HTTP, or hypertext transport protocol (the language linking on the web); and, of course, hackers want your cold hard cash.
Also, I suppose, because old code never dies.
It just gets hacked by the bad guys of tomorrow.
“The WAP billing workflow requires the provider to harvest the user’s MSISDN, which is typically available through a lookup service via the mobile carrier,” security researcher Eliya Stein says. “This is then reconciled on the backend and then the charges appear directly on the consumer’s phone bill. Historically, this flow required the consumer to load the provider’s site over WAP, but wapSiphone is able to exploit the fact that multiple carriers will make the MSISDN available over HTTP, either through headers or a lookup service. This enables the malvertiser to dispatch these lookup requests to the mobile carriers from within display ads in order to collect the victims’ MSISDN.”
Stein says that the ad networks in use by the hackers behind wapSiphone include RTBTradeIn and DecenterAds. From there, the ads get syndicated across the complicated mobile advertising ecosystem.
Currently, this scam is only targeting carriers such as Global Telecom Holding S.A.E. (formerly Orascom Telecom), which is based in Amsterdam, GB Mobile in Mexico, and an unknown mobile carrier in Iran.
That small target footprint may not, however, last long. I asked Stein, a senior security researcher at Confiant, for more information.
Koetsier: How much would scammers make?
Stein: We don’t have hard data on this, but most will probably try to go for a maximum of several dollars per victim so as to try and fly under the radar
.
Koetsier: have you seen any growth of this beyond the regions you mention
Stein: It’s less common in the US and Europe, probably due to increased privacy enforcement like GDPR. We have heard of similar attacks in the EU, but this specific attacker seems to limit their activity to Iran, UAE, and Mexico at the moment.
Koetsier: Would it work in North America and Europe as well?
Stein: Whether it would work in Europe or not is carrier specific. There are probably some vulnerable carriers, but less than in other parts of the world.
Koetsier: does it impact iOS and Android equally?
Stein: It really depends on what devices these carriers are compatible with, but certainly it would work on both if they are both supported.
Koetsier: Can it happen via in-app ads and/or mobile web ads?
Stein: These campaigns ARE mostly targeting in-app, but [they are] equally possible on mobile web.
Koetsier: Thank you for your time!