The macOS Phishing Easy Button: AppleScript Dangers
The Issue
The recently discovered OSX.Bella malware, which gets much of its payload from an Open Source Software (OSS) post-exploitation toolkit by the same name, reminds us again how easy it is for an attacker to create legitimate-looking phishing dialogs using built-in macOS scripting functionality.
By writing a few lines of AppleScript, an attacker can use system tools like System Preferences, App Store or iTunes to present a legitimate-looking dialog prompting the victim to re-enter their Apple ID or local user account credentials in order to fix a problem an application on their system is having.
Because there was no actual issue, the application will (still) be working as expected, giving the victim the impression that the prompt was legitimate and they helped to rectify the issue. Afterwards, the attacker can use the captured credentials to elevate privileges and take actions of their choosing such as deploying malware or taking control of the victim’s Apple ID account.
What is AppleScript?
Before we continue, let’s look at what makes all of this possible. AppleScript is Apple’s native scripting language that has shipped with Apple’s Macintosh operating system since System 7 in 1991, and every consecutive version through today. As such, it is deeply embedded in the OS and has far-reaching capabilities due to it being part of many system tools, especially those with a user-facing UI.
AppleScript has been popular among home users and professionals alike for its ability to close the gap between what the OS is capable of out of the box and third-party applications, as well as for batch-processing. To make creating AppleScript applications or system services even easier, Apple has also shipped the drag-and-drop driven Automator with macOS since version 10.4.
Why Use AppleScript?
One of the reasons AppleScript has remained popular with Mac users is because it is very easy to create a GUI-driven scripted workflow or self-contained application. Getting user input and displaying results is easy by using the display dialog verb which is available for any application that is AppleScript-compatible.
For example, one might create a script for Apple’s Mail application that gathers email messages from a certain sender by showing a prompt that allows the user to type in the name or email address to search for.
A dialog as shown in Figure 1 can be created with a single line of AppleScript:
The AppleScript snippet that tells Mail to show the dialog looks like this:
tell application "Mail" to activate tell application "Mail" to display dialog "Please enter the email address to search for..." default answer "" with icon 1 with title "Mail"
In order to execute the above snippet, copy and paste it into Script Editor, which ships with macOS and can be found at /Applications/Utilities/Script Editor.app.
Beyond Apple’s core services, there are many third-party applications that also support scripting via AppleScript. For example, if we wanted to write an AppleScript tool that searches our bookmarks for a URL, (ignoring for a second that Chrome has its own search capabilities), we could start with a dialog prompting the user for a website title or URL to search for, as shown in Figure 2:
AppleScript Goes Bad
As is clear from looking at these simple examples, an unsuspecting victim might assume that these dialogs are part of a trusted application because of the icon and generally having a “normal” macOS look and feel, while in actuality, they were generated by an unrelated script. This is convenient for someone developing scripted workflows, as it allows them to focus on functionality and application logic instead of creating UI elements from scratch. However it wouldn’t be a big stretch of the imagination to apply these “easy button UI” capabilities to something a lot less wholesome:
Wait a minute. What did we just do? In fact, we did nothing different from the previous examples where we were searching Apple Mail for email or Google Chrome for a website. All we needed to do was to tell the LastPass application to show a dialog with the application’s icon and text and buttons of our choosing. To be clear, none of the output generated by entering text in the password field or by clicking the Cancel or OK buttons would get sent to the LastPass application.
Instead, our script generating the dialog would receive the password in plaintext as well as the name of the button the victim clicked. The attacker could then take further steps to exfiltrate the victim’s LastPass Vault contents without their knowledge.
Other examples would be getting the victim’s macOS account credentials to elevate privileges if the victim has administrator privileges, or starting other processes that run on behalf of the victim and capture data that is then sent to a remote command and control server. Or, as the OSX.Bella malware implements, prompt the victim to enter their Apple ID credentials.
Pro-Level AppleScript Phishing
Successful phishing attacks are all about meeting the implicit expectations of users to avoid raising suspicions of something being amiss. The recent introduction of the new Touchbar MacBook Pro brought a Touch ID sensor to the macOS desktop experience, and with it a change in workflow of how users interact with their system when authenticating.
Extending the ruse of what has been discussed above to the new Touch ID workflow is relatively simple and we can come up with a sequence that looks something like this:
- First, an alert dialog is displayed by System Preferences, which is a familiar application to the victim.
- The victim is alerted to the fact that a timeout has occurred and that they must re-authenticate in order to keep using Touch ID.
- Optionally, this could be made to trigger only when the victim opens an application to make it seem as if the Touch ID re-authentication prompt was triggered by it.
- The attacker shows a secondary dialog using an available Touch ID icon that is part of macOS in order to complete the look and feel of a legitimate Touch ID prompt.
- Once the victim enters their credentials, the attacker stores them for further use.
- The victim will not notice any different Touch ID behavior since it was never in an unauthenticated state to begin with.
- The deception is complete, credentials were obtained.
A short animated sequence showing this in action can be seen in Figure 3:
The interesting thing to note here is the ease with which a new system workflow can be turned against a user and prey on their expectations and muscle memory. For operations like authentication, which should be considered sensitive or privileged, operations system designers need to think carefully about how their UI and UX communicate the source of their user-facing prompts and develop a clear way for a user to easily and reliably apply a level of trust to the action they are being asked to perform. The lack of a clearly defined and recognizable user credential request method and UI that is gated by the OS and not available to AppleScript could help there, but would take time to gain user trust as the “One True Way” an application can request credentials.
Conclusion
In our opinion, it is entirely too easy for an attacker to borrow (or hijack if you will) any AppleScript-capable application to prompt the victim with a legitimate-looking UI and ask them to enter any amount of sensitive data like passwords, two-factor authentication (2FA) codes, or other information.
Because there is no warning from the OS to let the victim know that another process is attempting to show a dialog via an application it is not part of, it is far too easy to gain a victim’s trust. It would be good security practice if macOS required the user to approve an unapproved AppleScript script in order to interact with an application before actually showing any alerts or dialogs.
For example, the user is shown such prompts in other parts of the OS when an application requires elevated privileges or when it requires Accessibility privileges in order to function. In all those cases, the OS intervenes on behalf of the requesting application by obtaining user authentication or authorization and performs the requested action before allowing the requesting application to proceed. It is time for Apple to apply the same security measures to AppleScript to prevent this type of phishing.