Un po' di divertimento anche se con un'ora di ritardo.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-= 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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-= Hello all,
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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-= Hi Fyodor, 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
like:
--not-evil-honest-guv
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@xxxxxxxxxxxxxxxx> Subject: Re:
Nmap compliance with new RFC 3514
[ cut ]
I got a message indicating that support has already been added to
FreeBSD...
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls"
book)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-= From: Chris Winter <chrisdwinter@xxxxxxxxxxx>
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
off.
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
head? :P
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-= From: Christopher Smith <christopher@xxxxxxxxxxxxxxxxxxxx> To:
nmap-dev@xxxxxxxxxxxx
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@xxxxxxxxxxxx>
> 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 "--compiled-for-bigtime-security-admin" options.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=
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@xxxxxxxxxxxxxxxxxx>
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.
Kind regards,
Paul Boot,
The Netherlands.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-= From: "Dario Ciccarone" <dciccaro@xxxxxxxxx>
Considering that everyone interprets RFCs the way they like (nmap OS
detection is the best example I can think of ;)), I would suggest two
flags, related:
--with-evil-intention
by itself should do nothing (or as an alternative, decide to set or not
the flag based on the output of a PRNG), but
--with-evil-intention --rfc3514-compliant
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 everybody.
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
one! ;p
By the way i loved what you said abour Iraq some days ago.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-= From: Lionel CONS <lionel.cons@xxxxxxx>
Fyodor writes:
>
> 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@xxxxxxxxxxxxxxxx>
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@xxxxxxxxx>
<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@xxxxxxxxxxxx>
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.
James
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=
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
own.
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@xxxxxxx>
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 you)?
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@xxxxxxx>
The Evil Bit should be set to 1 automatically when packets are routed
through Avian Carriers (see RFC1149).
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-= From: "dave" <dave@xxxxxxxxxxxx>
http://www.ietf.org/rfc/rfc3093.txt
http://www.ietf.org/rfc/rfc3092.txt
http://www.ietf.org/rfc/rfc3091.txt
http://www.ietf.org/rfc/rfc1149.txt
http://www.ietf.org/rfc/rfc0748.txt
--
Salve
Ivan Sergio Borgonovo
http://www.webthatworks.it/
give peace a chance
http://www.newamericancentury.org/statementofprinciples.htm
http://www.msnbc.com/news/795649.asp?cp1=1
|