Download AUDACIOUS User-Driven Access Control with Unmodified

AUDACIOUS
User-Driven Access Control with Unmodified Operating
Systems
Studied by
Talia Ringer | Dan Grossman | Franziska Roesner
Presented by
Ryan Tiedemann
What is AUDACIOUS?
AUDACIOUS stands for Android User-Driven Access Control in Only User Space. It
is a secure library implementation thats primary goal is to provide a system for
User-Driven access control in android applications without modifying the underlying
os
It does this through the use of Access Control Gadgets, or ACGs for short. An ACG
is UI element that users can interact with to grant applications access to restricted
resources.
Grant access to GPS Location
Grant access to camera /
Grant access to file system
microphone
Why use User-Driver Permissions?
Under the current permissions system of most modern smartphone operating
systems. An application either has unrestricted access to a resource, or no
access at all.
So why does this matter?
An application that has access to your GPS when you are using it, could also be
accessing your GPS when you are unaware
Currently we have no idea if the applications are secretly uploading all our GPS
locations, or other private resources, to the internet without us even knowing.
So what can we do about it?
What are AUDACIOUS goals?
User-Driven access
control
Ensure that applications can access sensitive resources only
when the user interacts with with the UI (through a ACG)
Unmodified OS
The final implementation should make no changes to the
underlying OS.
Regulate Resource
Use, not just access
Provide guarantees about the flow of sensitive resources.
Permission Model
Flexibility
Allow alternative permissions models for use cases where
user interaction would be inhibiting (A calendar app)
So how is AUDACIOUS going to do that?
Event Flow - Events must be Authentic
How do we ensure that the input event came from the user?
Direct Event Forgery
Indirect Event Forgery
Defense:
Taint Analysis
Monitor events from their source to sink.
If event travels through application code, then it is tainted
UI Context - the UI must not be ‘tricksy’
UI does not deceive the user
User has enough time to perceive the valid UI
Defense:
Dynamic bitmap checks, compare the applications output
with the expected output. This can be done at given time
intervals, or randomly within a predefined time period
Resource Flow - Resources used only as
expected
The application must use the resources only how the user
expects it to
Defense:
Track the flow of resource information through the application
before approving it for distribution
THIS IS done with SPARTA!
How would AUDACIOUS look in a release
environment?
Developers submit their app alongside:
1. Annotated Code
2. ACG Library
3. SPARTA Library
4. Flow Policy
5. Other Libraries
How would AUDACIOUS look in a release
environment?
The code is then automatically analyzed
1. SPARTA Analysis,
a. Detects where the resources end up
2. Event Analysis
a. Check that user input is never tainted
How would AUDACIOUS look in a release
environment?
A human verify approves / denies application
1. A Human verifier will look at the output
from the automated phase
2. Based on the results, the verifier will
make a decision to approve or deny
How would AUDACIOUS look in a release
environment?
Once an application has gone through the approval stages, it is still subjected to
runtime checks that ensure the application is operating as expected
Dynamic bitmap checks
A.The UI is consistent with the event
B.The event is deceptive
C.The UI is deceptive
Only scenario A is acceptable to AUDACIOUS
Does it actually work?
AUDACIOUS developers implemented the library into the above open source
applications.
Listed are the ACGs that the developers implemented into each application
Findings
• In cases where ACG like buttons already exists, swapping them out for ACGs
actually reduced code size
• In cases where it was not, it only added minimal extra code to implement an
ACG
• Event Analysis only takes at most 24 seconds to complete
•
During the testing performed by the AUDACIOUS developers, only 1 of the 5 applications tested
reported
false positives
• SPARTA takes at most 96 seconds to analyse the applications.
• Annotating code for SPARTA is fast for small applications, but a burden for
Performance Impacts
AUDACIOUS performs random bitmap checks at runtime, these can take some
time based on when they are performed.
More checks = slower average
performance
Checking at the same time as a user
interacts with the UI results in much
longer delays
Attack prevention
A Evil Application was developed that attempted to bypass the library security
features.
57 attacks
55 successfully defended
1 of the missed attacks was a result of an Android Bug, where half obscured UI
elements are not flagged as obscured.
The second missed attack was due to a limitation in the Android OS, where
there is no way to detect if a UI element is obscured by a Toast Element
Summary
Brings User-Driven Access Control to the current ecosystem of devices
Implements checks that ensure developers cannot bypass the security features
put into place
Due to no OS requirements, this secure library can be ported to numerous
different platforms with relative ease
Has minimal impact on performance and application size.
Issues
More items to trust (ACG Library, SPARTA, Event analysis, etc)
AUDACIOUS library updates require application updates
ACGs cannot override internal operating system permissions. As such an
application on the Android application, will still ask the user for permissions.
Which could be confusing for the user
Extra work for the developers.
Human verification process could have high costs, long processing times, and
the possibility of mistakes
SPARTA runs on source code, so developers will have to release it to the
Improvements
Redesign bitmap comparison such that it can be done statically before
application deployment
More customisation to ACGs appearance
Implement ACG type security gadgets for other forms of input, such as voice
commands, gestures or motion
Questions?
End of Slides