4 ms·

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 desper

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
        Well, that depends on your point of view. My personal opinion is that such a system would give people a false sense of security (since we know it's impossible for such a system to detect all malicious content) and would cause "script kiddies" a few minutes of annoyance as they make the tiny tweaks necessary to evade the filter. It would also drain development effort away from the main Wordpress system.
        cookiecaper 16y ago
        As long as the system doesn't make extravagant claims there shouldn't be a problem. A message on each page of the scanner like "This is only a precautionary measure that checks for known exploits; there can still be malicious code in any third-party code. Only use themes or plugins from sources you know to be safe." should not give a false sense of security, but can still help things. Anti-virus and anti-spam applications can never be 100% effective either, but we use those because they're useful on occasions where they do work. Should we give those up altogether because, since the virus writers merely have to look up circumvention techniques, it's a waste of programmer time?
    - Zak 16y ago
      For Wordpress themes as they are currently implemented, this is true, but the concept of being able to decide whether a given piece of code will do specific things is known as sandboxing and has many real-world implementations. You can be relatively certain that code running in specific sandboxes will not perform specific actions. You can be relatively certain, for example that an unsigned Java applet won't transmit data over a network to a third party. It wouldn't be hard to design an HTML templating system that would never render the string "<script", to provide an overly simple example. Making such a system popular enough that malicious themes are an issue worth worrying about is left as an exercise for the reader.
- henrikschroder 16y ago
  So what if malicious plugin writers then decide to encode urls like described in this story: http://news.ycombinator.com/item?id=2129745 http://news.ycombinator.com/item?id=2129745 How will you detect that with a scan?
  - jmah 16y ago
    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 16y ago
      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 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:// 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 16y ago
        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.
- jacquesm 16y ago
  It wasn't 24 hours ago that there was a pretty hard-core obfuscation example of what you can do with a bit of javascript, I can't imagine that method would be easy to detect when extended to 'hard coded urls'. You'd have to actually run the scripts embedded with real-life parameters in order to observe any malicious behavior. in case you missed it: http://news.ycombinator.com/item?id=2129745 http://news.ycombinator.com/item?id=2129745
kaerast 16y ago
The key here isn't a screening process for themes and plugins available through a WordPress website. The themes which have the back doors are typically pirated versions of paid-for themes which are never going to get into a WordPress app store. People are always going to pirate themes, people are always going to install themes from dodgy sources when they are free.
shankx 16y ago
Oops1 You made me think about third part plugins that I have installed on my blog.

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
      Well, that depends on your point of view. My personal opinion is that such a system would give people a false sense of security (since we know it's impossible for such a system to detect all malicious content) and would cause "script kiddies" a few minutes of annoyance as they make the tiny tweaks necessary to evade the filter. It would also drain development effort away from the main Wordpress system.
      - cookiecaper 16y ago
        As long as the system doesn't make extravagant claims there shouldn't be a problem. A message on each page of the scanner like "This is only a precautionary measure that checks for known exploits; there can still be malicious code in any third-party code. Only use themes or plugins from sources you know to be safe." should not give a false sense of security, but can still help things. Anti-virus and anti-spam applications can never be 100% effective either, but we use those because they're useful on occasions where they do work. Should we give those up altogether because, since the virus writers merely have to look up circumvention techniques, it's a waste of programmer time?
  - Zak 16y ago
    For Wordpress themes as they are currently implemented, this is true, but the concept of being able to decide whether a given piece of code will do specific things is known as sandboxing and has many real-world implementations. You can be relatively certain that code running in specific sandboxes will not perform specific actions. You can be relatively certain, for example that an unsigned Java applet won't transmit data over a network to a third party. It wouldn't be hard to design an HTML templating system that would never render the string "<script", to provide an overly simple example. Making such a system popular enough that malicious themes are an issue worth worrying about is left as an exercise for the reader.
henrikschroder 16y ago
So what if malicious plugin writers then decide to encode urls like described in this story: http://news.ycombinator.com/item?id=2129745 http://news.ycombinator.com/item?id=2129745 How will you detect that with a scan?
- jmah 16y ago
  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 16y ago
    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 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:// 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 16y ago
      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.
jacquesm 16y ago
It wasn't 24 hours ago that there was a pretty hard-core obfuscation example of what you can do with a bit of javascript, I can't imagine that method would be easy to detect when extended to 'hard coded urls'. You'd have to actually run the scripts embedded with real-life parameters in order to observe any malicious behavior. in case you missed it: http://news.ycombinator.com/item?id=2129745 http://news.ycombinator.com/item?id=2129745

kaerast 16y ago

The key here isn't a screening process for themes and plugins available through a WordPress website. The themes which have the back doors are typically pirated versions of paid-for themes which are never going to get into a WordPress app store. People are always going to pirate themes, people are always going to install themes from dodgy sources when they are free.

shankx 16y ago

Oops1 You made me think about third part plugins that I have installed on my blog.