Example abuse cases and policy

Dear all, 

 

Please find below some of the abuse cases and policy to address one of
the examples that I outlined in meeting yesterday.

 

What are the Dangers?

 

Let's look at the landscape that is being created. We are enabling
cross-platform, cross-device, easy to develop, highly functional
applications based on browser technology that has been proven repeatedly
to be untrustworthy - a perfect recipe for evil. Will this meet all the
criteria for really successful malware on mobile? Are we unintentionally
opening Pandora's Box?

 

Up until now the measures taken by the mobile industry have proved
highly successful and ensuring no major malware incident has affected
the industry. There have been attempts: the MMS-spreading Commwarrior is
probably the most infamous, along with the Spyware tool, Flexispy. An
additional factor in ensuring the success of mobile security has been
the fact that mobile platforms have been too fragmented and complex,
therefore not representing an attractive target so far. Existing modus
operandi from technology-related attacks can provide indicators as to
the types of attack and abuse that we can expect on widgets and web
applications as we open up device APIs. Here are some examples.

 

Example 1 - Premium Rate Abuse

A widget that seems benign but is actually spewing out SMSs to premium
rate numbers without the user's knowledge. 

 

This could be modified from an original safe widget such as a game. For
the malware author, the key piece to solve is to dupe the user into
thinking that the SMS capability is something that is part of the
original application. Examples of this have been seen in the past,
created from games and this model could be used for 'diallers' too
(which plagued the desktop world in the days of dial-up networking).
There have been recent warnings about this kind of abuse from security
firms.

 

Example 2 - Privacy Breach

An application that gains access to locations, contacts and gallery,
silently uploading the data in the background to a site owned by the
attacker.

 

This is something that has been a clear goal for attackers already.
There have been numerous high-profile examples in the past in the mobile
world. Celebrities such as Paris Hilton, Miley Cyrus and Lindsay Lohan
have all had private pictures, phone numbers and voicemails stolen from
devices or networks in clear breach of their privacy. There has been
embarrassment for teachers who had their pictures and videos copied by
the children in their class and spread around school. The most
high-profile case in the UK of a mobile related privacy breach was that
of the News of the World's use of voicemail hacking to gain access to
private information about Royalty. The Royal editor, Clive Goodman was
jailed for four months and the editor, Andy Coulson resigned over this
blatant privacy breach. Given the appetite for breaching privacy, users
need to be safe in the knowledge that their personal data will not leak
in any way.

 

Example 3 - Integrity Breach

A widget that replaces the voicemail number with a premium rate number
instead?

 

There are number of reasons why an attacker would want to breach the
integrity of the device. Simply changing the telephone number of the
voicemail that is stored on the device could be enough to make an
attacker a lot of money. Users usually have a shortcut key to their
voicemail and may not notice for a long time that anything is wrong. A
more sinister use could be to plant evidence on a device. Pictures,
files and even criminal contacts could potentially be anonymously
planted all without the user's consent or knowledge. Proving innocence
could suddenly become very difficult.

There are also a number of reasons why somebody would want to steal
data. The contents of corporate e-mails would be very interesting to a
competitor, as would sabotaging data stored in spreadsheets and
presentations on the target phone.

 

Example 4 - Phishing

Widgets contain web content - it is easy to duplicate and masquerade as
something legitimate... perhaps a bank?

 

In January 2010, Google removed a number of applications from the
Android Market which were supposed to be banking applications for a
number of different banks worldwide. It is unclear whether these
applications were intentional phishing applications. The removal was
based on a breach of terms and conditions surrounding copyright. The
episode however highlighted the phishing potential. Widgets contain web
content, therefore it is very easy to duplicate the look and feel of
something that  the user trusts and proceed to abuse that trust either
by stealing credentials or by manipulating money transfers. 

 

These are of course just examples to consider in relation to how we
would manage the policies for device APIs and are of course not
exhaustive. Alongside the device-API specific examples above, we still
need to consider traditional web threats which pose a significant risk
and lots of other types of attack which should be considered in a formal
threat model.

 

Policies to deal with one of the examples above

 

In the case of widgets on mobile devices we must take into account that
there are multiple layers of security which will already be dealt with
before a device API gets called. For example: digital signing of
widgets, application store inspection and installation checks. The next
stage would be to protect the user from potential abuse of the device
APIs.

 

Using XACML as recommended in OMTP BONDI, we can describe some policies
to deal with one of the threats above:

 

Example 1 - a policy to defend against premium rate abuse:

 

The example assumes that a number of mechanisms have already been
defeated in the security chain - the application is trusted and is on
the device. If the user (or the policy provider) has stated that they
don't want to call premium rate numbers in the UK:

 

<target>

    <subject>

        <subject-match attr="author-key-root-fingerprint">sha256
******** root fingerprint of author **** />

    </subject> <-- to identify the Identified domain, the same would
apply for the Unidentified domain-->

</target>

<rule effect=one-shot>

    <condition>

        <resource-match attr="dev-cap" match="messaging.*.send"
param:recipients="+4409*" func="glob"/>  <-- to block UK premium rate
numbers -->

    </condition>

</rule>

 

We could extend this to other countries if we are concerned that premium
rate numbers would not only be from the host country. Here is an example
of a policy fragment for blocking Spanish premium rate numbers that
could be added, along with the condition combining operator (please
note: there are probably more elegant ways of expressing this by using
regular expressions)::

 

    <condition combine=or>

        <resource-match attr="dev-cap" match="messaging.*.send"
param:recipients="+4409*" func="glob"/>  <-- to block UK premium rate
numbers -->

        <resource-match attr="dev-cap" match="messaging.*.send"
param:recipients="+34806*"  func="glob"/>  <-- to block Spanish premium
rate numbers -->

    </condition>

</rule>

 

If the malicious widget is out in the wild already and has been
identified, then we want to prevent it from installing and executing on
devices, halting the spread of the malware in its early stages of
distribution.

 

Clearly, if the widget is prevented from installing, then it cannot call
a device API - these functions are shown as a belt and braces example:

 

<target>

    <subject>

        <subject-match attr="id" match="http://www.maliciouswidget1.org
<http://www.maliciouswidget1.org/> " />

    </subject>

</target>

<rule effect=deny>
   <condition combine=or>

    <resource-match attr=widget-install />
     <resource-match attr=widget-instantiate />

    <resource-match attr=api-feature match=* />

    <resource-match attr=dev-cap match=* />  
    </condition>
  </rule>

 

As can be seen, very powerful policies can be implemented very easily.
We can add more example policies and threats as this work continues.

 

 

Thanks,

 

 

 

David.

 

 

David Rogers
OMTP Director of External Relations