Node Security: The Good, Bad & Ugly

32
NodeJS Security: The Good, Bad & Ugly

description

 

Transcript of Node Security: The Good, Bad & Ugly

Page 1: Node Security: The Good, Bad & Ugly

NodeJS Security: The Good, Bad & Ugly

Page 2: Node Security: The Good, Bad & Ugly

A look at Server Side JS History. How old do you think it is?

Page 3: Node Security: The Good, Bad & Ugly

1996 (LiveWire). Rhino (1997). 50+ more since then

Page 4: Node Security: The Good, Bad & Ugly

something went wrong…

Slow JS Engines JS not interesting

to many

JS is

misunderstood.

Under-rated

Lack of a

compelling

browser war

Page 5: Node Security: The Good, Bad & Ugly

So why now?

The Browser War

Lead to blazing fast engines

Google V8 (NodeJS uses this), FF SpiderMonkey, MS Chakra

Page 6: Node Security: The Good, Bad & Ugly

Wh

y is

it s

o H

OT?

Sp

eed

. Per

form

ance

. JS

to d

o it

all.

Page 7: Node Security: The Good, Bad & Ugly

Adoption: 11/11

Page 8: Node Security: The Good, Bad & Ugly

Adoption: 02/12

Page 9: Node Security: The Good, Bad & Ugly

(5 min Tech Primer) Event-driven. Asynchronous.

Single-threaded

Page 10: Node Security: The Good, Bad & Ugly

Traditional Platforms

• A sample code

• Pitfalls

– The program blocked when reading from db

– Lots of processor cycles wasted

data = readFromDatabase();

printData(data);

doSomethingUnrelated();

Page 11: Node Security: The Good, Bad & Ugly

In Node

• A typical code

• Gains – not have to wait for slow file I/O or db ops. Aka non-blocking server – everything runs in parallel. doSomethingUnrelated() doesn’t wait. – printData(data) called when finished reading – insanely fast – serve millions concurrent connections at once

readFromDatabase(function(data) { printData(data); }); doSomethingUnrelated();

Page 12: Node Security: The Good, Bad & Ugly

(What is MISSING?)

A production

Web Framework / MVC Arch.

Enter – Express, Mustache, Jade

A DB server.

Enter – NoSQL (MongoDB, CouchDB)

A full stack dev libraries.

Enter – NPM

Page 13: Node Security: The Good, Bad & Ugly

(In)Security

Page 14: Node Security: The Good, Bad & Ugly

(Mostly B’coz)

“JavaScript has so much expressive power that they are able to do useful things in it, anyway.”

http://javascript.crockford.com/javascript.html

"JavaScript is the world's most misunderstood programming language.”

http://www.crockford.com/javascript/private.html

With Power comes

Responsibility

Page 15: Node Security: The Good, Bad & Ugly

(The Ugly Parts)

Property: Implied Globals

Abuse: Namespace Pollution

Impact: what’s the worst you can think?

Property: eval (new Function,setTimeout,setInterval)

Abuse: JSON Parse, shortcuts

Impact: Host Compromise

Property: process privilege

Abuse: run as root (even Express)

Impact: Why does Apache run as nobody/nobody?

Page 16: Node Security: The Good, Bad & Ugly

Global Namespace Pollution

JS is a global lang. By default – all variables, functions, objects are

implied to global scope

(In contrast, with PHP (or others), each request lives in it’s unique scope.)

Page 17: Node Security: The Good, Bad & Ugly

Global Namespace Pollution

# Any request will share the same global scope. # As seen , for two different users, each request increased gbl by 1 (Try yourself: http://46.137.9.100:1314/)

WEB USER 1 WEB USER 2

An equivalent code in PHP will always print 1 for every request.

Page 18: Node Security: The Good, Bad & Ugly

• Overriding / Hijacking Sensitive Globals. Host Compromise • How? imagine XSS and SOP. think your browser is now server • Another innocent sample

– Bob sets is_valid to true for operation X but forgets to call it as “var”.

– Alice coding on the same project also forgets “var” and initialized is_valid to false.

• Attack Surface?

– NPM: malicious library. Insecure library – Malicious coder – Innocent coder

Y.mojito.controller = {

index: function(ac) {

var is_valid = true;

Y.mojito.controller = {

index: function(ac) {

if (is_valid){

// get access to user data or some functions

Exploits: Namespace Pollution

Page 19: Node Security: The Good, Bad & Ugly

eval is EVIL

USE CASE # treats data as code. Very powerful. Very very popular.

EXPLOIT # CODE EXECUTION. COMMAND EXECUTION. SHELL EXECUTION. NEVER USE IT! SIDE NOTE: exists in NPM. Audit. Audit. Audit.

eval has cousins – setTimeout, setInterval, new Function. DON‘T USE THEM

Page 20: Node Security: The Good, Bad & Ugly

eval is EVIL

Try yourself: http://46.137.9.100:1313 Exploit code: response.end(“my first ssi”)

Page 21: Node Security: The Good, Bad & Ugly

Runtime Privilege Context

# By default, NodeJS runs as privileged user

# By default, Express runs as privileged user

Why? Remote Shell Exploits.

Why Apache runs as nobody/nobody?

Page 22: Node Security: The Good, Bad & Ugly

(The Bad Parts)

Property: with

Abuse: shorthand typos

Impact: Context dependent

Property: switch

Abuse: faulty fallthru

Impact: Context dependent

Property: single threaded / interpreted

Abuse: incomplete exception handling

Impact: DoS

Property: templating engines [mu, jade, ejs, haml]

Abuse: context sensitive output escaping

Impact: XSS

Page 23: Node Security: The Good, Bad & Ugly

with is EVIL (exploitable on Cocktails)

Use Case# welcome message What went wrong # typo,…

Page 24: Node Security: The Good, Bad & Ugly

with is EVIL (exploitable on Cocktails)

Exploit # Depends (Try yourself: http://46.137.9.100:1315/)

Page 25: Node Security: The Good, Bad & Ugly

DoS (*doesn’t affect Express)

Generate a simple exception

JS is interpreted, NOT compiled. Code itself shouldn’t be faulty. Else it’s a self-DoS. Very difficult to ENSURE this.

Page 26: Node Security: The Good, Bad & Ugly

switch is EVIL (an old foe)

Use Case# Valued Customer be given 10% discount only Exploit # missing break leading to privilege escalation

Page 27: Node Security: The Good, Bad & Ugly

switch is EVIL (an old foe)

Exploit # Valued Customer getting more discount (Try Yourself: http://46.137.9.100:1317/)

Page 28: Node Security: The Good, Bad & Ugly

No CSAS Output Escaper

• What is the #1 web security issue? XSS (going to spiral further)

• All templating engines for NodeJS only provide HTML Context Escaping

Good, but shouldn’t an excellent new technology

attempt to fix the remaining BAD things?

<a href=“$url”> my url </a>

$url = javascript:alert(1)

<body onload=“bingbang(‘$id’)”>

$id = ‘);alert(1);

<script> var a = $b </script>

$b = ; alert(0);

<div name=$c>

$c = onload=alert(1);

many more….

• We ported Google AutoEscape to NodeJS, nicknamed Joe Will be open sourced soon…

Page 29: Node Security: The Good, Bad & Ugly

<!-- Research In Progress -->

• Can you do cross-domain (SetSecurityToken, RunInContext)? – Exploiting hosted environments

• NPM packages – Think external JS. Malicious? Insecure?

– Now even C libraries

• Are other JSLint bad practices exploitable? – Is Automatic Semicolon Insertion exploitable?

– Many more…. Read “The Good Parts” once again

Page 30: Node Security: The Good, Bad & Ugly

(SOLUTION)

Training JSLint

Secure Dev Frameworks

Coding Guideline

EcmaScript5

Page 31: Node Security: The Good, Bad & Ugly

(The Good Parts)

Bare bone web server.

Remember NetBSD?

Isn’t configured / capable more than what you want.

Unlike Apache, Tomcat, IIS?

But why is it good?

More features, bigger attack surface. Bigger attack surface, more chances of things going wrong.

And something that can go wrong will go wrong. E.g. 1.3 zillion BO exploits world has seen

Page 32: Node Security: The Good, Bad & Ugly

// end of a beginning twitter: b1shan / yukinying

blog: http://bishankochher.blogspot.com/