[Owasp-mobile-security-project] Consideration for Top 10

[Sarath Geethakumar]

Same issue persists on thick clients on pc's nd mac. However, PC/Mac/googles
note book etc are mainly used by end users to access urls using standard
browsers. IE, firefox nd chrome certainly do a good job in securing nd
preventing CSRF. but in a mobile world, we are diverging from browsers to
apps which are analogous to thick clients. If a user visits a site from
mobile browser, most websites now tell the user that they have an app that
can be used for the same. Since we are moving towards the app usage scenario
this has gained more importance.

Moreover ZEUS and other malwares are moving into appstores by posing as
legit apps, per latest research. Zeus targets users using infected pc's and
install browser plugins that instruct the user to download Zeus app from
centralized market place for mobile devices to perform banking operations.

Now coming to the search solution, a company can have multiple products and
need not have unique names. For example amex is only one App from american
express. There could be other apps with common english words as app or
service names. A keywork search in this scenario would not fetch the right
app. I searched for gmail in google market place the other day nd contrary
to expectation googles own app was nowhere near the top of the list. I also
searched for an app made by RIM in appworld using a playbook just to find
that the app never even appeared in the results.

Setting behavoiral patterns cannot defeat the malicious app scenario but can
certainly detect them.
As Jim just mailed me, fraud detection and per-user behavoiral analysis is
the only detection mechanism that i am aware of now.

Would love to know if anyones aware of a prevention mechanism.

Thanks & Regards,
Sarath Geethakumar


On Fri, Jun 17, 2011 at 5:43 PM, <joshbw at analyticalengine.net> wrote:

> Has this problem ever been solved for any other client (PC, Mac, etc)?  To
> the best of my knowledge it hasn’t, but if I am wrong that might be a good
> place to start.  The one thing that sets current mobile offerings off from
> traditional clients is the central app store – it wouldn’t stop malicious
> apps, but if the various App Stores highlighted apps that checked out with
> the correct cert in a stand out benign color and promoted them to the top of
> targeted search queries it would encourage users to select the official apps
> (essentially the model of EV certs but for apps instead of URLs – hopefully
> without the extortionate fees).  By targeted searches I mean if someone
> enters AmEx or American Express as a search query it makes a lot of sense to
> specifically highlight the official AmEx app – it would be
> counter-competitive to do so with a more generic query where the intention
> of the user is less obvious though.  None of that would happen in a context
> where a malicious party has much in the way of control. ****
>
> ** **
>
> *From:* owasp-mobile-security-project-bounces at lists.owasp.org [mailto:
> owasp-mobile-security-project-bounces at lists.owasp.org] *On Behalf Of *Sarath
> Geethakumar
> *Sent:* Friday, June 17, 2011 6:11 PM
> *To:* McGovern, James
> *Cc:* owasp-mobile-security-project at lists.owasp.org
> *Subject:* Re: [Owasp-mobile-security-project] Consideration for Top 10***
> *
>
> ** **
>
> Answers inline <Sarath>****
>
> ** **
>
> ** **
>
> Thanks & Regards,
> Sarath Geethakumar
>
> ****
>
> On Fri, Jun 17, 2011 at 4:42 PM, McGovern, James <james.mcgovern at hp.com>
> wrote:****
>
> Since most mobile applications have to be pushed from a “store” and the
> “store” itself has to somehow uniquely identify the application, is this a
> matter of: ****
>
>  ****
>
> a)      The backend receiving a unique identifier for each person who
> installed****
>
> <Sarath> Assuming the server receives a UUID for every user. Where is this
> Unique identifier stored? On-Device, decompilable code, String
> pool/C-Strings in an application binary. The real question is How long does
> it take a skilled attacker to retrieve this unique ID and make a fake app
> which uses this ID. Even if this UUID is not shared with the app, then lets
> look at how the app will correlate with backend in next step...****
>
> b)      The “installer” providing some form of unique GUID that can be
> correlated with A****
>
> <Sarath> Installers only install the app, they do not execute the app.
> Between installation and first run, where does the app/installer store the
> GUID. Whats stopping an attacker from retrieving or modifying the GUID
> before first execution. ****
>
> Would love to understand why code signing such as MS Authenticode couldn’t
> detect app tampering or recompilation****
>
> <Sarath> Security decision in the hands of the user, thats exactly what
> Android does now. Code signing  merely allows a user to see who developed
> the code and if the code has been tampered with. "While not guaranteeing
> bug-free code, Authenticode identifies the publisher of signed software and
> verifies that it hasn't been tampered with, before users download software
> to their PCs. ". Authenticode or code signing mechanism does not tell the
> user if the banking application they download from the appstore or market
> place is a malware or not or even if the app developer is a legitimate
> NON-MALICIOUS developer. There is NO SOP in mobile apps that prevent them
> from gaining the user credentials, provide seamless usage to end-user and at
> same time upload creds to attackers server.****
>
>  ****
>
> If you aren’t a fan of GUID, crypto, etc could we use an old school
> technique such as “port knocking” or similar convention (improved flavors of
> it though)?****
>
> <Sarath> I dont see that many web/mobile apps that use port knocking now a
> days. Besides the point, If I take a mobile application from the market
> place and recompile it to steal credentials without changing anything else,
> How will the server detect that the app has been compromised? The app still
> uses port knocking but still malicious too.... ****
>
> ** **
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> *From:* owasp-mobile-security-project-bounces at lists.owasp.org [mailto:
> owasp-mobile-security-project-bounces at lists.owasp.org] *On Behalf Of *Sarath
> Geethakumar
> *Sent:* Friday, June 17, 2011 7:33 PM
> *To:* owasp-mobile-security-project at lists.owasp.org
> *Subject:* [Owasp-mobile-security-project] Consideration for Top 10****
>
>  ****
>
> Fellow Security Enthusiasts,****
>
>  ****
>
> I have been a silent member of the OWASP mobile security poject for a while
> now, mainly because of my travel and work schedule.****
>
> However, I really see that this group has been doing an amazing work with
> some of the top 10 vulnerabilities listed on the OWASP wiki.****
>
>  ****
>
> My name is Sarath Geethakumar and I'm an Information Security Specialist at
> American Express. My research and area of work encompasses mobile and
> wireless security.I would like to take this opportunity to put forth another
> threat/vulnerability to be considered for OWASP Top 10 mobile threats (or
> learn from this group, if this issue has a fix that I'm not aware of).****
>
>  ****
>
> We have been hearing a lot of news and information regarding Fake banking
> applications and trojans in Android market place. ****
>
> These trojans and malware go undetected as they speak the same language as
> a legit banking app - XML based communication with backend webservice or web
> application.****
>
>  ****
>
>  ****
>
> This brings us to one of the most challenging mobile security issues faced
> by developers and security architects today: *Lack of Data Source and
> Client side integrity attestation*****
>
> (I'm not sure if this point is already under consideration or ever
> considered, as I could not find any direct points addressing this issue on
> the wiki).****
>
>  ****
>
> In simple words, How can the backend detect and identify the source of
> origin of a request? We had faced similar issues with web applications,
> probably a while ago, and which we termed as CSRF (cross site request
> forgery). Though we were able to incorporate security controls and features
> for CSRF, we are still to deal with the same in mobile application space,
> i.e. to identify where or which app a request originated from.****
>
>  ****
>
> I have heard and seen a couple of potential fixes in the past, all of which
> failed to fix the root cause of this issue. Putting unique identifiers,
> encryption keys on device/code etc are definitely not the solution. From a
> threat modeling perspective, any request coming from a mobile device can be
> forged or compromised if the device is rooted or if the application is
> compromised or recompiled with malicious intention.****
>
>  ****
>
> To aggravate the situation, current mobile devices have dual core
> processors and good amount of RAM to facilitate on-device application
> modification and recompilation. This has been successfully demonstrated by
> apps like "Privacy Blocker" which has the ability to scan other apk's and
> modify then on the device itself. This issue is not only a threat to banking
> applications but also for any application that relies on data provided by
> mobile device for purposes of tracking, licensing, etc etc.....****
>
>  ****
>
> *Cutting my point short, I would like to open a discussion on this topic
> so as to consider "Lack of data source and client side integrity
> attestation" as a potential candidate for OWASP's Top 10 mobile threats.**
> ***
>
>  ****
>
> I'm pretty sure that this will open the floor for some good discussion.
> Looking forward to hearing your thoughts and comments. Would love to know if
> someone already knows a fix or potential fix for the same.****
>
>  ****
>
> PS: Pardon any delay in mail responses, as my access to personal mail is
> very limited during working hours.****
>
>  ****
>
> Thanks & Regards,
> Sarath Geethakumar****
>
>
> _______________________________________________
> Owasp-mobile-security-project mailing list
> Owasp-mobile-security-project at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-mobile-security-project****
>
> ** **
>
> _______________________________________________
> Owasp-mobile-security-project mailing list
> Owasp-mobile-security-project at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-mobile-security-project
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-mobile-security-project/attachments/20110617/3139306b/attachment-0001.html