Exploiting Textpattern
- by Vince
-
in Blog
-
Hits: 1653
"Textpattern is a free and open-source content management system based on PHP and MySQL, originally developed by Dean Allen and now developed by Team Textpattern. While it is often listed among weblogging tools, its aim is to be a general-purpose content management system suitable for deployment in many contexts."
As far as content management systems go, it's fairly simple to install and it's also quite intuitive if you've used any of the other systems out there. That said, it has a lot of little bugs that make me wonder what could be found if you really did a deep dive. Everything I found is on the authenticated side but some of it can impact the unauthenticated visitor.
We start a new Article with some XSS:
When we publish and visit the site:
"That's not a bug, that's a feature..."
I can appreciate being able to upload ANY kind of a file but dropping a shell on this system is as easy as:
When we hit the upload button:
On the system, if we look at the root folder, we find /file:
When we browse to our shell:
With our handler setup:
Again, that could be a feature but it's an awesome feature to find during a pentest.
We also have the ability to upload images which seems to have a little more control on what's going on. We point to our misidentified shell:
We choose upload:
We successfully upload our fake image. When we look in the file system:
We find our file in the /images folder but it's been renamed. That's going to prevent up from abusing this attack vector unless we discover a method for renaming the file.
I should also point out that I've setup this file with the most basic bypass technique:
Without it, we get the following:
This next one is most definitely a feature but there are times when people ask -- what's the big deal if my website gets hacked? The ability to introduce outside code to your visitors could be bad for your brand.
In the UI, we have the ability to add custom URLs to our site:
These links appear at the bottom of the page:
We've moved off of the Textpattern site but we've executed unwanted code on the client side because we had control of the CMS. Again, not a bug, just making a point. I'll drive that point home at the end of this post.
This next one is interesting because it is a bug but it only impacts one side of a two-sided coin.
We have the comment section for the article, we insert XSS into the comment:
On the admin side, we find:
But when we dig into it:
We see that it's actually been sanitized. However, if we remove that sanitized XSS from the comment field and add it back properly:
We save it.
Now when we move back to the visitor side of the site, the code executes:
I'm not really sure why one side doesn't allow it but the other side does.
I was teaching a class the other day and I talked about XSS but I intentionally neglected to mention BeEF. I think it's enough to explain that XSS can be dangerous without showing a tool that has no real good intention. That said, even I refer to XSS as being fairly benign -- until it's not, like with BeEF.
We insert our hook:
And now when the attack occurs, we have the browser connected to the BeEF console.
I'm not sure if BeEF is still being maintained but most of the functionality no longer works or works well. You can still do bad things with it though.
Circling back on Textpattern -- no real harm can come from the visitor side of the page. BeEF aside, the XSS can't be used for session hijacking or CSRF, as far as I can tell. I tried brute forcing the login with Hydra with little success. So while it's got bugs, you have to get a login to take advantage of them.