UPDATE: 11/8 - Winners Announced! It is with great pleasure to announce the winner of the Ray Wenderlich Ultimate Pro Subscription for our AMA… @mohanhid! Thanks to everyone who participated in our first AMA, including: @jwb, @Marcin, @Aleon_Q, @Chuck-R, @Anoniim, @dgoulart, @Filippos_Sakellaropo, and @Taotronics. We hope to see you back soon!
We’re open for questions! In honor of #CyberSecurityAwarenessMonth, we invite you to connect with some of the key stakeholders at Guardsquare during this Ask Me Anything (AMA). Starting Monday, October, 25th and running through Friday, October, 29th, we’re welcoming all of your questions about mobile app protection and mobile app security testing. Follow us here and on our social handles as we’ll have more news about our hosts and some exciting prizes!
To provide you with holistic responses regarding mobile app security and how Guardsquare continues to be the industry leader, several of our Product Team members will be hosting our AMA! In addition, we’re giving away a Ray Wenderlich Ultimate Pro Subscription to a lucky participant, compliments of our friends at Ray Wenderlich.
Ok… Here’s what you need to know…
Ideas for topics!
Mobile App Security
Discuss mobile app security landscape, evolving threats, or even concerns, challenges, or product-specific feature / functionality recommendations.
ProGuard, AppSweep, Playground, ProGuard CORE and our other free or open source tools
Any feature requests? Or questions about AppSweep or mobile app security testing?
Questions about DexGuard, iXGuard, Threatcast that aren’t technical support related.
Miscellaneous
Have something on your mind not related to the above subjects? Ask away!
NOTE: The below types of posts are out of scope and will be removed or addressed outside these forums
Any post deemed inappropriate will be removed at the discretion of the Community Manager.
Any technical support questions for DexGuard, iXGuard, or ThreatCast will be removed.
If you have a ProGuard support question, we will shift it from the AMA to a seperate topic and help there.
Any questions that contain sensitive information (either showing customer information or proprietary information) will be taken offline. For customers, we will direct message them to ensure our response is personal and immediate.
Other guidelines about the AMA
Responsiveness: We have a team of experts worldwide who will be contributing to the event, so it’s our goal is to provide an answer to your question the same day you ask it.
Giveaway: To be eligible for the Ray Wenderlich Pro Subscription, you must post a question that does not violate the out-of-scope guidelines at any point starting Monday, October 25 through Friday, October, 29th. The winner will be chosen at random and announced on Tuesday, November 2nd, here as well as across our social channels.
Feel free to ask your question ahead of October 25th, however, our hosts may not be readily available to promptly answer your questions.
@Jesse The nice thing about DexGuard is that it is backward compatible with ProGuard, so the rules for your ProGuard configuration can be reused with DexGuard. ProGuard Playground doesn’t support DexGuard specific rules, but we’d love to hear ideas about how you want to use our tools! Reply if this is an important use case for you.
We’re also making improvements to make our products work together. A great example of this is the recent updates to ProGuard Playground, which included the ability to launch a Mobile Application Security Test leveraging AppSweep. It’s integrated so you only have to upload your APK once, and you can easily see the summary of your security test in the ProGuard Playground.
Hi Product Team - I’m on the fence about applying iXGuard. Considering iOS already comes with standard security features, why would I need iXGuard / what does it do differently? Thank you
Hi @jwb, Anton here, a product manager of iXGuard. Since I don’t know the exact threat model for your application or library, I will give you somewhat a generic answer, but please feel free to ask follow-up questions.
Why you may need iXGuard:
iOS security features may protect the phone user from making a bad move by accident, but they are hardly an obstacle against attacks done on purpose. We have a wonderful blog article here about some most common misconceptions of iOS security: 3 Misconceptions About iOS Mobile App Security | Guardsquare.
Here are some examples of commonly available tools that reverse engineers may use:
While reverse-engineers may prefer to use a jailbroken device, it’s not necessary for redistribution and use of modified applications.
iXGuard mitigates the risks associated with reverse engineering and tampering.
What does iXGuard do differently:
iOS application encryption is reversible (meaning that at some point in time the application will be restored to its original form - this is why it’s possible to capture a decrypted .ipa from a device), while iXGuard obfuscation is irreversible (meaning that at no point in time the application is fully “deobfuscated”).
iOS methods are generic, common for every application. This makes it much easier to study and break them. iXGuard creates protection that is unique not only to your appication, but even to an individual build of your application. The next build will be obfuscated differently, the security checks will be at different places etc. This means that the bad actors cannot re-use their past experience or generic methods to break your application.
Hi,
I would ask for any experience with submitting of obfuscated IPA applications to Apple store, where Apple rejected such applications. What could be a reason? The obfuscation itself or wrong description, anything else?
I just would like to avoid any issues after obfuscating my IPAs.
App Store Review Guidelines are aimed to protect the users from dangerous undocumented features or malware. Sometimes obfuscation may prevent the Apple review team from doing a proper app review.
If this happens, you will have to prepare and submit the explanation + additional data (if required) to the Apple review team. We always help our customers in preparation of the response.
By following this process iXGuard customers were always able to get their products approved.
Almost every mobile application communicates with backend and to have a secure communication most often we rely on certificate pinning along with HTTPS.
If the cert validations are handled in Mobile SDK that is distributed to partners and app developers, handling the cert expiry is becoming challenging.
What would be the best practice for handling cert expiry scenarios with in Mobile SDK?
I was wondering if there if there is a way where I can enter some metrics about an my and get estimates on the pricing right away from the website?
Or say is there a sample app/code published by lovely folks at GuardSquare, that has some pricing estimates published around it?
It doesn’t have to be exact price, just and idea of some range will do as well. Right now, I have no clue about the range of pricing
Pardon me if I am wrong, but right now, it appears that I have to enter some personal details and wait for someone to get in touch to know the pricing.
Hi @Aleon_Q - we don’t have an automated pricing page to enter metrics, but there are few factors to be aware of in how we estimate. The more info you can provide in your request, the more realistic the estimate we can provide is.
Number of Apps you wish to protect
Number of Platforms for that app (either Android, iOS or both)
Scope / use case, which could be our Guards products (providing obfuscation and runtime protection) but could also optionally include ThreatCast for threat monitoring for your app
Downloads of your app (less popular apps are priced lower than more popular apps)
Generally speaking, the cost of protecting your app will be far less than the cost of an FTE that develops your app.
Rest assured, our sales professionals are easy to work with and responsive. So if you need an estimate for budgeting purposes, just be explicit and clear about that in your pricing request, they’ll get you what you need with just a few inputs.
Applying certificate pinning in combination with HTTPS is definitely a good approach to secure your communication when in transit against man-in-the-middle (MiTM) attacks, but will not necessarily protect your communication against man-at-the-end (MaTE) attacks, as an attacker using your app can easily understand the protocol and discover the sent along data once the TLS ends and all data fields sent by the server reside unencrypted in the app. We have a cool blog and video which explains this more in detail: https://www.guardsquare.com/blog/ios-ssl-certificate-pinning-bypassing
On your question about the best practice for handling certificate expires the standard answer would be to rotate your certificates before the expiry date, by temporarily allowing both the old and the new certificate to connect to your backend. But for a SDK this might be challenging indeed, as you don’t have full control on when the apps that use your SDK will release with your latest version. A good additional practice would be to sunset older versions of your SDK on a regular basis (and e.g. only actively support the last 3 releases), as such forcing your users to upgrade. Additional benefit is that this also forces MaTE attackers to restart their reversing efforts.
We routinely get questions like this when working with new / potential customers. On the surface, building code hardening and protections yourself may seem like a viable exercise and even an interesting engineering challenge. We see a few drawbacks with taking a DIY approach:
Upfront Cost/Effort
Taking a DIY approach is going to involve a meaningful effort by at least 1 skilled software engineer (FTE). Putting aside the question of robustness of the solution for a moment, a commercial solution like DexGuard and iXGuard is generally going to cost less than the cost of a skilled full-time engineer. That’s not even counting the opportunity cost of having your skilled engineers working on something that isn’t directly generating value for your end user / customer.
Ongoing Maintenance
Beyond the upfront cost there is also the concern about maintenance. Maintenance on a solution like this comes in two forms, maintaining compatibility with languages, frameworks and developer tools you use to build your mobile app, but also keeping up to date on the evolving security threats that exist. The ongoing maintenance will quickly become a significant burden on your teams backlog.
Robustness of Security Protections
The final consideration is around the robustness of the solution itself. Simple obfuscation may seem straight forward, but in our experiences working with over 700 customers a more sophisticated solution is required. In terms of protecting against static analysis, code hardening needs to not only be applied to the different aspects of your application, but it also needs to exhibit polymorphic behavior, to ensure that each release is creating sufficient randomness in approach as to not be undermined with repeated analysis. Protecting against dynamic analysis brings even more sophisticated and ever-changing requirements. New tools and techniques for dynamic analysis are always being released and Guardsquare employs a dedicated team of Security Researchers that are identifying these threats and ensuring our solution adapts to these new tools and techniques. Often a naive viewpoint will focus on one aspect of application protection, such as string encryption, but overlook some of the other threat models. Robust application protection relies on a defense-in-depth strategy, with layers of protection that work together to create a resilient and hardened solution.
In short, this question is a bit of history repeating itself. Cryptography used to be an aspect of security where engineers would look to invent custom encryption schemes. Conventional wisdom as our industry has matured has demonstrated the fallacy in this approach. Many people overlook just how fiendishly difficult it is to develop a robust security mechanism that can withstand the resourcefulness of attackers with motive. As a general rule, standing on the shoulder of giants, or trusted experts that dedicate their career and livelihood to building, maintaining and researching a solution for protecting your application is going to yield a much better outcome, and, likely be a better financial ROI for your business.
When you mention “build-time modifications”, I’m assuming you are referring to the repackaging of your app?
A direct way of checking this is by double-checking that the app hasn’t been resigned, by checking that the app’s certificate is still the original as used when releasing the app. Notice however that when using Google Play signing, your certificate at build time will be different than the one for the released app, you need to make sure to validate against the latter.
This method is a safe way of checking, and also applicable to SDKs, but is of course a very reactive detection: whenever this check triggers it means your app already has been resigned.
Therefor using a layered approach by applying multiple security features on top of each other is the best way to harden your app or SDK against both static and dynamic analysis. And as a result, protect your app from being repackaged.
Please let me know if this answered your question or you were referring to something completely else.
For AppSweep we definitely intend to cover iOS in the future, but right now, we’re focused on first making sure we deliver the best mobile application security testing tool for Android. We have a very high bar for the product, we want to make sure it is fast, that the UX is intuitive for developers and that the findings we produce are relevant and actionable. So for now, our roadmap is focused on perfecting the Android support and continually improving the product. As we get into next year, we’ll be stepping back and planning support for iOS, so stay tuned, we will get to it! If you or the team have any feedback on AppSweep, we’d love to hear it.
With Flutter, we have delivered a closed Beta for some of our customers, allowing them to protect the apps developed with Flutter. We started the beta in August initially supporting Android based apps and we just recently added iOS support. Based on that Beta feedback, we’re finalizing the plan for our GA release of Flutter support in the coming months.
Hope that is helpful for you, feel free to follow-up if you’ve got any more questions!
Coming to the second part of your question, basically OpenID is very similar to the OAuth flow, you’d only get an ID token generated at the end.
Your first line of defence should probably be the proper implementation of TLS combined with SSL pinning, to mitigate interception by a MiTM. But you should go beyond this line, as your clients will still remain vulnerable to MaTE attacks. This is where tools like iXGuard (for iOS) or DexGuard (for Android) come into the picture. By using their runtime detection capabilities (aka RASP) they can detect any integrity violations towards your app while it’s running, and make it crash randomly upon detection. That way you’re guaranteed that for instance no one can attach a debugger and read out the app’s memory to intercept any traffic after TLS ended (all data has been decrypted), or to identify the ID token.
Other RASP methods like the resigning check make sure that the app installed on the end-user’s device hasn’t been tampered with. That is why you really need to apply SSL pinning in combination with hardening your mobile app. We have a blog and related video explaining this: https://www.guardsquare.com/blog/ios-ssl-certificate-pinning-bypassing.
Your further lines of defence might include mechanisms like app attestation, to guarantee that only genuine clients can connect to the server, and you might even want to go one step further by considering obfuscation of your protocol.
Does this provide a satisfying answer to your question? Feel free to reach out with follow-up questions or comments.
