NFC Vulnerability!

---

http://phandroid.com/2012/07/26/hack...urce=pulsenews

Sent from my HTC One XL using xda app-developers app

good read good thing i keep my nfc off all the time

Can anyone confirm that the radio is actually off when NFC is unchecked in settings?

Sent from my HTC One XL using xda app-developers app

This vulnerability affects very few users. Furthermore, those users that it does affect must have their phone's screen turned on for the vulnerability to be exploited. Surely if you have your screen on, you'd be aware of any foul play from third parties; why are you worried?

Screen has to be on and it has to be VERY close or near (hence the n in nfc)

Sent from my Nocturnal HOX

Originally Posted by JamesR913

Screen has to be on and it has to be VERY close or near (hence the n in nfc)

Sent from my Nocturnal HOX

Screen on, device unlocked *and* within a few cm of this device (this is the NFC antenna portion of the device, not just anywhere on the device).

I'm rather interested in how exactly this could be done. Though I reckon it could potentially be dangerous to publicly release that info, I could call it a case of "it's not a bug, it's a feature" and do pretty useful things with it. I'm thinking along the lines of making the phone connect to wifi, which without such hacks is only possible if the phone that scans it has one from a number of NFC apps installed. Pre-installing that app too just so you can log into wifi at someone's house kind of eliminates the purpose of using NFC to login in the first place.

If you programmed a NFC tag with a url that contained embedded javascript (or escaped characters that would later unescape to javascript) *and* the browser interpreted them instead of ignoring them or invalidating the whole url... maybe. But it's a big 'if'.

Most new-ish browsers now disallow Javascript in URLs. The other main attack vector would be a trusted site with reflected XSS vulnerability (ie, a site that renders URL-encoded parameters into the rendered page, like a 404 page that displays the requested URL within the error message), but it's more likely that an attacker would just host his own page since the URL target of a NFC tag is opaque until read, anyway.

The main thing: don't allow NFC to launch the browser without previewing the URL's value, and don't preview the url's value in any container that can be induced to interpret its content as HTML.

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2

Well, if it is possible to make someone connect to wifi using javascript, then it might be interesting to put a small website online with just that bit of javascript. I could then put a hyperlink to that page in the NFC tag. Would still require internet access, but it would use a lot less data to work that way (the normal way is installing an app first, which costs way more data) and it would also be faster and require less actions. From the user's view, it is a lot more elegant. This would mean you don't have to inject the javascript directly into the url and run the risk of the url being blocked by the browser.

Bad side is that you will in all likelyhood practically be putting your wifi password on the internet. That might be a major security issue.

That is assuming it is possible to make devices connect to wlan using javascript, which I understand from your post it is, though I can't find out any information on this.

What do you think about this theory?

It depends mainly upon how Android handles NFC events. If it fires an intent that relays the NFC tag's content to a handler that blindly fires it off as another intent, or blindly opens it in a browser window... well... there's a good chance that Bad Things(tm) will eventually happen somehow. If Android makes at least half an attempt to sanitize the NFC-read content, and doesn't have any command-injection vulnerabilities along the way, it'll probably be OK.

I'm still reading up on Android's specific implementation of it. Much of what I wrote above is actually based on naive handling of QR-encoded URLs.

Speaking in the abstract, the worst thing I can imagine an end user doing today is downloading (or writing) cobbled-together handler with no sanity-checking or sanitizing that registers itself as a listener for NFC events, gets the user to make it the official handler, then does something completely stupid, like reading the String straight from the tag and using it to blindly construct a new Intent and fire it off. The thought of someone doing that gives me chills.