Nmap Announce 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. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 () research att com> 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 () 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 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 () 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 "--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 () 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. Kind regards, Paul Boot, The Netherlands. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 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 () cern ch> 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 () 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. 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 () 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 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 () 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> 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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Cheers, Fyodor -------------------------------------------------- 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).
Current thread:
- "Evil bit" Redux Fyodor (Apr 01)