Last week, a number of publications ran a story about 1,000's of apps allegedly being vulnerable due to an SSL bug in AFNetworking. These articles contain a number of inaccurate and misleading statements on this matter.
We are publishing this response to clarify and correct these statements.
For those not familiar with AFNetworking, here are some relevant details about the library for this story:
- AFNetworking is an open source, third-party library that provides convenience functionality on top of Apple's built-in frameworks.
- One component of AFNetworking is
AFSecurityPolicy, which handles authentication challenges according to a policy configured by the application. This includes the evaluation of X.509 certificates which servers send back when connecting over HTTPS. - Certificate pinning is a security technique that improves on normal TLS evaluation by enforcing that a certificate sent by the server explicitly match the credentials included in the client. AFNetworking has provided certificate pinning since version 1.2.0.
- A man-in-the-middle (MitM) attack is an attack where a service inserts itself between the client and the server in such a way that both think that they're still communicating directly with one another.
- One such attack would involve an untrusted WiFi access point proxying requests between the client and server. Without properly authenticating the response, an attacker could intercept communications in such a way that could expose user credentials or other sensitive information.
- AFNetworking documentation strongly recommends applications communicate over HTTPS and use certificate / public key pinning in order to mitigate MitM attacks. The included examples follow these recommendations, demonstrating certificate pinning in an application.
With that in mind, here is a timeline of events related to this incident:
-
On 2/12/2015, AFNetworking 2.5.1 was released. This incorporated a patch that changed the way certificates were validated for security policies with
SSLPinningModeset toAFSSLPinningModeNone. By default, server certificates would not be validated during authentication challenges, unless the client configured different behavior, such enabling SSL pinning. -
On 3/12/2015, we first became aware of the impact of this change in behavior from this GitHub Issue.
-
On 3/26/2015, Simone Bovi and Mauro Gentile of Minded Security Research published a blog post detailing a potential MitM vulnerability in AFNetworking 2.5.1.
-
Also on 3/26/2015, AFNetworking 2.5.2 was released. This version reverted to the previous credential evaluation behavior for security policies with
SSLPinningModeset toAFSSLPinningModeNone, if that policy setvalidatesDomainNametoYES. -
On 4/20/2015, AFNetworking 2.5.3 was released. This version made the additional change to set
validatesDomainNametoYESfor all policies by default. -
On 4/21/2015, an Issue was opened on GitHub requesting improved documentation around Security features of AFNetworking. We are actively working to follow this recommendation with a comprehensive overhaul of our reference material.
-
Also on 4/20/2015, a Nate Lawson of SourceDNA published a blog post publicizing a tool that identified iOS applications in the app store that were using AFNetworking 2.5.1. A number of journalists, including Dan Goodin of Ars Technica, published an article citing this blog post and its author. None of these publications reached out to any AFNetworking maintainers for comment.
-
On 4/24/2015, SourceDNA released a follow-up blog post alleging that a greater number of apps were now vulnerable. Dan Goodin of Ars Technica similarly published a follow-up article to the same effect. Again, no publications reached out to any AFNetworking maintainers for comment.
If you are an AFNetworking user, here is the actionable information you need to know:
If your app communicates over HTTPS but does not enable SSL pinning, it may be vulnerable to the reported MitM attacks
From the documentation for AFSecurityPolicy:
Adding pinned SSL certificates to your app helps prevent man-in-the-middle attacks and other vulnerabilities. Applications dealing with sensitive customer data or financial information are strongly encouraged to route all communication over an HTTPS connection with SSL pinning configured and enabled.
Any applications following these recommendations should not have been exposed to the aforementioned vulnerabilities at any point.
If your app communicates over HTTPS and enables SSL pinning, it is not vulnerable to the reported MitM attacks
A significant proportion of apps using AFNetworking took the recommended step of enabling SSL certificate or public key pinning. Those applications are not vulnerable to the reported MitM attacks.
If you are using a previous release of AFNetworking, we strongly recommend upgrading to version 2.5.3
AFNetworking 2.5.1 and 2.5.2 include default behavior that are unsuitable for production applications—specifically, they do not provide necessary TLS evaluation without additional configuration.
AFNetworking 2.5.3 defaults to safer behavior, enabling domain name validation even when not using SSL pinning.
If you are using NSURLConnection / NSURLSession instead of AFNetworking, you should still audit your implementation of authentication challenges
Apple's built-in NSURLConnection / NSURLSession and Security framework APIs provide secure implementations of credential validation. However, like any API, an application is only as safe as its usage of those APIs.
The decision to use or not use AFNetworking alone cannot guarantee that your application is resilient against attacks like MitM. It all depends on how that application uses the available APIs. It is ultimately the responsibility of the developer to test their application in production environments for robust and secure networking.
If you want to disclose a vulnerability, please email security@alamofire.org
We will respond as quickly as possible to come to a resolution.
If you want to contribute to make AFNetworking better, please open an Issue or Pull Request on GitHub.
AFNetworking is open source, which means that everyone has the opportunity to contribute to make it better. Issues and Pull Requests are welcome.
Security researchers play a central role in making software secure for end users. Working together, security researchers and developers can work to quickly address vulnerabilities while minimizing the risk to existing users by following a defined protocol for responsible disclosure.
We are, however, disappointed by the manner in which some researchers and publications decided to conduct themselves in reporting on AFNetworking. Information security has never been a more important topic for everyone to understand, and both security researchers and journalists have a unique opportunity to inform readers about these realities. It's unfortunate that, all too often, such reports are written to drive traffic through fear rather than through objective reporting.
No clear methodology has yet been presented to justify claims about how many apps are affected by this behavior; conjecturing about the severity of security matters works to undermine accurate and proportional response to issue when they arise. Likewise, making claims of vulnerability based on conjecture provides very little utility to businesses or their customers.
The fact is, writing secure software is, and always has been, a difficult challenge. Doing so requires the cooperation of engineers across a multitude of disciplines. It is a vitally important task, and one that would best be served by rational, responsible actors.
There are a number of things we, as software maintainers, can do better, and are actively taking steps to improve our organization and processes. We look forward to working closely with members of the infosec community to responsibly find and address any vulnerabilities from now on.
We offer our sincere apologies to developers using AFNetworking and the iOS developer community as a whole.
As maintainers of a prominent open source project, it is our responsibility to provide software that meets the high standards of the applications choosing to incorporate it as a dependency. We failed to respond with updated releases as soon as we should have. We failed to effectively communicate critical security information to you. On all of these counts, we are truly sorry and accept full responsibility.
In the coming weeks, we will be rolling out a restructuring of AFNetworking and its related projects to ensure software quality and consistent communications going forward. What this means for users are more frequent releases and more transparency and feedback around the process of handling issues and pull requests. We are excited about what this will mean for the AFNetworking project and its users.
@michelzanini from what I understand, AFNetworing 1.x is not affected as this issue was introduced in 2.5.1.