4 ms·

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

by nbpoole 16y ago

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.

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

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