this post was submitted on 24 Aug 2024
124 points (100.0% liked)

Android

27508 readers
129 users here now

DROID DOES

Welcome to the droidymcdroidface-iest, Lemmyest (Lemmiest), test, bestest, phoniest, pluckiest, snarkiest, and spiciest Android community on Lemmy (Do not respond)! Here you can participate in amazing discussions and events relating to all things Android.

The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:

Rules


1. All posts must be relevant to Android devices/operating system.


2. Posts cannot be illegal or NSFW material.


3. No spam, self promotion, or upvote farming. Sources engaging in these behavior will be added to the Blacklist.


4. Non-whitelisted bots will be banned.


5. Engage respectfully: Harassment, flamebaiting, bad faith engagement, or agenda posting will result in your posts being removed. Excessive violations will result in temporary or permanent ban, depending on severity.


6. Memes are not allowed to be posts, but are allowed in the comments.


7. Posts from clickbait sources are heavily discouraged. Please de-clickbait titles if it needs to be submitted.


8. Submission statements of any length composed of your own thoughts inside the post text field are mandatory for any microblog posts, and are optional but recommended for article/image/video posts.


Community Resources:


We are Android girls*,

In our Lemmy.world.

The back is plastic,

It's fantastic.

*Well, not just girls: people of all gender identities are welcomed here.


Our Partner Communities:

!android@lemmy.ml


founded 1 year ago
MODERATORS
 

Attacker then emulates the card and makes withdrawals or payments from victim's account.

top 15 comments
sorted by: hot top controversial new old
[–] lemmyvore@feddit.nl 40 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

For those confused about how this could work with chip cards, the malware has two components, one installed on the victims phone and one on the attacker's. The attacker initiates the contactless authentication at an ATM or contactless payment and their phone communicates in real time with the victim's, which is tricked by the malware into reacting to that event and producing the one time token which is then relayed to the attacker and used.

They also previously social-engineered the card PIN from the victim, in case the contactless event requires it (definitely in case of ATM login).

The fact you can trick the NFC system on the phone into reacting to "phantom" payment events and intercept the resulting token sounds like a pretty big problem. The former should be entirely hardware controlled, and the latter should not allow the token to go anywhere else except to the hardware.

[–] Lojcs@lemm.ee 6 points 2 weeks ago (1 children)

The fact you can trick the NFC system on the phone into reacting to "phantom" payment events and intercept the resulting token sounds like a pretty big problem.

That's not what's happening though? It's relaying a physical card's nfc not tricking mobile contactless payments

[–] lemmyvore@feddit.nl 2 points 2 weeks ago (2 children)

That's what I mean, it shouldn't be possible to relay anything. It should only trigger when there's a reader physically in proximity to the phone.

Please keep in mind this is happening on the victim's phone which is not rooted, the malware is a regular non-system app.

If it were happening on a rooted phone I could understand being able to subvert the NFC chain because at some point it has to pass from hardware to software and if you're privileged enough you can cut in there. But the malware app is not privileged.

[–] Lojcs@lemm.ee 1 points 2 weeks ago (1 children)

There is nothing being subverted, nfc has applications other than contactless payments that require it acting as the reader, which is why it's supported. It would be better if it was behind an explicit permission (just like other sensors would) but limiting it to only responding to readers is like limiting Bluetooth to audio transmission.

[–] lemmyvore@feddit.nl 1 points 2 weeks ago (1 children)

This isn't about subscribing to NFC events, the malware is creating fake NFC events without the NFC sensor being involved in a physical interaction with a tag or reader.

[–] Lojcs@lemm.ee 1 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

No? The nfc sensor is next to the credit card, which is why it's able to communicate with it to relay it.

Why would it need to create fake events? How would that even help?

[–] lemmyvore@feddit.nl 0 points 2 weeks ago (1 children)

There's no credit card involved in this scenario.

  1. The attacker uses phone A and touches the ATM NFC reader. This creates a NFC event on phone A that requests a token.
  2. Phone A sensds the request data to the malware running on victim's Phone V.
  3. The malware on phone V creates a fake NFC event that makes it look like the phone V was touched against the ATM. <-- this is the huge security issue IMO
  4. The app on phone V that's currently associated with NFC contactless payments responds to the fake NFC event by issuing a token.
  5. The malware on Phone V sends the token to phone A.
  6. Phone A uses the token to "prove" to the ATM that the real customer is in front of it.
  7. The ATM asks for the PIN and the attacker supplies the correct PIN (which they've previously obtained via social engineering).
  8. Attacker can now withdraw cash from the ATM from the victim's account.
[–] Lojcs@lemm.ee 1 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

What scenario are you talking about?? From the article:

NGate malware can relay NFC data from a victim’s card through a compromised device to an attacker’s smartphone, which is then able to emulate the card and withdraw money from an ATM.
...
Masquerading as a legitimate app for a target’s bank, NGate prompts the user to enter the banking client ID, date of birth, and the PIN code corresponding to the card. The app goes on to ask the user to turn on NFC and to scan the card.

Physical card is involved, mobile payments isn't.

[–] lemmyvore@feddit.nl 1 points 2 weeks ago

In that case I call bullshit. What I described can work (relaying banking apps on the victim's phone to authenticate to ATM), with cards it should not. If you read the comments on the site you'll see people are just as confused as to how this can work.

[–] umbrella@lemmy.ml 1 points 2 weeks ago (1 children)

android permissions arent meant to be bypassable either but i bet theres malware that does it. its kinda what it does.

[–] lemmyvore@feddit.nl 1 points 2 weeks ago (1 children)

When it happens it's a security flaw and it needs to get patched. It's not normal everyday thing.

[–] umbrella@lemmy.ml 1 points 2 weeks ago* (last edited 2 weeks ago)

exactly! thats what i mean.

[–] hatedbad@lemmy.sdf.org 10 points 2 weeks ago

a surprisingly disappointing article from ars, i expect better from them.

the author appears to be confusing “relay attacks” with “cloning” and doesn’t really explain the flow of the attach that well.

really this just sounds like a complicated MitM attack, using the victim’s phone as the “middle” component between the victim’s physical card and the attacker’s rooted phone.

the whole “cloning the UID attack” at the end of the article is irrelevant, NFC payment cards don’t work like that.

Seems like an easy workaround is to not use your phone as a payment method. Or am I misunderstanding the ars article (which, I must say, is very low quality in comparison to their usual ones)?

[–] Reverendender@sh.itjust.works 9 points 2 weeks ago

Newly discovered Android malware steals payment card data using an infected device’s NFC reader and relays it to attackers, a novel technique that effectively clones the card so it can be used at ATMs or point-of-sale terminals, security firm ESET said.

ESET researchers have named the malware NGate because it incorporates NFCGate, an open source tool for capturing, analyzing, or altering NFC traffic. Short for Near-Field Communication, NFC is a protocol that allows two devices to wirelessly communicate over short distances.