Response to AFNetworking security bug

Last week a number of publications broke the story that approximately 1,000+ applications were vulnerable to an SSL bug in AFNetworking. These articles contained several incorrect and misleading statements about the issue.

It is for this reason that we have published this article to respond to and clarify these inaccurate descriptions.

Background Information

For those who are not familiar with AFNetworking, we have prepared some detailed information related to this story:

AFNetworking is an open source third-party library that provides developers with convenient tools based on Apple's basic platform.

One of the components of AFNetworking is called AFSecurityPolicy, which is responsible for handling authentication according to the policy configured by the application. This includes the verification of the X.509 certificate (sent back by the server when connecting via HTTPS).

Certificate pinning is a security technique that improves on the standard TLS score by enforcing that the server sends a certificate along with the client's credentials. Starting with version 1.2.0, AFNetworking provides certificate pinning.

A man-in-the-middle attack is an attack on a service by inserting itself between a server and a client in such a way that both believe they are still communicating directly.

Such an attack proxies requests between the client and the server through an untrusted WiFi hotspot. Without the proper authentication response, an attacker can intercept the communication, which could expose user credentials or other sensitive information.

The AFNetworking documentation strongly recommends that applications communicate over HTTPS and use certificate/public key pinning to mitigate MitM attacks.

Timeline

Considering that some friends are still not familiar with this, we provide a timeline of the emergencies related to this:

On February 12, 2015, AFNetworking 2.5.1 was released. This version incorporates a patch to correct the validation of credentials when the security mechanism is set by SSLPinningMode to AFSSLPinningModeNone. By default, the certificate server will not perform legitimacy verification when the authority changes unless the client is configured to behave differently, such as enabling SSL pinning.

We first became aware of the impact of this changed behavior on March 12, 2015 from this GitHub Issue.

On March 26, 2015, Simone Bovi and Mauro Gentile of Minded Security Research published a blog detailing a potential MitM vulnerability in AFNetworking 2.5.1.

Also on March 26, 2015, AFNetworking 2.5.2 was released. This version reverts to the previous certificate validation mechanism and sets the security mechanism SSLPinningMode to AFSSLPinningModeNone if the mechanism validatesDomainName is set to YES.

On April 20, 2015, AFNetworking 2.5.3 was released. An additional change made in this version was to set validatesDomainName to YES for all mechanisms by default.

On April 21, 2015, an issue was opened on Github requesting additional documentation on AFNetworking's security features. We followed this suggestion and are actively reviewing our reference documentation.

Also on April 21, 2015, Nate Lawson from SourceDNA published a blog post claiming that a tool for identifying iOS apps in the App Store used AFNetworking 2.5.1. Several journalists, including Dan Goodin of Ars Technica, published articles citing the blog post and its author. However, none of the publications reached out to any AFNetworking maintainers for comment.

On April 24, 2015, SourceDNA followed up with a blog post stating that more applications were vulnerable. Dan Goodin of Ars Technica followed up with an article doing the same. Again, neither publication has reached out to any of the AFNetworking maintainers for comment.

AFNetworking user-manipulatable information

If you are an AFNetworking user, here are some actionable information you need to know:

If your application communicates over HTTPS but has not enabled SSL binding, it may be vulnerable to the reported man-in-the-middle attack

From the documentation of AFSecurityPolicy

Adding SSL certificate pinning helps protect your application from man-in-the-middle attacks or other security vulnerabilities. For applications that handle sensitive customer data or financial information, we strongly recommend enabling SSL pinning and using HTTPS connections for communication.

Any application that follows these recommendations should not be exposed to the above vulnerabilities at any time.

If your application has SSL binding enabled and communicates over HTTPS, it is not vulnerable to MitM attacks as reported.

A large number of applications using AFNetworking have followed the recommended steps to enable SSL certificates or public key pinning. These applications are not vulnerable to MitM attacks as reported.

If you are using an earlier version of AFNetworking, we strongly recommend that you upgrade to version 2.5.3

AFNetworking 2.5.1 and 2.5.2 are not suitable for production applications, especially because they cannot provide TLS scoring without additional configuration.

AFNetworking 2.5.3 defaults to secure behavior and supports domain name verification even when not using SSL binding.

If you are using NSURLConnection / NSURLSession instead of AFNetworking, you still need to review your authentication implementation.

Apple's built-in NSURLConnection/NSURLSession and security framework APIs provide a secure implementation of credential verification. However, like any API, an application is only secure when using these APIs.

Deciding whether to use AFNetworking does not guarantee that your app is immune to attacks such as MitM. It all depends on how the app uses the available APIs. Ultimately, it is up to these developers to test the robustness and network security of their apps in a production environment.

If you wish to report a vulnerability, please email [email protected]

We will respond as soon as possible.

If you want to contribute to making AFNetworking more responsive, please open an Issue or Pull Request

AFNetworking is open source, which means anyone has the opportunity to contribute and make it better. Issues or Pull Requests are fine.

Responsible Security Research and Press Statements

Security researchers play an important role in ensuring the security of user-facing software. If security researchers work together with developers and follow protocols for responsible vulnerability reporting, application vulnerabilities can be addressed quickly while minimizing the risk to existing users.

We do this, however, we are very disappointed that some security researchers and publishers have decided to take it upon themselves to report on AFNetworking. Information security is an important topic that everyone needs to know about, and both security researchers and journalists have the opportunity to educate readers about these realities. Unfortunately, most of the time, these reports attract traffic through fear rather than objective reality.

There is no clear way to prove how many applications are subject to this behavior; guessing the severity of security issues is based on calculating how much damage they would cause when they occur and the proportion of responses. Likewise, inferring vulnerable applications based on the small number of tools provided to merchants or their users.

The fact is that writing secure software has always been a difficult challenge. Doing so requires the collaboration of engineers across multiple disciplines. It is a nontrivial task, and that person had better be rational and responsible.

As software maintainers, there are many things we can do better, and we are actively taking steps to improve our organization and processes. We look forward to working closely with members of the information security community to responsibly identify and address any vulnerabilities from now on.

A statement on responsible open source maintenance

We would like to express our sincerest apologies to all developers who are using AFNetworking and to the iOS community.

As a maintainer of a well-known open source project, it is our responsibility to provide users with choices that meet high standards as dependencies for their applications. We failed to respond by releasing an updated version as quickly as possible. We failed to effectively communicate important security information to you. We are truly sorry for the above, and we are willing to take full responsibility.

In the coming weeks, we’ll be rolling out a refactor of AFNetworking and related projects to ensure consistent software quality and communication moving forward. For users this means more frequent releases and more transparency and feedback on the process of handling issues and pull requests. We’re excited to see what this means for the AFNetworking project and its users.