Enable streamer mode.
Do we want that disabled?
I think you want it enabled, don't you?
That was my assumption.
Alright, well we should be going live.
Now we're live.
Okay, let's push that recording button.
Alright, chat!
If anybody is hanging out watching TrackOne,
feel free to start talking in the TrackOne channel on Discord.
You're also welcome to start giving us some questions over in the TrackOne live Q&A channel.
In the meantime, let's introduce our guests for right now.
We have Olek and we have Poontester.
I'm sure you two will come up with better ways to explain how to pronounce your names.
But thank you very much for joining us today.
Give us the name of the talk that you did,
and we'll start asking you some silly questions about it.
Okay, so the talk was Room for Escape,
Scribbling Outside the Lines of Template Security.
A talk around content management systems,
and in particular the template engines used in these systems,
and how we were able to break out of the sandboxes that they put in place.
If you have any questions about the talk or anything else,
maybe we can help you.
Just feel free to ask anything.
How do you like your handle pronounced?
I pronounce it Poontester.
Poontester?
I don't know if that's better.
I think that we just entered into one of the mighty arguments in the hacker world,
if it's Pwn or Pwn.
So we're going to go with Pwn because that sounds a little bit better.
So Olek, go ahead and give your little bit of an intro.
About myself?
Yeah, we'll click over to you.
I'm a security researcher for already more than 10 years,
and working for Micro Focus Spotify.
And I'm happy to have a chance to work with Pwntester for a couple of years already,
and it's our fourth shared research.
And I'm happy with these results,
and I hope to get something similar in the next years.
Absolutely.
I will retire.
Yeah, so that's a good segue, actually,
to talk while we're waiting for people to come up with some good questions for you.
Tell us a little bit about some of the...
This is definitely not your first talk here at DEF CON,
so just briefly give us some background on where you came from
and what the earlier talks were,
so that people know how to reach back and find you in the archives.
And then maybe touch on,
how does this one feel different than the other talks that you've done?
Okay, so I think the first one that we did together was Friday the 13th, JSON attacks.
No, actually it was...
Sorry, it was JNDI injections.
It was the first one.
Did we present that at DEF CON or just at Black Hat?
Just at Black Hat, you're right.
So the first one that we presented together was the JNDI injection.
I think the full title was something like JNDI injection...
How was that?
Dreamland to RC something.
Yeah, no, like a trip into RC.
I don't know. I don't remember the title anymore.
That was around JNDI injection in Java world of ecosystems,
which was then used for many of the visualization gadgets.
So that was a good one.
And then before that one, I presented at DEF CON,
one with Denis Cruz and AFPang,
that was called resting in your laurels will get you pwned or pwned.
Yeah, that was a nice one.
So the first one that we did together was this about JNDI injection attacks.
Then the first one that when we presented at DEF CON
and we had to drink our shots as newbie speakers
was this one about JSON attacks, JSON visualization attacks.
Gotcha.
And then last year we presented SSL Wars, the token menace,
where we presented an attack on some implementation in Microsoft stacks
that was flowing in .NET framework.
And now this year we repeat again as a team with this one.
Excellent. We really appreciate that you both came out to do that.
You two, as we're waiting for people to jump in with more questions,
you did present me with one that I'm going to sneakily slide in here
as if somebody else asked it.
The vulnerabilities that you disclose all seem to require
that the attacker have user-level access to the system.
Is that true?
Is that a hurdle for most...
Oh, see, now I'm talking over you. So your turn, Hugo.
Okay, I think it's mostly true.
It still depends on applications, on configuration,
on specific configuration.
But to be able to perform such attacks,
attackers should be able to create or at least modify some template.
And in most cases, it's at least user-level account.
For SharePoint, it's just user-level account.
It's default configuration and just user-level account.
Any user in default configuration can do this.
For other applications, it still depends.
Sometimes it's just user-level.
Sometimes you need to be like writer or some other roles,
more powerful roles.
Sometimes even administrator.
So one requirement for our attack,
attackers should be able to manage these templates
or ISPX pages in case of SharePoint.
Okay, so maybe not.
The minimum is just they have to be able to deal with the SharePoint side.
They have to be able to control that.
But it's not necessarily that...
So for SharePoint, it's a bit simpler.
Any user can have access to own private site and can manage it.
It's your site.
And you can use at least this site for performing attacks.
For other applications, yes.
It depends on configuration, depends on permission for specific projects,
for specific sub-sites and other things.
Okay.
So I was going to add that our assumption in this talk
is that we were able or the attacker were able to control the templates.
And then our research was around breaking outside of those sandboxes.
So in a similar way that we may present something around breaking mitigations
for buffer overflows, but our research was not how to find those buffer overflows
in the first place.
So I'm saying that because apart from being able to control the contents
of the template, different vectors may include things
like server-side template injection, or maybe, for example,
if there is a cross-site scripting vulnerability in that page,
you can use that to fool a victim into submit a malicious template
on your behalf.
Or maybe there is a cross-site request for you that you cannot use
in order to manipulate or modify the template content.
So we didn't really care about how you were able to get access to the content.
It may be because you have access to, like Alexander explained,
it's the normal case, for example, in things like SharePoint
or a wiki, for example, where you can edit your own articles
and things like that.
But maybe in other systems, some of the ones that we reported,
like Office, for example, they were vulnerable to server-side
template injection.
And for example, in some cases, we were able to request trial accounts
in content management systems that were deployed on the cloud,
like in software-as-a-service architectures.
And with those trial accounts, we were able to hone those servers
and compromise the underlying servers.
So in a big way, you've given us another step in our chain,
another tool to escalate how much damage we can do once we have a foothold.
Yeah, exactly.
Excellent.
What level of access were you using to get that remote code execution?
Were you just a regular user and able to escalate that far?
So in some cases, like Alexander explained for SharePoint,
just having an account in SharePoint, like a regular user account,
allows you to create your own site.
And then you can control the template or the ASPX page,
in this case for SharePoint.
And then you can use that to get remote code execution
on the underlying server.
In other cases, like XWiki, just a regular user as well.
Other systems, like for example, Atlassian Confluence,
you were required to be administrator in order to edit a template.
So in those systems, either you are an administrator,
so it's kind of more like an insider attack,
or maybe those systems are vulnerable, as I explained before,
you find a cross-site scripting vulnerability,
and you can escalate from cross-site scripting
to remote code execution by being able to fool the victim
to submit or modify a template on your behalf.
Okay, so can you give us a little bit of background
on how you came upon this type of research?
What was your entry point into doing this attack?
It's not easy to answer.
It's as usual, when you have some target that allows you something,
and you think, wow, it's a lot of things for attackers,
and it starts the game.
You try to use one thing to bypass something.
For example, SharePoint, it allows you to upload ASPX pages.
So the first thing, why we cannot put only the code there
and execute code there?
No, we cannot. Why we cannot?
And game starts.
And it's not only SharePoint.
There are a lot of such server or services that allows you
to define some templates for dynamic content,
and actually you can access getters.
You can access some methods.
You can access some objects.
Why we cannot abuse them?
Let's try. Let's see what we can do.
What we can do further with all this stuff.
And it starts our research investigation,
and at the end, we have such results.
You chained it down.
I'm on mute.
So you pushed it down that direction. That makes sense.
And I'm assuming then we're kind of talking to a general mindset
when you're doing your normal day-to-day work.
You find something that's a little funny,
and you just can't let it go.
I mean, this is that greater question about,
what does it take to be a hacker?
It's always nice to hear people who are out there in the world
doing these presentations, doing this research,
talk to the rest of us who are getting our feet wet
in the world of web application security
or whatever your niche is.
How do the rest of you folks who are getting all of the success,
doing these cool presentations and research,
how do you approach these?
How do you know when you have something cool?
So in my case, and continuing Alexander's response,
I guess that I started this research because Oleg came to me
and said, like, okay, I found these four different ways
of breaking the server in safe mode.
For that time, I mean, we found a lot of more.
So he said, like, maybe if we also look at the Java side,
we get something interesting that can be interesting,
like a full research, like something that is more self-contained somehow.
And then he told me, like, can you take a look
at some of the most popular engines in Java?
And when I was there, I was like, okay, let's see.
Before I started looking at the implementation of those engines
and do, like, code review and things like that,
it was like, okay, I'm here. I get access.
I assume that I get access to a template.
What can I do now? What objects are available?
So I started looking and inspecting the template context
by debugging the applications and setting some breakpoints.
And then I was surprised that I was able to access
thousands of objects that were non-intentionally exposed.
They were, like, they're indirectly exposed by other objects.
And with that big amount of attack surface,
it was like, this is going to be easy to find something
that I can use to get remote code execution.
That was the case.
And then as a second part of the research,
we started looking at the implementation of those libraries.
And then we found some specific flaws in the implementation.
The way they were checking block lists, for example,
or gaps on those block lists or things like that,
that I explained in the talk.
That was your entry.
You, all of a sudden, you're like, I have something.
And then you spent a significant amount of time
testing the boundaries of the thing that you had
until you worked your way towards where we are now.
That makes sense.
It's always good to hear from you folks,
kind of where you're coming from on that.
So I saw a few different content management systems
that you looked at.
And I imagine at some point, you just kind of run out of time
to keep checking things.
Do you think that there are still more out there
that people could follow your techniques
and do the same kind of thing to find vulnerabilities?
Is that also going to be an area
that you plan to continue to research?
Or are you guys kind of done with this one?
Definitely, there should be a lot of products.
We think there are a lot of products.
As you mentioned, just a couple of them are under our focus.
And actually, for example, if you're talking about SharePoint,
it is not an automated approach.
It's just manual and just to find some patterns.
And we try to show this pattern in our presentation.
And I believe there's still a lot of things to look for
in SharePoint specifically and about other content,
even not content management system.
In any other system, like maybe email servers,
if you can define a template for dynamic content
for some auto-creation emails,
it can be a starting point for your research as well.
So our purpose of our research, our presentation,
just show our patterns, our approaches and say,
hey guys, we use this and we got such results,
like 30 new vulnerabilities.
You can use the same.
It's not only for offensive side.
It's for defensive as well.
Guys, if you are developing something that go in this bucket,
you need to look on these areas to check this
because you can see what can happen.
So, of course, anybody welcome to continue this research.
About myself, I'm not sure.
I need to have some rest, vacation, couple months after that, maybe.
But usually, if you can see our talks, they are not linear.
We are jumping from one topic to another topic.
It's more interesting for me.
But I do not know, maybe.
If I still find something interesting, I will continue.
But for the next year, to be honest, it will be more difficult
because competition will be more higher.
Maybe it's better to leave this for others and try to find some new areas.
Based on all the different presentations that you two described earlier,
it seems like you two work together really well in finding these types of things.
I know some people earlier were asking,
how should somebody go about starting out research and picking out targets?
Do you have any suggestions for people on how they can start getting into the type of research field
that you two seem to do really well?
I don't think that one is easy to answer.
It's just like, at least for me, being up to date with the latest research
from other people in the community and industry.
Or maybe reading articles that are not directly related with what you do.
For example, I think that the JNDI injection that was the first one that we did together
started out of reading an article about a malware analysis.
And in that malware analysis, the malware was using some JNDI lookups.
We found that interesting. We started researching that.
And that led to the JNDI injection attack.
As part of that attack, we found some gadgets that were using setters
instead of magic methods in Java deserialization and so on.
And we found that as an entry point to the JSON deserialization attacks that we did the following year.
So sometimes one thing takes you to the next one.
Sometimes they are not even related.
Like jumping from JNDI to JSON deserialization or Mars Alert deserialization.
So sometimes just reading a lot of stuff gives you ideas.
Sometimes you just are playing with something in your regular work
and then you find something interesting and you just pull the thread and find something else.
It's just... I mean, things are not going to come to you.
You have to be actively reading, looking for things,
and then you will always find something that is interesting
and you can pull the thread and find something more.
If you just stay passive, like reading, but not asking yourself why things are working in such or such other way,
then I don't think that there is room for research.
And my suggestion is not to be focused on the results of the talk.
It's very difficult on the first year to be accepted in Black Hat or DEF CON or something like that
and produce such level of results.
I would suggest just to be focused on something, some area, what you like best
and you are passionate on that and follow for new research.
Try to understand each novel technique and maybe try own thing.
Maybe you have ideas and be passionate.
I think... I do not know. For me, it took a couple of years to get some...
If you are new, start to give your results and you can start to think about how to summarize this and present to others.
And just to start a career from Let's Talk at DEF CON, for me, it's difficult to imagine.
You need to have some background in this area and produce something new.
And for this, you need year... not years, you need time.
For somebody, it's months. For somebody, it's years.
But still, for me, it's main target, it's my passion in that areas.
Not just talk in DEF CON. DEF CON, it's results.
If you have results, you can present it in DEF CON.
If you do not have results, let's wait, let's try other direction.
But you need to like this. Without passion, it's difficult.
I love that you two said really quite different things there.
In one case, you have, hey, I was reading an article and then I thought really deep about that article.
But it seemed like it was something different from your previous research.
And then the other answer would be, I just really like this stuff and I learned everything I could about it.
So it's nice to hear the two different sides, if not the two different sides,
about how to approach a new topic and how to find something cool in it.
Which is probably why they work together so well and have had so much great research through the years.
We have very different approaches for everything.
Even research is different.
For example, I never read documentation before research.
It took more time, but I have some rules.
Do not open documentation.
Arvaro starts with documentation and can find something more quickly.
Significantly quickly.
So what did we not get to see during this presentation?
I know you've already talked about when your presentations tend to jump around a little bit.
So maybe you have the opportunity to hit more content or whatever you wanted to present during your go.
But due to time or due to not having it fully formed in your head,
what would you have liked to have put into this presentation where there was more time, more ability?
So there is a lot of content that is not in the actual talk, in the actual video.
But it's available in the white paper that we released as part of the talk.
It's simply that we were not able to fit all the content in those 40 minutes.
Apart from that, that's something that just didn't fit into the time allocated for the video.
I think that I would also like to have looked into other languages.
We just focused on .NET and Java.
And maybe for .NET, I would also have looked into other content management systems that are different from ServePoint.
Maybe, I don't know. I'm not really very familiar with .NET ecosystems.
But, for example, .NET Nuke is a potential target that we just didn't have time to look into.
I agree with Alvaro. Actually, we have more findings.
And usually, when you start to search something, you have more findings.
But you need to collect them in some topic, in some scope.
Of course, a lot of things are out of scope.
Maybe for the later research, maybe for some blog posts.
Maybe not. Maybe it's not interesting.
Something like that.
It depends. If you have, like, a two-hour talk, maybe we will include some new stuff for SharePoint.
There was some interesting stuff, because there was some playing with roles and other things.
But I think our current white paper meets the scope of what we drew before this white paper and talks.
And it's more interesting.
When you have a lot of stuff, it's not good as well, because it's very difficult to focus on something.
Even this stuff, we have two parts, .NET and Java.
It's a bit different. Java has a lot of templates and giants.
.NET has only SharePoint.
It's a bit difficult to keep focus audience for these two parts.
I think if you want to include something else, maybe it's better to have separate talk, not in this.
To build a new talk. Makes sense.
It's nice to be able to isolate down.
We always keep some sprouts.
How do you say that in English?
Something like seed sprouts for the next talk.
Something that looks promising.
Maybe it's a new way into a new road that can lead to something.
That's also something that we normally don't include in the talks.
You're never going to retire from this, are you?
There's always going to be something new and interesting to do a talk on.
It's difficult because competition from year to year, it's more harder and harder.
A lot of new guys and a lot of old guys.
It's not easy.
Let's hope that we will have motivation and time and resources for new researchers.
We like this.
Life will show.
We have about five minutes left in our scheduled time here.
What's your call to action?
Where would you direct people to keep poking at this?
Or what's something that, as you were hunting through all of this, that you were like,
Oh, this would be something that I want somebody to look at, but maybe I don't have the background or the time.
What's the gap?
There's your question out of the blue.
Yeah, so as I said, we didn't look at other languages.
I know there is a lot of research around server-side template injection in JavaScript and Python.
But yeah, so those are sandboxes as well.
And probably those sandboxes need to be bypassed.
A good direction for people wanting to look into this area of research is looking at how these other languages implement sandboxes and maybe try to find a way to break them.
I agree with Edovara. Actually, we have two different .NET and Java languages.
I think if we found something similar in these two languages, we can assume that many others are affected.
It's not a problem in languages, it's a problem in design.
Actually, it's very difficult to implement good sandboxes for these cases, I believe.
It's very difficult.
There are a lot of potential areas and we try to highlight the most obvious of them.
And I think it's a good idea to look in any places, in any languages, in any system, in any other place.
That makes sense. Well, thank you for that.
If you would be so kind, you can toss us in probably the TrackOne channel would be a good place for this.
Any place that folks can contact you later.
Since this is a new format, we can actually put down if there's an email address or a Twitter profile or a GitHub.
You could post that in that channel.
I don't know if you can hear me.
I can, as a matter of fact.
Oh, maybe.
I can hear you.
We might have just lost him.
You're back.
Yeah, I'm back. I lost all of you.
Well, welcome back.
So we were just chatting about if there is a GitHub or a Twitter profile or an email or something that you...
I believe you put something like that in your talk, but...
Can everybody hear me?
So my personal Twitter handle is Pontester, obviously.
And also I work for the GitHub Security Lab, where all the advisories for the different content management systems
with the details about how we were able to exploit them or break their sandboxes are being published.
Some of them have been published already.
Some of them are still to be published.
So you may also want to follow that one.
I think it's ghsecuritylab.
Just let me...
You can type that into the TrackOne channel at your leisure.
And people can see that there.
If there's...
And that's pretty much the last of the questions I have.
I want to thank you both very much for building this presentation and taking time out of your day to come and do this QA with us.
This is what makes this community better than anything else I've ever been a part of.
So thank you very much for your efforts.
And I hope to see more from you folks in the near future.
Thank you very much for having us.
And hopefully, yeah, we can present again in DEF CON next year.
And next time in person.
Definitely.
Next time in person.
Well, I appreciate it.
Have a great rest of your day.
Enjoy the con.
And to everyone watching, you should be able to see here in the next little while the contact information show up in the TrackOne channel.
Otherwise, we will see you for the next one.
Bye, everyone.
Have a good one.
Bye-bye.