Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

1/29/2019
05:40 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

FaceTime Bug an AppSec Fail

Apple has shut off Group FaceTime while it prepares a fix for a newly found security flaw found by a 14-year-old gamer.

The glaring security flaw in FaceTime that has rocked the Apple community since it went viral late yesterday was actually was first found on January 19 by a 14-year-old who stumbled upon it while setting up a group chat with friends playing Fortnite. 

Apple disabled the Group FaceTime service yesterday, January 28, at 10:16 p.m. PDT, after word of the bug and a video of how to abuse it spread like wildfire over social media and caught the attention of security experts. And the company — which late yesterday said it will issue a patch for the bug this week — was a little late to the party: Michele Thompson, the mother of the teenage gamer, Grant, who found the flaw, told media that she attempted to contact Apple about the bug but got nowhere. She even tweeted about it on January 20 after not getting a response from Apple Support:

My teen found a major security flaw in Apple's new iOS. He can listen in to your iPhone/iPad without your approval. I have video. Submitted bug report to @AppleSupport...waiting to hear back to provide details. Scary stuff! #apple #bugreport @foxnews

The vulnerability allows a Group FaceTime caller to access your audio and video even if you don't pick up the call. Grant found that after trying to call one friend via FaceTime who didn't pick up and then adding a second friend to the call, he was able to hear the microphone of his first friend, even though the boy hadn't picked up. He could hear the ringing sound on the first friend's phone, he told NBC News.

Aside from an obvious failure of communication in Apple's process for vulnerability reporting, the painfully simple bug also exposes a likely collapse in the final vetting phase of the vendor's software development life cycle. With a company like Apple, known for advanced privacy and security features in its software and hardware architecture, the bug demonstrates how even the best development programs can miss security problems.

Chris Eng, vice president of research at Veracode, says the Group FaceTime vulnerability appears to be a design flaw that should have been detected during Apple's threat modeling process, a step-by-step exercise where developers explore potential use and abuse cases in an application. The development team walks through a final flight-check of sorts, exploring usage possibilities such as: What if the user adds another contact's number to the Group call? What if the user adds his own number?

"It seems like an obvious scenario you'd expect them to go through in workflow in handling [potential] abuse, or they didn't account for that particular case," Eng says. "It seems straightforward enough that a light whiteboard review of this thing" even would have caught it, he says.

This design flaw isn't a deep architectural issue in Group FaceTime, Eng notes, but, rather, the result of a flawed new feature that wasn't fully vetted for problems like this one. "I wonder if they were under time pressure, or they wanted to squeeze it into a release," he says.

Apple had not yet responded as of this posting to a request for details on the flaw and what happened with the Thompsons' reporting of it.

The good news about the bug, according to Eng, is that it appears to have a limited impact on FaceTime users. "It's a bad bug, no question, but it's not like you have an unlimited spying tool," he says, given that the early tests show it provided a short window of audio and video access.

"Hopefully, they'll [Apple] go back and do a root-cause analysis" to determine where the threat modeling fell apart for the flawed feature, he says.

Apple's development process for the FaceTime code appears to have missed the mark, notes Chris Pierson, CEO of security firm BlackCloak. "Errors and problems in coding and implementation happen all the time in the software process. That is why static and dynamic security testing is critical as well as a robust Q&A [quality and assurance] process," he says.

Pierson echoes Eng's theory that there was likely an oversight in testing out any issues with the app before launching it. "In this case, it looks like the Q&A process failed to identify this risk in its preliminary or regression testing models. It could be a failure in the process itself, or a failure in imagination to test something like these steps. In any case, an enormous oversight," Pierson says.

The Fix
While architectural design flaws in software are difficult to remedy, this type of feature flaw is not. "I don't think this hard to fix," Eng notes. Apple may have to remove the ability to add a user's phone number to the Group FaceTime call, for example, he says.

"This doesn't [appear to] affect the whole FaceTime architecture and product. I think it's one use case where they didn't think about how it was going to handle this particular group-calling feature," Eng says.

It's a chilling reminder that even major companies with mature secure development programs can miss things. "Even though Apple has gone through great strides to protect their users' information, this latest bug is yet another reinforcement that privacy continues to remain a major concern regardless of your company's size or security and privacy investments," notes George Gerchow, CSO at SumoLogic. "It's also another reminder that nobody's data is 100% safe and that it's all of our responsibility to be more diligent in protecting the privacy of our customers' sensitive information against future vulnerabilities."

Related Content:

 

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
BradleyRoss
50%
50%
BradleyRoss,
User Rank: Moderator
2/4/2019 | 3:48:40 PM
Reporting security problems to Apple
The address for sending information on security problems at Apple is apparently [email protected]  However, I also sent them a message about a probable fix for a problem and received no response.  After a few attempts at escalation of the issue, I finally received a message that they couldn't talk about such issues.  However, I found the language in the communications from the product security group disturbing in that it appeared to be the type of double-talk encountered from people who didn't want to deal with the problem or admit that the problem existed.  I appreciate the need for deception in product security, but it seemed that they lacked sufficient skill and knowledge to successfully deceive.

I find the idea this is a problem in testing under AppSec simplistic and dangerous.  It is simplistic because problems like this usually represent errors by multiple persons in the software development life cycle, frequently over a period of years.  It is dangerous because testing is of limited use in finding problems unless the software is designed in a way that supports testing.

Designing the software to support testing first requires a design with sufficient documentation to design tests.  A problem of this type does not indicate a problem in testing, but a problem with the design methodology not providing enough information to develop the tests.
BROWN1808
100%
0%
BROWN1808,
User Rank: Apprentice
1/31/2019 | 11:43:12 AM
Apple Face Time Bug
The other issue that is very frustrating is reaching someone actually involved with the company to report this or any issue to, not a machine or a group of supporters helping Apple out by solving their problems for them. That aspect should have been commented on more thoroughly.
7 Truths About BEC Scams
Ericka Chickowski, Contributing Writer,  6/13/2019
DNS Firewalls Could Prevent Billions in Losses to Cybercrime
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/13/2019
Cognitive Bias Can Hamper Security Decisions
Kelly Sheridan, Staff Editor, Dark Reading,  6/10/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-12855
PUBLISHED: 2019-06-16
In words.protocols.jabber.xmlstream in Twisted through 19.2.1, XMPP support did not verify certificates when used with TLS, allowing an attacker to MITM connections.
CVE-2013-7472
PUBLISHED: 2019-06-15
The "Count per Day" plugin before 3.2.6 for WordPress allows XSS via the wp-admin/?page=cpd_metaboxes daytoshow parameter.
CVE-2019-12839
PUBLISHED: 2019-06-15
In OrangeHRM 4.3.1 and before, there is an input validation error within admin/listMailConfiguration (txtSendmailPath parameter) that allows authenticated attackers to achieve arbitrary command execution.
CVE-2019-12840
PUBLISHED: 2019-06-15
In Webmin through 1.910, any user authorized to the "Package Updates" module can execute arbitrary commands with root privileges via the data parameter to update.cgi.
CVE-2019-12835
PUBLISHED: 2019-06-15
formats/xml.cpp in Leanify 0.4.3 allows for a controlled out-of-bounds write in xml_memory_writer::write via characters that require escaping.