Skip to content

Instantly share code, notes, and snippets.

  • Star 29 You must be signed in to star a gist
  • Fork 4 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save AlamofireSoftwareFoundation/f784f18f949b95ab733a to your computer and use it in GitHub Desktop.
A response to recent concerns about security vulnerabilities in AFNetworking

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.

Background Information

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.

Timeline of Events

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 SSLPinningMode set to AFSSLPinningModeNone. 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 SSLPinningMode set to AFSSLPinningModeNone, if that policy set validatesDomainName to YES.

  • On 4/20/2015, AFNetworking 2.5.3 was released. This version made the additional change to set validatesDomainName to YES for 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.

Actionable Information for AFNetworking Users

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.


A Statement on Responsible Security Research and Journalism

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.


A Statement on Responsible Open Source Maintenance

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.

@orrc
Copy link

orrc commented Apr 28, 2015

Thanks for posting this, but I find this response quite odd, and with a strange understanding of what "responsible disclosure" means.

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.

I read the linked articles but didn't find anything glaringly obviously wrong or misleading. What were the misleading statements?
Why say allegedly? Was it not the case that 1000s of apps were (and possible are still) vulnerable?

On 3/12/2015 [one month after the 2.5.1 release], we first became aware of the impact of this change in behavior from this GitHub Issue.

It seems the first notification of the flawed behaviour came in issue #2560, which was made a few hours after the 2.5.1 release?

We are, however, disappointed by the manner in which some researchers and publications decided to conduct themselves in reporting on AFNetworking.

None of the articles were written before the vulnerability was publicly disclosed on the GitHub issue tracker. The articles linked here seemed to represent the facts — a lot of popular apps were vulnerable — and did not disclose any flaws not already public. Given that knowledge of the flaw was public, it's a positive thing that more people wrote about it.

If you have a concern about the behavior of client security, please open an Issue or Pull Request on GitHub.

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.

This is what I find the strangest. You seem to be upset by articles discussing this already-publicly-disclosed vulnerability (though again, I'm not sure which parts you find objectionable), yet you continue to ask people to report security issues publicly via GitHub.

Quoting the responsible disclosure article linked, "all stakeholders agree to allow a period of time for the vulnerability to be patched before publishing the details".
To enable responsible disclosure, this project needs a way of reporting security issues privately. On the master branch right now, the README only mentions Twitter as a way of getting in touch. Even with open source projects, having a security contact or private bug tracker for security issues isn't unheard of.

A Statement on Responsible Open Source Maintenance

To be fair, I didn't really have problems with this section ;)
And I'm glad that there at least was some sort of "post mortem" written, and that there is an ambition to improve communication and security in general. Good luck :)

@AlamofireSoftwareFoundation
Copy link
Author

@orrc Thanks for your response.

We've updated this document to include our security@alamofire.org email, which should be used for any security disclosures from now on.

@michelzanini
Copy link

Hi,

Can you tell me if 1.x branch is affected by this issue?
If yes, do you guys plan to release a patch for the older versions?

Thanks.

Copy link

ghost commented May 1, 2015

hey all,

great statement, you're all working above and beyond here, and i just wanted to acknowledge that and say thank you.

i may be misunderstanding something, but there's two instances in the statement where you wrote about the case where AFSecurityPolicy's "SSLPinningMode set to SSLPinningMode", which confuses me.
¿did y'all mean when the SSLPinningMode is set to AFSSLPinningModeNone?

@bplattenburg
Copy link

@michelzanini from what I understand, AFNetworing 1.x is not affected as this issue was introduced in 2.5.1.

@AlamofireSoftwareFoundation
Copy link
Author

@michelzanini AFNetworking 1.x is not affected by this issue.

@CalQL8ed-K-OS Yes—we meant AFSSLPinningModeNone. The statement has been updated accordingly.

@akgood
Copy link

akgood commented May 8, 2015

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.

Wouldn't it be more accurate to say that all versions of AFNetworking before 2.5.3 include default behaviour unsuitable for production applications? This would at least be true for any version in which domain-name validation was not enabled by default (e.g. in which validatesDomainName was set to NO by default).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment