

Remote exploit found in all WooThemes - jasongill
https://gist.github.com/2523147

======
jasongill
Reposting my GitHub comment:

Thanks all for your comments. Regarding responsible disclosure, I'm aware of
the concept. I did Google around and looked on the WooThemes site for a
security notice address or similar and didn't find one. Even as a paying
subscription customer, which I have happily been for the past year, the only
way to get support is via their public forum.

That being said, this is only "half" of the equation. I have already seen
numerous hosting accounts compromised via a more malicious form of this attack
which I have not published. In fact, finding a number of sites running
WooThemes all compromised in the past 4 days via the contents of shortcode-
generator/ lead me to take a quick look through the code to try to find the
attack vector and I found this.

Note that what I found isn't even really an exploit in its current form - just
a bug which combined with a lot more work could be used to potentially cause
harm. However, since I'm already seeing WooThemes-powered sites that have been
compromised via the contents of shortcode-generator/, there is already a more
serious problem in the wild. I would hope that WooThemes is aware of that -
but again, they don't appear to have any security contact address, or any
other transparency about the security of their products to be able to find
out.

With regards to security at WooThemes, I won't comment on their attack this
week because clearly they are trying to recover from it. However, as one
commenter in HackerNews posted, "Does this look like the authors even give a
crap about security?" and with that I would tend to agree. For example, a few
days prior to their site going down, WooThemes alerted their customers to
update their themes for a security vulnerability... via a 5am tweet:
<https://twitter.com/#!/woothemes/status/192545687051829248> "We found a minor
vulnerability in the WooFramework, which we've just fixed. Please update to
the latest version ASAP!" Not an email alert, not a blog post with details,
just a tweet.

Regarding the person who commented that this issue was already patched; that
is incorrect. This has been tested against vanilla WooThemes running the
latest version, which (according to the theme's built in updater) is 5.3.7.
The WooThemes website only lists a changelog up to version 5.3.1, released
almost 2 months ago: <http://www.woothemes.com/updates/functions-
changelog.txt>

Additionally, even if the issue is patched, my link above still works - which
means that the patch clearly isn't working or hasn't been applied to WooThemes
own servers.

The moral of this story is: WooThemes is a great company and makes a great
product, but they have grown to the point where security needs to be a real
concern. A proper channel to alert them of these issues, along with prompt and
honest email notifications of updates to their customers (free and paid), and
a publicly-accessible security/updates site (a la RedHat's RHSA system) are
all long overdue. This isn't just a jab at WooThemes either - a review of
almost any paid or free theme will surely come up with many issues like this.

Perhaps the best solution is for WordPress to add a built in update notifier
that can alert site admins when updates are available, but at this point
anything would be helpful.

Thanks again for the comments and thanks to those who posted simple patches to
correct this small issue until an official update is released.

~~~
qeorge
Regarding the changelog specifically, I found this to be quite weird:

[http://webcache.googleusercontent.com/search?q=cache:FhfL-
lo...](http://webcache.googleusercontent.com/search?q=cache:FhfL-
lo6DGYJ:www.woothemes.com/updates/functions-
changelog.txt+&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a)

(The changelog that's posted live ends at 3/06/2012. The one in Google's cache
lists changes up to 4/23, including the fix for this bug).

Hanlon's razor and all, but its odd.

------
rickmb
Now of course it was improper to reveal this before informing WooThemes, so
they can patch it and inform their users before this hole gets exploited on a
massive scale.

But just look at the code itself. Does this look like the authors even give a
crap about security? Or half decent code in general? Those 3 lines of code
alone make me cry, and it pretty much screams "potential security issue".

This kind of crap is endemic in the WordPress ecosystem, and virtually every
theme and plugin is a security hole waiting to be exploited.

Now if you're sharing your code freely that's one thing, but these guys run a
business and are asking money for this. One of their selling points, the first
on their homepage: "Solid Code Framework". Seriously.

~~~
masklinn
And one of the authors commented the issue was patched... apparently
discretely without notifying any user that they're at risk.

~~~
damncabbage
Apparently it wasn't fixed (or at least the fix hasn't been released to
customers yet): <https://gist.github.com/2523147#gistcomment-288527>

(Gist author posts a longer explanation, and mentions this as part of his
message.)

~~~
jasongill
It appears that they wrote a fix but then (the next day, I believe) had their
server troubles. During that mix-up, the file which alerts the theme that
there is an update was broken, so their patch basically hasn't "been released"
to their existing customers yet.

------
micahgoulart
You've made a bad situation worse by not revealing this first to the WooThemes
developers.

------
nbpoole
Potentially relevant: it seems like the WooThemes site was compromised
recently.

<http://www.woothemes.com/2012/04/were-alive-and-kicking/>

~~~
coenjacobs
Not related at all and the WooFramework has been updated days before all this:
<http://cl.ly/3S2o1z380L3i1D44443A>

For the people not yet on the latest WooFramework version: You can download
the latest version of WooFramework here: <http://cl.ly/2a3j1m351C3u2i0t122j>
(it is 5.3.10)

Do you know how to manually update the framework? This zip file unzips to a
"framework" folder, you need to replace to contents of the "functions" folder
of your theme. Obviously make a backup of everything before you start.

This exploit is fixed in the latest two stable builds and should have been
reported to us (WooThemes team) in the first place. Wonder if this guy has
ever heard of the concept of responsible disclosure...

~~~
Isofarro
Both links are shortened and resolve to a generic api.cld.me domain. You'd
expect a fix to be hosted on the woothemes controlled domain, not a largely
anonymous domain name. You'd also expect that there'd be at least a homepage
mention on woothemes.com to this same URL.

Seriously, if you are a representative of woothemes.com, this approach is a
major fail. you have a known website, that's where your authority and trust
resides. Use it.

This just looks like someone attempting to get people to add a new backdoor to
their existing wootheme powered site.

~~~
coenjacobs
No, the update pops up within your WordPress admin panel in case you are using
one of our themes. Secondary download - with the link I provided - is
available because our site was hacked last week:
<http://www.woothemes.com/2012/04/were-alive-and-kicking/> We only use that
download link temporarily to be able to provide the update to our users.

~~~
Isofarro
The secondary download link smells fishy. Don't do this. Host the file on a
domain that clearly belongs to and is fully managed by only WooThemes.

------
tnorthcutt
Did you attempt to responsibly disclose this to the WooThemes organization
before posting it publicly?

------
noinput
Looks like it was patched:
<https://twitter.com/#!/ryanr14/status/196461808331132929>

------
jasongill
WooThemes has just quietly bumped the version number and fixed their updater
bug so this is now fixed:

2012.04.29 - version 5.3.11 - critical * - SECURITY UPDATE - Shortcode preview
feature removed in previous version due to potential exploit. * admin-
functions.php - Make sure PressTrends banner displays only for PressTrends-
enabled themes.

I hope that in the future WooThemes (and the WordPress community as a whole)
takes security more seriously and notifies their customers more rapidly about
these sorts of problems.

Thanks to everyone who commented!

------
tszming
WooThemes' web site has been down in the past few days due to malicious hacks,
maybe related to this bug?

<http://www.woothemes.com/woothemes-server-status/>

~~~
coenjacobs
Not related at all. See my reply here:
<http://news.ycombinator.com/item?id=3905337>

------
mattyza
Hi all, This issue has been resolved in the latest version of the
WooFramework. We've bumped it up to V5.3.11 and marked the update as
"critical" for all WooFramework users.

Please see our official blog post here, where we detail the issue and the
solution we've implemented: [http://www.woothemes.com/2012/04/framework-
shortcode-exploit...](http://www.woothemes.com/2012/04/framework-shortcode-
exploit-has-been-fixed/)

~~~
qeorge
You guys should take this much more seriously. This blog post has a tone of
"much ado about nothing".

This is a very serious exploit. Combined w vulnerabilities in other unsecure
but popular plugins[1], this exploit is as damaging as one can possibly be. I
have a feeling I'll be cleaning up after this one for a long time (we're
_still_ having to clean up hacked sites from timthumb).

Look, mistakes get made. But you need to own up to it, and be honest about the
size of the problem. In particular, I find these passages disingenuous:

"Rest assured there is no link and the exploit was actually fixed a few days
before our website was hacked." (in bold)

Given that the exploit was live, _on your server_ , this is misleading at
best. Yes, you had found the bug and committed it on 4/23. But obviously it
hadn't made its way to active WooThemes installations, including your own. In
your repo != fixed.

"The potential exploit is such that the shortcode preview allowed users to
generate shortcodes using the preview window’s file, without authenticating
the user."

More accurate would be: "the exploit allows anyone off the street to run any
shortcode from any plugin you have installed. Vulnerabilities that were
limited to logged in users before are now available to bots."

The OP should have been more responsible in his disclosure. But so should have
WooThemes. Nothing in your public communications reflects the seriousness of
this exploit.

For what its worth, you just lost (at least) one customer.

[1] <http://secunia.com/advisories/46227/>

~~~
mattyza
qeorge,

We can assure you that we are aware of the nature of this possible exploit.
Security is of paramount importance to us.

The wording on our blog post is such to make known the severity of the
possible exploit, while also being sure to ensure our customers that the
possible exploit has been patched successfully.

To ensure that we communicate as effectively as possible to as many audiences
as possible in possible future exploits, we've setup a new development-
specific channel on Twitter and will be making other avenues of communication
open to ensure that we inform our customers of security updates as quickly as
possible.

------
themirage
Is this a result of someone analyzing the 'hacked' files?? Either way, it's
like kicking 'em while they're down!

~~~
kristofferR
Doesn't seem that way, it's a pretty simple exploit. Anyway, the source code
for the themes WooThemes sell is obviously available to all their customers.

------
mackyinc
Sure hope they were notified before it was released.

------
appleaintbad
Do you really think sharing this info on HN will do much good? Seems like it
is just a "injection attack me" sign for a bunch of Wordpress sites.

~~~
rscale
I just patched my wootheme'd wordpress sites to address the issue until an
official fix is out, so at least one person got positive value from this post.

That said, I really wish the original public report had been a private report.

~~~
jakejake
I just commented it out myself but validating $shortcode might be a better
solution.

[update] that wouldn't work either. it would still allow people to insert
random shortcodes with whatever params they like. i'm not sure what the point
of this function is, I don't think it should allow shortcodes to be passed in
at all via _REQUEST

~~~
golden_apples
The php code would be inside a shortcode that looked like [php][/php], so no,
that wouldn't protect you.

The smart fix is to check for user permissions and nonce before rendering the
shortcode preview, which I hope is what the Woo patch does.

~~~
jakejake
cool thanks, yea i just looked at do_shortcode again. this woothemes function
seems like a bad design.

Authentication would plug it from random attackers at least. But it seems to
me it would still be ripe for a CSRF attack..? That might seem unlikely but I
can imagine the attacker could post a comment with a link on the victims blog
who had been identified as having a wootheme installed. If the victim clicked
the link (likely while authenticated) the attacker's php code would execute.

~~~
golden_apples
Nonces, used properly, should be fairly decent protection against the kind of
CSRF attack you're describing. They're not bulletproof, but, someone who knows
enough about the internals of your site to generate a valid nonce probably has
several other possible attack vectors...

I haven't looked at the actual theme in question, but I can imagine that a lot
of Woo clientele want to be able to preview their posts with all the
shortcodes intact, which is what this function does, and why it has to receive
shortcode data through request parameter.

~~~
jakejake
I haven't seen their patch yet. I'd be surprised to see a nonce, my guess is
they just call the standard Wordpress function to require auth.

There's surely a better way to do it without accepting code via the query
string. Keep the code on the server and have that function only refer to an
index or something perhaps?

------
mgkimsal
The code could, at the very least, be using $_POST. Yes, that wouldn't stop
it, but it would make it harder to execute via naked URLs (assuming that's the
exploit going around, which I think it is).

This is precisely why I do not like $_REQUEST, and counsel against it in
presentations/classes I do on PHP. This is clearly written to be something
which modifies state - GET values should be ignored in this situations. And
yes, again, it's not perfect - someone could craft malicious POST requests - I
know - but that requires an extra level of effort not currently needed, and
it's an extra level of effort some people won't bother with.

