 Hello everyone, it is a great honor to present at DevCoin. Welcome to our presentation, don't dare to exploit an attack service tool of Serpent Server. It is presented by myself, Yuhao Wen of SengFall, Steven C. Lee of Kill Hill 360, and Juniang Peng of SengFall. Let me introduce ourselves at first. Yuhao Wen, who is a web security researcher of SengFall, and also a CTF player of Team K-Pog. Steven C. Lee is a security researcher of Kill Hill 360, and he is a very good trainer. Juniang Peng is the principal security researcher of SengFall. Let's begin. The agenda we will be talking about is introduction to Serpent Server, exploiting server side, exploiting client side and examples, and a conclusion. Serpent Server really doesn't need an introduction as a part of Office 365 products. It is one of the most popular trustee content management systems that we have today. It has online version hosted by Microsoft Azure and Openversion, which we can deploy ourselves. It doesn't need too much professional knowledge and skill to deploy, but actually, in my opinion, it should have a more higher learning curve than other content management systems. You always need to spend some time to get similarly. But many schools and institutions like In-Fat, this is an example of what Serpent Server would look like in 2019. This is a default communication side. It looks pretty modern out-of-date and pretty professional, but hidden behind all that is a lot of features that don't necessarily have buttons or area to reach. We are going to explore a lot of that in this present day. With an introduction to Serpent Server, we can talk about the structure, the key difference, design recognition, and any customized page default danger. With the Serpent Structures, it's a side of the main who can manage different sides, and they can assess the other main panel which has global commigrate settings that can impart multiple sides. Or you can deploy a new web path, lots of features, so it's really a powerful position. To be honest, we have not fully explored the other main panel, but I do believe there is the ability to upload regular files on the server and it's called anyway. Then this is known as the side owner, and this is the regular permissions that given by most users. So if a new user is created and they have side owner permissions, because they can create their own side. If they are just side viewers, they cannot do anything other than just viewing the page. They can change any settings, and waste my side, so think of it as lack of my space or something. They can create their own page, and they can book ten on there and do what they like, but they cannot use their side to assess other sides. They are in a restricted sandbox. The key difference with Serpent and some popular open source competitor would be this. As I said before, this ability to create side. In the Sherpa eyes, side is a new structure, it has a new physical folder on the file systems, then a new visual directly is created and ported to that folder on the file systems. It's run on a different part, it's different application pools, but sub-side will not create a new folder just a visual one, and they can upload page in that side, like a JavaScript file. Those JavaScript cannot assess other side content, which is why Microsoft demo is safe to be able to upload JavaScript code on your side, because it means that JavaScript cannot assess content on another side of other main side. Where lots of dangerous things can be done, users can upload a custom page like a conversation, and there are several different authentication measures, like NTLN, form-based authentication, and so on. The design mechanism of SharePoint is the ability to use an habitually file-related vulnerability that can be leveraged to achieve remote code execution, because it's possible to read the webcomical file, which can contain the validation key of build state destilization, which can be used to generate a particular build state. Execute an habitually command again the application. Oh, I know some other researchers have talked about this before, and this is something that children as a default design of SharePoint. I'm not exactly sure why they have. Besides that, it's generated using a randomized FIST kit in the webcomical, because it's possible to generate a learning kit without using FIST one, like the patch of CB2020.0688, but I'm not sure exactly why SharePoint doesn't use that particular feature. I believe that there are some codes in SharePoint that require the validation key to be stored in the webcomical file. I'm not very sure. But regardless, if a file disclosure vulnerability is found in SharePoint, it means that you have an habitually command execution. The added customized page defaults dangerous. Other permission rather is allowing users with a display village upside on the rather to upload page on that side. So this also works on SharePoint online as well as SharePoint on-premise, but it should be enabled by other means in SharePoint online. It gets dangerous because users can upload also SPS page, can contain client side script along with server-side ACP.net controls. Those are known as sidepages. The controls are filtered by an allow list that is defined in the web config, so you can't just upload whatever control you want. And those controls will be decelerized using SAANL. That several evil payloads use the indie path with SAANL related load, but those payloads don't work here. We can't just decelerize whatever payload we want and get code execution in that way. Users can also not upload in light ACP.net script. It will not work because compilation is never. You cannot run the compiler code on the server. Additionally, the ACP.net server-side encodes are also broke. However, a combination of the allowed server-side controls and JavaScript can be quick problematic. And we will talk about several vulnerabilities that are listed by this. Looking at the table, sidepages which are created by users, the content of those pages are stored in a database. They are not compiled and they are untrusted. And so application pages are opposite. They are created by the system or installation. They are on the file systems. They are compiled and they are trusted. Those files will get compiled and executed when accessed. Now for the server-side. We are going to briefly discuss the attack surface. So using things like bypass sp-page-palace-filter-check, server-side request foldering, SAM palacing, and we'll give you some exploitation examples. Bypass sp-page-palace-filter-check. Sp-page-palace-filter overrides the page-palace-filter. It doesn't check files in file systems and read them directly. But check files in database if they can only save controls and without server-side included. In addition, this page is copied from learn for escape. We want to know what a save control is actually made out of. The root class is system.web.ui.control class and so every sb.net control is then phoned in. And to work out what classes can be used for SAM and other serializations. The controls that are marked as save in webconfigure files. So here is an example. There are two different controls. The first one is actually a net space. System.web.ui.net space. And all types under that net space are saved. Then you have another that has the system.web.ui.web.control.net space. A particular type of cycle data source that is marked as false. It is not safe. By the way, if it is inside save control tag and don't special save or not, it is safe. Let's think if a control is tanned for an unsafe control, is it safe? Yes, actually. Examples. If we look into the webconfig file and we see the cycle data source, it is defined as an unsafe control. But as it turns out, that is a particular class called spcycle data source that is tanned from cycle data source. This particular control is not blocked from the webconfig. It was possible to raise a cycle connection to open sync. Attacker can control the connection stream properties and it can be used to attack the client drivers on the server itself. We saw that this real research is interesting because not many people sat down and looked at into attacking cycle drivers on client side. But all we know my cycle driver is interesting. If you can connect to a malicious mycycle server, then the local server can send back a request for local file. This has been publicly known since April 2nd, 2006. I do know that this is by the data feature of mycycle. If you control the connection stream in most applications, the connection stream is not controlled. But not shared point. Here is an example of a payload. You can see here that the connection stream driver equals mycycle. Then the server to the attack servers, port and database name, username and password. But we need specifically here you can see a select command, select start from users. We need a select command to be able to trigger the communication or it can communicate with the server. And then on the server side, we will ask for the particular file, you know, web.config. We have a proof of concern video here. Note that you need a mycycle driver in the target servers. And the SAP cycle data shows file disclosure bug had a patch by pass. It was interesting because this particular by pass was a tunnel check tunnel use in the way that they check the connection stream. To be honest, we never tested this patch by pass. We just reviewed the patch quickly and see it was vulnerable. They added a check of the connection stream. And this was the message called the check connection stream. It will get the connection stream and call is allowed ODBC driver. Let's check it. The first thing it look out is a DSN in the connection streams. Then you will look out the DSN and find the particular driver out of the DSN. And if that equal to cycle server driver, that's the traffic cycle server, then it will be allowed. But if you look at the implementation of the extra connection to open, it look for either DSN or driver property, whichever is set first it use. We can exploit this for a tunnel check tunnel use by providing a DSN property out of the driver. The impact again is RCE. But we need to know the existing DSN or the target systems that use cycle servers. At the time, we didn't spend too much time on these particular vulnerabilities, but we think there is a way to leak the DSN then. Here is our port. You can see that we're using PowerShell commander at ODBC DSN, which will create a DSN on the systems using cycle servers. When we actually payload itself, here contain DSN equal PLC, as long as the DSN is in here, then it will be treated as trusted. But then when the cycle connection is made, it say the driver property first, and then say it's in my cycle, it's in my cycle driver, then what are the properties? And then it ignore the DSN because that there is no a particular property for that particular driver is a cycle server. And you find a server port database and then trigger it again. So we can continue to read the web config file and get remote code execution. Then look at the next example, CVE 2021 28450. It is an IED DOS bar and come for another unsafe control. We find this control and then the regular expression validator. It look like that link to like as validation. That is unsuncast input from the regular expression validator, it stand from it, which is safe. Okay, let's check this normal example. As we see, we can control the validation expressions and validator value. And it's else when we read the code and we follow that, we can control the time out too. So in this case, we can specify the expressions and the input, as well as the match time out for the expressions to be calculated. What will happen if we insert a malicious expressions? Think about these expressions and our input is 1288 and exclamation mac. It will run very, very slow because the first power of these expressions will be excused repeatedly. It will keep matching and until run out of time. Here is the chart about how many steps will be excused when the number of A is increased. We can see that when we input 28, it will run more than 100,000 steps to try to match. And we will attack it with 1288 and we will, we can set a large time out value so these threads don't get close quickly. So we test it against SharePoint online and make it died after sending 50 requests. You don't need to send requests at the same time. Just send it slowly and save the result. And it will restart after some minutes, maybe 20 minutes or more or less. Then go to the next example that we will talk about. We found the two types that were blocked in web.config file. This was about creating users ready and trained password. And in this time, we can find any class that is trained from them. It is fine we ask ourselves, why are those controls blocked? Why are those particular controls? After doing a bit of research and investigation, we found that those people controls can reach an open file mentioned in the rule controlled class. The trained password and create user ways is standard from web controls, which has an open file mentioned. Of course, there was an additional controlled password recovery, which was not blocked in the web.config. We could use password recovery control to email ourselves, our own password, coupled with a file of our choice. We think it is designed to select an email template file, so email address will aside to account using the phone-based authentication, which was the default authentication for SharePoint Online. They will allow the users to email ourselves whether the web.config file and can ask you again. But the attacker also needs to leak the membership provider, and we can follow it by this session quick hit. And outgoing SMTB server need to be configured on the target system as well, so that we can receive an email of web.config file. This is what the payload looks like. All we have to do is specify the body file name equals a particular part to web.config. We load a quick proof of consent for that one and put it here. Email result here, we can receive machine key in our mailbox. Here we use both to capture it. Then let's put out ship control, and we will talk a little bit about server-side encoder. Server-side encodes are relative that placed in htl page and evaluated on the server while the page are being served. In sp.net, it's convenient to include web.config to still machine key, but it's blocked by default, or most case at least. When you were to make a sps page on the server, you will try to do it included for web.config. It's not allowed because sp page page filter is enabled by default, and it blocked the included. It's a side page and doesn't allow it, but as it turned out, there was a way to bypass some updates. Let's see this example. Here is a famous message named page control, which was introduced in look for escape presentation, and it was in many bounds with the share point. It will pass strings to control the class, and it has the ability to bypass the sp page page filter. If the second parameter to the pass control is true, an sp page page filter will be ignored, by ignoring that way could get an encoder going. So we want to find a message which will call page control with a dynamic flag. The data form will be part of control. It has a particular message called create child control, and it's called when the other control exists on that particular control, and inside this function it called page control. It is a good target if we can make the flag true, and the flag generated from verify spd control maker. We have to satisfy some validation to raise this code in a dangerous way. It has to be valid. Okay, first of all, it needs to be valid as an L, so we can illustrate up fast, because it is not available as an L format. We also need to have run an equal server, or it would be solved as client script and won't pass the modified control. It also needs to be a safe control. It can contain things like object data shows controlled, which is a famous gadget. We create a payload that will use server-side input instead, as you can see. It use phone with run and equal server tag. Don't need to use any unsafe control or object data shows. And then we include the web config file on that particular site, and that it will leak the validation kit and give us remote code execution back. As we have got a video demonstration here. Let's continue this presentation, next we will discuss another type of tag. Server-side requests for glory. Let's look at the bottom row code example. This server will retrieve the URL we controlled and park the URL into a request object. Send the request and return the response. We can set the URL to arbitrary address like verb, collaborator, localhost, file server, or other interesting HTTP servers. We found many SSI vulnerabilities in SharePoint. One of them will be discussed later. We found a very simple function called OLS. It passed the parameter URL of dimension to save create to get a request object and return the result of the request. It look very similar to the vulnerability example mentioned earlier. And here it can be considered as a wrapper of web request.quate. If we can control these parameters, here is a classical SSI vulnerability. At first, we need to judge whether we can assess these measures. Through the research of official documentation and online material list, we found out that when a measure is marked as client callable measure, it means that we can call it with SDP request. The generated format is slash sp slash namespace dot client callable type dot client callable mentioned. So the path here should be slash sp slash sp dot hashtag dot management dot call OLS. Know that here is SP SharePoint. Let's make a trend in there and we can control all the parameters of the client callable mentioned function. So it's very simple to write a proof of concern. Just edit the URL pattern for it. Then wait for the server to meet our address and return the result of URL request. Actually, there are more things about the server side request for gallery, but for some reason we can talk it this time. So the next thing we will talk is SNL pirating. SNL is a very popular make-out language. First standard in the late 1990s and adopted by Calderade Software Project. It is used for configuration files, document format, imagine format and network protocol. And it is so popular that any problem about it has will bring catastrophe results. In the process of pirating external entity, the SNL piracy can create better network protocols and survive like DNS, FTP, HTTP, SMB and so on. According to the protocol specified in the URL, external entities are very useful for create a dynamic reference in documentation so that any chance made to the reference results are automatic update in the document. According to official documents for lower versions of the event, the network. When reading SNL text container, external entities external entities will be automatic piracy. However, when dealing with external entities, many attacks can be launched against the application. Those attacks include the disclosures or local system files which may contain sensitive data such as password and private user data. Or the use of network access features of various programs to manipulate Internet applications. By combining those attacks with other employment files, the school of disc attacks can be extended to survey interruption and even habitually called execution. Depending on the context of those attacks, we call this attack type SNL external entity attack. We also share a simple vulnerability code example. The code snippet shows the classical SNL document.loadSNL mentioned. It will receive an SNL container and piracy to SNL document object. The DTD definition will be executed when pirating. There are also many ways to piracy SNL like as part document dataset.loadSNL and so on. In order to decrypt the huge problem caused by SSE, Microsoft recommends that users use SNL reader to read SNL test before loading and prohibit the piracy of external entity. Or upgrade to a higher version of the net framework which will not piracy external entity by default. But when we check SharePoint, we follow that. The dotnet version of SharePoint is photojello in SharePoint 2019 which means that we are likely to fight SSE vulnerability in it. Here is our fighting of SSE. The traditional vulnerabilities patterns can often bring supply without a message get public in content which will call SNL document.loadSNL. Like our example, it will literally content in the public in file and piracy as SNL content. Okay, let's take a quick look at the code state which appears to be accessible. We need to analyze the measurements. First, it will traverse all files in the slash catalog slash wp directly. We need to classify the files here in quotes or files in database and file systems because it is sp file which is a wrapper of the file object by SharePoint. Then looking for the file with the descent file then as parameter we set. Let it contain and pass it into load SNL. Including the visual file in the database is a good news. Users have enough permissions to upload such files on their website. If it can only read the files in the file systems, we are not be able to do anything. So therefore the first step in exploiting the vulnerability is to upload a sse file which shows it is sse.wp which contain sse payload. Note that the file need to end with .wp. But how to make the server related this file? Let's go back to the code state and take a closer look at the function in the live box. We notice that he has a special aptitude client callable. What does it represent here? It is similar to client callable mentioned we mentioned earlier but it is not the same. It means that we can call it with client-side SharePoint object model API. CSON sender for SharePoint client object model and it is used to instead update, delete and retrieve data in SharePoint. Microsoft provided various client object models like JavaScript models, SharePoint REST API, SharePoint.NET client object models. Then we want to use the last one, SharePoint.NET client object model. When we use debug tools to debug it, we found that every client callable function has a paired remote function. The calling process starts from the client code passes so the remote mentioned of the sender and then send the data to the server so SNL format. The server pairs the SNL and finds the policy mentioned of the corresponding mentioned so the invoke status mentions and finally falls to the client callable mentioned to complete the message call. Now we can start writing the second part of the exploiting, Clue the delete down of CSON and we need to pass the server URL and these users' credentials to get a client contest. Then use the contest to load the plugin file that we created before. And here we set it to SSE. Finally, we should call SQL query to package all the data and send the request which can trigger get public dimension as we wanted. After testing, this vulnerability can also work in SharePoint online. An example of reading window in SharePoint online and our demo of proof of concern is here. But if you notice that we call it SSE instead of Remote Call Execution because it is still 1% threat away from Remote Call Execution. We found that there is an unprecedented character in WebDoc config. According to the same test of the external entity, it will be considered as an entity definition but there is no specific name defined later. This will cause paraphrasing error and unable to read the content of WebDoc config normally. If someone can bypass this shortcoming for complete Remote Call Execution Explanation, please share your tips with us. Anyway, it is still an interesting bonus because it appears in SharePoint client code. Then we have discussed the security issues of the server side. They are often really powerful and don't need any user interaction. Next, we will assume that we have a user interaction. A big turn will open the URL you send in the SharePoint server, how to achieve an account takeover attack. SharePoint has a variety of user authentication measures including NTRN, FBA, OOS and so on. So let's check the FBA form basically authentication. Here is the login form and FBA is a form-based identity authentication. After the authentication is passed, SharePoint server will send a toolkit for users, RTFA and FedOS. If we obtain the toolkit of other users, we can fold user identities but the cookies have a TV-only spec so we can use JavaScript code to steal it directly. And users with decent cookies can access both admin panels and side collections if they have enough privileges. However, as we talked before, we don't trust on the JavaScript. We will introduce vulnerabilities that steal cookies or parameter binding. For these vulnerabilities, we need to solve a problem first. In addition to the request header, where does the toolkit exist? Can we get it? In Microsoft's documentation, a special value is recorded. IIS server variables provide information about the server deconnection with the client and the current request on the connection. IIS server variables are not designed as environment variables. Here is the value that we need HTTP Quickkit. Return the cookie string that was included with the request. Okay, we find another place to get cookies but it is a server values we need to bring it back to the page. When reading the sign articles, we notice that there is a special syntax called parameter binding. A resource can be brought to a parameter value in the current render SSL style shape. The parameter binding element includes a location attribute that specifies resource type. The syntax for this element is similar to the svdonate resource binding expression syntax. The location value is impressed as a function. We can use the location attribute to specify the values for context like query strings, server values, web part properties, control IDs, and so on. So, we can look at this process. When we send a request to the PLC page, the server will stop our cookie in HTTP Quickkit to try slow parameter binding and buy it to the data form of a part value and finally display it in the page. So, here is the proof of consent. We render the cookie back to the SSL value. Therefore, we have the ability to bring the cookies to the current site page. Then we can read the page slow down script without restrictions. Use SNL HTTP request to fetch the value of cookie and send it to our servers. And then check the server's request. You can see that all the cookies are sent contents, rtfa, and fitos that you can use to assign these side or big turns. So, here is our component of today's presentation. The above are all the vulnerabilities discussed in our showing. From the server to the client, we have studied many interesting tricks of SharePoint and most of the vulnerabilities are based on the permission we have to upload page. We're able to find many vulnerabilities in SharePoint because of the special use right. When you give users more permissions, your system is more dangerous. Users' great contents that can interact with server-side controls has the potential to cause some trusting violence. It is hard to build a strong enough filter to protect the systems. And multiple APIs give users different assessments and give an attack a large attack service for discovery tool. So, this is the end of our presentation. Thank you for your listening. Feel free to ask any questions.