An embarrassing surveillance revelation for Germany, an important finding regarding blacklists, a vulnerability affecting 1500 iOS apps, a DDoS war story, and unintended consequences for legit CloudFlare customers are this week's Top 5 #infosec reads.
While reviewing Germany's information sharing agreement with the United States, German Parliament has learned that Germany's BND has provided the NSA with intelligence data associated with telephone numbers, IP addresses and email addresses when requested. Parliament is now looking to narrow the terms of access allowed by the NSA. As criticism mounts, important trade and other agreements are now in jeopardy. Angry reaction remains anchored at the US, but it will be interesting to see how long this theme persists as country after country has its own surveillance and information sharing practices exposed.
Blacklists are security data feeds that identify malicious domains or internet addresses. This study examines eighty-five (85) Internet blacklists for patterns in entries the lists have in common. A number of different comparison techniques were used during the analysis. An important finding for blacklist users - basically, everyone from individual users with antispam measures on devices to enterprise IT - was that "there is surprisingly little overlap between any two blacklists". The most important action for blacklist users? Don't rely on one blacklist, use several... or many!
A vulnerability in an open source library used by 1,500 iOS apps exposes users to SSL traffic interception. The AFNetworking library creates opportunities for attackers to intercept SSL connection requests of vulnerable iOS devices on shared, open (WiFI) networks, where they impersonate a secure site using a fraudulent SSL certificate. SourceDNA, who discovered the vulnerability, has developed a search tool to helpusers check if apps they use are vulnerable.
This article relates the defensive measures a SaaS-based supplier of web content management took during a thirty-nine hour distributed denial of service (DDoS) attack against one of its customers. The author describes the initial attack vector, attack traffic composition and origins, and the initial abatement tactics. The author next describes subsequent attack stages where the attackers changed tactics and how supplier chose to respond, and concludes with a summary and useful discussion on how to protect against a DDoS attack. These recommendations are similar to those I've mentioned in some of my DDoS protection articles (1, 2).
A UK ISP put blocking in place to prevent access to the Torrent sharing site, Pirate Bay. These included conventional domain and IP address blocking; however, the ISP did not consider the impact their blocking would have on legitimate customers who shared the same IP addresses as a Pirate Bay proxy. This incident provides a good opportunity to remind readers (and ISPs) about unintended consequences and how to choose wisely when blocking, seizing or taking down domains, sites, or content.