No, FLAG SECURE does not protect you from a11y malware (and Google couldn't have protected 2FA tokens that easily)
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 actually don't think Google could have fixed this so easily. Re: stealing 2FA tokens, Cerberus uses accessibility service (a11y), not screenshooting (ref: https://t.co/7w0ls5kTqA). And to the best of my knowledge, FLAG_SECURE prevents screenshooting, not a11y. 1/n https://t.co/1weXG6QNPG
— Yanick Fratantonio (@reyammer@infosec.exchange) (@reyammer) March 9, 2020
Now, the original post (by @nightwatchcyber, https://t.co/axfxASvHxb) mentions that "FLAG_SECURE prevents that behavior even via accessibility permissions.", and it links to a FAQ of Google Accessibility Scanner (https://t.co/OcwCZAmMIw). 2/
— Yanick Fratantonio (@reyammer@infosec.exchange) (@reyammer) March 9, 2020
But Accessibility Scanner != a11y. Accessibility Scanner is an Android app (https://t.co/sf3Qn0gGj0), and it suggests developers a number of "accessibility improvements". It seems using a11y AND screen recording, and I believe FLAG_SECURE would only affect the latter. 3/
— Yanick Fratantonio (@reyammer@infosec.exchange) (@reyammer) March 9, 2020
I hacked a quick POC and my test a11y can dump all tokens, with or without FLAG_SECURE (will upload poc later tonight). Tested on Android 10. Also, The FLAG_SECURE docs don't mention anything about a11y (ref: https://t.co/bxqxCCZsDl). 4/
— Yanick Fratantonio (@reyammer@infosec.exchange) (@reyammer) March 9, 2020
But then I've seen that @LukasStefanko also suggested that FLAG_SECURE protects from a11y (https://t.co/7CLkUbefnV), and I fear I'm missing something :-) Anyone has more knowledge? /cc @threatfabric @nightwatchcyber @LukasStefanko @virqdroid @fs0c131y @maddiestone 5/
— Yanick Fratantonio (@reyammer@infosec.exchange) (@reyammer) March 9, 2020
BTW, we discussed these "a11y to steal 2FA" + "steal unlocking code to lock the device" in our 2017 C&D paper (https://t.co/khlL0xoshM). Interesting that malware picked them up ;-) 6/
— Yanick Fratantonio (@reyammer@infosec.exchange) (@reyammer) March 9, 2020
Anyways, if FLAG_SECURE can protect from a11y, that's news to me and it's good. When I last talked to Google about it, the answer was always "we can't fix it -- it would break benign use cases" aka "if malware gets a11y, it's game over & that will not change any time soon". 7/7
— Yanick Fratantonio (@reyammer@infosec.exchange) (@reyammer) March 9, 2020
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.