URL Confirmations in Preview

Michael, I would find such as trampoline page usefu, too. Do you use PHP, and if so, would you share the code for this, please?

It certainly seems annoying, but I’m assuming Apple didn’t spend money on implementing this just to be annoying. Regular people are subject to a dizzying array of phishing and related attacks on a daily basis, and come to very real harms because of it. It’s a vastly different threat landscape to 30 years ago, so I don’t think ‘I don’t like it’ and ‘it was good enough in the 90s’ are particularly great arguments against change here. It comes across as someone with great technical literacy assuming that everyone is the same as them.

@Thomas I’m using Python. It’s barely any code, but I’m happy to share if you e-mail me. The other half was in adjusting the links when compiling my help for PDF or Apple Help (but not for Web).

@Alex It is not at all clear to me that the alert actually protects against any of that. It uses the standard system font, which would make it difficult to detect phishing even when viewing the URL. I’m not saying there are no threats; I’m saying this is security theater, of little use to the less technical users, anyway.

And if that’s the argument, should there be the an alert when clicking links in Messages or Mail, too? Aren’t those more likely sources of attacks?

I think the proper place to handle this stuff is the browser. Of course, what Apple did there is hide most of the URL in the address bar, which makes it harder to detect such attacks.

I agree that the treatment in Preview feels inconsistent with Messages and Mail. On the other hand, Safari’s default behavior is to auto-open downloaded PDFs, correct? Perhaps part of the issue is that users have been trained to not click suspicious links they receive in Messages and Mail, but if a PDF that’s trying to spoof the system UI pops up they may not realize what’s happening because it lacks the equivalent of context of those other apps. (In other words, when users aren’t reading a message or email their defenses are down.)

> I think the proper place to handle this stuff is the browser.

How would this work, though? Ideally you want to avoid hitting the attacker’s server at all.

@Ghost Well, we had the green domain names, which didn’t really work out. The browser already checks a list of unsafe URLs and won’t auto-fill login information if the domain doesn’t match.

I think this is a good thing. Text recognition in Preview is not perfect, so it's possible that the URL think you are clicking on is malformed or pointing to an entirely different domain - a malicious actor could in theory craft an image to intentionally misdirect the user. A confirmation alert at least mitigates this attack vector.

@nhojb

1) How is this any different from hyperlinks on the web, which can obscure themselves in various ways?

2) If you've downloaded a malicious pdf, then you have *already* visited a malicious URL.

3) Preview has the same behavior even with pdfs that have no quarantine extended attribute. Indeed, it happens with pdfs that I created myself, for example in Pages app!

@Jeff

A malicious (or more accurately, deceptive) PDF can be hosted on an otherwise legitimate website and used to trick a user into visiting an attacker controlled domain. I’m still not really sure how useful this is for an attacker, outside of my theory that perhaps PDFs are a more effective vector for getting users to click on a link than, say, emails.

"an otherwise legitimate website" I'm not sure what this is supposed to mean. But in any case, it doesn't respond to my first question: "How is this any different from hyperlinks on the web, which can obscure themselves in various ways?" It seems that any site capable of hosting a malicious/deceptive PDF containing malicious/deceptive links could just as easily host the malicious/deceptive links themselves. And it doesn't respond to my 3rd point either, which is that Preview doesn't care whether you downloaded the pdf.

Moreover, I haven't heard of any pdf-based attacks. I follow security researchers fairly closely, and they haven't mentioned it. Indeed, Apple itself hasn't mentioned it in any of their security update release notes. And if it's a real problem, currently exploited in the wild, then why leave Monterey and Big Sur vulnerable?

It means any site that is not controlled by the attacker, does not allow overriding the display/formatting of URLs, but does allow uploading or sending of PDFs.

For example, attacker sends the message: “I’m sending you as an encrypted PDF, password is .” The PDF spoofs the password entry field as a PDF form, and has a “Submit”/“Unlock” button that opens an attacker controlled server. Attacker can use this to attempt sending a binary payload, spoofing a login page, exploiting a browser vulnerability, or even to simply unmask the user’s IP address.

This interaction isn’t even that contrived if you’re, say, working with an attorney, where they would expect you to upload a password-protected PDF to a website like Clio, but would not expect you to send them attachments or links via email.

> And if it's a real problem, currently exploited in the wild, then why leave Monterey and Big Sur vulnerable?

They leave old macOS versions out to dry all the time.

Attacker’s message should read “I’m sending you (whatever document) as an encrypted PDF, password is (password).” I used angled brackets and they were filtered out.