10 ms·

Free Wordpress themes coming with a price

285 points by fwdbureau 16y ago

noodle 16y ago
interesting to note that these are also some generally ugly themes.
nbpoole 16y ago
It would be interesting to analyze whether the code was actually malicious (or could be used for malicious things) or spammy but benign.
- jacques_chester 16y ago
  Despite what my degree says, I'm a horrible computer scientist. But would this be a bit like solving the halting problem? squint
  - nbpoole 16y ago
    I didn't mean a fully automated analysis (although it's possible to somewhat automate the de-obfuscation: see http://php-security.org/2010/05/13/article-decoding-a-user-space-encoded-php-script/index.html http://php-security.org/2010/05/13/article-decoding-a-user-s...). But given a bit of time, it should be possible to "unwrap" the obfuscated code in more detail and see what it's actually doing (which wasn't done in all cases).
- iamdave 16y ago
  Interesting point, actually. I'd like to see that same analysis now that you've brought it up just for the sake of pure curiosity. WP powers a good chunk of the blogosphere (including The New York Times website) out there now, and this kind of data could get some very good discussion going.
  - jacques_chester 16y ago
    > Though it can be argued that it's possible in some cases it's both; in the case of Gawker, perhaps there was a theme add-on that possible opened or exacerbated a hole resulting in the password leak. Gawker run a custom platform, not Wordpress.
    - iamdave 16y ago
      Ah, thank you for the correction
      - jacques_chester 16y ago
        No worries. Gawker was compromised through ordinary social engineering, basically. In some ways these faux themes are in the same class of attack.
- beoba 16y ago
  I think the fact that the authors were using base64 encoding to hide it answers your question.
  - nbpoole 16y ago
    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 16y ago
      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 16y ago
        "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 ;)
- ceejayoz 16y ago
  Being spammy can be malicious. The black hat SEO folks know full well that these sorts of spammy links can lead to innocent folks' WordPress blogs getting eventually penalized or blacklisted from search engine indexing.
jacques_chester 16y ago
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.
RBr 16y ago
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-wordpress-themes-from-shady-sites/ http://www.themelab.com/2009/12/08/stop-downloading-wordpres... TAC (Theme Authenticity Checker) isn't a bad place to start searching for malicious code: http://builtbackwards.com/projects/tac/ 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 16y ago
  > 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 16y ago
    What is your exhaustive definition of "malicious" in this case?
    - shadowpwner 16y ago
      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 16y ago
        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 16y ago
        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.
jacques_chester 16y ago
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 16y ago
  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 16y ago
    Sandboxing would be helpful. Java-like or Lua-like.
    - ptomato 16y ago
      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 16y ago
        You're right, I retract the point.
dholowiski 16y ago
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.
myth_drannon 16y ago
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 16y ago
  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/ http://www.woothemes.com/2009/06/woothemes-gpled/ and http://www.woothemes.com/terms-conditions/ http://www.woothemes.com/terms-conditions/) For what it's worth, I've happily paid for the WooThemes I use.
  - ionfish 16y ago
    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 16y ago
      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.
joshfraser 16y ago
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 16y ago
  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.
  - kaerast 16y ago
    You mean like the exploit scanner as linked to from the source article? Make that part of core WordPress and scan for other obfuscation techniques too and you're well on the way to improving things.
    - henrikschroder 16y ago
      No, that means you'll be well on the way of improving the obfuscation techniques. Scanning a piece of code to try and decide if it is "malicious" or not is essentially the halting problem, which is impossible to solve. As long as you have a system where you install third-party code you are screwed, no matter what the base language is.
      - cookiecaper 16y ago
        That doesn't mean it's totally pointless to look for blatant exploits. A lot of script kiddies are going to use naive and obvious methods that can be caught with simple automated scans. While this method may not catch 100% of occurrences, it can certainly help.
        nbpoole 16y ago
ams6110 16y ago
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 16y ago
  > 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 16y ago
    > 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 16y ago
      > 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.
lkrubner 16y ago
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 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.
- jacques_chester 16y ago
BoppreH 16y ago
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 16y ago
  > 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.
infinity 16y ago
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 16y ago
  Sorry, but who's talking about PHP here?
  - telemachos 16y ago
    I think he meant to reply to lkbruner[1] but "missed": > Some of these problems are inherent to PHP [1]: http://news.ycombinator.com/item?id=2131095 http://news.ycombinator.com/item?id=2131095
    - infinity 16y ago
      Yes, actually I wanted to reply, but my answer ended up as a stand-alone comment. I'm sorry for this, if it caused some confusion.
  - infinity 16y ago
    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.
zx76 16y ago
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 http://github.com/mojombo/jekyll/wiki Better performance + security and you can use Textile!
- brianwillis 16y ago
  Thanks to your comment I've lost four hours of my life to fiddling with Jekyll. Thanks for making my Sunday night more interesting.
jrockway 16y ago
Ironically, most of the base64 "encrypted" code is easier to read than the Wordpress core...
wildmXranat 16y ago
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.
bobds 16y ago
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 16y ago
  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 16y ago
    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 16y ago
Isn't this primarily Google's fault? Their algorithms should be capable of weeding out the bad sites.
patio11 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      You say "Wordpress is not fine", but yet this is a perfectly valid link: http://www.kalzumeus.com/wp-admin 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."
rick888 16y ago
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.
A1kmm 16y ago
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.
codelust 16y ago
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.
ck2 16y ago
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.
photomatt 16y ago
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.

285 points by fwdbureau 16y ago

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

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

jacques_chester 16y ago
Despite what my degree says, I'm a horrible computer scientist. But would this be a bit like solving the halting problem? squint
- nbpoole 16y ago
  I didn't mean a fully automated analysis (although it's possible to somewhat automate the de-obfuscation: see http://php-security.org/2010/05/13/article-decoding-a-user-space-encoded-php-script/index.html http://php-security.org/2010/05/13/article-decoding-a-user-s...). But given a bit of time, it should be possible to "unwrap" the obfuscated code in more detail and see what it's actually doing (which wasn't done in all cases).
iamdave 16y ago
Interesting point, actually. I'd like to see that same analysis now that you've brought it up just for the sake of pure curiosity. WP powers a good chunk of the blogosphere (including The New York Times website) out there now, and this kind of data could get some very good discussion going.
- jacques_chester 16y ago
  > Though it can be argued that it's possible in some cases it's both; in the case of Gawker, perhaps there was a theme add-on that possible opened or exacerbated a hole resulting in the password leak. Gawker run a custom platform, not Wordpress.
  - iamdave 16y ago
    Ah, thank you for the correction
    - jacques_chester 16y ago
      No worries. Gawker was compromised through ordinary social engineering, basically. In some ways these faux themes are in the same class of attack.
beoba 16y ago
I think the fact that the authors were using base64 encoding to hide it answers your question.
- nbpoole 16y ago
  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 16y ago
    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 16y ago
      "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 ;)
ceejayoz 16y ago
Being spammy can be malicious. The black hat SEO folks know full well that these sorts of spammy links can lead to innocent folks' WordPress blogs getting eventually penalized or blacklisted from search engine indexing.

jacques_chester 16y ago

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.

RBr 16y ago

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-wordpress-themes-from-shady-sites/ http://www.themelab.com/2009/12/08/stop-downloading-wordpres... TAC (Theme Authenticity Checker) isn't a bad place to start searching for malicious code: http://builtbackwards.com/projects/tac/ 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 16y ago
> 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 16y ago
  What is your exhaustive definition of "malicious" in this case?
  - shadowpwner 16y ago
    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 16y ago
      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 16y ago
        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.

jacques_chester 16y ago

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 16y ago
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 16y ago
  Sandboxing would be helpful. Java-like or Lua-like.
  - ptomato 16y ago
    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 16y ago
      You're right, I retract the point.

dholowiski 16y ago

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.

myth_drannon 16y ago

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 16y ago
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/ http://www.woothemes.com/2009/06/woothemes-gpled/ and http://www.woothemes.com/terms-conditions/ http://www.woothemes.com/terms-conditions/) For what it's worth, I've happily paid for the WooThemes I use.
- ionfish 16y ago
  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 16y ago
    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.

joshfraser 16y ago

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 16y ago
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.
- kaerast 16y ago
  You mean like the exploit scanner as linked to from the source article? Make that part of core WordPress and scan for other obfuscation techniques too and you're well on the way to improving things.
  - henrikschroder 16y ago
    No, that means you'll be well on the way of improving the obfuscation techniques. Scanning a piece of code to try and decide if it is "malicious" or not is essentially the halting problem, which is impossible to solve. As long as you have a system where you install third-party code you are screwed, no matter what the base language is.
    - cookiecaper 16y ago
      That doesn't mean it's totally pointless to look for blatant exploits. A lot of script kiddies are going to use naive and obvious methods that can be caught with simple automated scans. While this method may not catch 100% of occurrences, it can certainly help.
      - nbpoole 16y ago

ams6110 16y ago

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 16y ago
> 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 16y ago
  > 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 16y ago
    > 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.

lkrubner 16y ago

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 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.

jacques_chester 16y ago

BoppreH 16y ago

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 16y ago
> 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.

infinity 16y ago

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 16y ago
Sorry, but who's talking about PHP here?
- telemachos 16y ago
  I think he meant to reply to lkbruner[1] but "missed": > Some of these problems are inherent to PHP [1]: http://news.ycombinator.com/item?id=2131095 http://news.ycombinator.com/item?id=2131095
  - infinity 16y ago
    Yes, actually I wanted to reply, but my answer ended up as a stand-alone comment. I'm sorry for this, if it caused some confusion.
- infinity 16y ago
  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.

zx76 16y ago

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 http://github.com/mojombo/jekyll/wiki Better performance + security and you can use Textile!

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

jrockway 16y ago

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

wildmXranat 16y ago

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.

bobds 16y ago

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 16y ago
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 16y ago
  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 16y ago

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

patio11 16y ago

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 16y ago
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 16y ago
  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 16y ago
    You say "Wordpress is not fine", but yet this is a perfectly valid link: http://www.kalzumeus.com/wp-admin 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."

rick888 16y ago

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.

A1kmm 16y ago

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.

codelust 16y ago

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.

ck2 16y ago

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.

photomatt 16y ago

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.