

Fusker - a NodeJS security system that attacks back - mikaelchoni
https://github.com/wearefractal/fusker

======
jgrahamc
The idea of a firewall of some sort for web applications seems like a good
idea, but this particular one seems rather lame. For example, here's the
complete code that implements the 'local file inclusion' attack detection:

    
    
      var url = require('url');
    
      exports.check = function (req, res) {
    	if (req.url.indexOf('../') > -1) {
    		fusker.handleAttack('LFI', req, res);
    	}
      };
    

[https://github.com/wearefractal/fusker/blob/master/lib/detec...](https://github.com/wearefractal/fusker/blob/master/lib/detectives/lfi.js)

That's very simplistic and I wouldn't be surprised if you could get round it
with trickery like ..%2F or similar encodings since if you dig in it's being
passed the req from the http Node.js module and using the .url parameter. That
returns the full URL from the request itself.

And check out how SQL injection is detected:
[https://github.com/wearefractal/fusker/blob/master/lib/detec...](https://github.com/wearefractal/fusker/blob/master/lib/detectives/sqli.js)
It appears to be completely unimplemented.

Also, the whole 'fight back' idea is a bad one. We've seen from the spam world
that fighting back tends to create collateral damage. If someone is attacking
your web site then it's best just to silently discard attacks, after all if an
attack back is detected that gives the attacker information.

Also, blacklisting IP addresses on the Internet is quite a dangerous thing to
do. The IP address being presented to the end web site may well come from a
company or from an ISP where there are many, many legitimate users on the same
IP. A blacklist needs to be managed carefully to avoid an attacker knocking
out a large group of legitimate users.

~~~
mikaelchoni
Blacklisting is done for small temporary amounts of time

And yes, some things are not finished yet. The project was started a matter of
hours ago and not even close to it's full potential

EDIT: Keep in mind you are the one who decides what modules and payloads to
use. Blacklisting is optional

------
thaumaturgy
It "attacks back" in this case by redirecting users to various other sites.
The fun thing about applications like this one is that they make for a great
self-inflicting DoS; all I have to do, as an attacker, is run a script that
launches lame attacks with spoofed IPs against a fusker site. With not too
much trouble, I could cause your website to redirect a lot of your U.S.
customers to goatse, or whatever module you decide to use.

Hate to be a killjoy, but things like this are usually not a good idea.
Unfortunately, somebody has to rediscover that every six months or so.

edit: nevermind, I was going off of hilariously out-of-date information. TCP
ISNs haven't been easy to predict in -- _gulp_ \-- about a decade. Damn, now I
feel old.

~~~
FooBarWidget
> is run a script that launches lame attacks with spoofed IPs against a fusker
> site

How do you spoof your IP in TCP? If you spoof your source address you
shouldn't be able to get past the handshake.

~~~
jgrahamc
<http://en.wikipedia.org/wiki/TCP_sequence_prediction_attack>

You spoof the IP address you are sending from and then predict the TCP
sequence number so you can make it look as though you are receiving the
replies (even though they are going to another machine since you spoofed the
IP address).

Such an attack was proposed by Hacker News' very own rtm:
<http://tools.ietf.org/html/rfc1948>

~~~
thaumaturgy
Unfortunately for my original point, it looks like my info was waaaay out of
date, and most OSs started using cryptographically random ISNs years ago.

My bad, sorry for the noise.

edit: I suppose this means it's time for me to finally discard my copy of
Inside TCP/IP, third edition. :-(

~~~
khafra
Don't just throw it away; it's great for ergonomics. Most people's monitors
are way too far below eye level.

------
mikaelchoni
OP/Creator here

Entire project was created in a matter of hours so it's pretty basic for now.
Not a fan of the "this is lame shitsux" mentality going around but I'll get
used to it. All included modules will become much more sophisticated with time
so please hold those comments off until I get more than 2 hours to put towards
the project

If you have any detection/payload suggestions please comment in here and I
will most likely add them. Keep in mind that this is all for the lulz

If you have anything you want to add, feel free to fork!

~~~
danieldk
Well, it would help if a link were posted when the project is in a more mature
state. When something is linked and upvoted, people will judge it by the
current quality, not some future state of the project.

Good luck though!

------
jameshart
Completely misses the point of XSS and XSRF attacks. In those scenarios the
'attacking' browser is actually the attacker's victim. If you use this module,
an attacker can link a victim to you and have your 'defences' arbitrarily
attack them, making you part of the problem, not the solution.

~~~
mikaelchoni
Hmm... this never occurred to me. The future of the project is going to be
socket.io packet analysis with detectives. The current http request analysis
is really weak and not intended to be the main focus

If you want to prevent this from happening there will be http-xss and socket-
xss detectives in the future, just leave out the http-xss to keep it safe.
Optionally you could always set your payloads to logging only

~~~
EButlerIV
If it's not intended to be the main focus, why are you bothering to demo it
now? Why not wait and show us something even slightly representative of what
your project is supposed to be like?

------
nbpoole
Not to belabor the point, since other people have assessed this library quite
well, but:

1\. Detecting XSS by looking for '<', '>', '(', or ')' in the URL is a very
naive approach. It can be bypassed fairly easily and many XSS vectors could
have payloads constructed that bypass this filter. Also, you're likely to get
some false positives for a certain subset of applications, since parenthesis
have legitimate uses.

2\. I'm not sure on what basis the first part of the CSRF protection is valid
or what it's trying to protect. Is it looking for an Accept header for
application/json?

3\. The second part of the CSRF protection, which looks at the referer header,
seems buggy and easy to bypass. What is it trying to accomplish? Right now, it
seems like it blocks POST requests where the referer is set and contains the
server's hostname (which valid requests will have).

4\. Detecting CSRF by looking for non-GET/POST methods is a bad idea unless
your application specifically constrains itself to those two methods. Many
modern applications are using PUT and DELETE internally for routing purposes.

5\. Detecting LFI in the URL by looking for ../ is, again, naive (although
less likely to lead to false positives than the XSS testing).

6\. The most "objectionable" part here seems to be the "fight back" options.
There are definitely some legitimate concerns about an attacker being able to
get a targeted user banned from a site (after all, you can't distinguish
between a failed CSRF that an attacker is sending and a failed CSRF that an
attacker tried to convince a target to send). For the most part though, I
don't think they're a big deal for a small, independent site that opts-in to
them: they sound a lot like the Miserable Users mod for VB
(<http://www.vbulletin.org/forum/showthread.php?t=93258>)

That being said, no system that operates like a WAF is going to be perfect.
The idea of a mod_security-like system for node.js is very cool though. I just
think the way you tried to launch it here, with no indication on GitHub or
otherwise that it's not a finished product, has led to some backlash. :-)

~~~
mikaelchoni
Thanks for the suggestions. All of the detections are extremely primitive
right now, I didn't get a lot of time to put work into them (the whole project
has roughly 2-3 hours of time into it) but tomorrow they will be improved.

As I said to someone in another comment, the main purpose of the framework is
socket.io packet analysis. The http detectives are merely for testing at this
point while the framework itself matures

------
skrebbel
I love the idea, but I think the fighting-back tricks are a bit disappointing.
I expected stuff like "uses its own botnet to ddos the attacker". Yeah yeah,
stupid, not realistic. But redirecting to goatse? Come on. That's less
exciting than a garfield comic.

------
JonnieCache
At the very least it should be using the asyncness of node to hold malicious
connections open forever, bogging down any synchronous attack tools. Although,
I doubt there are any such attack tools out there these days.

------
meow
It's all fun and games to imagine attackers and script kiddies having trouble
with this. But its scary to think what might happen if one the innocent
visitors/customers are marked as attackers by mistake.

------
munin
be careful with anything that "attacks back", the legality of that is still
being phrased.

yes, i know that it doesn't "really" "attack back" but when you phrase it that
way you're going to raise some hackles.

~~~
EButlerIV
"Attacking back" with shock images may be genuinely legally problematic, given
the untested new Tennessee law on the subject. [http://arstechnica.com/tech-
policy/news/2011/06/tenn-law-ban...](http://arstechnica.com/tech-
policy/news/2011/06/tenn-law-bans-posting-images-that-cause-emotional-
distress.ars) . Using the included nimp payload is even more legally
problematic since it actually does redirect the user to a site that contains
malicious code.

I think this project, much like all "offensive security" projects, is
fundamentally misguided. At best, this project loudly alerts the hacker every
time an attack is detected, providing an easy way to black-box test the
service's attack detection criteria. At worst, it provides an easy way for
jerks to goatse, Last Measure, etc. third parties using the webmaster's site.
While I understand the kind of spiteful thrill that would come from
redirecting a (maybe not) attacker to a shocking image, quietly stopping and
logging the attack is always the best option.

~~~
mikaelchoni
Don't enable any payloads besides blacklisting then. Problem solved

------
maeon3
The solution to this is not to launch a counter attack on the attacker, but to
automatically launch automated collaborative investigation where evidence is
gathered to try to nudge the attacker into doing something that reveals his
location/identity.

1\. Software notices inappropriate behavior.

2\. Launches a honeypot service with lots of holes in it to give attacker
opportunity to get root.

3\. Root takes them to a locked down part of the computer.

4\. Have the system project a computer where the admins are complete fools,
making the attackers feel a false sense of security.

5\. Send investigation information about the attacker to other servers running
this software, ask other servers to "Help me find the bozo using this spoofed
IP address". If you see someone transmitting on this IP, help me find its true
origin.

The software could recursively trace right back to the ISP that is hosting the
computer of the attacker. Don't have it launch a counter attack, the goal here
is not to send the attacker to goatse (he probably enjoys it). The
counterattack should be in the form of a policeman tapping the attacker on the
shoulder and saying: "you have the right to remain silent".

The answer is not fighting back immediately, it's sun tzu's legendary advice,
let the enemy think they have gamed your box, so they launch a bolder move,
then you catch them with their hand in the cookie jar.

~~~
younewman
How exactly is this "recursive trace" going to work? As soon as you get to a
computer the attacker controls he can subvert whatever mechanism you're
thinking of.

~~~
xpaulbettsx
If you were clever with virtualization software, you could let the VM guest
get taken over, and use heuristics on the host to detect where they were
coming from.

