Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

some node.js unserialization + javascript RCE snippets #1487

Merged
merged 6 commits into from Aug 19, 2019

Conversation

@lifeforms
Copy link
Collaborator

commented Jul 21, 2019

Libraries performing insecure unserialization:

  • node-serialize: _$$ND_FUNC$$_ (CVE-2017-5941)
  • funcster: __js_function

See:
https://opsecx.com/index.php/2017/02/08/exploiting-node-js-deserialization-bug-for-remote-code-execution/
https://www.acunetix.com/blog/web-security-zone/deserialization-vulnerabilities-attacking-deserialization-in-js/

Some generic snippets used:

  • function() {
  • new Function(
  • eval(
  • String.fromCharCode(

Last two are used by nodejsshell.py,
https://github.com/ajinabraham/Node.Js-Security-Course/blob/master/nodejsshell.py

As base64 is sometimes (but not always) used to encode serialized values,
use multiMatch and t:base64decode.

@theMiddleBlue

This comment has been minimized.

Copy link
Collaborator

commented Jul 22, 2019

really love this PR! It would be nice to add some rules for cases like CVE-2017-16082 something that could intercept nodejs syntaxes like p=require('child_process') ... p.exec(...)

@lifeforms

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 23, 2019

I agree @theMiddleBlue , but was wondering about the best approach, considering possible false positives. What do you think, should we block on require(...) and .exec(...), or be more specific in what appears between the parentheses? If we are scan for require('child_process'), it would be trivial to bypass with something like:

p = require('child' + '_pro' + 'cess');

Since these types of attacks are more rare when compared to SQLi/PHP, I'm a bit hesitant about possible false positives...

@dune73

This comment has been minimized.

Copy link
Collaborator

commented Jul 24, 2019

This looks good. Thank you for the PR.

Could you please add the regex-generator call to the comment section like we do with the other generated rules?

@gotwf

This comment has been minimized.

Copy link

commented Jul 26, 2019

Would be nice to see more "REQUEST-934" app attack rules. Good on ya' for the effort. 👍

@lifeforms

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 27, 2019

@gotwf What kind of rules would you like? Some more common Javascript snippets?

@gotwf

This comment has been minimized.

Copy link

commented Jul 27, 2019

Generally more attack rules for "modern stack" stuff like various nosql db's, node.js, etc., especially since the "LAMP" stack of yore tends to be regarded in many circles as "legacy" and to be avoided to extent possible nowadays. Got to keep one eye towards the future and not allow mitigating past errors be all consuming. I'm more operations that dev though so just reporting my sense of things.

Not a security researcher though so I cannot point to more specific vectors. Does this help clarify or am I too new to modsec and out in left field here?

@lifeforms

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 27, 2019

@gotwf I agree we should work in the direction of NoSQL and modern stacks. This PR is getting my feet wet, but I plan to write more rules. The thing is, I'm still mostly defending typical PHP applications, so I can easily get inspiration there, but I've not seen so many attacks on other stacks. I see this shift happening though. If you could help by finding some relevant CVEs and listing them here, we can definitely help with rule writing.

@gotwf

This comment has been minimized.

Copy link

commented Jul 30, 2019

Ah, help is always nice, isn't it? Don't have much bandwidth to spare at this time. Also more on the ops than dev end. Lame excuses but such as it is doesn't mean I don't appreciate you taking up the baton. +1 for that.

This node.js developer has some blog articles addressing owasp top ten. A bit dated but maybe some insights to be gained? http://scottksmith.com/blog/2015/06/08/secure-node-apps-against-owasp-top-10-injection/

@theMiddleBlue

This comment has been minimized.

Copy link
Collaborator

commented Aug 7, 2019

Hi all,

I would create a lab to test this PR and all further nodejs rules that we'll add. Doing it, I realized that it would be nice to have a shared and containerized lab to test new rules, with a vulnerable app protected by CRS and synced with a specific pull request.

I'm trying to do something in this way, using the @franbuehler CRS docker image and a vulnerable nodejs app. I'm also trying to "standardize" (as much as I can) all scripts and docker-compose. You can find a draft here: https://github.com/theMiddleBlue/OWASP-CRS-PoC

asciicast

hope this could help

@lifeforms lifeforms merged commit dc2d00f into SpiderLabs:v3.2/dev Aug 19, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@lifeforms

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 19, 2019

@theMiddleBlue Really cool! I have to learn this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.