In a recent blog post, Felix Krause revealed a method for phishing Apple ID passwords on iOS that would be quite indistinguishable from a real iOS password request. This got us thinking about the ramifications—how else could this tactic be used in the Apple ecosystem, and what kind of damage could it do?
Image courtesy of krausefx.com
In the case of Krause’s iOS phishing scam, by using simple code any app could easily simulate a standard iOS password request, and most users wouldn’t think anything was amiss. Looking at Krause’s example above, I have to admit that this is something I might fall victim to, although I might wonder why the request was showing up within the context of a third-party app.
However, I don’t see this particular phish as a huge risk. iOS apps can only be downloaded through the App Store, and although I would never say that it’s impossible to get a phishing app into the App Store, it certainly would not be an easy thing to do. Not only would the hacker have to sneak this code past the review, they’d also have to create a decoy app that would be compelling enough to download—something that is increasingly difficult even for legitimate developers in the crowded iOS App Store. I view this as possible, but unlikely.
Of course, there are many other cases where the App Store screening process wouldn’t come into play, and that could be equally convincing, if not more so.
For example, consider macOS instead of iOS. Unlike on iOS, Mac users can download apps from anywhere, and frequently do. That’s how Mac users end up infected with things like malware, adware, and unethical junk software. Thus, there’s no review process a hacker would have to submit to.
Suppose you’re using your Mac, and suddenly the Mail app opens and shows a password request because of a failure with your iCloud account. It might look something like the image below. What would you do?
Would you enter your iCloud account password there? After all, it will reliably cite a correct iCloud account address. If you did enter your password in this case, sorry to tell you, you’d be pwned.
Okay, maybe that’s not the most convincing password request if you’re a Mac expert and know what these things are supposed to look like. (I can hear the criticisms now.) However, there are a couple important things to keep in mind.
First, this would trick a LOT of people. Sure, maybe not Mac aficionados, but most people are not, and shouldn’t have to be, experts in what every single macOS dialog looks like.
Second, this was the result of a four-line AppleScript I threw together in all of five minutes, with three of those lines involved in getting the email address associated with the user’s iCloud account. It would be entirely possible to make this far more convincing. Even just using AppleScript, it would be possible to use different techniques, and at least one that I can think of, for which I’ve seen a proof-of-concept, would be highly convincing.
Worse, it would be easy to mimic a real macOS authentication dialog, pixel-for-pixel, without too much effort in an app compiled in Xcode.
In fact, a similar event happened earlier this year, when Handbrake was hacked to install the Proton malware. The malicious copy of Handbrake ended up requesting the login password in such a way that even experts fell for it, such as a developer for the well-respected Panic, Inc.
We have become accustomed to such password requests as a part of our daily life, so when we see them, we tend to just enter the password without thinking about it. After all, Macs don’t get malware, right? Fortunately for Mac users, the actual incidences of this kind of harmful malware have been few, but that works in the hackers’ favor, since we’ve become inured to these requests and don’t treat them with the suspicion that they deserve.
So, what can be done about this kind of thing? Unfortunately, there is no one thing that Apple could do to solve this problem. An app will always be able to display a pixel-perfect simulation of any official macOS or iOS password request.
Worse, even a web developer could do the same, by combining screenshots from the target system and a web form. The code could detect the system and display an appropriate “window” for macOS, iOS, Windows, or Android. Slip something like that in as an overlay on top of a hacked legitimate site and you could fool a lot of folks.
Although Apple could direct the user at all times to a known, good location to enter passwords, that’s not always reasonable. Consider, for example, the horrible user experience Apple has foisted on Mac users with the new User-Approved Kernel Extension Loading process in macOS High Sierra. Although this is not the same as a password request, it’s a good example of how forcing the user to a location for security reasons could go horribly wrong, resulting in a bad user experience that may not actually be significantly more secure.
Instead of seeking fixes for something that can’t be fixed, we need to focus on changing our own behaviors. Every password request should always be viewed with suspicion, no matter the source. If Mail pops open and a window appears asking for a password, that doesn’t mean it’s actually Mail doing the asking.
Treating these password requests with suspicion means, in some cases, canceling and entering the password in a known, good location. For example, if an iCloud password is being requested, you should manually go to the iCloud pane in System Preferences to enter it.
Unfortunately, this is not always possible, as in the case of an installer asking for a password or an app asking for a password to install a helper tool. In the case of Handbrake, it is not normal for Handbrake to ask for a password, so seeing a password request in that context is a red flag. Although I must admit that I might have fallen for the fake Handbrake password request, if I were being more careful, I would check the developer’s website or product documentation to see if that is normal for Handbrake.
If the request comes up while you’re using your web browser, try moving the current web browser window around on the screen. If the “window” moves along with it, it’s not actually a window. It’s an element overlaid on top of the web page meant to look like a window, and that will mean it’s a fake.
It would also be possible to test these password requests by knowingly entering an incorrect password. Phishing malware or websites can’t know what your password is until you enter it, so they can’t know you entered the wrong password intentionally, and will simply accept what you typed. If, on the other hand, the bad password is rejected, it’s likely that the password request is legitimate.
With a little caution and attention paid to the context of password requests, you can avoid most, or even all, phishing attempts. The important thing is to be consistent, and not to get sloppy because you’re in a rush.
