Just another security blog - by Jon Bottarini

Tag: apple (page 1 of 1)

Don’t Reply: A Clever Phishing Method In Apple’s Mail App

About four or five years ago, friend and fellow bug bounty hunter Sam Curry asked if I had “ever thought about what was possible to load inside an <img> tag, besides an image“. What a peculiar question. I didn’t really understand what he was asking, and I assume Sam got bored of me guessing the wrong answers, so he sent a simple payload that looked like this:

<img src=https://www.jonbottarini.com/pocs/restricted.php></img>

At the surface, this appears to be a normal HTML <img> element, until you look a bit closer and realize that the src= parameter is not pointing to an image at all, but rather a webpage ending in .php. If you navigate to this page directly, you’ll be prompted with something that looks like this:

What you’re looking at is an implementation of WWW-Authenticate. In 2017, if you were to embed this <img> payload in an HTML editor on a 3rd party website, nearly anyone who viewed the page with the rendered <img> tag would see an authentication prompt, asking you to sign in to my site. It looked like this:

A prompt asking users on an AirBnb community website to login to my website

Simply incredible. I don’t think Sam realized at the time what he was sitting on in the world of bug bounty – this was essentially a lazy way to phish users on forums, help centers, etc – anywhere that you could enter an image tag. It was unique because in situations where you were allowed to insert an <img> tag but not able to pop an XSS payload (due to CSP or other protections in place), rarely did an application prevent you from loading an external “image” that was really my malicious WWW-Authenticate page. Remember: this was 2017, a lot has changed since then.

After sharing this revelation with Sam, we reported instances of sites vulnerable this issue to a few bug bounty programs, and it was largely hit or miss. Some programs (Yahoo!, if I remember correctly, back before they rebranded their program to Oath, and then to Verizon Media¹) paid $1,000 for each instance of the issue – other programs didn’t pay anything at all, and stated that it was a browser issue. This is understandable – in a way, this issue could be fixed by the browser. The Chrome team decided to fix this outright back in 2013 by preventing cross-origin authentication prompts to image resources. Sam petitioned Mozilla to do the same in 2017, which they (begrudgingly) implemented the change to disallow loading external WWW-Authenticate prompts via image somewhere around Firefox Version 57. Apple never responded to us when we reached out to inform them that Safari was the last (major) browser to suffer from this.

The Problem in Apple Mail

I got bored with the 50/50 odds of getting a bounty through the web programs we were reporting to. A few months passed and I had an epiphany – in the form of a spam email. In short, an email evaded my spam filter because the email had no content besides a photo. Just a big, massive JPG image. This led to an idea – what if I sent a “photo” that was behind a WWW-Authenticate response header in an email? What type of prompt would the recipient see? Would they see any anything at all?

It doesn’t work. Simply put, I am not sure why it doesn’t work when the recipient receives the email – but the prompt does appear when replying to the email. When you reply to an email with that <img> payload I mentioned above, the user is presented with this prompt, which asks them to enter their name and password “to view this page”:

This prompt poses a two-fold problem. This first being that users are already familiar with entering their username and password in ambiguous and confusing prompts on Apple devices – Apple keychain being a major offender.

But this is not a keychain prompt – when a user enters their username and password in this prompt, their credentials are sent directly to my server.

The second problem is that it’s possible to customize the message displayed underneath the URL – in the example above, I put “You need to enter your Apple Mail password again!”. This is made possible through the realm directive:


A string describing a protected area. A realm allows a server to partition up the areas it protects (if supported by a scheme that allows such partitioning), and informs users about which particular username/password are required. If no realm is specified, clients often display a formatted hostname instead.

Mozilla developer portal

All in all – you get a very clever Apple Mail phishing method. Now – a savvy person would realize that “jonbottarini.com” has nothing to do with Apple, and would probably be skeptical of entering a username and password in the prompt – but official-sounding Apple domain names are cheap!

This issue affected versions of Apple Mail from macOS High Sierra 10.13 to macOS Big Sur 11.2. Yes, you read that right – it took multiple operating systems and four years to fix this issue completely. But before you get out the pitchforks – it’s not entirely Apple’s fault it took so long – there was a two year period where both Apple and myself thought the issue was fixed – when it really wasn’t.


  • Sometime mid to late 2017 (email comms are a bit messy here) – reported issue to Apple
  • Oct 2017 – Apple can’t reproduce the issue, I reply with additional info
  • Nov 2017 – More back and forth, explaining to Apple that the issue only occurs when replying/forwarding the email
  • Sometime in 2018 – Apple states this issue is not eligible for a CVE 🙁
  • July 2018 – Apple states they fixed the issue in macOS High Sierra 10.13 and macOS High Sierra 10.13.2
  • May 2020 – I start to write this blog post, but when I test the old proof of concepts, I notice that the payload is not fully fixed on macOS Catalina 10.15.4 and I am still getting the prompt. Replied back to Apple with proof that the issue still exists.
  • October 2020 – Apple states they have fixed the issue again – I find a bypass pretty quickly (by sending a email with an embedded image loaded inside a pre-made feature in Apple mail called “email templates”). Apple continues work on the remediation.
  • April 2021 – I follow up asking for a status update. Apple states the issue has been resolved in macOS Big Sur 11.2
  • August 2021 – Apple sends me an email out of the blue stating that the issue is eligible for a $5,000 bounty (w0w!)
  • December 2021 – Bounty paid + this writeup is disclosed.

¹ – At time of writing, Verizon Media has rebranded back to Yahoo. We have come full circle.

Very special thanks to Sam Curry (@samwcyo) and Tanner (@itscachemoney) for reviewing a draft of this post.

Follow me on Twitter to stay up to date with my latest bugs + bug bounty finds.

Bypassing Apple’s iOS 10 Restrictions Settings – Twice

By default, Apple has a feature that allows all of their iOS devices to be assigned restrictions, so that employees and mostly children cannot access naughty websites and other types of less-desirable content. You can enable these settings by visiting Settings > General > Restrictions on your iPhone or iPad.

Around the beginning of every year I try to break Apple’s restrictions settings for websites. It’s a pretty nerdy thing to do and its not really classified as a “vulnerability” – but it’s a fun challenge and leads to some pretty interesting bugs, so I wanted to talk about a few of them here:

When I test the restriction settings, I turn restrictions on, and then I change the website settings to allow Safari, but only the default specific websites (see screenshot below).

The first time I found out how to bypass the restrictions, I did it on accident. I noticed that there were certain pages I had open previously in Safari that, when restrictions were turned on, I was still able to reload even though the domains were not on the list of approved websites. I realized that all these pages I had open had one thing in common: they were all displaying PDF’s. So now, by simply appending .pdf at the end of the Safari URL, it was possible to visit any website. An example is below:

Restricted URL: www.jonbottarini.com (left image)

Allowed URL: www.jonbottarini.com/anything.pdf (right image)

That one was pretty interesting. I reported it to Apple through their bug tracker and it was marked as a duplicate  – looks like someone else had found it before me. I tried again to see if it was possible through another method, and after a few hours I discovered another way:

(The following is my assumptions as to how the website restrictions work behind the scenes) When Apple checks a URL, they check the structure of the URL to see if it matches the list of whitelisted domains. What doesn’t happen is an additional check to ensure that the URL actually ends… or if it contains subdomains that match a whitelisted domain. This may be hard to explain so I made a photo to demonstrate:

See what’s happening here? Only the URL up to “.com” is checked against the whitelist. The restrictions settings do not check to see if a URL contains subdomains… so I’m able to trick the filter to allowing a domain such as “www.apple.com123.com” to be let through. The actual domain name in this case is com123.com – which is definitely not on my approved list of domains.

Restricted URL: www.com123.com (left image)

Allowed URL (but shouldn’t be!): www.apple.com.com123.com (right image)

I also reported this to Apple about 7 months ago and it still isn’t fixed. I asked them for permission to share this article.

This is just an interesting bug that slipped through the cracks, I assume they will have a fix out eventually for the bugs. Still haven’t made it in the Security HoF for Apple yet, but it’s definitely a goal of mine for the year.

I have other bugs and vulnerabilities that are cooler and more intense than this one coming soon, so check back later and I’ll share them with you. Additionally, you can follow me on Twitter to stay up to date with my bugs and what I’m doing, if you wish.