mod%log

From time to time, we publish security advisories about vulnerabilities in software. We always do Responsible Disclosure according to our Responsible Disclosure policy. There was only one exception to this principle in the past: a blog-posting about a minor flaw in HTC’s SSL certificate handling routines which was basically a repeating issue in 2013.

Sometimes, vendors need a lot of time to fix their problems. That's totally fine with us and we always agreed on extending our timeline until public release of a security advisory. Sometimes we have to deal with a vendor or business that is not experienced with external security researchers submitting security advisories, following certain Responsible Disclosure policies. Most of the discussions with vendors are very friendly and considerately, concerning the risks the vendor and its customers may be exposed after publication. We never publish security advisories with the intention to harm vendor's reputation or its customer's system-security. We always convinced vendors and customers that it is beneficial for everybody to provide security relevant information to the public - in coordination with the vendor.

I think the reason for the refusal of cooperation is based on overvalued self-confidence, ignorance or chemtrails. Even staff of inexperienced vendors can usually be educated regarding the value and benefits of proper coordinated disclosure - the ones mentioned above not. And I am somehow tired of listening to flimsy excuses, menaces and threats of legal trouble.

The reason for this blog-posting is Good Technology. In June 2013 we identified a remotely exploitable vulnerability in Good's Mobile Device Management (MDM) Suite "Good For Enterprise" that allowed remote attackers to hijack administrative accounts. We followed common responsible disclosure principles and contacted Good, providing a timeframe of 45 days to fix a simple, persistent Cross Site Scripting related vulnerability. They asked for another 60 days and said they would like to provide "updates or corrections" to the final version of our advisory. However, Good used the remaining 50% of the E-mail to express their understanding of their certain license conditions and provided their legal standpoint "just FYI". Eventually they emphasized their disrespect towards us with the following statement, knowing that nobody did any reverse engineering to benefit from their "secret sauce":

I could get our legal team to provide the exact language, but it pretty much disallows doing certain things with the software (i.e. no reverse engineering or other activities designed to discover our "secret sauce") - E-mail from GOOD, July 11th 2013

We didn't publish any detail about this vulnerability.

In September 2015 we found another security vulnerability in probably all Good Technology products that make use of Good's Authentication Delegation mechanisms. We told Good Technology about a new vulnerability, and that we are undecided how to proceed, as Good told us in 2013: "our lawyers would definitely argue that disclosing the results could result in negative repercussions to Modzero."

Thus we asked how to proceed with the new security issue and proposed three options:

1. Responsible Disclosure,
2. Full Disclosure,
3. We keep everything private.

None of these were accepted by Good. They simply ignored all of our options and asked for technical details.

Because we are tired of dealing with lawyers, when we already provide quality assurance to the vendor for free. Because we do not provide reputation assurance to the guys with the lawyer-backed CIRT.

We do not agree with the manner how the messenger is blamed. We are not responsible for the failures of software vendors. We believe in failosophy, the way to recap and learn from own mistakes. We do not back down when we see that a vendor spends more effort with issuing gagging orders rather than fixing vulnerabilities. It is common that vendors are pretty pleasant these days when it comes to bug-reports. Many vendors even pledge bug-bounties to motivate researchers to submit their findings, rather than selling them on the black-market.

You are welcome.

---------------------------------------------------------------- v1 -

modzero  Security  Advisory:  Insecure application-coupling  in  Good
Authentication Delegation [MZ-15-03]

---------------------------------------------------------------------

---------------------------------------------------------------------

1. Timeline

---------------------------------------------------------------------

 * 2015-08-18: Vulnerability has been discovered
 * 2015-09-09: Vendor contact to agree on responsible disclosure
 * 2015-09-25: Public Disclosure.

---------------------------------------------------------------------

2. Summary

---------------------------------------------------------------------

Vendor: Good Technology, Inc.
Products known to be affected:
 * Combination of Android Good Dynamics SDK version 1.11.1206
   Android Good Access app version 2.3.1.626
   Android Good for Enterprise app version 3.0.0.415
   Good Control server version 1.10.47.31
   Good Proxy server version 1.10.47.2
   Good for Enterprise server version 7.2.2.5c
 * Other products, versions and apps using authentication-delegation
   may be affected as well.
Severity: Medium/High

The  Good Mobile  Device  Management solution  provides two  separate
Android  applications,  Good  for  Enterprise [1]  (a  mobile  device
management Android application with functionality such as E-Mail) and
Good   Access  [2]   (an   Android  application   that  has   similar
functionality as  a regular  browser app  to access  company intranet
servers). Both  apps use  the underlying  Good Dynamics  framework to
communicate with  the Good server  located in the  customer's company
network.

Authentication delegation  is a method  to provision the  Good Access
Android app by using the Good  for Enterprise Android app. Using this
mechanism, an employee does not  need to manually enter an activation
key to  provision the  Good Access  app, if  Good for  Enterprise was
already provisioned before.

Third-party apps can  spoof their identity and try  to request access
to company  servers and  data. Users could  be tricked  into allowing
access to  company intranet servers to  a faked Good Access  app. The
server  administrator   is  not  able   to  prevent  or   detect  the
unauthorized access.

A CVE has not yet been assigned to this vulnerability.

---------------------------------------------------------------------

3. Details

---------------------------------------------------------------------

As a  precondition for this  vulnerability, the Good servers  have to
allow access to intranet servers on  the company network via the Good
Access app. It is also  necessary to enable authentication delegation
through Good for Enterprise.

A  specially  crafted third-party  Android  app  can use  an  Android
package  name  that starts  with  "com.good.gdgma"  (the Good  Access
package name). Subsequently the app is able to announce itself as the
Good Access app to the authentication delegate (Good for Enterprise).
The user of the Android device has to explicitly grant access to this
third-party app  [3], even  though the specially  crafted application
might be indistinguishable from the legitimate  app for a user. It is
possible to activate not only one, but several faked apps through the
authentication  delegate (Good  for  Enterprise)  by using  different
package  names (e.g.  "com.good.gdgma.test1", "com.good.gdgma.test2",
etc.).

The Good Dynamics server administrator  can not distinguish between a
malicious third-party  app and  the legitimate app  accessing company
data, as  the provisioned app  in the  Good backend web  interface is
showing that Good Access was provisioned.

As  a  mitigation the  Good  for  Enterprise  app could  protect  its
authentication-delegation-API intent (Android IPC mechanism) with the
signature level  protection provided by the  Android operating system
(android:protectionLevel="signature"). Only apps signed with the same
private key can use such permissions.

---------------------------------------------------------------------

4. Impact

---------------------------------------------------------------------

After tricking  a user  into installing  a modified  application that
pretends  to  be  a  Good   Access  app  towards  the  authentication
delegation mechanism, the missing  authentication can be exploited to
gain access to the intranet  data via the Good servers. Additionally,
other   third-party  apps   could   request   permission  to   access
company-data from  the user  - the Good  server administrator  is not
able to prevent usage of such third-party apps.

---------------------------------------------------------------------

5. Proof of concept exploit

---------------------------------------------------------------------

As a  proof of concept, an  example app of the  Good Dynamics Android
SDK can  be used.  modzero used  the ApacheHttp  example application.
After  loading the  example project  in the  Android Studio  IDE, the
GDApplicationID variable in the included settings.json file has to be
changed  to "com.good.gdgma".  Additionally the  package name  in the
AndroidManifest.xml file must be changed  to a value that starts with
"com.good.gdgma". The included classes have to be refactored to match
the new  package name. After  installing the example  application and
clicking  the  button  to  use authentication  delegation,  Good  for
Enterprise will  show the  dialog to confirm  access to  company data
[3]. If  the user enters  his Good  for Enterprise app  password, the
malicious application is allowed to access intranet servers [4].

An alternative  to demonstrate the  issue is probably  to disassemble
the  Good Access  app  via apktool  [5], add  malicious  code to  the
application and reassemble the app via apktool.

---------------------------------------------------------------------

6. Workaround

---------------------------------------------------------------------

Users can deactivate authentication  delegation and revoke access for
Good Access. Another workaround is not known.

---------------------------------------------------------------------

7. Fix

---------------------------------------------------------------------

It is not known to modzero, if a security fix is available.

---------------------------------------------------------------------

8. References

---------------------------------------------------------------------

[1] https://play.google.com/store/apps/details?id=com.good.android.gfe
[2] https://play.google.com/store/apps/details?id=com.good.gdgma
[3] http://www.modzero.ch/advisories/media/good_dynamics_provisioning.png
[4] http://www.modzero.ch/advisories/media/good_dynamics_usage.png
[5] https://ibotpeaches.github.io/Apktool/

---------------------------------------------------------------------

9. Credits

---------------------------------------------------------------------

 * Tobias Ospelt

---------------------------------------------------------------------

10. About modzero

---------------------------------------------------------------------

The  independent  Swiss  company  modzero  AG  assists  clients  with
security analysis  in the complex  areas of computer  technology. The
focus  lies  on  highly  detailed  technical  analysis  of  concepts,
software  and  hardware components  as  well  as the  development  of
individual solutions.  Colleagues at  modzero AG work  exclusively in
practical, highly  technical computer-security areas and  can draw on
decades  of experience  in  various platforms,  system concepts,  and
designs.

https://www.modzero.ch

contact@modzero.ch

---------------------------------------------------------------------

11. Disclaimer

---------------------------------------------------------------------

The information  in the advisory  is believed  to be accurate  at the
time of publishing  based on currently available  information. Use of
the information constitutes acceptance for use in an AS IS condition.
There are no warranties with  regard to this information. Neither the
author  nor  the publisher  accepts  any  liability for  any  direct,
indirect, or  consequential loss  or damage arising  from use  of, or
reliance on, this information.