Vault7: CIA Hacking Tools Revealed
Navigation: » Latest version
Opportunistic Locks
SECRET//NOFORN
Definitions:
Opportunisctic Locking: A file locking mechanism designed to improved performance by controlling caching of network files by the client. Unlike traditional locks, OpLocks are not used to provide mutual exclusion. The main goal of OpLocks is to provide synchronization for caching. Opportunistic Locking is supported by SMB.
Batch Lock: A batch lock is used to make multiple file opens and close operations in a short timefram emore efficient. A batch lockslows down the close operation so that if a new open file operation occurs, the operation is canceled.
Exclusive Lock: An exclusive lock occurs when a client opens a file on and SMB server in shared mode. When in an exclusive oplock state, the client can now cache all changes to the file before committing it to the server. When another process/client attempts to open the same file the server sends a break or oplock revocation to the client holding the exclusive lock. At this point the client who obtained the original opportunistic lock flushes all changes to the file.
Breaks: A break request is sent from server to client to inform the client that an oplock is no longer valid. This happens when another client wishes to open a file in a way that invalidates the OpLock. The first client is then sent an OpLock break and required to send all of its local changes and acknowledge the break. Upon acknowledgment the can reply to the second client.
TOCTOU: A time-of-check time-of-use (TOCTOUtime-of-check time-of-use) vulnerability, occurs when an application first checks and validates a resources, does other things, and then uses a resource. An example of a TOCTOUtime-of-check time-of-use bug would be if an application were to validate the certificate of an application, do something else, and then execute the application. TOCTOUtime-of-check time-of-use vulnerabilities rely on a window after validation to switch out the resource.
CNE Application:
For one CNE application we can key in on exclusive opportunistic locking. Specifically we will key in on the fact that the server notifies the owner (oplock initiator) of a break in the oplock. In Windows implementation of opportunistic file locking a callback function be given for oplock break notification. This means, our function will get called when a file is accessed by a third party, although you won't know who is accessing it, you can change the file (or other things) before letting the other application open it. Potentially this could be used to bypass intial PSPPersonal Security Product (Anti-Virus) scanning/sandboxing, by replacing the file with a benign one before the PSPPersonal Security Product (Anti-Virus) gets a handle to the file. This could also be used for notification of point of execution in another application and help you block execution (so you can always win the race). For example, if a TOCTOUtime-of-check time-of-use vulnerability is discovered, and in between check and use a file/directory is read, you may use a tell to know when to switch the resource.
*Note: The second client will not return from the CreateFile call on an oplock'ed file until it is released by the initial client. This could also potentially help DOS a PSP.
Example Vulnerability:
A vulnerability first discovered by User #75254 (Google's Zero Day Project), utilized a TOCTOUtime-of-check time-of-use vulnerability with a COM object to escape the Internet Explorer sandbox. In the sandboxed IEInternet Explorer process, you are allowed to create a COM broker to the medium integrity process. Once you have the broker, you are allowed to obtain some of the classes implemented by ieframe. This includes an implementation of IShDocVwBroker. One of the functions IShDocVwBroker, titled EditWith lets you pass a file path and a class registry handle to call ShellExecute on. Since you are only allowed to execute certain Microsoft processes, the target object is validated. However, between validation and execution the implementation takes time to verify that the file you pass exists. Thus, if we create an opportunistic lock on a file or folder that the medium integrity process tries to access in between validation and execution, we can swap out the execution values to one of our own. Let's take a look at this in action:
We'll start with skipping to the point where we have execution inside the Internet Explorer sandboxed process, have the IEBrokerComObject, and a IShDocVwBroker object. When we call the EditWith function this is the action we see in the medium integrity IEInternet Explorer broker process actions (IE11 Windows 8.1 Enhanced Protection Mode).
Here the process we sent to execute is being validated (Notepad is one of a handful of accepted processes):
Next, we see the process validating the existence of the file we pass to EditWith:
Finally, the medium integrity process calls CreateProcess on the application:
Let's take a look at some of the code. Knowing that we can get a callback when the medium integerity IEInternet Explorer process tries to read the dummy directory, we can set an oplock and change the application from notepad to calc (an untrusted process). Here is some code showing us setting the oplock.
Now, when we call EditWith with an oplock in place, we see we can always win the race.
SECRET//NOFORN