HTTPS Bug in AFNetworking Affects 25,000 iOS Apps
The new vulnerability is the result of a bug in AFNetworking that fails to ensure the domain name contained in the certificate matches the domain name of the HTTPS server it protects. As a result, anyone with a man-in-the-middle position—say, an attacker on an unsecured Wi-Fi hotspot, a rogue employee inside an Internet service or virtual private network provider, or a state-sponsored hacker sniffing the Internet backbone—can present their own CA-issued certificate, then read or tamper with the protected communications.
It wasn’t a black-box bug, but rather the library has now been made more idiot-proof and “safer out of the box”. The
validatesDomainNameproperty was always configurable by developers using the library, and those that failed to be aware of it could’ve been bitten in the situation where the setting was defaulting to “NO” under non-pinning connections. It now defaults to “YES” in all cases, but a developer could’ve chosen to set that explicitly in their own code and been okay.
There is no valid production scenario for turning off domain validation. It literally disables SSL to any attacker in the middle (e.g. shared WiFi). The fact that AFNetworking has now exposed user data two different ways via APIs that are only useful for testing shows that the defaults should be secure, and test mode should be something that is off by default and prints huge warnings if SSL is ever used in test mode.
Update (2015-04-28): Alamofire Software Foundation:
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.
orrc:
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.
[…]
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.
