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

[Sarath Geethakumar]

All,

This brings some good questions and points about the scope and limits of
OWASP mobile security initiative.

Excellent points Rohit, though my thoughts don't exactly align with all of
those.

First of all, My understanding was that the OWASP community caters to the
cause  of application Security as a whole as opposed to serving the needs of
any particular group or ecosystem related to technology - be it developers,
test engineers or security architects. Polymorphic malware and inability to
attest to the integrity of an application, especially when these
applications are the prime source and future of mobility, are definitely
points of concern for app sec enthusiasts.  OWASP, as of now, has a wealth
of information for devs, testers, pen testers, sec architects and even
efforts to develop standards and secure solutions (ESAPI, Training materials
etc...). As I mentioned in my first mail, I was a silent observer of this
forum for a while and may not have realized if the objectives of the mobile
group are different and only caters to developer needs at the moment. If so,
I agree that the issue I brought up cannot be addressed here and apologize
for the same.

However, I look at Security as a wholesome approach and effort. From my
understanding, Zeus malware creators do not care what medium they choose to
deliver, execute or exploit security loop holes. From my experience,
whenever security is dissected into multiple unrelated ecosystems, we often
come up with obvious but unrealized and gaping security holes.

I totally agree with you that putting any sort of excessive control on the
client side will be promoting security by obscurity and that is exactly what
I have been conveying with my replies to some of the excellent ideas and
suggestions so far. But that shouldn't deter us from researching or
contributing towards this issue, if this is the right forum. The fix for
CSRF is pretty simple, but is a novel idea that solved a problem once
considered unsolvable. My intent here is to make all possible stakeholders
aware of the impending threats or security loopholes, if any, as we venture
in to a new era of mobility.

Coming to the point of iPhone malware : iPhone is definitely a yardstick for
comparison as Apple set the starting stage for the race. Researchers have
successfully demonstrated that Apple appstore application vetting process is
not fool proof and can be used to inject or introduce malware (SpyPhone was
one of the POC's). There are fewer MAC targeted malwares as compared to
those for PC's, but that doesn't stop us from neglecting either PC/MAC
security. There are some wonderful research and analysis papers, articles
and blogs by some of the leading security researchers and organizations
pointing to potential vulnerabilities in appstore distribution process.
However, from reality - Malwares have always existed and will exist on
Android, Blackberry, Symbian, iPhone and even Windows Ph 6/7 platforms.
Fortify, FSISAC, Sophos, LookOut etc etc have some really good information
on these (I'm not associated with any of these companies and hence do not
want to make this mail look like a marketing gimmick, hence no links).

We must also realize that in the mobile device ecosystem relying on thick
client apps without:
- SOP
- ability for network traffic analysis
- signature based intrusion detection
- without ability to perform platform integrity, we are setting the standard
for a security posture by replying entirely on the the appstore distribution
process which is not fool proof, atleast as of now.

My 2 cents. Again, if this topic is off the limits of OWASP mobile security
initiative, then I would be glad to take this topic and research to other
appropriate groups. Any comments/suggestion/pointers welcome!!! Thank you
all in advance.

*P.S: With new developments in mobility, no one can be certain that iOS
devices will retain their popularity for ever. If Android with its new
SDK/HDK becomes more popular, where would be stand in terms of security
posture? Will we always accept this as an inherent risk of associated
technology or try to fix the same?*


Thanks & Regards,
Sarath Geethakumar


On Sat, Jun 18, 2011 at 7:57 AM, Rohit Sethi <rklists at gmail.com> wrote:

> I agree with Josh. It looks like the real issue here is the
> distribution of applications rather than anything within the app code
> itself. Ultimately any controls built into the client will amount to
> obscurity.
>
> Does this problem exist with non-jailbroken iPhone apps? I know it
> does theoretically - but has it actually happened the same way it has
> for Android?
>
> Sarath, your point is valid that this is a real mobile security
> concern but it seems to be focused on a different segment of the
> ecosystem than application developers. The question here is will the
> OWASP mobile security project attempt to handle threats in application
> distribution or not? If not, who will?
>
> On 6/17/11, Sarath Geethakumar <sarath at sarath-g.com> wrote:
> > 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
> >>
> >>
> >
>
> --
> Sent from my mobile device
>
> Rohit Sethi
> SD Elements
> http://www.sdelements.com
> twitter: rksethi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-mobile-security-project/attachments/20110618/7dca6d2d/attachment-0001.html