Categories
Article & News

How confidential are your calls?

No need to panic.

This is not a case of secret nation-state methods of phone tapping (or espionage, as it is often called).

It’s not a story of cybercriminals deliberately trying to tap your business calls in order to divert massive bill payments or implant ransomware with multimillion-dollar extortion demands.

That was the good news.

The flaw in this case, discovered by Indian cybersecurity researcher Anand Prakash, was just a bug of bad programming.

The bad news is that the side effects of the bug could be exploited by anyone, anywhere, anytime.

Who needs authentication?

The type of vulnerability Prakash found often gets the euphonious name IDOR, short for Insecure Direct Object Reference.

An IDOR vulnerability usually consists of a website or service that makes it easy for someone running the app to retrieve data they need to access….

To figure out how to retrieve other people’s data in the future without logging in or authenticating at all. Typically, you’ll find that an app or service uses a URL or web form that contains your own user ID, serial number, or other not-very-secret identifier without any other way to be sure it’s you. For example, you might try to create a request using someone else’s ID, the next number in sequence, or some other likely guess for a valid reference, and find that the system retrieves the data directly for you, even though it’s not your record and you shouldn’t see it.

In theory, many exploitable IDOR flaws can be found purely analytically by reverse engineering the suspicious app without ever creating a fake account and running the app itself. In practice, it’s often easier and faster to do some basic reversals to give you an idea of what to look for and then run the suspicious app while you watch it in action. You don’t need to spend days statically analyzing an app in a decompiler when you can infer the bugs directly from its own behavior – you just give the app a chance to cook its own cybersecurity goose while you take notes.

In this case, the app was called “Acr call recorder” – for the iPhone, like many apps in the App Store, it is (or was when we looked) littered with hundreds, even thousands, of glowing 5-star reviews.

You can probably guess where this is going, many of these 5-star reviews curiously recommend an entirely different app in their text, or praise the app with strange twists that make unlikely and even disturbing points.

For example, someone named Earnest assures you that “it’s definitely a waste if you haven’t tried this app,” while Christopher.1966 says he’s “been using this little thing almost since I got on the train,” and Brenda somewhat creepily, if redundantly, expresses her delight that she can now “record what me and my girlfriend said.” (A call recorder that couldn’t record calls would be simply misnamed.)

Even though it turns out that Brenda is referring to an entirely different app that includes a voice-switching feature, one wonders if Brenda’s friend realized who she was talking to when she was recorded. Brenda’s 5-star rating still counts towards the attractive average rating of 4.2/5 for the call recorder app mentioned above.

However, there are many 1-star reviews that warn you that this is one of those “free trial apps” that automatically charge you if you don’t cancel within three days – a type of free app that Elizafish very succinctly described with her review, “FREE ????? Ridiculous.” But perhaps the most apt review, at least until the app was updated after the developer received Anand Prakash’s bug report, was Leanne’s 5-star review that said, “Not only can I manage recordings, but I can easily share them when needed. So convenient for me!”

What Leanne left out, however, was that the app’s cloud-based storage feature is handy not only for her, but for everyone else in the world, including those who don’t own this app or an iPhone. Sharing her calls with other people was apparently much easier than she thought.

Who needs authentication?

Prakash decompiled the app to look for likely URLs it might connect to, monitored the app as it ran, and found that one of its call-home requests was a block of JSON data that looked something like this:

POST /fetch-sinch-recordings.php HTTP/1.1
Host: [REDACTED]
Content-Type: application/json
Connection: close
[. . .more headers, no unique cookies or tokens. . .]

{
“UserID”: “xxxxxx”,
“AppID”: “xxx”
}

​Since there is no way to bind this request to a specific user who has already authenticated himself, and the server has no way to decide whether the sender of the request even has the right to ask for data belonging to the user designated by UserID……, someone can insert the UserID of any user into a fake request, and therefore anyone’s data is not safe from anyone. This type of flaw gets the name IDOR because it allows attackers to insecurely and directly designate their victims by simply inserting a new UserID directly into the request.

What should I do?

Here’s our tip: As a user, don’t be influenced by the ratings in the App Store or on Google Play.

We suggest that you ignore the reviews and star ratings on the app stores. You have no idea who gave those ratings or left the reviews, or if they even used the app.

Fake reviews and official-looking app store ratings can be purchased online at a price that is almost literally ten pennies. Look for reviews in independent user forums or discussions in online cybersecurity groups.

Consider using third-party mobile cybersecurity software to supplement the built-in protection of the device you’re using.

Both Apple and Google operate their own online stores that contain vetted and approved apps.

However, these walled gardens are far from perfect. There are simply too many developers and too many apps for them to be thoroughly reviewed by an expert. As a programmer, follow the operating system’s own recommendations for secure coding. Guidelines from Apple, Google, and others on secure coding on their platforms alone are not enough.

However, if there is vendor advice that you have ignored or are not even aware of, your cybersecurity is probably not up to snuff. Therefore, treat the vendor’s own guidelines as “necessary but not sufficient.”

Apple, for example, has a wide range of security guidance for programmers that covers authentication (is the right person doing the right thing?), confidentiality (is the data safe from snooping when stored or moved across the network?), and validity (does the right code do the right thing?).

Never stop learning and reading about cybersecurity.

One of the reasons we exist is to help you understand and fight cybercrime and avoid the kinds of mistakes that make life easier for crooks. (We don’t see this as a one-way street – we read all the comments and advice you, our readers, leave here, and make sure our developers and product managers hear you, too!)

If you’re just getting into cloud or web development and want to know what to learn first, the OWASP Top Ten are probably a good place to start.

Remember that cybersecurity is a journey, not a destination.