mailing list archives
"Evil bit" Redux
From: Fyodor <fyodor () insecure org>
Date: Tue, 1 Apr 2003 12:09:31 -0800
Uh-oh! Some people noted serious problems with the April 1 "evil bit"
proposal :). There were also many clever and humorous responses.
Here are a couple dozen of my favorites:
Why on earth would a script kiddie doing truly evil-intended things, opt
to set the bit to evil? This approach seems very naive, what with script
kiddies being script kiddies.
Nmap is an invaluable tool for network troubleshooting, as well as
incidentally prociding other value useful to "evil" people. ;-) Nmap
should always have the bit set to innocent. If you choose to do anything
else, a new hacker patch branch will be distributed that does just that.
I think is a good feature to have this kind of "evil bit", but don't you
think every blackhat will set the "i'm innocent just testing bit" in
every scanner? Don't you think it could be dangerous to make such
separation between evil and innocent traffic? Non-experienced users will
take in consideration this bit when looking at the IDS logs.
And what I think is the main problem, Im quite sure we will experience a
lot of DoS attacks through packet forging setting the EVIL bit doing
hijacking or injection attacks (think on a hacker inserting a network
packet with the evil bit active into an active ssh session, what will
happen? The firewall will block you? )
This RFC is a good approach but I think it will be better not to do
automatic verification of this bit...
Ah! For Nmap option 2 is better I guess, set EVIL by default and
specific interaction (--innocent) to select non-evil.
It seems to me that no-one with evil intent is ever going to
set the evil flag, I am not sure why it would be in their interest
to do so. I think it would be more usefully used as a script kiddy
flag as you suggest. Set it to on for all scans and have an option
to switch it off if you know what you are doing perhaps something
Even then there would be a risk that people would try and look less
malicious by leaving the script kiddy flag on as a script kiddy
attack might be perceived as being less threating. I don't think
that I would be paying any attention to this flag if I was monitoring
traffic that did or did not contain it.
I'll be interested to hear any good reasons people come up with for
what can usefully be done with the flag.
From: "Steven M. Bellovin" <smb () research att com>
Subject: Re: Nmap compliance with new RFC 3514
[ cut ]
I got a message indicating that support has already been added to
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)
From: Chris Winter <chrisdwinter () comcast net>
NMAP should remain agnostic, and set the evil bit to .5, neither on nor off.
This should please the white, grey and black hats.
Forgive me if i'm being ignorant, but I totally don't see the point in this
at all. As if every attacker is kindly going to set the 'evil bit' just to
let their victim know that all their packets should be dropped. Is this a
joke? If not, I'd say add a --evil, it'll probably never be used, but ohwell
[ From a user who requested anonymity for some reason ;) ]
I think it is obvious that the default should be set based on
the location NMAP is being run from and the nationality of the
individual running NMAP. This may result in nasty problems
much like the days of crypto export controls, but I am sure
you will all see the positive far outweighs the negative.
1) When run by a good Christian US citizen, the bit should
be set to 0 since the good people of the USA can always
be trusted... I mean, we are the good guys! Questioning
any scan performed by a God Fearing US Citizen will result
in immediate and severe huffiness.
2) Less trustworthy US "citizens", immigrants, visa holders,
and people named "Francois" living in the US will need to
go to their local Immigration and Naturalization office for
a quick and friendly 36 hour interrogation before granted
use of the 0 bit. Even after clearing this, though, every
100th packet will have the bit set to 1 just in case.
3) British and Spanish government officials will be able to
use the same version as Jesus Loving US Freedom Fighters,
however, the traitorous citizens of Britain and Spain
fall into the next category:
4) Feriners, especially the French, will have the bit set to
1 at all times. This of course includes honorary Frenchmen
like Fyodor, as well as protesters. The version of NMAP
made available to "outsiders" (especially the French)
will be name NMAP-FreedomStyle and display a crude ASCII
rendition of the American flag at the start of each scan.
Personally, it seems like an evil bit would be set by
he evil-user, regardless of it being an option.
Wouldn't you think so? Source code would be altered to
serve his/her purpose. I think the idea of "evil-bit"
is futile, as all that would happen is the hacker
would use libraries, device drivers, altered nmap
source, or whatever to disable the use of an evil-bit.
A better solution would be if the evil bit is set by
the ISP, and included as a feature in the RAS. Talk to
the Lucent's, Redback's, Cisco's in the industry, and
make a feature request.
Let freedom reign at the desktop. It's too difficult
to enforce controls at the desktop, and pisses people
that's my 2C or 1.5P.
Fyodor, master of puppets, how're you doing? I'm fine, thankyouverymuch.
Well... I believe that RFC to be pathetic. Anyway, if you'd like to be
compliant with it, I believe that options such as Decoy Scanning, etc,
should set that bit. Anyway, I'm quite against this whole idea. Have you
ever seen a corrupt politician with a "I'm a motherfucker" flag in it's
From: Christopher Smith <christopher () christophersmith net>
To: nmap-dev () insecure org
I have created (but not tested) a patch that would put Nmap into compliance
with new Internet RFC 3154 (1-Apr-2003) by setting the "evil bit" on all raw
packets generated by Nmap. Attached.
[-- Attachment #2: nmap.patch --]
[-- Type: text/x-diff, Encoding: 7bit, Size: 1.8K --]
my personal opinion is this:
script kiddies should not be a concern when considering how to handle
this "evil" bit. what should be considered is what types of scans are
considered evil, and then in what ways/when should or would one even
care about the bit being set one way or another.
skript ciddies will always have some tool to abuse without even
knowing how to really use it. i highly doubt an "evil bit" will ever
get in the way of what they want to do. instead, we should think
about how non-skript ciddies use nmap and how they might want the evil
bit set. my first instinct is to make certain scans have a certain
default bit set and other scans have a different default bit set, and
add an argument designed specifically to override that default. i
would handle the defaults like this:
TCP Connect() scans by default would have the bit set to
non-evil. come on. i don't think anyone in their right mind could or
would use a plain old TCP Connect() for some evil purpose. it just
wouldn't do much good compared to other methods. then i'd say that if
they used a timing of Insane override that connection-type's default
and set the default bit to "evil", of course overridable by the
user-supplied argument. this sort of layered intelligence on defaults
could also lead to confusion on the part of the skript ciddies, and
considering they're lazy not to mention mostly ignorant people they
wouldn't always care about typing in "--set-evil-ipv4-bit 0". of
course the non-skript ciddie would already know which scan types and
combinations lead to what default bit so it shouldn't be a big issue
to those who understand its use.
i'll bring this issue up with people at my local 2600 meeting this
friday and hopefully i can get more opinions on the subject.
From: "Kurt Seifried" <listuser () seifried org>
1) How should Nmap determine evil intent? Perhaps an --evil option
would be handy, or maybe a standard environmental variable should
be used (SCRIPT_KIDDIE=1?) so that all security programs run by the
hacker set the flag appropriately? Or maybe Nmap could ship with a
hardcoded list of UNIX usernames used by known malicious hackers?
Maybe shady options like "decoy scan" and Idle Stealth scan should
always set the bit.
I think perhaps a default option configurable at compile time. For example
if I include Nmap in a rootkit I may not be able to control the username or
environmental variables properly, and would be potentially violating the RFC
which would be very rude towards the end system I am using.
2) Should the overall Nmap default be to set the bit unless the user
gives a "good intentions" option, or should we assume innocence
until proven guilty?
Configurable at compile time! Simply have a "--compiled-for-blackhat" and
The idea behind the RFC is good, but the way it was done is very stupid.
Nobody will use this EVIL bit unless it is hardcoded in the program. I
guess that is pretty much OK to be done on commercial applications like
ISS Scanner or eEye Retina but it won't work for open source program such
as Nmap. If an user can change the EVIL bit from 1 to 0 in order to make a
scan, it will be done.
An analogy for this RFC would be a law compelling bank robbers to use a
big yellow sign written "I'm gonna steal this bank". Even if it is a
security checkup authorized by the security manager it isn't interesting
to make the guards know this kind of test is being performed.
In my opinion this RFC won't be sucessful.
From: "Paul Boot - Bateau Knowledge" <pb () bateauknowledge nl>
I am very happy to hear that there is a final solution to this ugly IPv4
security issue. After adding one line in my iptables configuration I can get
rid of all evil packets by simply flipping one bit!(COOL)
It's a brilliant solution and I think it should be added asap to all
BSD/Linux kernels as a standard kernel parameter.
From: "Dario Ciccarone" <dciccaro () cisco com>
Considering that everyone interprets RFCs the way they like (nmap OS
detection is the best example I can think of ;)), I would suggest two
by itself should do nothing (or as an alternative, decide to set or not
the flag based on the output of a PRNG), but
Would _really_ set the flag ;)
I don't think it would be a good idea to implement this RFC...
Unless you wish/have to prove that nmap isn't an hacker tool.
This RFC probably won't be implemented in opensource kernels because it
restrict freedom (for my poin of view).
Anyway, even if it become implemented everywhere, there will be
techniques to reset this bit as soon as the RFC will be followed by
Thus, stupid administors will think even more they are protected by this
bit and their firewalls and script kiddies will patch their systems
without understanding anything...
For good administrators, or good hackers it won't change anything.
Anyway, i think that the idea of some usernames evilled is a pretty good
By the way i loved what you said abour Iraq some days ago.
From: Lionel CONS <lionel.cons () cern ch>
1) How should Nmap determine evil intent?
I would propose that, at each invocation, Nmap first scans the
localhost and, based on what it finds (especially the OS fingerprint),
it uses an expert system to find out whether or not to set the evil
bit. Neural networks would probably do good here, after a bit of
learning of course.
From: Stanislaw Skowronek <sskowron () ET PUT Poznan PL>
I think you could use mixing of names and numbers in the username and
matching against a dictionary to detect many h4x0rz. Also, analyzing texts
in the machine to determine if more than 25% of words end with 'z'.
That RFC is excellent, one of the best at least in few last years ;)
There seems to be some merit in the RFC. If the ultimate intent is to make
programmers liable for their code and it's use by the blackhat community.
However, as soon as you implement the extension, someone will write a patch
and that will be that. Implement the feature even if just to comply with
the RFC and let the rest of the world do what they will.
From: "Kohlenberg, Toby" <toby.kohlenberg () intel com>
<complete tangent with no redeeming qualities at all/>
here's a thought- implement a new feature that uses
fragmentation to send the bit set and unset. Then,
depending on how the OS reassembles the fragments,
they'll get evil or not.
Or maybe have Nmap do an ARIN lookup and require that
the person who runs Nmap actually be the point of
contact for the IP address range they are scanning?
That's perhaps a little less feasible. ;)
Given the options below, I'd say that any setting that
has been known to crash systems (the faster scanning
modes, some of the more strange flag combos, etc...)
should probably have the evil bit set.
Otherwise, just go with the new switch to specifically set it
at the user's request. After all the Real Bad Guys(tm)
will want vulnerable systems to respond and be compromised
or crashed so they'll have to set it.
On a side note, I really think they should have found more
than a single bit and given us the ability to specify
what kind of malicious packet we're sending, otherwise
an OS could be RFC compliant and just crash all the time
(do you think Microsoft had an early implementation in Win95?)
instead of providing the root shell that the attacker wants
and rightfully deserves...
</complete tangent with no redeeming qualities at all>
From: "James D. Levine" <levine () vinecorp com>
This is a tough one. It seems to me that Nmap has always struck
the right balance between strict compliance and useful bending of
the rules. Nmap should default to a conservative,
fully-compliant setting, but allow full control for more
advanced, deliberate use.
For RFC 3514 this properly translates to default E=0 for -sT, and
E=1 for all other scan types. I'm for a command-line switch. A
--evil switch can override to force E=1 for all scan types. For
E=0 override there would be the complimentary --good, or
--innocent (for strict compliance).
One can imagine --evil will be very welcome among the novice
hackers early in their careers, as they take those first hesitant
steps towards evil hacking.
It might be more useful to have pre-defined profiles, similar to
the existing timing switches (Paranoid, Sneaky, Polite, etc.):
--evil E=1 for all scans
--good E=0 for all scans
--wanna-be-evil E=1, forces -sT scan sequential ports/addresses
--l337-h4X0r E=0, forces IP range = www.asiankitty.com
--evil-genius E=n/a, nmap successfully predicts movements
in the stock market via a complicated
alogorithm scanning Fortune 500 sites
I suggest those only as a first swipe at the problem.
I'm troubled by some of the deeper implications and
interpretations of an --evil switch, but will restrain myself
from further exploration, pending the many intelligent analyses
of the RFC forthcoming on this list and elsewhere.
I know this probably wouldn't happen, but what if an attacker specified the
evil bit to be 0 either intentionally or accidentally.
There should be an 'attacker profile' that is built by the number of attacks
they have initiated -- but the attack HAS to have the evil bit set to 0x1 --
otherwise they will not get credit for the attack...in fact it should count
against them if they initiate an attack with the evil bit set to 0x0. This
way there is a common way to evaluate an attacker...not just the creative
use of capital letters in their handles.
Hi, I don't normally get involved in discussions of this nature
because basically it is just opinion and well, everyone sure has their
Anyway, I just wanted to comment on this. Is there really such a
problem today with hackers that we need to continue to "complicate"
matters more by adding new rules and regulations? From what I have
learned hackers malicious activity has decreased. It is the script
kiddies that have stepped up thier activity. Thier existence in the
technology community is inevitable as is their annoying behavior. Let
me explain. Kids (or immature adults) get bored and they look for a
way to express themselves or make thier mark on the world. They can
do this by being a script kiddie. However, the damage they cause with
thier "malicious" intent is, for the most part, an annoyance. At
least this is how I understood "the world" to be.
I say that we are complicating matters by adding these new rules and
regulations because how can a bit determine my true innocence or
guilt. I don't like that much at all. Honestly, I like to use "Black
Hat" tools... It is a way to learn. I am a self learner and though I
know some would question my ethics I know I would never do any actual
damage (when I say this I mean I would never use nmap to exploit the
weaknesses that I might find on networks). Therefore, if I am trying
to learn the nature of people and networks (and network security) I
shouldn't have to worry about the feds knocking on my door and
charging me for having an evil bit. Maybe I am taking this to the
extreme but I have thought about this alot. I am a wardriver, I do it
for fun but I also find it has helped me expand my knowledge about
networks and network security. I guess I am tired of people calling
me a hacker and questioning my ethics when in the long run all I want
to do gather as much knowledge as I can so that I can be in a position
later in life to help these people out. That's just my two cents.
Thanks for listening.
From: "Pez Mohr" <boredMDer74 () msn com>
I say that you should set it so that the, as you said, 'more shady' options
should set the evil bit. However, these may be used to legimitely scan a
network you have permission to. There's no real way to set this one in such
a way as to please everyone, I think. Perhaps keep it to set the evil bit by
default, and creating a flag to supercede that (-EO or --evil-off, what have
I mean really, when was the last time you've heard of a script kiddie
reading the man pages for a utility? You could keep it out of the
normal --help output in an effort to keep only those informed from setting
the evil bit on their scans.
2) Should the overall Nmap default be to set the bit unless the user
gives a "good intentions" option, or should we assume innocence
until proven guilty?
As said above, I believe that as far as a scanning utility w/ this kind of
power (btw, great job, Fyodor) I think that guilty until proven (or told)
innocent is a good choice. Just some thoughts...
From: Florin Andrei <florin () sgi com>
The Evil Bit should be set to 1 automatically when packets are routed
through Avian Carriers (see RFC1149).
From: "dave" <dave () netmedic net>
For help using this (nmap-hackers) mailing list, send a blank email to
nmap-hackers-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).
- "Evil bit" Redux Fyodor (Apr 01)