No, FLAG SECURE does not protect you from a11y malware (and Google couldn't have protected 2FA tokens that easily)

Tags: #android, #a11y, #FLAG_SECURE, #malware.

Last week, an article by @campuscodi ZDNet caught my eye. The headline is: "Google could have fixed 2FA code-stealing flaw in Authenticator app years ago". The article refers to a blog post by NightWatch Cybersecurity.

This caught my eyes for two reasons: to the best of my knowledge, 1) protecting from a11y is not that easy (it's definitively not just a matter of adding one flag); 2) the article mentions that FLAG_SECURE could be used for this purpose.

I've worked with a11y for the Cloak & Dagger project, and one of the net results was: if an app gets a11y, it's game over. (BTW, news from today: Kaspersky found WhatsApp-spying stalkware using a11y. I can't say I'm shocked :-))

So, I did some digging, and I published a quick twitter thread with the main takeaways. To not repeat myself, here it is:

I've then released my proof-of-concept on github.

The victim app simulates two activities providing 2FA tokens. One of the activity is protected by the FLAG_SECURE flag, the other one is not. The POC dumps on logcat what it can see via a11y: in all my tests, the POC can leak the tokens for both the protected and unprotected activities. So, I don't think the FLAG_SECURE is useful in this context.

A couple of Android infosec folks (@fs0c131y and @MaverickRocky02, thank you!) tested it and confirmed that I'm not insane: a11y does not seem to be affected by FLAG_SECURE.

If you have some cycles to check as well, please do so! I would be happy to stand corrected.

I hope this post provides a Google-friendly resource that a11y nerds can find when looking for it.


comments powered by Disqus