Skip to main content

Another "Fappening" on the Horizon?

So in case you aren't fully up-to-speed on useless hacker trivia, "The Fappening" (also sometimes referred to as "Celebgate") was a series of targeted end-user cyber attacks which occurred back in 2014 (which strangely feels like forever in tech years), that resulted in unauthorized access to the iCloud accounts of several prominent celebrity figures.  Following these breaches, photographs (for many including personal sexually explicit or nude photos) of the celebrities were then publicly released online.  Most evidence points to the attack vector being spear phishing email attacks which directed the victims to a fake icloud login site, and then collected the victim's credentials to subsequently access their real icloud accounts.

Migration to MFA

In response to these events, Apple has made iCloud one of the very few social web services that implements compulsory MFA ("Multi-Factor Authentication").  But while they might be ahead of the industry in that regard, they are still falling behind many of the other tech giants in its adoption of strong cryptographic MFA -- specifically FIDO U2F.

But not quite secure enough ¯\_(ツ)_/¯...

Because of their failure to support FIDO U2F, it is still possible to create a fake (evil twin) website and fully compromise access to user accounts -- just like the attacks that resulted in "The Fappening".  The only difference in the attack, is that the attacker would now need to (because of the MFA token expiry) replay the credentials acquired from the victim in real-time to the legitimate iCloud site...to then subsequently hijack the session and gain unauthorized access.

To demonstrate this risk, we were able to put together a fairly simple proof of concept by doing the following:

  1. Copied the recursive HTML source code for the iCloud login (to create the evil clone).
  2. Hosted the copied HTML on a Apache web server
  3. Configure basic handler using Python/Flask to receive the iCloud form POST request data and replay to the actual iCloud site using Selenium browser (would use headless for real attack, but to visually demonstrate, used a headed browser in POC)
  4. Modify the Action attribute of the HTML form, to have it POST to a Python Flask handler

Persistence too :)

Persistence (persistent bypass of 2FA) can be achieved by leveraging a post-authentication option in iCloud, in which the user is prompted (upon login and also at the time of log-off) to trust the browser that the session is running in.  Neither of these prompts require re-entry of the second factor.  This allows an attacker who has compromised an account via a Real-Time Replay Session Instantiation attack to be able to login at a later time in the future with only the compromised username and password (second factor no longer needed).



Responsible Disclosure Notice - These issues were responsibly reported to Apple (in February 2020), and have since been triaged and closed.

Comments

Popular posts from this blog

Bootstrap Fail - Persistent XSS via Opportunistic Domain Sniping

This is the story of how a failed Bootstrap implementation on a website allowed me to gain JavaScript code execution into thousands of user browsers. How I Found It? Before I get into the story, I'll quickly explain how I found this vulnerability in the first place.  I have started developing a new opportunistic approach for acquiring persistent XSS (Cross Site Scripting) on various web-services across the Internet.  This methodology consists of the following steps: Use custom web-crawler to spider web services across the Internet and scrape source code. It iterates through IP addresses and hits the web-root content for every IP address. It then identifies websites that are using externally hosted JavaScript. This is achieved for each server by… Reviewing the HTML source code for <script> tags with a source (src) value containing a full web-address (rather than a local path). An example would be <script type='text/javascript' src='https://domain.name/path/to/ho

Bypassing CAPTCHA with Visually-Impaired Robots

As many of you have probably noticed, we rely heavily on bot automation for a lot of the testing that we do at Sociosploit.  And occasionally, we run into sites that leverage CAPTCHA ("Completely Automated Public Turing Test To Tell Computers and Humans Apart") controls to prevent bot automation.   Even if you aren't familiar with the name, you've likely encountered these before. While there are some other vendors who develop CAPTCHAs, Google is currently the leader in CAPTCHA technology.  They currently support 2 products (reCAPTCHA v2 and v3).  As v3 natively only functions as a detective control, I focused my efforts more on identifying ways to possibly bypass reCAPTCHA v2 (which functions more as a preventative control). How reCAPTCHA v2 Works reCAPTCHA v2 starts with a simple checkbox, and evaluates the behavior of the user when clicking it.  While I haven't dissected the underlying operations, I assume this part of the test likely makes determination

Building Bots with Mechanize and Selenium

The Sociosploit team conducts much of its research into the exploitation of social media using custom built bots. On occasion, the team will use public APIs (Application Programming Interfaces), but more often than not, these do not provide the same level of exploitative capabilities that could be achieved through browser automation. So to achieve this end, the Sociosploit team primarily uses a combination of two different Python libraries for building web bots for research. Each of the libraries have their own advantages and disadvantages. These libraries include: Mechanize Pros: Very lightweight, portable, and requires minimal resources Easy to initially configure and install Cuts down on superfluous requests (due to absense of JavaScript) Cons: Does not handle JavaScript or client-side functionality Troubleshooting is done exclusively in text Selenium Pros: Operations are executed in browser, making JavaScript rendering and manipulation easy Visibility of browse