Tag Archives: RCE

Story of my two (but actually three) RCEs in SharePoint in 2018

I became interested in looking at .NET deserialization issues in Jan. 2018 when a work colleague (Daniele Costa) asked me whether I had worked with the ysoserial.net tool before (and the answer was a no!). I began to like it more and more just by looking at the generated payloads, and then by reading its useful references. It even answered one of the questions that I always had in mind: “How can ViewState or EventValidation without MAC enabled lead to remote code execution?“; the answer was simple: “deserialization attacks using ObjectStateFormatter or LosFormatter”. I know I was late to the party but as the attack surface is huge, I managed to exploit a number applications including SharePoint without really having deep knowledge in this area. 

As mentioned in the MS 2018 Q4 – Top 5 Bounty Hunter for 2 RCEs in SharePoint Online post, I managed to exploit two RCEs in SharePoint Workflows that also affected SharePoint on-prem versions. Therefore, in addition to having a good bounty for the online version, I managed to get two CVEs in .NET Framework (CVE-2018-8284 and CVE-2018-8421).

Details of these vulnerabilities were published in NCC Group’s website as can be seen here:

  1. Bypassing Workflows Protection Mechanisms – Remote Code Execution on SharePoint
  2. Bypassing Microsoft XOML Workflows Protection Mechanisms using Deserialisation of Untrusted Data

The first one was a logical issue in the Workflows. This was the one with the epic Microsoft’s response:

The second one however was a deserialisation issue that was not fully exploited on SharePoint until after the advisory was published. Here is the short story:

Which was shortly followed by a fully working exploit thanks to Alvaro’s tip:

It should be noted that Microsoft had already given me the maximum bounty that is for an RCE issue even for the second one.

Finally, 2018 was a good year for me on SharePoint finding 3 RCEs in it. If you are wondering what the third one was, the clue is in the ASP.NET resource files (.RESX) and deserialization issues post. I did not receive any bounty for it despite having a reverse shell on the Microsoft SharePoint Online server due to an ongoing engagement my company (NCC Group) had with them at the same time (unlucky me but I was lucky enough to be compensated by my company as they recognised my efforts).

ASP.NET resource files (.RESX) and deserialization issues

I have recently published a blog post via NCC Group’s website about the deserialization issue by abusing the ASP.NET resource files (.resx and .resources extensions). A number of products were exploited and some file uploaders can also be vulnerable to this type of attack.

The full article can be viewed in NCC Group’s website: https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2018/august/aspnet-resource-files-resx-and-deserialisation-issues/

PDF version of the blog post published by NCC Group can be downloaded from:


In addition to this, the advisories can be seen via:

Code Execution by Unsafe Resource Handling in Multiple Microsoft Products: https://www.nccgroup.trust/uk/our-research/technical-advisory-code-execution-by-unsafe-resource-handling-in-multiple-microsoft-products/

Code Execution by Viewing Resource Files in .NET Reflector: https://www.nccgroup.trust/uk/our-research/technical-advisory-code-execution-by-viewing-resource-files-in-net-reflector/

I had also reported the same vulnerability in Telerik justDecompile and JetBrains dotPeek:



Relevant tweets about this:

MS 2018 Q4 – Top 5 Bounty Hunter for 2 RCEs in SharePoint Online

I was amongst top 5 bounty hunters in MS Q4 2018: https://blogs.technet.microsoft.com/msrc/2018/07/26/recognizing-q4-top-5-bounty-hunters/

Although I am not doing active bug bounty hunting at the moment, this was a great experience. I got this prize because of reporting two RCEs in SharePoint Online.

One of the RCEs was patched in MS July 2018 patch (CVE-2018-8284) and this was an interesting screenshot:

I did not get any prize for CVE-2018-8300 which was another RCE in SharePoint using the resource files (the issue was similar to a bug reported in another MS project that I was part of its paid engagement).

Yahoo bug bounty program – LFI reported and patched!


Yahoo! bug bounty program is still young and I believe that they have been pushed to do this when they were not ready for it! Many of their web pages had not even been scanned by an automatic commercial scanner when they started running their bounty program and they will definitely lose profit on that. I guess this is the price that they are willing to pay to satisfy their customers. Other high profile companies that still do not care about an appropriate bug bounty program for their websites and their applications should rethink now! Thanks to the available bug bounty programs, the number of bounty hunters is now increased and the power of this community is growing everyday and this will save time and money for any company in the long run.

I remember the time that you could find at least one XSS in less than an hour and a SQLi in a few hours in Yahoo websites (http://www.xssed.com/pagerank). Now their bug bounty program is going to change this situation and the customers who have migrated to Gmail to have more security (I personally did that), may still use their Yahoo account!

However, it is still too early to say anything about Yahoo bug bounty program and we have to wait a few months to see their stable policy. There are security researchers who have reported more than 20 XSS issues to Yahoo now and they are waiting for their rewards! It is very interesting to see how much Yahoo will pay for any particular issue and how they are going to categorize the issues to pay from $150 for low risk issues to $15,000 for high risk issues. More info about Yahoo bug bounty programs from Ramses Martinez -Director, Yahoo Paranoids-: http://yahoodevelopers.tumblr.com/post/62953984019/so-im-the-guy-who-sent-the-t-shirt-out-as-a-thank-you

Now, I am going to share my experience in reporting a critical issue to Yahoo just for future reference (I am not going to talk about the XSS issues that I have reported to them).

LFI gave me RCE on “advertiser.yahoo.com” server!

I found a LFI issue in the following URL (it gives me the 404-error now!):


Interestingly, some of the users of this server had already left Yahoo a while ago but their user was still there! But this was not my concern; finding this issue was too easy and minimum skills were needed. However, exploitation was tricky as I could not find the log-files path on these Yahoo FreeBSD servers. I reported the issue to Yahoo at this point but I wanted to prove that this is a highly critical issue. So I searched in Google and by using try and error, I finally managed to find the log-file that I was looking for: “/home/y/logs/yapache/error”. Then, I just had to create an error! I sent a GET request with spaces in the request to cause 400-error-status and log my backdoor inside the log-file:

GET /<? passthru($_GET[cmd]) ?> HTTP/1.1

And now I could execute any commands on the server:



I ran a few commands (no network commands) and looked at the content of some PHP files but as I was not sure if I am allowed to continue, I stopped. Ramses Martinez (Director, Yahoo! Security Team) allowed me later to download the web files in order to find more vulnerabilities but when I looked into it the day after, the issue was fixed and it was too little too late to complete my glory ;) they were quite quick to address this issue as soon as they saw my email at the weekend.

I wish there was a policy that could tell me what I am allowed to do when I have RCE on the server in a bug bounty program. I did not even try to look at the sensitive files that could contain credentials such as database passwords as I was not sure about the legal side of my testing.


Fri, Oct 4, 2013 at 11:13 PM: Initial report of LFI to Yahoo

Sat, Oct 5, 2013 at 12:47 AM: LFI converted to RCE reported to Yahoo

Sun, Oct 6, 2013 at 6:19 PM: First contact from Yahoo directly from Ramses Martinez

Mon, Oct 7, 2013 at 3:16 AM: I have been informed that this issue plus other XSS issues that I had reported have been patched.


Ramses’ response: “Please keep in mind that we announced the program going live on 10/30 and we’re not fully operational. Which means we are still working out a few issues. Until that time our response could vary depending on submissions and workload. Work with me here and I’ll make sure that you are taken care of once the program is in place.”

I will update this section as soon as I get any news from Yahoo. The prize is between $150 to $15K based on the risk rating (impact x likelihood [?]) and I am wondering how much they are going to pay for this LFI to RCE issue.