- [Yuhao Weng] Hello, everyone.
It is a great honor to present at DefCon.
Welcome to our presentation.
Don't Dare to Exploit
An Attack Surface Tour of SharePoint Server.
It is presented by myself, Yuhao Weng of Sangfor,
Steven Seeley of Qihoo 360, and Zhiniang Peng of Sangfor.
Let me introduce ourselves at first.
Yuhao Weng who is a web security researcher of Sangfor
and also a CTF player of Team Kap0k.
Steven Seeley is a Security Researcher of Qihoo 360,
and he is a very good trainer.
Zhiniang Peng is the Principle Security Researcher
of Sangfor. Let's begin.
The agenda we will be talk about is introduction
to SharePoint Server, Exploiting Server-side,
Exploiting Client-side and examples,
and a conclusion.
SharePoint Server really doesn't need an introduction.
It's a part Of Office 365 products.
It is one of the most popular, trusted
Content Management Systems that we have today.
It has online version hosted by Microsoft Azure
and open version 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 similar with it
but many schools and institutions like it, in fact.
This is a example of what SharePoint server
will look like in 2019.
This is a default communication site.
It look very up-to-date and very professional.
But hiding behind all of that
is a lot of issues that don't necessarily have
buttons or earlier tools.
We're going to exploit a lot of that in this present day.
With a introduction to SharePoint Server,
we can talk about the structure,
the key difference, design weakness
and AddAndCustomizePages default danger.
With the SharePoint structures is site admin
who can manage the different sites
and they can access the admin panel,
which has global communities settings
that can impart multiple sites.
Or you can deploy a new web parts those of features.
So is really a powerful position.
To be honest,
we have not fully explore the admin panel,
but I do believe,
there is the ability to upload regular files
on the server and secure the code, anyway.
Then this is known as the site owner,
and this is the regular permissions
that given by most users.
So if a new user is created
they have site owner permissions
because they can create their own site.
If they are just site viewer,
they cannot do anything
other than just viewing the page.
They can change any settings
and waste my site
so seen as we lack of my space or something.
They can create their own page
and they can look on there and do what they like
but they cannot use their site to set other sites.
There are other securities involved.
The key difference of SharePoint
and some popular open source competitor
would be this.
As I said it before,
this ability to create a site.
In the SharePoint eyes site is a new structure.
It has a new physical folder on the file system.
Then are new virtual directory is created
and point to that folder on file system.
Is logged on different path is different application
messed up site will not create a new folder
just a virtual one
and they can upload page in their site
as well as our security file.
Those other script cannot access other site content,
which is why Microsoft demo is safe
to be able to upload server script code,
on your site, because it means that our script,
we cannot access content on another site
of other admin site.
where lots of other dangerous things can be done.
Users can upload a custom page like a conversation,
and there are several different authentication measures
like NTLM, Form Based Authentication, and so on.
It design weakness of SharePoint is the ability
to use an arbitrary file with vulnerability
that can be leveraged to achieved remote code execution,
because it's possible to load the web.config file,
which can contain the validation key
or ViewState deserialization,
which can be used to generate a particular ViewState,
executes and eventually command again the application.
I know some other researcher
have talked about this before,
and this is something that I told them
as a default site of SharePoint.
I'm not exactly sure why they have decide that is generate
use a randomized config key in the webconfig file.
Because it's possible to generate config key
without using phase one.
Like the past of CVE-2020-0688.
But I'm not sure exactly
why SharePoint doesn't use that particular feature.
I believe that there are some shared code in SharePoint
that require the validation key to be started
in the webconfig file. I not very sure.
But regardless if a file disclosure vulnerability
is file in SharePoint,
it means that you have an arbitrary command execution.
The AddAndCustomizePages default danger.
Other permission rather is allowing user with this privilege
of site owner rather to upload page on that site.
So this also work on server online (indistinct),
but it should be enabled by other admin
in SharePoint Online.
It gets dangerous because users can upload also aspx page
which can contain client-side script
along with a server-side asp.net controls.
Those are known as site pages.
The control are filtered by an allow lists
that is a defined in the web.config.
So you can just upload what type of control you want.
And those controls will be the deserialized using xaml.
That several evil payloads used in the past
with XamlReader.Load.
But those payloads don't work here.
We can adjust deserialized what type of payload we want
and get the code execution in that way.
Users can also not upload inline asp.net script.
It will not work because compilation is never,
you cannot run a compiler code on the server.
Additionally, the asp.net server-side include
are also blocked.
However, a combination of the allowed server-side controls
in Java script can be quite problematic.
And we will talk about several vulnerabilities
that are raised by this.
Looking at the table site page,
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 page is opposite.
They are created by system or installation.
They are only file systems.
They are compiled and they are trusted.
Those files will get compiled and secured when accessed.
Now for the server side.
We're going to briefly discuss the attack service.
So using things like a Bypass SPPageParseFilter Check,
Server Side Request Forgery,
XML Parsing will give you some exploitation examples.
Bypass SPPageParseFilter Check.
SPPageParseFilter overrided the page parse filter.
It doesn't check files in file system
enter directory directly,
but check files in database
if they then only save controls
and without server side included,
In addition, this page is copied from Look for Escape.
We want to know what a safe control is actually make out of.
The load class is System.Web.UI.Control class.
And so every ASP.net control is taken from it.
And to work out what classes
can be used for XAML deserialization
the controls that are marked as safe in web.config file.
So here is an example,
that's two different the controls.
The first one is actually a namespace,
System.Web.UI namespace.
And all type under that namespace are safe.
Then you have another
that has the System.Web.UI.WebControls namespace.
A particular type, SQLDataSource,
that is marked as false, it is safe.
By the way,
if it is inside safe control tag
and don't special save, it is safe.
Let's think if a control extends from unsafe control.
Is it safe?
Yes, actually.
Examples.
If we look into the web.config file
and we see the SqlDataSource
it is defined as an unsafe control.
But as it turned out,
that is a particular class called SPSqlDataSource
that is taken from SqlDataSource.
This particular control is not found from web.config
It was possible to reach a SqlConnection.Open sink.
Attacker can control the connection string properties,
and it can be used to attack the client drivers
on the server itself.
We saw this earlier research is interesting because
not many people sat it down and look at into attacking
Sql drivers on client's side.
But overall mySQL driver is intuitive.
If you can connect to a malicious, mySQL server,
then the local server can send back a request
for a local file.
This has been public knowledge that since April 2nd, 2018.
I do know that this is by design the features of mySQL.
If you control the connection stream in most application,
the connection string is not controlled.
But not SharePoint.
Here is an example of a payload.
You can see here that the connection string driver
equals mySQL, then the server to the attack servers, port,
and database, name, username and password.
But when you, basically here,
you can see a SelectCommand select * from users.
We need a SelectCommand
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 it need a mySQL driver in the time keeper servers.
(silence)
And the SPSqlDataSource file disclosure bug
had a patch bypass.
It was interesting because this particular bypass
was a time of check time of use
in the way that they check the connection string.
To be honest,
we never tested this patch bypass
we just reviewed the patch quickly
and seeing it was vulnerable.
They added a check of the connection string.
And this was the method called CheckConnectionString.
It will get the ConnectionString
and call IsAllowedOdbcDriver.
Let's check it.
The first string it look out
is a dsn in the ConnectionStrings.
Then you will look out the dsn
and find the particular driver,
out of the dsn.
And if that equal to SQL server driver,
that's the trustee SQL server then it will be allowed.
But if you look at the implementation
of the SqlConnection.Open
it look for either, dsn or driver property,
whichever is set first it used.
We can exploit this for TOCTOU used
by providing a dsn property after the driver.
The Impact, again, is RCE.
But we need to know the other
existing dsn only target systems
that use SQL servers.
At the time we didn't spend too much time
on these particular vulnerabilities.
But we're saying there is a way to leave the dsn.
Here is our port.
You can see that way using PowerShell command line.
Add-OdbcDsn which will create dsl on the systems
using SQL servers.
When the Add-OdbcDsn here contain equal POC
as long as the dsl is in here,
then it will be traded as trustee.
But then when the SQL connection is made
is set, the driver property first and then set it,
You see mySQL? Use mySQL driver.
Then what other properties?
And then it ignored the dsl
because there is no a particular property
for that particular drivers is a SQL server.
And the driver, server, port, database
and then trigger it again.
So we can continue to reveal the web.config file
and get remote code executions.
Then look at the next example, CVE-2021-28450.
It is an RE DOS file
and count for another unsafe control.
We find this control and then RegularExpressionValidator.
It look like a link tool as validation.
That is unsigned class InputFormRegularExpressionValidator
is taken from it, which is safe.
Okay, let's check this normal example.
As we see, we can control the validation expression
and validationvalue.
Anything else?
When we look at the code and we found out 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 calculate.
What will happen if we insert a malicious expressions?
Think about this expression and our input is 128*a+!.
It will run very, very slowed
because the first part of this expression
will be executed repeatedly.
It will keep measuring,
it will keep measuring until run out of time.
Here is the chart about how many steps will be executed.
When the number of a is ingest,
we can see that when we input 20a,
it will learn more than 100,000 steps to try to match.
And we will attack it with 128a.
And we will, we can set a large count timeout value
so the script don't get close quickly.
So we tested against SharePoint online and make it died
after sending 50 requests.
You don't need to send requests at the same time.
So I send it slowly and see whether it dies out.
And you will restart after some minutes,
maybe 20 minutes 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 where they changed password.
And in this time we cannot find
any class is taken from them.
Let us find it ourselves.
Why are those controls blocked?
Why those particular controls?
After doing a bit of research and investigation,
we found that those people controls
categories of a file methods
in the lower controlled class.
They changed password and create and create user wizard.
It taken from web controls,
which has open file methods,
Of course,
there was an additional control the password recovery,
which was not block any web.config.
We could use password recovery control to email ourselves,
our own password, coupled with a file of our choice.
We're seeing is designed to see that email template file.
So email address were assigned to the account
using the phone based authentication,
which was the default authentication for SharePoint online.
They will allow yours to email ourself
with the web.config file and get us here again.
But the attacker also need to link the membership provider
and we can follow it by the session cookie
and outgoing SMTP server needed to be configured
on the target system as well,
so that we can receive email of web.config file.
This is what the payload look like.
All we have to do is specify the body file name,
and that equals a particular part to web.config.
We load a proof of consent for that one and put here.
Email results here.
We can receive machine key in our mailbox.
Here we use both to capture it.
Then let's (indistinct) control,
and we will talk a little bit about server-side include.
Server-side include are directives that place in html page
and evaluated on these server
while the page are being served.
Asp.net is convenient to include web.config
to steal your machine key.
But it is blocked by default on most case, at least.
When you were to make asp as page only server,
it will try to do it included for web.config.
It is not allowed because asp page filter,
is enabled by default and you block the encoder
SSI site page and doesn't allow it.
But as it turned out,
there was a way to bypass that over this.
Let's see this example.
Here is a famous method parser control,
which was introduced in Look For Escape presentation,
and it was in many environments where the SharePoint.
It will parse strings to control the class.
And it has the ability to bypass the SPPageParserFilter.
If for the second parameter to the past control is true,
to SPPageParserFilter will be ignored.
In that way we could get an inquiry going.
So we want to find a method in which we'll call the parser
control with a generic value.
The data form will be part of controlling.
It has a particular measure called CreateChildControls.
It is called when the other control exists on that
particular control.
And inside this function,
you call ParseControl.
It is a good target if we can met the flag too,
and the flag generated from,
verify SPD control markup.
We have to satisfy to some validation
to lose this call in a dangerous way.
It has to be valid.
Okay, first of all, it need to be valid xml so we can,
so we cannot register with this
because it is not a valuable xml format.
We also need to have runat=server,
or it will be seen as client script
and want to pass the verify control.
It also need to be a safe controlled.
It can contain things like objected the shows controlled,
which is a famous gathered.
We create a panel that with
use server-side inquiry instead,
as you can see.
It use (indistinct)
Don't need to use any unsafe control
or objectdatasource.
And then we equaled the web.config file
of that particular site.
And that it will leak the validation key
and give us remote code execution back.
We've got a video demonstration here.
(silence)
Let's continue this presentation.
Next, we will discuss another type of attack.
Server-side request forgery.
Let's look at the vulnerable code example.
This server will retrieve the url we control.
And park the url into a request object.
Send the request and return the response.
We can set the url to arbitrary address
like web evaluator, localhost, fileserver or other
interesting http servers.
We found many SSI vulnerabilities
in SharePoint and will be discussed later.
We found a very simple function CallOLS.
If passed the parameter URL of the mentioned SafeCreate
to get a request option.
And return the result of the request.
It look very similar to the vulnerability example
mentioned earlier.
Here, it can be considered
as a wrapper of WebRequest.Create.
If we can control this parameters
here is a classical SSI vulnerability.
At first we need to try
whether we can access this method.
Through the research of official documentation online
we found out that when method is marked
as ClientCallableMethod it means that
we can call you with an ftp request.
The general format is
/SP/NameSpace.ClientCallableType.ClientCallableMethod.
So the path here should be
/SP.HashtagStoreManager.CallOLS.
Note that here is SP not SharePoint.
As mentioned in there.
And we can control all the parameters
of the ClientCallableMethod function.
So it's very simple to write a proof of concern.
Just add the url pattern for it.
Then when it follows the server to our address
and return the result of url request.
Actually, there are more things
about the server-side request forgery.
But for some reason we cannot talk in this time.
So the next thing we will talk is XML Parsing.
Xml is a very popular markup language.
First vendor in the late 1990s
and adopted by countless software projects.
It is used for configuration files, document format,
image format, and the network protocol.
And it is so popular that any problem about it
will bring catastrophic result.
In the process of parsing external entity
the xml parser can query various network protocols,
and survive like a dos, ftp, http, smb, and so on.
According to this protocol
specified in the EUIO
external entities are very useful for
creating generic levelers in documentations.
So that any change admitted to the levelers results
are automatically update in the document.
According to official documents
for lower versions of the .NET network.
When reading xml test container external entities
will be automatically parsed.
However, when dealing with the external entities
many attack can be launched against the application.
Those attacks include the disclosure of local system files.
Which may contain sensitive data such as password,
and private user data
or the use of network SSL certificates
various programs to manipulate internet applications
by combining those attacks with other malicious code.
The scope of this attack can be extended
to server interruption and even eventually code execution,
depending on the content of those attacks.
We call these attack types xml external entity attack.
We also share a simple vulnerability code example.
The code snippet show the classical
xmldocument.load xml method.
It will receive an xml container
parsing to xml document object
The dtt definition will be executed when parsing.
There are also many ways to pase xml.
Like XPathDocument, DataSet.LoadXML, and so on.
In order to decode the problem caused by SSE.
Microsoft recommends that users use XML evaluator
to evaluate xml test before loading.
And prohibit the parsing of external entity.
Or upgrade to higher version of .NET framework
which will not parse external entity by default.
But we will check SharePoint will follow that.
The .NET version of SharePoint that is 4.0
in SharePoint 2019.
Which means that we were likely to find
SSE vulnerability in it.
Here is our finding of SSE.
This regional vulnerability patterns can often
bring destabalized. We found unmentioned
GetPluginContent which will call xmlDocument.Loadxml.
Like our examples it will read the container
in the public in file and parse it as xml container.
Okay, let's take a quick look at the call state,
which appears to be accessible.
We need to analyze the method.
First, it will traverse all files in
/_catalogs/wp directory.
We need to create a file.
The files here includes all files in database
and file system because it is SPFile
which is another of the file object by SharedPoint.
Then looking for the file that the send filename
as the parameter we set.
Then its content is passed into Loadxml.
Including the visual file in the database is good news.
Users now have permissions to upload
such files on their website.
If it can only load the files in the file systems
we will not be able to do anything.
So therefore the first step in exploiting the vulnerability
is to upload a xxe file. We are sure it is
xxe.webpart which contain xxe payload.
Note that the file need to end with a .webpart.
But how to make the server load this file?
Let's go back to the call state and take a closer look
at the function in the live post.
We notice that he has a special attribute ClientCallable.
What does it contain here?
It is similar to ClientCallableMethod
that we mentioned earlier but it is not the same.
It means that we can call it using client-side
SharePoint Object Model API.
CSOM stand for SharePoint client object model
and is used to insert, update, delete,
and retrieve data in SharePoint.
Microsoft provided various client object model like
Javascript models, SharePoint REST API, SharePoint
.NET client object model.
Then we will not use the last one, SharePoint .NET
client object model.
When we use debug tools to debug it
we found that every ClientCallable function
has a paired remote function.
The calling process starts from the client code passes
so that the remote method of the same name.
And then send the data to the server so xml format.
The server parser the xml and find the policy method
of the corresponding method invoke state method.
And finally fall to the ClientCallable method
to complete the method called.
Now, we can start writing the second part of the exploiting.
(indistinct) relayed there of CSOM.
And we need to pass this server url
and the user's credential to gain a client contents.
Then use the contents to load the plugin file
that we created before.
And here, we set it to xxe.
Finally, we should call ExecuteQuery
to package all the data and send the request.
Which can trigger GetPlugin method as we want it.
After testing this vulnerability
that can also work on SharePoint Online.
An example of loading window in SharePoint Online
and our demo of proof of concern is here.
(silence)
But if you notice that we called it as xxe
instead of remote call execution.
Because it is only 01%& remote call execution.
We found that that & character in the web.cofig.
According to the same task of the external entity.
It will be considered as an entity definition
but there is no specific name defined later.
This will cause parsing error and able to load
content of web.config normally.
If someone can bypass this shortcoming for
invalid remote code execution exploitation,
please share your tips with us.
Anyway, it is a real interesting
because it appeared in SharePoint client code.
Then we have discussed the security issue
of the server side.
They are often very powerful
and don't need any user intervention.
Next, we will assure that we have a user intervention.
A victim will open the url he send in his java server.
How to achieve an account takeover attack?
Server has a variety of user authentication methods,
including NTLM, fba, Oauth and so on.
So, let's check the fba.
Form-based authentication.
Here is the login form and fba is a
form-based identity authentication.
Httd authentication is passed to SharePoint server
will set a cookie for users, rtFa & FedAuth.
If we obtain the cookie of other users
we can forge user identities.
But the cookies have activity only specs
so we can't use java script to call it to steal it directly.
And users with the same cookies can access both
admin panel and site collection
if they have enough privilege.
However, as we talked before
we don't just own the javascript.
We will introduce a vulnerability
that steal cookies stored parameter validly.
For this vulnerability we need to show the problem first.
The addition to the request header.
Where does that cookie exist? Can we get it?
In Microsoft documentation a special value is recorded.
IIS server variables provide information about the server,
the connection with the client,
and the current request on the connection.
IIS server variables are not the same
as environment variables.
Here is the value that we need, http cookie.
With any cookie string that was encoded with the request.
Okay, we find another page to get cookie
but it is a server values.
We need to put it embed with the page.
When reading some sever-side codes
we noticed that there is a special syntax
called ParameterBinding,
a resource can be bound to parameter
value in the current vendor xsl style sheet.
The ParameterBinding element encoded are
location attribute that specify resource time.
The same task for this element is similar
to the SPResourceBinding expression syntax.
The location value is expressed as a function.
We can use the location attribute to specify the values for
server-side query strings, server values,
webpart properties, control ids and so on.
So, we can look at this process.
When we send a request to the poc page
the server will stop our cookie in http_cookie
slow ParameterBinding and bind it
into DataFormWebPart value.
And finally display it in page.
So here is the proof of consent.
We render the cookie back to the xsl value.
Therefore, we have the ability to bring the cookies
to the client-side page.
Then we can we can read the page script
without restrictions.
Use XMLHttpRequest to fetch the value of cookie
and send it to our servers.
And then check the servers request.
You can see that all the cookies are sent contains
rtFA and FedAuth that you can use to access
the site of victims.
So here is our conclusion of today's presentation.
The about all the vulnerabilities disclosure in our sharing.
From the server to the client we have studied many
interesting traits of SharePoint and most of the
vulnerabilities are based on the permission we have
to upload page.
We've been able to find many vulnerabilities in SharePoint
because of these virtual (indistinct)
When you give users more permission,
your system is more dangerous.
User created content that can interact with server-side
controls has the potential to cause some trusted violence.
It is hard to build a strong enough filter
to protect this instance.
And multiple API give users different access methods
and give an attacker a large attack surface
for discovery tool.
So, this is the end of our presentation.
Thank you for listening.
Feel free to ask any questions.