Subscribe to RSS
Follow me on Twitter
Join me on Facebook
The Wall Street Journal this week ran an excellent series on government surveillance tools in the digital age. One story looked at FinFisher, a remote spying Trojan that was marketed to the governments of Egypt, Germany and other nations to permit surreptitious PC and mobile phone surveillance by law enforcement officials. The piece noted that FinFisher’s creators advertised the ability to deploy the Trojan disguised as an update for Apple’s iTunes media player, and that Apple last month fixed the vulnerability that the Trojan leveraged.
Image: spiegel.de
But the WSJ series and other media coverage of the story have overlooked one small but crucial detail: A prominent security researcher warned Apple about this dangerous vulnerability in mid-2008, yet the company waited more than 1,200 days to fix the flaw.
The disclosure raises questions about whether and when Apple knew about the Trojan offering, and its timing in choosing to sew up the security hole in this ubiquitous software title: According to Apple, as of June 2011, there were approximately a quarter billion installations of iTunes worldwide.
Apple did not respond to requests for comment. An email sent Wednesday morning to its press team produced an auto-response stating that employees were already on leave for the Thanksgiving holiday in the United States.
I first wrote about this vulnerability for The Washington Post in July 2008, after interviewing Argentinian security researcher Francisco Amato about “Evilgrade,” a devious new penetration testing tool he had developed. The toolkit was designed to let anyone send out bogus automatic update alerts to users of software titles that don’t sign their updates. I described the threat from this toolkit in greater detail:
Why is this a big deal? Imagine that you’re at an airport lounge, waiting to board your flight, and you pop open your laptop to see if you can hop on an open wireless network. Bear in mind that there are plenty of tools available that let miscreants create fake wireless access points for the purposes of routing your connection through their computer. You connect to that fake network, thinking you can check your favorite team’s sports scores. A few seconds later, some application on your system says there’s a software update available. You approve the update.
You’re hosed.
Or maybe you don’t approve the update. But that may not matter, because in some cases, auto-update features embedded in certain software titles will go ahead and download the update at that point, and keep nagging you until you agree to install it at a later date.
Evilgrade leveraged a flaw in the updater mechanism for iTunes that could be exploited on Windows systems. Amato described the vulnerability:
“The iTunes program checks that the binary is signed by Apple but we can inject content into the description as it opens a browser, with a malicious binary so that the user thinks its from Apple,” Amato said of his attack tool.
Emails shared with KrebsOnSecurity show that Amato contacted Apple’s security team on July 11, 2008, to warn them that the iTunes update functionality could be abused to push out malicious software. According to Amato, Apple acknowledged receipt of the report shortly thereafter, but it did not contact him about his findings until Oct. 28, 2011, when it sent an email to confirm his name and title for the purposes of crediting him with reporting the flaw in its iTunes 10.5.1 patch release details. Interestingly, Apple chose to continue to ignore the vulnerability even after Amato shipped a significant feature upgrade to Evilgrade in Oct. 2010.
The length of time Apple took to patch this significant security flaw is notable. In May 2006, I undertook a longitudinal study of how long it took Apple to ship security updates for its products. In that analysis, I looked at two years’ worth of patches issued to fix serious security bugs in Apple’s Mac OS X operating system, as well as other Apple software applications like iTunes. I found that on average, 91 days elapsed between the date that a security researcher alerted Apple to an unpatched flaw and the date Apple shipped a patch to fix the problem. In that study, I examined patch times for four dozen flaws, and the lengthiest patch time in that period was 245 days.
