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.
Some vendors refuse cooperation.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.
Talking to GoodThe 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.
Yet.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:
None of these were accepted by Good. They simply ignored all of our options and asked for technical details.
We decided to chose option two, Full Disclosure.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.
---------------------------------------------------------------- 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.