
Free Wordpress themes coming with a price - fwdbureau
http://wpmu.org/why-you-should-never-search-for-free-wordpress-themes-in-google-or-anywhere-else/
======
infinity
I disagree that these problems are inherent to PHP. If the themes were written
in almost any other language, people would still download themes or plug-ins
and put it on their webspace. Many of the WordPress users are not experienced
in coding for the web and some are not aware of the potential dangers that
come with scripts from a shady source. They only get interested in security
when their sites get owned. In the first place they just want to blog.

There are similar problems with widgets that people like to install in a
sidebar or footer, like counters, clocks, ... There have been several cases
where the widgets used a JavaScript hosted on a different domain, and later
the JavaScript was changed to something that redirected visitors to infected
sites. Here no PHP or any other server side language is involved. This problem
is older than WordPress.

~~~
JoachimSchipper
Sorry, but who's talking about PHP here?

~~~
infinity
When the discussion started there were some remarks like this:

>Some of these problems are inherent to PHP

Also the availability of eval() and base64 encoding and decoding functions in
PHP were blamed for the problems. You can find these statements if you read
through the whole thread.

~~~
troels
Every comparable language has an eval statement or equivalent. And the base64
functions are quite practical have around if you should ever have to ... eh
... decode or encode in base64. The problem here is not with PHP, but with
naïve users installing software from a dubious source.

~~~
infinity
Yes, this is similar to what I wrote above. And the problem is even older than
PHP. For as long as I can think back there have always been people clicking
every colorful link saying "Click here! It's FREE!" and "Download for Free!".
Back then the nasty payload came from cracked software and games, stuff like
boot sector viruses. I wouldn't put the blame for this on assembly language.

------
joshfraser
The whole WP ecosystem is very insecure. For example, it's trivial to add a
back door to a plugin that gives you full access to their server. Wordpress
desperately needs to add a screening process. You can't assume everyone will
do a code review before installing stuff even if they should.

~~~
mortenjorck
The admin backend should simply search any newly-installed theme or plugin
file for hard-coded URLs, and then display them to the user prior to
activation. And throw a huge red flag if it encounters any base64 obfuscation.

~~~
henrikschroder
So what if malicious plugin writers then decide to encode urls like described
in this story: <http://news.ycombinator.com/item?id=2129745>

How will you detect that with a scan?

~~~
jmah
The main goal of the high-ranking templates seems to be to add links to
specific sites (to boost their PageRank). Those links are unobfuscated for the
search bots, with the encoded JS serving to replace them for humans. So
mortenjorck's suggestion would still apply.

However, including _any_ JavaScript is arbitrary exploitation, but perhaps
there's less of an incentive once the Google-bombing aspect is removed.

~~~
damncabbage
It's less javascript than PHP you've got to worry about; that javascript
obfuscation article was a nice example of how much you can mangle a language
to hide things.

For example, in your Wordpress template, put the following snippet in:

    
    
      <?php echo urldecode('%68%74%74%70%3A%2F%2F%67%6F%6F%67%6C%65%2E%63%6F%6D'); 
    

This will display "<http://google.com> on your page.

Okay. So how about looking for urldecode (a perfectly useful function, with
uses not restricted to hacking)?

    
    
      <?php $f=chr('117').chr('114').chr('108').chr('100').chr('101').chr('99').chr('111').chr('100').chr('101');
      echo $f('%68%74%74%70%3A%2F%2F%67%6F%6F%67%6C%65%2E%63%6F%6D');
    

... And so on, ad infinitum. Looking for particular sequences
(%68%74%74%70%3A%2F%2F --> <http://>)? Add numbers together at run-time.
Looking for a block of these together? Spread them out, or construct them from
innocuous-looking things.

It's a game you're not going to win.

~~~
cookiecaper
It shouldn't be that hard to run a search on a rendered page automatically.
Assuming someone is embedding a URL in what ultimately becomes plaintext, then
it should be easy to look for suspicious links on the final rendering. There's
still JS obfuscation, but that would at least exclude most PHP-based
obfuscation.

~~~
nbpoole
That's completely untrue :P

You're assuming that there is some supreme Rendering Engine which maps code to
a single canonical output. In reality, every browser renders things slightly
differently and a malicious script would take advantage of that (while
rendering things "normally" for the scanner). See also: cloaking
([http://en.wikipedia.org/w/index.php?title=Cloaking&oldid...](http://en.wikipedia.org/w/index.php?title=Cloaking&oldid=408912417))

~~~
cookiecaper
You're right of course, but again, the scanner would not go after
sophisticated or complex attacks, but naive attacks implemented by posers.

It's just a matter of time before everything we currently consider "secure" is
cracked; I reckon that eventually they'll have computers that can bruteforce
2048-bit encryption keys (and I've seen all of the theoretical calculations
about the computing power needed to do that, so we don't need to repeat that
here) in a day or less. That doesn't mean we shouldn't make the best of what
we have at our disposal, whether that's encryption or detection techniques to
catch at least some bad guys.

------
photomatt
The WordPress team has thought a lot about this issue, and the most effective
solution so far has been to have robust official sources of themes and plugins
and educating people to get everything from WordPress.org. (It's the only
source built-in to WP software.) It's our equivalent of airplane security's
"tougher cabin doors and passenger's willingness to fight back."

An automated scanner in core might temporarily relieve some of the current
techniques of spammers but it would be trivial to vary obfuscation to evade
any automated check, and I worry more about the false sense of security they
would provide. A built-in automated checker would not make it safe for you to
Google around random sites and install their software to execute on your
server.

On the plus side, we now have over 1,300 themes in our official repository and
every single one of them has been verified by hand.

------
RBr
Wordpress themes aren't the only ones guilty of this. Shady plugins also
contain hidden code.

[http://www.themelab.com/2009/12/08/stop-downloading-
wordpres...](http://www.themelab.com/2009/12/08/stop-downloading-wordpress-
themes-from-shady-sites/)

TAC (Theme Authenticity Checker) isn't a bad place to start searching for
malicious code: <http://builtbackwards.com/projects/tac/>

However, the only real solution to this problem is to run a limited set of
extremely trustworthy plugins and build your own themes.

~~~
shadowpwner
> However, the only real solution to this problem is to run a limited set of
> extremely trustworthy plugins and build your own themes.

What on earth? It's pretty simple to check for malicious Javascript or PHP
code in a theme.

~~~
jarek
What is your exhaustive definition of "malicious" in this case?

~~~
shadowpwner
Let's see:

1) Anything linked outside of the domain. 2) Anything not
HTML/CSS/image/Wordpress tag/Javascript libraries 3) Anything encrypted.

Let me know if I missed anything.

~~~
jarek
Do you whitelist the Javascript libraries? Who certifies them? Is having a
base64 decode function available from the library a problem?

Do you scan the CSS for url() references outside of the domain?

~~~
shadowpwner
1\. Most Wordpress theme developers use popular Javascript libraries, so it
wouldn't be too difficult to replace them with the original if you suspected
something was amiss. The function wouldn't be a problem, if there wasn't any
base64 code. 2\. url() references should all be relative, in the same domain,
so if it linked on the outside, I'd change it.

Most of the time I use a Wordpress theme as a starting point, rewriting some
parts and looking over all of the code.

Also, mentioned above, securing the theme against injections and XSS is
important.

~~~
jarek
Do you scan images provided with the theme to check if any subset or
combination of subsets of their contents can be malicious when base64 decoded?

------
patio11
Reminder: if you're typing "sudo gem install ..." or the equivalent in your
language of choice, you could be installing Wordpress.

OSS doesn't mean somebody else audited it for you.

~~~
burgerbrain
Huh? Wordpress is just fine (well, fine enough..), it's the themes from shady
3rd party websites that are the issue being talked about here.

~~~
patio11
Wordpress is not fine, because it encourages installing untrusted code. I am
making the fairly consequential point that Wordpress is hardly alone in this,
and that doing so allows the attacker to do _anything they want_. Shady 3rd
party websites are hardly the only thing you have to worry about: how hard do
you think it would be to use a modestly popular Ruby gem or Rails plugin to
inject links? I think the answer is "Absolutely trivial."

~~~
AgentConundrum
You say "Wordpress is not fine", but yet this is a perfectly valid link:
<http://www.kalzumeus.com/wp-admin>

I understand the point you're making here, Patrick, but it does feel slightly
hypocritical for you to deride something as "not fine" when it seems to suit
your needs just "fine."

------
nbpoole
It would be interesting to analyze whether the code was actually malicious (or
could be used for malicious things) or spammy but benign.

~~~
beoba
I think the fact that the authors were using base64 encoding to hide it
answers your question.

~~~
nbpoole
No, it doesn't.

Is it shady? Yes. Would I want it running on my server? Absolutely not. Is the
code running a backdoor that lets the attackers execute shell commands? We
don't know.

Obfuscation like this could be used for any number of things. Themes sometimes
have credits at the bottom (i.e., "This theme created by John Smith"): the
obfuscation could be an attempt to keep people from finding/removing the
credit. It can also be used to include shady backlinks to other sites. And as
I mentioned before, it could be used to allow arbitrary code execution. It's
all a matter of degrees, and it DOES matter which it is: one is dangerous and
the others are just shady.

~~~
beoba
If a user is already intent on removing a credit url, hiding it behind
obfuscation isn't going to change their mind. As an author giving out an
effectively open source theme, the only asset you can depend upon is your
users' goodwill.

I think WP would be better off if it just automatically pruned these calls at
the time of import, and if it breaks the theme, maybe the author should
consider being more honest.

I'm not saying that there's isn't a difference between code that's merely
obnoxious and code that's actively damaging, but rather that both should be
discouraged whenever possible.

~~~
nbpoole
"If a user is already intent on removing a credit url, hiding it behind
obfuscation isn't going to change their mind. As an author giving out an
effectively open source theme, the only asset you can depend upon is your
users' goodwill."

I was simply suggesting a more benign reason why this code might exist: I'm
not defending it. ;)

What calls do you suggest Wordpress disallow though? Eval isn't the only way
to execute a string as PHP code ;)

------
wildmXranat
I stopped hosting my personal rant blog and went with wordpress.com free
hosting. I have given up trying to patch, update, comb through every plugin,
theme, whatever. Having said that, I don't care if the hosted wordpress blog
gets hacked. Losing some written word is something I can live with as long as
the server isn't mine.

I have entered a period in my life where I only trust static code. I write all
content in a meta markup language, I run a static page compiler on the
directory structure and upload the created html and resources to the server.

------
codelust
Consider this the iOS versus Android equivalent on the web. You can either
take the app store approach to themes and plugins and police every bit of code
uploaded to codex or it can be the Andoriod model where there is no proactive
policing.

Somehow, I don't think the Wordpress app store is going to make much progress
at Automattic. It will require them to put in considerable resources to
policing the code than improving the core.

The other way is to have a the Wordpress core bootstrap allow only a whitelist
of functions to be called, which would have the effect to severly curtailing
the flexibility that is required by plugin/theme developers.

Mind you, these problems are there not just with PHP/Wordpress. You can have
the same issues with Chrome/Firefox extensions, bookmarkelets and most of the
add-on models where you are running code that has not been subject of a decent
audit.

The trouble for Wordpress/PHP is the footprint they have on the web now, which
makes them pre-Vista/7 days for Microsoft on the web. You could probably do
similar nasty things with a fancy jQuery plugin, but it is much better bang
for the for the buck for the evil guy to have a go at something that is so
widely installed and used by a large number of people who would not know it
even if you were to show them code that does nasty things.

On other hand, a certified/curated theme/plugin/app store for all ecosystems
that follow the reactive model to policing add-ons is a great idea for a
start-up. I have been amused that nobody's done it so far. I know there are
directories, but they don't test/audit the apps. Someone should give it a
shot.

------
A1kmm
Creating advertising supported themes is a legitimate business model, and
trying to stop someone removing the advertising by obfuscating code isn't
really any worse than, say, distributing binaries to software which have been
compiled to make it harder to change the source code.

I personally don't like to use software projects which aren't Free / Open
Source (meaning that the full, unobfuscated source code is available and you
are free to do what you like with it) - but I think it would be a stretch to
say that distributing binaries or obfuscated code is automatically shady. You
have to trust the person that makes the site, but asking someone to trust you
is not synonymous with shady unless you then violate that trust.

Of course, if the sites are plagiarising other people's work without a
license, including malicious code, or misleading people about what the code
does or doesn't do, then there is a legitimate concern.

------
zx76
This is just one of the reasons I recommend Jekyll - a static HTML blog
generator. It's an excellent piece of software written by Tom Preston-Werner
you can read about here: <http://github.com/mojombo/jekyll/wiki>

Better performance + security and you can use Textile!

~~~
brianwillis
Thanks to your comment I've lost four hours of my life to fiddling with
Jekyll. Thanks for making my Sunday night more interesting.

------
BoppreH
Can't base64 be used to encode small images, like icons? I'm sure that I've
seen this in desktop apps. Why didn't the author decode them all, instead of
just the last ones?

Also, did the tone of the article bother anyone else? It made me cringe after
every few phrases.

~~~
duskwuff
> Can't base64 be used to encode small images, like icons?

Yes, but if the "base64_decode" function is being used in the PHP code for the
theme, chances are that it's being used to hide something.

------
ck2
I noticed that a few months after I put up a list of themes for bbPress
(WordPress's little sister for forums) someone started a website that copied
them all for download (which is fine because they are GPL) but then inserted
all sorts of malicious spam links and other code into them.

Despite my warnings to users and trying to get Google to put that site into
their security blocklist (never happened) I can now search for and find
hundreds of sites that have these spam links from using those bad copies.

------
ams6110
Anyone know if contributed code for other website platforms (Drupal, Joomla,
DNN) etc. has similar issues? Is there any sort of "vetting" that goes on?

I actually worry more about the cheap but commercial modules, vs. the
free/open source ones. With open source modules, chances are _someone_ has
perused the code looking for any signs of mischief. With the commercial code,
often authored in another country, who knows?

~~~
jacques_chester
> Anyone know if contributed code for other website platforms (Drupal, Joomla,
> DNN) etc. has similar issues?

Absolutely. It's common to all these programs because they all use the LAMP
architecture, which includes PHP (eval() and base64_encode()) and an inability
to securely partition the data (can't have multiple users in the DB).

~~~
drdaeman
> which includes PHP (eval() and base64_encode())

At least Python, Ruby and Perl have those functions too. The problem is not
related to PHP being able to eval(), it's:

1\. Inadequate usage of PHP as template engine, where templates are coming
from untrusted sources. Think of this as very extended case of non-sanitizing
user input.

2\. "Dancing bunnies"-type problem. A lot of users don't understand what they
are doing. They are promised they would get a nice theme, so they install it.

> can't have multiple users in the DB

Wrong, it's perfectly possible. Unless you are stuck with some god-forsaken
cheap crappy LAMP hosting.

Disclaimer: I don't like PHP at all, and I try to avoid it. Experts say, and I
totally agree that there are a lot of various problems in LAMP ecosystem, but
they lie in very different direction.

~~~
jacques_chester
> Wrong, it's perfectly possible.

I thought so too, but in practice it doesn't work (I proposed it to them a
while back).

Wordpress stores database credentials as globals. Even if you gave each plugin
its own permissions, they could always go straight to the superuser account
for that database.

------
bobds
STEP 1:

Make every theme/plugin author create a private key to sign their releases.
Their public key will be available on their profile page and via API.
Wordpress will notify you if the public key for an author has changed or if a
release signature doesn't match the public key.

Why is this not done?

(Also in other software that uses plugins and is updated easily over the
internet.)

~~~
kaerast
That's largely not going to make a difference. You can already mostly trust
themes and plugins listed on the WordPress.org website. The themes with the
bad code are the ones available elsewhere, and quite often are pirated
versions of commercially available themes.

~~~
bobds
I shiver when I think how many pieces of code are fetched over the internet on
my machines.

If you are a motivated attacker you can compromise a plugin author's PC or
server and silently push a backdoor to a whole lot of people.

Signed releases are commonplace. It would make sense to require them in most
plugin systems, especially those with central plugin repositories and lots of
users.

------
w1ntermute
Isn't this primarily Google's fault? Their algorithms should be capable of
weeding out the bad sites.

------
myth_drannon
Not only the free themes but I see many pirated commercial packages on torrent
websites. It's very tempting to download all these 50 woothemes, even just to
try them out ... but the fear of hidden code just too strong.

~~~
apowell
While your fear of hidden code is probably well-founded, I don't think it's
piracy to redistribute the WooThemes. They have been released under the GPL.
(<http://www.woothemes.com/2009/06/woothemes-gpled/> and
<http://www.woothemes.com/terms-conditions/>) For what it's worth, I've
happily paid for the WooThemes I use.

~~~
ionfish
Not to mention that even if they haven't been explicitly released under the
GPL, they are derivative code upon a GPL-licensed piece of software and thus
GPLed themselves.

~~~
dangrossman
One might argue. Plenty of others, including lawyers, have argued that isn't
so. There are even court decisions to support that WP themes and plugins may
not be derivative works. Nobody can say definitively until there are some
actual cases resolved in court to provide guidance.

------
rick888
I found some of the offending code when I downloaded a free theme the other
night.

It took me around 5 minutes to:

1) open footer.php 2) echo base64_decode('code') 3) take out all of the links
and paste the rest of the code in the footer.

Problem solved.

------
jrockway
Ironically, most of the base64 "encrypted" code is easier to read than the
Wordpress core...

------
noodle
interesting to note that these are also some generally ugly themes.

------
dholowiski
Hasn't this been on HN already?

Anyway, just stick to wordpress.org/extend/themes - those themes are all under
the scrutiny of the community and there's a group of peoe who are ramping up
to do code reviews on them.

------
jacques_chester
Wordpress isn't responsible; the faults are due to the design of PHP. The
availability of the eval() and base64_encode() make these sorts of attacks
basically unpreventable in untrusted sources.

~~~
ptomato
And _not_ including eval and base64_encode would be _ridiculous_. No
programming language is at all difficult to do nasty things with if you decide
it's a good idea to include random untrusted code snippets.

~~~
jacques_chester
Sandboxing would be helpful. Java-like or Lua-like.

~~~
ptomato
Java-style sandboxing prevents all run code from having access to anything
important on the filesystem (&c) which a) wouldn't really work for a server-
run application and b) wouldn't at all prevent the type of nasty that shows up
in those WP themes.

I'm not terribly familiar with Lua sandboxing, but a cursory overview suggests
that absolutely nothing would prevent it from including similar nastiness if
used in display code.

In any case, something like a website theme in _any_ language, can always
display HTML that is at least that hidden. So sure, kill base64_decode in php,
but as long as you have a Turing-complete language which is at least
moderately inevitable if you allow any logic in your templating system at all
and you can implement the equivalent trivially.

If you completely neuter your templating system, then do something like
include inline base 64 in CSS as image data, decode & exec using JS. Google's
spiders will run JS now, unless I'm mistaken, so that's just as good from an
SEO standpoint.

~~~
jacques_chester
You're right, I retract the point.

------
lkrubner
Some of these problems are inherent to PHP, but the WordPress team has decided
to work with PHP, therefore the problems of PHP are also legitimate issues to
raise with the WordPress team. That is to say, in accepting PHP as their
language, the WordPress team must take responsibility for that choice, and
that includes confronting the security risks that arise from the choice of
language.

Sam Ruby made this same point, and he said it much better than I can hope to
(he is responding to Matt Mullenweg in the comments):

"Those that contribute to PHP apparently feel the most pain concerning support
of multiple versions. Yes, you can argue that they brought this upon
themselves; but it is worth noting that at this point you are along for the
ride. When I’m in similar circumstances, I tend to consider the karma
implications of cursing the driver. In any case, some people who are along for
the ride with WordPress happened to cross my path yesterday. Perhaps you are
in a position where you can help them. To my eyes, I see a bug that was
reported on WordPress 2.1, and the milestone on that defect is currently set
to 2.3. Hopefully the users affected won’t have a tendency to kick, or scream,
or rant too much."

<http://intertwingly.net/blog/2007/07/17/Popular-Sovereignty>

There is another way to look at this. Microsoft has faced 30 years of
criticism of its decision to promote features rather than security, a problem
that began with DOS and lasted at least until Vista showed up.

That same type of criticism can and should be made against the WordPress team.
They promote features to make the user experience pleasant, but their attitude
towards security has been horrible.

What can they do? They can automate the test that Siobhan Ambrose does in the
above article linked to by this thread. At the very least, WordPress can
search a theme for Base64, so that when you try to activate the theme, you get
a warning:

"These templates contain Base64, which may be masking malicious code. Do you
wish to proceed?"

Again, it was the choice of the WordPress team to use PHP, so they must take
responsibility for the choice of language. As Sam Ruby said, "It is worth
noting that at this point you are along for the ride. When I’m in similar
circumstances, I tend to consider the karma implications of cursing the
driver"

More so, WordPress became popular because it was easy for designers to work
with, and the WordPress team has certainly participated, and encouraged, the
creation of a culture in which the promiscuous sharing of templates seems
normal.

It is irresponsible of the WordPress team to ignore the security issues that
this raises.

~~~
cosgroveb
I am about as big (read: little) of a fan of PHP as the next guy but how in
the hell are these problems inherent to PHP? If I were to run COBOL code from
untrusted sources on my server you can forget about security.

~~~
lkrubner
Why does WordPress allow people to run untrusted code?

You write:

"If I were to run COBOL code from untrusted sources on my server you can
forget about security."

That is why there should be a warning about untrusted code. Are you trying to
let WordPress off the hook? Their attitude toward security has been horrible
and they should be called out on it. I quote myself:

What can they do? They can automate the test that Siobhan Ambrose does in the
above article linked to by this thread. At the very least, WordPress can
search a theme for Base64, so that when you try to activate the theme, you get
a warning:

"These templates contain Base64, which may be masking malicious code. Do you
wish to proceed?"

It doesn't matter if WordPress is written in PHP or COBOL, the team developing
the software should make some attempt to address its many security flaws.

Please consider the odd use of the word "disrespectful" in this paragraph:

"It seems fundamentally disrespectful to users who are simply caught in the
crossfire of a political power move their neither know or care about. PHP core
has never shown any particular regard for its biggest apps, as evidenced by
the above bug and others, so I’m not sure why we should go out of our way to
promote their upgrade. PHP 6 sounds much more compelling."

<http://ma.tt/2007/07/on-php/#comment-422760>

That is Matt Mullenweg. Please note that his statement can be turned on its
head. I could write:

"It seems fundamentally disrespectful to users to create software for them
that has lots of fun features but no security."

~~~
lkrubner
The downvoting on Hacker News sometimes seems wholly random. I am curious who
would down vote this above comment of mine. I'm looking at each sentence and
trying to think what people are disagreeing with.

For instance:

"That is why there should be a warning about untrusted code."

What is the counter-argument, that WordPress should do nothing about the fact
that the templates allow the execution of arbitrary code?

"It doesn't matter if WordPress is written in PHP or COBOL, the team
developing the software should make some attempt to address its many security
flaws."

What is the counter-argument, that WordPress has no responsibility for the
security flaws in WordPress?

Very curious.

~~~
pclark
The downvoting is probably due to your tone, I read your comments and agreed
with you _but god why do you write like that_ \- why do you keep quoting
people with "You write" style opening lines? it sets the tones of your
comments off in the most horrible light.

------
jacques_chester
The major price is that you had to install Wordpress. Now you're stuck with
massaging that fat, slow sucker into shape.

I predict that Matt Mullenweg will be here within minutes to be all cheerful
and helpful. Hello Matt!

edit: I realise it's a snide remark, but I've been running Wordpress sites
since 2005 and I have an excellent storehouse of corrosive hatred built up at
this point.

