Hacker News Reader

Comment by mortenjorck | Hacker News Reader

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.

View on HN

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

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?

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.

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.

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.

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

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.

By the time you've rendered the page, it's already too late. In rendering the page you're running the untrusted code.

Wordpress themes are a double-edged sword--Wordpress became what it is today because of the flexibility that themes provide, but it comes at a cost. Other theming engines traded flexibility for security, and as a result aren't nearly as popular.

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.

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.

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.

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.

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?

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.

Reply on news.ycombinator.com