 Good afternoon. Thank you for coming. My name is Cesar Zarrudo. I'm going to present Talking in Napping's Revenge. This is kind of a follow-up of a research I did before that was called Talking in Napping. All the issues I found in previous research were fixed and these are all new issues. The objectives of this talk are first to demonstrate that while Windows operating systems are getting more secure with every new version, there are still some issues that are very easy to find. Just scratching the surface you can find some issues. This allows to bypass protection as we are going to see. Another objective is try to show you how I found these issues with the tools, with the techniques I used so you can learn, so you can do it at home or work. It's an important thing for me as a takeaway for you if you can learn something today. I'm going to be fast. I have a lot of demonstrations. In the past, think about Windows 2000 and before, all the Windows services used to run under the local system account, which is the most powerful account on Windows operating systems. So if a service was compromised, then all the system was compromised. Then with Windows 2003 and XP, Microsoft introduced a couple of new user accounts called Network Service and Local Service. These accounts have restricted privileges. They have fewer privileges than the local system account. So in theory, they started to run some system services under these accounts to prevent when one of these services was exploited. That doesn't mean that all the system was going to be compromised. Then with Windows Vista, Windows 2008 and Windows 7, there were a lot of new protections for Windows services. They improved a lot from the previous operating system version, but we are going to see that this protection can be easily bypassed by spreading some issues. Let's see some theory first about what is impersonation and what are tokens. Impersonation is when a thread can act as if running under another user account as the process that's on the thread. For instance, we have a process that is running under the Network Service account, so that process can impersonate. So when a thread starts to impersonate, it can start acting as if it were another user. So when this thread starts to access resources such as file system or registry, all the ACL checks are performed against the impersonated user and not the user that the process is running under. There are many different APIs to impersonate. Here we have a few like impersonate name pipe client, impersonate logon user and RPC impersonate client. So when you call one of these APIs and a client connect to your service, then if you can impersonate, you start impersonating. In order to be able to impersonate the account that the process is running under has to impersonate a client after authentication privileges. This privilege is not assigned to all users, only to accounts such as Network Service, Local Service and accounts used to run service on Windows. Also IIS, Internet Information Services, Workout Processes, the process that are used to run web application, those has impersonation privileges too. And also we have Windows management instrumentation processes which also has impersonation and they run under Network Service, Local Service and Local Assistant account. So when a thread starts to impersonate, it will get an associated impersonation token. Well, a token is a Windows object that has information about the security context of a thread or a process. It includes information such as the identity of the user and the privileges associated with the user. There are two kinds of tokens. We have primary tokens and impersonation tokens. The primary ones are those that are assigned to processes during process creation. And then the impersonation tokens are those that are get when a thread impersonates. There are different levels of impersonation. We have a security anonymous identity impersonation and delegation. We will focus on the impersonation level which is when a thread can act like it's another user. On Windows XP and 2003, the services run under the Network Service, Local Service, Local Assistant or User Account. And all the services on this Windows version can impersonate. There was a weakness I found in my previous search that if there were two processes, two service processes running under the same account, they could access each other and get a impersonation token from the other process and evade privileges. So what Microsoft did was adding a protection to special processes and services to avoid them to access each other and get token and evade privileges. So they protected mostly processes that impersonate the system account. So for instance, they protected the service that ran RPC. And they also protected Windows management instrumentation processes. We also impersonated the system account. On Windows Vista, 2008 and Windows 7, one of the new protections that were added by Microsoft is called PerService SID. This is a really good protection. But basically what they do is just put a special ACL in the process object. So for instance, we have a service that is running on the Network Service account. So they remove the Network Service account from the ACL of the process and they insert a unique SID on the ACL. This means that the other processes that are running on the Network Service account won't be able to access these processes because they don't have permissions. Basically this is almost the same protection they added to fix the issues on Windows XP and 2003. I found a couple of weaknesses on Windows Vista and 2008 that while the regular thread were properly protected by an ACL like the same as the process, the threads from thread pools with our special kind of thread managed by pools on Windows is a functionality provided to automatically manage thread. They had the default ACL. So other process running on the same account could access these thread pools and manipulate them and elevate privileges or do other things in another process different than the process that was attacking. Another issue was I think I already said that Windows Management Instrumentation processes that runs on the Network Service, Local Service and System Account, they were not protected by a proper ACL. And these processes impersonate the System Account. So any other process running on the same account can access these processes and still the token and elevate privileges. So they fixed that Microsoft did was properly protect the thread from the thread pools with the appropriate ACL and also the same for the Windows Management Instrumentation processes. So when Windows 7 was available, I think it was the release candidate, I decided to take a look at it to see if I could find some low-hungry fruit, just like I said scratching the surface to see if there was something easy to find with simple tools. I will show you the tools. For instance, we have Process Explorer tool. This tool allows you to run all the processes on a Windows system. You can see here the process names, the process IDs in this column, description of the process. Here you can see the username that the process is running under. You can see if DEP is enabled, the integrity level of the process, et cetera. And when you select one process, you can see information related to the process. Here we can see all the handles, the process has opened. We can see the token handles, the thread handles, registry key handles, same for five handles, et cetera. Also we can see the information related to the process, like the security, we can see the permissions, the ACL of the process, the privileges assigned to the account, the process is running under. We can see the thread. It's a lot of information. For instance, if you double-click over a service, in this case it's SVC host process, which is a hosting process that is hosting many services inside. We can see here all the services. We can see the permissions. We can stop and start the services. This tool is really easy to use and very powerful. So I started to play with this tool, looking around permissions, processes on the handles, et cetera. And I couldn't find anything in a couple of minutes. So I think I also checked if the protections Microsoft added to fix the issues I found before were okay. And everything was fine. So I thought that it was pretty secure. Then I remembered that I had found a little issue on Windows 2008. But it's a minor issue. The issue is about on-telephony service. We can see here this is another SVC host process that is hosting five services. And one of them is the telephony service, TAPI service. The issue is that inside this process, there is a process handle from another process. We can see here the process ID is 1308. I don't know if you can see there. This one is process ID 976. And this service run under the network service account. You can see it here. Network service account. But the other process that this process has the handle inside that process was, let me see, 976. We can go to process 976. And this process run under the system account. So this is weird because there is a process running under a low-privileged account having a handle, a process handle for a privileged process. So I took a look at Windows Debugger to see what were the access of that handle. So we can attach the process on Windows bug and take a look at the handles. And you can see here the handle value in exa notation. This is the handle from the process itself. And this is the handle from the process that is running under the system account. And we can see here that it has granted access, duplicate handle granted access. That means that from this process I can access any handle from the other process, duplicate them and do whatever I want. I can do almost anything with the other process. And this is clearly an issue because I am accessing from a process running on the network service account to a process running under the system account, which is the most powerful account on Windows. So I could duplicate for instance the primary token, which will be a system token and use it to elevate privileges. It's pretty simple. But in order to exploit this issue, first you have to find an issue on the telephone service itself because this will be a post exploitation issue that I could use to elevate privileges. But first I had to find an issue on the telephone service. So that was the only I was getting when looking at Windows 7, so I started to focus on the telephone service. So I decided to use the... There is another tool called process monitor. It allows you to monitor all system activity on the Windows operating system. And it allows you to filter by many options. You can filter by process ID to display activity to a specific process, by process name, by path of the object that is being accessed, etc. It has a lot of options. This is also a very powerful tool. And you can monitor at the same time, registry access, file access, network access. So what I did was set a filter to monitor only the telephone service and run the tool. And after running the tool I had to interact in some way to the service so the service will perform some action that will be captured by the tool. So what I did was starting the... Stopping and starting the service. And you can see there in the background the tool is capturing activity. So I stopped the service. Then I started again. And a lot of activities was being captured. So when looking at the capture, there were a lot of things. So I started to look around. There was something that got my attention that was one registry key that I haven't seen before. It's a registry key on each key, local machine key. And the soup key is called tracing slash TAPI SRV. I don't know if you can see there. So I went to registry editor to look at this registry key. And I thought about checking permissions on the key. And when I checked the permission, I found a surprise there. I found that the local service, network service and user account had a special permission. So I went to see what were those special permissions. And I found out that all this account could set value, has the permission of set value in this registry key. So this is another issue because any user can set any value in this registry key that is then read by a privileged process such as the telephony service. So I think it was a way to maybe exploit in something and then elevate the privilege with the previous issue. So I started to look around at the registry values. Also the registry subkeys. And I could see very, you can see here very similar names to processes in Windows. So I thought it was a functionality that was used by many processes in Windows. I didn't know what it was about. It was just playing with the tools. So then I started to look at the values of the subkeys. And I found one interesting value called file directory that has a data value of directory, Windows directory. So I looked at the directory and it was empty. You can see there is nothing there. Then I continued looking at the values and I found another more interesting value that was almost self describing. The values named enabler file tracing. And it was a tracing, remember tracing subkey. So I said okay, let's set this value to one to see what happened. So I set the value to one. And in the background process monitor was still running. So I set the value to one and returned to see on process monitor it was also happening. And I could find something interesting. Here at the end you can see a file being created in the directory that was specified in the registry. So when I saw this, I started to think that it was exploitable. Maybe the guys that know about Windows local exploitation know how to exploit it already. So I could get a file created in any directory I want. So it was clearly an issue because any user could do that, could change that registry key. You can see there the file that was created, the SAP SRB log. So after this I started to reserve more what was the tracing functionality. I noticed that it was a functionality used by some services and processes to save information related with the bug, with errors. I don't know maybe Microsoft used this information for customer support, I don't know. But basically in that file that was created it saved the bug information and error information. So the way to exploit it is pretty simple. You remember one of the APIs used for impersonation I mentioned at the beginning is called impersonate, name pipe client. What you can do is build a simple program that creates a name pipe, lessen on the pipe and wait for connections. When it gets a connection it will impersonate the process that is connecting to the pipe. So I saw the issue it was very easy to exploit but I have to confirm if the process will try to access the pipe. So I set in the file directory value slash localhost slash pipe slash x, which will be a name pipe. And after setting the value I went to process monitor and I found that the telephony service was trying to access the name pipe. You can see there it is trying to access the name pipe. So this was clearly exploitable and pretty easy to exploit. Just the only need for an attacker to exploit this is to be able to impersonate. If you can impersonate then you can elevate previous privileges to network service account which is the tap service account and from the tap service account you can access the other process that is running under the system account because the process handle with duplicate handle privileges. So basically you can go from any user with impersonation privileges to local system account. But changing the registry value for the telephony service will be a two-stage attack. So I decided to look at the other registry keys and I found one familiar for me which is IPH, LPSBC which is reminding to the IP helper service. So I went to process explorer trying to see if there was the same name as the IP helper. So I looked for the IP helper and I found it. You can see there the IP helper service is hosted in a SBC host process and the process runs under the system account. So this is the best candidate for exploitation. I only need to write a value to the sub key of this service putting a name pipe there and they wait for the connection of this service and impersonate the system account and elevate privileges. You can see there I changed the value in every file tracing and then process monitor, sorry, you can see here the file is being created after I changed the value when I enabled the tracing functionality. When doing more in-depth research I started to debug a little and I found out that the processes that use the tracing functionality will be monitoring all the time for the registry. So if there is any change to the registry key they will read it instantly. There is a special API used to monitor changes on registry and they use it. So the exploit is pretty simple. What you have to do is just set a name pipe, create it, lessen on it, change the registry value to the name pipe, enable file tracing and you get the impersonation talking from the system account and elevate privileges. I will show you an exploit now. I have a net cut locally and then I have access to an internet information service 7.5 which I have a .net command shell there. I can run any command and you can see the version is 6.1, it's Windows 2008 release 2 and you can see the web application, the worker process of internet information services is running under this special account called the fall app pool that was introduced on Windows 2008 release 2. Microsoft decided to change that the web application on internet information services don't run anymore by default under the network service account. So now by default they run under this special account which has the same privileges as the network service account. It can impersonate which is cool. So I have uploaded this command shell to the server, then I also uploaded the exploit. The exploit is called Chimichurri. So I put the path of the exploit, the remote IP and the port number. I run the exploit and I get a reverse shell on my host and you can see here it's a reverse shell running under the system account. So it's pretty easy to exploit. You just need to be able to upload some stuff to some internet information service and you can root the system. Let's see the some code. Well this exploit is called Chimichurri which is an Argentinian source used for Churrasco. It was the idea of Federico Kisman, San Federico for the nice name. So basically this exploit what it does is creating the pipe. You can see here the name of the pipe with the file name that is created by the service when tracing functionality is enabled. So we set this value on the registry value and then enable file tracing and we get this file, the name pipe, try to be accessed. So here the name pipe is created here we can lessen on the pipe and when we get the connection we impersonate and with the impersonation we open the thread token and we run a reverse shell. The trigger of the vulnerabilities here this is the trigger of the vulnerability. So we set the file, the tracing file name, file tracing name to this value and then we enable file tracing and that's it. It's a pretty simple exploit. So after finding this issue, after finding this issue I decided to continue looking at the telephone service because it was very easy to find. So I found that with the dialer application you can dial and call by using the modem. You can interact with the telephone service. It uses the service to make the telephone connection to handle the modem etc. So I ran the dialer application while monitoring the activity with process monitor and a lot of activity was captured. So looking at the capture, I found another interesting key, registry key which I haven't seen before. So I got my attention on H key, local machine, software, Microsoft, Windows, current version, telephony. So I went to this to see what was this registry about with registry editor and again the first thing I did was checking the permissions and I found another issue there when checking the permissions. You can see there that network service account has full control over the key. Why this is an issue because you may think it is okay because the process running under the network account, so the process should have permission to manipulate this key. But the issue is that this breaks the per server SID protection because any other service or process running under this account will be able to manipulate this registry key which then will be read by the telephony service which is a different service. So by this permission issue we are breaking the per service SID protection. But in order to exploit this I had to find some way to do it. So I started to look at the different sub keys and there were a lot of sub keys until I found another interesting sub key with some interesting values. You can see there provided file name 0, provided file name 1, provided many stream values there that has a data value what it seems to be a file name with extension TSP. Looking at the process monitor I found that the service was trying to access these files. And to my surprise these files were loaded as a DLL. You can see there that these files are loaded as DLL, loaded image operation. So the issue started to become very easy to exploit. So any service could change this registry value any process running under the Neuropsy account could change this value and get a DLL loaded inside the telephony service. So I had to check if it was really a DLL so what I did was open it with notepad and check for the headers. You can see MF at the beginning and this program cannot run in those mode so it's actually a real DLL. So it was easy to exploit, I mean just changing a registry value but I had to find out how to interact with telephony service so it will load my DLL because I could change the registry value but that doesn't mean that the service will load it because in this case these files were loaded as DLL because the DLL application was interacting with the service. You can see there also the other file names are also loaded as DLL. So what I did was going to MSDN looking for information about the telephony service to find out how I could, from my exploit I could interact with the service to get the DLL loaded. So I started to look around the documentation until I found a really interesting API that was almost self-describing. The API is named Line App Provider and you can see in the description is this function install a new telephony service provider into the telephony system. And it has the first argument name is LPSF provider file name. So that got my attention because this argument name is almost similar as the registry value name. And you can see the description is pointer to a non-terminated string containing the path of the service provider to be added. So I thought I had to try this API to see what happens. So I built a very simple application. It's a very simple application that we call the API Line App Provider and we pass as a first parameter Toto.tsp. So I built this application and started to run tests to see what was, what would happen when I run it, what will do the telephony service with that. So first I ran it under the administrator account to see just if it worked or not. So I ran it and on process monitor I could see that the telephony service was trying to find the file on all the registry path of the system. It couldn't find it because it didn't exist. But I could find out that this API really worked and it would get me the DLL directly loaded. I had to confirm it with running under the network service and account. So what I did was I created a Windows task, set the task to run under the network service account. So I ran the task while monitoring with process monitor. And after running it I could see the capture and again the telephony service was trying to load the file. You can see here again it tried to find the file on the registry system path. So I could find out finally that this was an issue and it was very easy to deploy. Just call the API, pass a DLL and you get it loaded inside the telephony service. And from there the DLL code can manipulate the handle of the process running under the system account and elevate the system. So one last try I had to do was try to run the program as a local service account because it was clearly that the network service account will work because the registry permission was full control for network service account. But I had to try with local service account just in case. So I tried with the local service account. And I found out that also the telephony service tried to load the DLL. So the risk was wider because in this case any user running under the network service or any process running under the network service or local service account could get a DLL loaded inside the topic service and elevate privileges. Well when running the DLL application and the test program I noticed something. If you remember in order to elevate privileges from the telephony service to local system account we need to have the process handle with duplicate privileges inside the topic service. And in the test I did sometimes that process handle wasn't there. And that was the case sometimes exploit wouldn't work because I would be trapped inside that service without elevating privileges. So I have to find out why sometimes the process handle was there or not. So when running the DLL application I noticed that also the telephony service get a handle of the DLL process. So I looked again with the Windows debugger and I could find out that the DLL process handle has duplicate handle too. So I realized that any process that uses telephony service functionality will get a process handle with duplicate handle access inside the telephony service. So what I have to do now is to find out what was the service that was running under the system account accessing the functionality of the telephony service. So I get the PID of the process and started to look, it was a SBC, you can see here, it was a SBC host process hosting a lot of services. So the option will be to stop and start the service to see when the handle appears and disappears and identify the service by looking around at the different service iPhone 1 that was really suspicious to be the guilty because the name was remote access connection manager. So I said, okay, access remote connection should use maybe telephony service functionality. So I stopped the service and I went to look to the telephony service to see if the process handle was still there and the process handle wasn't there. You can see there it's only the process handle from the same process, not from the process running under the system account. So I found out what was the service that was running under the system account that was interacting with the telephony service. The next step was to check if any user could run the service because if the service wasn't running, if I want to exploit the telephony service, I won't be able to get this process handle duplicated. So what I did was checking the permissions on the service, on the Rasmus service and I found out that any user can run the Rasmus service. So if the service is not running, then you can run it and then exploit and elevate privileges. You will always have the handle inside the telephony service. I checked also if it was my initial test was on Windows 7, but I did the same test on Windows 2008, release one and two and it was the same issues were there. I had to check also on Windows XP and 2003. And to my surprise, the telephony service, the registry permission issues wasn't present on Windows 2003. So there were no issues related to the permissions. But the surprise was that the telephony service on Windows 2003 and Windows XP runs under the system account. So if I'm local system account on NevoService account, I just call the API and get the DLL running under the system account. It's more easy to exploit on Windows 2003 and XP. You can see here the telephony service running under the system account on Windows 2003. You can see here the telephony service running on Windows 2003 and 2003. So no issues with registry permissions. So while I was researching the issues, I noticed something strange on registry access, some processes trying to access some different sub keys with similar name under different keys also. So I started to look around. I have a few time. I started to test again the fix on for Windows management instrumentation process on Windows 2003 because while Microsoft was protecting with a proper ACL these processes because they impersonate the system account. You can see here and the process in charge of running this Windows management instrumentation process is the decon-launch process. So I started to monitor this process, the decon-launch Windows management instrumentation process with a test script. You can see here that the Windows management instrumentation is running under the network service account. But if you look at the ACL of the process, the network service account isn't there. So this is the protection that was added by Microsoft. So I cannot access this process from another process running under the network service account. So I had to find a way to modify this ACL to be able to exploit it. So I continue researching this. By looking at the process, in this case, is this SBC host process which is the decon-launcher process is in charge of launching the Windows management instrumentation process which are this. So I was monitoring the activity related with decon-launch and I found it accesses a lot of registry key and I found something interesting. You can see here H key user S1520 classes. This is the class sub-key for the network service account. The S1520 SID is the SID of the network service account and this is the user key from that user account. So first this process try to access this key and it successfully access it but after accessing the sub-key try to access another sub-key inside this the previous one and it's not found. So it's not found so the process continue with activity and later it try to access the same sub-key as before but in another different key. In this case the key is H key classes root. So you try to access the key in the sub-key in that key and you find it and then after finding it it will read the values try to use these values. So I found that this was probably an issue because the sub-key under H key user this sub-key can be manipulated by the user that the sub-key belongs to. As you can see there NegoService has full control over the sub-key but the key name H key classes root can only be modified by administrators and system account and cannot be modified by other users. So there is probably an issue here because users can modify the user sub-key and this sub-key will be read by a privileged process so this could be an exploitable issue. As you can see at the different values from the registry key that were that were being read those problems. As you can see Windows Media Plash Air sometimes has some problems. Okay, we will continue with this. So there was the problem here was that we have two different keys one controlled by administrators and this two different keys are accessed by a privileged process and try to read value from them. So I thought what about if I create those values that are not present there maybe the process we read the values I create and use them and maybe I can elevate privileges and modify the actions or do something. So I started to make some test creating the values that were existing on the network service user sub-key. So I created the value, started to change some options and I couldn't get anything working at the first try. But then I found an interesting value called app ID flags. So I went to look for the value description of MCN, I found it and said that it contrasts the security behavior of comm servers. So I said okay and the value that was being used was number two was secure comm server. So I said maybe this value is used to secure the process. So let's try to set the value to zero. So I did that. Create the value set it to zero run the test program and I got the Windows management process running without protection. So finally I confined what was the Microsoft application was adding a new value to the registry to get the process protected. And because the issue of this service running on the system I called accessing two different keys and one user controllable. So I could set my own values and have the Windows management process running without protections. And exploiting it will be easy because I already have deployed that I did for research. So the only change I have to do to exploit was creating a registry value. The former spot was churrasco this is churrasquito which is a small churrasco. The only modification I have to do was just create the registry sub key and values. You can see here. So I create the sub key. Here you can see S1, S5 classes. UpID and then set the upID flags value to zero. So when I set this value to zero then I call Windows management instrumentation functionality, get the process running unprotected, access the process and get the system token from there and elevate privileges. This exploits almost the same as before and works on Internet information service 6 by 40 runs under the network service account. So you only need to upload a common shell or an ASP.NET exploit and run it and you can compromise the Internet information service 6. So sadly I don't know let me show the exploit video. It's pretty simple. So I run network locally. So I already uploaded a common shell. This is IIS 6. So I can run any command there. And you can see that by default it runs under the network service account. This is Windows 2003. IIS is this application is running on the network service account. So I run the remote IP and port number and I get the remote shell running under the system account. Like I said it's almost the same exploit with a little modification. Just creating a registry value and that's it to bypass the fix that Microsoft introduces for my previous research. So we should be ending. So the threat scenarios basically are web hosting companies where they allow you to upload your stuff and you can run web applications so you can compromise them for $5 or $4.99. In company developers can also upload codes for testing production. They are not administrator but they can upload your stuff and you can compromise servers. SQL server administration which are not Windows administration they can also run programs and SQL server account can impersonate so they can also compromise the server. And finally like we already saw on process protection scenarios some of this issue will allow you to bypass the protection. First you don't have enough privileges and you cannot access other processes by spreading the issue you will be able to elevate to system and escape from the protections. So about fixes Microsoft will be fixing the registry key issue and another local elevation privileges that I didn't speak about today because any user can elevate privileges on Windows 2008, no, Vista and 7. Also Microsoft is releasing an adversary stating the issues related to impersonation with the nervous service and local service account. So final conclusion is that Microsoft has improved a lot but some protection can be easily bypassed sometimes with simple issues like the one I showed. Like you saw finding this issue are not difficult just making a round using public available tools. You just need to look and observe and find the issues. So we are out of time. Thank you for coming. We have questions and a question I am answering for one.