 Morning everyone. We're here to talk about the Windows data architecture, more specifically WSS. But before that let me just introduce ourselves briefly. Here's Yves. He works for the French National Security Agency. He works as a security auditor for more than 10 years now. And I'm Roman. I was a security auditor but I'm now a developer in a small company dealing with active directory security issues. Before talking about the WSS itself, I'll introduce you to a problem scenario that we're encountered sometimes during our pen tests. So that's you waiting to compromise a network. The network. And somehow you get a foothold inside this network. It can be by phishing or compromising J-BOSS server or Tumcat or Oracle with default credential. And as anyone knows, when you're compromising this kind of server, it runs with system privileges because you have to. It doesn't work otherwise. So you filter the credentials on this server. You manage to do some lateral movements. And at some point you just realize that everything you have, you're blocked. You can't go more in the network. But by looking at the information, the data that you get on the servers, you realize that there's another network, disconnected ones, next to the one you're trying to compromise. The problem here is that you don't have any more credentials to get more into the network. So you're basically screwed. But when you look at the servers you've compromised, there's a WSS server. And the question we are going to talk about in this talk is that what if you can use this WSS server to compromise its clients? And more specifically, the domain controllers that are clients to the WSS server. And to answer this question, we need to understand a little bit of WSS architecture. So here you have a WSS server inside the enterprise network which is synchronizing its updates with Microsoft updates servers. And this synchronization is done in two steps. The first step is to synchronize the metadata on an HTTPS secured channel. And the second one is to synchronize the binaries associated with this metadata on an HTTPS, sorry, channel this time. This can be a problem, but actually it isn't because of the signature that any binary needs to have. We're talking about authentic signature here. So no one can actually tamper with the binary even if the channel is not secured by TLS. In the metadata you have anything relating to the updates themselves, including the MS Microsoft bulletin number, the description of the updates, whatever the information. And the binaries can be anything from a PSF file, a cabinet file, or more interesting for us, an executable file. The executable file has a particularity because it can take common line arguments and the common line arguments are provided into the metadata, which aren't signed. We'll see why this is important later. Then inside the enterprise network you have WSS clients. It can be work station, it can be servers from a filer to a domain controller that regularly synchronizes with their updates with the WSS server. They do it by default on an HTTPS channel. Microsoft is pushing forward to administrators to enable TLS, but it's not really often the case. The updates are obviously applied with full system privileges because if you need to replace a critical part of your system, well you need to have full system privileges to do that. In more complicated network you have what Microsoft calls upstream and downstream servers. Think of a worldwide company with an internet access and one policy to manage updates. You can change servers and the updates will follow the chain. And if you have even more complicated networks with disconnected ones, for example, Microsoft is providing a tool to export updates from WSS server to an external disconnected WSS server. So that's a quick overview of the WSS architecture. We're going to talk about now the start of the art, state of the art of the attack on WSS and it's going to be pretty quick because there's only one attack that has been presented at Black Hat USA two years ago now. It's called WSS specs. And the idea of the attack is to get a managed middle position between the WSS clients and a WSS server to intercept the answer of the server, inject a fake update into the meta data stream because it's on HTTP channel inside the enterprise network and the meta data on sign. And the clients then apply these new updates with system privileges and that's how you get control of the WSS clients. This really is an awesome attack because it's the first one on Microsoft architecture but it has some limitation. The first one is that you need to get a managed middle position, meaning that there's no network limitation in place such as private VLAN, for example. And the second limitation is that you need to get a useful one. So here I presented you a node TLS enabled network but sometimes administrators do their job and secure these streams. In our case it's difficult to put in place inside the network, the internet connected network but it definitely can't be used for the disconnected one. So we developed our own tool which is called WSS Pandia and it's freely available on GitHub. The idea of the tool is not to have network limitations but if you have compromised our WSS server you can inject meta data into the database and use the sign binary, we'll talk about that later, inside this WSS server. And when the clients will download this update, it will see a new update and it will download the binary related to this update. The first thing a client does when it downloads a binary is to check if the binary is signed by Microsoft. So you have to have a signed binary which can execute arbitrary commands. So the two most known binaries are PSXI and BGINFO. They were presented with WSS spec attack but actually you can find other binaries if you look at the up-locker bypass projects such as the one with sub-t. So you can use for example MS build or install util which are two of the binaries which are signed by Microsoft and that take command line arguments that execute arbitrary commands. So you have in the meta data command line arguments, the binary is signed, that's how you get the control of the WSS clients. Okay, so we have some video to demonstrate what could be done with WSS pandue. Okay, in the scenario we have compromised a bunch of servers but we don't have compromised the domain controllers. So we can use some servers to try to compromise the domain controllers. And among the control servers, among the servers we have compromised, they are WSS servers. So we try to inject an update, a malicious update to control all the clients. Here we are on a WSS client. We have absolutely no privilege and no, no account on this servers. We can verify and only the administrator account is present. The aim of the attack is to add the new users on this computer. So as we have compromised the WSS servers, we copy the binary, WSS pandue and a payload. It's exactly in this case. And the servers aren't, we want to launch, we want to launch an injection. So we launch the injection of the payload, that's exact in this case. And with some arguments to add a new user. So we launch a command to add a specific user with a specific password. While the update will be installed with system privileges, we take advantage of this to add the user in the local group, administrator local group. The last things we have to precise, we can precise is the computer name of the targeted computer. By processing it, we can automatically approve the update for this computer. We can check in the MMC console and after refreshing, we can see everything is okay. The update is present and is approved for one computer among the four declared in the WSS server. Okay, we go back to the client and we have to write the client check if a new update is available. We can force it by clicking on check for updates. And if an update is present, the system download it, install it with system privileges and the update will be installed. That's it. So we can check now the user list and we can see the new user is present and the user is a member of the administrator local group. So mission succeeded. Okay, we have compromised the connected network. We have compromised all the connected network, but we want to have a more intrusion in this network. We have seen that a new user will be able to connect to the current network. Another network is present, but this network is not connected to the current network, not to the internet. So we want to inject an update in the WSS server present in the connected network. And we want to wait that an administrator transfer the update to keep up to date the disconnected network. So as we have compromised, again, the WSS servers in the connected network, we can launch the script, we can copy the WSS to perform an injection. And this time we want to launch PSXX, but the argument of PSXXX is not to add a new user because it's not relevant to a disconnected network, but we want to launch a power shell and the argument of the power shell is an uncoded payload. We'll see later what is this payload. This time we can't precise the targeted computer because no computer of the disconnected network is known in this WSS servers. Okay, the data is injected. We can see it in the MLC console again. And everything is okay. Now we have to wait that a legitimate administrator has to perform his work to transfer the updates to keep up to date the disconnected network. To do that, the administrator is connected on the WSS server located in the connected network. The administrator transfers the updates, the update binary and launch the WSS tools provided by Microsoft to export the metadata from the database to an external device. After transferring the device and the disconnected network, you can import the updates. So to do that, you copy the WSS content directory in the disconnected network and launch again WSS tool to import metadata into the database. Now we can see the data in the WSS servers located in the disconnected network. We can see some information like the classification, the update as a security update classification. We can see some other information like the Microsoft Bulletin, MS 1710, the Bulletin describe the vulnerability exploited by when I try. And the description is set. All this information are controlled by the metadata, so by the WSS pandue. Now the behavior of the WSS servers depend of the configuration of the servers. If we check in the option, we can see that a default automatic approval rule is set. This option is active, is present by default, but not active by default. In this case, the administrator just enable it. This rule says that if we are in case of security updates classification, the update will be automatically approved. So if it's not the case here, so the update will be approved for all the computers. Now we go on victim. We can see a victim is a computer in the disconnected network, and we have to wait the victim search if a new update is available. We can force it again by click and check for updates. And normally the update will be, will arrive, and start with system privileges. And if everything is okay, something will be open. Okay. Remember that the administrator just want just to update the disconnected network to protect again somewhere, as example. And after doing it, we can see the effect is a little bit different. As an attacker, we just have to wait for money now. Okay. So we have compromised the connected network. We have managed to transfer an update, malicious update to the disconnected network, and we have compromised the disconnected network. Okay. In conclusion, we can see that if we have WSUS servers in, if we have WSUS servers in the network, we have control relationship from the WSUS servers to all these clients. So we need to be careful about the positioning of these WSUS servers. When you design a new architecture, we have to add things about the WSUS servers. Thanks for your attention.